V2Ray 故障排查大全

无法上网：先确认请求走到哪一层

“连接成功”通常只说明客户端启动了内核或建立了本地服务，并不表示浏览器请求已经到达目标网站。排查时把路径分成应用、本地入站、路由选择、远端出站和目标服务五层。先关闭其他代理程序，选择一个固定网站重复测试，同时打开 v2rayN 的日志区域。不要一开始更换协议、改 DNS、启用 TUN 并重置路由；这些动作同时发生后，即使恢复连接，也难以判断真正原因。

基础网络与本地监听

先清除系统代理，再访问平时可以直接访问的网站。若仍失败，检查无线连接、网关、门户认证与系统时间，必要时在同一设备上换用另一条网络。完成网页认证后重新启动客户端连接。基础网络恢复前，代理日志中的超时通常没有独立诊断价值。若关闭客户端后所有浏览器都失去连接，还应检查系统是否遗留了指向本机端口的代理设置，而不是立即认定远端服务器异常。

接着在 v2rayN 中选择目标服务器作为活动服务器，观察是否出现内核启动错误。进入相关设置核对本地监听地址与端口，再确认浏览器或系统代理使用相同端口。不要按网上截图假定端口固定：不同配置、不同入站类型可以使用不同值。若日志提示端口占用，先退出其他客户端，再重新启动内核；确需更换端口时，必须同步修改使用该端口的应用，否则本地服务正常也接不到请求。

以日志判断入口与出站

重新打开网页，观察这一时刻是否新增连接日志。没有新增记录时，优先检查应用入口：浏览器扩展是否覆盖系统代理，应用是否使用独立代理设置，目标地址是否落在系统绕过列表。日志是否记录连接也受日志级别影响，不能只凭一个空白窗口下结论；先确认正在查看当前内核的日志，并临时开启能够观察连接的级别。完成定位后恢复原日志级别，避免持续产生大量记录。

如果连接进入内核，却被分到 direct，检查状态栏路由模式和自定义规则顺序。路由通常按顺序寻找匹配规则，宽泛的直连规则放在前面可能遮住后面的代理规则。可暂时切换到全局代理模式作对照，确认是否属于分流问题；测试完成后恢复原模式。“全局”是客户端路由选择，不代表系统中每个程序都会自动接入，未使用本地代理的应用仍可能完全绕开客户端。

区分整条路径故障与单站异常

若多个不同网站都失败，沿节点连接与 DNS 章节继续排查；若只有一个站点异常，先换浏览器新建会话，检查该站点是否正在维护、是否要求登录，以及其静态资源域名是否被另一路由处理。网页文字出现而图片一直等待，往往意味着页面依赖多个域名，不能只检查地址栏中的主域名。将同一时刻的请求与规则对应起来，比反复刷新整页更容易找出差异。

节点超时：拆开地址连接与协议握手

超时表示某一步在等待期限内没有完成，不能仅凭这两个字认定服务器失效。客户端的测试功能可能采用 TCP 连接、经过代理访问测试地址或其他方式，不同测试衡量的对象并不相同。先查看功能名称与日志，再用浏览器真实请求复现。若测试地址本身不可用，节点列表的测试结果也可能全部异常；不要据此批量删除服务器或覆盖原有订阅。

先确认地址、端口与连接阶段

在服务器编辑窗口检查地址是否完整、端口是否为服务提供方给出的值，复制时有没有带入空格或换行。地址为域名时，还要确认系统可以解析这个域名。日志中若在连接远端地址时就超时，排查重点是网络路径、服务器可达性与端口；若已经建立连接，随后才出现 TLS 或认证错误，则应转向传输安全与协议参数。把这两类错误混在一起改设置，通常只会延长定位时间。

同一设备切换另一条网络，是区分本地网络限制与服务器问题的有效对照；同一网络换用另一条已知可用的配置，则有助于判断故障是否集中在某个服务器。对照时保持客户端、目标网站与路由模式不变。若在企业网络内测试，先确认是否需要门户认证或经过指定出口，并遵守网络使用规定。不要为了通过测试随意开放系统入站防火墙，出站连接失败与本地服务对外开放不是一回事。

