为什么公网 IP 一样，也不代表网络环境完全一样

很多部署在验收时只做一件事：打开 IP 查询网站，看两台电脑是不是同一个公网 IP。这个检查有价值，但它不能证明两个环境的所有流量都走了同一路径。

先明确你真正要验证什么

更有用的问题不是“IP 一不一样”，而是“我真正要用的应用，有没有经过预期的网络路径”。

浏览器可以遵循 HTTP 代理，但桌面软件可能直接连接；某个工具支持 SOCKS5，但 DNS 仍可能在本地解析；设备同时有 IPv4 和 IPv6 时，两个协议族也可能走不同路径。

NetConfiger 当前能控制的范围

当前版本的 NetConfiger 是显式 HTTP/SOCKS5 分发：Windows 主机已经有可用的网络出口，NetConfiger 在主机上提供代理端口，下游应用把代理地址指向这台主机。

因此它控制的是“明确交给代理的应用流量”，不是自动接管下游设备的全部数据包。这个边界必须写清楚。

一套更可靠的验收顺序

1. 先确认 Windows 主机本身能通过目标出口访问需要的服务。
2. 在下游应用中配置 NetConfiger 的 HTTP 或 SOCKS5 地址和端口。
3. 在这个应用里检查公网 IPv4。
4. 检查这个应用如何做 DNS 解析，不要拿浏览器的结果代替其他软件。
5. 如果环境启用了 IPv6，就单独测试 IPv6，不要默认一律关闭。
6. 如果业务是浏览器并且用到 WebRTC，再检查 WebRTC 候选地址。
7. 暂时取消代理，再测试一次，确认结果确实随代理设置变化。

出现不一致不等于主机坏了

如果浏览器正常而另一个软件不正常，先看这个软件是否真正支持代理、是否自己做 DNS、是否使用 UDP，或者是否直接走 IPv6。不同原因对应不同解决办法。

如果关键应用根本不支持 HTTP/SOCKS5，而需求又是整台设备都必须走统一路径，那就应该使用网关/路由层方案，而不是把显式代理描述成透明网关。

最后把主机地址、协议、端口、应用名称、预期出口和验证结果写进交接记录。这样的记录比一张 IP 查询截图更有用。