v2rayN 问题诊断与故障排查大全

一、已连接但无法上网

先确认故障位于哪一层

“客户端显示运行中”只表示本地内核进程已经启动，不代表远端节点可达，也不代表浏览器正在使用该代理。完整链路依次经过应用程序、系统代理或 VPN 接口、本地监听端口、路由规则、DNS、远端节点和目标网站。排查第一步不是反复点击连接，而是判断断点位于本机之前还是节点之后。先关闭客户端的系统代理或 VPN 开关，确认普通网络能否打开常用网站；如果直连网络本身不可用，应先修复 Wi-Fi、网线、网关或运营商连接。基础网络正常后再重新启动客户端。

随后在 v2rayN 中选择一个已知配置完整的节点，将路由暂时切到全局模式，并启用系统代理。全局模式只用于诊断，它可以暂时绕开复杂分流规则。如果此时恢复访问，说明节点与内核基本正常，问题集中在路由规则、DNS 或绕过列表；如果仍然无法访问，则继续检查本地监听、节点连通性和应用代理范围。诊断完成后应恢复适合日常使用的路由模式，避免把临时测试状态长期保留。

检查本地监听和应用代理

桌面客户端通常在本机回环地址上提供 HTTP、SOCKS 或混合代理端口。端口被其他程序占用时，内核可能启动失败，也可能启动后无法接受连接。打开 v2rayN 日志，查找“address already in use”“bind failed”“failed to listen”等含义明确的错误。发现端口冲突后，可以退出占用该端口的程序，或在 v2rayN 设置中改用未占用端口，然后重启内核。不要仅修改浏览器代理而忽略客户端监听端口，两侧端口必须一致。

Windows 可在 PowerShell 中检查端口是否处于监听状态。以下示例中的端口应替换为客户端界面显示的实际本地端口：

Get-NetTCPConnection -State Listen |
  Where-Object LocalPort -In 10808,10809 |
  Select-Object LocalAddress,LocalPort,OwningProcess

Test-NetConnection 127.0.0.1 -Port 10809

如果端口正常监听，但只有某个应用无法联网，需要确认该应用是否遵循系统代理。一些程序自带代理设置，一些程序只读取启动时的系统代理，还有一些程序直接建立连接。对自带代理选项的应用，可显式填写 127.0.0.1 与对应 HTTP 或 SOCKS 端口进行对照测试。若显式代理可用而系统代理无效，问题不在节点，应转到“系统代理不生效”章节。

用最小配置隔离路由与 DNS

复杂配置中常见的断点包括：域名规则提前命中直连、目标 IP 被错误拦截、DNS 查询走了不可达的出口、订阅合并后留下无效出站标签。诊断时可暂时禁用自定义路由，仅保留一个代理出站和一个直连出站。若最小配置可用，再逐组恢复规则，每恢复一组就测试同一批地址。不要一次导入多套规则后再猜测是哪一条造成故障。

日志是判断出站路径的主要依据。正常请求通常能看到目标域名或 IP、选中的出站标签以及连接结果。若日志完全没有新增请求，说明应用流量没有进入客户端；若有请求但立即出现解析失败，应检查 DNS；若连接远端节点时超时，应进入下一章；若只有部分域名失败，优先检查分流和域名解析。通过“是否进入本地端口、是否完成解析、是否建立远端连接”三个判断点，可以把模糊的“不能上网”缩小为可操作的问题。

还要检查系统时间。TLS 握手依赖正确的日期、时间和时区，设备时间偏差过大时会出现证书尚未生效或已经失效的错误。启用操作系统自动校时后完全退出客户端，再重新打开并测试。企业网络、校园网络或公共热点还可能要求先通过门户页面完成认证，此时应先关闭代理，在浏览器完成网络认证，再启用客户端。若认证页面被代理拦住，表面现象同样会表现为所有网页无法打开。

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

区分三类连接错误

节点测试中的“超时”“连接被拒绝”和“握手失败”代表不同阶段。超时通常意味着数据包没有在规定时间内得到响应，可能是服务器不可达、端口被过滤、线路丢包或地址解析错误；连接被拒绝表示目标主机可达，但对应端口没有服务监听，常见于端口填写错误或服务端没有启动；握手失败则说明 TCP 已经建立，协议参数、TLS、传输方式或认证信息不匹配。只有先区分阶段，后续操作才不会停留在无效的重复测速。

