V2Ray 无法连接
故障排查大全

先建立可复现的诊断顺序

先判断故障发生在哪一层

V2Ray 客户端的一次连接至少经过基础网络、客户端界面、代理核心、远端节点、系统代理或虚拟网卡、DNS 解析和目标应用七个环节。页面打不开只是最终表现，不能直接说明节点失效。基础网络断开、核心没有启动、系统代理指向旧端口、节点参数不一致、域名解析异常，都可能产生相似结果。有效的排查方式不是反复切换所有开关，而是先确定故障边界：关闭客户端接管后普通网络能否访问；客户端日志里是否出现核心启动成功；本地监听端口是否存在；节点连接是在建立 TCP 时失败，还是在 TLS 或协议握手阶段失败；只有浏览器受影响，还是所有应用都受影响。

建议先写下四项现场信息：使用的平台与客户端、故障开始前做过的改动、受影响的应用范围、日志中第一次出现的错误。记录“第一次错误”比复制最后几十行更有价值，因为后续的连接关闭、重试失败通常只是连锁结果。若问题发生在更新订阅之后，还应保留旧配置组，不要立即删除。旧配置能够工作而新配置不能工作，排查范围可以直接收缩到订阅内容或新参数；新旧配置都不能工作，则应优先检查网络、系统代理与客户端运行状态。

用最小变量法复现

每轮测试只改变一个条件，并在改变后完整重连。比如测试节点时，先固定同一网络、同一客户端和同一路由模式，只切换一个节点；测试系统代理时，先固定一个已知可连接的节点，再分别比较“关闭系统代理”“自动配置系统代理”和“TUN 模式”。如果一次同时更换节点、更新订阅、切换内核并修改 DNS，即使恢复了连接，也无法知道真正起作用的是哪一项，后续故障还会重复出现。

最小测试环境应尽量简单：关闭重复运行的代理工具，退出会修改网络栈的调试软件，暂停浏览器中的独立代理设置，暂时使用客户端默认路由。桌面端优先使用 v2rayN 做基准测试；Android 可在 v2rayNG 与 v2flyNG 中按订阅所需内核选择。客户端安装来源与架构不确定时，先到下载页核对平台和安装类型。不要在核心无法启动的情况下继续研究路由规则，因为所有上层测试都会失去意义。

读取日志时抓住阶段关键词

日志要按阶段理解，而不是只搜索“error”。出现监听地址与端口，说明核心已经读取配置并开始接收本地连接；出现连接拒绝，通常表示目标端口没有服务或中间设备主动拒绝；出现超时，表示在规定时间内没有完成连接；出现证书域名不匹配、握手失败或服务器名称相关提示，应检查系统时间、SNI、TLS 与传输配置；出现 DNS 查询失败，则先处理解析链。日志可能包含服务器地址和订阅信息，转发给他人前应删除账号标识、认证字段和完整订阅地址。

开启客户端后完全无法上网

先区分基础网络故障与代理接管故障

第一步是关闭 v2rayN 的系统代理或退出 Android 客户端连接，但不要急着删除配置。随后用浏览器访问一个平时可正常打开的站点，并测试局域网网关。关闭代理后仍然无法访问，说明故障在基础网络、无线连接、网关或系统 DNS，继续切换节点没有意义。关闭代理后立即恢复，则说明客户端接管了流量，但本地代理没有正确转发。常见原因包括核心未启动、系统代理端口与实际监听端口不一致、所选配置不可用、路由把所有请求送入了错误出口。

桌面端还要观察故障影响范围。浏览器和系统组件都失败，优先检查系统代理；只有某个应用失败，检查该应用是否忽略系统代理、是否保存了独立代理地址；局域网地址也无法访问，检查路由模式是否错误地代理了私有地址。TUN 模式下所有应用一起断网，则重点查看虚拟网卡、路由表、DNS 接管和运行权限。不要把“系统代理”和“TUN”当成同一个功能：前者主要为遵循系统代理设置的应用提供入口，后者通过虚拟网卡接管更广泛的网络流量，两者的故障点不同。

