V2Ray 故障排查

无法上网：先拆分请求路径

客户端显示已启动，并不等于应用请求已经经过代理。一次访问通常经过应用、本地监听、内核路由、远端连接和目标服务。前一段没有交接成功，后一段即使配置正确也不会收到请求。先记录是所有应用失效、只有浏览器失效，还是仅部分网站打不开；同时写下连接前后的变化，避免把原本就存在的网络问题归到客户端。

建立直连与代理两个对照

先在客户端清除系统代理或停止安卓连接，再访问一个平时能够直连的页面。如果直连也失败，应先处理无线网络认证、路由器连接、系统时间或网络本身的问题。测试时不要只看已经打开的标签页：页面可能来自缓存。重新打开一个页面并刷新，确认实际发生了网络请求，再启动客户端进行同样的访问。

桌面端首推使用 v2rayN 进行排查。进入参数设置，查看实际的本地监听地址、端口和协议，再对照系统代理中的地址。本站示意图中的 10808、10809不是所有版本共用的保证值：部分界面使用混合监听，部分配置分别提供 SOCKS 与 HTTP。只以当前客户端设置和启动日志为准，不要照着旧截图修改系统。

接着打开客户端日志，清空旧内容或记住当前时间，只触发一次失败访问。如果完全没有新的连接记录，优先检查应用是否读取系统代理，以及浏览器是否被独立代理设置覆盖。如果出现本地入站记录后才报错，说明请求已到内核，应转查节点、路由和 DNS。日志级别过低时看不到逐条连接，可短暂提高一级，测试后恢复。

用显式代理隔离系统设置

下面命令仅适用于已确认 127.0.0.1:10808 提供 SOCKS 服务的情况；端口不同必须替换。Windows 在 PowerShell 中使用 curl.exe，macOS 与 Linux 可使用 curl。示例域名用于验证请求路径，不用于比较速度。工具未安装时可改用应用自带的代理设置，不必为此安装额外网络工具。

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

如果显式代理能获得响应，而普通浏览器访问失败，节点本身不应成为首要怀疑对象，应阅读系统代理章节。若提示无法连接本地地址，检查内核进程、监听端口和端口冲突；若已经建立本地连接，随后出现握手失败或超时，则转到节点超时章节。HTTP 错误状态仍可能证明传输已经接通，不能把所有非成功状态都当成代理断线。

验证恢复，而不是只看连接按钮

恢复时按相反顺序确认：内核启动没有错误，本地监听存在，应用请求进入日志，目标页面得到响应。每次只调整一个变量，并重新执行最初失败的访问。只切换节点却同时更改 DNS、路由和浏览器设置，会让结果无法归因，也不利于后续恢复原配置。成功后记录解决动作，保留必要日志即可。

节点超时：从端口到传输参数

超时只表示某个操作在等待期限内没有完成，并没有直接说明故障位置。节点列表的延迟测试、建立传输连接和网页加载可能使用不同的测试目标与路径。先确认错误来自哪一项操作，再看同一时刻的内核日志。一次测试失败不足以判定节点永久失效；连续失败时也应先排除本地网络变化和配置未生效。

区分拒绝连接、握手失败与等待超时

日志出现 connection refused，通常说明对应地址没有接受连接，可能是端口填错、服务未监听，也可能是中间设备主动拒绝。出现 i/o timeout 则表示等待到期，仍需判断等待的是解析、拨号还是读取响应。看到 EOF 只能说明连接提前结束，单独这一行不足以证明凭据错误，要连同前后的协议和握手记录分析。

先检查系统日期、时间和时区，让系统自动同步时间。证书有效期检查和部分认证机制依赖时间；电脑休眠后、离线后或系统时间被手动改动时，可能出现突然无法连接。随后确认活动节点就是正在排查的条目，停止旧连接并重新连接一次。列表中选中某行，不一定意味着已将它设为活动服务器。

接着对照服务提供方给出的配置，逐项核对服务器地址、服务端口、用户标识或密码、传输方式与安全设置。服务器端口是远端服务入口，本地监听端口是应用接入客户端的位置，两者不能互换。通过订阅导入的条目也可能因为旧缓存、分组更新失败或手工修改而与当前服务端配置不同。

