V2Ray 故障排查：按症状定位连接问题

先区分“本地断网”和“代理路径断开”

客户端托盘图标显示运行中，只能说明图形界面与内核进程已经启动，不能证明流量已经到达远端。排查时先暂时关闭系统代理或 Android 的 VPN 连接，然后访问本地网络中原本可用的站点。如果关闭客户端后仍无法访问，问题在当前 Wi-Fi、网线、移动网络、网关或系统网络栈，不应继续修改节点参数。重新连接网络、关闭再开启网卡，或在另一条网络上复测，通常比反复导入订阅更快。

若直连正常、开启代理后所有网站都失败，下一步查看客户端日志。v2rayN 可从日志区域观察 Xray 启动和连接记录；v2rayNG、v2flyNG 可打开日志页后重新访问一次目标地址。重点不是日志行数，而是第一次出现的错误。包含 connection refused 通常表示目标端口明确拒绝连接；timeout 表示握手在限定时间内没有完成；no such host 指向域名解析；certificate 或 handshake 则应检查系统时间、SNI 与传输安全参数。

用最小配置排除路由规则干扰

复杂路由可能把浏览器流量分配到不可用的出站，也可能把本应由代理处理的域名错误送入直连。先保留一个确认可用的节点，将路由模式临时切换为全局代理，关闭额外的自定义规则、链式代理、Mux 和实验性 DNS 功能，再测试一个普通 HTTPS 页面。如果全局模式可用而规则模式不可用，故障就在路由匹配，不在节点本身。恢复规则时应一次只启用一组，并在每次变更后建立新连接，避免浏览器继续复用旧的 TCP 或 HTTP/3 会话。

图形界面的路由规则最终会转换为 Xray 配置。规则按客户端生成顺序参与匹配，域名、IP、端口和网络类型可能同时决定出站。下面的最小结构只保留代理与直连两个出站，用于理解问题边界；实际客户端会补充入站监听和节点凭据。

{
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vless",
      "settings": {}
    },
    {
      "tag": "direct",
      "protocol": "freedom"
    }
  ],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

检查端口占用、时间与残留进程

桌面客户端会在本机监听 SOCKS、HTTP 或混合代理端口。若同一端口已被另一个代理程序、旧内核进程或调试工具占用，新内核可能启动失败，界面却仍保留上一次的状态。Windows 可在终端执行 netstat -ano 查看监听端口及进程编号；macOS 与 Linux 可用 lsof -iTCP -sTCP:LISTEN。发现冲突后，应先退出相关程序，再从客户端完整重启内核，不要只切换节点。

netstat -ano | findstr LISTENING
lsof -iTCP -sTCP:LISTEN
date

系统时间也必须准确。TLS、REALITY 及订阅服务器的 HTTPS 连接都会依赖时间判断。时间偏差较大时，常见表现是所有节点同时失败、订阅也无法更新，或者日志持续出现证书尚未生效、证书已过期等提示。启用系统自动校时后彻底退出客户端并重新启动，让新建连接使用校正后的时间。若上述检查均正常，再从下载页确认使用的是对应平台客户端，并重新完成一次最小配置，而不是直接覆盖大量旧设置。

延迟测试结果不等于真实网页速度

v2rayN 的延迟测试可能采用 TCP 建连、真实延迟或其他可用性检测方式，不同方式回答的问题不同。TCP 建连成功只表示远端地址和端口可以完成基础握手，不能证明协议认证、TLS、REALITY 或目标网站访问一定成功；真实延迟测试会经过更多处理，但仍可能受到测试地址、DNS 和当前路由影响。因此，不应仅凭一个超时标签删除节点。正确做法是先查看测试类型，再实际访问网页，并结合日志确定超时发生在解析、连接远端、TLS 握手还是出站访问阶段。

单个节点超时而同一订阅中的其他节点正常，通常是该节点地址、端口、传输参数或服务状态的问题。所有节点同时超时，则更像本地网络、系统时间、DNS、内核启动或网络环境变化。若只有某一网络下全部失败，而切换到另一网络恢复，应优先检查当前路由器、防火墙、企业网络策略或 UDP 可用性，不要同时改动每个节点。