确认本地核心与监听端口

v2rayN 界面显示已选择服务器，不等于代理核心已经成功运行。切换配置后查看日志开头，确认核心配置加载完成，并出现本地 SOCKS 或 HTTP 监听信息。如果日志提示地址已被占用，通常是另一个客户端进程、上次异常退出留下的后台进程，或其他软件占用了相同端口。先退出重复客户端，再通过系统工具查看端口占用。Windows 可以在终端运行以下命令，将示例端口替换为客户端设置中显示的本地端口：

netstat -ano | findstr LISTENING
netstat -ano | findstr :10808
tasklist /fi "PID eq 进程编号"

macOS 与 Linux 可使用 lsof -iTCP -sTCP:LISTEN 或 ss -lntp 查看监听状态。若端口没有出现，回到客户端日志处理核心启动错误；若端口存在，再测试系统代理是否指向相同端口。修改端口后必须重新应用系统代理，仅改客户端监听值而不刷新系统设置，会让应用继续连接旧端口并出现拒绝连接。

检查路由模式与错误残留

排查阶段先选择客户端提供的基础路由模式，不要从复杂自定义规则开始。若“绕过局域网及中国大陆地址”模式可以工作，而自定义模式完全断网，应检查规则顺序、默认出站和域名匹配。路由通常按顺序命中，过宽的阻断规则放在前面，会截断后续代理规则；只定义局部规则却没有合理默认出口，会让未匹配流量走向不明确。恢复连接后再逐条加回规则，每次至少测试域名、纯 IP、局域网地址三类目标。

Windows 在客户端异常退出后可能保留系统代理。此时浏览器仍尝试连接已经停止的本地端口，表现为退出软件后全站无法打开。重新启动 v2rayN 并关闭系统代理，或进入系统网络设置关闭手动代理即可。macOS 需要检查当前网络服务的网页代理与安全网页代理是否仍启用；Linux 桌面环境还可能分别保存 HTTP、HTTPS 与 SOCKS 设置。处理残留时只清理当前确认由客户端设置的代理项，不要随意重置全部网络配置。

节点超时、连接拒绝与握手失败

把三类错误分开处理

“超时”“连接拒绝”和“握手失败”指向不同阶段。超时表示客户端发起连接后长期没有获得预期响应，可能是地址不可达、端口被过滤、链路丢包或服务器没有回应；连接拒绝通常表示目标主机可达，但指定端口没有服务，或中间设备明确返回拒绝；握手失败则说明基础连接可能已经建立，问题发生在 TLS、协议认证、传输层或服务器名称校验阶段。若把三种情况都当成“节点失效”，就会错过本机时间、SNI、传输路径和参数复制错误。

先固定一个节点进行原始网络测试。域名节点要分别确认域名能否解析、解析结果是否稳定、端口是否可建立 TCP 连接。Windows 可使用 PowerShell 的 Test-NetConnection，macOS 与 Linux 可使用 nc。这些测试只判断网络与端口，不验证 VMess、VLESS、Trojan 或 TLS 参数，因此端口可达不代表完整代理一定可用，但端口不可达时应先处理地址、网络和服务端状态。

Test-NetConnection example.com -Port 443

nc -vz example.com 443

示例域名需要替换为配置中的服务器地址。若域名解析不到地址，转到 DNS 章节；若解析正常但端口持续超时，可换一个网络做对照。相同节点在不同网络下结果不同，说明问题更可能位于当前网络路径；所有网络都失败，且同订阅其他节点可用，则该节点本身或节点参数更可疑。

逐项核对协议与传输参数

