你想确认某个自己搭的服务是不是真的能从公网访问。于是登录机器，curl 一下自己的公网地址，返回 200。你松了口气，关掉终端。但这个结论很可能是假的——而且假阳性比假阴性危险得多。
现象
在一台服务器上验证自己某个公网地址是否可达，本地测出来的结果是"可达""正常返回"。但换真实的外网环境去访问，却连不上或者超时。
测试结论和事实完全相反。危险的地方在于：这种假阳性会让你以为暴露面没问题，于是不再检查，直到某天从别处发现端口其实一直敞着。
根因
问题出在"你用了谁去测"。
那台机器自己跑着代理客户端，而代理的分流规则列表里有一条常见的规则："目标是中国 IP 就走直连"。当你从机器上发起请求去访问自己的公网地址时，这条规则命中，请求根本没有出网——它变成了机器自己连自己，也就是所谓的发夹回环（hairpin）。请求在内部绕了一圈就回来了，当然"通"。
换成同网段的内网机器去测，也会有类似的路径问题：它们可能共享同一套分流规则，或者走同一条出口路径，测出来的结果同样不代表外网的真实情况。
解决
正确的姿势是站在"外界"的位置上去测。
一是用代理自带的延迟测试接口。 指定由某个境外节点去访问目标地址，这样请求是真的从境外发出的，测出来的连通性才有意义：
# 示意：让指定节点去请求目标地址
curl -x http://127.0.0.1:7890 "https://example.com"
# 更可靠的是用代理面板的"延迟测试 / 连通性测试"功能
# 选择具体节点，目标填待测地址
二是准备阳性 / 阴性对照组。 选一个你确定公网可达的地址（阳性），再选一个你确定不可达的地址（阴性），分别测一遍。只有两组结果都符合预期，中间那个"待测地址"的结论才可信。这一步是排除"测试工具本身失灵"的标准手段。
三是看往返延迟。 真的出了网，延迟会明显高于内网回环。如果延迟低得可疑（个位数毫秒），基本可以判定请求根本没出去——本地回环的往返时间就是这么短。
四是用完全独立的第三网络。 最干净的验证方式是找一台不在同一网络环境、不共享任何代理规则的机器去测，比如手机蜂窝网络。这是最接近"真实的陌生人访问"的方式。
延伸与预防
这条的推广意义是一句话：测量者不能是被测系统自身的一部分。
任何"外界能否访问我"的验证、任何性能基准测试、任何"用户会不会看到某个东西"的判断，都要保证测量路径和真实访问路径一致。
具体到日常习惯：
- 写测试的时候先问一句"我这个测试是真的经过了用户会走的那条路，还是走了个近道"；
- 验证暴露面时，"内网测内网"的结论一律作废，必须从外部网络发起；
- 如果必须在同一台机器上自测，至少要显式绕过代理（
curl --noproxy '*'）并配合延迟数据来判断，而不是看到一个 200 就下结论。
这套"分组对照 + 看延迟 + 换独立路径"的方法，在排查任何"本地正常、远端异常"的问题时都通用。