不要只依赖客户端列表中的单次延迟测试。部分测试方式仅检查 TCP 建连，无法覆盖协议握手；另一些测试会请求特定网址，结果又会受到 DNS 与路由影响。应同时查看运行日志，并在桌面系统上测试服务器地址与端口的基础可达性。Windows 可使用以下命令：

Resolve-DnsName node.example.com
Test-NetConnection node.example.com -Port 443

其中 node.example.com 是文档示例地址，实际操作应填写配置中的服务器域名。若域名无法解析，先处理 DNS；若解析结果存在但 TCP 测试失败，检查网络路径、端口和服务器状态；若 TCP 成功而客户端握手失败，重点核对 UUID、密码、协议类型、传输方式、TLS 开关、SNI、Host、路径和 REALITY 参数。

逐项核对协议参数

VMess、VLESS、Trojan 等配置不能只比较服务器地址和端口。协议字段必须作为一个整体匹配。以 VLESS 为例，用户标识、流控方式、安全层、传输类型和服务端名称之间存在关联；REALITY 配置还需要对应的公钥、短标识和服务器名称。WebSocket 配置通常需要正确的路径与 Host；gRPC 需要匹配服务名称；TLS 连接中的 SNI 应与服务端证书和入口配置一致。任何一个字段被订阅转换工具截断，都可能在 TCP 成功后立即握手失败。

手工编辑节点时，应优先与提供方给出的完整原始配置逐项对照，而不是根据经验补齐。大小写、前导斜线、空格和不可见字符都可能产生差异。复制 UUID 或密钥后，可以先粘贴到纯文本编辑器检查首尾空格，再写入客户端。二维码与分享链接导入后也应打开节点详情复核，因为旧格式可能无法携带较新的传输字段。若同一节点在一台设备可用、另一台不可用，把两端的协议详情并排比较通常比重新导入更有效。

识别线路、网络与服务器侧问题

同一配置在移动网络可连接、在家庭宽带超时，通常说明客户端配置本身有效，应检查本地网络、路由器、DNS 或上游路径。反过来，如果所有网络环境都在相同阶段失败，服务器侧异常或参数失配的概率更高。可使用手机热点让桌面设备进行一次对照测试，也可以在 Android 设备上切换 Wi-Fi 与移动数据。测试时保持节点、客户端路由模式和 DNS 设置不变，只替换接入网络。

节点地址若使用域名，还要关注解析到的 IP 是否在不同网络中发生变化。CDN、双栈解析或本地 DNS 缓存可能让两台设备连接到不同地址。使用 nslookup 或 Resolve-DnsName 记录结果，再与客户端日志中的实际目标 IP 对照。若域名同时返回 IPv4 与 IPv6，而当前网络的 IPv6 路由不完整，连接可能长时间等待后才回退。此时可临时优先 IPv4 进行验证，但不应在没有证据时永久关闭系统的 IPv6 功能。

若日志出现证书名称不匹配、未知证书颁发者或握手协议不一致，不要把“跳过证书验证”作为常规解决方法。先检查设备时间、SNI、服务器名称和 TLS 设置。临时关闭验证只能用于确认问题是否位于证书链，确认后仍应恢复并修正配置。对于来自订阅的节点，应优先重新拉取完整配置；如果多个客户端同时出现相同握手错误，则需要由配置提供方核对服务端入口，而不是在客户端反复更换无关选项。

节点超时还可能是本地安全软件拦截内核进程或阻止新建出站连接。判断方法不是直接关闭所有防护，而是查看拦截记录，并确认 v2rayN 使用的内核程序是否被允许访问当前网络。若客户端目录被移动、内核文件路径变化，旧规则可能不再匹配。重新授权当前实际路径后重启客户端。完成排查后，再用真实网页和文件传输验证，单纯显示“延迟可用”并不足以证明完整链路正常。

三、订阅更新失败、节点为空或内容未变化

先判断请求失败还是解析失败

订阅更新包含下载和解析两个阶段。请求失败时，客户端无法取得订阅正文，日志通常会出现超时、名称解析失败、连接被拒绝或 HTTP 状态异常；解析失败时，请求可能已经成功，但返回内容不是客户端支持的订阅格式，最终表现为节点数量不变、节点列表为空或提示格式错误。排查时应先阅读更新日志，不要只根据列表结果判断。两类问题的处理方向完全不同。

先检查订阅地址是否完整。地址中的查询参数、大小写和特殊字符可能是认证的一部分，复制时缺少末尾字符就会失效。以下地址仅用于说明结构，不能作为实际订阅使用：

https://example.com/subscription?token=xxxx&client=v2rayN

