VPN是否生效怎么查？先对照连接前后的出口 IP，再检查 DNS 请求的去向，最后验证实际使用的应用。客户端的“已连接”只是起点：它通常说明会话已经建立，不能单独证明浏览器、桌面软件和后台服务都使用了预期线路。
检查前先明确目标：是仅让指定网站走国际线路，还是希望设备的大部分流量进入隧道？分流模式下，部分请求保持本地直连是正常行为。只有把预期路径写清楚，后面的检测才有判断依据，也不会把正确的分流误认成连接失败。
先分清连接状态与实际路径
日常统称的 VPN 客户端，实际可能使用系统隧道，也可能通过本地代理转发流量。系统代理通常只影响愿意遵循该设置的应用；TUN 模式通过虚拟网络接口接管匹配的流量，但仍受到路由、排除项和系统权限影响。按钮颜色相同，并不代表覆盖范围相同。
Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUIC 等协议名称，也不能直接回答“哪些应用已生效”。协议负责连接和传输的不同环节，应用是否进入该连接，仍要看客户端的接管模式与规则。订阅导入成功只代表配置可读取，不能代替实际访问验证。
| 检查项目 | 可以确认 | 不能单独确认 |
|---|---|---|
| 客户端显示已连接 | 客户端报告会话已建立 | 全部应用都已进入线路 |
| 网页出口 IP 改变 | 该次网页请求使用了不同出口 | 其他应用与 DNS 的路径 |
| DNS 检测出现解析器 | 测试查询由这些解析服务处理 | 查询到解析器之间的完整传输路径 |
| 目标应用正常访问 | 应用当前访问功能可用 | 其全部后台连接均符合预期 |
用出口 IP 做前后对照
出口 IP 是网站看到的请求来源地址，不等于设备在局域网里的地址。开始时先断开客户端，打开IP 检测页，记录公网地址、网络归属及检测时间。随后连接目标线路，在同一浏览器重新检测，避免同时更换浏览器、网络和节点，导致结果无法比较。
- 在未连接状态记录基线。若设备还有其他代理、浏览器扩展或企业网络隧道，应先了解它们是否仍在接管流量。
- 连接目标线路，确认客户端当前使用的节点与分流模式，不要只看首页的状态提示。
- 重新加载检测页，必要时关闭旧标签后再打开，减少缓存、旧连接或页面未刷新造成的误判。
- 对比完整公网地址及网络归属，并检查该检测网站在客户端规则中实际命中了直连还是代理。
- 断开后再次检测，观察是否恢复基线路径。这个往返过程比单独看到一个境外地址更有解释力。
如果 IP 不变，先别急着换协议。检测站可能被分流规则指定为直连，也可能浏览器没有遵循系统代理。可以暂时使用覆盖范围更明确的测试模式，再验证同一个页面；测试结束后恢复原来的分流设置。切换模式是排查手段，不是长期必须采用的配置。
IP 归属地数据库可能存在更新滞后，线路标注地区也不一定与数据库城市完全一致。优先比较公网地址和网络归属是否改变，不要仅凭城市名称判定连接失效。
DNS检查看去向，不只看地区
DNS 用来把域名解析成可连接的地址。出口 IP 已改变，但域名查询仍通过不符合预期的路径发送，这种情况需要继续检查。常见原因包括系统保留原网络的解析配置、客户端未接管 DNS，以及浏览器单独启用了加密 DNS。
使用会发起新域名查询的 DNS 检测工具，分别记录连接前后显示的解析器归属。普通网页能打开，不代表 DNS 经过隧道；浏览器可能使用缓存，根本没有发起新查询。反过来，检测到本地地区的解析器，也不能直接证明发生泄漏，公共解析服务可能使用就近节点，归属信息也可能不准确。
更可靠的判断方式，是把检测结果与配置对照：客户端预期使用哪个解析服务、是否通过代理访问它、哪些域名允许本地解析。浏览器的安全 DNS 或系统的加密 DNS 可以改变解析路径，但“加密”与“经过所选线路”是不同问题，不能互相替代。
怀疑泄漏时，先查看客户端的 DNS 接管与防泄漏选项，再检查浏览器是否覆盖系统设置。每次只调整一个相关选项，并用新的检测查询复测。不要把清空缓存当成修复方案：它只能移除旧结果，无法改变下一次请求的路由。
判断结论：DNS 泄漏应以“查询是否绕过预期通道”为依据。仅凭检测页面上的国家、解析器数量或一个醒目的警告标签，无法还原完整路径；证据不足时，应标记为待核验，而不是宣布隐私保护已经失效。
浏览器通过后，继续按应用验证
浏览器检测通过，只能说明该浏览器的相关请求符合预期。桌面应用可能使用自己的网络库，忽略系统代理；某些游戏、语音或会议应用还需要客户端具备对应的 UDP 转发能力。网页能打开而应用连接失败，通常需要检查应用路径，不应直接推断节点完全不可用。
在 Windows 和 macOS 上，先区分系统代理与隧道接管，再检查目标应用是否有独立代理设置。移动端要看系统的 VPN 权限、按应用排除项及后台运行状态。Linux 的桌面代理配置与命令行环境也可能不同，终端中的访问结果不能自动代表图形应用。
- ✅ 打开实际要用的应用，执行需要联网的操作，而不是只看本地首页或已缓存的内容。
- ✅ 查看客户端连接记录，确认目标域名或进程命中了预期规则；日志功能以所用客户端实际支持为准。
- ✅ 对照应用的独立代理、排除列表和分流设置，确认没有同时启用互相冲突的接管方式。
- ✅ 在断开、连接与切换网络后分别复核关键操作，观察结果是否跟随线路变化。
- ❌ 不用一个浏览器的出口结果，替所有应用、后台服务和其他设备作结论。
能够访问目标服务，也不等于服务地区已经改变。账号地区、付款资料、定位授权、缓存及服务自身的风控都可能影响页面内容。验证网络路径时，应先看出口与连接记录，再讨论服务显示的地区，避免把应用策略问题当成线路问题。
双栈与 WebRTC 的补充检查
设备可能同时具备 IPv4 和 IPv6 连接能力。如果客户端仅接管其中一类地址，部分应用可能选择另一条可用路径。因此，检测工具支持时，应分别查看两类公网出口；没有检测到某类地址，只能说明当前测试未取得该连接，不能据此保证所有场景都已覆盖。
发现某类地址仍走原网络时，优先查阅客户端对该地址族的接管说明及系统路由设置。是否需要调整系统配置，应结合实际网络和客户端能力决定，不要为追求检测页“全绿”盲目关闭系统功能。修改后还要确认日常应用没有因此失去连接。
WebRTC 用于浏览器实时通信，相关检测可能展示候选连接地址。私有局域网地址、经过隐藏处理的本地标识与公网出口不能混为一谈。若出现原网络的公网地址，需要结合浏览器策略和实际候选连接进一步核验；单凭出现了一个地址字段，不足以说明网页已经绕过隧道传输所有内容。
看似连上却未生效，按层排查
配置层：检查当前选中的是否为刚导入的配置，订阅是否已按客户端要求更新，以及所选节点是否仍包含在有效配置中。不要反复导入同一订阅制造多个相似配置；先确认正在运行哪一个，再检查连接错误提示。
接管层：检查系统权限、代理开关、TUN 状态及其他网络工具。多个代理客户端、浏览器代理扩展或企业隧道可能争用设置。排查时保留一个明确的接管入口，逐项恢复其他工具，才能定位冲突来源。
规则层：查看检测站与目标应用分别命中了什么规则。规则顺序、域名匹配和进程排除都可能导致不同结果；如果临时测试模式有效而日常模式无效，应优先查分流，而不是继续更换线路。
网络层：公共网络可能需要先完成门户认证，网络切换也可能让旧会话失效。先确认本地网络能正常访问，再重新建立连接。IEPL 专线、中转和直连描述的是线路路径与组织方式，不能替代终端的权限、DNS 或路由检查。
订阅链接可能包含访问凭据。求助时不要公开完整链接、密码或未经处理的日志；保留系统、客户端、模式、操作与错误提示，遮盖凭据及不必要的网络地址后再提交。
保留复测记录，再下结论
一份有用的检查记录不需要复杂工具。写下系统与客户端、当前网络、节点、接管模式、连接前后出口、DNS 解析器归属，以及目标应用的实际结果即可。睡眠唤醒、网络切换或更新规则后出现异常时，用同样流程复测，比凭印象判断“今天变慢了”更容易定位原因。
也要区分“未生效”和“已生效但体验差”。出口已按预期改变，应用连接记录也命中代理，但加载缓慢，接下来应检查拥塞、丢包、解析耗时或目标服务本身。反复刷新 IP 页面不能解释吞吐表现，更不能据此证明某种协议一定更快。