V2Ray 故障排查手册

01 / 应用 → 本地入口 → 内核 → 出站

无法上网：拆开连接路径

“客户端已连接”通常只表示本地服务已经启动，不能证明远端认证成功，也不能证明浏览器流量进入了代理。排查时先记录客户端名称、操作系统、当前服务器别名、系统代理模式、路由模式和 Tun 状态，再记下失败网站及发生时间。不要一开始就删除配置或重置网络；原始日志与设置是判断问题所在的依据，清空之后很难比较前后差异。

先确认基础网络，再确认本地入口

退出客户端并恢复原来的系统网络设置，测试平时可以直接访问的网站。如果直连也失败，先检查无线网络是否需要网页登录、网线是否断开、网卡是否取得地址，以及系统是否残留手动代理。公共网络的认证页面可能在代理开启时无法出现，应完成认证后再启动客户端。若只有某个网站直连失败，不足以证明整个网络异常，应至少更换一个独立目标交叉判断。

基础网络正常后，重新打开 v2rayN，选择一个已经导入且参数完整的服务器，先关闭 Tun，只测试系统代理这一条路径。检查客户端设置中的本地监听地址和端口，确认内核启动日志没有报错。下面的命令只适用于本地端口确实为 10808、且该入口接受 HTTP 代理的情况；端口不同必须替换。它绕开浏览器是否读取系统代理这一变量，但不会绕开内核路由规则。

curl.exe --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 20 --head https://example.com/

命令返回网站响应头，即使是访问限制状态，也通常说明请求已经到达某个 HTTP 服务；仍要结合证书和响应内容确认目标。出现连接本地端口失败，优先检查内核是否运行、端口是否一致。出现代理隧道建立失败或远端握手错误，则转到服务器连接层。不要把 HTTP 入口当成 SOCKS 入口使用；两种协议写错时，端口虽然能连接，请求仍然无法正确解析。

用日志区分入口、出站与目标网站

打开 v2rayN 的日志窗口，记住当前时间，只发起一次目标访问，再观察对应的新日志。完全没有相关记录，可能是应用没有走代理，也可能是当前日志级别不记录正常请求，不能仅凭“没日志”断定流量未进入。可以临时提高日志详细程度，并用显式代理命令对照。日志出现连接拒绝，说明已经触达某个端点但服务未接受连接；持续等待直至超时，则还需要检查地址、网络路径与服务端状态。

若显式代理成功、浏览器失败，检查浏览器扩展、自定义代理及安全 DNS 设置，再按系统代理章节排查应用接管。若所有代理请求都失败，但直连正常，优先换一个配置来源独立的可用服务器。若只有单个域名失败，先查该域名的路由匹配与解析结果，不要立即更换全部订阅。服务器、目标网站和客户端是三个不同对象，需要分别验证。

最后关闭临时调试日志，恢复需要的系统代理或 Tun 模式，重新打开最初失败的应用。浏览器可能复用旧连接，必要时完全退出后重开。记录“哪一项改变使结果不同”，比记录“重启后好了”更有价值；前者能在故障复现时快速定位，后者无法区分偶发网络恢复与设置修正。

02 / 地址 → 端口 → 传输 → TLS → 认证

节点超时：定位握手阶段

节点测试显示超时，不等于服务器必然离线。测试可能需要先解析服务器域名，再建立传输连接，完成安全握手和协议认证，最后请求测试网址。任何一步失败都会影响结果。先查看使用的是 TCP 连接测试、真实连接测试还是网页测速；它们覆盖的链路不同。尤其是采用非 TCP 传输的配置，普通 TCP 探测不能直接代表真实协议的可用性。

先核对服务器端点，不急着改协议

在服务器编辑窗口核对地址和端口，确认地址栏没有带入 https://、路径或尾部空格，端口是服务端实际监听端口。域名地址应先确认能解析；IP 地址则要确认是否仍为当前服务地址。Windows 可以用下面的命令测试 TCP 可达性，示例域名需要换成自己的服务器地址。成功只证明 TCP 建连，不证明协议认证、TLS 或目标请求能够完成。

Test-NetConnection -ComputerName example.net -Port 443

测试失败时，在不改配置的前提下更换手机热点等另一条网络比较。如果另一条网络成功，优先调查原网络的出口、防火墙或路由限制；若两条网络都失败，再检查服务端监听、入口防火墙及地址是否过期。没有服务端管理权限时，把失败时间、端点和错误阶段提供给配置提供方，不要连续随机更换端口。端口与服务端不一致，只会产生新的故障。

