V2Ray 客户端
故障排查

无法上网：先分开底层网络与代理链路

停止代理，确认原始网络能够工作

v2rayN → 清除系统代理，并关闭 Tun 模式；v2rayNG → 停止连接。先访问平时可以直接打开的站点，确认当前网络是否需要网页认证。公共无线网络即使显示已连接，也可能尚未完成登录；此时代理客户端启动成功，并不代表设备已经取得可用的互联网出口。若关闭客户端后仍无法访问，优先检查无线信号、路由器上网状态和系统网络设置，不要继续修改节点参数。

切换到另一种网络再复测，但保持节点和客户端配置不变。例如从无线网络切到移动数据，观察直接访问能否恢复。只有某个网络失败，检查范围就收敛到该网络的认证、解析和访问策略；所有网络都失败，则继续检查设备本身。测试期间暂停其他会接管网络的程序，尤其是其他 VPN、加速工具与带代理功能的安全软件，避免两个程序互相覆盖路由。

沿“内核启动、节点连接、流量接管”逐层检查

重新打开客户端，先看日志中是否出现内核退出、配置加载失败或端口占用。界面显示运行只说明前端仍在，内核进程可能已经停止。内核能够保持运行后，对当前节点做真连接测试，再在浏览器发起一次实际访问。真连接失败时转到节点超时；真连接通过、浏览器仍失败时，重点检查系统代理、应用代理以及 DNS，不必立即更换协议。

桌面端可以临时关闭 Tun，只保留自动配置系统代理，以减少变量。若此时浏览器恢复，而开启 Tun 后失败，优先查虚拟网卡创建、运行权限和路由冲突。反过来，Tun 可用而系统代理不可用，通常需要核对应用是否读取系统代理，以及系统设置里的地址和端口是否仍指向当前客户端。两种方式不能互相证明全部配置正确，它们接管流量的位置并不相同。

用少量访问样本区分全局故障与单站故障

选择两个不同站点，并同时观察其他应用。只有一个站点打不开，可能是目标服务维护、账号限制、证书错误或对应路由命中异常。浏览器显示证书警告时，先核对系统日期与时区，不要把关闭证书验证当作常规修复。只有一个应用失败，则检查应用自己的代理、独立 DNS 和缓存；所有应用同时失败，才更接近公共链路或系统接管层的问题。

恢复联网后，先退出客户端一次，确认系统代理能够正常清除，再重新连接复测。异常退出留下的代理地址，可能让下次开机看起来仍然断网。不要直接重置整套网络：先保存出错时间附近的日志与原设置，只在证据指向系统层时再扩大操作范围。基础流程可与首次连接检查笔记交叉核对。

节点超时：区分连通、握手与测试目标

先确认超时发生在哪一段

节点列表 → 真连接测试，随后打开日志，找到同一时间的错误。连接超时通常表示在规定等待时间内未完成某一步，不等于服务器已经永久失效。域名解析失败、连接服务器端口失败、加密握手失败，以及代理建立后测试目标不响应，都可能表现为测试失败。先读错误里的阶段和目标地址，再判断下一步；只看列表中的一个结果，容易把不同原因混在一起。

如果日志停在连接服务器地址，核对订阅是否刚更新、当前节点是否仍被设为活动项，以及服务器域名能否解析。换一个同组节点作对照，再换一种网络复测。单节点失败而其他节点正常，优先怀疑该条配置或服务端；同组全部失败但其他组正常，检查该组服务状态；所有组都失败，则回到设备网络、系统时间和客户端内核启动情况，避免同时修改所有节点。

连接端口成功，不代表协议握手完成

端口可达只能证明有服务接受连接，无法证明用户标识、传输方式和加密参数匹配。握手错误时逐项核对协议类型、服务器端口、传输类型、TLS 开关、服务器名称与路径。使用 WebSocket 等传输时，路径和 Host 字段也需要与服务端一致；使用 REALITY 时，公钥、短标识和服务器名称同样不能靠猜测填写。最稳妥的恢复办法是从可信的原始配置重新导入，而不是逐个尝试随机值。

系统设置 → 日期和时间，开启自动校时后再试。明显的时钟偏差可能影响证书有效期判断，某些协议认证也依赖时间。遇到证书域名不匹配，应核对服务器名称与服务方说明，不要直接改成允许不安全连接。若配置来自长期保存的剪贴板，确认没有混入换行、全角字符或旧端口；手工编辑前备份该条节点，便于与重新导入后的条目比较。

