v2rayN 故障排查
连接、订阅与客户端设置

一、连接后无法上网：先划分故障层

建立直接连接与代理连接的对照

“无法上网”不是单一故障。先退出客户端并恢复系统原有代理设置，打开一个平时可以直接访问的网站。如果此时仍失败，优先检查无线网络、网关、系统时间和网络登录页面。酒店、校园或公共无线网络可能需要先完成网页认证；客户端显示已启动，并不能代替基础网络已经连通的证据。不要在基础网络尚未恢复时反复更换协议。

直接访问正常后，再启动客户端，确认服务器列表中确实存在活动服务器，而不是只有一条被鼠标选中的记录。然后查看运行日志，确认内核已成功启动、本地入站开始监听。界面托盘图标存在，只能说明图形程序仍在运行；如果内核启动失败、端口被占用或配置生成失败，浏览器仍会连接到一个没有服务的本地地址。

选择同一个测试网站，分别记录直接连接与经代理连接的结果。每次只执行一次请求，并记下时间，便于在日志中定位对应记录。若浏览器报错但客户端完全没有新日志，问题通常还在应用接管或本地入口；若出现出站连接错误，则继续检查服务器与协议。不要把浏览器缓存的旧错误页面当成新的测试结果。

用显式代理确认本地入口

在 v2rayN 的参数设置中确认 HTTP 或混合入站的实际端口。下面示例假定该端口为 10808；只有设置一致时才直接执行，否则先替换数字。在 Windows 可使用 curl.exe，避免某些命令环境中的同名别名影响参数。测试只用于判断请求是否经过本地入口，不代表所有网站都能正常访问。

curl --noproxy "" --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com

若提示无法连接到本地端口，先检查内核进程、监听地址和端口类型，不必立即修改远端服务器。若已经建立本地连接，但随后收到握手失败或远端超时，应转到下一章。若收到网站的 HTTP 响应，即使状态码不是成功，也说明请求已经获得应用层响应；需要结合内容判断是目标站限制、认证问题，还是代理链路中的其他环节。

显式代理成功而浏览器失败时，重点检查浏览器独立代理设置、代理扩展及系统代理。浏览器隐私窗口不一定停用全部扩展，也不一定绕过系统配置。可以使用一个没有独立代理规则的浏览器配置进行对照。若只有某个应用失败，还要确认它是否遵循系统代理，不能因为浏览器可用就推断所有程序都会自动使用相同入口。

恢复最小配置，再逐项加回功能

如果多个自定义设置同时存在，先备份，再保留一个已确认有效的服务器和简单路由方案。暂时停用额外代理链、复杂规则集及重复运行的网络工具，避免请求在多个本地入口之间循环。测试期间不要同时开启系统代理、另一套流量接管和浏览器扩展代理，除非已经明确各自的入口与出口，否则日志很难对应到同一条链路。

当所有网站都失败时，检查共同依赖的入口、解析和出站；当只有某一类域名失败时，查看路由规则、目标地址和该网站本身的状态。可暂时将测试域名交给明确的代理出站，验证后恢复原规则。不要把临时全局代理长期留作修复结果，它可能只是绕开了一条错误规则，并没有解决原来的配置问题。

修复完成后，按顺序恢复自定义路由、浏览器设置和其他网络工具，每恢复一项都重测同一目标。最后关闭并重新启动客户端，确认设置在重启后仍有效。把有效入口、活动服务器及代理模式记录下来；下次遇到故障就能先与这份基线对照。连接步骤不确定时，返回快速上手教程核对，而不是重新导入大量相同配置。

二、节点超时：区分传输连接与协议握手

确定超时发生在哪一个阶段

客户端测试显示超时，可能是服务器域名解析失败、目标端口无法建立连接，也可能是传输已经连通但协议握手未完成。不同测试功能使用的目标和方法并不完全相同，因此列表中的测试结果不能替代真实访问。先查看日志中最早出现的错误，后续连续报错可能只是同一次失败引出的重试，不应被当成多个独立故障。

在 Windows 中可运行下面的端口测试，地址与端口均为教学示例，需要换成配置中的实际值。测试成功仅表示能够建立对应的 TCP 连接，无法证明 VLESS、REALITY 或用户认证正确。测试失败也要结合服务器是否只接受特定网络路径来判断，不要凭一次结果就断定客户端损坏。

