发布于 更新于
代理出现在请求路径中间，往往是出于很普通的工程理由：出口管控、区域测试、缓存，以及让构建机能访问内网。所以测试代理本质上是连通性排查，有用的产出不是「通过 / 失败」这个标签，而是请求停在了哪一段。本文讲怎么用单个端点建立基线、怎么读懂每一种失败形态，以及一次代理测试能证明和不能证明什么。
批量之前先测一个代理
先拿一个端点、一个你自己掌控或明确获准访问的目标开始。把定义它的四件事写下来 —— 协议、主机、端口、认证方式 —— 因为莫名其妙失败最常见的原因，是这四项里有一项填错了，而不是代理坏了。同一个端口上的 HTTP 代理和 SOCKS5 代理行为完全不同，客户端按错误的协议配置时，通常只会报一个语焉不详的错误。
一次成功的请求才能建立基线：它证明协议判断没错、凭据被接受、目标经由这条路径可达。有了它，批量结果才有意义。在还没拿到一次确认成功之前就跑两百条列表，得到的是两百条一模一样的错误和零信息 —— 这是发现自己端口打错的一种很慢的方式。
基线不只要看到，还要量出来。记录连接耗时、首字节时间和状态码。这三个数字给了你比较列表其余部分的基准，也让你能区分「挂了」和「只是被打满了」。四秒才回一次和完全不回，是两种不同的运维问题，而在一个短超时下它们都会显示为「失败」。
# socks5h:// 让「代理」去解析域名。
# socks5:// 在本地解析后把地址发过去 ——
# 光这一个区别就能解释很多「curl 能通、应用不行」。
$ curl -sS -o /dev/null \
--proxy socks5h://198.51.100.20:1080 \
-w 'connect %{time_connect}\nttfb %{time_starttransfer}\nstatus %{http_code}\n' \
https://www.example.com/
connect 0.186
ttfb 0.944
status 200
# 带认证的 HTTP 代理 —— 不要把凭据写进命令行，
# 也不要留在 shell 历史里：
$ curl -sS --proxy http://198.51.100.21:8080 \
--proxy-user "$(cat ~/.config/proxy-user)" \
-o /dev/null -w '%{http_code}\n' https://www.example.com/
200判断失败发生在哪一段
带代理的请求比直连多几段，而每一段失败时都有可辨认的特征。判断对了段，诊断就完成了大半，因为它直接告诉你问题是你的、代理的，还是目标的。407 是你的凭据；代理返回的 502 是目标或更远处的路径；connection refused 两者都不是，是端点本身。
最容易让人栽跟头的，是分不清「代理自己产生的错误」和「代理转发过来的错误」。两者都以 HTTP 响应的形式到达。代理自身的错误通常带着代理的 Server 头、且没有来自目标的内容；转发过来的错误则带着目标的响应头和响应体。拿不准时，把同一个 URL 不走代理再取一次，对比两份响应即可。
从上往下找到匹配的症状。匹配行以上的每一段，都已经成功了。
| 阶段 | 典型错误 | 最可能的原因 |
|---|---|---|
| 连接到代理的 TCP | connection refused 或连接超时 | 主机或端口写错、端点不在线，或者你自己的出口防火墙挡了这个端口 |
| 协议握手 | SOCKS 通用失败、HTTP 400，或一堆无法解析的字节 | 端点讲的协议和你配置的不一样 —— HTTP CONNECT、SOCKS4 与 SOCKS5 互不通用 |
| 认证 | HTTP 407、SOCKS 认证被拒，或连接被立即关闭 | 用户名或密码错误；或者服务商按源 IP 授权，而你的地址不在白名单里 |
| 上游域名解析 | 502 并提示找不到主机 | 代理解析不了这个名字；或者客户端在本地解析后发了一个代理不接受的地址 |
| 上游连接与 TLS | 502、504、TLS 告警，或证书名称不匹配 | 目标拒绝这个出口地址、上游太慢，或者路径上有东西在终结 TLS |
| 目标响应 | 任意状态码，包括 200 | 代理已经完成了它的工作，这个状态码归目标所有，不归代理 |
解读代理返回的响应
把 HTTP 状态码、响应时间、失败阶段和观察到的出口地址放在一起看，而不是一项项孤立地看。一次成功的连接，证明的是这一次请求、在这一个时刻、经这条路径完成了。它既不描述当前浏览器或应用使用的全部网络路径，也预测不了一小时后服务商的地址池轮换之后同一个代理会怎么表现。
读状态码时要分清它来自谁。经代理返回的 403，几乎总是目标在拒绝那个出口地址，而不是代理在拒绝你 —— 同一个 URL 直连通常会返回 200，这正是确认的方法。经代理返回的 429，意味着目标在对那个出口地址限流，而这个地址是与所有使用者共享的。由代理自己发出的 502 或 504，说明它没能完成上游请求，耗时能告诉你是哪一种：很快的 502 是被拒绝，很慢的 504 是超时。
非透明代理经常会添加或改写请求头。Via、X-Forwarded-For 链或 Forwarded 头对目标是可见的，并可能改变目标对这次请求的处理方式。如果你要验证目标看到的东西是否符合预期，就去请求一个你自己掌控的回显接口，原样读取实际到达的内容，而不是假设代理是隐形的。
边界要说明白：代理检查测量的是一次请求的可达性、延迟和出口地址。它不是匿名性评估，也不该被当成匿名性评估来读。账号会话、Cookie、TLS 与浏览器指纹、应用层标识，以及被测客户端之外的流量，都不在任何连通性检查的观察范围内。要看浏览器层面的 WebRTC、IPv4 / IPv6 和 DNS 解析器信号，请在同一台设备、同一张网络上运行 Browser Leak Check —— 把两项检查并排放，才能把代理可用性和浏览器的路由行为区分开。
对比区域出口
区域出口有一个具体而正当的用途：确认按地理位置路由的系统行为是否正确。CDN 有没有命中就近的边缘节点？区域部署返回的货币、语言和法律声明对不对？对延迟敏感的接口，是不是真的由你付费的那个区域提供服务？回答这些问题必须从别的地方发起请求，而跨出口对比结果正是回答的方式。
对比时要预料到「标称区域」和「观测区域」有时对不上，并且要谨慎判断哪一个才是错的。服务商是按自己的库存记录给出口贴标签；地理位置数据库是靠推断给它贴标签。两者都可能过期。值得据此行动的信号，是同一家服务商的大量出口出现系统性的不一致，或者这个不一致恰好和你正在测的事情相关 —— 比如一个号称在欧洲的出口，稳定地收到面向另一个区域的内容。
把结果按出口区域分组，再在每组内部比较成功率、延迟分布和失败阶段。分组能让平铺列表掩盖的模式浮现出来：某个区域统一在 TLS 阶段失败、其他区域都正常，说明那条路径上有具体问题；整个区域延迟一致偏高，通常意味着流量在出口之前被回传到了很远的地方。不稳定的条目换个时段重跑，因为服务商负载和目标的限流策略都会随时间变化。
妥善处理凭据与授权
代理凭据是机密，应当按对待其他任何机密的标准来处理。不要写进命令行 —— 那会留在 shell 历史里，也会出现在同机其他用户可见的进程列表中；不要写进工单、截图和聊天记录。把它们放进权限受限的文件或密钥管理系统，并在测试清单被传阅之后轮换。如果服务商支持按源 IP 授权而不是密码，那通常更安全，因为不存在可泄漏的共享秘密。
关于测试本身，规则很简单，值得明说：只测试你拥有或已获授权使用的代理，只针对你拥有或获准访问的目标。未经许可借道他人的基础设施做连通性测试，是对他人资源的未授权使用；把批量任务指向第三方目标，则是在给一个从未同意的服务施加负载。请遵守公开的速率限制和服务条款，并如实标识你自己的工具。
本站的 Proxy Check 对每个访问 IP 每个 UTC 自然日限 500 次。一份 500 条的列表跑一遍就会把额度用光，所以先去重、先剔除已知失效的条目，并在花掉它之前想清楚你到底要测什么。计数以 X-Forwarded-For 中上报的访问地址为键，也就是说共享出口的办公室里，所有人共用同一份额度。
- 在确认自己获准之前，不要把生产环境的代理凭据粘贴进任何工具，包括本站。
- 分享结果前先抹掉代理 URL 里的 userinfo 部分 —— user:pass@host 就是一个写在 URL 里的密码。
- 给测试过的端点留一份带日期的记录和测试理由；一份没有日期的代理地址清单，事后既难以说明用途，也容易被滥用。
要点回顾
- 跑列表之前先把一个端点端到端验通，并记录连接耗时、首字节时间和状态码作为基线。
- 按分段诊断：connection refused 是端点问题，407 是你的凭据，代理自己发出的 502 / 504 是上游，任何来自目标的状态码都说明代理这一段已经跑通。
- 经代理返回的 403 或 429，通常是目标在针对那个出口地址做反应 —— 把同一个 URL 直连取一次即可确认。
- 代理检查测量的是一次请求的可达性、延迟和出口地址；它不是匿名性评估，也看不到 Cookie、会话和指纹。
- 只测试你有权使用的代理和目标，凭据不要出现在命令行和工单里；Proxy Check 每个访问 IP 每个 UTC 日 500 次。