v2rayN 故障排查大全

无法上网：先确认请求停在哪一层

“客户端已运行”与“应用已通过代理联网”是两件事。一次连接通常经过应用、系统代理或虚拟网卡、本地入站、路由规则、远端节点，最后才到目标服务。任何一层没有接上，表现都可能是网页打不开。排查时先记录失败范围：所有应用都失败，还是只有一个浏览器；所有网站都失败，还是只有某个域名；关闭客户端后普通网络是否恢复。这个范围比单独一条错误提示更能缩小问题。

建立普通网络与代理网络的对照

先退出其他代理工具，关闭 v2rayN 的系统代理与 TUN，检查普通网络能否打开平时可直接访问的页面。若此时也失败，应先查看网络连接、网关、无线认证页面和系统 DNS，不要继续换节点。公共无线网络有时需要先完成登录；代理启动后，认证页面反而无法显示。确认普通连接正常后，再启动 v2rayN，选择一个已有配置的节点，打开系统代理，用同一个浏览器访问同一个测试页面。

随后打开客户端日志，清空当前显示或记下开始时间，再发起一次请求。若没有新增连接记录，优先检查应用是否使用了系统代理、本地端口是否正确、浏览器是否被扩展接管。若日志已有目标域名与出站记录，请求至少进入了内核；接下来应看错误发生在解析、远端拨号、握手还是目标响应阶段。日志级别设为信息通常够用，只有定位具体问题时才短暂提高详细程度。

绕开系统代理，直接测试本地入站

下面用 SOCKS 入站做对照，端口必须改成客户端设置里实际显示的值。示例的 10808 不是所有安装的固定端口。Windows 可在终端使用 curl.exe，macOS 与 Linux 通常使用 curl。测试地址只是用于观察连接是否完成，不代表所有业务都正常；返回某种 HTTP 状态也不等于代理出错，要结合连接是否建立判断。

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

第一条显式指定代理，第二条绕过代理，两次结果应分别记录。socks5h 让目标域名交给代理侧处理，能避免把应用本地解析混进这次测试。如果第一条提示连接本地端口失败，先检查内核是否启动和监听；如果代理请求成功而浏览器失败，则问题更可能在浏览器代理设置、扩展或缓存。不要把 HTTP 入站端口当成 SOCKS 端口，两种协议混用可能得到空响应或协议错误。

区分路由错误与目标服务故障

请求进入内核后，查看它实际选择了 direct、proxy 还是 block。某个网站误入 block 时，换节点没有意义；应该找出命中的域名规则。误入 direct 时，也可能表现为连接超时。可以暂时切换到简化的代理路由，复测同一请求；若恢复，再逐条恢复原规则。这个对照只用于定位，不建议长期把所有请求都交给同一个出站，尤其要保留局域网与节点服务器地址的合理直连路径。

如果多个常用服务正常，只有一个目标失败，还应考虑目标站维护、账户限制、服务端区域策略或浏览器会话异常。使用另一个浏览器会话以及同一网络下的另一台设备进行对照，比反复重装客户端更有效。最终验证应包含一个代理目标、一个直连目标和一个局域网目标，并确认日志中的出站符合预期。连接恢复但路由错误，仍不算完整修复。

节点超时：拆开地址、端口与握手问题

节点测试超时不一定表示服务器停止运行。客户端的测试可能包含域名解析、建立传输连接、协议握手和访问测试地址，其中任何一步失败都可能归为超时。先区分是所有节点同时失败，还是只有一个配置失败；是当前网络失败，还是换到另一条网络也失败。所有节点同时异常时，本地网络、DNS、代理循环或测试地址更值得先查；单个节点异常时，再逐项核对该节点参数。

核对连接目标，避免把参数填在错误位置