Test-NetConnection -ComputerName your-server.example.com -Port 443

若服务器使用的传输并非单纯的 TCP 连接，这项测试的参考范围更有限。对于基于 UDP 的路径，还需要检查本地网络与服务端是否允许相应流量。普通网页能打开，并不能证明所有传输都可达。更换无线网络与移动网络进行同目标对照，比连续修改多个协议参数更容易识别网络环境差异。

逐字段核对 VLESS 与 REALITY 参数

传输端口能够连通但握手失败时，应按服务端提供的原始资料逐字段核对。服务器地址决定连接目的地，服务器名称用于安全握手，两者不一定相同。不要把服务器名称自动改成连接地址，也不要因为地址后面使用了某个端口，就擅自推断应该关闭传输层安全。客户端与服务端必须采用一致的协议组合。

采用 XTLS Vision 时，还要核对流控与当前传输、安全选项是否匹配。不要看到同类配置可用，就将其流控值复制到其他服务器。REALITY 的公钥、短标识和服务器名称都需要与服务端要求对应；短标识可以有不同约定，是否允许留空取决于服务端配置，不能以某个教程截图作为唯一依据。

系统时间明显偏差也可能影响安全握手。启用操作系统的自动校时后，确认日期、时间与实际时刻相符。若错误信息涉及证书或服务器身份，应检查服务器名称、证书部署和系统信任环境，不要用关闭身份验证作为常规修复。握手错误被隐藏后，连接可能看似恢复，但原来的配置与安全问题仍然存在。

判断服务端、内核与本地网络边界

同一网络下只有一个服务器持续超时，而其他已知可用服务器正常时，优先确认该服务器的地址、服务状态和账号有效性。若所有服务器同时异常，且刚好发生在路由器调整或网络切换之后，应先检查共同的网络路径。对照测试必须使用同一份参数，否则无法判断差异来自网络还是配置本身。

同时核对所选内核是否支持该配置要求。Xray 与 V2Fly 的功能集合并不完全相同，不能把能够导入的分享内容等同于内核能够执行。有关 REALITY 与配置兼容性的背景，可阅读Xray 与 V2Fly 内核差异。只有日志明确指向功能不支持时，才按配置需求调整内核或客户端。

向配置提供方反馈时，整理测试时间、使用网络、连接目标、错误阶段以及脱敏后的第一条错误。不要只发送“超时”截图，也不要公开订阅凭据。如果相同配置在另一网络正常，应说明两种环境的差别；如果在所有环境都失败，则需要服务端日志配合。客户端侧无法单独修复远端未监听、账号停用或服务端参数不一致的问题。

三、订阅失败：先分清获取、解析与更新

判断地址是否能返回正确内容

订阅更新包含获取地址、解析内容和写入服务器列表三个阶段。显示更新失败时，先读具体错误：域名解析失败、连接超时、认证拒绝和内容无法解析，对应的处理方式不同。某些服务会返回一个正常的网页状态码，但内容实际是登录页面或访问提示；这并不是有效的订阅数据，反复点击更新不会改变结果。

从可信的配置管理页面重新复制完整订阅地址，核对协议头、路径与查询参数是否齐全。聊天工具换行、手动删去尾部字符或复制到前后空格，都可能让地址发生变化。订阅链接常带有访问凭据，应视为密码处理；不要贴进公共测速网站、在线解码工具或问题讨论区，也不要用含完整地址的截图寻求帮助。

如果日志显示认证拒绝或资源不存在，先在原配置管理页面确认订阅是否仍有效、账号是否有权限、地址是否已重置。服务器节点可连接与订阅地址可更新是两件事：已有服务器记录可以继续使用，而订阅访问凭据可能已经变更。相反，订阅获取成功也不能证明其中每个服务器当前可连接。

检查更新请求走的是哪条网络路径

订阅更新可能使用直接连接，也可能根据客户端设置经过现有代理。先查看更新相关选项，不要假定它一定跟随系统代理。若客户端刚安装且尚无可用服务器，而订阅又需要经过代理获取，就会出现启动依赖：没有配置就无法取得配置。此时需要使用提供方允许的可达地址或可信的手动配置入口，而不是循环尝试同一条失效路径。

