403错误主因是服务器通过请求头识别出非浏览器身份；requests默认无user-agent等关键头，需手动添加完整headers（含user-agent、referer、accept-language等），并注意大小写与字段完整性，缺一可能触发拦截。
为什么requests.get()返回403但浏览器能正常访问
这不是代码写错了，而是服务器通过请求头识别出了你不是浏览器。默认的 requests 请求头里没有 User-Agent，很多网站会直接拒绝这种“空载”请求。
实操建议：
Python Sdk
下载
inference.sh 的 Python SDK：运行 AI 应用、构建智能体，并集成 150 多个模型。包名：inferencesh (pip install inferencesh)。支持同步/异步……
- 给
requests.get()加上headers参数，至少包含User-Agent，比如：{"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36"} - 别用网上随手搜的 UA 字符串，有些已被封；优先用当前 Chrome/Firefox 的真实 UA（F12 → Network → 刷新 → 点请求 → Headers → Request Headers）
- 某些站点还会检查
Accept、Accept-Language、Sec-Ch-Ua等字段，缺一可能触发 403
requests.Session() 保持会话仍被 403 拒绝
Session 能复用 Cookie 和连接，但不能绕过反爬逻辑——比如服务端要求 JS 渲染后生成的 token 或时间戳签名，而 requests 不执行 JS。
常见错误现象：
- 第一次请求成功拿到 Cookie，第二次带 Cookie 请求却返回 403
- 抓包发现请求里多了一个
X-Requested-With或Referer，但没在代码里设置
实操建议：
- 用浏览器开发者工具完整复制一次成功请求的全部 headers（包括大小写），粘贴进代码的
headers字典 - 检查是否漏了
Referer：比如从https://example.com/list请求详情页，Referer必须是前一页 URL - 如果目标站用了 Cloudflare 或类似防护，requests 几乎必然失败，得换方案
用 Selenium 或 Playwright 还是 403？
说明问题不在“有没有渲染”，而在“渲染出来的行为是否被识别为自动化”。Selenium 默认启动的 Chrome 会被检测出 webdriver 属性，很多站点直接拦截。
实操建议：
- Playwright 更隐蔽，但也要禁用自动化特征：
context = browser.new_context(accept_downloads=True, user_agent="...")，并关闭accept_downloads外的无关选项 - Selenium 启动时加参数：
options.add_argument("--disable-blink-features=AutomationControlled")，再执行driver.execute_cdp_cmd("Page.addScriptToEvaluateOnNewDocument", {...})覆盖navigator.webdriver - 别用 headless 模式测试初期——先开界面看是否真能加载，再逐步加隐藏逻辑
403 伴随 Cloudflare 验证或“Checking your browser”页面
这是明确的主动防御信号。Cloudflare 的验证页不是 HTML 内容，而是 JavaScript 渲染的挑战，requests 完全无法处理，Selenium 也常卡在“正在检查浏览器”不动。
实操建议：
- 优先确认是否真的必须爬它——很多数据有官方 API 或 RSS，比硬啃 Cloudflare 成本低得多
- 短期调试可用
cloudscraper库（基于 requests 封装，自动处理部分 CF challenge），但稳定性差，版本更新频繁，容易失效 - 长期方案要么走付费代理池（带真实浏览器指纹轮换），要么联系对方申请白名单或使用其开放接口
真正麻烦的不是 403 错误本身，而是它背后代表的动态验证逻辑——每次请求可能生成不同 token，依赖本地时间、Canvas 指纹、鼠标轨迹等不可复现因素。这时候硬编码 headers 或模拟点击，大概率只是延缓失败，不是解决。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