只检查当前节点真正使用的字段

使用 WebSocket 的条目需要核对路径和 Host；路径中的大小写、前导斜杠和多余空格都可能影响匹配。使用 gRPC 的条目应核对服务名称。使用 TLS 的条目需要核对服务器名称与证书对应关系，连接地址不一定等于证书名称。不要为了消除错误直接关闭证书验证，这会掩盖配置问题并改变连接的安全边界。

VLESS 是代理协议，REALITY 是与具体实现相关的安全机制，二者不能当成同一个设置开关。排查 REALITY 条目时，要核对服务端要求的服务器名称、公钥、短标识和指纹等参数，并确认当前内核支持该组合。v2rayNG 与 v2flyNG 使用的内核家族不同，同一条分享链接能被导入，不代表其中全部字段都能按原样执行。

对于传输参数复杂的条目，优先重新导入一份原始配置进行对照，而不是在现有条目上连续尝试不同选项。保留原条目并给测试条目添加便于识别的备注，避免误覆盖。不要把其他节点的路径、服务器名称或安全参数移植过来；这些字段通常是一组配套设置，单独替换容易得到新的错误。

通过控制变量确认远端问题

保持客户端设置不变，先换一个已经确认可用的节点。如果新节点能连接，问题更可能集中在原条目的参数或远端状态。如果全部节点都在同一网络失败，再尝试另一条正常网络，并暂时停止其他代理或隧道程序。切换网络后应重新建立连接，旧连接不会因为网络出口改变而自动成为有效对照。

只有在地址和端口无误、客户端兼容性已确认、不同网络重复失败后，才适合向服务提供方询问服务端监听、防火墙和账户状态。提供失败时间、所用内核、脱敏后的错误行以及是否所有节点均失败即可。不要公开完整订阅地址、用户标识、密码或分享链接；这些内容可能同时承担访问凭据的作用。

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

订阅更新包含获取内容、识别格式、解析节点和写入分组几个阶段。提示更新失败不一定是链接过期，也可能是网络不可达、返回登录页面、格式不受支持或分组被误选。先记下完整错误文字，区分“请求失败”和“解析失败”，再决定检查网络还是内容。不要一开始就删除所有节点，否则会丢失用于对照的可用配置。

先保护现有分组与有效节点

在 v2rayN 中打开订阅分组，确认正在更新的分组名称与地址一致，检查是否存在重复分组或相似备注。若客户端提供配置导出功能，可以在本地保存一份备份，并妥善保管；备份本身可能包含账户信息。测试新地址时另建分组，比覆盖现有分组更容易回退，也方便比较更新前后的节点内容。

粘贴链接时检查开头和结尾是否夹带空格、换行、引号或聊天软件添加的说明文字。不要擅自删掉问号后的查询参数，其中可能包含认证和格式选择信息。带有有效期的链接可能需要重新获取，但“看起来很长”不代表有问题。若地址由服务提供方重新生成，旧地址是否继续有效应以对方说明为准。

接着确认本次更新采用直连还是代理。不同客户端和界面版本的更新菜单名称可能不同，应查看该操作的实际说明。当前代理节点已经失效时，使用它更新订阅可能陷入循环；此时可在允许直连的网络上尝试普通更新。相反，只有经过可用代理才能访问的订阅地址，应先选择已经验证可用的连接再更新。

识别返回内容，而不是反复点击更新

如果日志记录了 HTTP 状态，认证相关错误应优先检查地址和账户权限；请求过多则应暂停重试并遵循服务端提示。成功状态也不一定代表得到节点内容：网络认证门户、登录页面和反向代理错误页都可能返回普通网页。客户端把网页当作订阅解析时，往往只显示空列表或格式错误，而不说明网页本身的内容。