已有可用服务器时，可以保持该服务器活动，再分别测试直接更新与经代理更新，每次只切换更新方式。若其中一种成功，说明问题更可能在订阅地址的可达路径或解析环境。不要同时改变系统代理、DNS 和更新方式；当多个变量一起变化时，即使更新恢复，也无法知道真正有效的是哪一步。

对于返回网页、重定向异常或安全连接错误的地址，应检查系统时间、网络登录状态及是否经过需要认证的上游网络。不要为了获取订阅而长期放宽安全连接检查。若请求被重定向到登录页，需要从正常的服务管理入口确认授权状态，而不是把登录页面内容保存为配置文件再导入客户端。

处理格式不兼容、重复记录与覆盖风险

能够取得内容但解析失败时，确认提供的格式适合当前客户端。分享链接集合、编码后的订阅文本以及某些专用配置文件，并不是任意互换的。不要只根据文件后缀判断格式，也不要通过盲目添加或删除编码层来尝试修复。优先使用配置提供方明确标注的客户端格式，并确认其中的协议特性与所选内核一致。

更新前先备份订阅分组及少量手工修改过的记录。订阅刷新可能重建分组内容，手动更改的别名、地址或传输字段可能被新的订阅值覆盖。需要长期保留的手动配置，应放在独立分组并清楚命名。不要同时维护多个指向同一地址的分组，否则服务器列表看似增加，实际上只是相同记录重复出现，排查时容易选错对象。

若更新后记录消失，先检查分组筛选、名称过滤和订阅返回内容，不要马上再次清空全部列表。空列表可能来自筛选条件，也可能是地址返回了空数据。保留旧备份后，用独立测试分组验证，能够把界面显示问题与远端内容问题分开。更新成功提示只说明客户端完成了某个操作，不代表内容一定符合预期。

最后选择更新后的明确记录设为活动服务器，重新测试访问。部分客户端不会自动把原活动记录映射到新生成的条目，因此“订阅更新成功但无法连接”仍可能是活动选择没有恢复。有关订阅与服务器选择的基础关系，可查阅常见问题；若日志已经进入协议握手阶段，则返回节点超时章节继续排查。

四、速度慢与间歇卡顿：用一致条件比较

先区分首开慢、持续慢和单站慢

页面第一次打开很慢，但随后传输正常，常见原因在解析、连接建立或安全握手；下载开始后持续低速，则更可能与链路吞吐、丢包、服务器负载或本地设备有关。视频播放偶发停顿还可能来自目标服务的缓存与调度。先描述可重复的症状，不要把所有等待都归结为“节点速度差”，否则容易用更换服务器掩盖真正的问题。

建立对照时，固定设备、网络、活动服务器、测试目标与大致时间，暂停云同步、系统下载和其他大流量任务。优先使用自己确实需要访问的业务，而不是只看一项通用测速。不同目标的连接路径和服务策略可能不同，某个测速结果良好，也不能证明文件下载、视频或实时通信一定表现相同。

比较前还应确认测试请求命中了相同路由。相同域名可能因规则更新、地址解析结果或应用设置变化而走不同出口。打开连接日志，检查目标最终选择的出站；若一次直连、一次代理，两次结果没有可比性。连续重复少量测试即可，不必高频并发请求，以免额外流量反过来影响观察。

沿本地网络、远端链路和设备资源定位

先观察不经过代理的正常业务是否也变慢。若同样卡顿，检查无线信号、路由器负载和宽带上行是否被占满。上行拥塞会拖慢确认包和交互请求，即使下载带宽看似仍有余量，也可能出现网页迟迟不响应。条件允许时用有线网络或靠近路由器进行对照，但不要同时切换服务器，否则无法分清改善来自哪一层。

若只有代理业务慢，分别比较同一服务器访问不同目标，以及不同服务器访问同一目标。前者用于观察目标站和出口调度，后者用于观察服务器路径差异。跨网络链路会随时间变化，短时间测试只能说明当前状态。晚间拥塞、服务端限速或远端资源不足，都需要多次同条件记录，不能凭一次峰值作结论。

同时查看系统任务管理器或资源监视器。若客户端或其他进程持续占用较高处理器、内存紧张导致频繁换页，瓶颈可能在本机。大量并发连接、过度详细的日志以及频繁测速也会增加开销。先减少非必要任务，保留正常日志级别；不要因为看到一次处理器尖峰，就立刻关闭安全软件或修改系统网络参数。