区分 TLS、传输参数与协议认证

连接到端口后仍失败，应查看日志是否出现证书验证、握手、认证或传输路径相关错误。TLS 配置需要核对服务器名称，也就是常见的 SNI 字段，以及系统时间是否准确。证书名称通常不需要等于连接使用的 IP，但必须与服务端证书及配置要求匹配。使用 WebSocket 时还要核对路径和 Host；使用 gRPC 时核对服务名称。把它们都写成地址栏里的域名，并不是通用修复方法。

REALITY 配置除服务器地址外，还需要按来源核对公钥、短标识和服务器名称等字段。它与普通 TLS 的证书配置不同，不应套用同一组参数。VLESS、VMess 和 Trojan 的身份字段也不能互换。更新订阅后，旧服务器条目可能仍在另一个分组中，注意核对当前选中的是新条目，而不只是别名看起来相同。涉及证书错误的细分流程可继续阅读系统时间与 SNI 排查笔记。

不要通过长期跳过证书验证来掩盖握手故障，也不要为了消除超时不断增加等待时间。超时阈值只影响多久判失败，不能修复错误地址或认证参数。每修正一个字段后重新发起一次真实访问，确认日志已推进到下一阶段。若端口可达、握手成功而测试网址失败，问题可能已经转移到服务端出口、DNS 或测试目标本身，应换目标交叉验证，而不是继续修改客户端身份信息。

03 / 获取订阅 ≠ 连接服务器

订阅失败：检查获取与解析

订阅更新是一项独立的网页请求，使用的网络路径未必与当前服务器相同。先区分“请求没有下载到内容”和“下载到了内容但客户端无法导入”。前者通常涉及地址、网络、账户状态或证书，后者可能是返回页面不对、格式不匹配或字段不受支持。更新失败时先保留已有服务器，不要删除分组；旧配置有时仍能建立连接，能够帮助恢复订阅请求的网络路径。

核对地址与订阅分组

在 v2rayN 的“订阅分组”中打开对应分组设置，核对订阅地址是否复制完整，尤其检查问号后的查询参数、尾部字符及误带的换行。订阅链接中的令牌属于访问凭据，不要粘贴进公开日志、截图或在线解码工具。浏览器从聊天窗口复制文本时可能带入标点，富文本链接的显示名称也可能不是真实地址，应从配置提供方给出的复制入口重新获取。

确认正在更新的分组与编辑的分组一致，再尝试“更新订阅（不通过代理）”。当本地网络可以访问订阅服务时，这条路径可避免依赖失效服务器。若直连请求超时，而当前代理已经通过真实访问验证，再尝试通过代理更新。两种方式都失败时，记录各自错误；不要因为按钮名称不同就假设客户端一定走了预期出口，还应结合日志与当前代理状态判断。

根据返回内容选择处理分支

出现未授权或禁止访问，通常需要核对账户状态、订阅令牌与服务端权限，重复点击更新不会改变权限。出现请求过于频繁，应停止连续重试，等待服务端允许的间隔后再试。出现证书错误则检查设备时间和证书链。若请求返回成功却提示没有可用服务器，可能拿到的是登录页、维护页、验证页面或其他客户端格式；HTTP 请求成功不代表订阅内容正确。

订阅可以是客户端支持的分享链接集合或编码后的内容，并非看到一段文本就能通用导入。不要自行把其他配置格式改名后导入，也不要把订阅地址填进“从剪贴板导入分享链接”并期待所有客户端都自动识别。应按来源提供的客户端类型选择入口。订阅中某个新字段不被识别时，可以先在下载页核对客户端选择，再备份配置后更新客户端，避免直接手改整份订阅内容。

更新完成后验证当前条目

更新结束后，查看分组内服务器是否符合预期，再重新选择用于测试的条目。某些分组设置会保留旧服务器或保留当前选择，不能只看“更新完成”就认定所有条目已替换。别名相同也不代表地址、端口与安全参数相同。若更新后立刻无法连接，先比较新旧配置的协议、传输、安全设置，再向来源核对是否进行了服务端迁移或参数调整。

如果只有定时更新失败而手动更新成功，检查定时任务执行时客户端是否已启动、系统是否尚未联网、代理是否还没有可用服务器。启动顺序造成的失败不需要改写订阅格式。恢复后做一次完整闭环：手动更新成功、分组内容可见、选择新条目、真实网页访问成功。首次建立订阅分组的操作仍按快速上手教程进行，本章只处理这条链路中断的位置。

