省流摘要： 403 和 429 不是同一类故障。403 多数是请求特征被目标站点识别------请求头、TLS 指纹、IP 信誉任意一项露馅；429 是单位时间请求数超过了站点阈值。先看返回头里有没有 Retry-After，再决定是改请求特征还是降频换出口 IP。上来就盲目挂一层代理，两种问题往往都治不好。
先按返回信号对号入座，能省掉一半排查时间
403 和 429 的处理路径完全不同，第一步是用返回信号把现象归到具体一类，而不是笼统地认为站点在拦截自己。这张表覆盖了采集中最常见的几种信号组合，照着定位即可跳到对应小节。
| 你看到的现象 | 典型返回 | 大概率方向 |
|---|---|---|
| 偶发 403，同一链接用浏览器能正常打开 | 403 | 请求头 / Cookie / TLS 指纹不完整 |
| 一上量就持续 403，单 IP 几乎全废 | 403 | 出口 IP 信誉差或已进入站点风控名单 |
| 固定间隔后返回 429，且带 Retry-After | 429 | 单 IP 请求频率超过站点阈值 |
| 并发拉高时 429 明显增多 | 429 / 503 | 瞬时并发量超过速率限制 |
| 脚本报 403，但浏览器、Postman 正常 | 403 | TLS / JA3 指纹被识别为非浏览器客户端 |
把现象拆到这一层，后续每一步排查都能落到一个具体原因上，而不是反复换代理碰运气。
排查前先固定三个观测点，不然改了也分不清是谁起的作用
排查 403 / 429 最容易踩的坑，是改一个参数就立刻重试，结果分不清到底哪一步生效。先固定三个观测点再动手：
-
抓完整返回头：记录 status code、Retry-After，以及 Server、CF-RAY 等字段，用来判断是站点本身限流还是中间网关拦截。
-
留一份对照请求：同一个 URL 用浏览器或 curl 手动跑一次，把成功请求和失败请求逐字段比对，差异往往就是根因。
-
记录请求节奏：当前并发数、每个 IP 每秒请求数、单个 IP 的累计请求量------429 的根因几乎都藏在这三个数字里。
这三样准备好，后面每改一处都能用前后对比确认是否生效，比盲改高效得多。
五类高频根因，先按概率扫一遍
403 / 429 的根因高度集中，按真实出现频率排下来就这五类。先整体扫一遍，再跳到与自己症状匹配的小节。
| 序号 | 根因 | 典型返回 | 出现频率 |
|---|---|---|---|
| 1 | 请求特征不完整：缺 User-Agent / Referer / Cookie，或 TLS 指纹暴露非浏览器客户端 | 403 | 高 |
| 2 | 单 IP 请求频率超过站点阈值 | 429 | 高 |
| 3 | 出口 IP 信誉差，IP 段已被目标站点标记 | 403 | 中 |
| 4 | 瞬时并发过高，峰值触发速率控制 | 429 / 503 | 中 |
| 5 | 触发需登录或授权的接口，超出公开数据范围 | 403 / 401 | 低 |
前两类占了绝大多数采集故障，先从它们查起命中率最高。
请求被识别成非浏览器客户端，是 403 的头号原因
如果同一链接浏览器能打开、脚本却返回 403，问题几乎都出在请求特征上。
如何确认：先把浏览器请求的完整 Header 复制到脚本里，补齐 User-Agent、Referer、Accept 和必要 Cookie；如果补齐后仍然 403，而 Postman、浏览器都正常，那大概率是 TLS / JA3 指纹问题------原生请求库不带浏览器的握手特征，会被风控直接区分出来。CSDN 技术社区有作者复盘过这一现象：脚本报 403、Postman 却成功，根因正是请求库缺少浏览器自带的 TLS 指纹。
解决步骤：补全请求头与会话 Cookie；对有指纹校验的站点，改用能携带完整 TLS 特征的请求客户端；把请求节奏放缓，避免零间隔连发。
验证是否修复：单次请求稳定返回 200，且连续多次不再偶发 403，说明请求特征这一环已经过关。
单 IP 频率超限，是 429 的头号原因
返回 429 且带 Retry-After，基本可以锁定是单 IP 请求频率超过了站点上限。
如何确认：检查返回头是否带 Retry-After 字段；把单 IP 每秒请求数下调后 429 随之消失，就能确认是频率问题。按 IETF RFC 6585 的定义，429 Too Many Requests 用于表示客户端在单位时间内请求过多，并可通过 Retry-After 首部提示需要等待的时间。
解决步骤：严格按 Retry-After 退避，不要无视它硬重试；控制每个 IP 的每秒请求数；把请求量分散到多个出口 IP，让单个 IP 的频率始终落在阈值以下。
高频采集时单 IP 用不了几秒就触发频率限制怎么办？极安代理的隧道代理把换 IP 放在云端------统一入口接入、毫秒级自动换 IP、异常 IP 自动切换，程序端不用为每个 IP 改代码，请求自然分散到不同出口。
验证是否修复：在相同总请求量下，429 占比明显下降并趋于稳定，说明频率分散到位。
出口 IP 信誉差、整段被风控，是容易被忽略的 403
有时请求头、频率都没问题，403 依然成片出现，这种情况往往是出口 IP 本身的信誉问题。
如何确认：换一批来源不同的 IP 后 403 消失，或发现报 403 的请求集中在同一 IP 段，基本可以判定是 IP 信誉，而不是请求特征。
解决步骤：评估一家代理服务商，IP 池的纯净度和日更量比总规模更值得看------长期回收复用的 IP 早被标记，新增的纯净 IP 才扛得住风控。了解到极安代理为千万级纯净 IP 资源池、日更 300 万+，IP 可用率 99.9%，新增的是经过筛选的纯净 IP，而不是历史 IP 反复回收。
验证是否修复：同一批任务的请求成功率和 IP 可用率回升到稳定区间，说明 IP 质量这一环达标。
瞬时并发与合规边界，最后两类别漏掉
前面几类都排掉后，还剩两种容易被忽略的情况：并发峰值和合规边界。
如何确认：总频率不高却在高并发时段集中出现 429 / 503，多半是瞬时并发超限；若是需要登录态、或站点明确要求授权的接口，则属于合规边界，不在技术排查范围内。
解决步骤：对并发问题，限制并发数、加入随机抖动延迟、错峰执行；对边界问题，优先走目标站点的官方 API 或授权接口，遵守 robots 约定，只采集公开、授权范围内的数据。有技术社区文章建议，遇到 403 时先核对 robots 规则、确认站点是否提供官方 API，再决定采集方式。
验证是否修复：在合规范围内稳定运行、无突发拦截，说明并发与边界都处理妥当。
这些情况不要硬扛，该停就停
不是所有 403 / 429 都该靠技术手段继续推进，下面几种情况应当停下来重新评估：
-
持续 403、换 IP 和补全请求头都无效：站点可能已要求登录态或启用了强校验，继续硬试只会让出口 IP 损耗更快，应重新评估采集路径。
-
目标数据非公开、或站点明确要求付费、授权 API：这属于授权问题而非故障，应走官方授权渠道，不用技术方式硬采。
-
数据涉及个人信息或受版权保护：先确认合规边界，再决定是否采集。
把自救边界划清楚，既是对账号和 IP 资源的保护，也是合规采集的前提。
常见问题FAQ
Q1: 403 和 429 到底有什么区别？
A1: 403 是站点理解了请求但拒绝执行，多与请求特征、IP 信誉有关；429 是请求频率超过站点上限，通常带 Retry-After。两者根因不同、解法也不同，不能一律靠换 IP 解决。
Q2: 挂了代理 IP 就不会再出现 403 / 429 吗？
A2: 不会。代理只解决 IP 来源和频率分散的问题。如果 403 是请求头或 TLS 指纹引起的，换多少 IP 都没用；429 也要配合降频和退避，单靠加 IP 治标不治本。
Q3: 什么情况下该换 IP，什么情况下该降频？
A3: 返回 429 且带 Retry-After，优先降频并分散出口 IP；403 集中在某 IP 段、换批 IP 就好，说明是 IP 信誉问题；403 但浏览器正常，先查请求特征而不是换 IP。
Q4: 返回头里的 Retry-After 应该怎么用？
A4: 它是站点告诉你需要等待的秒数或时间点。正确做法是按它的值退避后再重试，而不是无视它继续发请求------无视 Retry-After 会让频率限制持续触发。
Q5: 一直处理不了 403，会不会有合规风险？
A5: 有可能。如果数据非公开、需要登录或授权才能访问，反复用技术手段推进就越过了合规边界。这种情况应转向官方 API 或授权采集，而不是继续在 403 上较劲。