谨慎调整传输、复用和流量接管设置

连接复用并非对所有协议与网络都有收益。某些组合可能增加队头等待，某些功能又有内核或协议限制。只有配置提供方说明支持、且能够做前后对照时，才调整相关选项。不要把网上一组“加速参数”整体复制到所有服务器；错误的复用、流控或传输设置不仅不能提升速度，还可能让原本可用的连接变得不稳定。

若简单页面能打开，但大页面或长连接经常停住，可进一步检查接管模式、路径 MTU 或 UDP 相关行为。不过 MTU 应作为后续分支，而不是第一步。先对照显式代理与当前接管方式；只有问题随接管方式变化时，才检查其网络接口和相关设置。修改前记录原值，逐步调整并恢复验证，避免用多个随意数值形成新的未知状态。

只有单个网站慢时，检查浏览器开发者工具或应用提示，区分主文档、图片、脚本与接口请求。页面依赖多个域名，其中一项被错误分流或解析失败，就可能表现为整页卡顿。此时应修正规则覆盖范围，而不是将所有流量长期强制送往同一出口。若目标服务自身返回限流或账号限制，客户端设置也无法代替业务侧处理。

调整完成后至少覆盖首次打开、持续传输和空闲后重连三类场景，确认没有只改善一项却破坏另一项。记录有效修改及撤销方法，清除临时测速任务。安卓端若主要表现为熄屏后卡顿，应转到移动端章节；后台冻结与链路吞吐不足的表现相似，但需要处理的是系统运行策略，而不是盲目增加连接数量。

五、DNS 异常：明确解析发生的位置

区分系统、浏览器与内核解析

DNS 问题常表现为域名打不开、偶尔成功、连接到了错误地址，或者首个请求等待很久。同一设备上可能同时存在系统解析器、浏览器安全 DNS、客户端内核 DNS，以及应用自带解析。它们未必使用同一服务器，也未必走同一条路由。先画清当前请求由谁解析，再修改对应设置，不要只替换系统 DNS 就认为所有应用都会跟随。

可在 Windows 中用下面命令检查系统解析结果。它反映的是系统解析路径，不代表客户端内核或浏览器的最终结果。记录返回地址、错误类型和查询时间，再与客户端日志对照。直接用 IP 打开网站也不是通用验证办法，因为很多网站依赖主机名、安全握手和虚拟主机；IP 访问失败不能单独证明网络不通。

Resolve-DnsName example.com

如果系统解析正常、浏览器仍失败，应检查浏览器是否启用了独立安全 DNS，以及它是否能够访问所选解析服务。反过来，浏览器正常而某个应用失败，也可能是两者解析路径不同。测试时暂时统一一处设置，并记录原值；不要同时更换浏览器解析、系统解析和内核解析，否则只会得到无法归因的结果。

排除解析回环和引导依赖

远程解析服务本身可能使用域名，这个域名首先需要被解析。如果系统把所有查询都交给该服务，而访问它又依赖尚未建立的代理，就会形成引导依赖。类似地，服务器地址使用域名，而解析服务器的请求又被指定必须经该服务器出站，也可能形成循环。配置时应保留明确可达的引导路径，避免每一步都依赖下一步已经成功。

下面是内核配置中的 DNS 片段，用于说明解析地址与查询策略的关系，不是完整客户端配置，也不应直接覆盖图形客户端自动生成的文件。实际使用时通过客户端支持的设置修改，并结合所选内核文档确认字段行为。该片段展示普通 DNS 查询，是否适合当前网络与隐私需求，需要单独评估。

{
  "dns": {
    "servers": [
      "1.1.1.1"
    ],
    "queryStrategy": "UseIP"
  }
}

DNS 服务器能否访问、查询流量如何路由，以及解析结果随后怎样建立连接，是三个不同问题。某个服务器地址能够回应查询，不代表返回结果适合当前出站。对于需要区分直连与代理的环境，应保持域名规则、解析策略与出站选择相互一致。不要把“解析更快”直接等同于“目标连接更快”，地理调度结果也可能影响后续路径。

检查 IPv6、缓存与规则命中

