V2Ray 故障排查大全

一、建立可复现的诊断基线

先描述现象，不先猜原因

有效排查从一条可复现路径开始。先记录当前客户端、所选节点、系统代理模式、路由模式、发生时间与失败应用，再区分“所有网站都打不开”“只有特定域名失败”“浏览器正常但其他应用失败”“能连接但速度明显下降”等现象。节点名称本身不能证明节点可用，列表中的延迟值也不能代替完整连接测试。最好保留一个此前可工作的节点或配置作为对照；如果新旧配置在同一网络下表现不同，范围就能快速收缩到节点参数或路由规则。

随后做最小化测试：关闭其他代理客户端、浏览器代理扩展、抓包工具和临时网络加速功能，只保留一个 V2Ray 客户端运行；暂停自定义路由规则，切换到客户端提供的基础代理模式；选定一个节点后保持不变。桌面端还应确认系统时间、时区与日期准确，因为 TLS 证书验证依赖系统时间。移动网络与 Wi-Fi 的出口条件不同，测试时要明确当前使用哪一种网络，避免在切换网络后仍把结果归因于原来的配置。

按层判断故障位置

一次请求大致经过应用、系统代理或虚拟网络接口、本地入站、路由与 DNS、远端节点、目标服务器。浏览器完全没有请求进入客户端日志，通常先查应用和系统代理；日志出现连接节点超时，重点查本地网络到节点的链路；节点握手成功但目标域名解析失败，重点查 DNS；只有某一组域名走错出口，则查路由匹配顺序。这样的分层比反复重装客户端更有效，也能避免把多个独立问题混在一起。

保存日志与本地监听证据

日志应覆盖“启动客户端—选择节点—发起一次失败访问—停止测试”的完整过程。不要只截取最后一行，因为真正原因常出现在前面的配置加载或入站监听阶段。v2rayN 可查看主窗口日志区域与核心日志；v2rayNG、v2flyNG 可从日志页面观察连接、路由和错误信息。分享日志前应删去订阅地址、节点凭据、用户标识和完整服务器地址，只保留错误类型、发生顺序与必要参数。

桌面端可以确认本地代理端口是否处于监听状态。以下命令只检查本机端口，不会验证远端节点；端口号应替换为客户端设置里实际显示的 SOCKS 或 HTTP 端口。

netstat -ano | findstr LISTENING
curl --proxy http://127.0.0.1:10809 https://example.com/

若端口未监听，问题仍在客户端启动、端口冲突或核心加载阶段；若通过显式代理的命令可以访问，而浏览器不能访问，问题通常位于系统代理或应用代理层；若显式代理同样失败，再检查节点和 DNS。完成这一轮后，应能写出一条简短结论，例如“本地 HTTP 端口正常监听，浏览器请求进入日志，但连接节点地址超时”。这条结论就是后续排查的起点，而不是笼统的“V2Ray 不能用”。

二、启动代理后无法上网

区分本地断流与代理链路失败

“连接后无法上网”通常包含两类情况。第一类是系统代理已经指向客户端，但客户端本地入站没有正常监听，所有遵循系统代理的应用都会立即失败；第二类是本地入站正常，流量已经进入核心，但远端节点、路由或 DNS 没有完成请求。先观察客户端日志：访问网页时完全没有新增记录，说明流量没有进入客户端；出现目标域名与出站记录，则说明系统代理至少已经把请求送到本地核心。

先关闭系统代理并退出客户端，确认直接网络本身可用。如果直接网络也不能访问常用站点，应先修复 Wi-Fi、网卡、网关或本地 DNS，不要继续修改节点。直接网络恢复后，再启动客户端但暂不启用系统代理，确认核心没有启动错误；最后启用系统代理并访问一个固定测试页面。这样的启动顺序可以判断故障是在原始网络、核心启动还是代理接管之后出现。

检查端口、模式与进程归属

v2rayN 的 HTTP、SOCKS 与局域网监听是不同设置。系统代理必须指向当前实际监听的 HTTP 端口，不能照抄另一台设备或旧配置中的端口。若端口被其他程序占用，核心可能启动失败，也可能自动切换后与系统代理记录不一致。检查日志中是否有 address already in use、bind failed 或 listen failed 一类信息；发现冲突后，应退出占用程序，或在客户端中改为未使用端口，再重新设置系统代理。