手动配置时，服务器地址、端口、用户标识、加密方式、传输类型、路径、Host、TLS、SNI 和指纹等字段必须与服务端一致。订阅导入虽然会自动填充，但更新失败、格式转换或旧配置残留仍可能让字段不完整。检查时不要只比较地址和端口。WebSocket 路径多一个斜线、gRPC 服务名不同、TLS 开关不一致、SNI 使用了错误域名，都可能让 TCP 连接成功后立即断开。

TLS 相关错误首先检查系统日期、时间与时区。证书有效期判断依赖本机时间，偏差较大时会产生尚未生效或已经过期的判断。随后核对 SNI 是否为证书覆盖的域名，而不是随意填写服务器 IP。不要把跳过证书验证当作常规解决办法，它只会掩盖域名、证书或服务端配置问题。详细的证书错误类型可继续阅读TLS 证书错误排查清单。

理解客户端测试与真实访问的差异

客户端中的连通性测试、延迟测试和实际网页访问可能使用不同请求方式。某个测试失败但网页可用，不应只凭测试结果删除节点；测试成功但网页打不开，则要检查系统代理、DNS 与路由接管。排查时以真实应用请求和核心日志为主，同时记录测试方式。不要比较一次测试的瞬时结果，应在同一网络、同一路由和相近时间下重复验证。

如果一个订阅组中的所有节点同时出现握手失败，应优先检查系统时间、客户端核心、订阅内容是否发生结构变化，以及当前网络是否影响共同使用的域名或端口。如果只有单个节点失败，重点核对该条配置。若 v2rayN 在切换核心类型后开始报错，应确认配置使用的协议特性是否由当前核心支持。Xray 与 V2Fly 有共同来源，但对部分协议扩展的支持并不完全相同，不能只替换核心名称而假定所有配置兼容。

订阅更新失败或导入后列表为空

先确认订阅请求是否真正发出

订阅更新涉及订阅地址解析、网络请求、服务端响应、内容解码和配置转换多个阶段。提示“更新失败”时，先查看日志中的 HTTP 状态、超时信息或格式错误。请求超时通常说明当前网络无法访问订阅地址，或更新请求没有按预期经过可用代理；返回未授权或禁止访问，通常与链接失效、账号状态、访问限制有关；返回成功但列表为空，则要检查响应内容是不是客户端支持的订阅格式。

复制订阅地址时要保留完整查询参数。聊天工具、笔记软件或浏览器地址栏可能截断末尾字符，也可能把特殊字符转换成可见文本。建议从原始来源重新复制，再在客户端中覆盖原地址。订阅地址属于账号凭据的一部分，不应发布到公开页面或截图中。为订阅分组设置名称只影响本地识别，不会修复远端链接；同名分组也不表示两个链接内容相同。

区分直连更新与经代理更新

部分环境下订阅地址需要通过已经可用的代理访问。如果客户端尚无任何可连接配置，而更新又依赖代理，会形成“需要订阅才能连接、需要连接才能更新”的循环。解决方式是保留一个已知可用的旧配置，先连接后更新；或者按服务提供方给出的方式导入初始配置。不要在更新失败时立即清空全部服务器列表，因为旧配置往往是恢复订阅请求的唯一基准。

v2rayN 的订阅更新选项可能允许使用系统代理或当前代理，具体行为应结合日志确认。若日志中的订阅请求直接超时，而浏览器在代理开启后可以打开相同域名，说明客户端更新路径可能没有经过代理。Android 上还要确认 v2rayNG 或 v2flyNG 在后台执行更新时拥有网络权限，并且没有被系统的数据限制阻断。切换无线网络与移动网络进行对照，可以快速判断是否为当前接入网络的问题。

处理“更新成功但没有节点”

更新成功只说明请求和解析流程没有抛出明显错误，不保证内容包含有效节点。先检查分组是否被筛选、节点是否进入其他分组、界面是否保留了搜索关键词。取消筛选后仍为空，再查看响应内容类型。常见订阅可能是经过编码的链接集合、结构化配置或客户端专用格式；如果服务端返回登录页面、错误说明或空文本，客户端可能只显示格式无法识别。

