爬虫 403 Forbidden 先查什么？代理、Header 和登录态
爬虫遇到 403 Forbidden 时，按代理认证、出口 IP、Header、Cookie、登录态和请求频率逐层排查，避免盲目换代理 IP。
爬虫遇到 403 Forbidden 时，不要先批量更换代理 IP。应先确认代理认证是否返回 407，再核对出口 IP、Header、Cookie、登录态和请求频率；只有这些条件稳定后，才判断是否与目标站规则有关。
403、407、429 和超时的判断分支
如果需要进一步了解错误码组合排查，可参考 爬虫 403、429 和验证码排障方法。
| 现象 | 第一检查项 | 下一步 |
|---|---|---|
| 407 | 代理认证、端口、账号和密码 | 修正认证后重试；仅在动态住宅代理 IP 的 API 提取场景检查白名单 |
| 403 | Header、Cookie、登录态和目标站规则 | 对比直连与代理请求 |
| 429 | 请求频率、重试策略和轮换节奏 | 降低频率并设置退避 |
| 超时 | 本地网络、端口、代理有效期和目标站响应 | 更换协议或测试其他出口 |
| 浏览器成功、程序失败 | Header、TLS、JavaScript 和 Cookie | 对齐浏览器请求特征 |
采集目标和访问方式：公开页、登录态、API、渲染页面
先确认目标站允许访问的范围。对获授权的公开页面，建立直连基线，再对比代理请求的状态码、响应头、Header、Cookie、登录状态、重定向链和请求频率；登录态、API 或渲染页面则还要遵守站点授权与接口规则。
浏览器成功、程序失败怎么办
浏览器成功而程序失败时，先导出浏览器请求作为对照，逐项比较 User-Agent、Accept、Referer、Cookie、跳转处理和 TLS 特征。只有出口不同而其他请求条件一致时，才适合继续判断代理资源是否影响结果。
程序请求被拒时，Header、Cookie 和 TLS 怎么逐项核对
请求实现、参数和频率也会影响结果；目标站要求登录或接口权限不足时，应先按站点规则处理。
最小请求与日志示例（仅限获授权的公开页面）
下面示例用于核对请求是否确实经过代理、Header 和 Cookie 是否按预期发送，不用于绕过访问控制：
```bash
curl -i --max-time 15 \
-x http://USER:PASSWORD@proxy.example:PORT \
-H 'User-Agent: Mozilla/5.0 (compatible; AuthorizedMonitor/1.0)' \
-H 'Accept: text/html' \
-H 'Cookie: session=REDACTED' \
'https://public.example/robots.txt'
```
伪代码核对顺序：response = request(url, proxy, headers, cookies, timeout=15); log(status, headers["location"], elapsed_ms, proxy_exit, retry_count)。Cookie、账号标识和认证信息写入日志前必须脱敏。
脱敏日志样例：2026-09-01T14:20:00+08:00 | GET /robots.txt | proxy_exit=US-NY | status=403 | location=- | elapsed_ms=842 | ua=AuthorizedMonitor/1.0 | cookie=session=REDACTED | retry=0 | action=stop_and_review
403 排查时，动态、静态和机房代理怎么取舍
| 代理 IP 方案 | 适合任务 | 测试重点 | 不应直接假设 |
|---|---|---|---|
| 动态住宅代理 IP | 多地区、短会话、公开采样或大量出口 | 地区识别、轮换节奏、结果复现 | 轮换越快效果越好 |
| 静态住宅代理 IP | 长期账号、连续会话、同地区复核 | 出口稳定、地区一致、验证码 | 仍可能触发验证 |
| 机房代理 IP | 住宅属性非硬要求、重速度或成本的访问测试 | 目标站兼容、带宽、延迟 | 天然不适合所有任务 |
公开页面需要多出口轮换时可以评估动态住宅代理 IP；登录态采集或跨页流程更需要稳定会话。选型前先确认目标站是否允许访问、请求是否需要粘性会话，以及失败是否真的随出口变化。
403、429 出现后，重试和日志应该怎么设
1. 用同一 URL 建立一次直连请求基线，保存状态码、响应头和响应片段。
2. 加入代理后复用相同请求；出现 407 时先修正认证，不进入目标站排查。
3. 认证成功但返回 403 时，对照浏览器检查 Header、Cookie、登录态和跳转链。
4. 返回 429 时降低频率，并按 Retry-After 或指数退避设置重试间隔。
5. 为每次失败记录出口、状态码、耗时、重试次数和最终结果，超过上限后停止自动重试。
排查完成后如何选择代理方案
完成直连与代理对照后，再根据失败类型选择方案：需要稳定登录会话时可查看 静态住宅代理 IP；地区匹配要求更高时再了解 原生静态住宅代理 IP。错误码较复杂时，参考 403、429 和验证码排查指南，并把状态码、请求头、Cookie、登录态和重试日志一起提交。
FAQ
爬虫代理 IP 适合哪些场景？
代理 IP 适合用于验证错误是否随出口变化，以及为允许访问的公开页面提供多出口请求。它不能替代登录权限、接口授权或目标站允许的访问方式。
爬虫代理 IP 应该选动态还是静态？
无登录态的短请求可以先测试动态住宅代理 IP；需要 Cookie 连续、跨页操作或登录态的采集任务，应优先评估可保持会话的方案。
配置后如何确认代理已经生效？
用实际请求确认代理生效：日志中应看到代理出口，并且目标站请求确实经过代理。仅查看浏览器 IP 检测页，不能证明程序请求也使用了相同配置。
出现验证码/打不开/地区不准时先排查什么？
验证码增多时先降低频率并检查 Cookie 与会话；完全打不开时先查认证、协议和端口。地区不准时再核对出口定位，不要把三类问题同时归因于代理质量。