关于 批量代理可用性检测
代理批量检查会接收最多 100 个 HTTP、HTTPS 或 SOCKS5 代理，逐个经由它们连接你指定的目标 URL，并报告每个阶段发生了什么：代理是否接受了 TCP 连接、认证是否通过、隧道是否建立、TLS 是否校验通过，以及目标返回了什么状态码。可用与不可用的条目可以分别复制成两份列表。
端口上有应答的代理，不等于能用的代理。从第一个报文到拿回可用响应之间，有五六件彼此独立、都可能出错的事，而从外面看它们几乎一模一样：连接一直挂着、密码不对、服务端并不支持你以为的握手、代理解析不了目标域名、目标拒绝了这个出口地址。手动逐个试，只会把这些压缩成「能用 / 不能用」，完全看不出是凭据过期、供应商挂了，还是目的地屏蔽了这段地址。检查停在哪个阶段，是结果里最有价值的字段。
如何使用这个开发者工具
- 每行粘贴一个代理。带协议头的 URL 形式（http://user:pass@host:port、socks5://host:port）和冒号分隔形式（host:port:user:pass）都接受，完全相同的条目会去重。
- 把测试目标设为你有权访问、且返回内容短小可预期的地址。trace 或回显 IP 的端点最合适，因为它还能显示请求是从哪个出口到达的。
- 开始批量检查。同时只跑 5 条，既让结果有序呈现，也避免对代理造成冲击。
- 先读每一行的摘要 —— 已连接、认证状态、HTTP 状态码 —— 只对失败的行展开详情。
- 在详情里直奔失败阶段和失败跳点：这两个字段指明该修哪一层，下面的详情是上游自己给出的说明。
- 把成功列表复制进配置，把失败列表留着稍后重试，因为代理可用性经常只是暂时性的状态。
实例：三个代理，三种结局
一份从供应商后台复制下来的典型列表。一条可用、一条凭据已过期、一条根本没有监听 —— 每种失败都会指出它走到了哪个阶段。
http://demo:s3cret@203.0.113.9:8080
socks5://198.51.100.20:1080
192.0.2.77:3128:demo:s3cret203.0.113.9:8080 — 成功
已连接 · 认证成功 · HTTP 200
代理协议 http_connect
目标地址 https://example.com
响应耗时 412 ms
目标 IP 203.0.113.9 · IPv4
TCP 已连接 是 隧道已建立 是 TLS 已验证 是
198.51.100.20:1080 — 成功
已连接 · 无需认证 · HTTP 200
代理协议 socks5
响应耗时 780 ms
192.0.2.77:3128 — 失败
失败代码 PROXY_CHECK_FAILED
失败阶段 代理认证
失败跳点 192.0.2.77:3128
详情 proxy returned 407 Proxy Authentication Required第三条才是最有意思的。TCP 已经连上、代理也作出了应答，说明主机和端口都对、服务也活着 —— 错的只是凭据，或者凭据已过期。如果它是在首跳 TCP 阶段失败，要检查的就变成主机和端口了。表面症状一样，修法完全不同。
失败阶段及其指向的问题
先读阶段再读错误信息，能把一份「都是死代理」的列表，变成一份具体且可修的问题清单。
| 阶段 | 当时在做什么 | 在这里失败意味着什么 |
|---|---|---|
| validation | 解析你粘贴的那一行 | 地址根本没离开工具：协议写错、缺端口，或有密码却没有用户名。没有联系过任何主机。 |
| first_hop_dns | 解析代理自身的主机名 | 代理写成了解析不出来的域名。请改用字面地址或修好解析记录 —— 代理本身还没被接触到。 |
| first_hop_tcp | 向代理发起 TCP 连接 | 端口上没有监听、防火墙丢弃了连接，或端口写错了。当供应商按客户端 IP 白名单授权、而我们的地址不在白名单上时，看到的也是这一步。 |
| proxy_auth | 向代理进行认证 | 服务活着并且拒绝了凭据 —— HTTP 407，或 SOCKS5 认证被拒。主机和端口没问题，用户名或密码有问题。 |
| proxy_chain | 在多跳链路中逐跳协商 | 中间某一跳失败了。失败跳点字段会指出是哪一跳，可以把它单独拎出来测。 |
| target_connect | 经由代理抵达目标 | 代理接受了你，却到不了目的地：解析不了目标域名、目标端口被封，或代理出口侧有目的地过滤策略。 |
| request | 发送请求并读取响应 | 隧道是通的，与目标的交互失败了 —— TLS 问题、响应被截断，或目标主动断开了连接。 |
常见问题排查
代理在你浏览器里能用，这里却在首跳 TCP 阶段失败。
成因 多数商用代理按客户端 IP 授权。你的机器在供应商白名单里，本站服务器不在，于是连接在进入认证之前就被拒绝了。
解决办法 测试期间把该代理改成用户名密码认证，或者从白名单内的机器上测。按 IP 授权的代理，本质上无法由远端服务代为检查。
整份列表全部卡在 validation 阶段。
成因 列表格式解析器不认识 —— 从 JSON 里复制出来带着引号和尾随逗号、使用了不支持的 socks4 之类协议，或四个冒号字段的顺序不符合预期。
解决办法 先把列表规范化。代理格式化工具可以在常见排列之间互转；支持的协议是 http、https、socks5 和 socks5h，冒号形式要求写成 host:port:user:pass。
代理连上并通过了认证，目标却返回 403。
成因 目的地在屏蔽这个代理的出口地址。机房地址段和已知代理池会被机器人防护打上很低的分，而屏蔽发生在连接成功之后。
解决办法 这是「代理没问题、目标不配合」的组合。换一个中立目标（例如回显 IP 的端点）重测，确认代理本身可用，再判断这类出口是否根本进不去那个目的地。
同一个代理，几次运行结果时好时坏。
成因 轮换型和住宅型代理池按连接重新分配上游出口，相邻两次检查走的可能是完全不同的路径。共享代理在高负载时还会排队。
解决办法 把列表跑两三遍，保留稳定通过的条目。对轮换池来说，单次通过只描述了某一时刻的某个出口，而不是整个池子。
批量还没跑完就停了。
成因 每个访问 IP 每个 UTC 自然日 500 次的额度已经用完，而这份额度由同一公网地址背后的所有人共用。
解决办法 把大列表分到几天跑，或先在本地筛掉明显已死的条目。复制失败列表，这样重试时只在仍需要答案的条目上消耗额度。
适合用这个工具的场景
- 把刚拿到的代理列表，筛成真正能连上并通过认证的那一部分。
- 判断一个失效代理是凭据不对、主机已死，还是被目的地屏蔽了。
- 在把生产流量切过去之前，确认某个代理确实能访问特定目标。
- 在供应商轮换或凭据变更之后，重新校验一份保存已久的列表。
应该换用别的工具的场景
- 从世界上某个特定位置测试代理。地区代理出口检查会从你选定的地区发起同样的请求，并取多个样本。
- 检查自己的浏览器是否绕过了代理。浏览器泄漏检查会在本地检视 WebRTC 候选和 DNS 解析器，这是服务端检查看不到的。
- 测量网站可用性。站点检查会从多个地区直接请求 URL，链路中不经过代理。
隐私与数据处理
代理地址、其中包含的用户名与密码、目标 URL 以及检查参数，都会发送到本站服务器，因为连接必须由一台真正能访问该代理的机器发起。这些信息用于执行你请求的检查，不会被拼装成用户画像，但会经过服务器常规的请求处理与日志，而目标站点会看到请求从你代理的出口地址到达。请把你粘贴的每一条凭据都视为已向本服务披露：只测试你有权测试的代理，尽量使用可随时轮换的凭据，并注意结果详情会把你填入的用户名和密码显示出来，分享截图前请先打码。该检查额度为每个访问 IP 每个 UTC 自然日 500 次。
相关开发者工具
常见问题
端口开着就说明代理能用吗？
不能，阶段字段的存在正是为了纠正这个假设。一个端口可以先接受 TCP，然后拒绝你的凭据、握手失败、拒绝解析目的地，或者根本到不了目标。只有拿到目标状态码的完整请求，才能证明整条链路可用。
一次能测多少个代理？
单批最多 100 个不重复条目，以 5 路并发检查；额度为每个访问 IP 每个 UTC 自然日 500 次。完全相同的条目会在运行前去重，所以带重复项的列表实际消耗会低于行数。
检查通过是否证明这个代理是匿名的？
不能。它只证明连接完成了、目标作出了应答。匿名性取决于代理添加或剥离了哪些请求头、是否泄漏原始客户端地址、目的地能从 TLS 和时序中推断出什么，以及运营方记录了什么 —— 一次成功的请求无法确立其中任何一项。
我的代理凭据会被保存吗？
凭据会发送到本站服务器（连接就是在那里发起的），用于本次检查，不会被拼装成画像。它们确实会经过常规的请求处理与日志，而且结果详情会把它们回显在屏幕上。请使用可随时轮换的凭据，分享截图前先打码。
支持哪些代理格式？
带协议头的 URL 形式 —— http、https、socks5 或 socks5h —— 可选携带凭据；以及冒号分隔的 host:port:user:pass 形式。省略端口时，http 默认 80、https 默认 443、SOCKS5 默认 1080。
为什么检查显示的出口地址和供应商列出的不一样？
代理池会轮换，而且供应商公布的经常是入口地址而非出口地址。这里显示的是目标连接实际使用的地址。如果它长期落在你购买的地址范围之外，这件事值得和供应商确认。
可以测试任意代理和任意目标吗？
只能测试你有权使用的基础设施和目的地。不要测试不属于你的凭据，不要用它来绕过访问控制，并且要同时尊重代理供应商和目标站点的频率限制 —— 每一次检查都是对别人服务器的真实请求。