如果地址通过聊天工具或文档中转，可能被自动换行或附加标点。建议在订阅分组设置中重新粘贴，并检查首尾是否存在空格。不要把网页管理地址、节点分享页或登录页当作订阅地址。能够在浏览器中打开页面，也不等于返回内容适合客户端解析；反之，浏览器直接显示一长串编码文本通常是正常订阅响应，不代表内容损坏。

决定更新请求是否经过代理

订阅服务器的可达路径可能与节点流量不同。客户端通常允许选择更新订阅时使用直连、当前代理或系统代理。若直连请求超时，而已有节点仍可连接，可将订阅更新切换为经过当前代理；若代理节点本身已经失效，强制通过代理更新又会形成闭环，此时应改用直连或先导入一个可用节点。判断原则是根据日志确认请求实际走了哪个出口，而不是在多个选项之间随机切换。

首次安装且列表为空时，没有可供订阅更新使用的现成代理，因此应先确认订阅地址能够通过当前基础网络访问。已有节点的用户可先选中一个实际可用的节点，再执行更新。更新完成后检查订阅分组的最后更新时间、节点列表变化和错误日志。如果手动更新成功而自动更新失败，重点检查自动更新间隔、设备休眠、客户端是否常驻，以及更新任务启动时代理内核是否已经就绪。

关于更新请求未走代理、链接失效、超时和格式异常的分支，可继续阅读v2rayN 订阅更新失败的六种原因与自动更新设置方法。该文侧重自动更新配置，本章侧重根据日志区分故障阶段。

处理格式、缓存与分组覆盖

常见订阅内容包括 base64 编码的分享链接集合、逐行分享链接和原生 JSON 配置。不同客户端及内核对字段的支持范围并不完全相同。v2rayN 订阅可以包含多种常见节点类型；v2rayNG 与 v2flyNG 在内核能力和导入字段上可能存在差异。如果服务端返回的是网页 HTML、登录提示、错误 JSON 或空文本，客户端就无法按节点订阅解析。此时应检查响应内容的实际类型，并确认账户状态与订阅入口。

若日志显示下载和解析都成功，但列表看起来没有变化，应检查订阅分组筛选、别名覆盖和去重策略。部分用户启用了仅显示当前分组、按关键字筛选或按备注去重，新节点可能已经导入但被界面过滤。先清空搜索框，切换到完整服务器列表，再查看目标分组。不要立即删除全部旧节点；先导出当前配置或复制分组，再执行一次覆盖更新，这样可以判断是订阅内容未变化，还是客户端合并策略隐藏了差异。

订阅缓存也会造成“更新成功但仍是旧内容”。可以完全退出客户端，重新打开后手动更新；若客户端提供清理订阅缓存或不使用缓存的选项，可在备份后执行。系统代理指向当前客户端时，不建议在内核停止期间用浏览器判断订阅可达性，因为浏览器请求可能仍指向已经关闭的本地端口。应先关闭系统代理，确认直连状态，再进行对照。

自动更新间隔不宜设置得过短。高频请求不能提升节点质量，反而可能遇到服务端频率限制，并在网络切换或设备唤醒时产生重叠任务。根据订阅实际变化频率设置合理周期，在需要时手动更新即可。更新后若只有某些新协议节点无法使用，应回到节点详情核对字段，并确认所选客户端内核支持对应配置。需要了解格式差异时，可阅读V2Ray 订阅格式科普与转换说明。

四、连接成功但网页慢、下载慢或速度波动

把延迟、吞吐和稳定性分开测量

延迟低不等于下载速度高。延迟反映一次往返所需时间，吞吐取决于线路容量、拥塞、丢包、服务器负载和 TCP 行为，稳定性则体现连续连接中是否频繁抖动或重传。客户端节点列表中的测试结果只能作为初筛，不能代替实际访问。诊断速度问题时，应固定同一设备、同一接入网络、同一测试时段和同一目标，分别比较直连、单个节点和另一个节点，避免把目标网站自身负载误判为客户端故障。

先关闭其他下载、云盘同步、系统更新和视频播放，再测试普通网页首开、连续图片加载和一个合法文件下载。若所有节点在同一网络都慢，而切换手机热点后恢复，应优先检查本地宽带、Wi-Fi 干扰、路由器性能和上游路径；若只有一个节点慢，通常是节点线路或负载问题；若浏览器快但特定应用慢，应检查该应用是否使用相同代理、是否采用 UDP、是否有独立 DNS 或连接并发限制。

检查路由是否让流量绕行

