VPN 是否生效怎么查?出口 IP 与 DNS 泄漏检测教程
教你查出口 IP、检测 DNS 泄漏、按应用逐个验证,并列出「显示已连接其实没走代理」的几种典型情况与排查办法。
VPN 是否生效：先区分连接状态与访问路径
VPN 是否生效，不能只看客户端的连接图标。出口 IP 查询用于判断请求从哪里出去，DNS 泄漏检测用于观察域名解析路径，而目标应用是否正常工作，还需要单独验证。把这些结果放在一起，才能区分正常分流与配置遗漏。
客户端显示已连接，通常说明隧道或代理服务已经启动，不等于所有流量都进入了它。系统代理可能只影响遵循系统设置的软件；TUN 模式通过虚拟网络接口接管匹配的流量，但仍受路由、排除规则和平台权限影响。两种模式都不能仅凭名称判断覆盖范围。
检测前先确定目标：是只让指定国际网站走代理，还是希望设备上的外部访问都进入隧道？规则模式下，本地服务保持直连可能正是预期结果。若把任何直连都当成泄漏，会为了修正并不存在的问题而破坏正常分流。
连接前后对比出口 IP
先在可以安全断开代理的环境记录基线。若当前任务不能承受直连，不要为了测试主动断开；可以先检查客户端日志，待合适时再补充基线。记录时关注完整 IP、网络运营主体与地址类型，不只记页面显示的国家或地区。
- 在断开状态打开IP 查询页，记录浏览器当前的公网出口。如果页面分别提供 IPv4 与 IPv6 结果，分别保存。
- 连接计划使用的线路，确认订阅可用、节点已选中，系统代理或所需的 TUN 模式已经启用。
- 重新加载查询页，避免仅查看旧标签页中的缓存内容。比较连接前后的完整地址，而不是只比较地区名称。
- 打开客户端连接记录，确认查询域名命中了哪条规则、使用哪个出口。若查询页本身被设为直连，它就不能代表代理出口。
- 换一个独立查询来源交叉检查，再进入目标应用验证。不要因为某个站点没有打开，就直接认定线路完全失效。
IP 归属地来自数据库，可能滞后，也可能与线路名称不一致。相同地区不代表相同出口，地区变化也不能说明全部流量都经过代理。更可靠的证据是地址确实改变，并且客户端记录显示该请求走了预期线路。
DNS 泄漏检测：看解析路径，不只看地区
DNS 把域名转换成可连接的地址。应用流量进入代理，并不必然意味着域名查询也进入代理：查询可能由系统发出，也可能由浏览器的安全 DNS、客户端内置解析器或代理服务器处理。所谓泄漏，需要结合原本希望隐藏或控制的解析路径来判断。
可以访问独立检测站点，例如 DNSLeakTest。运行其页面提供的检测，记录返回的解析器运营主体，再与系统、浏览器和客户端的 DNS 设置对照。检测站会接触测试请求，使用前应自行评估其隐私说明。
这类测试通常让浏览器请求专门生成的域名，再观察哪些递归解析器进行了查询。因此，页面展示的主要是测试域名对应的解析器，不是设备上所有应用的完整 DNS 清单。检测结果没有显示本地解析器，也不能推出后台应用不会另走路径。
如果预期所有外部 DNS 都走隧道，却反复看到本地接入网络的解析器，应继续排查。如果看到公共解析服务，也不能只凭它的国家或品牌判断安全与否。浏览器通过加密 DNS 直接访问公共解析器，与通过隧道访问同一解析器，可能显示相似结果，但网络路径不同。
- 检查客户端是否启用 DNS 接管、远程解析或配套的 DNS 路由规则，具体名称以客户端说明为准。
- 检查浏览器安全 DNS 是否使用独立服务。需要统一路径时，应让其设置与客户端方案协调，而不是盲目叠加。
- 修改设置后清理相关 DNS 缓存，或重启受影响的应用，再重新检测，避免沿用已有解析结果。
- 如果客户端使用 Fake-IP，应用可能先获得映射地址，再由客户端处理连接。这不代表应用拿到的地址就是公网出口。
常见结果与下一步排查
把出口、解析器与连接日志放在同一轮测试里看。每次只改一项设置，并保存修改前的结果，才能知道是哪项变化产生了作用。下表是排查方向，不是对单次检测结果的绝对判定。
| 检测现象 | 可能原因 | 下一步 |
|---|---|---|
| 出口 IP 未变化 | 查询站点直连、系统代理未生效，或浏览器另设代理 | 查看该域名的规则命中记录，检查浏览器与系统设置 |
| 浏览器出口变化，目标应用不变 | 应用忽略系统代理，或被单独排除 | 检查应用内代理、进程规则和 TUN 接管范围 |
| 出口变化，但出现本地网络解析器 | DNS 未接管，或存在独立解析路径 | 对照系统 DNS、浏览器安全 DNS 与客户端记录 |
| IPv4 走代理，IPv6 仍是原网络出口 | IPv6 路由或接管策略未覆盖 | 检查客户端的 IPv6 支持与排除策略，分别复测 |
| 出口符合预期，服务仍报地区异常 | 账户地区、会话缓存、IP 分类或服务端限制 | 检查目标服务规则与账户状态，不只重复切换线路 |
延迟检测成功只说明某种探测请求得到了响应，不代表网页、登录接口、图片资源和实时连接都走了同一路径。类似地，能打开主页不代表应用中的所有域名都已匹配规则。需要结合实际失败动作找对应记录。
按应用验证：浏览器、桌面与移动端
Windows 与 macOS：确认谁在使用代理
先检查系统网络代理设置是否与客户端一致，再查看浏览器扩展是否覆盖了系统配置。桌面应用可能使用系统代理，也可能采用独立网络栈。对必须经过代理的软件，执行一次真实操作，例如登录、加载内容或发起请求，同时观察客户端日志。
开发工具和终端尤其需要单独检查。有些程序读取 HTTP_PROXY、HTTPS_PROXY 或 ALL_PROXY，有些需要专门配置，不能假定设置环境变量就能覆盖所有命令。若配置了本地代理端口，应从客户端当前设置复制，不要沿用其他教程中的端口。
iOS 与 Android：确认接管范围
检查系统是否允许当前客户端建立 VPN 连接，以及是否有其他 VPN 配置正在接管网络。Android 客户端可能提供按应用包含或排除规则，应确认目标应用在正确的范围内。iOS 的 VPN 状态标识同样不能替代出口与应用测试，具体路由取决于客户端配置。
Linux：区分桌面设置与进程环境
桌面环境中的代理选项不一定被后台服务、容器或终端工具继承。检查进程实际使用的配置与环境变量；若使用 TUN，还要确认路由与权限设置。容器拥有独立网络环境时，宿主机浏览器的结果不能直接代表容器内请求。
Shadowsocks、VMess、Trojan、VLESS 等代理协议的名称，也不能说明客户端采用哪种系统接管方式。协议决定连接机制的一部分，系统代理、TUN 和分流规则决定哪些请求会被交给它。排查时不要把“换协议”和“扩大接管范围”混为一谈。
IPv6、WebRTC 与断线后的边界
IPv4 检测正常，仍应关注 IPv6。若设备和接入网络支持 IPv6，而客户端没有按预期处理，部分连接可能使用另一条路径。应优先核对客户端的支持情况和路由策略；只有在理解影响后，才考虑临时调整系统设置，修改后还要复测。
WebRTC 用于浏览器实时通信，测试页面可能展示主机、服务器反射或中继候选地址。私有地址或经过隐藏处理的主机候选，并不等于真实公网出口泄漏。若页面发现与预期出口不同的公网地址，再结合浏览器策略、UDP 路径与客户端日志调查。
如果需要确认断线保护，应在不含敏感任务的测试环境中观察：隧道中断后，原本应走代理的请求是失败，还是转为直连。不能仅因设置页出现相关开关就认定保护已经有效；也不要在真实工作会话中贸然断网测试。
IEPL 专线、中转与直连描述的是线路组织方式，并不能替本机完成 DNS 接管或应用分流。换成另一类线路可能改变网络表现，却不会自动修正浏览器独立代理、应用排除或遗漏的 IPv6 路由。
复测清单与结果记录
完成调整后，回到原先失败的应用和操作复测。建议保存连接模式、线路名称、命中的规则、出口查询结果和检测时间。遇到需要协助的问题，可通过帮助中心了解处理入口，或对照使用指南核查客户端配置。
- ✅ 查询请求命中了预期规则，出口地址与目标路径一致。
- ✅ DNS 检测结果能够与系统、浏览器和客户端的解析设置对应。
- ✅ 目标应用完成了真实操作，而不只是客户端显示连接成功。
- ✅ 在适用的网络环境中，分别检查了 IPv4、IPv6 与实时通信路径。
- ✅ 修改设置后重新建立相关连接，避免用旧会话结果判断新配置。
- ✅ 分享截图或日志前，遮盖订阅链接、凭据、令牌与不必要的个人信息。
订阅链接可能包含访问凭据，不应贴进公开检测站或讨论区。排障通常只需要脱敏后的规则命中、错误信息与出口结果，不需要公开整份配置。若无法判断日志中哪些字段敏感，先询问支持人员所需的最小信息范围。