TLS、传输与 REALITY 参数

连接建立后出现证书相关报错，先校准设备日期、时间与时区，再检查服务器名称设置是否与配置来源一致。TLS 的服务器名称与连接地址可以不同，但不能凭经验互相替换。证书链不被信任、名称不匹配与握手超时属于不同分支，应根据完整错误文字处理。关闭证书验证并不是常规修复步骤，它可能隐藏配置错误，也会削弱连接身份验证；应修正名称、时间或服务端证书条件。

使用 WebSocket 或 gRPC 时，逐项比对传输类型、路径、Host 或服务名称。路径大小写、开头的斜线和服务名称中的字符都可能影响匹配，端口能够连接并不意味着这些参数正确。通过分享链接导入后仍应检查字段是否被完整识别；如果来源格式超出客户端支持范围，界面中可能出现缺项。不要把“传输类型”当成可以任意切换的加速选项，客户端与服务端必须使用相容配置。

VLESS 搭配 REALITY 时，需要核对服务端指定的服务器名称、公钥、短标识以及对应的流控要求；这些字段承担不同作用，不能互相代替。还应确认所选内核支持当前组合。v2rayNG 与 v2flyNG 的内核家族不同，不应假定同一分享链接在两者中都能等价执行。最稳妥的恢复方法是重新取得有效配置，完整导入后测试，而不是从不同教程里拼接几组看似相同的字段。

重试节奏与结果记录

连续快速重载可能让短暂网络恢复、服务端连接限制和旧进程退出过程交叠。每次修改后等待内核完成启动，只发起一次明确请求，再看对应时间段的首个错误。若多个错误连在一起，通常应先处理最早出现的失败，后面的连接关闭可能只是结果。记录“哪条网络、哪个服务器、哪个目标、停在哪一步”，并保留一份可用配置作回退，比单独截图一个超时提示更有帮助。

向配置提供方反馈时，可说明连接远端失败还是 TLS 后失败，并附上隐藏敏感内容后的日志片段。不要发送完整订阅链接或认证字段。若其他服务器可以稳定工作，而该配置在不同网络下始终停在同一握手阶段，继续修改本机路由的收益很低；此时应确认远端服务状态与配置有效期。常见字段含义可结合FAQ阅读，避免把网络超时与协议不兼容视为同一个问题。

订阅失败：区分获取失败与内容解析失败

订阅更新包含两个独立步骤：先从订阅地址取得响应，再把响应解析为客户端可识别的服务器记录。提示“更新失败”时，先看日志是否有连接、证书、状态码或解析错误。地址能在浏览器打开，也不保证响应就是订阅；浏览器可能显示登录页面、验证页面或账号到期通知。不要把网页内容另存后反复导入，也不要因为一次获取失败就删除仍然可用的服务器记录。

核对订阅地址与获取路径

进入订阅分组设置，检查地址是否完整，尤其注意末尾参数、复制时混入的空格，以及消息软件把长链接截断的情况。订阅地址常带有账号访问权限，应当作为敏感信息保存。若曾把链接公开到截图或讨论区，应在服务提供方允许的情况下重置链接，再更新本地分组。普通网页地址、用户控制面板地址与订阅接口不是同一个对象，必须使用来源明确提供的订阅入口。

在 v2rayN 中，可依据当前网络条件尝试“更新订阅(不通过代理)”与通过代理的获取方式，具体名称以界面为准。直连失败但代理可用时，可以借助已有可用服务器更新；代理已经失效时，继续依赖该代理获取订阅可能形成循环。先保留原分组，使用明确可行的路径重试。企业网络中的网页认证或本机网络尚未就绪，也会让订阅请求返回与预期不同的内容。

根据响应类型选择处理分支

如果日志记录了 HTTP 状态码，应区分权限拒绝、地址不存在、请求限制与服务器错误。权限问题通常需要确认订阅是否失效、参数是否完整；请求过于频繁则应停止连续点击，等待后再试。证书错误先检查设备时间和本地信任环境。切勿把错误状态码全部解释为“客户端太旧”，也不要为了下载订阅而随意忽略证书验证，这样会掩盖获取路径上的实际异常。

