VPN 怎么确认生效？先比较连接前后的出口 IP，再检查 DNS 请求的去向，最后验证真正要用的应用。客户端显示“已连接”，只能说明某个连接环节已经建立，不能替浏览器、终端或其他应用作出结论。
还要先分清目标：是让某个网站经过国际线路，还是让尽可能多的设备流量进入隧道？规则模式允许部分访问直连，这往往是预期行为。下面的检查以“目标请求是否按设置经过指定线路”为准，不把所有 IP 都发生变化当成唯一标准。
开始检查前：留好直连基线
先暂停当前代理或 VPN，在同一网络、同一浏览器里打开可信的公网 IP 查询页面，记录显示的地址、运营商信息，以及页面是否分别列出 IPv4 和 IPv6。随后连接客户端，确认当前线路与模式，再用同一页面复查。不要同时切换无线网络和线路，否则难以判断变化来自哪里。
检查期间，尽量只保留一个负责接管流量的客户端。浏览器代理扩展、系统代理、其他 VPN 和应用自带代理可能相互覆盖；受单位管理的设备也可能有强制网络策略，不宜擅自关闭管理组件。
- ✅ 记下当前网络、选中线路，以及规则模式或全局模式。
- ✅ 保存直连时的公网 IP 结果，区分 IPv4 与 IPv6。
- ✅ 确认系统已允许客户端建立 VPN 或启用所需的代理接管。
- ✅ 准备一个实际要访问的网站或应用，不只盯着检测页面。
出口 IP：确认这次请求从哪里出去
公网 IP 查询页面看到的是“访问该页面的请求出口”，不是设备全部流量的总报告。连接后地址发生变化，且与所选线路的出口信息相符，说明这次请求很可能已经经过代理或隧道。若地址没有变化，应先看检测域名命中了哪条规则，再判断连接是否失败。
IP 所属地区也不是精确定位。不同数据库可能更新不同步，线路名称中的接入地区也不一定就是最终出口地区。遇到显示不一致，可以换一个查询来源交叉确认，但不要仅凭城市名称就断定线路有问题。
| 观察结果 | 可能原因 | 下一步 |
|---|---|---|
| 地址变化，目标网站正常 | 检测请求已经过不同出口 | 继续验证目标应用及 DNS 路径 |
| 地址不变，日志显示直连 | 规则允许检测网站直连 | 检查目标域名的规则，不急着更换线路 |
| 地址不变，日志没有请求 | 应用可能没有进入客户端接管范围 | 核对系统代理、应用设置和接管模式 |
| IPv4 变化，IPv6 仍为本地出口 | 不同地址族可能采用了不同路径 | 核对客户端的 IPv6 支持与路由策略 |
| 地址变化，目标服务仍不可用 | 可能涉及账号、服务策略或出口限制 | 按错误提示检查，不能只重复查 IP |
如果服务本身已经使用了同一出口，切换线路也可能仍显示相同地址，因此“地址变化”是有用证据，却不是所有场景的必要条件。更可靠的判断需要把出口结果与客户端连接日志放在一起看。
DNS：看解析路径，不只看地区
DNS 的作用是把域名转换成可连接的地址。检测页面通常让浏览器请求一组测试域名，再观察哪些递归解析器参与查询。结果中出现的服务器地址通常属于解析器，不等于访问网站的出口 IP；解析器所在地区与线路地区不同，也不能直接证明发生了泄漏。
所谓 DNS 泄漏，应结合预期策略判断：本来要求域名解析也经过指定路径，实际却交给了非预期的本地或运营商解析器。反过来，规则允许国内域名本地解析时，出现本地解析器可能完全符合配置。先读清客户端的 DNS 模式，再解释检测结果。
浏览器安全 DNS 与系统 DNS 要分开看
浏览器可能通过加密 DNS 使用独立解析器，应用也可能自行解析。因此，修改系统 DNS 后，浏览器的检测结果未必随之改变。加密只说明查询的传输方式，不自动证明查询经过所选隧道；实际路径仍受路由和代理规则影响。
- 确认客户端是否接管 DNS，以及规则对目标域名使用什么解析策略。
- 查看浏览器是否开启独立的安全 DNS，并记录当前设置。
- 在同一网络下对比连接前后的检测结果，每次只改动一项设置。
- 必要时重新打开应用或按系统说明清理缓存，再测试新的解析请求。
分应用验证：浏览器正常还不够
桌面系统的“系统代理”通常只是向应用提供代理设置，并不强制所有程序遵守。浏览器能打开目标页面，不能证明终端、下载工具和桌面应用也采用相同路径。TUN 或 VPN 接口可以在网络层接管更多流量，但仍可能受路由、应用排除项和协议支持范围影响。
浏览器与桌面应用
先在客户端连接记录里找到目标域名，查看命中的是代理、直连还是拒绝规则。若浏览器正常、桌面应用异常，检查后者是否使用独立代理、是否需要重启才能读取系统设置，以及实际请求是否去了另一个域名。登录页面可用不等于登录后的接口、媒体资源或长连接也可用。
终端与开发工具
终端中的工具可能读取 HTTP_PROXY、HTTPS_PROXY 或 ALL_PROXY，也可能只接受自己的配置。不同工具对变量名称、代理协议和 DNS 解析位置的处理并不完全相同。不要照抄别人的本地端口；应使用当前客户端明确显示的监听地址、协议和端口，并检查工具文档。
如果浏览器能访问而终端不能，先观察终端请求是否进入客户端日志。没有进入时，优先处理接管方式；已经进入且连接失败时，再检查规则、线路和目标服务。企业开发环境里的证书问题应按管理规范处理，不应靠跳过证书验证掩盖。
移动设备
iOS 的 VPN 标识和 Android 的 VPN 状态只能作为连接提示。是否接管全部应用，要看客户端能力、分应用设置及系统策略。切换无线网络与蜂窝网络后，旧连接也可能需要重建。验证时应重新打开目标应用，执行实际操作，并观察客户端是否出现对应流量，而不只是看状态栏。
“连上了却没走”的常见原因
规则命中直连：规则模式根据域名、地址或其他条件选路，未命中规则的请求还可能落入默认策略。临时使用客户端提供的全局代理模式可以帮助对比，但这里的“全局”通常指已接管请求统一选用代理，并不代表所有应用都必然被接管。检查结束后再恢复需要的分流方式。
订阅更新后仍选着旧配置：更新订阅不一定会改变当前选中项。检查更新是否成功、当前线路是否仍存在，以及策略组实际选择了什么。遇到订阅获取失败，应通过服务面板核对状态，不要把完整订阅链接发给陌生人。
地址族或传输方式没有覆盖：应用可能优先使用 IPv6，或者使用 UDP，而当前接管方式只处理了部分请求。不能因为网页能打开，就推断实时通话或其他 UDP 应用同样可用。先确认客户端和线路是否支持所需传输，再按文档调整。
检测页面给出了其他线索：WebRTC 检测可能显示本地地址、经隐私处理的主机标识或公网候选地址。它与普通网页请求的出口不是同一个概念。应区分地址类型；如果出现非预期的本地网络公网出口，再结合客户端路由和浏览器设置排查。
连接与服务访问是不同问题：目标服务还可能检查账号地区、授权状态、支付信息或出口信誉。VPN 生效不能替代这些条件。换用不同代理协议，或看到线路标注为 IEPL、中转、直连，也不能单独证明目标服务一定可访问。
按这个顺序排查，避免反复重装
- 先确认原网络可用。暂停连接后测试普通网页；直连本身异常时，先处理网络接入问题。
- 确认配置与接管。核对订阅状态、选中线路、系统授权、代理开关以及是否存在冲突客户端。
- 用同一个检测页面比较出口。分别看 IPv4、IPv6，同时查看该域名命中的规则。
- 核对 DNS 策略。将系统、浏览器和客户端的解析设置分开检查，不凭地区标签直接下结论。
- 复现目标应用的问题。记录具体操作、错误提示，以及日志中对应的规则和连接结果。
- 只改变一个变量。可对比另一条线路或另一种接管模式，保留前后结果，再决定是否继续调整。
仍无法定位时，可把系统与客户端名称、所选模式、问题发生的操作，以及脱敏后的错误提示整理给支持人员。截图应遮住订阅链接、访问令牌、账号资料和不必要的地址信息。比起“已经连接但不能用”，这些线索更有助于区分配置问题与服务侧问题。
InnVPN 的订阅与客户端入口通过用户面板获取。需要核对基础配置时，可查看使用教程；需要继续定位异常时，可参考故障排查或通过客服工单说明情况。