分流规则错误会让原本适合直连的流量经过远端节点，或让需要代理的请求先尝试直连后超时回退。两种情况都会增加页面首开时间。打开日志观察慢请求最终命中的出站标签，尤其关注域名规则、IP 规则和默认规则的顺序。路由通常按从上到下或按内核规定的优先级匹配，一条范围过大的规则可能遮盖后续细分规则。调整时先复制现有规则集，再用少量域名验证，不要直接重写全部配置。

一个用于理解分流结构的简化规则如下。该片段展示 geosite 与默认出站关系，实际标签名需要与客户端现有出站保持一致：

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

domainStrategy 决定域名匹配与解析的关系。使用 AsIs 时优先按原始域名规则处理，避免不必要的提前解析；需要按 IP 规则分流时，内核可能在后续进行解析。没有统一适合所有网络的设置，应根据规则结构选择。修改后必须重新载入配置，并在日志中确认新规则已生效。

排查 MTU、UDP 与多路复用

网页能打开但大文件卡住、视频间歇缓冲或部分请求长时间停顿，可能与路径 MTU 有关。VPN 接口、隧道和某些接入网络会增加封装开销，过大的数据包若无法正确分片，表现为小请求正常、大传输异常。桌面端可先比较系统代理模式和虚拟网卡模式：如果系统代理正常而虚拟网卡模式异常，检查该模式的 MTU、驱动和路由表。不要凭经验把 MTU 降到极低，应该逐步调整并观察大文件传输是否稳定。

UDP 对 DNS、实时通信和部分新型传输很重要，但不同节点与网络对 UDP 的支持可能不同。若开启 UDP 后出现间歇性问题，可先在应用层确认是否确实需要，再查看内核日志有无 UDP 超时。只关闭某个应用的 UDP 与全局禁用 UDP 是两种不同操作，后者可能改变 DNS 和其他程序行为。对于使用 QUIC 的网页，浏览器也可能在 UDP 不稳定时经历回退，从而造成首次加载慢、随后正常。

多路复用可以减少部分场景下的重复建连，但它并非越高越快。在线路丢包明显时，过多请求共享连接可能互相影响；服务器未按相同方式配置时也可能握手失败。排查速度波动时，可以暂时关闭多路复用进行对照，而不是同时调整并发、缓存、DNS 和传输协议。若关闭后稳定性提升，再根据节点服务端能力决定是否恢复。

检查本机资源与无线网络

内核需要进行加密、解密、路由匹配和日志写入。老旧设备、节能模式或大量详细日志都可能限制吞吐。传输时观察 CPU、内存和磁盘占用：若单个核心持续高负载，瓶颈可能位于本机处理；若资源占用较低但网络吞吐周期性归零，更像是线路丢包、无线干扰或服务器拥塞。Android 设备还会受到省电策略和后台限制影响，相关处理见移动端章节。

Wi-Fi 信号格数不能完整反映链路质量。同频干扰、路由器过热、设备距离和自动频段切换都会造成抖动。条件允许时先使用有线网络测试；只能使用无线网络时，靠近路由器并暂停其他设备的大流量任务。若每天固定时段变慢，而客户端设置未变化，通常应记录时段、接入网络和节点差异，避免反复重装客户端。稳定性问题需要多次、低干扰的对照数据，而不是一次峰值结果。

五、DNS 解析失败、域名污染表现与地址不一致

判断是域名问题还是连接问题

DNS 故障常表现为网页提示找不到服务器、日志出现解析失败、同一节点使用 IP 可以连接而使用域名超时，或部分域名打开到错误地址。首先区分“没有解析结果”和“解析到了不可用地址”。前者通常与 DNS 服务器不可达、代理 DNS 配置错误或系统缓存异常有关；后者可能来自缓存、分流策略、IPv4 与 IPv6 优先级或不同 DNS 返回差异。直接更换一串 DNS 地址并不能解释原因，应该先记录当前解析结果。

Windows 可使用以下命令查看系统解析和指定类型的返回结果：

nslookup node.example.com
Resolve-DnsName node.example.com -Type A
Resolve-DnsName node.example.com -Type AAAA
ipconfig /displaydns

macOS 与 Linux 可使用 nslookup，也可根据系统环境使用 dig。对照客户端日志中的目标 IP，判断请求使用的是系统 DNS、客户端内置 DNS 还是远端解析。若命令行结果正常而客户端日志解析失败，重点检查客户端 DNS 配置与出站标签；若系统和客户端都失败，应先检查网络提供的 DNS、路由器转发和本机防火墙。