浏览器能打开网页而命令行工具不能，并不一定是节点问题。许多命令行程序不会自动读取桌面系统代理，需要显式设置代理参数或对应环境变量。反过来，某些应用保存了自己的手动代理地址，即使系统代理已经关闭，仍会继续连接旧端口。排查时应检查应用内部的网络设置，把“跟随系统”“手动 HTTP”“手动 SOCKS”“直连”区分清楚。只有使用同一种代理入口测试，结果才可比较。

回到最简单的路由配置

复杂分流规则可能把 DNS、节点域名或目标请求送入错误出站。暂时禁用自定义规则集，选择基础全局代理模式进行对照。如果全局模式恢复，节点链路大概率正常，问题位于规则匹配；如果全局模式仍失败，则继续检查节点参数与 DNS。恢复分流时，应从少量明确规则开始，先放置私有地址和本地网络直连，再放置确定的域名规则，最后设置兜底出站。规则通常按顺序匹配，前面的宽泛规则会遮蔽后面的精确规则。

还要检查出站标签是否真实存在。规则引用的标签与当前配置中的代理、直连、拦截出站必须完全一致，大小写和拼写差异都可能导致加载失败或落入默认出站。订阅更新后，客户端管理的出站结构可能变化，因此不应把另一套完整配置中的标签机械复制到当前客户端。若核心日志明确提示找不到 outbound、invalid field 或配置解析错误，应先恢复客户端生成的默认配置，再逐条添加自定义项。

恢复网络状态

客户端异常退出后，系统代理可能仍保留为本机地址，而对应端口已经无人监听，于是浏览器表现为全部断网。重新打开客户端并执行“清除系统代理”，或在系统网络设置中关闭手动代理，再重新测试直连。若使用虚拟网络模式，还要正常停止该模式，让路由表与 DNS 设置恢复；仅强制结束进程可能留下临时网络状态。恢复后重新启动客户端，先确认直连，再确认显式本地代理，最后才启用系统级接管。

若只有局域网资源不能访问，检查私有网段是否被代理。家庭路由器、打印机、存储设备和公司内部服务通常使用私有地址，应由直连出站处理。把私有地址规则放在兜底代理规则之前，并确认虚拟网络模式没有把局域网发现流量错误送入远端。若只有单个站点失败，可在浏览器隐私窗口中排除缓存与扩展影响，并查看该域名在日志中最终命中了哪个出站。完成这些检查后，通常能把“无法上网”拆成明确的端口、规则、DNS 或节点问题。

三、节点超时与握手失败

读懂超时、拒绝与握手错误

节点列表显示超时，只能说明测试请求在限定时间内没有完成，不能单独证明服务器永久不可用。连接超时通常表示到节点地址与端口的 TCP 或 UDP 路径没有及时建立；连接被拒绝表示目标地址可达，但对应端口没有服务接受连接；连接被重置表示链路建立后被某一端主动中断；TLS 握手错误则应进一步检查服务器名称、传输层、安全参数与系统时间。不同错误指向不同层，不能统一归结为“节点失效”。

先对同一订阅中的两个节点做真连接测试。如果所有节点在当前网络同时超时，而切换到另一网络后恢复，应优先检查本地网络出口、防火墙或路由路径。如果只有一个节点超时，其他节点正常，问题更可能位于该节点地址、端口或远端服务。如果同一节点在多台设备和不同网络均失败，再联系配置提供方核对节点状态与参数，比不断更改客户端设置更直接。

逐项核对节点参数

手动导入节点时，地址、端口、用户标识、协议、安全层、传输方式、服务器名称和路径需要成组一致。VLESS、VMess 等协议的字段不能互相套用；WebSocket、gRPC、TCP 等传输方式对应的路径、服务名和请求头也不同。最常见的问题不是字段缺失，而是从旧节点复制配置后只改了地址和端口，遗留了不匹配的服务器名称或传输参数。应将客户端编辑页与原始配置逐字段对照，不要依赖节点备注判断。

启用 TLS 时，服务器名称通常用于证书校验与握手，不能随意替换成节点 IP。系统时间误差过大会导致证书尚未生效或已经过期的判断异常。若日志出现 certificate、handshake、server name 或 verify failed，应先校准系统时间，再核对服务器名称与安全设置。不要通过关闭必要验证来掩盖参数不一致；正确处理方式是取得与服务端一致的配置。若使用 REALITY 等安全方式，还需保持公钥、短标识、服务器名称与流控参数一致。

延迟测试并不等于可用性结论