04 / 吞吐量、等待时间与稳定性分开测

速度慢：建立可比较的测试

“速度慢”至少包含网页首开慢、持续下载慢、视频缓冲和连接间歇中断四种现象。首开慢常涉及 DNS、握手及连接建立，持续下载慢更可能涉及带宽、拥塞与目标限速，中途断开则还要检查无线网络、设备休眠和服务端连接策略。先写清症状发生在哪一步，再选择测试方法。延迟低不代表吞吐量高，一次测速结果也不能代表所有网站的速度。

固定网络、目标与测试时段

测试时使用同一设备、同一网络、同一文件或网页，暂时停止系统更新、云盘同步及其他大流量任务。优先在有线网络或信号稳定的无线网络下比较，避免把无线干扰算到服务器上。连续测几轮并记录时段，不要同时启动大量服务器测速；并发测试本身会抢占本地带宽，也可能触发远端的连接数量限制。测速完成后等待连接结束，再做下一组比较。

先比较直连可访问目标的基础表现，再比较代理路径上的表现。两组目标不同，只能帮助发现本地网络是否普遍异常，不能直接用来计算代理损耗。若需要公平比较两个服务器，应使用相同目标与相同请求方式。某个下载源可能按来源地址限速，也可能只提供较慢的出口线路，因此“换服务器后更快”只证明该组合更合适，不一定说明原服务器整体性能不足。

把解析等待与传输等待拆开

若每次首次打开网页都等待很久，而随后下载正常，优先检查 DNS 超时、IPv6 回退和 TLS 握手。浏览器开发者工具中的网络时间线可以区分解析、连接、等待响应与内容下载，但使用代理时部分阶段可能由代理完成，数值解释要结合实际链路。可用显式代理命令排除浏览器扩展影响，再按DNS 章节比较解析路径。不要看到首开慢就直接修改缓冲区或线程数。

若持续传输速度低但网页响应正常，换一个独立下载源，检查是否只有某个目标慢。再换另一条本地网络，判断瓶颈在本地出口还是远端路径。路由策略也会影响结果：本应直连的大文件若被规则送到代理，可能绕远；本应代理的目标被错误直连，也可能反复等待重试。测试期间可以临时切换路由模式对照，成功后应修正具体规则，而不是长期忽略分流需求。

只在症状对应时调整高级参数

不要把开启复用当作必选项。复用的实际效果取决于内核、协议和服务端支持，可能减少部分连接开销，也可能在丢包时影响多个请求。UDP 转发是否可用，同样依赖客户端、出站协议、服务器与网络条件，不能通过一个开关保证。遇到语音或游戏异常，应先确认应用是否真正进入代理及 UDP 路径是否建立，再决定是否调整，而不是只看网页能否打开。

Tun 场景若表现为小网页正常、大请求卡住，可以检查路径 MTU，但这只是候选原因，不能据此直接下结论。先关闭 Tun，使用显式代理对照；只有差异稳定复现时，再参考客户端当前提供的 MTU 设置逐步调整，并保留原值。公司网络、虚拟机和多层隧道会改变有效报文大小，照搬他人的数值未必合适。每次调整后都要复测相同的大请求。

如果问题仅在固定高峰时段出现，保留跨时段的对照记录并向服务方反馈。客户端不能修复上游拥塞或远端出口容量不足。完成测试后恢复日志级别、路由与临时关闭的应用，避免调试环境与日常环境差别过大，导致测试正常而实际使用仍然缓慢。

05 / 服务器解析与目标域名解析是两条链

DNS 问题：确认由谁解析

先区分服务器域名与目标网站域名。客户端必须先知道服务器地址，才能连接远端；目标网站的域名则可能由应用、操作系统、内核或远端处理。浏览器开启安全 DNS 后，还可能走自己的解析路径。因此，系统命令能解析域名，不代表代理内核使用相同结果；网页通过代理成功，也不代表系统 DNS 已经恢复。排查第一步是画清实际路径，而不是立即替换解析器地址。

分别验证系统与内核的解析