当旧节点在更新后全部被替换，可查看订阅设置中的更新策略。覆盖更新适合由订阅统一维护的分组，本地手工修改的节点则不应混在同一自动覆盖分组中。若需要保留本地参数，先复制到独立分组，再执行更新。关于桌面端和 Android 端的标准导入入口，可参考订阅链接导入步骤；自动更新间隔、代理更新与失败原因可参考订阅更新失败处理方法。

连接成功但速度慢或波动明显

先排除测试方法造成的误判

速度问题要在可比较的条件下判断。单个网页加载慢可能来自目标站点、浏览器扩展、缓存或图片资源，不等于代理链路整体变慢。建议选择同一网络、同一设备和同一下载目标，分别测试关闭代理、开启代理且固定节点、切换另一个节点三种状态。每轮测试前停止后台同步、大文件更新和云盘任务，并避免同时运行多个测速工具。对比重点是稳定吞吐、首次连接时间和长连接是否中断，而不是只看一次瞬时峰值。

如果关闭代理也慢，先处理本地无线信号、路由器负载和运营商链路。直连正常而所有节点都慢，检查客户端路由、TUN、DNS 与设备资源；只有单个节点慢，则更可能是该节点线路、拥塞或远端负载。桌面端与 Android 在同一网络使用同一配置时都慢，可以把设备因素降低优先级；只有一台设备慢，则检查该设备的省电、后台限制、虚拟网卡和安全软件。

分清延迟、带宽与丢包

延迟影响连接建立和交互响应，带宽影响持续传输速度，丢包会导致重传和明显波动。三者不是同一个指标。一个连接建立较慢但持续下载稳定的节点，可能延迟较高而带宽足够；一个初始响应快但传输反复下降的节点，可能存在拥塞或丢包。客户端的基础测试只提供有限参考，最终应以实际使用场景验证。不要根据一次延迟排序频繁自动切换节点，频繁切换会让已有连接中断，也会让排查样本失去一致性。

协议封装、TLS、传输方式和路由路径都会增加开销，但通常不应仅凭协议名称判断快慢。相同协议在不同服务器、网络与时间段的表现可能完全不同。先选择参数正确、连接稳定的节点，再比较网络路径。若日志中持续出现连接重置、重试或写入超时，速度下降可能是连接质量问题，而不是设备算力不足。

检查 TUN、MTU 与路由绕行

TUN 模式会接管更多流量，也增加虚拟网卡、DNS 和路由处理环节。系统代理模式正常而 TUN 明显变慢时，先检查是否存在其他虚拟网卡、重复路由或安全软件过滤。某些网络下 MTU 不合适会表现为小网页可打开、大文件卡住、特定站点加载不完整。不要随意把 MTU 调到极端值，应先恢复客户端默认，再按当前网络逐步测试较小值，并在每次修改后重新连接。

分流规则也可能造成绕行。目标域名先被远程 DNS 解析到与预期不同的地址，再被 IP 规则二次匹配，可能改变出站方向。复杂规则集之间存在重叠时，应查看日志中的路由命中结果。排查阶段可暂时使用简单模式，确认速度恢复后，再逐项加入域名规则、IP 规则和远程 DNS。规则越多并不代表判断越准确，清晰的优先级比规则数量更重要。

检查设备资源与并发

桌面端出现高占用时，先确认消耗资源的是界面进程、代理核心还是其他应用。大量并发连接、持续日志输出、TUN 接管和实时安全扫描都可能增加负载。关闭不必要的详细日志，减少重复运行的客户端，并确保系统没有同时启用多套代理。Android 设备在省电模式、温度较高或后台受限时，连接可能被降频或暂停；将客户端加入允许后台运行的范围后再测试。

