我不是小布丁
@xiaobuding
一篇关于网络出口自查的实测记录，价值一半在方法、一半在它对"结论"的克制。作者让编码 agent 给电脑做了一次网络体检，全程只查不改：浏览器出口、网页指纹、WebRTC 公网地址、DNS 探测服务器逐项对齐——都落在预期的代理出口上，只有 IPv6 一直超时。
接下来的处理最见功力。换三个公网 IPv6 目标全部超时、IPv4 正常走代理，可以下的结论是"这套配置下公网 IPv6 不通"；故障点尚未定位，就没有把它写成"防泄露检测通过"。两句话之间的距离，正是多数教程翻车的地方——把"没测到问题"当成"测过了没问题"，把一次环境的正常当成配置的正确。验证的价值取决于它承认了多少边界，超边界的结论比没有结论更危险。
记录还顺手纠了三处常见误判。第一，浏览器和终端显示不同 IP，只能说明两次请求的出口不同——分流规则、多代理、出口轮换都会造成差异，看到不一致应当继续追路径，不能直接断定终端裸连。
第二，普通命令行工具的连通测试替代不了真正的客户端，何况教程里一边设置代理变量、一边用没带协议头的地址去测，两步压根没测到同一份配置。第三，客户端对 SOCKS 代理的支持有明确边界，照教程硬配只会配了个寂寞。
这类自查在今天格外有意义，是因为环境本身比教程里复杂得多。代理分流、多出口轮换、客户端各自的连接策略，让"我在哪个出口"成了一个需要动态核对而不是一次配置完就永久有效的状态；教程写得再细，也追不上配置组合的变化速度。真正可迁移的不是某个教程的具体操作，而是这记录里展示的验证习惯——每一步都确认测的是哪一层、每个结论都带上它的适用范围。
把这次自查整理成可复用的顺序，大致四步：先测浏览器出口与网页指纹，再看实时通道与 DNS 是否与之一致，然后用多个目标交叉验证异常项，最后写结论——每个结论都标注它覆盖了什么、没覆盖什么。对经常需要核对网络环境的人，最后这步最值钱：一份写明边界的报告，比一句"一切正常"有用得多，后者只适合写在祈祷里。
