Referer校验主要拦截非授权页面发起的请求，通过比对请求头中的Referer字符串是否来自允许域名；其本质是简单字符串匹配，易被伪造，但常与Origin、Cookie等联合校验。
Referer校验到底在拦什么
服务端通过检查 Referer 请求头，判断请求是否来自它允许的页面（比如自家官网），而非直接调用接口或爬虫脚本。这不是加密验证，只是个字符串比对——所以伪造有效 Referer 通常就能过这一关。
但注意：很多网站会同时校验 Referer 和 Origin，或者配合登录态（Cookie）做二次校验。单设 Referer 不一定够用。
requests 中怎么加 Referer 头
用 requests.get() 或 requests.post() 时，把 Referer 写进 headers 字典里就行，和其他 header 一样处理：
import requests
headers = {
"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36",
"Referer": "https://example.com/list/"
}
response = requests.get("https://api.example.com/data", headers=headers)
-
Referer的值必须是合法 URL（带协议，如https://），不能是空字符串或纯路径 - 值最好和目标接口的“来源页面”逻辑一致，比如你模拟从
/search?q=python页面点进去，就填那个完整地址 - 有些站点会校验域名层级，填
https://example.com可能被拒，而https://example.com/some/path才行
Referer 被自动清空的几种情况
requests 默认不会自动设置 Referer，但某些操作会意外导致它丢失或被覆盖：
macOS UI 自动化技能包 —— 用 Python 控制你的 Mac
下载
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- 重定向时，requests 默认会把新请求的
Referer设为上一个响应的Location地址——这可能触发校验失败；可加allow_redirects=False手动控制 - 使用
Session对象时，如果之前发过其他请求，且没显式传headers，旧 header 不会自动继承，Referer就没了 - 用
requests.request(method, ...)低阶接口时，若headers是None或未传入，自然没有Referer
绕过 Referer 校验的边界在哪
伪造 Referer 是最轻量的绕过手段，但它只解决表层校验。真正在意数据安全的服务，往往还会：
- 检查
User-Agent是否匹配常见浏览器特征（比如 Python-requests/2.31.0 就很可疑） - 要求携带有效的
Cookie（尤其是登录态 token），而这个 cookie 通常需要先访问首页触发 set-cookie - 对高频请求做行为分析（比如 Referer 正确但没带 JS 渲染痕迹、无
Sec-Fetch-*头等）
所以别只盯着 Referer ——它常是第一道门，但门后还有锁、摄像头和值班保安。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