Windows 可以用下面的命令观察系统查询的结果。记录回答中的地址类型、是否超时，以及换网络后是否变化。域名有多个合法地址并不一定异常，内容分发服务会按地区和网络返回不同结果。用 IP 直接访问 HTTPS 网站也不是可靠的替代测试，因为服务器可能依赖域名进行证书校验和虚拟主机选择；出现证书错误不能直接证明原域名解析有问题。

Resolve-DnsName example.com

再查看内核日志中是否存在解析超时、解析器不可达或无可用地址。若服务器地址本身是域名，而远程 DNS 又必须经过尚未建立的代理，就可能形成启动依赖环：连接代理需要解析域名，解析域名又需要先连代理。应按客户端提供的引导解析或服务器域名解析设置打破依赖，确保启动阶段所需的地址能够通过当前网络获得，不要把所有解析都强行送进未建立的隧道。

理解域名策略对分流的影响

路由中的 AsIs、IPIfNonMatch 与 IPOnDemand 控制的是路由匹配时如何使用域名解析，不能简单理解为三个“DNS 速度档位”。AsIs 不为这一步主动把域名转为 IP；IPIfNonMatch 在域名规则未命中时解析后尝试 IP 规则；IPOnDemand 在匹配需要 IP 的规则时触发解析。实际出站仍可能需要解析，不能把路由策略与全部 DNS 行为画等号。

下面是内核路由字段的局部示例，不是完整配置，也不应直接覆盖客户端生成的配置文件。它展示先匹配域名分类、再匹配地址分类的思路；需要已有对应的地理数据文件和名为 direct 的出站。通过 v2rayN 的路由设置编辑时，应确认客户端确实把规则写入正在使用的路由集。规则顺序及其他先行规则仍会影响最终结果。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": ["geoip:cn"],
        "outboundTag": "direct"
      }
    ]
  }
}

检查浏览器缓存、IPv6 与 Tun 接管

若只在浏览器中异常，检查浏览器安全 DNS、扩展和缓存；若所有应用异常，再检查系统与内核。IPv6 解析成功不代表当前网络具备可用的 IPv6 出口，反过来禁用 IPv6 也不是通用修复。应先比较地址族与连接日志，确认是否存在某一类地址持续失败，再调整客户端的解析或出站策略。修改后可能需要等待缓存过期，或重新启动相关应用以避免继续复用旧结果。

Tun 的 DNS 接管是否生效取决于客户端实现、系统路由和应用行为，不能认为开启 Tun 后所有 DNS 都必然采用同一条路径。若日志出现异常的虚拟地址，先确认是否启用了 FakeDNS 类机制，不要直接把地址写进系统 hosts。清理缓存前记录旧结果，变更解析设置后重新比较。更完整的前缀和匹配顺序说明见自定义路由规则笔记，具体分流组合见直连、代理与阻断配置。

06 / 系统设置、应用设置与虚拟网卡分开查

代理不生效：检查接管方式

系统代理是应用可以读取的一组设置，不是所有流量都必须经过的总开关。Tun 则通过虚拟网络接口与路由接管流量，两者作用层级不同。排查时先只开启一种方式：桌面浏览器优先从“自动配置系统代理”开始，确认本地入口与远端连接都正常，再测试 Tun。两种方式一起开且同时修改 DNS，会使失败原因混在一起，很难判断究竟是哪一层改变了结果。

确认系统设置与应用实际读取一致

在 v2rayN 底部状态栏选择“自动配置系统代理”，然后进入操作系统的代理设置查看是否确实写入了本地地址与端口。端口必须与客户端监听入口一致，不能只检查地址为回环地址就结束。若系统设置会自行恢复，检查是否有另一个代理程序、浏览器扩展、设备管理策略或安全软件在改写。不要让多个客户端同时管理系统代理，也不要反复争抢同一组设置。

Windows 下部分命令行程序和后台服务不会使用桌面系统代理，有的读取环境变量，有的采用独立的代理设置。浏览器能访问而命令行失败，不一定是客户端坏了。先按应用自身文档设置代理，或使用支持显式代理参数的请求进行对照。macOS 的代理设置与当前网络服务相关，切换无线网络、网线或其他服务后，应检查当前生效的服务，而不是只看此前配置过的那一个。

用单一入口排除端口与绕过列表

检查系统代理的绕过列表，以及浏览器是否为目标域名配置了直连规则。内网地址直连通常是合理设置，不能为了让日志出现记录就把全部内网流量强制送到远端。若目标被绕过，应根据实际用途修改具体规则。需要连接本机代理的其他设备则属于另一种场景，涉及监听地址、防火墙和访问控制；不要为了修复本机浏览器而随意开启局域网监听。