ICMP ping、TCP 连接、代理握手和下载测速测量的是不同阶段。服务器可以不响应 ping，但代理端口正常；TCP 端口可以建立连接，但协议认证失败；真连接延迟可以很低，持续传输带宽却很有限。因此选择节点时，应先用客户端提供的真连接测试确认代理握手，再用实际网页和文件传输验证稳定性。关于三种测试的差异，可继续阅读V2Ray 延迟测试原理。

测试过程还应避免并发过多。一次对大量节点同时测速会占用本地连接、DNS 查询与网络出口，部分路由器也会对短时间内大量新连接做限制，结果可能出现整批超时。先选少量节点顺序测试，等待前一轮连接释放，再比较结果。移动网络下信号切换、后台省电和网络类型变化也会让短时测试失真，应在网络稳定后复测。

确认地址解析与协议所需网络

当节点地址是域名时，客户端必须先解析该域名。若当前 DNS 规则又要求通过尚未建立的代理查询，就可能形成启动依赖：没有节点就无法解析 DNS，没有 DNS 又无法连接节点。可临时使用可靠的直连 DNS 解析节点域名，同时让目标域名按既定策略解析。使用 UDP 的功能还要求本地网络、客户端入站、远端节点与出站路径共同支持，不能只看客户端是否勾选 UDP。

最终记录应包含节点参数是否来自完整导入、同组其他节点是否可用、换网络后是否恢复、错误发生在 TCP 建连还是协议握手。若问题只发生在一个节点且跨网络复现，保留日志中的错误类型即可，不必暴露完整凭据。若所有节点只在当前网络失败，则把重点转向本地防火墙、路由器、DNS 与网络出口，而不是继续编辑每个节点。

四、订阅更新与导入失败

先判断是下载失败还是解析失败

订阅失败至少分为三个阶段：客户端没有取得订阅内容、取得内容但格式无法解析、解析成功但节点没有进入当前分组。更新时先查看日志与提示文字。HTTP 超时、连接失败或域名解析失败通常属于下载阶段；base64、JSON、YAML 或 unsupported scheme 一类提示通常属于内容解析阶段；更新完成但列表没有变化，则可能是分组选择、去重、筛选或订阅内容本身未变化。

确认更新的是当前正在查看的订阅分组。v2rayN 支持多个订阅分组，节点列表可能仍停留在另一个分组；更新命令也可能只作用于选中的分组。不要在同名分组之间反复导入同一地址，应先查看分组属性中的订阅地址、启用状态与更新结果。Android 客户端同样要区分单节点导入、剪贴板批量导入与订阅管理，三者不会自动合并为同一个更新源。

检查订阅地址的完整性

从聊天工具或网页复制订阅地址时，前后空格、换行、转义字符和被截断的查询参数都可能导致请求失败。应在订阅编辑框中确认地址从协议头到最后一个参数完整连续。某些地址带有临时令牌或设备参数，少复制一个字符就会返回未授权或空内容。不要把订阅地址粘贴到公开日志、截图或在线分析工具中，因为它通常具备获取配置的权限。

若客户端支持通过代理更新订阅，应分别测试“直连更新”和“通过当前代理更新”。当前网络能够直接访问订阅服务时，直连路径最简单；需要经过已有节点才能访问时，则必须保证先有一个可用节点。若唯一订阅中的所有旧节点都已不可用，通过代理更新会形成死循环，此时应向配置提供方取得可直接访问的新地址或独立配置，而不是继续刷新同一失败请求。

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

先看更新时间与日志是否真的发生变化，不要只看节点数量。订阅服务可能返回与上次相同的内容，客户端也可能按节点标识去重，因此数量不变是正常结果。检查是否启用了名称筛选、正则过滤、仅保留特定协议或删除旧节点等选项。过滤表达式过宽时，新节点可能在解析后全部被排除；表达式语法错误时，部分客户端会保留旧列表并提示更新失败。

对订阅分组做修改前先导出当前可用配置，随后新建一个临时分组导入同一订阅。临时分组可以排除旧缓存、旧筛选条件与重复项影响。如果临时分组也为空，重点查订阅返回内容；如果临时分组有节点，而原分组没有，重点查原分组的过滤、排序与更新设置。完成比较后再决定是否替换原分组，不要一开始就删除唯一可用节点。

识别格式与客户端能力差异

订阅内容可能是协议链接集合，也可能是结构化配置。客户端只能解析自身支持的格式和字段。把完整核心配置当作普通订阅导入，或把单个分享链接放进订阅地址栏，都可能得到格式错误。应确认提供方标明的导入方式与当前客户端一致。v2rayNG 使用 Xray 内核，v2flyNG 使用 v2fly 内核，两者对部分新字段与传输组合的支持范围可能不同；同一内容在一个客户端可导入，不代表另一个客户端必然接受。