逐项核对地址、端口与传输参数

手工配置节点时，服务器地址不能带协议前缀、路径或多余空格；端口必须是整数；UUID、用户标识、密码等认证字段要完整复制。VLESS 与 VMess 不是可以互换的协议，传输层的 TCP、WebSocket、gRPC 也不能只凭端口猜测。使用 TLS 时要核对服务器名称和主机字段；使用 REALITY 时还需要匹配公钥、短标识、指纹与服务器名称。任何一项不一致，都可能表现为握手超时或连接建立后立即关闭。

WebSocket 节点还要核对路径与 Host，路径通常以斜杠开头，大小写和附加查询部分都可能影响服务端匹配。gRPC 要检查服务名称，不能把它填入 WebSocket 路径。若节点来自订阅，优先重新更新订阅而不是手动“修正”字段，因为订阅提供方可能已经调整了参数。重新导入前可先复制当前订阅分组作为记录，但不要让两个同名节点同时参与自动选择，以免测试对象混淆。

不要用扩大超时时间替代定位

将连接超时从几秒提高到很长时间，只会让不可用节点更晚返回失败，通常不会修复协议或端口错误。合理的复测方式是选择一个节点、关闭自动切换、建立全新连接，然后观察从点击连接到首条错误日志之间发生了什么。若 TCP 可以连接但 TLS 握手失败，重点检查 SNI 和时间；若 TLS 完成后认证失败，重点检查用户标识与协议；若代理已建立但访问特定网站超时，则转向路由、DNS、MTU 或目标侧连接问题。

UDP 场景还需要单独判断。某些网络对 UDP 不稳定，浏览器可能优先使用 HTTP/3，DNS 也可能通过 UDP 查询，从而出现“部分网页转圈、普通 TCP 测试却正常”。可临时关闭浏览器的 HTTP/3、把 DNS 改为 TCP 或 HTTPS 方式，观察故障是否消失。若仅 UDP 失败，不应把整个节点判定为完全不可用，而应根据实际应用需求调整传输方式与路由。

自动选择或负载策略会增加排查变量。测试期间固定一个出站，避免客户端在多个节点间切换；确认单节点稳定后，再恢复自动选择。若某节点在桌面端与 Android 上同时失败，且两台设备使用不同网络，节点参数或远端状态的可能性更高。若同一节点只在一台设备失败，则应比较两端的内核类型、路由规则、DNS 设置与系统时间，而不是重新购买或反复导入相同订阅。

先分清订阅地址与单节点分享链接

订阅地址通常返回一组节点数据，客户端保存地址后可以再次更新；以 vmess://、vless:// 等开头的分享链接通常只描述一个节点。把单节点链接放进订阅管理器，可能出现格式错误或更新后没有列表；把订阅地址当作单节点扫码，也可能无法解析。两者区别可参考分享链接与订阅地址说明。排查时先确认复制的是完整地址，没有在聊天软件换行、截断，也没有把末尾参数遗漏。

订阅更新涉及两段连接：客户端先访问订阅服务器获取内容，再解析内容生成节点。下载阶段失败时，日志常见 DNS、TLS、HTTP 状态或连接超时；下载成功但解析失败时，通常会提示格式不支持、数据为空或个别条目异常。先记录错误属于哪一段，能避免把网络问题误判成节点格式问题。

检查系统代理与订阅更新路径

订阅更新可能选择直连，也可能通过当前代理。若订阅地址只能在代理连接可用时访问，而当前节点已经失效，就会形成“必须先有节点才能更新节点”的闭环。此时可切换到仍可用的旧节点，再执行更新；也可以检查客户端的订阅更新代理选项，明确它是走系统代理、当前代理还是直连。不要在不清楚含义时同时开启多层代理，因为请求可能被送回本机代理端口形成循环。

反过来，若订阅服务器在直连网络中可访问，通过代理却失败，应临时改为直连更新。更新完成后先不要删除旧分组，确认新列表包含预期节点，再清理重复项。对于多个订阅，逐个更新比“一键全部更新”更容易确定具体失败地址。订阅名称只是本地标签，不参与连接；真正需要检查的是地址、更新方式、用户代理要求和返回内容。