内容格式方面，分享链接集合、经过 Base64 编码的订阅与原生 JSON 配置不能仅按文件扩展名判断。Base64 是编码形式，不代表一定包含正确的服务器信息；原生内核 JSON 也不一定适合粘贴进普通订阅输入框。应使用客户端对应的导入入口，确认支持的数据结构。若只是一条分享链接，先用剪贴板导入测试其可识别性，可以将格式问题与远程获取问题分开。

更新后的分组与活动服务器

更新成功后，检查目标分组中是否出现预期记录，再重新确认活动服务器。订阅更新可能改变记录名称或移除已撤下的配置，旧的选中项未必继续有效。不要只看“更新成功”提示就认为连接已恢复。先选择一条记录，启动连接并访问固定网站，再判断是否需要进一步检查握手参数。多个分组名称相似时尤其要核对正在更新、查看与连接的是否为同一个分组。

自动更新间隔不宜设置得过于激进。频繁拉取不会修复错误地址，反而可能触发接口请求限制；定时更新还可能恰好发生在休眠唤醒或网络切换时。手动更新可用而自动更新偶发失败时，先观察失败时间与设备网络状态的关系，不必立即重建所有配置。若需要调整分组结构，先通过客户端导出功能保存可恢复副本，并将副本保存在受保护的位置。

不同订阅格式与转换边界可继续阅读V2Ray 订阅格式详解。排查结束应留下明确结论：是地址权限、获取路径、响应格式还是配置兼容性问题。这个结论决定后续联系谁、修改哪里，也能避免下次遇到相同提示时又从删除客户端开始。

速度慢：分别观察首包、持续传输与应用差异

“速度慢”可能指打开网页前等待很久、图片断续加载、文件传输不稳定，或视频播放反复缓冲。这些现象对应的瓶颈并不相同。先描述慢发生在哪个阶段，再固定同一设备、同一网络、同一目标与同一服务器测试。不要用一个节点测试结果代替真实应用体验；延迟反映往返或测试请求的耗时，不能直接推导持续吞吐能力，更不能说明某个网站的服务状态。

建立可比较的测试条件

先暂停其他大流量任务，检查设备是否处于省电模式，以及无线信号是否稳定。后台同步、系统更新与其他设备占用出口，会让代理连接看起来忽快忽慢。必要时在同一网络下用有线连接作对照，或者让设备靠近无线接入点后复测。对比时只改变一种条件，避免同时换服务器、换网络和换浏览器，否则无法区分改善来自哪一层。

如果只有首次打开网站慢，后续页面比较正常，重点观察 DNS 查询、连接建立和 TLS 握手。若页面很快出现但大文件持续传输缓慢，则更需要检查出口带宽、远端负载、目标服务限速与链路丢包。若只有某个视频或下载站点慢，用另一类内容作对照；目标服务可能根据出口位置、账号或内容分发节点采取不同策略，这类情况不一定能靠修改本地端口解决。

确认实际路由，避免错误归因

查看慢请求最终走 direct 还是 proxy，尤其注意网站的图片、视频与接口域名。主页面代理、静态资源直连，或相反的组合，都可能出现部分内容等待。若自定义规则过宽，应缩小匹配范围并确认规则位置。临时切换全局模式可用于对照，但不应直接作为长期结论：全局模式改变的是流量路径，不会消除无线干扰、远端拥塞或目标服务本身的等待。

对比两条服务器配置时，保持其他条件不变，并分开记录网页首开与持续传输体验。如果一条在多个目标上都慢，另一条正常，可以优先怀疑该路径或远端资源；若所有配置只对同一个目标慢，应转向该目标的解析与服务策略。不要为了追求某个测试数值而连续重载内核，旧连接中断与缓存重新建立会污染观察结果，造成越测越慢的错觉。

传输参数与网络边界