打开节点编辑页，按服务提供方给出的配置检查服务器地址、端口、协议、传输方式与安全设置。服务器地址一般是域名或 IP，不应带网页协议前缀，也不应夹入路径。WebSocket 的路径、Host 与 TLS 的 SNI 是不同字段，不能因为文字看起来相似就互相替代。端口必须是远端服务监听端口，本地 SOCKS 端口只供应用连接客户端，填到服务器端口位置会把连接送往错误服务。

若节点来自订阅，先更新订阅再检查，避免继续使用已迁移的地址。但更新会覆盖订阅管理的节点，手工修改前应另存一个用于对照的副本。比较时只改一项，不要同时改传输、端口与安全参数。密码、用户标识、公钥等字段即使格式正确，也可能与服务器不匹配；这类错误无法通过延长超时时间修复，需要从有效配置重新导入。

用错误类型判断连接到了哪一步

日志出现 connection refused，通常说明连接尝试得到了拒绝响应，检查端口、服务状态与中间设备策略；i/o timeout 或拨号超时，只能说明在等待时间内没有完成预期操作。network is unreachable 更接近本地路由或地址族问题。不要把这些提示都解释成同一种原因，也不要仅凭服务器不响应 ping 就认定代理不可用，服务可以不允许那类探测而仍接受正常连接。

若 TCP 连接已经建立，随后出现 TLS 或认证错误，应转查握手参数。先同步系统时间，再核对 SNI、证书对应的域名以及客户端所选传输是否与服务器一致。REALITY 配置还需核对公钥、短标识、服务器名称和指纹等字段，并确认所选内核支持该组合。为了减少变量，排查时沿用提供方明确支持的设置，不要临时把另一种协议的参数拼进当前节点。

排除网络路径与代理循环

用同一个节点在另一条可信网络下测试。若手机热点可用而当前无线网络失败，重点检查当前网络的出口限制、地址族支持与防火墙；若各网络都失败，应回到配置和远端服务。切换网络后重新建立连接，不要沿用旧网络上的会话。节点域名同时返回不同地址族时，某个地址可解析但不可达也会拖慢连接，先确认实际拨号地址，再决定是否调整地址选择策略。

启用 TUN 后才超时，常见原因之一是连接节点服务器的流量又被送进代理，形成递归路径。应确认节点服务器地址被正确排除，或者由客户端维护了相应直连路由。另一个原因是订阅地址或节点域名的解析依赖一个尚未建立的代理出站，形成启动依赖。先关闭 TUN，用普通网络完成解析与订阅更新，再逐项恢复，可帮助区分这种问题与真正的远端不可达。

最后要分开验证节点连接与业务访问。客户端测试地址异常，可能让多个正常节点一起显示失败；实际网页可访问时，应检查测试地址和测试方式，而不是立即删除所有节点。保存报错发生时间、使用的网络与错误类别，向服务提供方反馈时隐藏访问凭据。证书相关分支可继续阅读TLS 握手与证书报错排查，修复后再恢复原来的路由与运行模式。

订阅失败：区分下载、解析与节点更新

订阅导入包含三个环节：保存地址、下载订阅内容、把内容转换成节点列表。界面能保存链接，不代表下载成功；下载得到一段文字，也不代表它是客户端能解析的节点格式。先确认错误发生在哪个环节，以及更新后列表是否真的变化。已有节点仍能连接而订阅更新失败时，应保留可用配置，优先修复更新通道，避免删除整组节点后失去排查所需的连接路径。

先检查地址和服务状态

在订阅分组设置中核对完整地址，特别留意复制时混入的换行、前后空格和中文标点。有些地址带查询参数或访问令牌，不能只保留问号前面的路径，也不要自行修改其中的字符。浏览器打开的管理页面与订阅接口不一定相同，应使用服务提供方明确标记的订阅地址。链接已过期、订阅账户状态改变或访问令牌重置，都可能让原地址返回错误页面。

