V2Ray 故障排查

无法上网

“客户端已启动”只说明图形界面正在运行，不代表内核、服务器连接和应用代理都已建立。排查时先区分三个范围：关闭代理后也无法联网；只有启用代理后无法联网；只有某个应用或网站异常。三者的检查入口不同，直接更换协议或反复安装通常不能缩小范围，还可能覆盖原本可用的配置。

先确认基础网络和故障范围

在 v2rayN 托盘菜单清除系统代理，再退出客户端，用浏览器打开平时能够直连的网站。同时确认无线网络已连接、网关可达，公共网络的登录认证已经完成。若此时仍无法联网，应先处理系统网络、路由器或上级网络问题。安卓端则先停止 VPN，再测试无线网络和移动数据，不要把底层断网误判成订阅失效。

基础网络正常后重新启动客户端，只选择一个当前有效的服务器进行测试。不要同时运行两套代理客户端，也不要一边启用桌面系统代理、一边保留另一个工具的虚拟网卡接管。多个入口并存会让请求进入不同路径，出现浏览器能开、其他应用超时，或者退出某个程序后整个系统突然恢复的现象。

检查内核、本地监听和应用入口

打开客户端日志，先看内核是否成功启动，再看发起访问时是否产生新记录。出现配置解析失败、无法绑定地址或端口已占用时，应先解决本地启动问题；此时测试远端服务器没有意义。若内核正常运行，但打开网页完全没有相关记录，优先检查应用是否使用系统代理、是否配置了独立代理，以及当前监听端口是否一致。

下面的 Windows 示例直接指定本地 HTTP 代理，用于把浏览器设置从测试中移开。示例端口为 10808，执行前必须核对参数设置中实际启用的 HTTP 或混合监听端口；若该端口仅接受 SOCKS，应换用对应协议。目标地址只是标准示例域名，不代表所有网络都能访问它。

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

如果提示无法连接到本地地址，检查监听是否存在；如果已连接本地代理后发生远端超时，再转入节点超时排查。收到目标站点的 HTTP 响应，哪怕是拒绝访问或不允许该请求方法，也说明这一次请求已经到达响应方，但不代表所有网站或全部协议都正常。不要只凭命令退出码判断整条链路。

把路由问题与连接问题分开

本地代理测试能收到响应，而浏览器不能访问时，重点检查浏览器代理扩展、系统代理和安全软件的网络过滤。若仅部分域名异常，先查看这些域名匹配直连还是代理规则，再检查 DNS。可以临时选用明确的代理路由作对照，完成测试后恢复原规则；不要同时修改 DNS、路由和服务器，否则无法确认究竟是哪项改动起作用。

最后做一次完整复测：直连正常、本地代理能响应、浏览器按预期接入、目标域名使用正确出口。记录是哪一层失败，再进入对应章节。若只有特定网站返回账号限制、地区限制或业务错误，应按站点返回内容处理；这与客户端完全无法联网不同，也不应通过持续切换设置来掩盖真实原因。

节点连接超时

超时表示某个阶段没有在等待期限内完成，不等于服务器一定离线。客户端可能正在等待域名解析、建立 TCP 连接、完成安全握手，或等待测试目标响应。先保存同一时间段的日志，找出最早出现的错误，再看后续连锁报错。最后一行的笼统超时往往只是结果，前面的解析失败或握手错误才是定位依据。

区分测试类型和失败阶段

Tcping 通常只测试服务器地址和端口的 TCP 建连情况，不会完整验证认证信息、传输层设置或目标网站访问。真连接延迟会通过代理链路请求测试地址，结果又会受到测试目标本身影响。因此 Tcping 有结果但网页打不开并不矛盾；反过来，服务器不响应普通 ICMP 请求，也不能据此认定代理不可用。

先确认服务器条目仍来自当前订阅，而不是很久以前复制出的独立条目。查看地址、端口与协议是否完整，核对是否误选了同名但不同分组的记录。若近期修改过服务端参数，应重新更新订阅或按完整参数重建条目，不要只改地址而沿用旧的传输设置。更多测试边界可参考延迟测试原理说明。

按日志类型检查参数

使用 TLS 时，服务器地址与用于握手的服务名称可能不是同一项，不要把界面中的地址字段机械复制到所有名称字段。检查系统日期、时间和时区，时间偏差会影响证书有效期判断。遇到证书错误应核对配置来源和服务端证书，而不是直接启用跳过验证；后者可能让连接看似恢复，却保留错误的身份验证配置。