不要盲目开启多路复用或随意替换传输方式。多路复用是否有益取决于协议支持、连接模式与服务端条件，某些场景还可能把多个请求集中到同一拥塞路径。WebSocket、gRPC 与其他传输也必须与服务端匹配，不能仅在客户端下拉框中切换。遇到网上建议的“优化参数”，先确认适用内核和版本，再备份原配置，以单项对照证明收益，而不是长期保留无法解释的设置。

使用 TUN 时，如果小网页正常而某些大响应或特定应用反复停顿，可留意路径 MTU 与网络对数据包的处理，但这应建立在日志、对照网络和复现条件之上。不要把降低 MTU 当成所有慢速问题的通用操作。先在普通系统代理路径下测试同一目标，若该路径正常，再集中检查 TUN、网卡与网络环境。修改后记录原值，以便确认无改善时恢复。

完成排查后保留一组日常使用的基准条件：固定测试网站、已知可用的服务器配置和正常路由模式。后续异常先与基准比较，而不是重新执行全部优化建议。若表现随着时段变化明显，可记录发生时间并反馈给服务提供方；本地配置保持稳定，才能让这些观察具有可比性。有关分流规则的具体调整，可阅读v2rayN 路由分流配置实战。

DNS 问题：区分应用解析、内核解析与节点解析

DNS 故障常表现为域名打不开、等待后才开始连接，或不同应用得到不同结果。排查前先区分三个对象：操作系统怎样解析域名，客户端内核怎样解析目标域名，以及用于连接远端服务器的域名怎样解析。浏览器还可能启用独立的安全 DNS，使其绕开系统解析路径。修改某一个 DNS 地址并不会自动改变所有层级，必须知道发生错误的查询实际由谁发起。

从错误文字确认解析层级

日志若提示无法解析远端服务器地址，应先修复节点域名的基础解析，否则代理通道尚未建立，依赖该通道的远程 DNS 也无法启动。若远端连接正常，只有目标网站域名失败，则查看目标查询使用的解析器与出站路径。不要把服务器地址直接替换为任意查到的 IP 后就结束排查；某些配置依赖服务器名称、证书与动态地址，替换可能暂时绕开问题，却破坏后续维护。

系统查询工具只能证明系统当前的解析结果，不能证明浏览器或内核采用相同结果。可在终端使用下列命令对照系统解析；其中测试域名是公开示例域名，不涉及账号信息。命令成功后仍需查看应用日志，确认真实连接路径。若系统查询失败但浏览器能打开，可能存在浏览器自己的解析器或缓存；若系统查询成功而客户端失败，则应检查内核 DNS 配置及其出站依赖。

nslookup example.com

路由策略与解析结果的关系

以 Xray 路由为例，domainStrategy 决定路由匹配过程中何时尝试将域名解析为 IP。AsIs 不主动为路由匹配解析域名，IPIfNonMatch 在域名规则未匹配时尝试 IP 匹配，IPOnDemand 会在匹配需要 IP 的规则时尝试解析。这是路由层的策略，不等同于 DNS 服务器列表，也不能与出站中的同名或近似字段混用。改动前应确认所在配置层级。

下面是路由对象的示意片段，需合并到已有、包含对应出站的配置中，不能直接当成完整客户端配置启动。客户端已有图形路由编辑器时优先在界面修改。内核按规则顺序匹配，示例先处理指定域名，再处理私有地址；实际出站标签必须与当前配置一致。域名是否仍以域名形式进入内核，也取决于应用使用的代理协议与解析方式。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["full:example.com"],
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

缓存、加密解析与循环依赖

修改 DNS 后，系统、浏览器与应用都可能保留旧结果，已建立的连接也不会因为更换解析器而自动重建。先关闭相关网页并重建连接，必要时按系统提供的方法清理缓存，再观察新请求。不要在尚未确认查询出口时同时开启多个加密解析功能；浏览器解析、客户端远程解析与系统解析叠加后，结果差异会更难解释，也可能让按域名分流的观察不完整。