如需查看响应，只在受信任的本地环境中操作，不要把订阅地址粘贴到在线解码或在线测试工具。确认返回的是客户端支持的分享链接集合或订阅格式，而不是说明页面。浏览器能显示一大段文本，只能证明获取到了内容，不能证明所有节点协议、字段和编码都兼容当前客户端。

当同一订阅只有部分节点被导入，应查看被跳过条目使用的协议和传输方式。可能是字段缺失、格式扩展不受支持，也可能是服务端返回了面向其他配置体系的内容。应向提供方选择适用于当前客户端的输出格式，不要把一整份其他用途的配置直接贴进单节点导入框。切换内核前同样要确认协议能力。

检查过滤、分组和更新结果

更新提示成功后列表仍为空，先取消搜索关键字，切回全部分组，检查是否启用了节点名称过滤或隐藏条件。随后比较日志中的导入数量与当前列表，而不是只看状态提示。部分客户端会用新订阅内容替换分组内旧条目，因此服务端返回空内容时，重复更新可能让原有节点消失；保留备份可以降低回退成本。

更新成功也不等于连接验证成功。选择新导入的一个条目作为活动节点，重新连接，再按订阅导入步骤完成访问验证。如果新节点全部失败而旧节点可用，应重点比较参数与输出格式；如果只有更新过程失败而现有节点可用，则不要同时修改节点的路由、DNS 和传输设置。

遇到格式兼容性问题，可以前往客户端下载页选择与系统和架构匹配的客户端，再按升级方式保留配置。更新程序不是所有订阅问题的答案：地址失效、账户权限和服务端返回错误仍需分别处理。记录获取路径、错误阶段和最终导入结果，可让下一次排查直接从已确认的环节继续。

速度慢：区分延迟、吞吐与停顿

“速度慢”至少包含三个不同问题：首次打开页面等待很久、持续下载速度低、连接一段时间后频繁停顿。延迟测试主要反映特定请求的响应时间，不能直接代表大文件吞吐，更不能代表所有站点的表现。先用一句具体描述记录症状，例如“同一页面首次打开慢，刷新后正常”，再选择能验证该现象的测试。

固定测试条件，避免比较失真

测试时固定设备、网络、客户端路由和目标服务，只切换一个节点。先暂停系统更新、云同步和其他大流量任务，确认本地带宽没有被占满。无线网络信号弱、路由器负载高或同时连接设备较多，都可能表现为代理速度下降。若直连可访问的服务也变慢，应先处理本地网络，而不是反复更换内核。

每个节点测试几次，并把偶发失败与持续异常分开记录。目标服务本身可能限制单连接速度，也可能根据出口地址选择不同的内容分发路径；同一个节点访问不同服务速度不同，并不罕见。不要用一个站点的一次测速结果推断所有业务。测试页面、文件或视频时，应尽量保持内容和清晰度一致。

如果节点测试显示低延迟，但网页仍然加载缓慢，观察日志中是否先出现较长的解析等待，或者有大量重复连接。页面往往同时请求多个域名，主文档响应快不代表图片、脚本与接口都走了正确路径。浏览器开发者工具可帮助区分域名解析、建立连接和等待响应阶段，但应注意其中的请求地址可能包含个人信息。

检查实际出站与设备资源

暂时选择一个明确的代理路由作对照，确认慢请求没有被规则送到不合适的直连出口。若临时改变路由后明显改善，应恢复原模式并定位具体规则，不要长期用扩大代理范围来掩盖问题。对于需要登录的服务，出口改变也可能触发额外验证；测试结果中应把验证等待和正常传输耗时区分开。

持续下载慢时，查看系统任务管理工具中的网络、处理器和内存占用。低功耗设备在高吞吐、复杂加密或大量连接下可能出现资源瓶颈；处理器持续繁忙时，换一个低延迟节点未必改善速度。日志若设为非常详细的级别，还可能增加磁盘写入与界面刷新负担，完成诊断后应恢复日常日志设置。

多路复用不是适合所有节点的加速开关。它会改变连接组织方式，实际表现依赖协议、传输、服务端支持和链路质量。仅在配置提供方明确支持时做单项对照测试，并记录开启前后的结果。不要同时改变多路复用、拥塞相关参数和 DNS，否则即使速度变化，也无法知道是哪项设置产生作用。