{
  "remarks": "example-subscription",
  "url": "https://example.com/subscription?token=xxxx",
  "enabled": true
}

上面的结构只用于说明需要核对的逻辑字段，实际订阅应通过客户端界面添加，不要把示例直接当作客户端配置文件。出现解析错误时，保留错误行附近的字段名，并确认客户端与内核来自当前下载页提供的安装入口。不要编造版本号判断兼容性，应以客户端实际显示的功能和日志为准。

若订阅请求间歇性失败，应在同一网络下间隔一段时间重试，并比较直连与代理更新结果。频繁连续刷新可能触发服务端请求限制，也会让日志堆叠得难以阅读。最终应明确回答：请求是否成功、返回内容是否可解析、节点是否进入目标分组、过滤规则是否删除了结果。更多短问题可在帮助中心按“安装配置”分类继续核对。

五、连接正常但速度慢

把延迟、带宽与稳定性分开测

速度慢不能只看节点列表中的毫秒数。延迟决定短连接建立和交互响应，带宽决定持续传输速度，丢包与抖动决定视频、通话和长连接是否稳定。一个低延迟节点可能出口带宽有限；一个延迟稍高的节点可能持续下载更快。测试时先打开固定网页观察首屏响应，再做持续传输，最后观察几分钟内是否反复断流。三种现象应分别记录，避免用一次测速结果替代完整判断。

建立对照组时，保持设备、网络、目标资源和测试时间接近，只更换节点。先测直连网络可用带宽，再测两个不同线路的节点。如果直连本身很慢，优先处理 Wi-Fi 信号、移动网络质量和本地占用；如果所有节点速度都接近同一低值，检查设备性能、虚拟网络模式和远端出口；如果只有一个节点明显慢，则更可能是该线路拥塞或出口质量问题。

排除本地资源与并发影响

同步软件、系统更新、云盘、视频播放和其他设备都可能占用上行或下行。尤其上行被占满时，确认包无法及时发送，下行也会表现为卡顿。测试前暂停大流量任务，并在路由器或系统任务管理器中观察网络占用。浏览器同时打开大量页面、下载器开启高并发、客户端对全部节点并行测速，也会消耗连接数和 CPU，导致结果不稳定。

客户端核心需要处理加密、传输封装、路由匹配与 DNS。低功耗设备在高吞吐下可能出现 CPU 饱和，表现为速度达到某个上限后不再增长。可观察系统资源：若传输时单核持续满载，减少复杂规则、关闭不需要的日志级别，并比较系统代理模式与虚拟网络模式的差异。不要为了追求速度随意修改不理解的传输参数；客户端配置必须与远端服务一致，单方面调整往往只会导致连接失败。

检查路由是否绕行

速度问题有时是路由问题。原本应直连的本地或区域资源被送入代理，会增加路径与出口负担；原本应走代理的目标被误判直连，则可能反复重试。查看日志中的目标域名、解析结果与最终出站，确认规则命中符合预期。使用 geosite 与 geoip 分流时，域名规则和 IP 规则可能得出不同结论，且规则顺序会决定最终结果。

先使用全局代理模式测节点上限，再恢复分流模式。如果全局模式快而分流模式慢，应检查 DNS 与规则匹配；如果两者都慢，继续检查线路和设备。如果只有首开页面慢、后续访问正常，常见原因是 DNS 查询、首次 TLS 握手或连接建立；如果开始很快、持续传输后下降，则更像线路拥塞、丢包、设备温度或带宽限制。路由规则的实际配置方法可参考geosite 与 geoip 分流实战。

使用可重复的测试方法

不要同时使用多个测速网站并把结果混在一起。选择固定资源，在相近时间测试直连、节点 A、节点 B，每种状态重复两到三次，记录中位表现而不是最高值。测试中保持路由模式一致，并关闭浏览器缓存对下载结果的影响。若目标资源本身对不同出口有不同调度，换另一个稳定资源交叉验证，避免把目标站点的单点拥塞误判为节点速度。

真连接延迟测试应限制并发，节点数量多时分组执行。若日志中频繁出现 retry、broken pipe、reset 或 idle timeout，即使平均速度尚可，也说明链路稳定性不足。此时应优先选择丢包更少、重连更少的节点，而不是只选延迟最低者。视频与交互应用通常更在意稳定性，长时间文件传输则更在意持续带宽，选择标准不能完全相同。