观察响应类别有助于定位问题。未授权或禁止访问通常与凭据、账户权限或服务策略有关；找不到资源可能是路径已变；限流则应降低更新频率，等到允许的时间再试。服务器临时错误不应通过修改节点密码解决。即使响应状态看似成功，也可能下载到登录页面或提示文本，需要看客户端的解析错误，确认收到的内容不是一份网页。

解决“订阅要代理，代理又等订阅”的依赖

部分订阅地址在当前网络无法直接访问，需要通过已可用的代理更新。此时选择客户端提供的经代理更新方式，并确认当前节点确实能连接。若刚安装客户端、列表为空，经代理更新会因缺少可用出站而失败。可以先使用提供方给出的单节点配置完成首次连接，再更新订阅；没有独立可用配置时，应联系提供方确认可访问的订阅入口，不要反复切换无效节点。

反过来，原本可直连的订阅地址经代理更新失败，也可能是代理侧 DNS、证书或出口访问限制。对同一地址分别尝试直连更新与经代理更新，并记录结果。只有一个方式失败时，就能把问题收窄到下载路径。若浏览器能打开但客户端不能，还应检查浏览器是否使用了不同代理、登录会话或自动重定向；浏览器携带的账户状态不一定会传给客户端订阅请求。

检查格式，不把解析失败当成网络超时

v2rayN、v2rayNG 与 v2flyNG 对协议和配置格式的支持取决于各自实现与所用内核。服务提供方可能为不同客户端准备不同入口，下载到另一种配置文件时，即使内容完整也可能无法导入。先确认订阅入口面向当前客户端，并查看错误是格式无法识别、部分节点不支持，还是整份内容为空。遇到不支持的字段，不要随意删掉安全参数来换取导入成功，这可能改变原连接的含义。

更新成功却“没有新节点”时，检查当前选中的订阅分组、搜索筛选和排序条件。某些更新会替换节点标识，原来选中的节点可能不再存在，应重新选择并应用。节点名称不变，也不说明服务器地址和参数没有更新，可以对照配置详情。若只剩部分节点，先检查是否因为协议支持差异或订阅服务返回了不同内容，再判断是不是客户端丢失了数据。

控制更新频率并验证实际结果

不要把连续点击更新当成重试策略。频繁请求可能触发服务限流，也会让日志难以对应某一次操作。先暂停自动更新，进行一次手动请求，记下时间、使用的下载路径与报错，再处理明确原因。恢复自动更新时，设置合理间隔，并避免多台设备在短时间内反复请求同一地址。网络刚恢复时，可以先检查节点连接，再更新订阅，减少失败请求相互叠加。

修复完成后应确认分组更新成功、节点可以选中、内核加载了新配置，再做一次实际连接。订阅通常负责同步节点，不保证桌面与安卓的路由、DNS、应用分流和 TUN 设置完全一致。电脑更新成功不能替代手机端验证；跨设备同步的边界可查看v2rayN 与 v2rayNG 多设备配置同步。保存可用配置的安全备份，但不要把含凭据的导出文件放进公开目录。

速度慢：区分建立连接慢与持续传输慢

速度问题至少有三种表现：首次打开页面等待很久、开始传输后持续缓慢、连接偶尔停顿再恢复。它们分别可能与 DNS 和握手、持续带宽和拥塞、网络切换或丢包有关。先描述实际症状，而不是只记一个测试结果。小文件很快、大文件慢，与每个网站首次打开都慢，是两条不同的排查路径。测试应使用相同节点、相同目标与相同设备，避免把目标服务器差异误算成节点性能差异。

固定条件，建立可以复现的对照

关闭正在占用网络的同步、下载和系统更新，再重复一次原来的业务操作。无线网络环境下，靠近接入点做一次对照；有条件时比较有线连接与无线连接。若普通直连业务也慢，应先处理本地网络。若只有代理业务慢，再比较同一网络下的两个有效节点。不要一边切节点一边改 DNS 和路由，那样即使恢复也难以判断是哪项修改起效。