针对间歇性停顿检查网络变化

如果大流量传输在开始后停住，而小页面仍能打开，应关注丢包、连接重置、路径差异与服务端限制。系统能够连上不代表长连接始终稳定。先在另一条正常网络上测试相同节点，再判断是否需要进一步检查路径 MTU。不要直接照搬较小的 MTU 数值，它可能让部分连接恢复，也可能降低效率或造成新的兼容问题。

连接一段时间才变慢，还应检查设备温度、电源模式、安卓后台限制和网络切换记录。休眠唤醒或无线网络重新连接后，旧连接可能仍在等待结束，新连接则已经正常。先重新建立客户端连接进行对照；若只有长连接失效，可记录发生时间和网络切换情况，再继续定位，而不是把整个节点判定为不可用。

当多个设备在同一时段使用同一节点都出现吞吐下降，而更换节点后恢复，远端负载或出口链路问题的可能性更高。此时应把固定条件下的复现步骤反馈给服务提供方。只报告“测速不快”很难定位；说明目标服务、持续时间、是否直连正常，以及低延迟但低吞吐的差异，信息更有用。

DNS 问题：确认域名由谁解析

DNS 异常常表现为部分域名打不开、第一次访问等待很久，或切换路由后结果不同。一次请求可能使用系统解析、浏览器加密 DNS、内核内置 DNS，或把域名交给远端处理。先确定应用交给客户端的是域名还是已经解析的地址，再检查对应解析链路。只修改系统 DNS，未必能影响浏览器或内核独立发出的查询。

用同一域名检查解析阶段

先记录失败域名和错误文字。系统提示找不到主机，与解析成功后连接超时，是不同阶段的问题。可用下面的系统命令检查系统解析器能否返回结果；它不能证明代理内核使用了相同结果，也不能证明目标服务可达。为了排除缓存影响，应在修改设置后重新建立连接，并对同一个域名复测，而不是换一个恰好可用的网站。

nslookup example.com

如果系统解析失败，但通过显式 SOCKS 代理访问正常，可能是代理把域名交给其他解析路径。前文命令中的 socks5h 会让 curl 把域名交给 SOCKS 端处理；使用 socks5 时通常由 curl 在本地先解析。两者适合作为对照，但本地代理收到域名后最终如何解析，仍取决于内核路由与 DNS 配置。

如果只有一个浏览器异常，检查浏览器是否启用了独立的安全 DNS 设置。浏览器可能不使用系统解析器，也可能因自身解析失败而根本没有向本地代理发送请求。临时改回使用系统解析路径可以帮助定位，但测试后应根据实际需求决定保留方式。不要一边改变浏览器设置，一边替换内核 DNS，避免把两层问题混在一起。

核对内核 DNS 与路由的关系

内核的 DNS 设置不仅包含服务器地址，还涉及查询类型、请求走哪个出站，以及路由匹配时是否需要把域名解析为地址。下面是用于说明字段层级的局部 JSON：它保留域名参与初始路由判断，不主动为了匹配地址规则而解析。片段不是完整运行配置，不能直接替换客户端生成的整份文件。

{
  "routing": {
    "domainStrategy": "AsIs"
  }
}

在支持该字段的 Xray 与 V2Fly 配置中，AsIs 不表示所有域名永远不会解析；实际拨号或其他组件仍可能需要地址。若选择遇到域名未命中后再解析的策略，地址规则才有机会参与后续匹配，但也会增加解析依赖。应先明确分流目标，再选择策略，不要因为看见 DNS 报错就随机切换所有选项。

使用加密 DNS 时，还需要考虑解析服务器自身的域名如何获得地址，以及连接该服务器的请求走直连还是代理。若建立代理需要先解析节点地址，而解析请求又依赖尚未建立的代理，就可能形成启动循环。解决时应给启动阶段保留可达的解析路径，并遵循客户端对应设置的说明，不要简单叠加更多解析服务器。