使用 REALITY 时，需把服务端要求的公钥、短标识、服务器名称及相关流控设置作为一组核对。空白字符、复制不完整或使用了另一台服务器的参数，都可能让底层端口可达而握手失败。字段是否必填取决于服务端配置，不能照着其他条目补值。基础含义见REALITY 术语解释。

用可控对照缩小网络范围

同一条目在无线网络失败、移动数据正常，说明应优先比较网络路径、解析结果和网关策略，而不是立刻重装客户端。不同测试之间保持服务器、协议和目标地址一致；切换网络后重新建立连接，避免旧连接继续使用原路径。若所有条目同时失效，还要检查本机防火墙是否刚更新了应用规则。

只有一条服务器持续失败，而同分组其他服务器正常时，问题更接近单条配置或服务端。确认订阅已更新后，把错误发生时间、错误阶段和脱敏日志交给配置提供方。不要发送完整订阅地址，也不要公开认证字段。若需要对照内核能力，先阅读内核选型说明，不能把更换内核当作修复任何超时的通用手段。

延长超时只能用于确认慢响应，不能修复地址错误、端口未监听或握手参数不匹配。每次调整后使用同一测试目标复测，并保留原结果。若日志显示代理已经建立而测试站点迟迟不返回，应换一个明确可用的测试目标交叉验证，避免把测试服务故障当成整个服务器不可用。

订阅更新失败

订阅更新包含下载内容、解析格式、写入分组三个环节。显示更新失败，可能是地址无法访问，也可能已经下载到内容，但返回的是登录页、错误页或不兼容的配置格式。先保留现有条目，不要急着删除整个分组。已有服务器仍能使用时，删除后再重建可能让后续诊断失去可用的连接入口。

核对地址与分组设置

打开订阅分组设置，确认地址是完整的一行链接，没有把说明文字、引号、换行或结尾空格一并粘贴。订阅地址通常包含个人访问凭据，应当按密码保存，不能放进公开截图或在线转换网站。核对时只查看结构是否完整，不要为了让别人判断而直接发送原文；需要协助时可以描述返回状态和错误类型。

检查正在更新的分组是否就是当前查看的分组。多个分组同名时容易误判“更新后没有变化”，可先改成能够区分用途的名称，再逐个更新。若客户端提供启用开关、更新地址或过滤选项，也要确认分组没有被禁用，且筛选条件没有把所有条目排除。分组显示为空不一定代表网络请求失败。

分别尝试直连更新和经代理更新

部分订阅地址在当前基础网络可以直接访问，部分则需要现有代理连接。按客户端提供的更新方式分别测试，注意两次测试只改变请求路径。选择经代理更新之前，必须先有一条能够工作的服务器；如果现有代理已经失效，再依赖它更新订阅，就会形成无法自行恢复的循环。

浏览器能够打开地址，但客户端仍失败时，不要直接认定客户端异常。浏览器可能保留了登录 Cookie、使用独立代理，或自动经过认证跳转；客户端请求通常不会继承这些状态。检查地址是否由服务方明确作为客户端订阅入口提供。返回需要交互登录的网页，不能等同于可被客户端读取的订阅响应。

如果能看到响应状态，认证失败通常需要重新取得有效地址；请求过于频繁则应停止连续刷新，按服务方说明稍后再试。服务端错误应结合相同时间段的其他访问结果判断。不要把所有状态都解释成客户端版本过旧，也不要使用浏览器扩展持续重试，这可能进一步触发服务端的访问限制。

确认格式与写入结果

常见内容包括按行排列的分享链接、经过编码的链接集合，以及面向特定内核的原生 JSON。文件扩展名和网址后缀不能保证格式正确，订阅接口也可能根据请求返回不同内容。拿到原生配置时，应使用客户端对应的配置导入入口，而不是默认所有 JSON 都能作为普通订阅分组更新。详见订阅格式与转换说明。

更新提示成功但没有服务器时，先切回“全部”或清除列表搜索条件，再检查订阅过滤表达式、条目协议支持情况与日志中的解析提示。单节点分享链接和可重复更新的订阅地址不是同一种资源；前者适合导入单条配置，不能仅因看起来是一段链接就填入订阅地址栏。相关区别见分享链接与订阅地址。

确认地址已过期或被服务方替换后，在原分组中更新地址，再执行一次更新并观察条目变化。若要新建分组作对照，保留旧分组直到新条目通过连接验证，避免两个分组同时自动更新造成混淆。问题解决后撤销临时过滤和重复分组，恢复合理更新频率，并保留最近一次可用配置的私密备份。