如果慢速只发生在特定应用，检查应用是否使用 QUIC、独立 DNS 或自带代理。可临时比较浏览器与系统下载工具的表现，判断问题是否局限在应用层。若所有应用在固定时间段同时变慢，记录发生时段、网络类型和节点组，不要不断修改客户端。稳定复现后，才能区分本地配置与外部链路变化。

DNS 解析失败、污染缓存与分流错位

识别 DNS 故障的典型表现

DNS 问题常表现为域名打不开但直接访问已知 IP 有响应、部分域名间歇失败、客户端日志出现 lookup 或 resolve 错误、切换网络后短暂恢复。还可能出现更隐蔽的分流错位：域名解析成功，但返回地址被错误规则匹配，导致流量走向与预期不同。排查 DNS 时要同时回答三个问题：查询由谁发起、发送到哪个 DNS、解析结果如何参与路由。

先关闭代理测试系统 DNS，再开启客户端比较结果。Windows 可使用 nslookup 或 PowerShell 的 Resolve-DnsName；macOS 可使用 dig 并通过 scutil --dns 查看系统解析器；Linux 可使用 resolvectl query 查看 systemd-resolved 的查询结果。测试时记录域名、返回地址和所用服务器，避免只写“DNS 不通”。

nslookup example.com
Resolve-DnsName example.com

dig example.com
scutil --dns

resolvectl query example.com
resolvectl status

清理缓存之前先保存证据

系统、浏览器、客户端核心和应用都可能缓存解析结果。立即清空所有缓存虽然有时能暂时恢复，但会丢失判断线索。建议先比较系统工具与浏览器结果：系统工具返回正常而浏览器失败，检查浏览器安全 DNS、扩展和自身缓存；系统工具与客户端日志结果不同，检查客户端内置 DNS；所有工具都失败，再检查当前网络提供的 DNS 和网络连通性。

确认需要清理后，Windows 可执行 ipconfig /flushdns；macOS 可以重启当前网络服务或刷新系统解析缓存；Linux 根据实际使用的解析服务重启对应组件。清理后应重新发起查询并记录结果。如果每次清理只能短暂恢复，说明根因不是缓存本身，而是上游 DNS、规则或网络持续返回异常结果。

核对客户端 DNS 与路由的关系

V2Ray 配置中的 DNS 不只是“填一个服务器地址”。查询可能按域名规则选择本地或远程解析器，返回的 IP 又可能继续参与 IP 路由匹配。如果域名先按本地解析，但访问流量按代理规则发送，解析结果与代理出口看到的目标可能不一致；如果启用 fake DNS 或 TUN DNS 接管，还要确认虚拟地址能够被核心正确还原。排查时先关闭复杂的域名分流与 fake DNS，使用一个明确的解析路径验证，再恢复高级设置。

下面示例展示 Xray 风格配置中一个简化的 DNS 结构。实际服务器地址与查询策略应依据网络环境设置，重点是保留明确的本地与远程职责，并让路由规则与 DNS 标签对应：

{
  "dns": {
    "servers": [
      {
        "address": "1.1.1.1",
        "domains": ["geosite:geolocation-!cn"]
      },
      {
        "address": "223.5.5.5",
        "domains": ["geosite:cn"]
      }
    ],
    "queryStrategy": "UseIP"
  }
}

配置示例不能直接覆盖现有完整配置，因为内核类型、规则资源和网络条件可能不同。若当前客户端由订阅管理，优先通过界面中的 DNS 与路由设置调整，避免手工编辑后被下一次订阅更新覆盖。使用 V2Fly 内核的 v2flyNG 时，也要确认相关字段属于当前内核支持范围。

处理浏览器与系统结果不一致

现代浏览器可能启用独立安全 DNS，从而绕过系统解析路径。若系统命令能解析、浏览器却访问错误地址，先在浏览器网络设置中确认解析方式，并暂时关闭扩展做对照。某些应用会缓存连接和解析结果，即使系统 DNS 已更新，旧进程仍继续使用原结果；完全退出应用后重开，比只刷新页面更可靠。