完成排查后，应能判断瓶颈位于直连网络、设备处理、路由绕行、DNS 首查、单个节点线路或目标资源。若瓶颈随时间段变化，保留不同时段的对照记录；若随网络变化，重点比较 Wi-Fi 与移动网络；若随客户端模式变化，检查虚拟网络接口和规则复杂度。这样的结论比“测速低”更适合后续处理。

六、DNS 解析错误、污染与泄漏式错配

识别 DNS 故障的典型表现

DNS 问题常表现为域名打不开但直接访问已知 IP 有响应、同一网站在不同应用中结果不同、切换代理模式后解析地址发生变化，或日志出现 lookup、resolve、no such host、SERVFAIL、NXDOMAIN 等信息。还可能出现节点本身能连接，但目标域名被解析到不合适地址，最终表现为超时或证书名称不匹配。排查时必须把“节点域名解析”和“访问目标域名解析”分开，两者可能使用不同路径。

先清理系统与浏览器缓存，再重复查询。浏览器可能启用独立的安全 DNS，不一定遵循系统或客户端设置；系统也可能缓存旧答案。测试时关闭浏览器独立 DNS 或明确记录其状态，然后使用系统查询工具与客户端日志对照。Windows 可用 nslookup 查询，macOS 与 Linux 可用 dig 或 nslookup。查询结果不同并不自动代表某一方错误，还要看请求最终应由直连 DNS 还是代理侧 DNS 处理。

nslookup example.com
nslookup example.com 1.1.1.1

dig example.com
dig @1.1.1.1 example.com

理解本地解析与远端解析

本地解析会先在设备侧取得 IP，再由路由规则处理连接；远端解析通常把域名交给代理侧处理。前者便于按 IP 规则分流，也依赖本地 DNS 的结果；后者可避免本地解析路径影响目标域名，但客户端仍需解决节点地址与部分直连域名。具体模式名称因客户端与内核配置不同，不应只根据一个开关名称判断，需结合日志确认域名是在本地还是远端被解析。

若路由规则同时包含域名和 IP 条件，要注意解析策略决定是否产生可供 IP 规则匹配的地址。只按域名匹配时，不一定需要提前解析；需要按 geoip 判断时，核心可能先解析再匹配。错误的策略会出现“域名规则没命中、IP 规则也没有预期结果”的现象。应先定义需求：本地域名和私有地址直连，特定域名走指定出站，其余请求走默认出站；随后选择与该需求一致的解析路径。

防止启动依赖与解析回路

如果节点地址本身是域名，而配置又要求所有 DNS 查询都通过该节点，就会产生解析回路。解决方法是为节点域名提供可在代理建立前使用的引导解析，或让节点域名走明确的直连 DNS。引导 DNS 只负责建立代理所必需的少量解析，不应与目标域名策略混为一谈。日志中若反复出现对节点域名的查询、连接尚未建立便再次发起 DNS 请求，通常应检查这一依赖关系。

虚拟网络模式还可能接管系统 DNS。客户端异常退出、网络切换或休眠恢复后，系统可能保留已经不可达的 DNS 地址，表现为关闭代理后也无法解析。此时先正常停止虚拟网络模式，再查看系统网卡的 DNS 是否恢复为自动或原有设置。不要在客户端运行期间同时由多个网络工具修改 DNS，否则很难确认最终生效的是哪一套配置。

用日志验证最终答案

修改 DNS 后不要只看网页是否偶然打开。应清理缓存，查询固定域名，记录返回地址，再从客户端日志确认该域名命中的出站。若同一域名有多个地址，短时间内变化可能来自正常的负载调度；真正需要关注的是地址类别与出站是否符合路由设计。只有解析结果、路由命中和最终连接三者一致，才能认为配置有效。

当单个域名持续失败时，比较其根域名与子域名，检查是否存在单独的域名规则、hosts 覆盖或缓存。hosts 条目优先级通常较高，旧条目会让所有 DNS 设置看起来都不生效。若错误只出现在某个浏览器，清理该浏览器的 DNS 与连接缓存；若所有应用一致，则回到系统和客户端层。更换 DNS 服务只能作为对照，不应代替对解析路径的确认。

DNS 修复后的验收标准包括：客户端冷启动可以连接节点；系统查询与预期解析路径一致；浏览器和命令行在采用同一代理入口时结果一致；切换网络、休眠恢复和正常退出后系统 DNS 能恢复。若仅在虚拟网络模式下失败，而普通系统代理正常，应继续检查虚拟接口的 DNS 接管、路由优先级和系统权限。