排除测试地址与真实使用之间的差异

真连接测试通常会经过代理访问一个指定目标。目标临时不可达、响应方式变化或被规则送往不同出口，都可能让节点被判为失败。先查看客户端参数中的测试地址，确认它仍是有效的网页地址，再用浏览器经过相同节点访问另一站点。不要为了得到通过结果不断缩短超时阈值，也不要把测试地址的可达性当成全部互联网服务的可用性。

需要进一步定位时，可在 Windows PowerShell 检查 TCP 端口。下面命令仅检查本机示例端口是否有人监听，适合确认本地入口；要检查远端服务器，应在本机填入实际服务器地址和实际端口。结果为成功也不能证明代理认证成功。 macOS 与 Linux 可用系统网络工具做同类检查，但不必为一次排查额外安装整套工具，客户端日志通常已经提供足够的阶段信息。

Test-NetConnection -ComputerName 127.0.0.1 -Port 10808

如果同一节点在另一台设备能用，比较两端是否刚更新过订阅、使用相同内核能力，以及是否存在手工覆盖字段。v2rayN、v2rayNG 和 v2flyNG 的界面相近，不代表每个配置扩展都能互换。保留服务方原始参数，向服务方说明具体握手错误和失败时间，比只反馈“超时”更容易定位。涉及用户标识、订阅地址与完整服务器信息的日志，不应直接公开。

订阅失败：分清下载失败与内容无法导入

从订阅分组中的地址与更新方式开始

v2rayN → 订阅分组 → 订阅分组设置，检查地址是否完整；v2rayNG → 订阅分组设置，检查同一项。复制时常见的问题是只选中了链接的一部分、把分享说明一并复制，或者保留了前后的空格。订阅地址可能包含个人访问凭据，排查时只在本机查看，不要发送到公开转换工具。若服务方重新生成过地址，旧地址可能已经作废，需要重新复制当前有效入口。

更新失败先看错误是超时、解析失败、证书问题，还是服务器返回拒绝访问。超时先检查当前网络；解析失败转到 DNS 章节；证书问题先检查系统时间和返回的证书提示。访问被拒绝或资源不存在，往往需要核对账号状态、地址是否过期以及服务方是否更换入口。不要通过重复点击更新来验证账号权限，多次相同结果并不会提供新的判断依据。

直连更新与通过代理更新分别验证

订阅更新本身也需要联网。若当前所选节点已失效，而更新又被设置为通过代理，便会出现“必须先有可用节点，才能获取新节点”的循环。先试客户端提供的不通过代理更新方式；若直连失败，而已有另一条可用连接，则保持该连接后再尝试通过代理更新。不同构建的菜单措辞可能不同，关键是明确这次请求实际走哪条链路，不要只切换按钮却不看日志。

更新操作返回成功，也要确认得到的是节点内容。有些网络会把订阅请求重定向到无线认证页，有些服务会返回账号到期说明或普通网页。此时下载请求完成，但解析器无法把内容转换成节点。若客户端支持查看更新日志，留意是否提示格式不支持、没有有效服务器或内容为空。可以在本机浏览器检查响应是否为登录页面，但不要保存或分享含凭据的完整页面截图。

保留原分组，用小范围导入验证格式

不要先删除整组再更新。先保留仍能使用的配置，必要时导出到自己的受保护目录，再新建一个测试分组导入同一订阅。新分组可导入而旧分组失败，检查旧组是否设置了过滤条件、自动排序、别名或其他覆盖选项。两组都无法导入，则确认服务方提供的是对应客户端可识别的格式。普通配置文件、单条分享链接和聚合订阅不是同一种输入，不能只凭链接外观判断用途。

订阅更新会影响后续自动生成的配置。把重要的手工修改直接写在订阅节点上，下一次更新可能被覆盖；需要长期保留的调整，应先了解客户端是否提供独立的覆盖或自定义配置机制。更新结束后检查活动节点是否仍存在，重新选择有效项，再做一次真连接测试。节点数量变化本身不等于出错，服务方可能正常增加或移除条目，判断依据应是有效配置与实际连通性。