理解本地解析与远端解析

系统代理主要转发应用的 HTTP 或 SOCKS 流量，应用发起的 DNS 查询不一定自动经过代理。某些浏览器会使用自身的安全 DNS，某些程序直接调用系统解析，SOCKS 客户端还可能选择本地解析域名后只把 IP 交给代理。于是同一台设备上，不同应用可能得到不同地址。排查时要确认应用传给代理的是域名还是已经解析的 IP，并检查浏览器自带 DNS 设置是否覆盖了系统策略。

虚拟网卡模式通常能接管更广泛的流量，但仍需要正确的 DNS 劫持、路由和排除规则。若开启后所有域名失败，而直接访问 IP 有响应，说明虚拟接口已接管流量但 DNS 请求没有到达可用解析器。检查客户端生成的 DNS 入站、虚拟地址范围和路由表，确认 DNS 服务器本身不会再次经过错误出站形成循环。修改虚拟网卡相关设置后，应停止内核、等待接口释放，再重新启动。

远端解析适合需要让代理出口决定域名地址的场景，本地解析则更适合按本地网络返回就近地址的服务。两者不能简单视为优劣关系。若路由规则先按域名决定出站，通常应保留原始域名信息；若规则依赖 IP 集合，则需要在适当阶段解析。配置中同时存在多个 DNS 服务器时，还应明确每个服务器的匹配域名、查询出口和失败回退，避免查询在直连与代理之间循环。

处理缓存、IPv6 与 Fake DNS

更换 DNS 后旧记录可能仍保留在操作系统、浏览器和客户端缓存中。Windows 可执行 ipconfig /flushdns 清理系统缓存，随后完全退出浏览器和客户端再测试。清理只会移除缓存，不会修复错误的路由或 DNS 配置；如果记录很快再次变错，应继续检查实际查询路径。浏览器自身缓存和安全 DNS 也要单独核对，不能只依赖系统命令。

双栈网络中，域名可能同时返回 A 与 AAAA 记录。系统会根据网络状态和地址选择策略决定连接顺序。如果路由器广播了 IPv6 但上游连接不完整，应用可能先等待 IPv6 超时，再回退 IPv4，表现为页面首开慢。可以分别查询 A 与 AAAA，并在日志中观察实际尝试的地址。临时优先 IPv4 可用于验证，但最终应修复路由器 IPv6、代理出站或客户端域名策略，而不是永久掩盖问题。

Fake DNS 会向应用返回保留地址，再由客户端还原原始域名进行路由。它适合虚拟网卡接管，但要求保留地址池不与局域网、公司网络或其他 VPN 冲突。若启用后局域网设备不可达、特定应用识别到异常地址或重启后旧映射失效，应检查地址池、排除域名和缓存生命周期。局域网打印机、路由器管理域名和内部业务域名通常需要按实际网络设为本地解析或直连。

完成 DNS 修复后，应同时测试节点域名、普通网页域名和局域网域名。只测试一个公开网站无法覆盖订阅更新、节点入口与本地设备访问。若问题只发生在某个应用，检查该应用是否启用了独立 DNS；若多个设备在同一路由器上表现一致，则优先检查路由器的 DNS 转发和 IPv6；若仅客户端开启时异常，则回到内核 DNS、路由出站和虚拟接口设置逐项验证。

六、系统代理已开启但浏览器或应用不生效

确认操作系统中的代理值

v2rayN 的“系统代理”开关负责把操作系统代理地址指向本地监听端口。内核运行和系统代理是两个独立状态：内核已启动但系统代理关闭时，只有显式配置了代理的应用会经过客户端；系统代理已写入但内核停止时，应用会连接到一个没有服务的本地端口。排查时应同时确认内核运行状态、本地端口监听和系统代理地址，三项缺一不可。

Windows 中可在系统网络代理设置里查看手动代理地址与端口，也可以通过 PowerShell 查看当前用户的相关配置。重点不是记住注册表位置，而是确认界面显示的端口与 v2rayN 实际监听端口一致。若切换配置后端口发生变化，旧系统代理可能仍指向之前的端口。先关闭系统代理，再由客户端重新启用，通常比手工修改多个位置更可靠。

macOS 上的代理设置按网络服务保存，Wi-Fi 与有线网络可能各有一套配置。切换接入方式后，如果客户端只更新了旧网络服务，新连接就不会使用代理。Linux 桌面环境对系统代理的支持存在差异，有些应用读取桌面设置，有些应用读取环境变量，还有些应用完全使用自己的网络配置。因此“系统代理开启”不能保证所有桌面应用自动遵循。