TUN 模式下如果只有域名失败而纯 IP 请求可达，检查 DNS 流量是否被虚拟网卡接管、53 端口是否被其他软件占用，以及系统中是否存在多个活动网络接口。无线、网线、虚拟网卡同时在线时，系统可能把 DNS 请求发送到优先级更高但不可用的接口。先停用无关接口进行验证，再调整长期接口优先级。

系统代理不生效、部分应用不走代理

确认系统设置与客户端监听一致

系统代理本质上是把支持该设置的应用请求引向本地 HTTP 或 SOCKS 端口。客户端显示“系统代理已开启”时，仍要核对系统设置中的地址和端口是否与核心实际监听一致。通常本机地址应指向回环接口，端口应与 v2rayN 设置页和日志中的监听端口相同。若修改过端口、切换配置目录或同时运行多个实例，系统可能仍保存旧值。

Windows 可在系统网络代理页面查看手动代理，也可用命令检查 WinHTTP 状态：

netsh winhttp show proxy

需要注意，Windows 的用户级系统代理与 WinHTTP 代理并非完全相同。浏览器能通过用户代理访问，不代表系统服务或命令行工具会使用同一设置。macOS 的代理按网络服务保存，切换无线网络与网线后应分别检查；Linux 桌面环境、终端环境变量和单个应用也可能各自维护代理配置。排查时要先明确目标应用读取哪一套设置。

处理只有部分应用直连

部分应用不遵循系统代理，或只支持 HTTP 代理而不读取 SOCKS 设置。此时节点和核心可以完全正常，但应用流量仍直接连接。先用浏览器验证本地代理，再检查目标应用是否提供独立代理选项。若应用支持代理，填写客户端的本地监听地址和对应协议端口；若不支持且确实需要接管，可评估使用 TUN 模式。不要为了一个应用修改所有路由规则，先确定它是否进入了本地代理入口。

命令行工具通常读取环境变量。临时测试时可以只在当前终端设置，关闭终端后自动失效。以下示例使用本地 HTTP 端口，端口应替换为客户端实际值：

set HTTP_PROXY=http://127.0.0.1:10809
set HTTPS_PROXY=http://127.0.0.1:10809

export http_proxy=http://127.0.0.1:10809
export https_proxy=http://127.0.0.1:10809

前两行适用于 Windows 命令提示符，后两行适用于 macOS 与 Linux 常见 shell。测试结束后清除变量，避免以后在客户端未运行时继续指向失效端口。应用内代理、环境变量与系统代理叠加时，通常以应用自身设置优先，因此系统设置正确却仍失败时，要检查应用是否保存了旧代理。

区分 PAC、全局代理与 TUN

PAC 或自动配置模式根据规则决定哪些请求使用代理，适合遵循系统代理并支持自动配置的应用。全局系统代理通常把更多受支持的请求交给本地端口，但仍不能覆盖完全忽略系统代理的程序。TUN 通过虚拟网卡处理更广泛流量，代价是需要正确的路由、DNS 和权限配置。选择模式应依据应用范围，不应把 TUN 当成修复所有问题的第一步。

若 PAC 模式下部分站点不走代理，而全局模式可以，问题多半在 PAC 规则、缓存或应用对 PAC 的支持。先刷新系统代理设置并重启目标应用，再核对规则匹配。若全局系统代理也不生效，但直接在应用中填本地端口可以工作，说明系统配置没有被该应用读取。若 TUN 开启后所有应用都断网，回到第二章检查虚拟网卡与路由，而不是继续修改节点。

客户端无法启动、闪退或核心反复退出

先区分界面进程与核心进程

v2rayN 由图形界面与代理核心协同工作。界面可以正常打开，但核心可能因配置错误、端口占用或权限问题立即退出；反过来，核心残留在后台时，重新打开界面又可能提示端口占用。排查时先观察任务管理器或系统进程列表，确认哪个进程退出。界面闪退应查看应用日志与系统事件，核心退出则优先查看客户端日志中启动命令之后的第一条错误。