使用需要经过代理访问的解析服务时，应特别防止循环依赖：代理服务器域名必须先能解析，代理通道才能建立；通道未建立时，又无法访问依赖代理的解析服务。应根据客户端支持的功能，为启动阶段提供可达的解析路径，并检查解析服务自身域名的处理方式。不要随意把所有 DNS 流量都交给尚未可用的出站，也不要把同一个解析配置机械复制到不同内核。

恢复验证至少覆盖原故障域名与另一类正常网站，同时检查路由是否符合预期。网页恢复访问但所有连接都改变了出口，不算完成分流排查。若日志提示 geosite 或 geoip 数据缺失，则属于规则数据加载问题，应转到启动与崩溃章节检查资源，而不是继续替换解析器。规则前缀与匹配顺序可参阅Xray 自定义路由规则语法。

系统代理不生效：检查应用是否接入本地入站

系统代理与路由模式是两个开关层级。前者告诉支持系统代理的应用把请求交给哪里，后者决定进入内核后的请求走哪个出站。在 v2rayN 中把路由切为“全局”，并不等于操作系统中的所有流量都会被接管。浏览器可以遵循系统代理，命令行工具、游戏与其他应用则可能采用独立设置。先确认故障应用的代理机制，再决定是否需要应用内配置或 TUN。

识别状态栏中的三种选项

“自动配置系统代理”用于写入客户端需要的系统代理设置；“清除系统代理”用于移除相关系统代理配置；“不改变系统代理”表示客户端不主动修改当前状态，不能理解为自动关闭代理。若之前遗留了错误设置，选择“不改变”可能继续保留错误路径。测试时先记下原有设置，避免覆盖公司网络或其他软件所需的配置，再明确切换到本次测试所需的选项。

进入系统网络设置核对代理地址与端口，不要只看客户端状态栏是否点亮。若系统值与界面预期不一致，可能有其他代理软件、浏览器扩展、自动配置脚本或管理策略在写入设置。一次只运行一个代理客户端，暂时停用接管代理的浏览器扩展，再重新测试。受管理设备上的代理策略可能由组织统一下发，遇到设置自动恢复时应确认管理要求，而不是反复强行覆盖。

手动接入与环境变量

对支持手动代理的应用，可临时填写当前客户端实际提供的本地地址与端口进行对照。HTTP 入站应按应用支持的 HTTP 代理方式使用，SOCKS 入站则对应 SOCKS 设置；两者不能仅凭端口相似就互换。监听地址限定在本机时，其他设备不能直接连接这个端口。排查本机问题不需要开放局域网访问，也不应将监听改为所有网络接口作为常规修复办法。

命令行程序可能读取 HTTP_PROXY、HTTPS_PROXY 或 ALL_PROXY 环境变量，也可能完全忽略它们。图形界面更改系统代理后，已打开的终端未必刷新进程环境。若只有命令行失败，检查工具自己的代理说明与当前环境变量；若只有浏览器失败，检查扩展、配置文件与独立代理设置。不要据一个应用的行为推断整个系统状态，应用间差异正是定位入口的线索。

TUN 与退出后的恢复

TUN 是另一种流量接入方式，可能涉及虚拟网卡、路由表、权限与 DNS 接管，不是系统代理选项的别名。系统代理路径本来可以工作时，应先完成该路径的基线测试，再决定是否排查 TUN。两个机制同时启用且配置不清楚，可能使部分流量绕路或产生回环。涉及权限提示时只授予所需权限，不要把整个客户端长期以高权限运行当成唯一解决方案。

如果退出客户端后网络立即失效，检查系统代理是否仍指向已停止监听的本地端口。重新打开客户端并执行“清除系统代理”，再在系统网络设置中确认恢复；还要排除独立应用中的手动代理。强制结束进程、系统异常关机或软件冲突都可能打断退出清理，因此恢复时应先处理遗留设置，再讨论是否重新安装。重装程序未必会清除系统中独立保存的代理参数。