若只有某种新协议组合无法导入，到安装包页面确认客户端选择，再阅读该客户端支持的配置说明。安卓默认先使用 v2rayNG，只有明确需要相应内核配置时再考虑 v2flyNG。不同内核家族的扩展字段存在差异，不能假定改个应用名称就能兼容。常见的导入入口与订阅概念也可在FAQ中查阅，避免将格式问题误判为节点全部失效。

速度慢：分开首包等待与持续传输

先描述慢在哪里，再决定测试方法

网页第一次打开等待很久，打开后内容很快，与大文件始终下载缓慢，是两类问题。前者通常需要观察解析、连接建立和握手；后者更接近带宽、丢包、服务负载或流量策略。先关闭后台下载、云同步和正在播放的视频，固定一个节点、一个应用与同一个测试资源。无线信号不稳时尽量靠近接入点，桌面端有条件可换有线网络，以免把本地无线重传算到代理性能上。

用直接连接能够访问的同一资源作基础参照，再经代理访问。资源本身如果限制速度，即使链路正常也无法据此判断出口能力。不同站点可能选择不同内容分发入口，同样的下载地址也可能得到不同路径，因此一次测试只能说明当时那条访问链路。不要把真连接测试的耗时当成下载带宽，它主要反映建立请求的等待，无法覆盖长时间传输中的拥塞与稳定性。

固定变量，比较节点、网络和时段

先在同一网络换一个节点，再保持节点切换网络，最后在另一个时段复测。这样能够分别观察服务出口、本地网络与高峰负载。只有单节点变慢，优先检查该节点服务状态；所有节点在某个无线网络都慢，优先查信号、路由器负载与运营链路；所有设备访问同一目标都慢，则需要考虑目标站点或共同出口。每轮记录现象即可，不需要长时间持续压满线路。

路由规则也会改变速度。某些资源本来可以直接访问，却被送入较远的代理出口；另一些页面主体直连、图片和接口却走代理，呈现出来就像部分内容卡住。检查当前路由模式、规则顺序与日志中的目标去向。可以临时使用更简单的路由方案对照，但测试后恢复原设置。不要用永久全代理掩盖规则错误，也不要仅因某个站点变快，就认定所有应用都适合相同模式。

仅在证据指向接管层时调整 Tun 与 MTU

关闭 Tun 后浏览器传输正常，开启后大文件停顿，需要进一步检查虚拟网卡、其他 VPN 与 MTU。MTU 过大在某些路径上可能造成分片或重传问题，但并非所有慢速都由它引起。先记录原值，只做小范围调整并使用相同资源复测；没有稳定改善就恢复。不要一次同时修改 MTU、DNS、传输参数与内核，否则即使恢复，也无法知道真正有效的是哪一项。

音视频、游戏等应用还可能使用 UDP 或 QUIC。某条链路对网页 TCP 请求正常，并不意味着其 UDP 转发同样正常。若只有这类业务卡顿，应确认节点与客户端接管方式是否覆盖相关流量，并查看是否存在应用自行回退到其他传输的过程。浏览器关闭某项实验功能可用于短期对照，但不能作为所有用户的固定优化方案，更不应改变不相关的系统设置来追逐一次测速结果。

同时查看设备资源占用。大量规则、频繁日志写入与并发连接，可能让低性能设备的处理器或存储成为瓶颈。排查时停止重复测速，关闭不必要的调试级日志，再观察正常使用；不要把关闭系统防护当作提速步骤。共享代理时还要确认是否有其他设备同时占用出口，相关范围与监听设置见局域网共享设置笔记。若最终定位为服务端拥塞，客户端本地微调通常无法消除，需要更换可用出口或向服务方反馈时间段与测试条件。

DNS 问题：确认由谁解析、经哪里查询

域名失败不等于代理服务器不可用

日志出现解析失败、找不到主机或反复等待解析时，先分清失败的是代理服务器域名，还是最终访问目标的域名。前者发生在建立代理连接之前，若它只能通过尚未建立的代理解析，就可能形成依赖循环；后者则需要查看客户端 DNS、路由策略与目标应用的解析方式。浏览器页面转圈只是一种外观，不能据此判断是本机解析器还是远端解析器出了问题。

Windows 可在终端运行下面命令，观察系统解析器是否返回结果。这里使用公开文档域名，只检查系统当前 DNS 的基础行为。返回地址不代表网页一定可访问，也不代表代理内核使用同一解析路径。若系统查询成功而客户端日志仍显示 DNS 错误，继续检查内核配置里的 DNS 服务器地址、查询所走的出站和域名策略，不要反复清理浏览器历史记录来替代定位。