处理浏览器缓存与独立代理设置

浏览器通常会读取系统代理，但扩展、企业策略、安全 DNS 和启动参数可能覆盖系统配置。如果浏览器不生效，先新建一个不加载额外扩展的临时配置进行对照，或检查浏览器网络设置是否明确写入了其他代理。修改系统代理后完全退出浏览器再重新打开，因为部分程序只在启动时读取代理。若新配置可用，问题位于原浏览器配置，而不是 v2rayN 节点。

可以使用命令行显式指定本地代理，验证内核是否接受请求。以下端口仅为示例，应替换为客户端实际 HTTP 端口：

curl.exe --proxy http://127.0.0.1:10809 https://example.com/
curl.exe --socks5-hostname 127.0.0.1:10808 https://example.com/

如果显式代理成功而浏览器失败，说明节点、内核和本地监听都正常，应继续检查系统代理读取链路。如果两条命令都失败，查看客户端日志中是否收到请求；完全没有日志通常是端口或安全软件问题，有请求但连接失败则回到节点、DNS或路由章节。使用 --socks5-hostname 时，域名由 SOCKS 代理侧处理，可用于与本地解析进行对照。

理解绕过列表与 PAC 行为

系统代理通常包含绕过本地地址、局域网网段或特定域名的列表。范围过大的绕过规则会让目标请求直接连接，看起来像代理没有生效。检查是否存在通配符过宽、域名后缀写错或把测试网站包含在直连列表中的情况。局域网地址通常需要绕过代理，但具体范围应与实际网络一致。删除所有绕过项并不是长期方案，因为可能影响路由器管理页面、打印机与内部服务。

PAC 模式通过脚本决定每个请求使用代理还是直连。浏览器可能缓存 PAC 文件，脚本地址不可达时也可能回退为直连。诊断时可以临时切换到固定系统代理，若立即恢复，问题集中在 PAC 获取、缓存或匹配规则。修复后再恢复 PAC，并验证代理域名、直连域名与局域网地址三类请求。关于系统代理、全局模式与绕过规则的关系，可阅读系统代理、全局模式与绕过大陆模式区别详解。

权限、残留状态与代理循环

客户端异常退出后，系统代理可能残留。下次启动若使用了不同端口，浏览器就会继续连接旧地址。遇到“退出后无法上网”时，先在系统设置中关闭手动代理，再检查自动配置脚本是否仍然启用。随后启动客户端，确认内核正常后由客户端重新写入。不要同时让多个代理客户端管理系统代理，否则它们可能交替覆盖地址，造成状态与界面不一致。

代理循环常见于客户端更新订阅、检查网络或下载规则时错误地再次经过自身已失效的系统代理。日志会出现本地端口重复连接、请求无响应或内核停止后所有网络操作都失败。解决思路是明确每类内部请求使用直连还是当前代理，并确保客户端启动前不依赖尚未建立的出口。切换节点时也应等待新内核完成监听，再触发需要代理的操作。

部分应用不支持系统代理，或只代理 HTTP 流量。此类程序需要在自身设置中填写 SOCKS 或 HTTP 地址，或者在适合的桌面环境中使用虚拟网卡模式接管流量。切换到虚拟网卡模式前应了解其权限、DNS 和路由影响，不要把它当作系统代理问题的通用开关。若只有一个程序异常，优先查该程序文档中的代理能力；若所有程序都异常，再检查系统层与客户端层。

七、客户端无法启动、内核退出或频繁崩溃

区分界面进程与内核进程

v2rayN 由图形界面负责配置管理，再调用 Xray 或 V2Fly 内核处理流量。界面能打开但连接后立即停止，通常是内核启动失败；界面本身无法打开、窗口闪退或配置页面崩溃，则应检查运行环境、配置文件、权限和界面相关组件。两者的日志位置和修复路径不同。首先记录崩溃发生在“打开客户端”“启动内核”“载入订阅”还是“开始传输”阶段。

如果界面仍可操作，先打开日志目录，保留本次启动前后的错误内容。内核常见启动错误包括 JSON 语法错误、出站标签不存在、端口冲突、规则文件无法读取和配置字段不受支持。不要只截取最后一行，因为根因往往出现在前面的配置解析阶段。若日志过于详细，可暂时将级别调整到 warning 或 info，重新复现一次，避免大量正常连接记录掩盖关键错误。

验证生成配置是否完整