Tun 失败时先检查权限和路由

关闭其他 VPN 或隧道程序，再按客户端提示授予创建虚拟接口和修改路由所需的权限。Windows 常涉及管理员权限，其他桌面平台按当前客户端的权限提示操作。打开 Tun 后观察日志是否确实完成接口创建，而不是仅看开关是否点亮。如果系统要求权限但对话框被取消，界面状态可能暂时不能完整反映底层结果，应以日志和实际接口状态为准。

若 Tun 一开就断网，先关闭并确认网络恢复，再检查多网卡、虚拟机网络、企业接入软件和残留路由。远端服务器的连接若被错误地重新导入自身隧道，可能形成回环；DNS 接管冲突也会使所有域名看起来同时失效。不要在不理解路由作用时批量删除系统路由。优先使用客户端正常停止功能撤销设置，再逐个停用冲突程序进行比较，保留恢复路径。

修复后分别验证需要代理的应用、局域网服务和系统联网检查。某个系统联网图标显示异常，可能只是其检测目标不可达，应结合实际请求判断。关于主窗口状态栏、日志与参数设置的位置，可查看v2rayN 主界面说明。最终应留下清楚的工作方式：哪些应用读取系统代理，哪些应用需要独立设置，以及何时才需要 Tun。

07 / 图形界面启动与内核启动分别处理

启动失败：保留现场再恢复

双击没有窗口、窗口打开后退出、界面正常但内核停止，是三种不同问题。先查看任务管理器中是否已有客户端进程，确认窗口是否缩到托盘或移到已断开的显示器。不要连续双击启动多个实例；它们可能争用本地端口或配置文件，让原本单一的故障变成多实例冲突。需要结束进程时先记录日志，再正常退出，只有无响应时才考虑强制结束。

确认安装格式、架构与可写目录

从客户端下载页核对系统和处理器架构。Windows 的桌面版与经典 WPF 版界面技术不同，所需运行环境也可能不同，应以安装包说明和启动提示为准，不能把另一版的依赖要求当成统一答案。Linux 还要区分 deb 与 rpm 包格式，macOS 则先区分 Apple Silicon 与 Intel。架构错误、系统版本不满足要求和缺少依赖，都不是修改服务器参数能够解决的问题。

如果使用解压形式的程序，先完整解压到当前账户可写的目录，不要在压缩包预览窗口里直接运行，也不要只拷贝主程序而漏掉附带文件。配置写入失败时检查目录权限、磁盘剩余空间和同步软件的文件占用。安全软件拦截需要查看其具体记录，确认被处理的是哪个文件；不要为了让程序启动而整体关闭设备防护，更不要从不明来源补齐所谓缺失组件。

内核启动失败按第一条错误处理

图形界面正常但内核无法启动，先看日志最早出现的错误，而不是最后一行“已停止”。端口占用、配置语法错误、未知字段、地理数据文件缺失与权限不足，处理方法完全不同。若本地监听端口冲突，先查明占用进程，不要直接结束陌生的系统服务。Windows 可以使用以下命令观察端口与进程；示例端口仍需与客户端实际值一致。

Get-NetTCPConnection -State Listen -LocalPort 10808 |
  Select-Object LocalAddress, LocalPort, OwningProcess

Get-Process -Id 1234

第二条命令中的进程号只作演示，应替换为第一条命令查到的值。如果占用者是另一个客户端实例，退出重复实例；若是需要保留的程序，可修改本地监听端口，并同步系统代理及应用内代理。只改其中一处会把启动问题变成入口连接失败。若查询没有结果，也要留意错误指向的是其他监听端口，而不是默认假定所有冲突都发生在同一个端口。

配置错误应结合日志指出的对象与字段定位。JSON 的多余逗号、错误类型和未闭合引号会导致解析失败；能被 JSON 解析器接受，也不代表符合内核字段要求。自定义片段需要与所用内核兼容，Xray 与 V2Fly 的字段支持不能机械互换。客户端生成的运行配置可能在重启后被覆盖，应回到客户端设置或自定义配置入口修改，不要只编辑临时输出文件。

用最小配置判断是否为用户数据问题