七、系统代理设置不生效

确认应用是否遵循系统代理

系统代理不是所有程序都会自动使用的统一隧道。浏览器和部分桌面应用通常读取系统代理，命令行工具、游戏、后台服务和使用自有网络栈的程序可能忽略它。出现“浏览器正常、某个应用直连”时，先查该应用是否支持系统代理，是否保存了手动代理，是否需要单独设置 HTTP 或 SOCKS。若应用明确不读取系统代理，可考虑客户端提供的虚拟网络模式，但启用前要理解其权限、路由与 DNS 接管范围。

反过来，浏览器代理扩展可能覆盖系统设置。扩展指向旧端口、旧协议或另一代理程序时，v2rayN 的系统代理状态不会决定浏览器实际路径。排查时暂时禁用扩展，使用浏览器默认网络设置；若恢复正常，再重新配置扩展。企业管理策略也可能锁定代理项，此时系统设置界面虽然可见，应用读取的值仍可能由策略决定，应查看系统代理页面是否提示由组织管理。

核对协议与监听地址

HTTP 代理与 SOCKS 代理不能只靠端口号互换。系统代理通常需要 HTTP 入口，而某些工具可以直接使用 SOCKS。应在客户端设置中确认每个入站的协议、监听地址与端口，再让应用对应填写。监听在 127.0.0.1 表示仅本机可访问；允许局域网连接后，客户端可能监听全部接口，但这不是本机系统代理生效的必要条件。日常使用中不应为了修复本机代理而随意开放局域网监听。

使用以下方式可验证显式 HTTP 代理。若命令成功、系统代理模式下浏览器失败，问题在系统代理记录或浏览器覆盖；若命令连接本地端口就被拒绝，检查核心进程与端口；若本地连接成功但远端失败，则转查节点、路由和 DNS。

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

示例端口只是演示，必须以客户端当前设置为准。--socks5-hostname 会让域名通过 SOCKS 路径解析，适合与本地解析方式做对照。不要同时运行多条自动设置系统代理的程序，它们可能轮流覆盖系统值，导致界面状态与实际注册表或网络服务设置不一致。

处理异常退出后的残留代理

客户端被强制结束、系统突然关机或核心崩溃后，系统代理可能仍指向本机端口。此时所有遵循系统代理的应用都会失败，看起来像网络断开。先重新启动原客户端，执行清除或关闭系统代理，再正常退出；也可以进入系统网络设置手动关闭代理。恢复直连后，再启动客户端并重新设置。不要在网络已断的状态下立即删除所有配置，否则会失去判断残留端口和原设置的依据。

Windows 环境还需区分不同账户和权限上下文。以不同权限启动的程序可能读取不同环境变量或设置范围，后台服务也不一定使用当前桌面账户的代理。macOS 的代理设置按网络服务保存，Wi-Fi 与其他网络接口可能拥有不同配置；切换接口后，应确认当前活动网络服务的代理状态。Linux 桌面环境可能同时存在桌面代理、环境变量和应用独立设置，三者要逐层核对。

环境变量与命令行程序

命令行程序常读取 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY 与 NO_PROXY。变量可能来自当前终端、用户配置文件、系统服务或容器环境。若终端仍保存旧端口，即使桌面系统代理已经更新，命令行请求也会失败。检查变量后重新打开终端，确保新进程读取最新值。内网域名和本地地址通常应加入不经过代理的范围，但规则应保持精确，过宽的排除项会让本应代理的请求直接连接。

set HTTP_PROXY
set HTTPS_PROXY

env | grep -i proxy

清空变量前要记录其来源，避免只在当前终端临时修改，下一次启动又恢复旧值。容器和子系统拥有独立网络命名空间时，127.0.0.1 可能指向容器自身而不是宿主机，必须使用其能够访问的宿主机地址，并确认客户端是否允许相应接口连接。这属于应用网络边界问题，不是节点协议问题。

最终应确认：核心端口实际监听；系统代理指向同一端口和正确协议；浏览器没有扩展覆盖；命令行变量没有旧值；异常退出后代理能够恢复；不遵循系统代理的应用采用了明确方案。若要重新安装客户端，应先从客户端获取页选择对应平台，并在卸载前记录当前端口、分组和路由设置，避免安装后把配置差异误认为程序问题。