测试目标也要固定。不同下载站可能限制单连接速率，网页包含的第三方资源也可能位于不同网络。一项速度测试不能代表视频、会议与文件下载的全部表现。记录首次响应的等待、开始传输后的稳定程度以及是否反复重连，通常比追求某个瞬时峰值更实用。同一个节点在不同时间表现不同，可能与网络拥塞有关，需要在相近条件下重复观察，而不是立即重装客户端。

首次打开慢，先查 DNS、握手和错误重试

页面首次打开缓慢、再次访问明显改善，优先观察解析时间、地址选择和连接复用。节点域名或目标域名有多个地址时，客户端可能先尝试一个不可达地址，等待失败后才换另一个。日志中重复拨号、握手失败或解析超时，都比“测速偏低”更接近原因。检查系统时间、传输参数与 DNS 路径，确认没有依靠不断重试才偶然建立成功。

如果多数页面主体很快，但图片、字体或脚本长期等待，可能是资源域名被路由到不同出站，或者某条拦截规则影响了页面依赖。可以在浏览器网络面板里观察失败资源的域名，再对照客户端日志，不要直接把整个网站都归为节点慢。短暂切换简化路由后若恢复，就逐条检查规则顺序和规则集内容。具体域名规则应放在更宽泛规则之前，避免被前面的条件提前匹配。

持续传输慢，检查拥塞、设备资源与传输条件

传输开始后稳定但缓慢，先看本机处理器、内存和磁盘是否接近负荷上限。后台大量连接、过度详细的日志、实时扫描或设备节能模式都可能增加开销。移动设备发热后还可能降频，造成同一连接越来越慢。桌面端应在正常电源模式下复测，安卓端同时注意温度与后台任务。减少不必要的并发，比盲目叠加多个优化选项更容易得到可解释的结果。

只在 TUN 模式下大文件停顿，而系统代理模式正常时，应考虑虚拟网卡路径、MTU 与额外封装。路径能通过小数据包，却无法正常处理较大报文时，会出现建立连接成功但传输卡住的现象。不要直接套用网上的固定 MTU 数值；先比较两种模式，确认问题确实随虚拟网卡路径出现，再按客户端提供的设置做小幅、可回退的调整，并用原业务复测。

协议名字不能直接决定速度。VMess、VLESS、Trojan 与 Shadowsocks 的表现还取决于传输组合、服务器负荷和网络路径。仅更换协议而没有可匹配的服务器配置，不会产生有效优化。可先阅读代理协议区别与使用场景，理解参数边界，再按服务提供方支持的组合选择。修复后既要验证常用业务，也要确认直连业务没有因路由调整而变慢。

DNS 问题：分清系统解析、内核解析与代理侧解析

DNS 负责把域名映射到地址，但代理场景里并非所有解析都由同一个地方完成。应用可以先在本地解析，再把 IP 交给代理；也可以把域名交给 SOCKS 或 HTTP 代理，由内核或远端处理。TUN 还可能接管系统的 DNS 请求。因此，系统命令能查到地址，只能证明那条解析路径工作，不能证明浏览器、内核和远端的路径都正常。排查前先确认失败的是哪个域名，以及请求由哪一层解析。

从节点域名与目标域名分别检查

节点服务器本身使用域名时，客户端首先需要解析节点地址；代理连接建立后，才可能访问目标网站。这是两次不同的解析。日志中节点域名无法解析，应先检查启动阶段使用的 DNS，而不是修改目标网站路由。目标域名无法解析，则要看应用是否提交域名、内核是否启用了相应 DNS 配置，以及所选解析服务器能否通过预期出站访问。

Windows、macOS 与 Linux 都可以在具备相应工具的终端里用下面的查询做基础对照。查看返回地址、使用的解析服务器和报错类型，不要只看是否有输出。若系统查询成功而代理访问失败，再结合内核日志继续定位。查询结果可能来自缓存，修改配置后要确认新请求实际走了新的解析路径；只反复刷新网页，可能仍在使用浏览器保存的旧结果。