连接正常但速度慢

速度慢需要先明确表现：网页首次打开慢、文件持续下载慢、视频间歇停顿，还是只有某个应用响应慢。首次打开涉及解析、连接和握手，持续传输则更受带宽、丢包、拥塞与服务器负载影响。把这些现象混在一起比较，容易得出“延迟低就一定下载快”的错误结论，也容易把网站自身限速归到客户端。

建立能够复现的对照条件

测试时固定设备、网络、服务器和目标站点，暂停系统更新、云盘同步与其他大流量任务。无线网络信号弱或同一频段拥挤时，先靠近路由器或换用有线连接对照。若直连同类资源也慢，应先处理本地网络；只有经过代理明显变慢时，再检查代理链路。不同日期、不同资源的结果不能直接作为同一条件比较。

不要同时对所有服务器执行下载测速。并发测试会争用本地带宽、增加服务端压力，还会让本来稳定的连接表现成波动。每次选择少量候选，按相同顺序逐个测试，并在两次测试之间留出恢复时间。记录开始时间、网络类型和资源来源即可，不需要把某次瞬时峰值当成长期可用能力。

分别观察建立连接和持续传输

若每个网页第一次打开都慢，但打开后图片和文件加载正常，重点观察 DNS、握手、连接复用与路由规则；若开始很快、持续下载逐渐下降，则要比较无线网络稳定性、长连接质量和远端限速。浏览器开发工具中的等待阶段可以辅助判断，但缓存、站点脚本和第三方资源会影响结果，应先用结构简单的页面作对照。

Tcping 测到的是一个较早阶段的连接特征，真连接延迟包含更多代理过程，下载测试才会施加持续流量。这三项不能彼此替代。某个服务器测试延迟较高，仍可能有更稳定的持续吞吐；某个服务器建连很快，也可能在繁忙时段传输受限。选用时应围绕实际应用需求，而不是仅按一列数值排序。

检查分流、重复接管与传输设置

只有部分资源慢时，检查主页面与图片、视频资源是否匹配了不同的路由。网页可能同时访问多个域名，其中一部分走代理，另一部分直连；界面显示已连接并不能说明整页使用相同出口。临时用统一路由做一次对照有助于定位，确认后再修正规则顺序，不应长期依赖一条覆盖全部流量的临时规则。

同时启用系统代理和虚拟网卡接管时，要确认内核自身出站不会再次被代理。重复接管、错误的上游代理或链式配置可能增加额外往返，严重时形成回环。不要为了测速同时开启所有模式。对于普通浏览器测试，先使用单一明确入口；确有不遵循系统代理的应用需求，再单独验证虚拟网卡模式。

传输层参数必须与服务端配套。随意启用多路复用、修改传输协议或套用其他人的连接参数，并不会自动增加带宽，反而可能导致兼容问题。若怀疑路径的报文大小异常，应先依据特定症状和网络环境逐步测试，记录原值并一次只改一项；不要在没有依据时复制整套系统网络“优化”配置。

最后区分可调整项与外部限制：客户端可以修正错误路由、解析和接管方式，却无法保证服务端负载、目标站点策略或上级网络始终不变。如果多次固定条件测试都指向同一远端路径，应把时间段与现象交给配置提供方处理。恢复所有临时测试设置后，再用日常应用确认稳定性，而不是持续运行测速。

DNS 与域名解析

DNS 问题常表现为域名打不开、同一服务时好时坏，或者日志在连接前就报告名称解析失败。需要区分服务器域名的解析与目标网站域名的解析：前者决定客户端能否找到代理服务器，后者决定请求如何到达目标站点。两者可能由不同解析器、不同路由处理，不能只修改一个系统 DNS 就认为所有环节都已改变。

先判断解析发生在哪一层

服务器地址填写域名时，连接建立之前就必须得到可用地址。如果这一阶段依赖的解析路径本身又要求代理可用，就可能形成启动依赖循环。应先确认基础网络能够解析服务器域名，再检查客户端 DNS 设置中的引导路径。不要简单把服务器域名替换成随手查到的地址，服务端可能使用动态地址或依赖正确的握手名称。

目标域名可能在应用、本地系统或代理内核中解析，取决于应用代理协议和客户端配置。SOCKS 请求也有本地解析与交由代理解析的差别，因此浏览器能打开不代表命令行一定采用相同方式。排查时记录使用的是 HTTP 代理、SOCKS 代理还是虚拟网卡模式，再依据日志确认名称在哪一层被转换成地址。