配置文件损坏是常见原因之一。若问题发生在导入新节点、编辑路由或更新订阅之后，先切回之前可用的配置。不要直接删除整个配置目录；先复制备份，再让客户端以新的空白配置启动。空白配置可以启动，原配置加载即退出，说明问题集中在配置内容或数据库。空白配置也无法启动，则检查运行环境、权限、文件路径和安全软件处理记录。

检查端口、路径与运行权限

核心启动时需要读取配置、加载规则资源、创建日志并监听本地端口。安装目录没有写入权限、路径被同步软件锁定、文件被其他程序占用，都可能导致启动失败。桌面端建议把客户端放在当前用户可读写的常规目录，避免从压缩文件预览窗口直接运行。下载平台或架构选错也可能造成程序无法执行，可前往下载页重新核对 Windows、macOS、Android 与 Linux 对应入口。

端口占用可按第二章的方法查看。若发现旧核心进程，先正常退出客户端，等待进程结束后再启动；进程无法结束时再通过系统工具停止。不要通过不断更换随机端口掩盖重复进程，因为系统代理和应用内代理可能继续指向旧端口。修改端口后要同步更新系统代理，并检查防火墙是否允许本地回环通信。

处理升级后启动异常

升级客户端后出现异常，常见原因包括旧配置字段与新界面不兼容、运行依赖变化、核心文件未完整替换或旧进程仍在占用文件。先完全退出客户端和核心，再重新启动。若仍失败，备份订阅地址、路由与必要设置，使用新目录启动当前安装包，然后逐项导入。不要直接把旧目录全部覆盖到新目录，否则可能把损坏文件和不兼容配置一起带回。

v2rayN 桌面版与经典 WPF 版的界面技术和平台范围不同，遇到显示或运行环境问题时，应先确认使用的是哪一版，而不是在两版目录之间混合配置文件。两者差异可参阅v2rayN 桌面版与 WPF 版选择说明。切换版本前备份订阅与自定义规则，再用独立目录测试，能够避免旧文件干扰。

分析崩溃是否由资源或规则触发

客户端只在更新订阅、测速或开启 TUN 时退出，说明故障可能由特定操作触发。订阅包含大量配置时，解析、去重与测试会产生更高瞬时资源占用；复杂路由资源加载失败，也可能让核心启动后立即停止。先关闭自动测速与自动更新，使用单个手工配置验证基础运行，再逐项恢复功能。若只在某一订阅组发生，保留日志并检查该组是否含异常字段。

日志持续快速增长会占用磁盘并影响运行。排查时可以短期开启详细日志，复现后立即恢复正常级别，并保存关键片段。不要长期保留包含完整连接信息的调试日志。若系统磁盘空间不足，客户端可能无法写配置或更新资源，应先释放空间并确认目录可写。

形成可恢复的配置管理习惯

稳定运行后，应分别保留订阅地址、自定义路由和客户端设置的备份，避免把所有恢复希望放在同一个程序目录。更新前记录当前使用的客户端类型、核心类型和关键端口，出现问题时才能准确回退。备份内容应放在受控位置，不公开分享订阅地址或认证字段。

如果客户端能够以空白配置稳定运行，逐项恢复的顺序建议为：先添加单个节点并验证连接，再添加订阅，再恢复系统代理设置，最后加入自定义 DNS、路由和 TUN。每一步都启动一次并查看日志。这样即使再次崩溃，也能明确是哪一类配置触发，而不必从整个目录重新猜测。

Android 上的连接中断与后台限制

确认虚拟网络授权与客户端状态