nslookup example.com

用代理测试区分本地解析与代理侧解析

在 SOCKS 测试中，socks5 通常让 curl 在本地解析目标域名，socks5h 则把域名交给代理侧。对同一目标分别测试，可帮助判断本地解析是否参与了故障。这里仍需替换成实际 SOCKS 端口。某种方式成功不代表另一种应该被永久关闭，而是说明两条路径存在差异；最终应根据路由需要与应用行为决定采用哪一种。

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

若代理侧解析正常、本地解析失败，应检查系统 DNS、浏览器安全 DNS以及网络提供的解析服务。若两者都失败但日志中的错误不同，应分别处理，不能一次改多个地方。浏览器使用自己的加密 DNS 时，系统 DNS 修改可能不会影响它；反过来，浏览器查询正常也不能证明其他应用正常。可临时让浏览器跟随系统设置进行对照，完成定位后再恢复符合使用需求的配置。

理解路由中的域名策略

domainStrategy 会影响路由匹配过程中是否需要把域名解析成 IP。在 V2Ray 家族内核中，AsIs、IPIfNonMatch 与 IPOnDemand 的目的不同，不能简单理解成三档性能设置。下面是路由片段，不是完整可直接启动的配置；它假定已有名为 direct、proxy、block 的出站，且相应规则数据存在。图形客户端应优先通过路由设置录入，避免直接覆盖其生成的整份配置。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": ["geosite:category-ads-all"],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

带有明确末尾匹配规则时，后续解析行为还受规则顺序与内核实现影响，不应认为选择某个策略就必然让所有请求执行 IP 匹配。修改后检查实际日志，而不是只看配置名称。广告域名规则、局域网 IP 规则与地域域名规则分别依赖不同信息；规则集缺失或类别名称不可用，也可能导致配置加载失败。更完整的顺序说明见geosite 与 geoip 分流配置实战。

避免解析依赖循环，谨慎处理虚拟地址

加密 DNS 服务器也需要网络连接，若它必须走代理，而节点地址又必须通过它才能解析，就可能形成循环。应为启动所需解析保留可达路径，并确认 DNS 请求的出站与预期一致。使用虚拟地址映射时，系统返回的地址不一定是真实服务器地址，这是机制的一部分；但客户端退出后遗留路由、旧缓存或局域网域名误入映射，都可能让应用无法访问目标。

修复时先恢复最简解析配置，停用冲突的 DNS 接管功能，再逐项添加。局域网主机名、打印设备和内部服务通常需要本地解析，不宜统一交给远端。每次调整后测试节点域名、代理目标、直连目标与局域网名称，确认四类需求都正常。关于 fake DNS、域名策略与规则集的含义，可在概念速查对照理解，避免为了一个网站能打开而破坏整套解析逻辑。

系统代理不生效：确认应用入口与 TUN 接管范围

系统代理是操作系统向应用提供的代理配置，不是强制接管所有连接。遵循系统设置的浏览器通常会使用它，但命令行、某些游戏和自带网络栈的软件可能忽略它。TUN 通过虚拟网卡与路由接管流量，覆盖范围不同，也引入权限、路由和 DNS 等额外条件。因此，应用不走系统代理时，先确认它的网络机制，不要把“系统代理已开启”当作所有流量都必然进入内核的证据。

检查系统实际保存的值

在 v2rayN 中启用系统代理后，再打开操作系统网络设置，核对代理地址与端口是否变成当前客户端的本地 HTTP 或混合入站。地址通常是回环地址，但端口必须来自实际设置。内核监听端口改了，系统代理仍指向旧端口，会让所有遵循系统设置的应用失败。若系统显示自动配置脚本而不是手动代理，还应确认当前使用的是哪种方式，避免两套设置互相覆盖。

