403 Forbidden：服务器明确拒绝提供内容的排查
403 Forbidden严重程度 Medium请求成功到达了服务器，但服务器根据某种策略拒绝提供内容。最可能是基于出口地址的访问控制或 WAF 拦截；第一步是换一个网络出口重试，看拒绝是否跟着出口走。
结论
403 的信息结构值得先摆正：网络层没有任何问题——DNS、TCP、TLS 全部通过，请求完整送达，服务器读完之后说了"不"。所以别去重启路由器，这是一次策略层面的对话：服务器根据它看到的你（出口地址、请求头、凭据、行为记录）做出了拒绝决定。排查就是弄清它到底看到了什么不喜欢的东西。
适用环境
- 全部平台
- 网站访问、API 调用、订阅地址（订阅场景另见 SUB-001）
一分钟快速判断
- 换出口：换节点或换网络后重试。恢复 → 服务器不喜欢的是你的出口地址（地区限制、IP 信誉、黑名单段），结案率最高的一步；
- 换客户端：浏览器正常而某工具 403 → 服务器校验的是请求头（UA、Referer 等），该工具的请求特征被拒；
- 想想凭据：带 token 的接口或订阅返回 403，先怀疑凭据过期而不是网络。
这条错误代表什么
服务器视角下的四类拒绝理由：
- 出口地址维度：目标只对特定地区开放、或你的出口 IP 段被标记为数据中心/滥用来源。共享出口的公共性意味着"别人作恶你挨枪"很常见；
- WAF/风控维度：请求频率、路径特征、指纹综合评分超阈值。特征是同一出口下时好时坏、带验证码挑战页；
- 凭据维度：过期或被重置的 token。服务端用 403（而非 401）回应无效凭据的实现相当普遍；
- 请求头维度：缺 Referer、UA 命中黑名单、缺自定义头。特征是浏览器可以而脚本/工具不行。
ConnProof 如何判断
connproof subscription "https://目标地址"（通用 HTTP 目标同样适用此命令做可达性判定。）证据要点：确认 DNS/TLS 各层通过（坐实"网络无辜"）、403 状态码、响应体类型——WAF 拦截页通常是带说明或验证码的 HTML，纯策略拒绝往往是简短文本或空体，这个差别能区分"风控挑战"与"硬黑名单"。
最常见原因
- 出口地址被限制：地区封锁、IP 段信誉；
- WAF 行为拦截：频率、指纹；
- 凭据失效：订阅 token、API key 过期重置；
- 请求头校验不过：非浏览器客户端的天然劣势。
Windows / macOS / Linux 排查步骤
- 换出口对照（两个不同地区的节点 + 直连，共三个数据点）；
- 全出口都 403 → 凭据或账号维度：重新获取地址/token；
- 仅部分出口 403 → 出口维度：固定使用干净的出口；
- 命令行工具专属 403 → 补齐请求头（UA 至少给一个正常值）后重试；
- 出现验证码挑战页 → 降低请求频率，等待冷却，不要尝试自动化绕过验证码——那既违反服务条款，也会让出口信誉进一步恶化。
手机端排查步骤
- Wi-Fi/蜂窝/代理三种出口各试一次，定位拒绝跟着哪个出口走；
- 应用内 403 而浏览器正常时，多为应用凭据过期——重新登录该应用；
- 不要反复快速重试，风控的记分板会越刷越差。
如何区分本地问题和节点问题
| 证据 | 更可能是 |
|---|---|
| 换出口后恢复 | 原出口地址被目标限制 |
| 所有出口都 403 | 凭据/账号维度 |
| 仅特定工具 403 | 请求头特征 |
| 返回验证码页 | 风控挑战（等待+降频） |
| 同出口时好时坏 | 行为评分波动 |
出口信誉：为什么"我什么都没做"也会被拒
很多用户对 403 最大的困惑是无辜感——"我就正常打开个网页"。理解出口信誉机制能化解这个困惑：目标站点看到的不是"你"，而是"你的出口 IP"。共享出口（代理节点、公司网关、运营商 NAT 池）上的行为由所有共用者共同书写：有人在这个出口上爬虫、撞库、刷接口，整个 IP 段的信誉分就会下降，风控名单收录的是 IP 而不是人。数据中心 IP 段天然比住宅宽带段信誉低，这也是"直连能开、走代理 403"的底层原因——不是代理坏了，是那个出口的"前科"太多。
由此推出的实用结论有三条：其一，同一服务多个节点里总有信誉较好的，多换几个试而不是死磕一个；其二，对信誉敏感的站点（银行、票务、部分登录系统）优先直连或用固定的干净出口；其三，不要在共享出口上运行高频脚本——那是在消耗所有共用者的信誉。
仍未解决时收集什么信息
- ConnProof 错误码（HTTP-001）与脱敏报告；
- 三出口对照结果；
- 响应体类型（HTML 挑战页 / 纯文本 / 空）；
- 问题开始时间与操作频率背景。
禁止提交：完整订阅链接、密码、验证码、私钥、Token。
重新运行检测
connproof subscription "https://目标地址" --format markdown --output http-report.md修复后应得到 2xx 状态码与预期内容类型。注意验证时机：如果你刚被风控拦截过，即使换了正确的出口，部分风控系统仍会对"新出口 + 老指纹"保持几分钟的观察期——验证前等待五到十分钟，避免把冷却期误判为"没修好"。
一个边界说明
本页讨论的是"你想正常使用而被误伤"的排查。如果目标站点明确按服务条款拒绝你所在地区或你的使用方式，绕过它的访问控制不在本站的建议范围内——那属于对方的规则，尊重规则或与对方协商开通权限才是正路。ConnProof 的价值是帮你确认"拒绝的维度"，让沟通有据可依，而不是提供绕过手段。顺带一个提高沟通效率的细节：上报给目标服务方时，附上被拒请求的大致时间与出口地区（不需要完整 IP），他们的风控日志按这两个键检索最快。
相关文档
更新记录
- 2026-07-28：规则 v1 发布，确立"三出口对照"与响应体类型判读。