双栈环境下，域名可能同时返回 IPv4 与 IPv6 地址。如果本地获得了 IPv6 地址但实际出口不完整，应用可能先尝试不可达路径，造成明显等待。先分别确认两类地址的可达性，再决定是否调整查询或连接策略。不要仅凭看到 IPv6 结果就关闭整个系统的 IPv6；局部策略调整更容易回退，也能避免影响其他依赖。

修改解析设置后，旧结果可能仍留在操作系统、浏览器和内核缓存中。Windows 可在确有需要时使用 ipconfig /flushdns 清理系统缓存，但它不会清掉所有应用自己的缓存。先停止测试请求，按需重启相关应用或内核，再查询一次。连续清缓存而不检查配置，会让现象不断变化，却没有消除错误来源。

如果只有少量域名异常，查看 hosts、客户端自定义域名映射、广告过滤或安全软件是否改变了结果。规则中的域名匹配与 IP 匹配可能在不同阶段执行，解析后得到的地址也可能命中另一条规则。应根据连接日志确认最终出站，而不是只凭规则列表的排列猜测。需要临时加规则时，限定到测试域名并注明撤销条件。

验证结果至少包括系统查询、实际应用访问和客户端日志三部分。成功解析只是其中一步，仍需确认安全握手与页面请求完成。若调整后只有浏览器恢复，继续检查其他应用是否使用独立解析；若所有域名解析都正常但连接仍超时，则返回传输与握手章节。将两类问题分开，才能避免在服务器端口故障时反复改 DNS。

六、系统代理不生效：检查应用是否接管

理解系统代理与全设备流量的区别

系统代理是一组提供给应用读取的网络设置，不等于操作系统把所有流量强制送入客户端。浏览器通常会遵循相应设置，但命令行工具、游戏、后台服务或使用独立网络组件的应用可能忽略它。因此系统代理开启后，某个程序仍直接连接，并不一定是 v2rayN 设置失败。先确定该应用支持哪一种代理方式，再选择相应的接入方法。

先查看 v2rayN 当前系统代理状态，确认不是清除代理或保持原设置。随后打开操作系统的网络代理页面，核对地址、端口以及是否存在自动配置脚本。不同代理方式的优先关系由系统和应用决定，手动代理与自动脚本同时存在时容易造成误判。排查期间保留一种明确方式，并记录此前的原始值，避免影响工作网络要求。

本机应用通常使用回环地址连接本地入口，填写 127.0.0.1 时，指向的是当前设备本身。手机若把代理地址也写成这个值，就不会连接到电脑。局域网共享需要填写主机的局域网地址、正确的入站端口，并配置访问范围。它与本机系统代理是两条不同路径，不应为了修复本机浏览器问题就直接开放局域网监听。

核对协议、端口与应用自身设置

显式代理测试能成功而应用不生效时，先检查应用内是否有“直接连接”“使用系统设置”或独立代理选项。某些工具读取环境变量，另一些读取系统设置；即使它们运行在同一个终端窗口里，也不保证行为一致。修改代理后还要关闭旧连接或重启应用，因为已经建立的长连接不一定立即切换到新出口。

端口必须与入口协议对应。HTTP 代理地址不能随意指向一个只接受 SOCKS 的端口；混合入口是否同时接受两类请求，应以当前客户端设置为准。若需要通过 SOCKS 让代理端处理目标域名，支持该语法的工具可以使用 socks5h，它与本地先解析的行为不同，测试时要明确差异。

curl --noproxy "" --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com

上面的端口仍是假定值，先确认它确实接受 SOCKS 请求。若 HTTP 测试成功而 SOCKS 测试失败，不应立即判断服务器有问题，可能只是两个测试用了不同的本地入口能力。还应查看应用的代理绕过列表，例如对本地地址、特定域名或网段的排除规则；被明确排除的请求本来就不会进入代理。

排除多工具冲突与残留设置

多款网络工具同时运行时，可能反复写入系统代理。常见现象是刚设置成功又被改回，或者客户端退出后其他应用全部断网。先停止其他具有代理管理功能的程序，再观察系统设置是否稳定。浏览器扩展也可能覆盖系统设置，所以必须分别查看系统层和浏览器层，不能只根据托盘菜单中的选中项判断接管成功。

客户端异常退出后，系统可能仍保留指向本地端口的代理设置，而该端口已经没有进程监听。恢复方法是重新启动客户端并正常清除系统代理，或到系统网络页面移除失效的手动配置。不要反复重启路由器；请求尚未离开本机就已经失败。恢复直接访问后，再检查客户端为何异常退出，避免下次重现同样的问题。

