关于 地区代理出口检测
地区代理出口检查会通过你提供的某一个代理发起请求，但发起点不是你自己的连接，而是你选定的远端地区。每个地区都会取多个样本，并报告 HTTP 状态码、这些样本的成功率、协商出的协议，以及分阶段耗时拆解，让你看清这个代理对「不在你这个位置」的客户端表现如何。
代理是一条两段式路径，而你从哪里测，会改变其中一段。第一段从客户端到代理，受该客户端的路由、上游中转商，以及运营方施加的地域过滤影响；第二段从代理到目标，几乎不变。只从自己机器上测，测的是你自己的第一段，然后默默假设别人的第一段也长这样 —— 而当另一个大洲的用户反馈同一个代理根本不能用时，崩掉的正是这个假设。
如何使用这个开发者工具
- 填入单个代理，格式与批量检查一致 —— 带协议头的 URL，或 host:port:user:pass。
- 选择代表你关心的那批客户端的地区组；下拉项会列出它覆盖的国家代码。
- 设置一个你有权访问的目标 URL。会回显来源地址的端点信息量最大。
- 运行检查，按流式返回逐条阅读。每个地区上报的是多个样本而不是一个，因此部分成功率本身就是一种结果。
- 横向比较各地区的分阶段耗时：首跳 DNS 与 TCP 描述的是该地区到你代理的这一段，首字节时间描述的是整条链路。
- 某个地区失败时先重跑一次，再与从我们自有网络直连该代理的批量检查结果对照，判断是哪一段出了问题。
实例：同一个代理，从多个地区看过去
这个代理在直连检查中是通过的，但它的可用性在很大程度上取决于客户端在哪里。每个地区取多个样本，才能把真正断掉的路由和一次运气不好的请求区分开。
代理 http://demo:s3cret@203.0.113.9:8080
地区 东亚
目标 https://example.com4/4 个地区已完成 · 3 个可达 · 1 个失败
JP 200 h2 3/3 样本 dns 2 ms · tcp 61 ms · tls 130 ms · ttfb 268 ms
KR 200 h2 3/3 样本 dns 3 ms · tcp 74 ms · tls 151 ms · ttfb 302 ms
SG 200 h2 1/3 样本 dns 2 ms · tcp 88 ms · tls 190 ms · ttfb 1420 ms
HK — — 0/3 样本 FIRST_HOP_CONNECT_FAILED这里有三种截然不同的读数。日本和韩国干净利落。新加坡 3 个样本只成功 1 个，且首字节时间远高于握手耗时，这是代理过载或被限流的典型特征，而不是路由断了。香港则根本没能连上代理，失败出在第一段，和目标没有关系。
读懂地区结果中的分阶段耗时
每个阶段衡量的是这条两段式路径中的不同片段，清楚某个数字属于哪一段，才能把「慢」变成可以动手的线索。
| 阶段 | 衡量的内容 | 数值偏高或失败指向什么 |
|---|---|---|
| 首跳 DNS | 从所选地区解析你代理的主机名 | 该域名在那边解析很慢或解析不出来。改用字面地址可以彻底去掉这一阶段。 |
| 首跳 TCP | 从地区出口向你的代理建立连接 | 第一段的距离与路由质量。这里失败意味着从该地区根本没碰到代理 —— 地域过滤、客户端白名单，或路由问题。 |
| TLS | 经由代理与目标完成握手 | 大致相当于整条链路两个往返的开销。这里失败意味着代理连上了，但安全会话建立不起来。 |
| TTFB | 目标响应的第一个字节回到探测端 | 端到端的总开销。当它远高于 TLS 时，连接本身没问题，是有东西响应慢：可能是目标，也可能是拥塞的代理。 |
| 成功率 | 完成的样本数占尝试数的比例 | 只要不是 0 或 100%，就说明存在间歇性 —— 丢包、池内成员质量不一，或第一次请求之后限流开始生效。 |
常见问题排查
代理在批量检查中通过，从这里的每个地区却都失败。
成因 代理按客户端 IP 授权，而白名单里只有我们批量检查的出口地址；也可能是运营方对允许连接的客户端网络做了地域过滤。
解决办法 测试期间把代理改成凭据认证，或向运营方确认允许哪些客户端地址段接入。直连检查成功、而所有地区都在首跳失败，是白名单机制的强信号。
目标报告的出口地址不在你选择的地区里。
成因 这是设计如此，不是故障。你选择的地区是请求「进入」你代理的位置，也就是第一段；目标看到的是你代理自己的出口，代理从哪里出网就是哪里。
解决办法 如果要让目标看到某个特定国家，那必须由你选择的代理来提供。本工具回答的是另一个问题：那个地区的客户端到底能不能用这个代理，以及用得怎么样。
某个地区返回「区域出口暂时不可用」。
成因 该地区的探测能力在那一刻不可达。这描述的是我们的探测节点，而不是你的代理。
解决办法 稍等片刻重跑，或换一个相邻地区组。当结果指向服务提供方或出口本身、而不是某个连接阶段时，它就不构成关于你代理的证据。
延迟比同一个代理的直连检查高出很多。
成因 你测的是两段链路而不是一段。从东京到法兰克福的代理、再到美国的目标，每一跳的开销都要付，还要在整条链路上完成一次没有会话复用的完整 TLS 协商。
解决办法 在本次运行内部横向比较各地区，再把本次运行与一次直连批量检查对照。两者之差就是第一段的成本。
大多数地区的成功率都是部分成功。
成因 共享型和轮换型代理按连接分配不同上游，很多运营方还会按客户端限流，于是第一个样本成功、后两个被限速。
解决办法 换个空闲时段重跑对比。多次运行都稳定呈现部分成功率，说明这个代理撑不住并发使用，这是一项值得向供应商反馈的容量结论。
适合用这个工具的场景
- 确认某个代理对世界上特定区域的客户端是否可用，而不只是对你所在的位置可用。
- 把第一段问题（客户端地区到代理的路由）与第二段问题（代理到目标）区分开。
- 在把代理交给海外团队之前，先确认他们那一侧确实连得上。
- 对同一地区取多个样本，让间歇性以「部分成功率」的形式暴露出来，而不是变成一次掷硬币。
应该换用别的工具的场景
- 筛选一长串代理列表。代理批量检查一次可接收最多 100 个条目，并为每个条目给出失败阶段。
- 测试与代理无关的网站。站点检查会从多个地区直接请求 URL。
- 验证你自己的浏览器暴露了什么。浏览器泄漏检查会在本地检视 WebRTC 候选和 DNS 解析器，这是任何服务端探测都看不到的。
隐私与数据处理
代理地址、其中包含的凭据、选定地区、目标 URL 以及检查参数，都会发送到本站服务器，以便远端探测节点代你发起请求。这些信息用于本次检查，不会被拼装成用户画像，但会经过服务器常规的请求处理与日志。另有两方会看到其中一部分：你的代理运营方会看到来自所选地区出口地址的连接，目标站点会看到来自你代理出口的请求。请只测试你有权测试的代理与目的地，尽量使用可轮换的凭据，含有用户名或密码的截图请先打码。代理类检查的额度为每个访问 IP 每个 UTC 自然日 500 次，与代理批量检查共用这份额度。
相关开发者工具
常见问题
选择地区会改变我自己的网络连接吗？
不会。你浏览器的网络完全不受影响。地区决定的是远端探测节点从哪里出发去连接你的代理 —— 这是一种从你自己线路之外的位置测试代理的方式。
为什么一个代理在某地区通过、在另一地区失败？
第一段因地区而异：路由、互联关系、中转质量、运营方的地域过滤，以及任何客户端白名单，都取决于连接来自哪里。首跳连接失败是第一段的问题，TLS 或请求阶段的失败则指向第二段。
这能证明代理是匿名的吗？
不能。它报告的是某一时刻、某一条请求路径上、某一个目标返回了什么。匿名性取决于代理添加或去除了哪些请求头、原始客户端地址是否泄漏、目的地能从 TLS 与时序中推断出什么，以及运营方记录了什么。
为什么每个地区要取多个样本？
因为一次请求无法区分「路由坏了」和「这个包运气不好」。对共享代理来说，部分成功率是真实且常见的状态，而想看到它，唯一的办法就是每个地区多试几次。
它和代理批量检查有什么区别？
批量检查从我们自有网络测试多个代理，并精确指出每一个失败在哪一步。本工具则从多个客户端地区测试一个代理，并重复取样。用批量检查判断代理「能不能用」，用本工具判断它「对谁能用」。
地区检查一天能跑多少次？
两个代理类工具共用每个访问 IP 每个 UTC 自然日 500 次的额度，并且这份额度由同一公网地址背后的所有人共用。请有目的地挑选地区组，而不是把所有地区都扫一遍。
可以测试不属于我的代理吗？
只有在获得授权的前提下可以。每次检查都会使用你提供的凭据，向代理运营方的基础设施和目标站点发起真实连接。未经许可测试他人的代理或凭据，属于对这两方服务的滥用。