恢复前备份订阅分组、路由、自定义 DNS 和必要的用户设置，并保护其中的订阅凭据。退出程序后，按客户端支持的方式使用独立配置目录或重命名原配置目录，再测试最小配置；不要在程序仍运行时移动数据库。如果干净配置能启动，逐项恢复设置，先恢复一个服务器并验证，再恢复路由和高级选项。一次把整份旧数据导回去，会把故障一起带回来。

若最小配置仍崩溃，查看操作系统的应用错误记录、权限提示与运行环境信息，再考虑重新安装。提交问题记录时注明复现步骤和错误文本，隐藏身份字段、订阅地址及个人目录中的敏感部分。更细的配置错误示例见内核启动失败日志诊断。恢复的完成标准不是窗口能打开，而是内核持续运行、本地入口可连接，并且退出重开后设置仍然正确。

08 / VPN 授权 → 应用范围 → 后台 → 网络切换

安卓专项：连接与后台断流

安卓优先使用 v2rayNG，确实需要 V2Fly 内核时再考虑 v2flyNG。两者的配置能力和字段支持可能不同，不能为了排查把同一份复杂配置直接互相覆盖。先确认安装包与设备架构匹配；主流新设备通常使用 arm64，但具体仍以设备系统为准，无法确认时查看下载页的通用包说明。安装失败应先看系统给出的原因，不要通过修改安装包或绕过系统签名检查来处理。

VPN 授权成功后仍要验证远端连接

首次连接时接受系统 VPN 授权，并观察系统是否显示对应连接。若已经有其他 VPN 应用运行，先断开它，再测试 v2rayNG。安卓通常只允许同一用户或资料环境中的一个常规 VPN 服务占用对应位置，两个应用反复接管会造成看似随机的断连。系统钥匙图标说明本地 VPN 服务已建立，不表示服务器认证通过，也不表示订阅里的每个配置都可用。

在 v2rayNG 中选择目标配置后连接，打开应用日志，只发起一次真实网页访问。若报服务器解析失败，先按 DNS 章节检查；若握手失败，按节点超时章节核对传输与安全参数。需要比较时先使用同一配置分别测试无线网络和移动数据，不要在换网络时顺便更换服务器。移动数据的流量限制、漫游权限和系统联网控制也可能影响结果，应在系统设置里逐项确认。

检查分应用代理与系统专用 DNS

若只有某个应用不能访问，打开分应用代理设置，确认当前采用的是“仅代理选中应用”还是“绕过选中应用”的逻辑。两者勾选相同应用会得到相反结果。检查目标应用是否位于工作资料、应用分身或其他用户空间，这些环境可能不属于当前 VPN 的接管范围。修改应用列表后，按客户端要求重建连接，并完全退出目标应用后再试，避免旧连接继续沿原路径工作。

系统“私人 DNS”或“专用 DNS”的名称会因设备而异，它可能与客户端内置 DNS、浏览器安全 DNS 共同参与解析。若问题只在某种网络下出现，可在记录原设置后暂时改为系统自动模式作对照，再检查客户端的域名策略与解析器可达性。不要同时修改三个位置，否则即使恢复联网，也无法知道哪个设置才是原因。网页可以打开但单个应用失败时，还应检查应用自己的代理和联网限制。

锁屏断连优先查后台管理

前台正常、锁屏一段时间后失效，优先检查电池优化、后台活动权限、自启动限制和系统数据节省模式。允许客户端持续后台运行，并确认系统没有禁止它在后台使用移动数据。不同设备厂商的设置入口不同，应按系统实际菜单操作，不必寻找完全相同的名称。将应用留在最近任务列表并不能替代所有后台权限；仍要用锁屏前后日志与连接状态确认服务是否被终止。

如果系统支持始终开启 VPN，可在基础连接稳定后再评估是否启用。“没有 VPN 时阻止连接”会改变断线后的网络行为：客户端停止时，普通联网也可能被系统阻止。排查阶段应记录此项状态，避免把系统主动阻断误认为服务器故障。需要临时恢复直连时，应先理解并调整对应策略，而不是仅关闭客户端连接按钮。受单位设备管理策略控制的设备，则应按管理要求操作。

网络切换后短暂等待或需要重连，可能与旧连接、地址变化和系统网络恢复有关；若每次切换都永久失效，应检查 VPN 是否自动重建、服务器域名是否重新解析，以及新网络是否能连接远端端口。最后在常用应用里做实际访问，不要只依赖应用内的延迟测试。初次导入和连接步骤参照配置教程；需要更换安装格式时回到安卓客户端下载，保留现有设置备份后再操作。