用 HTTP 状态与返回内容定位

状态码能快速划分责任边界。返回 401 或 403 往往表示地址中的令牌、路径或访问条件不再有效；404 多见于链接被替换或复制错误；429 表示短时间请求过多，应停止连续刷新并稍后重试；5xx 表示订阅服务端暂时异常，本地反复重装客户端通常没有帮助。若状态为 200 但列表为空，应检查返回的是节点文本、网页提示还是登录页面。图形客户端可能只显示“解析失败”，详细日志通常能看到响应类型或解码错误。

桌面端可用系统自带工具只查看响应头，避免把完整订阅内容输出到共享屏幕或公开日志。下面命令中的地址仅表示本地示例，不包含真实订阅信息：

curl -I "https://example.invalid/subscription"
nslookup example.invalid

若域名无法解析，转到本页 DNS 章节；若 TLS 报错，校正时间并检查证书名称；若响应正常但客户端解析失败，可新建一个空白订阅分组，仅导入该地址以排除旧缓存和重名节点影响。v2rayN、v2rayNG 与 v2flyNG 对常见分享格式的处理细节可能不同，因此同一订阅在不同客户端出现差异时，应查看订阅是否包含该客户端不能识别的扩展字段，而不是直接假定设备网络故障。

处理更新后节点没有变化

更新成功但列表看似没有变化，可能是订阅确实返回相同内容，也可能是客户端启用了保留自定义节点、按备注合并或缓存展示。先比较节点数量、备注和服务器地址，再完全退出列表页面重新进入。若客户端提供清除订阅缓存或不保留旧节点的选项，可在确认已有备份后使用。不要仅凭节点名称判断是否更新，因为提供方可能保留名称但替换地址，也可能改变名称而保持同一连接参数。

系统时间错误也可能让 HTTPS 订阅和节点连接同时失败，这是最容易被忽略的共同原因。若所有订阅突然报证书错误，同时所有 TLS 节点不可用，先同步时间，再重启客户端。只有一个订阅失败时则集中检查该地址。完成更新后，手动选择一个新节点并进行实际访问，不要让自动选择继续停留在已删除节点的缓存引用上。

把速度问题拆成延迟、吞吐与稳定性

“速度慢”至少包含三种不同现象：网页首次打开等待很久，通常与 DNS、连接建立和延迟有关；大文件持续下载速率低，更接近链路吞吐、拥塞和设备性能；速率忽高忽低或视频周期性缓冲，则要检查丢包、无线网络干扰、节点负载、协议重传和后台流量。只看一次延迟数字无法解释全部现象，应在相同设备、相同本地网络、相近时间内对比两个节点，并保持路由、DNS 和测试目标一致。

测试前暂停云同步、系统更新、游戏平台下载和其他设备的大流量任务。无线网络应靠近路由器测试一次，再使用网线或另一条网络复测。若直连下载本身就慢，代理无法消除本地接入瓶颈；若直连稳定而所有节点都波动，应检查本机代理链路、MTU、内核负载和网络对 UDP 的处理；若只有单个节点慢，则更可能是节点线路或远端负载。

检查路由是否造成绕行

规则模式会根据域名、IP、端口和协议选择出站。域名先被本地解析成某个 IP 后，如果 domainStrategy 与规则集配合不当，同一个网站的主页面、图片和视频可能分别走不同出站，表现为页面能打开但媒体资源很慢。排查时临时使用全局代理，对比同一资源。如果全局模式明显改善，应检查规则命中顺序、域名规则与 IP 规则是否冲突，以及 DNS 返回结果是否满足预期。

路由规则不是越多越好。大量重叠规则会增加维护难度，旧规则集还可能把新增域名归到不合适的出站。先使用客户端内置的简洁规则集，确认基础连接稳定，再添加必要的自定义项。每次只增加一组规则，并在日志中确认对应域名最终使用的出站标签。若某应用直接连接 IP，域名规则可能不会命中，此时需要根据应用特征、目标 IP 或端口设计规则，但应避免过宽的网段把无关流量一并送入代理。

