多跳代理怎么逐段排查？

本文属于 代理检测完全指南 系列，聚焦多跳链式代理的逐段隔离与故障定位。

本地 VPN → 住宅代理 → 目标网站，三层都「能连」，业务却 403 或匿名度从 Elite 掉到 Transparent——多跳代理最怕的不是某一跳慢，而是不知道坏在哪一跳；HTTP CONNECT 隧道见 RFC 9110 CONNECT。整链重配往往浪费时间，还可能把本来正常的节点换掉。本文在 链路检测入门 之上，给出多跳故障树、逐段 curl 命令与 008ip 验收对照方法，帮你把问题钉死在具体环节。

与 C09 入门指南的区别

链路检测入门（C09）按单跳四环节建模：本地→代理入口→代理出口→目标响应。它回答「这一个代理能不能把请求送到目标站」，适合刚配好凭证、需要确认连通性的场景。

多跳链式代理（本地→VPN→住宅→爬虫网关→目标）则引入中间转发层：每一跳都可能注入转发头、叠加延迟、或把上一跳的真实 IP 暴露给下一跳。C09 的「全链路一次 curl」在多跳下只能验证最终入口是否生效，无法告诉你「是第二跳住宅池脏了，还是第三跳网关把 X-Forwarded-For 写进去了」。

表1：单跳入门 vs 多跳进阶检测

简单判断：只用一个代理 → 读 C09；VPN 与代理同时开、或浏览器插件再套一层网关 → 读本文，按跳拆解。

多跳链路模型

把链式代理抽象为五段，便于记录排查笔记：

1. L0 本地环境 — 系统代理、TUN 网卡、DNS、WebRTC 是否绕过链路透传
2. L1 第一跳入口 — 常见为 VPN 客户端或本地 HTTP 网关（如 Clash、Proxifier 上游）
3. L2 中间跳 — 住宅/机房转发节点，可能再套供应商内部 NAT
4. L3 末跳出口 — 目标网站实际看到的公网 IP，风控与 403 都针对这一地址
5. L4 目标响应 — 状态码、TLS、业务 Cookie 与地区策略

多跳排查的黄金法则：先单跳、后组合。每一跳单独 curl 能通，再逐级叠加；哪一级叠加后首次失败，问题就在刚加上的那一跳。末跳 IP 与匿名度评级以 L3 为准，中间跳再干净也不能替代末跳验收。

故障树：超时、403、匿名度

分支 A：连接超时 / 极慢

从 L0 向下逐段测量 RTT，不要一上来就 curl 目标业务 URL：

• L0→L1 超时：VPN 未连接、本地防火墙拦端口、DNS 解析到错误入口
• L1→L2 超时：住宅代理认证失败、IP 池耗尽、供应商区域线路故障
• L2→L3 超时：内部网关拥塞；常见于「入口显示在线但出口分配挂起」
• L3→L4 超时：目标站对末跳 IP 段限连、或地理距离导致 TTFB 超标（跨洋多跳延迟叠加）

多跳延迟近似各跳之和。单跳 P50 2s、三跳合理预期 4–6s；若总耗时 >10s 且某一跳单独测也 >5s，优先换该跳节点或降跳数。

分支 B：能连但返回 403 / 429

403 几乎总是末跳出口 IP 或请求画像问题，不是本地 VPN 段的问题——除非目标站按完整 X-Forwarded-For 链封禁。

• 仅多跳组合 403、末跳单跳 200 → 中间跳注入了可疑头（Via、X-Real-IP）或改变了 TLS 指纹
• 末跳单跳也 403 → 该出口 IP 已被目标封；换 IP 或换池，与跳数无关
• 直连正常、任意代理 403 → 目标反爬策略，需住宅末跳 + 合规 User-Agent，见 代理检测 FAQ

分支 C：匿名度从 Elite 降为 Transparent

匿名度在链路上只升不降：任一中间跳写入 X-Forwarded-For、Via、Forwarded，末跳再删头也来不及——目标站已收到。逐段对 httpbin.org/headers 或 008ip 匿名度模块发请求，对比哪一跳之后出现泄露字段。分级标准见 代理匿名度检测。

常见根因：企业 VPN 强制透明转发；免费网关默认追加 XFF；供应商「高匿池」与「普通池」混用，第二跳实为透明节点。

逐段 curl 排查示例

以下命令假设两跳 HTTP 代理：L1 为本地网关 127.0.0.1:7890，L2 为住宅 user:pass@res.proxy:8080。请替换为你的真实凭证。

Step 1 — 仅测第一跳（不经住宅）

# 看 L1 出口 IP 与耗时
curl -s -o /dev/null -w "http_code=%{http_code} time=%{time_total}s\n" \
  -x http://127.0.0.1:7890 https://httpbin.org/ip --connect-timeout 15

Step 2 — 仅测第二跳（临时关 VPN，直连住宅）

# 关闭系统 VPN 后执行，隔离 L2
curl -s https://httpbin.org/ip \
  -x http://user:pass@res.proxy:8080 --connect-timeout 15

Step 3 — 组合态（VPN + 住宅，与业务一致）

# 先连 VPN，再指定住宅为上游（Clash 等已路由时可只 -x 住宅）
curl -v -x http://user:pass@res.proxy:8080 https://httpbin.org/headers 2>&1 | \
  grep -iE '^(< |x-forwarded|via|forwarded)'

Step 4 — 对照业务 URL（末跳视角）

# 仅看状态码，快速判断 403 是否来自末跳 IP
curl -s -o /dev/null -w "%{http_code}\n" \
  -x http://user:pass@res.proxy:8080 \
  -A "Mozilla/5.0" https://目标业务域名/登录路径

Step 5 — 本地转发链（curl 不支持多 --proxy 叠跳）

# curl 多次 --proxy 只会覆盖前一跳；多跳须用 gost / proxychains 等在本地合成一个端口
# 例：gost 将 127.0.0.1:7891 → hop1 → hop2 转发后，再：
curl -s https://httpbin.org/ip -x http://127.0.0.1:7891 --connect-timeout 15

记录每步的出口 IP、http_code、time_total、响应头中的 X-Forwarded-For/Via。Step 2 与 Step 3 的 IP 不一致是正常现象（VPN 改变了路由）；若 Step 3 出现 Step 2 不应出现的转发头，即定位到 L1 泄露。

008ip 验收要点

手工 curl 适合研发排查；运营验收建议与 008ip 代理检测 对照，减少漏项：

1. 测「业务入口」凭证：若 Clash 把 VPN+住宅合并为一个本地端口，在 008ip 填你代码里实际用的那一个 -x 地址，不要填中间供应商后台才可见的内网 hop。
2. 分段复测：对采购的两份凭证（如 VPN 出口池 + 住宅池）分别生成报告，再测组合态。对比三次报告的末跳 IP、匿名度、风控分，确认组合后没有评分突变。
3. 链路模式 + 业务 URL：在链路检测中填入真实登录页或 API 域名，而不只测 httpbin。008ip 会标红「本地→代理」「代理→目标」哪一段失败，与上文 curl 记录交叉验证。
4. 匿名度模块逐跳：单跳 Elite、组合变 Anonymous 时，回到故障树分支 C，对每一跳单独跑匿名度检测，截图留存作为换节点依据。

常见问题 FAQ