分别处理 IPv6、缓存与 FakeDNS

有些网络会返回 IPv6 地址，但到目标的 IPv6 路径不完整，表现为等待后才回退或偶发超时。先确认设备是否真的具备稳定的 IPv6 连通性，再在支持的设置中比较地址族策略。临时改用 IPv4 可用于验证，但不能据此认定所有问题都应通过关闭 IPv6 解决；不同网络下的结果可能完全不同。

修改解析设置后，旧连接、应用缓存和系统缓存可能继续使用旧地址。先关闭相关页面与连接，再按系统提供的方式刷新缓存；不要频繁重启整台设备掩盖复现条件。涉及 FakeDNS 时，应用拿到的虚拟地址必须由对应内核还原域名，切换接管方式后残留的虚拟地址可能无法路由，需要让应用重新解析。

排查时先恢复简单、能够解释的解析路径，验证成功后再逐项加入复杂功能。日志中同时检查查询错误与最终出站，避免只看一条解析成功记录就忽略后续拨号失败。虚拟地址机制的原理与适用边界可阅读FakeDNS 原理详解，相关概念也可在名词解释中查阅。

系统代理不生效：检查接管与分流

系统代理、内核路由和透明接管是三个不同层次。系统代理告诉支持该设置的应用把请求交给哪里；路由决定内核收到请求后选择哪个出站；透明接管则尝试在其他层面导入流量。因此，把路由改为全局，不会让一个完全忽略系统代理的应用自动接入客户端。先证明请求进入了内核，再讨论它应该走哪条规则。

核对地址、端口与应用行为

在 v2rayN 中选择自动配置系统代理后，打开系统网络设置，核对代理地址与客户端实际监听是否一致。本机使用时通常指向回环地址，但端口必须以当前设置为准。不要把远端节点地址填写到系统代理栏，也不要把仅提供 SOCKS 的端口当成 HTTP 代理端口。若使用混合监听，应确认该监听确实支持应用使用的协议。

Windows 的不同应用可能读取不同代理配置，命令行工具也不一定沿用浏览器设置。macOS 的代理设置与当前网络服务相关，切换有线和无线连接后应重新检查。Linux 桌面环境、应用自身配置和终端环境变量之间也可能相互独立。因此，浏览器可用只能证明浏览器的路径正常，不能替其他程序作保证。

某些应用提供自己的 HTTP 或 SOCKS 设置，应优先确认它是否覆盖系统代理。浏览器扩展、开发工具和下载工具都可能保存旧地址。终端工具还可能读取代理环境变量及排除列表；排除规则命中后，请求会绕过指定代理。排查时查看具体进程的设置来源，不要只检查系统设置页面上的一个开关。

用局部规则检查顺序与出站

确认请求进入内核后，再看路由命中。多数规则按顺序匹配，前面的宽泛规则可能让后面的精确规则永远没有机会执行。下面是局部规则示例，表示将示例域名及其子域名交给名为 direct 的出站。只有完整配置中已经定义该出站标签时才可使用；不要把片段当成独立配置导入。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["domain:example.com"],
        "outboundTag": "direct"
      }
    ]
  }
}

规则的显示名称不一定等于实际出站标签，修改自定义规则前应检查生成配置。若应用先把域名解析成地址，入站只带有地址信息，域名规则可能无法匹配。流量探测在部分场景可以补充域名信息，但也受协议和配置限制，不能保证恢复所有请求的原始域名。应根据日志确认规则是否具备需要的匹配信息。

临时切换全局路由后恢复正常，通常说明原规则、解析结果或默认出站存在差异。下一步应恢复原模式，为单个失败域名添加精确对照规则，观察命中后是否恢复。不要直接清空全部规则或长期放大匹配范围，否则本应直连的局域网服务、工作网络和本地设备也可能受到影响。

排除多套代理相互覆盖

同时运行多个代理程序时，它们可能争用系统代理设置或本地端口；关闭其中一个后，另一个未必自动恢复接管。测试时只保留一个客户端，重新应用系统代理，再检查实际地址。若启用了透明接管或虚拟网卡模式，也应明确哪一层负责流量入口，避免形成请求循环或重复接管。