nslookup example.com

检查系统、浏览器与客户端三层设置

系统网络设置 → DNS，记录当前是自动获取还是手工指定。随后检查浏览器是否启用了安全 DNS，以及客户端是否配置了独立 DNS。三者可以并存，但会让同一个域名得到不同结果，也可能绕开预期的分流规则。排查时先选择一条明确的解析路径，暂时关闭不必要的独立覆盖，复测后再逐项恢复。企业或校园网络存在内部域名时，还要保留其必要的内部解析能力。

使用加密 DNS 时，需要连接解析服务自身的地址。如果该地址也是域名，就需要先完成初始解析；若规则又要求它经过一个尚未成功建立的代理，仍可能形成循环。遇到这种情况，应按客户端文档设置可达的引导解析与出站，而不是继续叠加更多解析服务。增加服务器数量不一定提高可靠性，错误的并行查询和选路反而会把结果来源变得难以解释。

结合路由理解查询与连接的关系

下面是内核配置中的 DNS 与路由片段，仅用于理解字段关系，不是可直接导入客户端的完整文件。它展示了域名服务器列表和按需解析的策略；实际运行仍需要完整的入站、出站与其他必要配置。使用图形客户端时，应优先修改客户端对应设置，避免直接编辑自动生成文件，因为重启或切换节点可能重新生成内容。不同内核可用字段也应分别核对。

{
  "dns": {
    "servers": [
      "1.1.1.1",
      "8.8.8.8"
    ]
  },
  "routing": {
    "domainStrategy": "IPIfNonMatch"
  }
}

按域名匹配的规则可能在解析前就决定出口；按地址集合匹配则可能需要先拿到 IP。解析结果、规则先后顺序和连接目标三者必须放在一起看。若直接访问返回的 IP 失败，也不能立即断定 DNS 错误，因为很多网站依赖正确的域名与 TLS 服务器名称，直接输入 IP 并非等价请求。只有在理解目标服务的前提下，地址级测试才有诊断价值。

修改解析设置后，旧结果可能仍保留在系统、浏览器或应用缓存中。Windows 可在确认新设置已生效后运行下面命令，再重启出问题的应用并发起新请求。缓存清理只是让新查询发生，不会修复不可达的 DNS 服务器。若域名只在某个网络失败，比较该网络的 DNS 与认证状态；若仅开启 Tun 后失败，重点核对 DNS 接管、虚拟网卡路由与其他网络工具冲突。

ipconfig /flushdns

系统代理不生效：核对应用入口与监听地址

先检查客户端与系统是否指向同一端口

v2rayN → 自动配置系统代理，再打开系统网络设置中的代理页面，检查地址是否为本机回环地址，端口是否与客户端实际监听一致。常见本地端口可以是 10808，但应以当前设置为准，不能按教程数字强行覆盖。内核未启动、监听端口被其他程序占用，或系统仍保存旧端口，都会出现“代理已开启但访问失败”。先证明本地入口存在，再去排查远端节点。

客户端参数设置中还要确认该监听入口接受哪种代理协议。应用选择 HTTP 代理却连接只接受 SOCKS 的入口，或反过来，通常会导致连接立即失败或返回异常内容。某些构建提供混合入口，能够接收多种代理协议；也有构建分开配置不同端口。不要仅凭端口数字判断类型。局域网监听与回环监听也不是一回事，本机使用通常不需要开启允许来自局域网的连接。

系统代理只影响愿意读取它的应用

浏览器可能读取系统代理，也可能使用自己设置的代理或扩展。先暂停代理扩展，在浏览器设置中确认使用系统配置，再打开一个新页面观察日志。若客户端没有看到对应请求，流量可能根本没有进入本地入口。命令行工具、游戏与部分桌面程序不一定读取系统代理，应查看应用自己的网络选项，不能仅因为浏览器正常就判断所有程序都会自动经过客户端。

可以使用显式代理请求与普通请求对照。下面命令要求本地 10808 入口接受 HTTP 代理，且内核和活动节点已经运行；若当前是其他端口或协议，应按实际设置调整。在 Windows PowerShell 中使用系统提供的 curl.exe，可避免命令别名差异。显式请求成功而普通浏览失败，重点检查系统与浏览器入口；显式请求也失败，继续检查监听、节点和解析，不要先扩大接管范围。