可以用系统命令检查基础解析是否返回结果，但这只验证系统解析路径，不代表内核 DNS 的最终结果。下列命令使用示例域名；测试真实故障时替换为出现问题的公开域名，避免把包含账号或访问凭据的完整链接粘贴进命令。检查结果时还要注意是否同时返回了不同地址族。

nslookup example.com

检查加密 DNS、地址族和缓存

浏览器的安全 DNS 设置可能绕开系统解析器，客户端也可能单独配置加密 DNS。为了建立可比较的测试路径，可暂时让浏览器跟随系统设置，再观察故障是否变化；测试结束后按实际需求恢复。解析服务能否访问与返回地址是否适用是两件事，服务端没有响应时，连续更换解析地址也未必能解决路由问题。

部分域名同时返回 IPv4 和 IPv6 地址，而当前网络对两种地址族的可达性不同。若日志显示持续尝试不可达的地址族，应对照系统网络状态和客户端的域名解析策略。临时限制地址族可以帮助定位，但不应把永久关闭某一种协议作为所有设备的通用方案；最终设置应匹配实际可用网络与服务器能力。

修改解析设置后，旧结果可能仍存在于浏览器、系统和内核缓存中。先关闭旧标签页或重启相关应用，按需重启客户端，再进行同一域名的测试。Windows 可使用下面的命令清理系统解析缓存，但它不会清空所有应用缓存，也不会修复错误的上游解析器。不要反复清理缓存来替代对错误路径的检查。

ipconfig /flushdns

让 DNS 路径与路由保持一致

直连流量和代理流量可能适合不同的解析路径。若直连请求得到只适用于另一网络出口的地址，连接会失败或变慢；若远端解析请求被错误地送到无法访问的出口，也会产生超时。先检查 DNS 请求自身如何出站，再检查域名匹配规则，避免只盯着最后返回的地址而忽略查询过程。

虚拟网卡模式下，还要检查系统 DNS 是否经过客户端预期的接管路径，以及其他 VPN 是否改写了同一设置。若启用了虚拟地址映射一类机制，应保证解析和后续连接由配套规则处理，不能只复制其中一项配置。普通订阅导入用户优先从客户端图形设置排查，避免直接编辑自动生成的运行配置。

修复后至少验证三个方面：服务器域名能够解析、目标域名得到响应、实际访问命中预期路由。若只有一个域名持续异常，比较其权威记录变化、站点状态及不同网络结果，再决定是否需要单独规则。DNS 不是所有连接错误的总开关，解析成功之后仍可能存在端口、握手和目标服务故障。

系统代理不生效

系统代理是操作系统提供给应用读取的一组代理设置，并不是对所有流量的强制转发。浏览器通常能够遵循这些设置，但部分终端工具、游戏和带独立网络模块的应用不会自动使用它。因此“浏览器正常、某个应用不通”应先检查应用入口，而不是把路由切到全局后继续等待；路由只能处理已经进入客户端的请求。

确认监听端口与系统设置对应

在 v2rayN 参数设置中查看本地监听地址、端口及支持的代理协议，再打开系统代理设置核对。不同配置可能使用不同端口，不应把教程示例当成当前设备的固定值。本机应用通常连接回环地址；地址写成另一台设备、端口写成远端服务器端口，都会让系统设置看似已经启用却无法连接本地入口。

下面的 Windows PowerShell 命令可检查示例端口是否有 TCP 监听。若没有输出，先确认客户端内核已启动以及端口是否与实际设置一致；若有输出，可进一步核对所属进程。存在监听只证明有程序占用了这个端口，不能单独证明它就是期望的代理，也不能说明远端服务器可用。

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

如果其他程序占用了端口，可在明确用途后关闭冲突程序，或修改客户端监听端口并同步更新应用代理设置。不要只改客户端而保留系统中的旧端口。也不要为了本机访问把监听地址扩大到全部网卡；允许局域网连接涉及额外访问边界，与修复本机系统代理不是同一件事。

分清手动代理、自动配置与应用独立设置

手动代理与自动配置脚本是不同机制，系统界面中可能同时保留相关字段。客户端的模式名称也不能简单等同于操作系统某一个开关，应以实际写入的地址、端口或脚本地址为准。切换模式后关闭并重新打开测试应用，避免旧进程继续复用已建立的直连连接，从而误判设置没有生效。

