只改User-Agent不够用，因为现代网站会校验Accept、Accept-Language、Sec-Ch-Ua等字段是否与UA逻辑自洽；需确保所有请求头构成一致的浏览器指纹，否则易被识别为自动化工具。
为什么只改 User-Agent 不够用？
很多网站现在不只看 User-Agent，还会检查 Accept、Accept-Language、Sec-Ch-Ua、Sec-Ch-Ua-Mobile、Sec-Ch-Ua-Platform 这些字段是否匹配真实浏览器行为。比如你发一个 Chrome 120 的 User-Agent，但没带对应的 Sec-Ch-Ua 字段，或者 Sec-Ch-Ua-Platform 写成 "Linux" 而实际请求来自 Windows，就可能被识别为自动化工具。
绕过这类检测的关键不是“伪造得像”，而是“组合一致”——所有 header 必须构成一套逻辑自洽的指纹。
-
Sec-Ch-Ua和Sec-Ch-Ua-Mobile必须与User-Agent中的浏览器版本、设备类型对齐（例如桌面 Chrome 通常配Sec-Ch-Ua-Mobile: ?0） -
Accept-Language应与目标用户地域习惯一致（如中文站点优先用zh-CN,zh;q=0.9） -
Accept和Accept-Encoding要匹配主流浏览器默认值（Chrome 通常发text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8）
怎么生成一套可用的、带完整 Sec-* 头部的请求？
手动拼接容易出错，推荐用现成的、更新及时的指纹库，比如 fake-useragent + 手动补全 Sec-* 字段，或直接用 undetected-chromedriver（适合 Selenium 场景）。但如果是 requests 爬虫，最轻量的做法是复用真实浏览器抓包结果。
操作步骤：
立即学习“Python免费学习笔记（深入）”；
- 用 Chrome 打开目标网站 → F12 → Network → 刷新 → 点击任意 HTML 请求 → Headers 标签页 → 复制全部 Request Headers（注意去掉
Cookie、Referer等会话相关字段） - 把复制内容转成 Python 字典时，注意：
Sec-Ch-Ua中的双引号要保留，且整个值要用单引号包裹，避免 Python 解析错误，例如：'Sec-Ch-Ua': \'\"Chromium\";v=\"124\", \"Google Chrome\";v=\"124\", \"Not-A.Brand\";v=\"99\"\'' - 不要硬编码固定指纹，建议每次请求随机选一组已验证的 header 组合（可存为 JSON 文件，含多套 Win/macOS/Chrome/Firefox 指纹）
requests 发送时哪些 header 容易被自动覆盖？
requests 库会在你没显式设置时自动添加某些 header，比如没传 Accept-Encoding 就会加 gzip, deflate；没传 Connection 就默认设为 keep-alive。这些看似无害，但和真实浏览器行为不完全一致，尤其当服务端做深度指纹比对时会暴露问题。
稳妥做法是：显式声明所有关键 header，并禁用 requests 的自动补全：
- 传入
headers=your_headers时，确保包含Accept、Accept-Language、Accept-Encoding、Connection、Upgrade-Insecure-Requests等字段 - 避免使用
session.get(...)前未清理 session 默认 headers；必要时用session.headers.clear()再重置 - 注意
requests会自动将User-Agent设为python-requests/2.x，除非你显式覆盖——这点常被忽略
绕过指纹检测后，为什么还是被 403 或验证码拦截？
Header 只是第一道关卡。如果服务端启用了更深层的行为分析（比如请求频率、鼠标轨迹模拟缺失、TLS 指纹、HTTP/2 支持状态），光靠 header 已经不够。常见诱因：
- 同一 IP 短时间内复用相同指纹，触发“指纹集群识别”——解决方法是搭配代理池 + 指纹轮换
- 没启用 HTTP/2（现代 Chrome 默认用 HTTP/2），而你的 requests 还在用 HTTP/1.1 —— 可考虑切换到
httpx并开启http2=True - SSL/TLS 握手参数（如 ciphers、ALPN 协议顺序）与真实浏览器不一致 —— requests 默认 OpenSSL 行为与 Chrome 差异较大，此时需用
curl-cffi或playwright替代
真正稳定的方案，往往不是“修 header”，而是让底层网络栈更贴近真实浏览器——这点容易被当成高级技巧跳过，但恰恰是多数人卡住的地方。