只有在确定应用不读取系统代理、且确有接管需求时，才考虑客户端支持的其他模式。需要权限的模式应按平台说明授权，不能用长期以管理员身份运行来替代定位。受管理设备上的系统代理还可能由组织策略设置，此时本地修改会被覆盖，应遵循设备管理要求，而不是反复强制改写设置。

恢复验证要覆盖原先失败的应用以及一个正常的直连服务，并确认客户端退出后网络仍能恢复。若仅局域网访问异常，检查排除列表、监听范围与规则顺序，不要直接开放全部入站接口。概念容易混淆时，可先查看路由与 DNS 术语，再回到本章核对每个设置所处的层次。

启动失败与崩溃：区分界面和内核

启动故障应先分成界面打不开、界面正常但内核退出、运行一段时间后整个程序结束三类。它们分别更可能涉及运行环境、配置或端口、资源与系统事件。先记录最后能看到的界面和完整错误，不要直接删除配置目录。客户端界面仍在运行时，托盘图标存在也不代表内核已经成功启动。

检查安装入口与系统架构

先回到客户端下载页，确认选择了对应平台和处理器架构。Windows 的桌面版与经典 WPF 版界面及运行环境可能不同，具体要求应以对应安装入口说明为准。macOS 要区分 Apple Silicon 与 Intel；Linux 要同时核对处理器架构和发行版的软件包格式，不能只根据文件扩展名相似就尝试安装。

如果系统报告缺少运行组件，先识别报错所指的组件与当前客户端分支，不要从不明来源复制动态链接库。Linux 图形程序还依赖桌面会话与相应图形环境，只有命令行环境时，图形界面无法出现不等于内核网络功能故障。安装包权限或系统安全提示也应按系统支持的流程处理，不要整体关闭防护。

若升级后出现异常，先完全退出旧实例，确认后台没有残留进程，再启动新程序。多个实例可能争用配置文件与监听端口。保留原配置备份，用独立的测试目录或客户端支持的新配置方式验证；不要把旧程序目录里的内核与新界面随意混用，否则会引入难以识别的兼容差异。

检查监听端口是否被占用

日志出现地址已被占用或无法绑定时，应先查占用者。下面用 10808 演示查询方法，不代表每个版本都默认监听该端口。Windows 命令在 PowerShell 中执行；macOS 与 Linux 的工具是否可用取决于系统安装情况。查询没有结果只说明当时未发现对应监听，仍需重新启动内核并观察日志。

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

# macOS
lsof -nP -iTCP:10808 -sTCP:LISTEN

# Linux
ss -ltnp 'sport = :10808'

获得进程标识后，先在系统进程工具中核对程序名称和路径，不要直接结束陌生进程。若是旧客户端实例，正常退出后重试；若是另一个仍需要运行的服务，可在客户端参数设置中改用未占用端口。修改后要同步更新系统代理和应用独立代理设置，否则内核虽然启动成功，请求仍会发往旧地址。

如果日志提示配置解析失败，应从第一条语法或字段错误开始检查。自定义 JSON 常见问题包括多余逗号、错误引号、字段层级不正确，以及出站标签不存在。先撤回最近一次修改，再重新生成配置。不要一次修复多处猜测，也不要把日志最后的退出提示当作根本原因，真正的错误通常出现在更前面。

定位运行中的退出与资源问题

运行一段时间才崩溃时，记录发生前是否刚更新订阅、切换网络、唤醒系统或开启详细日志。检查磁盘剩余空间、内存压力和配置目录是否可写。同步软件同时改写配置文件、目录权限变化或磁盘写入失败，也可能造成异常。避免把活动配置放在多个程序会同时修改的位置。

若界面退出而内核仍残留，先正常结束相关实例，再清理系统中指向旧监听的代理设置。仅删除桌面快捷方式不会终止后台进程。若系统提供崩溃事件记录，可按故障时间查找对应事件，记录异常模块和错误类型；分享记录前遮住用户名、个人路径以及可能含有节点参数的命令行内容。