关闭其他可能写入代理设置的软件，包括浏览器代理扩展、另一款代理工具或设备管理策略。公司或受管理设备的代理可能由策略固定，客户端即使修改后也会被恢复；这种情况应遵守设备管理要求，不要不断覆盖系统设置。普通个人设备则可观察启用前后的值是否变化，确认 v2rayN 操作的是当前使用的网络环境，而不是一个已经断开的连接配置。

用应用日志判断是否真的走代理

发起一个新请求并查看客户端连接记录。没有记录时，检查应用自己的代理选项；有记录但出站是 direct 时，系统代理其实可能已经生效，只是路由选择了直连。使用出口查询页面观察地址变化也有局限：若该页面命中直连规则，结果不变不能证明代理失效。应该同时看请求是否进入内核和选择哪个出站，再决定是入口问题还是规则问题。

终端程序常受 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY 与 NO_PROXY 影响。有的应用只认小写形式，有的只支持其中部分设置。排查时先使用命令显式指定代理，确认本地入站工作，再检查环境变量。NO_PROXY 包含目标域名或网段时，会让该请求绕过代理；修改变量后通常需要重新启动应用或终端，已有进程未必读取新值。

TUN 启动失败与启动后异常要分开处理

TUN 无法启动时，先看日志中的权限、虚拟网卡创建和路由写入错误。桌面系统可能需要提升权限或允许相关网络组件，但不应永久关闭系统防护。只按具体日志处理被拒绝的操作。若内核已启动但虚拟网卡创建失败，界面显示运行也不代表 TUN 接管成功；应确认客户端模式、网卡状态以及日志中是否有相应启动记录。

TUN 启动成功却断网时，先关闭 TUN，再用系统代理测试同一节点。若系统代理正常，问题更可能在路由、DNS 接管或其他虚拟网卡冲突。同时运行多个 VPN 或虚拟网络工具，可能导致默认路由反复变化。节点服务器流量必须有正确的外部路径，局域网也需要相应排除规则。不要把所有排除项全部清空，否则可能把节点连接和本地服务一并接管。

退出后恢复网络，保留可回退路径

客户端异常退出后，系统代理可能仍指向一个已经关闭的本地端口。此时浏览器失败，但显式直连测试正常，是很有价值的线索。打开系统代理设置清除遗留项，再检查 TUN 是否仍有残留网卡或路由。普通情况下先正常退出、重新启动客户端并执行关闭操作，比直接删除网卡更稳妥；手动修改网络配置前，记下原来的值，尤其是受管理网络的设置。

最后分别验证浏览器、终端与一个不遵循系统代理的应用，不能只测一种程序就宣告修复。还应确认局域网设备和直连目标可达，退出客户端后普通网络能够恢复。应用级代理与 TUN 各有适用范围，优先选择满足需求、变量较少的方式。基础操作可回到快速上手教程核对，故障排查期间不要同时引入新的路由模板和新的接管模式。

客户端崩溃：区分界面退出、内核退出与配置错误

客户端窗口突然关闭、窗口仍在但无法联网、点击启动后立刻停止，分别对应不同故障。v2rayN 的图形界面与代理内核并非同一个环节，界面正常不保证内核正在运行，内核退出也不一定导致窗口关闭。先记录触发条件：刚启动就失败，导入某个节点后失败，启用 TUN 后失败，还是运行一段时间后失败。能稳定复现的单一操作，是定位问题的最好起点。

先保留配置与日志，再做安装修复

如果界面还能打开，先通过客户端提供的功能导出必要配置，并记下当前订阅分组、路由模式与 DNS 设置。备份可能包含访问凭据，应保存在受控位置。无法进入界面时，不要立即清空用户数据目录；先保留该目录副本，再查看启动日志或系统的应用错误记录。复制日志用于求助前，移除服务器凭据、订阅地址、用户路径等不必要的敏感内容。