如果涉及局域网共享，只允许需要的网络范围访问，并在防火墙中限定对应端口和网络配置文件。不要为了方便关闭整个防火墙，也不要把本地代理入口直接暴露到公网。共享设置的详细步骤见v2rayN 允许局域网连接说明。主机更换网络后，局域网地址可能变化，其他设备也需要同步核对。

最终验证应覆盖开启代理、应用重新连接、关闭代理和客户端退出四个动作。开启后看日志确认请求进入正确出站，关闭后确认直接访问恢复，退出后确认系统没有留下失效入口。若只有不支持系统代理的应用仍未接管，应依据应用能力选择其独立代理或适合的接管方式，而不是继续重复写入同一组系统代理地址。

七、客户端崩溃与内核退出：保留最早错误

区分图形界面退出与内核启动失败

窗口消失、托盘仍在、服务器无法连接和内核反复重启，是不同层面的故障。先确认究竟是图形程序退出，还是内核子进程停止。界面正常但日志提示配置错误时，应检查生成配置及功能兼容性；整个程序无法打开时，则需要检查安装包架构、系统支持条件、运行依赖和文件访问权限。不要一开始就删除所有配置目录。

记录故障触发动作，例如启动即退出、更新订阅后退出、切换内核后失败，或打开某个设置页时崩溃。随后查看客户端日志和操作系统事件记录中的对应时间段。保留最早的异常以及紧邻它的上下文，后续连接失败往往只是程序已经停止的结果。日志量很大时，先复制一份，再清理后重现一次，避免有效信息被滚动覆盖。

分享诊断资料前检查其中的路径、用户名、订阅凭据和完整配置。不要把整个用户目录打包公开，也不要上传包含服务器认证内容的崩溃附件。通常客户端名称、系统架构、触发步骤和脱敏错误已经足够开始定位；若需要更详细资料，应明确收集范围，并通过可信渠道处理，而不是直接贴出所有本地文件。

检查安装环境、权限和端口占用

从客户端下载页按系统和处理器架构选择安装包。Windows 桌面版与经典 WPF 版具有不同的界面技术和运行条件；切换前先备份配置，不要将不同安装内容直接覆盖混放。两者选择方法可参考Avalonia 桌面版与 WPF 版对比。不要为解决界面问题而随意复制来源不明的运行组件。

便携目录应放在当前用户能够正常读写的位置，避免受限目录、只读介质或频繁同步的文件夹。若日志显示权限拒绝，检查具体路径及权限，而不是长期以管理员身份运行来掩盖问题。安全软件拦截时，先看拦截记录与来源，再按系统机制处理；不应把停用全部保护作为标准安装步骤。

内核报端口被占用时，可能是另一个客户端实例仍在运行，也可能是其他服务使用了同一端口。先查看托盘和进程列表，关闭重复实例，再确认监听恢复。若必须换端口，要同步修改系统代理和应用独立代理地址。只改客户端一处，会把原来的端口冲突变成应用无法连接本地入口的问题，表现看起来却仍像网络故障。

用独立配置隔离损坏与兼容性问题

启动错误紧随某次设置变更出现时，优先撤销该项。若无法进入界面，在确认配置位置并完成备份后，可使用独立的测试目录或新的用户配置进行验证。不要直接删除原目录；其中可能包含订阅分组、手动服务器及路由规则。测试环境只放一个已知有效的配置，能帮助区分程序环境与历史设置损坏。

新环境正常而旧环境失败时，逐项迁回服务器、订阅和路由设置，每迁一项就重新启动验证。若导入某组规则后开始失败，检查规则文件路径、字段格式和内核支持情况。图形客户端能保存某项内容，不代表最终生成的内核配置必然有效；应以启动日志中的字段错误和实际生效结果为准。

如果同一份最小配置在干净环境中仍使程序退出，再检查系统资源、磁盘空间、运行依赖与软件冲突。更新或重新安装时保留原始备份，并避免在测试过程中同时恢复全部旧设置。只有明确定位到某项不兼容功能时，才选择替代实现；不能因为重装暂时恢复，就忽略此前留下的触发条件。