浏览器扩展、企业策略以及应用自己的代理选项，可能覆盖系统设置。先停用代理类扩展作对照，再检查应用是否选了“不使用代理”或固定的其他地址。某些命令行程序读取环境变量而不读取桌面系统代理，另一些 Windows 组件又使用独立的代理配置来源；不能要求一个托盘开关同步改写所有环境。

检查退出残留与虚拟网卡接管

客户端异常退出后，系统代理可能仍指向已经停止监听的本地地址，表现为退出客户端反而所有网页都打不开。此时在系统设置中暂时关闭残留代理，确认直连恢复，再启动客户端并重新设置。不要先删除网络适配器或重置整个系统网络；简单的残留地址问题不需要用破坏性操作处理。

确实需要接管不读取系统代理的应用时，可按客户端文档评估虚拟网卡模式。该模式可能涉及权限、路由与 DNS 接管，启用前先确保普通本地代理链路可用，再单独测试。不要把权限提升当作所有系统代理问题的解决办法，只有明确的权限报错或接管需求才需要对应授权。

最终验证应覆盖设置层和流量层：系统界面显示正确地址，客户端端口实际监听，应用发起请求时产生日志，目标访问按预期完成。只看到托盘菜单勾选不能证明这四项成立。完成后退出客户端再检查系统是否恢复预期状态，避免下一次启动前因残留设置再次出现同样症状。

客户端崩溃与启动失败

启动异常首先区分图形界面没有打开、界面打开但内核退出，以及运行一段时间后整个程序关闭。三种情况涉及不同层级：图形运行环境、生成配置或核心网络进程、系统资源与后台软件。先记录触发动作，例如启动即退出、更新订阅后退出、启用虚拟网卡后退出，再寻找对应时间的日志，不要只描述“不能用”。

先排除包类型、权限与运行环境

从客户端下载页按系统和处理器选择对应包。Windows 的桌面版与经典 WPF 版使用不同界面技术，所需运行环境应以实际包提示为准；不能把某一种运行环境当成全部包的共同要求。macOS 要区分 Apple Silicon 与 Intel，Linux 则同时考虑处理器架构和发行版包格式，避免把架构不匹配误当成配置损坏。

如果使用需要解压的文件，应完整解压到有写入权限的位置后再运行，不要从压缩包预览窗口直接启动。确认依赖文件与主程序位于预期目录，工作路径没有被清理工具移走。若安装或首次启动被系统安全机制阻止，先阅读系统给出的具体原因，通过系统提供的应用授权流程处理，不要直接关闭整机防护。

出现明确的运行环境缺失提示时，按提示核对系统架构与所需组件；出现文件访问失败时，检查目录权限、磁盘空间和配置文件是否被其他程序占用。把整个目录放进云同步位置可能引入锁定或同步冲突，排查时可复制到本地普通目录测试，但要保留原目录，并避免同时启动两份实例写入同一配置。

区分界面故障与内核配置错误

图形界面仍在、只有内核反复退出时，先看日志是否指出不支持的字段、无效的协议组合、端口占用或规则文件缺失。最近刚启用自定义配置、路由或 DNS 的，应先撤回该项改动。普通订阅用户不宜直接修改自动生成的运行配置，因为下一次应用设置时可能被覆盖，也容易让图形界面状态与实际配置不一致。

如果确实在排查原生 JSON 的语法，下面是合法的最小 JSON 示例，仅用于理解对象、数组、逗号与布尔值写法，不是可以直接建立代理连接的完整内核配置。检查时特别注意末尾多余逗号、中文标点和字符串引号；配置语法正确，也不代表其中的协议字段符合当前内核要求。

{
  "log": {
    "loglevel": "warning"
  }
}

涉及内核兼容性时，先确认条目要求的协议能力，再比较客户端实际使用的内核。v2rayNG 与 v2flyNG 的内核家族不同，不能只改应用名称便认为参数必然兼容。相关背景见Xray 与 V2Fly 内核区别。诊断时避免把来历不明的核心文件直接覆盖进客户端目录。

通过隔离配置判断是否损坏

怀疑用户配置损坏时，先退出所有实例，备份配置、订阅分组与自定义规则，再按客户端支持的方法使用新的用户配置目录测试。不要直接删除原目录。新配置能够启动，只说明问题更接近旧配置或扩展设置；随后分批恢复订阅、路由和其他设置，观察哪一步重新触发故障，而不是一次把全部旧内容覆盖回来。