Mux、并发与传输方式的取舍

Mux 可以让多个逻辑连接复用底层连接，在特定高延迟场景中减少重复握手，但它不保证提升吞吐。对于长时间大流量传输，复用连接可能让丢包影响多个请求；某些服务端配置也不适合客户端单方面开启。排查速度时先关闭 Mux，建立基线，再单独开启比较。若关闭后更稳定，就保持关闭；若大量短连接明显改善，再评估启用。不要同时调整 Mux、并发数、分片、DNS 和路由，否则无法确定哪项改变产生效果。

WebSocket、gRPC、TCP 等传输方式由服务端配置决定，客户端不能通过随意切换来“加速”。参数不匹配通常会直接失败，而不是得到更快链路。REALITY 与 TLS 解决的是握手和安全传输条件，也不是速度按钮。真正影响吞吐的因素包括本地接入质量、设备 CPU、远端容量、链路拥塞、丢包率、往返时间以及应用自身并发策略。

观察设备资源与 MTU 症状

低性能设备在高吞吐加密、复杂规则或大量并发时可能出现 CPU 占用升高。桌面端可同时观察任务管理器或系统监视器，Android 可关注设备发热与后台限制。如果速度上升时 CPU 接近满载，减少复杂路由、关闭不必要日志和并发功能，再比较不同内核客户端的表现。v2rayNG 使用 Xray 内核，v2flyNG 使用 v2fly 内核，二者适合作为 Android 上的对照，但节点协议必须被对应内核支持。

MTU 问题常表现为小网页能打开，大图片、上传或特定 HTTPS 页面卡住。VPN、隧道与某些宽带接入叠加后，有效报文尺寸可能降低。可先切换网络验证：如果同一设备在另一网络完全正常，原网络的 MTU 或路由设备值得检查。Linux 可使用不允许分片的 ping 逐步缩小报文尺寸，但不同系统参数写法不同，测试结果还会受目标是否响应影响，因此它只能作为线索。图形客户端没有必要为了普通速度波动直接改动底层 MTU；先确认症状与网络相关，再在系统或路由器层谨慎调整。

最终比较应使用相同文件、相同时段与至少数分钟的持续传输，记录平均速率和中断情况。一次峰值没有代表性。确认节点稳定后再恢复规则模式、自动选择和日常 DNS 设置，每恢复一项都复测一次，这样才能知道性能损失来自节点还是本地配置。

识别 DNS 故障的典型边界

DNS 把域名转换为 IP。解析失败时，直接访问已知 IP 可能仍有响应，而域名访问会提示找不到服务器；解析到不合适的地址时，页面可能连接超时、证书名称不匹配，或同一网站在不同网络表现不同。若所有网站都失败，不要立即断定是 DNS，因为本地代理端口、节点和系统代理同样会造成全断。更可靠的判断是分别查询域名、查看客户端 DNS 日志，并比较关闭代理前后的结果。

桌面系统可用 nslookup 或 dig 检查基础解析。命令输出中的 DNS 服务器、返回地址和错误类型比单纯的“能否打开网页”更有价值。若系统查询成功但通过代理访问失败，可能是 Xray 内置 DNS、路由规则或浏览器安全 DNS使用了另一套解析路径。浏览器、系统和客户端同时启用各自的安全 DNS 时，排查会变得困难，建议暂时保留一条明确路径。

nslookup example.com
dig example.com A
dig example.com AAAA

理解本地解析、远程解析与路由关系

域名可以在进入代理前由系统解析，也可以交给代理内核的 DNS 模块处理。前者便于系统缓存，但解析结果会受本地 DNS 影响；后者可让域名与路由规则保持更一致，但必须正确配置 DNS 出站和查询路径。Xray 的 domainStrategy 还决定路由匹配时是否解析域名。AsIs 尽量按原始域名处理，IPIfNonMatch 会在域名规则未命中时解析 IP 再尝试匹配。策略选择要与规则结构配套，不是数值越复杂越好。