curl.exe --proxy http://127.0.0.1:10808 --head https://example.com/

区分系统代理、自动配置脚本与 Tun

系统代理页面可能同时存在手动代理、自动配置脚本与自动检测。保留旧脚本地址或其他程序写入的配置，可能使实际选路与界面预期不同。先记录原状态，停止其他会修改代理的工具，再只保留这次排查所需的一种方式。受组织策略管理的设备可能禁止修改或自动恢复设置，这类限制应联系设备管理员处理，不应通过反复提升权限绕过管理要求。

确实需要接管不读取系统代理的流量时，再考虑 Tun。开启前先证明当前节点能够通过普通代理访问；开启后观察虚拟网卡是否建立、默认路由是否改变以及日志是否出现权限错误。其他 VPN、虚拟机网络或安全软件都可能参与路由，出现冲突时一次只暂停一个相关程序作对照。不要把允许局域网连接当成 Tun 的前提，两者解决的不是同一个问题。

退出前使用清除系统代理，再检查系统页面是否恢复。若客户端此前崩溃，系统可能仍指向已经停止的本地端口，需要手工关闭遗留的代理设置，之后再正常启动客户端。恢复过程中的旧值应保存，尤其是工作环境原本存在代理时，不能直接删除所有项目。有关系统代理与路由的基本区别，可回到快速上手核对；需要判断客户端平台差异时，查看客户端对比，不要在不同系统间机械复制设置。

客户端崩溃：先保存现场，再隔离配置

分清界面退出、内核退出与后台停止

窗口消失不一定表示程序崩溃，也可能只是最小化到托盘；界面仍在也不一定说明内核运行正常。先检查任务栏、托盘与进程列表，再看日志是否持续记录新请求。若前端保持运行但内核反复启动后退出，重点检查配置、端口与权限；若点击启动就整个程序关闭，则需要观察系统应用错误记录、运行环境和配置读取情况。安卓后台停止另见下一章，不能直接套用桌面结论。

操作前停止自动重复启动，保存应用日志和出错时间附近的系统记录。Windows 可在事件查看器的应用程序日志中找对应错误；macOS 可查看系统提供的崩溃报告；Linux 可查看桌面启动提示与用户级日志。无需把整套记录全部上传，先提取错误模块、退出原因与时间。日志可能包含服务器地址、用户标识和订阅凭据，对外反馈前应遮盖这些内容，但保留错误类型与上下文顺序。

检查架构、安装方式和文件写入权限

从安装包页面按系统与处理器架构选择客户端。程序无法启动时，不要先从不同来源混合复制可执行文件和内核文件，这容易造成依赖不一致。Windows 的桌面版与经典 WPF 版属于不同界面方案，排查可按说明选择对应入口，但迁移前应备份原配置。macOS 应核对芯片类型，Linux 应核对发行版包格式与系统架构，不能只看文件扩展名就决定适用性。

程序所在目录、用户数据目录和日志目录需要具备正常写入权限。只读位置、受控目录、磁盘空间不足或同步软件占用文件，都可能让保存配置和启动内核失败。先查看具体错误路径，再把数据迁移到自己可写的位置，避免直接给整个磁盘放宽权限。系统安全软件若提示拦截，先阅读提示与文件来源信息，不要整体关闭防护；组织管理的设备还应遵循管理员的安装策略。

用最小配置复现，不直接抹掉原数据

完整备份后，关闭客户端，再按其数据目录说明建立独立的测试配置。若客户端支持便携或独立数据目录，应使用正式支持的方式，不要猜测目录参数。测试环境只导入一条已知可用配置，暂时关闭 Tun、自定义路由和额外覆盖。最小环境能启动，说明问题更接近原配置或某个扩展选项；最小环境仍崩溃，则继续查看安装环境、架构与系统错误记录。

恢复原设置时按订阅、基础代理、路由、Tun 的顺序逐项加入，每加入一项就启动并测试。某一步稳定复现错误，保留该步前后的差异。配置语法错误通常会在日志里指出字段或位置；如果手工编辑过 JSON，检查双引号、逗号与字段类型，但不要用文本替换批量修补所有文件。自动生成文件出错还应追溯源设置，否则下次切换节点仍可能生成相同错误。

