Python爬虫遇到403 Forbidden怎么办_通过伪造User-Agent与Cookie绕过封禁

Python爬虫遇到403 Forbidden怎么办？通过伪造User-Agent与Cookie绕过封禁

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

为什么加了User-Agent还是返回403 Forbidden

问题往往出在这里：你以为只换件“外套”就能蒙混过关，但服务器早已升级了安检系统。如今，多数网站早已不再单纯校验User-Agent，而是将Accept、Accept-Language、Referer乃至请求频率等多个维度结合起来，进行综合判断。单独修改User-Agent，就好比只换了件外套，身份证却没换——在服务器眼里，依然是那个可疑的爬虫。

那么，具体该怎么操作呢？

立即学习“Python免费学习笔记（深入）”；

• 第一步，用真实浏览器抓包。打开Chrome DevTools，切换到Network标签页，刷新目标页面，然后任意点击一个请求，查看其Headers。你需要完整复制Request Headers里除Cookie外的常见字段。
• 至少需要补全Accept、Accept-Language、Sec-Ch-Ua（如果存在）、以及Sec-Fetch-*系列请求头（部分站点对此有强校验）。
• 注意，避免使用过时的UA字符串。例如，如果还写着Mozilla/5.0 (Windows NT 10.0; Win64; x64)却没有带上Chrome/120.0.0.0这类新版浏览器标识，同样容易被识别。

如何安全复用浏览器的Cookie而不暴露登录态风险

直接把登录后获取的Cookie字符串硬编码进代码，是一种风险极高的做法。这无异于把门禁卡直接贴在玻璃门上——一旦卡片过期或被系统轮换，整个请求链就会立刻崩溃。更糟糕的是，如果Cookie里包含sessionid或_auth_token这类敏感字段，还可能引发账号异常，得不偿失。

安全复用的实操建议如下：

立即学习“Python免费学习笔记（深入）”；

• 推荐使用selenium或playwright这类工具启动真实浏览器。完成登录后，再导出与requests.Session兼容的cookie字典。示例代码如下：

  from requests import Session
  from selenium import webdriver
  
  driver = webdriver.Chrome()
  driver.get("https://example.com/login")
  # 手动或自动完成登录
  cookies = driver.get_cookies()
  s = Session()
  for c in cookies:
    s.cookies.set(c['name'], c['value'], domain=c.get('domain', ''))

• 避免长期保存Cookie文件，尤其不要将其提交到Git仓库。如果确有持久化需求，务必加密存储并设置合理的过期时间。
• 检查Cookie中是否包含HttpOnly字段。这类Cookie无法被前端Ja vaScript读取，selenium通常也拿不到，遇到这种情况就必须走服务端的登录流程，或者换用playwright（它支持拦截响应头）。

requests.get()发请求仍被封？试试Session + mount自定义适配器

很多人习惯直接用requests.get()，但这恰恰可能成为被封锁的原因。默认情况下，requests每次都会新建TCP连接，没有连接复用机制，也不维护TLS会话上下文。而现代WAF（如Cloudflare、Akamai）会检测“连接指纹”，包括TLS版本、SNI顺序、ALPN协商值等。这种一次性的、来去匆匆的请求，就像访客刷了门卡进楼又立刻消失，系统很容易将其标记为可疑行为。

如何改进？关键在于模拟一个稳定的、有状态的“访客”。

立即学习“Python免费学习笔记（深入）”；

• 始终使用Session对象。它能自动复用底层HTTP连接、保持Cookie状态、并复用DNS缓存，行为更接近真实浏览器。
• 更进一步，可以为Session挂载一个定制的HTTPAdapter，从而精细控制底层urllib3的行为：

  s = Session()
  adapter = HTTPAdapter(pool_connections=10, pool_maxsize=10)
  s.mount("https://", adapter)

• 在极端场景下，可能需要指定ssl_context来模拟真实浏览器的TLS栈（这需要pyOpenSSL和cryptography库）。不过对于大多数情况，仅仅开启keep-alive并设置合理的pool_maxsize，就足以绕过初级的封禁策略了。

哪些行为比Header更易触发403，却常被忽略

请求头只是表层伪装，真正让WAF拉响警报的，往往是请求的“节奏”与“内容语义”。举个例子：一秒内连续请求20个不同ID的详情页，或者在URL参数中呈现?page=1→?page=2→?page=3这种完美的线性递增——这些行为在人类的操作中几乎不存在。

下面这些坑，你是否也踩过？

• 使用固定的time.sleep(0.1)可能不够。WAF会识别“请求间隔的标准差”，过于固定的间隔反而更像脚本。改用random.uniform(1.2, 2.8)这类带有波动的随机延时，会更像真人操作。
• URL参数的顺序不一致。例如，/api?b=2&a=1和/api?a=1&b=2可能被服务器视为两个不同的资源，频繁切换参数顺序容易触发路径遍历检测。
• 响应体解析失败后仍继续请求。比如某次请求返回了一个HTML登录页（意味着可能已被重定向到登录界面），而你的代码却强行用json.loads()去解析，接着抛出异常并重试。这种“异常响应+高频重试”的组合，是典型的爬虫特征。

说到底，绕过封禁不是比拼谁的请求头更长，而是要让每一次请求，在网络层、应用层、行为层都像一个真实的、有停顿、有上下文、偶尔也会点错链接的“人”。最危险的，往往就是你自以为“已经够像人”的那个环节。