验证时用同一个浏览器发起新请求，确认日志能看到对应连接，再检查出站标签是否符合路由预期。入口恢复但走错出站，应回到分流规则，而不是继续改系统代理。不同桌面环境对代理设置的支持范围也不完全相同，特别是 Linux 应用可能采用各自的网络栈；必要时在应用内显式配置。初次操作可结合使用指南建立可重复的接入流程。

启动与崩溃：分开检查界面、内核和配置资源

客户端窗口打不开、窗口打开后内核启动失败、连接一段时间后进程退出，是三个不同问题。先记录故障发生时机：双击程序立即退出，选择服务器后出现报错，还是某次订阅或规则更新后才异常。v2rayN 的图形界面与代理内核承担不同职责，界面能够正常显示不代表内核已运行；同样，内核退出也不一定是整个客户端崩溃。应分别查看应用提示、核心日志与系统错误记录。

安装包、架构与运行环境

先确认安装入口与设备系统、处理器架构一致。桌面首推 v2rayN，Windows 的桌面版与经典 WPF 版界面及运行环境要求有所区别；macOS 与 Linux 也应选择适合芯片和发行版的入口。需要重新获取程序时，使用客户端下载页核对平台说明。不要凭文件图标判断架构，也不要从旧目录里随意抽取单个可执行文件替换，以免形成程序与附带资源不匹配的组合。

程序依赖运行环境时，应根据安装提示和系统错误信息补齐对应组件，而不是下载名称相近的任意组件。检查安装位置是否可写、可执行，是否位于受限制目录，以及安全软件是否拦截了程序或资源。查看拦截记录后再决定如何处理，不要直接关闭整个安全防护。Linux 还应检查文件权限与桌面启动入口，macOS 则按系统给出的安全与权限提示确认程序来源和允许方式。

从第一条错误定位内核启动失败

核心日志提示监听失败时，通常先检查地址或端口占用；提示解析配置失败时，检查 JSON 语法、字段位置与当前内核支持范围。JSON 不允许尾随逗号，字段值的类型也必须正确，数字、字符串和布尔值不能随意互换。若使用图形客户端生成配置，应优先修正界面中的来源设置。手工修改临时生成文件可能在下一次重载时被覆盖，造成“改好后又坏”的反复。

listen tcp 127.0.0.1:1080: bind: address already in use

上面的文字展示端口占用的典型报错形式，端口只是示例，不表示客户端默认端口。确认占用来源后，可以退出冲突程序，或在客户端修改监听端口并同步调整应用代理。不要直接结束不了解用途的系统进程。若旧内核进程尚未退出，先正常退出客户端并等待，再重新启动；如果反复出现残留进程，应检查安全软件干预、权限与退出日志，而不是只重复重启。

规则数据、内核兼容与配置回退

涉及 geosite、geoip 的报错，应查看数据文件是否存在、是否可以读取，以及被引用的集合是否包含在当前数据中。规则名称拼写错误与文件缺失是两类问题，更新数据不能修复错误的集合名称。自定义规则从其他内核环境复制而来时，还可能使用当前内核不认识的字段。先撤回最近新增的一条规则，验证内核能否启动，再逐条恢复，比一次删除全部路由更容易保留有效设置。

切换 Xray 与 V2Fly 家族内核时，需要重新确认协议、传输和扩展字段兼容性。它们属于相关生态，但并不保证所有配置通用。若错误只在某种内核出现，先用该内核明确支持的配置建立基线，再检查差异。不要通过重命名文件强行替换内核，也不要把某个内核独有字段保留在另一套配置里。客户端提供的切换入口与配置生成方式应当配套使用。

若界面加载用户数据时崩溃，可先退出程序，备份客户端数据目录，再按客户端支持的方式建立独立的干净配置进行对照。不要立即删除原目录，因为其中可能包含分组、路由和订阅资料。干净配置正常时，再分批恢复设置以定位损坏或不兼容项；干净配置仍失败，则转查运行环境、权限与系统日志。更细的错误阅读方法见v2rayN 内核启动失败排查。

移动端专项：VPN 权限、分应用与后台限制