八、客户端无法启动、闪退与核心崩溃

区分界面进程与核心进程

v2rayN 等图形客户端通常负责配置管理、订阅、系统代理与界面展示，实际连接由 Xray 或 v2fly 内核进程处理。界面能打开但无法连接，可能是核心没有启动；界面直接退出，则优先查运行环境、配置文件、权限与程序文件。任务管理器或系统进程列表中只看到界面进程，不代表核心已正常运行。日志中若停在“启动核心”之前和之后，排查方向也不同。

首先完全退出客户端，确认没有残留界面和核心进程，再重新启动一次。不要连续点击多次启动，否则多个实例会争用配置文件和监听端口。若客户端提示已有实例运行，先在任务管理器中结束残留进程，等待端口释放，再启动。若每次都在加载某个配置后退出，可暂时把当前配置导出备份，然后切换到一个最简单的已知有效配置测试。

检查配置解析与写入权限

手动编辑 JSON 时，一个多余逗号、错误引号或字段类型都可能阻止核心加载。日志中的 failed to parse、invalid character、unknown field 或 failed to load config 通常会给出字段位置。应使用客户端界面恢复默认生成配置，再逐项加入自定义 DNS 和路由，而不是在错误文件上继续叠加。下面是一个语法完整的最小 JSON 结构示意，用于理解括号与数组关系，不包含可直接连接的节点。

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [],
  "outbounds": [
    {
      "protocol": "freedom",
      "tag": "direct"
    }
  ]
}

配置目录不可写时，订阅更新、日志创建和设置保存都可能失败。检查客户端所在目录与用户数据目录是否允许当前账户写入，避免从只读位置直接运行。安全软件隔离核心文件时，界面可能报找不到核心或启动后立即结束；应查看系统安全记录，确认文件来源与本站下载入口一致，再根据本机管理策略处理。不要从不明位置补齐单个核心文件，这会造成界面与内核组合不一致。

处理端口冲突与重复实例

核心启动后立即退出，常见原因是本地端口已被占用。日志会出现 bind、listen 或 address already in use。先查明占用进程，判断它是旧客户端实例、另一代理程序还是系统服务。若是残留实例，正常结束后重启；若端口属于必要服务，在客户端中修改 HTTP 与 SOCKS 端口，并同步更新系统代理、浏览器扩展和命令行环境变量。只改客户端端口而不改使用方，会把“崩溃”转化为“代理不生效”。

多个用户账户、远程桌面会话或开机自启动任务也可能启动不同实例。检查启动项和计划任务，确保只有一个负责设置系统代理的客户端。若需要并行运行不同配置，必须为每个实例分配独立的数据目录、日志与监听端口；普通排查不建议这样做，因为结果难以归因。

从干净状态恢复，而不是盲目删除

恢复前先备份订阅分组、手动节点和自定义路由，但订阅地址与节点凭据不要放进公开位置。随后关闭系统代理和虚拟网络模式，正常退出客户端，再将现有配置目录重命名为备份目录。启动客户端生成新的默认配置，确认界面和核心能够运行，然后逐项导入：先单个节点，再订阅分组，最后路由与 DNS。在哪一步重新崩溃，就重点检查该类数据。

若全新配置仍无法启动，转查运行环境、系统权限、程序架构与安全软件记录。macOS 需要确认系统对应用的打开许可；Linux 应从终端启动以观察缺失依赖和权限错误；Windows 应查看应用程序事件和客户端日志。错误报告中保留异常模块、退出阶段与错误代码，但删除个人路径、订阅内容和凭据。

若崩溃只发生在更新订阅或大量测速时，应减少并发并观察内存与磁盘空间；若只发生在休眠恢复后，检查网络接口变化和旧核心进程；若只发生在虚拟网络模式，检查驱动、权限与其他虚拟接口冲突。完成排查后，应能确定是界面、核心、配置解析、端口、权限还是运行环境问题，再决定修复配置或重新安装，而不是把所有异常统一归因于客户端版本。

九、Android 连接与后台运行专项

确认虚拟网络授权与当前客户端

v2rayNG 与 v2flyNG 在 Android 上通常通过系统虚拟网络接口接管流量。首次启动连接时需要系统授权；授权被拒绝、被另一虚拟网络应用占用或系统在重启后撤销时，客户端可能显示正在启动但没有实际接管。先停止其他使用同类系统接口的网络工具，再重新启动当前客户端并确认授权提示。状态栏出现连接标记只是接口建立的线索，仍需通过日志和实际访问验证节点链路。