如果在干净配置下仍稳定复现退出，检查系统事件记录、剩余存储、内存压力及安全软件拦截记录。Linux 桌面启动失败还应核对图形会话和包依赖，macOS 则关注系统授权提示。按触发条件收集证据后，再决定更新或重新安装。覆盖安装未必清除损坏的用户配置，因此不能把“重装后仍失败”直接归为软件本身异常。

恢复运行后，先用一条已知配置验证普通代理，再逐步恢复复杂功能。保留可复现步骤、错误原文和已排除项目，比连续尝试多个安装包更有助于后续定位。首次安装流程另见桌面首次安装与初始设置，本章主要处理异常状态，不替代日常安装步骤。

安卓连接与后台运行

安卓端先使用 v2rayNG 排查常见连接问题；需要 V2Fly 内核能力时再评估 v2flyNG。两款应用都要区分服务器配置与系统 VPN 通道：状态栏出现 VPN 标记，只能说明系统通道已建立，不代表服务器握手成功。若图标正常但无法访问，仍需按本地接管、节点连接、路由和 DNS 的顺序检查。

核对 VPN 授权和网络状态

首次启动连接时，系统会要求确认 VPN 授权。若误拒绝，应再次发起连接并按系统提示授权；受工作资料、设备管理策略限制的设备，则需要遵循相应管理要求。不要反复清空应用数据来绕过授权问题，这会同时删除订阅和自定义设置。先停用其他 VPN 应用，确认当前配置没有被另一条 VPN 通道替代。

公共无线网络可能要求先登录认证页面。连接 VPN 前先停止代理并完成网络登录，再重新建立连接。无线网络切换到移动数据后，旧连接可能仍等待超时，可停止后重新连接，并观察日志是否使用了新网络。若只在其中一种网络失败，保持同一服务器与设置作对照，避免边切网络边更换节点而失去判断依据。

系统的始终开启 VPN 与阻止不经过 VPN 的连接，是独立于应用界面的设置。若开启了阻止绕过，在 VPN 未连接时，部分流量可能按系统策略被阻断。此时“停止客户端后仍不能联网”不一定是基础网络损坏，应先检查系统 VPN 策略，并根据实际需求恢复，不能仅通过重启手机来回避原因。

分应用代理与 DNS 要配套检查

开启分应用代理后，确认采用的是只代理所选应用，还是绕过所选应用；两种列表的含义相反。测试浏览器如果没有进入预期名单，就可能完全不经过客户端。修改列表后重新建立 VPN，并完全关闭再打开测试应用，避免旧连接保留原路径。不要仅凭应用图标在列表中被勾选，就推断它一定使用代理。

若只有某个应用失败，检查它是否依赖其他组件发起请求，以及是否有独立代理或安全 DNS 设置。主应用与相关组件可能采用不同网络入口，导致登录正常而资源加载失败。先用一个确认进入代理范围的浏览器建立基线，再逐步加入其他应用。安卓配置主线见v2rayNG 使用教程。

启用本地 DNS 或流量嗅探并不会自动修复所有应用问题。嗅探可能帮助路由识别域名，但它不等于解密应用内容，也不能替代正确的 DNS 与协议配置。遇到域名相关错误时，应对照DNS 章节判断解析位置，再一次只修改一项。服务端参数仍必须按完整配置核对，不能照桌面截图随意补字段。

后台断连先查电池与进程限制

锁屏后断开、切回应用又恢复，常见检查项包括电池优化、后台活动限制、流量节省和厂商的自动启动管理。按系统提供的应用设置允许必要后台运行，并保留客户端要求的前台服务通知。不同设备入口名称不同，应依据系统实际界面查找；不需要为了一个客户端关闭所有应用的电池管理。

若允许后台运行后仍中断，记录断开是否发生在切换网络、长时间空闲或系统清理内存之后。保持屏幕开启做一次对照，区分网络空闲回收与进程被终止。日志停止写入、VPN 图标消失和服务器重连失败代表不同线索，应分别记录。单纯提高重连频率可能增加耗电，却不能解决系统持续终止进程的问题。

需要重新安装时，先备份订阅与自定义规则，再从安卓下载入口选择匹配处理器的包；不要把更换安装包与修改协议同时进行。最终复测应包含前台访问、锁屏后恢复、无线网络与移动数据切换。若仍失败，整理设备系统、应用名称、触发步骤和脱敏日志，再回到对应故障章节继续缩小范围。