VPN怎么确认生效?出口IP与DNS检测新手完整指南

连接状态与实际流量的区别

先分清「连上了什么」。有些客户端启用系统代理，主要接管遵循系统代理设置的程序；有些使用虚拟网卡或系统 VPN 接口，通过路由规则接管流量。客户端界面相似，覆盖范围却可能不同。浏览器能走线路，不能证明游戏、终端或其他应用也走同一出口。

分流模式会进一步改变结果。某些域名被设为直连，另一些走代理；按应用分流时，只有指定程序进入隧道。检测页面如果命中直连规则，看到原来的 IP 可能是预期行为，而不是连接失败。检查前先记下当前模式和检测域名的规则。

判断标准应与配置一致：全局接管时检查接管范围；分流使用时检查目标应用是否命中预期规则。不能要求所有分流请求都显示同一个出口。

出口 IP：连接前后如何对照

出口 IP 是检测网站收到请求时看到的源地址。家庭路由器给设备分配的局域网地址，不是这里要检查的公网出口。浏览器地址栏旁的连接安全标记也只说明网站连接使用了 HTTPS，不能证明请求经过 VPN。

1. 断开客户端连接，打开本站的IP 检测页面，记录公网 IP、所属网络和显示地区。若页面分别展示 IPv4 与 IPv6，也分别记录。
2. 连接所选线路，确认接管模式，重新加载检测页面。避免只看仍停留在屏幕上的旧结果。
3. 比较地址是否变化，并核对所属网络信息。地区数据库可能更新滞后，城市名称不一致不能直接认定线路无效。
4. 换一个独立的检测来源复核。如果结果不同，检查是否分别命中不同分流规则，或分别使用了不同地址族。
5. 断开连接后再次检测，观察是否回到原先出口。保留前后记录，方便复现问题。

如果地址没有变化，先确认检测请求是否应当走代理。若日志显示直连，就应检查规则；若日志显示代理而结果仍不符合预期，再检查浏览器自带代理、扩展、旧连接以及客户端错误信息。不要仅凭「地区没变」就反复更换线路。

IPv4 出口改变而 IPv6 仍显示本地网络，需要单独核对 IPv6 路由。客户端可能仅接管了部分地址族，也可能按规则让它直连。优先查看客户端的 IPv6 支持与接管说明，再决定是否调整配置，不要把关闭 IPv6 当成所有场景的固定答案。

DNS 检测：解析器不同不等于泄漏

DNS 用来把域名解析成网络地址。DNS 检测通常让浏览器请求测试域名，再根据服务端观察推测参与解析的递归解析器。它看到的是解析链路的线索，并不是设备上所有程序的完整 DNS 记录。

所谓 DNS 泄漏，是本来希望经过指定路径的解析请求，实际经由其他路径发出。是否构成问题，取决于预期配置。浏览器使用独立的加密 DNS 时，显示另一家解析服务可能符合设置；而该加密 DNS 连接本身也可能经过代理。只看解析器品牌或国别，无法判定传输路径。

• 先检查客户端 DNS 配置，确认是否要求远端解析、是否为直连域名单独选择解析器。
• 查看浏览器的安全 DNS 设置，它可能覆盖系统解析行为。将其与客户端策略一起核对，而不是只改系统 DNS 地址。
• 保持网络不变，对照断开与连接时的检测结果。连接后仍出现本地网络提供的解析器，是值得排查的线索，但需要日志与配置佐证。
• 使用新的测试域名或重新发起检测。已有缓存可能使请求不再触发解析，导致结果缺项或看起来没有变化。

加密 DNS 保护的是设备到解析服务之间的查询传输，并不自动改变网页访问的出口。相反，网页流量走代理，也不自动保证所有 DNS 请求都走代理。需要把「域名由谁解析」和「连接从哪里出去」分开验证。

分应用验证：浏览器之外也要检查