在干净的测试配置中能正常启动，而恢复旧配置后必现，应按订阅分组、自定义路由、DNS 和其他扩展设置分批恢复。这样能够找到触发条件，而不是把所有旧设置一起搬回。端口冲突的具体处理可继续阅读定位冲突进程并修改监听端口。

安卓专项：授权、后台与分应用

Android 上的 v2rayNG 与 v2flyNG 通常通过 VpnService 接入应用流量，系统连接授权、后台策略和分应用规则都会影响实际效果。连接按钮变为运行状态，只能说明启动流程进入了相应阶段；仍应检查系统连接标识、通知和客户端日志。先区分刚启动就失败、锁屏后断连，还是只有部分应用不能使用。

确认 VpnService 授权与连接归属

首次连接时，系统会要求允许应用建立 VPN 连接，应确认授权对象就是当前使用的客户端。若弹窗没有出现或立即返回，检查是否被其他系统界面遮挡，或设备管理策略是否限制了连接。不要反复快速点击启动按钮，这可能让授权、停止和重新启动动作交错，反而使日志难以对应。

同一系统用户下，通常只能有一个应用承担当前 VPN 连接。其他使用同类接口的网络工具可能替换现有连接；反过来，启动 v2rayNG 也可能让另一条连接停止。排查时先停止其他同类工具，再启动目标客户端，确认系统显示的连接归属。不要同时运行 v2rayNG 与 v2flyNG 来比较节点，它们应分别测试。

系统如果启用了始终开启的 VPN 或阻止未经过 VPN 的连接，停止客户端后可能连直连访问也失败。这不是订阅自动损坏，而是系统策略仍在限制流量。检查系统 VPN 设置中的当前应用与相关选项，按照实际需求调整。工作资料与个人资料可能具有不同管理规则，应在出现问题的资料空间内检查。

锁屏后断连先查电源与数据限制

如果前台可用，锁屏一段时间后失败，先查看客户端进程是否仍在、通知是否消失、日志是否中断。系统省电策略可能限制后台网络，也可能结束进程。为当前客户端设置允许后台运行或合适的电池策略，并检查厂商提供的自启动与后台管理选项；不同系统菜单名称不同，应以设备当前界面为准。

允许后台运行不等于所有网络条件都放行，还应检查后台数据和流量节省设置。无线网络下正常、移动网络下失败时，确认客户端与目标应用都被允许使用相应网络。调整后重新连接，再锁屏复测相同时间与同一应用。一次解锁后恢复，不能证明后台问题已经解决，因为应用可能在回到前台时才重新建立连接。

若通知仍在但网络已经切换，可能是旧连接没有及时恢复。先记录无线网络与移动网络切换的时间，停止并重新启动连接做对照。若重新连接立即恢复，应重点观察网络切换恢复流程，而不是不断替换 DNS。设备进入深度省电、信号暂时中断和切换接入点，都可能影响已有长连接。

确认分应用列表表达的含义

启用分应用代理后，先看当前模式是仅所选应用经过代理，还是所选应用绕过代理。同一份勾选列表在相反模式下会产生相反结果，不能只看应用是否打勾。调整后应重新建立客户端连接，并完全退出目标应用再打开，以避免旧连接沿用原路径。新安装的应用是否自动包含在范围内，也取决于所选模式。

某些业务会调用系统组件、下载服务或独立登录进程，实际网络请求未必全部来自眼前的应用。排查时可短暂关闭分应用限制，验证完整接管是否正常；若恢复，则逐步缩小范围。不要仅凭主应用可打开首页就判断所有功能都成功，登录、附件下载和媒体播放可能使用不同请求路径。

从 v2rayNG 切换到 v2flyNG 时，需重新确认系统授权、分应用设置及协议兼容性。两者分别属于 Xray 与 V2Fly 内核路线，不能假定所有扩展参数都通用。优先使用与节点要求匹配的客户端，先验证一个明确受支持的条目，再恢复自定义设置。安装入口及架构选择见Android 客户端下载。