Android 上的 v2rayNG 与 v2flyNG 通常通过系统 VPN 接口接入应用流量，排查路径与桌面的系统代理不同。状态栏出现 VPN 标识，只能证明系统存在相应连接状态，不能证明远端握手与目标访问都成功。先进入客户端选择活动配置，启动连接并查看日志，再用一个固定浏览器测试。两款客户端的内核家族不同，涉及特定协议与传输组合时，应核对兼容性，不要只按界面相似程度判断。

系统授权与 VPN 冲突

首次连接需要确认系统 VPN 授权；如果取消授权或被系统策略阻止，本地流量就不会按预期进入客户端。检查是否有另一款使用 VPN 接口的应用正在运行，例如本地网络过滤或工作环境工具。此类应用可能争用同一接入位置，启动其中一个会影响另一个。先停止冲突应用，再重新建立连接，并观察系统提示。受组织管理的设备可能有专门限制，应先确认设备策略允许的使用方式。

系统中的始终开启 VPN 与阻止未经过 VPN 的连接，会改变断线时的网络行为。如果客户端未运行或连接未建立，而系统仍要求所有连接经过 VPN，设备可能表现为完全无法访问网络。检查这些系统选项时先理解其目的，记录原状态，再进行对照。不要把断线保护产生的阻断误判为无线网络损坏，也不要未经判断就重置设备全部网络设置；先恢复客户端与系统策略之间的一致状态。

分应用规则与网络切换

只有某个应用不能访问时，查看客户端是否启用了分应用代理，以及当前使用的是仅代理所选应用还是绕过所选应用的模式。两者方向相反，选中同一个应用会产生相反结果。修改列表后通常需要按界面要求重新建立连接，使新规则进入当前运行配置。系统应用、工作资料中的应用与普通安装应用也可能位于不同范围，不能只根据名称相同就认为已经选中了正确对象。

Wi-Fi 正常而移动数据失败时，先关闭连接，在目标网络稳定后重新启动，并检查移动数据权限、流量限制与门户认证状态。网络切换会改变地址、路由与解析环境，旧连接不一定能继续使用。反向情况也按同样方式对照，保持服务器和测试网站不变。如果仅在某条网络下出现 DNS 或远端连接错误，应回到对应章节定位，不要直接清空订阅，因为订阅记录并不随网络类型自动失效。

锁屏断线与后台运行

连接在前台正常、锁屏后中断，优先检查电池优化、后台活动与系统自动清理规则。不同设备的设置位置不同，应在系统应用详情中查找相关选项，并只为需要持续连接的客户端调整。不要同时修改所有省电策略，否则难以确认哪一项造成限制。调整后锁屏等待，再唤醒检查客户端进程、VPN 状态与日志时间，区分进程被结束、网络暂时休眠和远端连接自行断开。

从最近任务划掉应用、执行一键清理或启用极限省电，可能影响后台服务。若系统保留了 VPN 图标而应用日志已停止更新，应重新进入客户端核对运行状态，必要时正常停止后再启动。不要只根据通知是否还在判断连接健康。持续后台运行也会消耗设备资源，恢复后应观察耗电、网络使用与稳定性；如果异常资源占用伴随大量重连，先处理导致重连的网络或配置问题。

安装更新与恢复验证

安装包应从Android 下载入口按设备架构选择；不确定架构时可查看设备信息与下载页说明。安装失败要区分架构不兼容、系统要求不满足、存储空间不足与现有安装来源差异。不要为了尝试另一个安装包就直接卸载，先保存配置和订阅资料。更换 v2rayNG 与 v2flyNG 也不是纯粹替换外壳，应确认待导入配置对应的内核功能。

最终验证覆盖前台浏览、锁屏唤醒和一次网络切换，逐项确认请求仍能进入客户端且路由符合预期。分应用模式下，还应分别检查一个应被代理和一个应被绕过的应用。把恢复所需的最少设置记录下来，保留其他系统选项原状。若仍需反馈问题，提供设备系统、客户端名称、网络类型和隐藏敏感信息后的错误片段；基础操作可返回使用指南，零散设置疑问可查阅常见问题。