浏览器检测只代表浏览器那次请求。要确认日常工具是否生效，应使用实际目标应用发起新的联网操作，并同时观察客户端的连接列表或日志。若客户端提供规则名称和出站标签，核对该请求究竟显示直连还是所选代理线路。

桌面系统上，Windows 与 macOS 的系统代理并不会让所有软件自动遵循设置。终端程序可能读取代理环境变量，也可能完全忽略它们；Linux 上的桌面代理设置同样不是所有进程的统一入口。虚拟网卡模式通常覆盖更多 IP 流量，但仍受路由、排除项和客户端能力影响。

iOS 与 Android 客户端可能通过系统 VPN 接口接管流量，具体范围仍需看配置。Android 客户端可能提供按应用包含或排除的选项；不要把某个平台的操作步骤直接套到另一个平台。若应用已有持续连接，调整线路后应让它重新建立连接再测。

• ✅ 打开需要使用的应用，执行实际联网操作，而不是只观察缓存页面。
• ✅ 在客户端日志中找到对应请求，核对域名、规则和出站线路。
• ✅ 检查应用专属代理、浏览器扩展与系统代理是否互相覆盖。
• ✅ 切换模式后重建应用连接，并在同一网络下重复验证。
• ❌ 不把某个网站能打开，当成全部设备和应用都已接管的证据。

有些应用不会公开显示自己的出口 IP。此时应结合连接日志、规则命中和功能表现判断，并明确结论范围。目标网站拒绝访问也可能来自账号状态、地区政策或出口信誉，不一定是本地连接没有生效。

「已连接却没走线路」的排查顺序

排查时先找流量有没有进入客户端，再找它被送到哪里。这个顺序比不停刷新订阅或更换节点更容易定位问题。每次只改一项，重新发起请求后记录变化；恢复配置时也有明确依据。

1. 确认配置已被选用。导入订阅链接只是获得配置，不代表已经选中节点并启用接管。检查当前配置、所选线路和连接错误。订阅链接含有访问凭据，不要贴进公开截图或讨论区。
2. 确认系统入口。系统代理模式下检查代理是否启用；虚拟网卡模式下查看权限与路由状态。其他网络工具可能改写这些设置，测试时避免让多个工具争用接管入口。
3. 确认规则命中。若目标域名走直连，检查规则顺序、按应用排除项和默认出站。临时调整模式可以帮助定位，但不是让全部业务长期走同一路径的理由。
4. 确认解析成功。日志出现解析失败时，先检查 DNS 路径。出口 IP 检测正常，不代表目标域名的解析一定正常。
5. 确认出站可用。请求已经进入代理却发生连接错误，再检查节点、网络与客户端兼容性。仅凭错误提示无法断定线路拓扑或服务端故障。
6. 复查完整证据。调整后重新检测出口、DNS 和目标应用。不要因为其中一项恢复，就忽略另一项仍然异常。

协议名称本身不是验证结果。Shadowsocks、VMess、Trojan、VLESS 等配置能否被接管并正常使用，还取决于客户端支持、传输设置和服务端配置。线路标注直连、中转或专线，也不能替代终端出口检测，更不能由 IP 地区标签反推出具体线路拓扑。

浏览器 IP 暴露与检测结果的边界

一些检测工具还会展示 WebRTC 地址。WebRTC 用于实时通信，其连接路径可能与普通网页请求不同。局域网地址、经隐私处理的本地地址和公网地址需要区分；看到本地地址信息，不等于已经证明公网出口绕过线路。

如果检测出现不符合预期的公网地址，应核对浏览器策略、客户端对相关流量的支持和路由设置。不要依靠安装大量扩展来叠加修复，扩展可能只影响浏览器，也可能与现有代理设置冲突。修改后仍要用真实应用重新验证。

这些检测只能反映测试时的路径，不是永久状态证明。更换网络、更新客户端、调整规则或重新导入配置后，值得重新检查。地址改变也不是隐私保证：登录账号、网站 Cookie 与应用权限仍然可以提供身份线索。