重新安装前，到下载页核对系统和处理器架构。Windows 的 v2rayN 桌面版与经典 WPF 版是不同界面入口，不应把其中一版的程序文件与另一版混放。macOS 按芯片选择对应安装包，Linux 同时核对处理器架构与发行版包格式。若系统提示依赖缺失，应根据明确错误补齐官方运行环境，不要从不明弹窗获取所谓修复组件。

界面闪退，观察启动与资源错误

刚启动就退出时，检查系统是否阻止了应用运行、安装过程是否完成、用户数据目录是否可写。macOS 应先把应用放到合适的应用目录，再处理系统安全提示；Linux 可从图形终端启动已经安装的程序，查看标准错误输出，并核对桌面会话所需组件。路径权限或依赖异常应有具体线索，不要简单通过长期使用管理员权限掩盖所有错误。

运行一段时间才崩溃时，观察是否与大量连接、日志积累、休眠恢复或显示环境变化有关。检查磁盘空间与内存压力，减少不必要的详细日志，并在相同操作下复测。设备休眠后网络接口可能发生变化，先重启连接而不是重装应用。若问题仅在某个界面操作出现，可暂时绕开该操作保留连接，同时记录步骤，避免把偶发系统问题误判为所有节点配置损坏。

内核立即退出，先读第一条配置错误

配置加载失败通常会指出字段、出站标签、规则数据或监听端口的问题。应优先处理日志里最早的有效错误，后续大量失败可能只是它的连锁结果。端口被占用时，查明占用程序，退出重复运行的客户端或修改本地入站端口，然后同步调整系统代理。不要为了让内核启动而删除所有路由规则；缺失规则数据与错误出站名称应该分别修复。

只有某个节点导致内核退出时，核对协议与内核支持关系。v2rayNG 以 Xray 内核为主，v2flyNG 使用 V2Fly 内核，支持能力并不完全相同；v2rayN 切换内核也不能让不支持的组合自动变得兼容。保持节点、传输与内核的匹配，必要时从有效订阅重新导入。尤其不要删除 REALITY 等连接所需字段来绕过加载错误，能启动不代表能正确连接。

用最小配置确定故障边界

保留备份后，建立仅含一个已知可用节点、基本路由和默认 DNS 的对照环境，暂时不启用 TUN、复杂规则与自定义配置。若最小环境正常，再依次恢复订阅分组、路由、DNS 和接管功能，每恢复一项都复测。这样可以把问题收窄到具体配置层。测试环境不要与原环境同时监听同一个端口，也不要让两个实例竞争系统代理设置。

修复后做一次正常退出与重新启动，再验证订阅、节点、系统代理和 TUN 的实际状态。若仅靠重新安装恢复，但导回旧配置后再次失败，问题更可能在配置而不是安装程序。关于内核与客户端的关系，可查看关于本站与 Project V 生态说明。反馈故障时提供系统类型、架构、客户端名称、触发步骤和脱敏错误文本，比上传整份配置更安全，也更便于复现。

安卓连接异常：检查 VPN 授权、应用分流与后台限制

安卓端的 v2rayNG 与 v2flyNG 通过系统 VPN 接口接管流量，排查方式与桌面的系统代理不同。状态栏出现 VPN 标记，只能说明系统接口已经建立，不能证明远端节点连接成功。先选一个有效节点，确认启动授权已完成，再用浏览器发起请求并查看客户端日志。若刚启动就停止，应先查授权、配置加载与其他 VPN 冲突；若保持运行但无法上网，再沿着节点、DNS 与路由继续检查。

确认系统授权与 VPN 使用状态

首次连接通常需要批准系统 VPN 请求。授权框被取消、被其他窗口遮挡，或设备策略限制了 VPN 功能，都可能让客户端无法建立接口。打开系统 VPN 设置确认当前活动连接，并停止其他正在接管流量的 VPN 类应用。部分本地过滤工具也使用同一接口，因此看起来与代理无关，却会发生冲突。先只保留一个接管应用进行对照，再决定日常怎样安排它们的使用顺序。