手工添加路由或从旧配置迁移后，逗号、引号和括号错误会导致内核拒绝启动。标准 JSON 不允许注释，也不允许最后一个数组项后保留多余逗号。下面是结构完整的最小示意，可用于理解层级，不应直接替换已有节点配置：

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "protocol": "freedom",
      "tag": "direct"
    }
  ]
}

若客户端支持查看生成配置，应重点检查日志指出的字段路径。自定义片段不要重复定义客户端已经生成的顶层对象，也不要引用不存在的 outboundTag。从另一款客户端复制配置时，应确认目标内核支持相同字段。Xray 与 V2Fly 存在共同基础，也各有不同能力；关于内核差异，可阅读Xray 内核与 V2Fly 内核差异对比。

处理权限、路径与安全软件拦截

客户端目录缺少写入权限时，可能无法保存配置、更新内核文件或写入日志。桌面系统中应把客户端放在当前用户有正常读写权限的位置，路径避免指向临时目录或会被自动清理的位置。不要长期依赖管理员权限启动；如果普通权限失败，应先确认具体被拒绝的文件或操作，再修正目录权限。以高权限运行可能改变配置文件所有者，导致之后普通启动继续失败。

安全软件可能阻止新下载的内核进程运行，或在更新后把新文件视为未授权程序。应查看系统安全记录和隔离记录，确认被拦截的实际文件路径。仅为当前可信安装目录配置必要的运行和联网权限，不要关闭整个防护体系。若 v2rayN 界面启动正常但内核文件立即消失，通常需要先处理隔离规则，再重新从Windows 下载入口获取客户端。

路径中包含特殊字符、同步盘占位文件或过长目录层级时，外部内核和规则文件可能无法正常读取。可将客户端移动到简短、稳定且可写的用户目录进行对照。移动前先退出程序，移动后重新选择内核路径，并检查订阅、日志和规则目录是否仍指向旧位置。不要在程序运行时搬动目录，这会让界面保存位置与内核当前工作目录不一致。

恢复损坏配置而不丢失全部数据

如果更新订阅或修改路由后界面立即崩溃，可以先复制整个配置目录作为备份，再尝试移走最近修改的自定义规则、界面状态文件或单个订阅分组。恢复过程应从最小变更开始，不要直接删除全部配置。能够重新打开后，逐项导入服务器和路由设置，每次导入后重启验证。这样可以定位具体损坏文件，并保留其他正常数据。

客户端频繁崩溃还可能由内存不足、规则集过大或日志持续增长引起。观察崩溃前的内存、磁盘空间和日志大小。大量重复规则会增加启动解析时间，自定义域名列表中一行异常长的内容也可能带来额外负担。删除重复项、按用途拆分规则，并保留必要日志即可。若仅在传输大量连接时崩溃，降低应用并发进行对照，同时查看系统是否记录进程被资源限制终止。

完成恢复后，应按“界面启动、内核监听、单节点连接、订阅更新、自定义路由”顺序逐层加回功能。每一步保持可用后再继续。如果错误只在某个自定义片段出现，应依据当前内核支持的字段重写，而不是继续复用旧客户端导出的完整配置。需要重新安装时，从下载中心选择当前平台的软件包，并在导入旧数据前先验证空白配置能够正常启动。

八、Android 上的连接中断、后台失效与应用分流

确认 VPN 权限与系统冲突

v2rayNG 与 v2flyNG 通常通过 Android 的 VPN 接口接管应用流量。首次连接时系统会显示 VPN 授权，未授权、授权被撤销或已有其他 VPN 占用时，客户端无法建立接口。状态栏出现 VPN 标识只能说明接口存在，仍需结合客户端日志确认内核已经启动并加载选定节点。若点击连接后立即断开，先检查系统是否提示另一个 VPN 正在运行，再确认工作资料、企业管理或安全应用是否限制 VPN 权限。

Android 同一时间通常只允许一个主要 VPN 服务。广告过滤器、企业 VPN、网络加速工具和其他代理客户端可能与 v2rayNG 或 v2flyNG 冲突。排查时应完全停止其他占用 VPN 接口的应用，而不是仅从最近任务中划掉界面。系统设置中的“始终开启 VPN”和“阻止未使用 VPN 的连接”也会影响切换客户端；如果始终开启绑定了另一应用，新客户端可能无法获得权限。

选择客户端时，v2rayNG 使用 Xray 内核，v2flyNG 以 V2Fly 内核为基础。两者在常见配置上有交集，但部分协议与传输字段支持不同。订阅导入后若只有特定节点无法连接，应先核对节点是否依赖对应内核能力，不要把同一配置在两款客户端之间无条件复制。需要安装或更换软件包时，可进入Android 下载入口。