不要同时保留两个客户端处于连接状态。v2rayNG 使用 Xray 内核，v2flyNG 使用 v2fly 内核，配置字段支持范围可能不同。把同一个订阅导入两个客户端做对照时，应分别停止前一个连接，再启动后一个；否则系统只允许其中一个接口生效，结果会被误判为节点故障。桌面端可用 v2rayN 做交叉验证，但跨设备比较时要考虑 Wi-Fi、移动网络与 DNS 路径差异。

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

部分 Android 系统会限制后台进程、锁屏网络和电池使用。典型现象是前台连接正常，锁屏数分钟后断开，重新打开客户端又恢复。应在系统应用设置中允许客户端持续后台运行，关闭对该客户端的严格电池限制，并确认系统没有自动清理其通知或服务。不同设备的菜单名称不同，应以“电池”“后台使用”“自启动”“应用启动管理”等实际设置为线索。

完成设置后不要只看客户端按钮状态。建立连接，访问固定网页，锁屏等待，再解锁重复访问并查看日志时间线。如果日志中间完全停止，通常是进程被系统暂停；如果日志持续但连接重建，可能是网络接口在休眠期间切换；如果请求进入日志后节点超时，则继续检查网络路径。保持常驻通知通常有助于系统识别正在运行的网络服务，不应随意关闭相关通知类别。

Wi-Fi 与移动网络切换

从 Wi-Fi 切换到移动网络时，设备 IP、DNS、最大传输单元和网络能力都会变化。旧连接通常需要重新建立，短暂失败属于切换过程的一部分；若切换后长期无网络，应停止并重新启动客户端，让虚拟接口绑定到新网络。反向切换到 Wi-Fi 时也应复测，尤其是需要网页登录认证的公共网络：应先暂停代理完成网络认证，再重新连接。

若 Wi-Fi 正常而移动网络超时，比较节点地址是否能在移动网络解析，检查移动网络接入点是否限制特定连接方式，并换订阅中的其他节点对照。若移动网络正常而家庭 Wi-Fi 失败，检查路由器 DNS、防火墙与同网其他设备。不要在切换网络的同时修改节点参数，否则无法判断恢复是由网络变化还是配置变化引起。

分应用代理与绕过设置

Android 客户端常提供分应用代理。启用后，必须明确当前模式是“仅代理选中应用”还是“绕过选中应用”。两种模式方向相反，选错后会出现浏览器正常、其他应用直连，或只有少数应用失败。排查时暂时关闭分应用设置，让所有应用使用同一路径；确认基础连接正常后，再逐个加入应用并测试。应用更新或重新安装后标识可能变化，也应重新核对列表。

局域网应用、投屏、打印和设备发现可能需要绕过代理，但具体流量还受虚拟接口路由控制。若局域网访问失败，确认客户端是否允许局域网绕过，并检查私有地址是否走直连。不要用过宽的绕过范围覆盖所有流量；每次增加一项后，用目标应用验证。若应用内部还有独立代理或安全 DNS，也要临时恢复默认，避免与客户端的虚拟网络设置叠加。

移动端日志与最终验收

移动端日志采集应覆盖连接启动、切换网络、锁屏恢复和失败应用发起请求的时间点。记录系统是否显示虚拟网络连接、客户端服务是否仍在运行、请求是否进入日志、节点是否重连。分享日志前删除订阅地址、用户标识和服务器完整信息。若问题只在某个应用出现，应同时记录该应用是否启用独立 DNS、是否被分应用规则选中，以及浏览器对照是否正常。

最终验收至少包含四项：前台连续访问正常；锁屏恢复后能够继续访问；Wi-Fi 与移动网络切换后能自动恢复或通过一次重连恢复；分应用规则与预期一致。若 v2rayNG 与 v2flyNG 对同一配置表现不同，先确认该配置的内核字段兼容性，再决定使用哪一个客户端，不要把客户端名称差异当作唯一原因。需要重新获取安装入口时，回到Android 客户端下载区。

完成九章排查后，仍无法定位时，可把问题压缩成“在哪个层发生、哪种对照会改变结果、日志给出什么错误”。例如“显式本地代理可用但系统代理无效”“节点在 Wi-Fi 超时而移动网络正常”“订阅下载成功但解析为空”“锁屏后核心日志停止”。再到帮助中心查找对应分类，或回到使用指南重建一条最小可用配置。系统化排查的目标不是尝试更多设置，而是用更少的变量得到可验证结论。