更新后才出现问题，应记录更新前后采用的界面方案、内核家族与配置变化，而不是凭记忆填入版本信息。需要反馈时，说明操作系统、处理器架构、启动方式、复现步骤，以及最小配置是否也失败。若发生在休眠唤醒或网络切换后，再补充电源与网络状态变化。恢复后先验证退出时系统代理能否清除，确认不会把局部程序故障遗留为系统断网，最后再恢复自动启动。

移动端专项：VPN 授权、后台与分应用代理

确认 VPN 服务真正建立，而非只有应用打开

v2rayNG → 连接，首次启动需要系统 VPN 授权。该授权允许客户端通过 Android 的 VPN 服务接管本机流量，不代表已经连上远端服务器。授权后仍要查看运行通知、应用日志与实际访问。若反复出现授权提示，检查是否有另一个 VPN 应用正在运行，以及系统是否由工作资料或设备管理策略限制。一个用户环境中的 VPN 接管通常存在竞争，应先停止其他接管程序再测试。

设置中的 VPN 与仅代理模式也需要区分。VPN 模式通过系统接口接管符合条件的应用流量；仅代理模式主要提供本地代理入口，需要应用自己使用该入口。误选仅代理后，客户端内测试可能正常，而普通应用没有变化。先记录当前模式，使用 VPN 模式完成基础访问验证，再考虑高级用途。若系统设置了始终开启的 VPN 或阻止未通过 VPN 的连接，还要核对其绑定的是否正是当前使用的客户端。

锁屏后断连，检查电池和后台限制

系统设置 → 应用 → v2rayNG → 电池，检查是否限制后台活动，并按设备提供的选项允许持续运行。不同厂商的菜单可能写作后台运行、自启动或电池优化，路径名称并不统一。先保证应用能够显示持续运行通知，再做锁屏测试。通知被关闭不一定等于服务被停止，但会减少可观察信息；电池状态、系统省电模式与后台数据限制则可能直接影响连接保持。

把屏幕亮着、锁屏后和切换网络后三种情况分别记录。只有锁屏一段时间后失败，重点查后台限制；从无线网络切到移动数据后失败，重点查网络恢复与旧连接重建；移动数据始终失败而无线正常，则检查流量节省、应用移动数据权限与该网络的连通性。修改省电选项后，要重新启动连接并重复同样的锁屏条件，不能仅看设置已保存就判断问题解决。

分应用代理必须核对名单方向

v2rayNG → 设置 → 分应用代理，先看当前是仅代理所选应用，还是绕过所选应用。两种名单方向相反：前者要求目标应用被选中才进入代理，后者要求目标应用没有被排除。若浏览器正常、某个应用始终不通，先检查它是否在名单中，以及关联组件是否属于另一个应用。网页跳转、账号登录或下载可能由系统组件接手，不能假定一次操作始终由同一个应用完成。

为定位名单问题，可以先暂时关闭分应用代理，让目标应用纳入基础接管范围，再停止并重建 VPN 连接后复测。恢复正常说明应回查名单方向或组件范围；仍然失败则继续检查应用独立代理、DNS、目标服务和 UDP 支持。不要同时开启多套筛选规则来试错，规则越多，越难判断流量为何被排除。工作资料与普通用户环境可能有独立应用实例，也需要分别确认系统允许的接管范围。

网络切换后重建连接，再检查内核兼容性

无线网络与移动数据切换会改变本地地址、路由和可达路径，已有连接不一定立即恢复。先停止连接，等待系统网络稳定，再重新启动并做一次真连接测试。若只有某种网络失败，回到节点超时与 DNS 章节，不要反复重装应用。开启绕过局域网地址后，本地设备访问应单独验证；这一选项解决本地目的地址的选路，不负责让互联网节点恢复，也不能替代分应用代理。

安卓优先使用 v2rayNG；需要 v2fly 内核配置时，可按具体兼容需求选择 v2flyNG。两者都应从安卓安装包入口按设备架构选择，切换前保留原订阅与必要设置，不要让两套 VPN 同时竞争。若问题来自协议扩展，向服务方确认配置面向的内核，比直接复制全部高级选项更可靠。最后按VPN 授权与后台设置笔记复核，并测试锁屏、网络切换和主动停止三种状态，确认恢复不仅发生在刚点连接的那一刻。