修复后执行一次完整退出和重新启动，检查内核只启动一个实例、本地入口正常、系统代理退出时得到恢复。接着验证订阅更新和常用路由，确认问题没有被临时空配置掩盖。将触发步骤与解决动作一起记录，比只记“重装好了”更有价值；后续环境变化时，也能据此快速判断是否属于同一故障。

八、安卓断连与耗电：检查授权和后台策略

确认 VpnService 授权与唯一运行实例

安卓端首先区分服务未启动、服务启动但无流量，以及熄屏后服务停止。v2rayNG 与 v2flyNG 通过系统提供的 VpnService 接管相应流量，首次连接需要确认系统授权。授权通过只代表服务有权建立本地虚拟网络接口，不代表服务器握手已经成功。若状态显示运行但无法访问，仍需要结合日志检查活动服务器、DNS 与出站参数。

同一用户环境下，系统通常只允许一个此类 VPN 服务处于活动状态。另一个网络过滤、工作网络或代理应用启动时，可能替换当前服务。先确认系统设置中实际运行的是哪一个应用，再查看常驻通知是否存在。不要同时启动 v2rayNG 和 v2flyNG 来比较速度，应该完全停止前者后再测试后者，否则结果会混入服务接管变化。

更换客户端不等于原配置必然兼容。v2rayNG 采用 Xray 内核，v2flyNG 是 V2Fly 内核备选，应按配置所需功能选择。若配置依赖 REALITY 或特定流控，先确认内核支持，不要将握手失败当成系统授权问题。首次授权、后台设置与分应用代理的操作关系，可参考v2rayNG 安卓设置要点。

处理熄屏断连与网络切换

前台正常、熄屏一段时间后断连，优先检查应用的电池使用策略、后台运行权限和厂商提供的自动启动管理。不同系统菜单名称不同，可以从应用信息页面进入电池相关设置查找。先允许必要的后台活动，再锁屏重测；不要直接给所有应用放宽限制。常驻通知用于说明服务仍在运行，不建议仅为隐藏通知而破坏服务的后台条件。

将后台限制放宽会影响耗电，应以实际稳定性需求为准。按固定时间间隔观察熄屏前后日志与系统电池统计，确认是进程被结束、网络被冻结，还是远端连接自然失效。服务通知仍在但请求失败时，可能需要重建连接，并不一定是应用被系统关闭。反复强行停止和清理后台，会破坏原本想保持的运行状态。

无线网络与移动网络切换会改变地址、路由和可达性，已有连接可能中断。先等待客户端完成重新建立，再发起新的请求，不要用切换前遗留的页面判断当前状态。如果每次切换都失败，检查系统是否限制后台移动数据、是否启用了数据节省，以及客户端的重连行为。两种网络分别可用而切换后失败，才应集中检查迁移过程。

排查分应用代理与异常电量消耗

只有部分应用不走代理时，检查分应用模式究竟是“仅代理所选应用”还是“绕过所选应用”。两种列表含义相反，选中了应用却没有达到预期，往往是模式理解错误。修改后停止并重新启动服务，再关闭目标应用已有连接进行测试。系统组件、工作资料中的应用与同名应用副本可能拥有不同身份，不能只凭桌面图标名称判断是否选中正确。

耗电高时先看统计时间范围、总运行时长以及前后台占比。VPN 服务可能被系统归入经过它转发的网络活动，因此电池页中的占比不等于全部开销都由客户端额外产生。比较前后需要保持业务量接近；一边持续视频播放、一边待机的两组数据没有参考意义。还要排除信号弱、热点共享和其他应用高频联网的影响。

若空闲时日志仍持续重连，检查服务器可达性、解析失败与网络抖动。频繁握手、自动测试和过密的更新任务可能增加唤醒，应减少非必要轮询，而不是随意放大所有超时。反过来，过短超时可能把暂时拥塞误判为断线，引发更多重试。保留默认或有明确依据的策略，逐项对照，比套用一组所谓省电参数更可靠。

最终安排前台访问、熄屏待机、网络切换和分应用访问四组验证，记录每组的服务状态与错误时间。若主要问题是电量，可继续阅读v2rayNG 耗电与后台运行排查；若所有场景都在同一握手阶段失败，则返回节点超时章节。系统后台策略、内核兼容性与远端连接是三条独立线索，分开处理才能得到可重复的修复结果。