处理省电与后台限制

锁屏后连接中断、切换应用后很快失效，通常与电池优化和后台限制有关。系统可能暂停客户端进程、限制后台网络或回收 VPN 服务。应在应用电池设置中允许后台活动，并根据设备系统提供的选项取消对客户端的严格省电限制。部分设备还有自启动、后台弹出或任务锁定设置，应以“允许 VPN 服务持续运行”为目标，不必开启与网络无关的权限。

修改省电设置后，应重启客户端并进行完整测试：保持屏幕开启访问一次，锁屏数分钟后再次访问，再在 Wi-Fi 与移动数据之间切换。若只在锁屏后失败，重点仍是后台策略；若网络切换后失败，则可能是 VPN 接口没有重新建立、旧 DNS 缓存未更新或节点连接未重拨。日志中若出现网络丢失后没有新的默认网络，说明客户端未及时获得系统网络变化。

系统内存紧张时，后台进程也可能被回收。大量常驻应用、游戏和浏览器标签页会增加这种概率。观察客户端通知是否在中断时消失；通知消失通常表示服务已经停止，通知仍在但无法访问则更可能是隧道、DNS 或节点连接断开。开启持久通知有助于系统把 VPN 服务视为前台任务，也方便区分服务停止和链路失效。

检查应用分流与绕过设置

Android 客户端可按应用决定经过 VPN、绕过 VPN 或仅代理选中应用。列表配置错误时，会出现浏览器可用而其他应用直连，或只有少数应用无法联网。排查时先暂时关闭按应用分流，让所有普通应用进入 VPN，确认基础连接正常；随后再恢复白名单或黑名单，并逐个验证目标应用。不要同时启用“仅代理所选应用”和与之相反的绕过逻辑。

系统组件、下载管理器和嵌入式网页可能由不同进程发起请求。某个应用界面中的下载动作不一定由该应用包名直接执行，因此只选择主应用可能导致登录正常但下载失败。遇到这种差异，应查看客户端按应用统计或日志，确认实际流量是否进入 VPN。对于依赖局域网设备的应用，还要根据需要允许绕过本地网络，否则投屏、打印机和路由器管理功能可能失效。

分应用代理与内核路由属于两个层级。前者决定应用流量是否进入 VPN，后者决定进入后的流量走代理还是直连。如果应用根本没有进入 VPN，修改 geosite 或 IP 规则不会产生效果；如果应用已经进入但目标域名命中错误出站，才需要调整内核路由。日志中完全没有该应用请求时先查应用分流，有请求但出口不符时再查路由规则。

网络切换、私人 DNS 与热点共享

从 Wi-Fi 切换到移动数据时，本地地址、DNS 和 MTU 都可能变化。客户端需要重新绑定默认网络并恢复隧道。若切换后状态显示连接但网页停滞，可以先暂停再连接，而不是删除节点。频繁发生时，检查客户端是否允许在网络变化后自动重连，并确认系统没有限制后台网络。双卡设备还应确认当前数据卡与系统默认网络一致。

Android 的私人 DNS 设置可能与客户端内置 DNS 并行或冲突。出现域名失败但 IP 连通时，可记录当前私人 DNS 模式，临时切换为系统自动进行对照。如果自动模式恢复，继续检查私人 DNS 主机可达性与客户端 DNS 路由；如果没有变化，问题更可能位于 VPN 内的解析路径。不要把关闭私人 DNS当作最终结论，测试后应根据实际解析结构选择合适设置。

设备开启热点时，下游设备的流量是否经过手机 VPN，取决于系统能力与客户端转发方式，不能仅根据手机本机连接状态推断。若手机可访问而连接热点的电脑不可访问，先确认下游设备能否普通联网，再检查客户端是否明确支持热点流量转发。没有对应转发能力时，应在下游设备独立安装桌面客户端，而不是反复调整手机节点。

最后使用固定顺序验证：取消严格省电限制，停止其他 VPN，关闭应用分流，选择一个已确认可用的节点，保持默认路由完成网页测试；随后锁屏、切换网络并逐项恢复分流。若基础状态仍然失败，查看日志属于解析、连接还是握手问题，并返回前面对应章节。若基础状态正常而恢复某项设置后失败，该设置就是明确的排查入口。通过逐层恢复，比反复清除应用数据更容易保留订阅和路由配置。