下面是一个简化 DNS 结构，使用普通地址展示字段关系。实际使用时应根据网络环境和客户端界面配置，不要直接覆盖客户端自动生成的完整文件。

{
  "dns": {
    "queryStrategy": "UseIP",
    "servers": [
      {
        "address": "1.1.1.1",
        "domains": ["geosite:geolocation-!cn"]
      },
      "localhost"
    ]
  },
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

配置示例中的公共解析地址不一定适合所有网络。关键是确定查询从哪里发出、走哪个出站、返回 A 记录还是 AAAA 记录，以及结果如何参与路由。如果查询被直连发送，而当前网络无法稳定到达该解析服务，就会出现间歇超时；如果查询经代理发送，但代理尚未建立，又会形成启动依赖。客户端默认配置通常比从多个教程拼接出的复杂配置更容易维护。

清理缓存并处理 IPv6 差异

修改 DNS 后，系统、浏览器和客户端可能继续保存旧结果。Windows 可执行 ipconfig /flushdns 清理系统缓存；Linux 的具体命令取决于正在运行的解析服务；macOS 可通过重新连接网络或重启对应解析服务刷新。浏览器还可能维护独立连接池，应完全关闭相关页面并重新打开。清缓存只解决旧记录问题，不会修复错误的 DNS 路由或不可达的解析服务器。

ipconfig /flushdns
resolvectl flush-caches

IPv6 是另一条常见分支。域名若同时返回 A 与 AAAA 记录，系统或应用可能优先尝试 IPv6。当前网络看似分配了 IPv6 地址，但实际出口不稳定时，就会出现首连等待、部分域名失败或回退后才打开。可以暂时让 DNS 只返回 IPv4 结果进行对比；如果问题消失，应检查本地 IPv6 连通性和客户端的查询策略，而不是永久依赖反复刷新。反之，在 IPv6 网络正常时粗暴禁用它也可能丢失更合适的路径。

FakeDNS 的适用范围与退出条件

FakeDNS 会为域名分配保留地址，再由内核在连接阶段恢复域名，便于透明代理和按域名分流。它不是普通 DNS 的简单替代。某些应用会检查返回 IP、缓存地址后绕过代理，或直接使用内置解析逻辑，这些情况下可能出现登录失败、局域网设备不可达、推送异常或 UDP 应用不稳定。遇到这类边界时，应先关闭 FakeDNS，用常规 DNS 建立基线。更完整的机制说明可阅读FakeDNS 工作原理与适用场景。

若只有局域网主机名或打印机、路由器管理地址失败，应确保私有地址和本地域名走直连解析，不要交给远程 DNS 或 FakeDNS。若只有浏览器失败而其他应用正常，检查浏览器自身的安全 DNS；若所有应用都失败，检查系统 DNS 与客户端 DNS 入站。按“系统查询—客户端查询—浏览器查询”三层逐一验证，比频繁更换公共 DNS 更容易找到真正冲突点。

确认系统代理与本地入站端口一致

系统代理本质上是把支持代理设置的应用指向本机 HTTP 或 SOCKS 监听端口。客户端界面显示“系统代理已开启”时，仍需确认系统设置中的地址和端口与当前内核实际监听值一致。常见地址是回环地址，端口由客户端配置决定。若更改过本地端口但系统仍保留旧值，应用会连接到不存在的监听端口；若旧客户端进程仍占用该端口，流量可能进入错误实例。

先在客户端日志中确认入站已经启动，再使用端口查看命令验证监听进程。不要把远端节点端口与本地代理端口混为一谈：远端端口用于内核连接服务器，本地端口用于浏览器连接客户端。系统代理只需要填写本地监听地址，不应填写节点地址。修改后彻底关闭并重新打开浏览器，因为已建立连接可能继续沿用旧路径。

理解不同应用对系统代理的支持差异

浏览器和多数桌面网络程序会读取系统代理，但并非所有应用都会遵循。部分程序使用自己的代理设置，部分命令行工具只读取环境变量，还有应用直接建立网络连接。因而“浏览器可用、某个应用直连”并不表示系统代理整体失效。应先在一个明确支持系统代理的浏览器中建立基线，再查看目标应用是否提供 HTTP、HTTPS 或 SOCKS 设置。

命令行工具通常需要显式环境变量。下面示例将 HTTP 与 HTTPS 请求指向本地 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

SOCKS 代理还涉及域名解析位置。某些工具的 socks5 写法在本地解析域名，而 socks5h 会把域名交给代理端解析。若命令行只有域名失败而 IP 可连接，这一区别值得检查。不要同时在应用内设置代理、系统中设置代理，又让透明代理接管同一流量，否则连接可能重复进入客户端。

排查 PAC、绕过列表与规则模式

系统代理模式可能是全局、PAC 或保持不变。PAC 通过脚本决定哪些地址使用代理，脚本未更新、缓存旧内容或规则没有覆盖目标域名时，浏览器会直接连接。全局系统代理则把支持系统代理的请求统一送入客户端，但进入客户端后仍会受到 Xray 路由规则影响，所以“系统全局”不等于“所有流量都走代理出站”。排查时要分别观察操作系统这一层和内核路由这一层。

系统绕过列表通常包含局域网地址和本地主机名。列表写得过宽时，某些普通域名也可能绕过代理；写得过窄时，路由器管理页和局域网服务又可能被送入代理。建议保留回环地址和明确的私有网段，不用模糊通配符覆盖大批域名。若公司环境通过策略统一下发代理，客户端可能无法持续覆盖系统设置，此时应比较修改前后系统代理值是否被自动恢复。

处理退出后残留代理与休眠恢复

客户端异常退出、系统强制结束进程或设备休眠恢复后，系统代理可能仍指向本地端口，但对应内核已经停止。这时所有遵循系统代理的应用都会失败，而关闭系统代理后立即恢复。解决时先在系统网络设置中关闭代理，再重新启动客户端并由客户端重新开启。正常退出客户端通常会执行恢复动作，但不能依赖异常进程完成清理。

Windows 上还要区分当前用户代理设置与部分旧程序读取的不同接口；macOS 上应确认修改的是当前正在使用的网络服务；Linux 桌面环境可能有系统代理、桌面代理与应用环境变量三套来源。不要在所有位置同时填写，先选一种明确方式验证。使用 v2rayN 的 Linux 桌面安装与自启动时，可参考Linux 桌面安装指南检查用户服务和桌面会话是否处于同一环境。

最终验证应查看客户端访问日志是否出现目标域名。日志完全没有记录，说明流量没有进入客户端，应继续检查应用和系统代理；日志出现目标域名但走了 direct，说明是路由规则；日志显示走代理后超时，则回到节点与 DNS 章节。利用日志把问题分层，能够避免在系统代理失效时反复更换节点。

区分图形界面崩溃与内核启动失败

v2rayN 由图形界面、配置数据和代理内核共同组成。窗口打不开、窗口打开后立即消失、界面正常但连接按钮无效，分别可能属于不同层。若界面仍能操作但日志提示内核退出，重点查看生成配置与端口；若程序本身没有窗口，应检查系统事件、启动终端输出、文件权限和运行依赖。不要把所有启动问题都归因于节点，因为损坏的节点通常只会导致连接失败，不一定让整个界面无法显示。

排查前先完整结束相关进程，再重新启动一次。多次双击可能启动多个实例，造成配置文件锁定或本地端口冲突。桌面端应从任务管理器或系统监视器确认图形进程与 Xray 进程是否残留。若重启系统后恢复，仍应检查上一次日志中的端口占用与异常退出原因，避免问题在下一次休眠后重复出现。

从第一条配置错误向上追踪

内核加载配置时会验证 JSON 结构、字段类型、协议参数与引用标签。日志中后续的大量退出信息通常由第一条配置错误引发，真正有价值的是最早出现的 failed to load config、未知字段、缺少出站标签或 JSON 解析位置。手工编辑 JSON 时，逗号、引号和括号最容易出错；图形客户端生成配置失败时，则可能是某条自定义路由、DNS 条目或节点附加参数不合法。

JSON 不允许注释，也不允许最后一个成员后保留逗号。字符串中的反斜杠和双引号需要转义。下面结构语法完整，可用于对照基本层级，但不包含可连接节点：

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

若错误只在启用自定义配置后出现，先禁用自定义项并让客户端重新生成默认配置。确认默认配置可以启动后，再逐段添加 DNS、路由和出站。配置文件结构及各区块职责可参考V2Ray JSON 配置结构解析。不要直接把其他客户端的完整配置覆盖进当前客户端，因为界面可能依赖自身生成的入站标签、端口和管理接口。

检查目录权限、路径与安全软件拦截

客户端需要读取配置、写入日志并启动内核子进程。安装目录不可写、用户目录权限异常、路径所在磁盘只读，都会造成启动失败。Linux 上尤其要避免用管理员身份启动一次后，再以普通用户运行同一配置目录，因为前一次生成的文件可能归管理员所有。修正文件所有者和权限后，以普通桌面用户重新启动。macOS 与 Windows 则应确认程序目录没有被系统保护策略阻止写入，并查看安全软件是否隔离了内核文件或阻止子进程运行。

路径中包含特殊字符时，现代客户端通常能够处理，但外部脚本、旧配置或自定义命令可能错误拆分路径。可将配置目录临时移动到简短的用户目录进行对比。不要把配置放在实时同步目录中测试，文件同步可能在客户端写入时创建冲突副本或短暂锁定文件。确认问题与路径有关后，再逐项恢复原位置。

保留诊断资料并安全重建配置

需要重置时，先退出客户端并复制配置目录作为本地备份，然后只重命名当前配置目录，让客户端生成一套全新设置。若新设置可以启动，说明程序文件和系统运行环境基本正常，问题位于旧配置。此时应重新添加订阅和少量必要规则，不要立刻把整个旧目录覆盖回来。可以按订阅、路由、DNS、界面设置的顺序逐类恢复，每次启动验证一次。

若全新设置仍无法启动，再考虑重新安装。应从客户端下载页选择与平台和处理器匹配的 v2rayN；Android 使用 v2rayNG，或在需要 v2fly 内核时选择 v2flyNG。重新安装前记录日志错误、操作系统、处理器架构和复现步骤，这些信息比一张“无法启动”的截图更能定位问题。不要编造或猜测版本兼容关系，以下载页当前提供的包类型和系统要求为准。

若崩溃发生在导入某个节点后，可在新配置中先导入其他节点，再单独导入可疑链接。若发生在开启特定 DNS 或路由功能后，则保留默认设置并逐项复现。只要能确定“加入哪一项后开始失败”，就能把问题缩小到具体配置，而不必同时更换系统、客户端和订阅。

确认 VPN 权限与系统中唯一的连接实例

v2rayNG 和 v2flyNG 在 Android 上通常通过系统 VPN 接口接管流量。首次连接需要确认系统授权；若授权窗口被取消，客户端可以保存节点，却无法建立 VPN。状态栏出现 VPN 标识只代表接口已创建，仍需通过日志确认内核和节点连接成功。系统同一时间通常只保留一个 VPN 服务，其他 VPN 类应用、工作资料管理工具或系统网络功能可能抢占接口，导致刚连接就断开。

排查时先关闭其他 VPN 类功能，彻底停止 v2rayNG 或 v2flyNG，再重新打开并授权。不要让两款客户端同时处于自动连接状态。若切换客户端后旧 VPN 图标仍未消失，可在系统网络设置中断开当前 VPN，再启动目标客户端。节点在桌面端可用、Android 端立即失败时，应先比较 Android 导入后的协议、传输、安全方式、服务器名称与路径，确认二维码或剪贴板内容没有被截断。

处理省电策略与后台限制

屏幕熄灭几分钟后连接中断、重新点亮后恢复，通常与后台限制有关。Android 厂商的省电策略可能暂停客户端进程、限制后台网络，或清理长期运行的 VPN 服务。应在系统应用设置中允许客户端后台运行，取消针对该客户端的电池优化，并允许必要的自启动或后台活动。不同设备的菜单名称不同，但判断标准相同：客户端在锁屏后应继续运行，系统不应将其列为受限应用。

仅把客户端留在最近任务列表不一定足够；某些系统的“锁定任务”也不等同于后台网络许可。调整后应锁屏等待一段时间，再通过消息同步、网页请求或客户端日志确认连接是否持续。若只有移动网络切换到 Wi-Fi 时断开，可能是网络变化后旧连接没有及时重建。返回客户端手动停止再启动，可判断是否属于重连问题。频繁切网场景下，应避免同时启用系统始终开启 VPN、其他自动化网络工具和客户端自身自动连接，以免多个机制竞争。

应用分流与绕过设置的排查顺序

Android 客户端可按应用决定哪些流量进入 VPN。设置方向容易混淆：有的界面表示“仅代理所选应用”，有的表示“绕过所选应用”。若选项理解相反，会出现浏览器正常、目标应用直连，或只有少数应用能联网。排查时先关闭应用分流，让所有应用进入同一 VPN 路径，确认节点和 DNS 正常，再启用分流并只选择一个测试应用。

系统应用、工作资料中的应用与普通用户应用可能属于不同配置范围。目标应用若调用系统组件打开网页，主应用与系统组件可能走不同路径，表现为登录页和正文连接结果不一致。此时应同时观察客户端日志中是否出现目标域名，并检查相关系统组件是否被分流规则排除。不要一开始就添加大量应用名单，名单越长越难判断实际方向。

解决局域网访问、热点共享与 DNS 差异

开启 VPN 后访问路由器、局域网存储或打印设备失败，应检查“绕过局域网”或私有地址直连规则。局域网地址通常不应送往远端节点。若按 IP 可以访问、按本地主机名失败，则问题更接近本地 DNS 或组播解析，而不是节点。关闭 FakeDNS、让局域网域名使用本地解析，并确保私有网段走直连，可以建立更清晰的基线。

设备热点共享是另一层网络转发，连接本机热点的设备不一定自动使用手机上的 VPN。即使手机浏览器已通过客户端连接，热点下游设备也可能走独立出口。不要仅凭手机状态栏判断共享设备路径，应在下游设备上单独验证。若需求只是手机应用访问，关闭热点共享可减少变量；若需要处理共享流量，则要确认客户端和系统是否提供相应支持，不能把普通 VPN 模式的行为直接推断到热点。

Android 的私人 DNS 与客户端 DNS 可能同时存在。私人 DNS 配置不可达时，部分应用会持续等待；客户端启用 FakeDNS 或远程 DNS 后，又可能与系统策略产生不同解析结果。排查时将私人 DNS 恢复为系统自动，关闭客户端高级 DNS，仅保留默认设置。基础连接恢复后，再根据实际需求逐项开启。若只有某个应用失败，还要考虑应用内置 DNS、QUIC 或证书固定机制，不能把所有差异归为客户端错误。

收集日志并在两款 Android 客户端间对照

复现问题前先清空或记住当前日志位置，然后执行一次明确操作，例如断开后重新连接、打开一个失败域名或锁屏等待。记录第一条错误、所用网络类型、是否开启应用分流、DNS 模式和节点协议。日志中若完全没有目标请求，检查应用分流；若有请求但解析失败，检查 DNS；若节点连接超时，回到地址、端口与网络；若锁屏后内核日志停止，重点检查后台限制。

v2rayNG 使用 Xray 内核，是 Android 的首选客户端；v2flyNG 使用 v2fly 内核，可用于协议兼容和运行行为对照。对照测试时应导入同一份受支持节点，保持 DNS、路由和分流尽量简单。若两款客户端在同一网络都失败，而桌面端在另一网络正常，应让 Android 切换网络复测；若只有其中一款失败，则比较内核支持和生成配置。不要同时更换客户端、节点与网络，否则测试结果无法说明原因。

完成排查后，恢复必要的后台权限、应用分流和 DNS 设置，并逐项验证。长期稳定配置通常比堆叠大量实验选项更容易维护。首次配置步骤可返回使用指南重新核对；涉及证书握手的错误，可继续阅读TLS 与证书报错检查清单。