检查系统是否启用了始终开启的 VPN 或阻止未经过 VPN 的连接。若指定的是另一款已停用的应用，可能导致普通网络也无法访问；若当前客户端异常退出，而阻止直连的策略仍有效，也会表现为整机断网。调整这些设置前先理解它们的作用，测试结束后按使用需求恢复，不要把所有限制都永久关闭。受管理设备应遵守管理员策略，不能通过反复重装解决授权限制。

某些应用正常，另一些失败时检查分流名单

应用分流可以采用仅代理选中应用，或绕过选中应用两种相反逻辑。名单内容相同，模式不同，结果就完全不同。先确认当前模式，再核对失败应用是否在名单里。系统组件、工作资料中的应用和普通个人应用也可能具有不同的接管范围。浏览器正常但另一个应用失败时，不应立即换节点，应先看那个应用的请求有没有进入客户端日志。

应用流量进入 VPN 后，仍会经过域名与 IP 路由。名单决定是否接管，路由决定接管后走哪个出站，两者不能互相代替。某些应用使用自己的 DNS、固定 IP 或长连接，行为与浏览器不同；修改路由后，需要完全退出并重新打开该应用，避免旧连接继续沿用原路径。对局域网设备访问异常时，检查局域网直连规则与应用接管设置，而不是把所有目标都强制代理。

熄屏后断开，先查电池与后台策略

前台正常、熄屏后失败，是后台限制的重要线索。查看系统电池管理中是否允许客户端在后台运行，并检查省电模式、后台数据限制与设备厂商的任务清理设置。不同设备的名称并不一致，应按功能寻找。调整后让设备进入相同的熄屏状态，再观察连接是否保持；只在屏幕点亮时测试，无法证明后台问题已经修复。

同时区分进程被停止与网络暂时中断。若客户端已经退出，应重点检查后台管理；若仍在运行但日志出现断线，可能是无线与移动网络切换、网络休眠或远端会话结束。允许后台运行不能保证所有会话永不断开，客户端仍需在网络变化后重新连接。切换网络后等待新连接建立，再发起一个新请求，避免用旧会话的失败判断当前网络仍不可用。

移动网络与无线网络分别验证

同一节点在无线网络正常、移动网络失败时，应检查两条网络的地址族与 DNS 差异，以及是否有系统数据节省限制。可先关闭额外的私人 DNS 自定义设置做对照，但这只是定位步骤，不是要求长期停用。若只有 UDP 相关业务异常，应确认节点、传输与服务端支持相应转发，不能因为网页能打开就认为所有协议都已正常。普通 HTTP 请求主要验证的是另一类连接路径。

无线网络切换后首次连接慢，还可能与旧解析缓存和地址变化有关。先停止并重新启动连接，确认日志中的服务器地址来自当前解析，再考虑调整 DNS。公共网络需要认证时，先完成认证再启动 VPN。若关闭客户端后也无法访问网络，应回到系统网络与 VPN 策略检查，不要继续修改节点。系统时间不同步也会影响 TLS，安卓设备同样需要核对自动时间与时区设置。

选择适合的客户端并完成闭环验证

安卓首推 v2rayNG，v2flyNG 是使用 V2Fly 内核的备选，但替换客户端不是所有问题的通用解法。涉及特定内核能力的节点，应确认兼容性后再导入。安装包按设备架构选择，无法判断时可到安卓下载说明查看对应入口，不要因为安装失败就随意更改节点协议。两个客户端之间共享订阅，仍需分别检查应用名单、DNS 与路由设置。

最终验证包括前台访问、熄屏后的新请求、无线与移动网络切换、局域网访问和停止 VPN 后的普通网络恢复。每一项都用相同业务做对照，并确认修改没有破坏其他场景。首次使用的配置主线见订阅导入与连接教程；术语不清楚时先查概念速查。保留可用设置与脱敏排查记录，下一次出现相同症状时，就能从已确认的环节继续检查。