v2rayNG 与 v2flyNG 在 Android 上通常通过系统虚拟网络接口接管流量。首次连接或系统重置授权后，系统会要求确认连接权限。客户端界面显示正在启动却没有形成有效连接时，先查看是否有被遮挡的授权对话框，再确认状态栏中的虚拟网络状态。若另一款网络工具正在占用同类接口，需要先断开旧连接，再启动当前客户端。

导入配置后必须明确选中一个节点。订阅分组存在并不表示已经选择可连接配置；更新成功也不代表核心已启动。连接后打开日志，确认核心加载配置、建立本地入口并尝试连接远端。若日志在启动阶段直接报配置错误，先用一个结构简单的节点验证，不要同时开启分应用代理、复杂 DNS 和自定义路由。

处理锁屏后断开与后台被停止

Android 的省电策略可能在锁屏、待机或内存紧张时限制后台进程。典型表现是前台使用正常，锁屏一段时间后连接失效，重新打开客户端又恢复。应在系统的电池与后台管理中允许 v2rayNG 或 v2flyNG 持续运行，并确认没有被自动休眠。不同设备的设置名称不同，但判断方法一致：保持同一节点，分别测试亮屏前台、锁屏短时和锁屏较长时间，观察客户端进程与连接状态是否被系统停止。

只把应用锁定在最近任务列表不一定足够，还要检查后台网络、数据节省和省电限制。无线网络在休眠时被关闭，也会造成连接中断；切换到移动网络后客户端可能需要重新建立连接。网络切换后的短暂重连属于正常过程，若长时间不恢复，可手动断开再连接，并查看日志是否仍在使用旧网络接口。

检查分应用代理与绕过设置

分应用代理允许只接管指定应用或排除部分应用，但选择逻辑配置错误时，会出现“浏览器可用、其他应用直连”或相反结果。先关闭分应用功能，验证全局接管是否正常；正常后再启用，并确认当前模式是仅代理选中应用还是绕过选中应用。应用更新、重装或工作资料空间可能改变应用标识，原列表不一定继续匹配。

若只有系统组件或某个应用无法连接，检查它是否被排除、是否使用独立 DNS、是否限制虚拟网络。不要通过不断切换节点处理明显的应用范围问题。分应用列表修改后应重新连接，使路由规则完整重载。工作资料与主用户空间可能拥有独立网络策略，应分别验证，不要假定一处设置对所有空间生效。

在无线网络与移动网络之间做对照

同一节点在无线网络可用、移动网络超时，或结果相反，说明配置本身可能有效，差异来自接入网络、DNS、地址族或 MTU。分别记录两种网络下的域名解析、连接错误和使用的传输方式。若移动网络优先使用 IPv6，而节点域名返回的地址不可达，可检查客户端地址策略与 DNS 查询策略；若无线网络存在需要网页认证的门户，应先关闭客户端接管完成认证，再重新连接。

网络切换时旧连接可能保留在原接口，导致短时间内请求失败。先等待客户端自动重连；仍未恢复时，断开并重新连接一次。若每次切换都必须重启应用，检查系统是否限制后台网络变化通知，并确认客户端没有被冻结。不要频繁清除应用数据，这会删除订阅、分组和路由设置，却未必解决网络切换问题。

选择 v2rayNG 与 v2flyNG 的排查基准

Android 首先根据配置所需内核选择客户端。v2rayNG 使用 Xray 内核，适合需要 Xray 相关协议特性的配置；v2flyNG 使用 V2Fly 内核，可作为对应生态配置的选择。两款客户端同时安装时，不要同时连接，也不要假定同一配置在不同内核下具备完全一致的支持。对照测试应固定网络和节点，只更换客户端，并记录具体错误。

若 v2rayNG 能连接而 v2flyNG 不能，或结果相反，先核对协议与传输特性是否由对应内核支持，而不是把问题归因于手机网络。关于 Xray 与 V2Fly 的功能边界，可阅读Xray 与 V2Fly 内核区别。需要重新安装时，到Android 下载入口选择与设备架构匹配的版本，保留原订阅信息后再迁移。