V2Ray 故障排查大全

无法上网：先确定流量停在哪一层

恢复基础网络，再测试代理入口

先退出客户端或关闭代理，并在系统网络设置中确认手动代理已经取消。如果普通网站仍打不开，优先检查无线网络认证、网关、系统时间和网络连接，而不是继续修改节点。酒店、校园或公共无线网络可能要求先在浏览器完成认证；代理开启后，认证页面的跳转反而容易失败。基础网络恢复后，再启动客户端并选择一个已知可用的配置，避免把接入网络故障误认成代理故障。

随后区分“界面显示运行”与“内核确实监听”。打开 v2rayN 主界面的日志区域，查找配置加载、入站监听和启动失败信息。若出现地址占用、配置解析失败或内核退出，浏览器还没有机会连接远端。进入设置中的基础设置或入站设置，读取实际本地监听端口；不同界面名称可能变化，应以当前设置和启动日志为准。不要直接照抄教程中的端口，也不要把远端服务器端口填进系统代理。

用显式代理请求分离问题

下面命令假设本地提供 HTTP 代理，且实际端口确认为 10808。Windows 使用 curl.exe，避免命令被终端别名替换；其他桌面系统可使用 curl。测试地址只用于验证请求路径。若本地仅启用 SOCKS 入站，应改用对应的 SOCKS 参数，不能向 SOCKS 端口发送 HTTP 代理握手，否则测试失败只能说明协议不匹配。

curl.exe --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 25 -I https://example.com/

如果显式代理请求成功，而浏览器失败，重点转向系统代理、浏览器扩展和浏览器自身的代理设置。如果命令立即报告无法连接本地地址，检查监听端口、内核进程和安全软件规则；如果连接本地成功后才超时，再查节点、路由和 DNS。返回网页状态码不必一定是成功码：拒绝访问等响应也可能证明请求已经到达目标，但仍要结合日志确认使用了预期出站。

把全局模式作为短时诊断工具

暂时关闭 TUN，只保留系统代理，并将客户端路由切到全局代理后重测同一地址。如果此时恢复，问题更可能位于分流规则或直连出口，而非节点认证。全局路由通常只是让已进入内核的流量统一选择代理出站，不会自动接管所有进程；不能因为切换全局后某个应用仍不通，就认定节点完全不可用。测试结束后恢复原来的模式，避免扩大流量范围。

若只有单一网站失败，应对照同一浏览器的其他网站，并查看错误是否与证书、重定向或登录状态相关。若所有代理请求都失败，再更换另一个节点做对照。不要一开始就更换传输协议，因为协议、端口、路径、流控和服务端配置必须成套匹配。服务端没有对应入口时，客户端单方面换协议不会改善连接，反而增加新的错误来源。

节点超时：分开检查传输与认证

确认测试方法到底测了什么

节点列表中的延迟测试并不总是完整代理请求。TCP 测试通常只检查服务器端口能否建立连接；真连接测试还会经过代理握手并请求测试地址。因此，TCP 能通而真连接失败并不矛盾，可能是认证、TLS、传输路径或测试目标出了问题。反过来，列表显示超时也不能单独证明所有应用都无法访问，应先查看所选测试方法和超时范围，再用实际网页请求复核。

只选择一个节点执行测试，同时查看同一时间段的日志。连续测试整个列表会制造大量并发连接，容易触发远端限速、连接数限制或本地资源争用，反而淹没原始错误。记录错误发生在解析地址、建立连接、TLS 握手还是读取响应阶段。如果日志只有笼统的超时，先把测试范围缩到一个入口和一个目标，再临时提高日志详细程度；问题定位后恢复常规日志级别。

先查地址与端口，再查握手字段

确认服务器地址没有前后空格、端口没有抄错，域名可以正常解析。若所有节点来自同一服务方，同时失败可能与账户状态、服务端维护或订阅过期有关；若只有一个节点失败，更应怀疑单节点配置或线路。使用另一条接入网络进行对照有助于区分本地网络路径与远端故障，但每次对照都应保持节点及其他设置不变，否则无法判断究竟是哪项变化起作用。

对带 TLS 的连接，检查服务器名称、证书匹配、传输方式及系统时间。连接地址和用于证书验证的名称可能不同，不能因为连接地址写的是某个域名，就随意覆盖服务器名称。WebSocket 的路径与 Host、gRPC 的服务名称也必须与服务端一致；这些字段不是任意备注。服务提供方没有要求时，保留导入配置，不要把网上示例中的路径或请求头复制进现有节点。

REALITY 与流控需要成套匹配

VLESS 搭配 REALITY 时，还要核对服务端给出的公钥参数、短标识、服务器名称和流控。部分界面会采用不同字段标签，应以客户端实际说明为准，不能把客户端公钥参数当成服务端私钥填写。流控 xtls-rprx-vision 也不是通用加速开关，必须符合当前内核和服务端组合。原理与字段关系可查阅REALITY 与 XTLS Vision 解析。

不要把允许不安全证书验证当成常规修复。该选项会改变身份验证边界，而且对端口错误、REALITY 参数错误或服务端不在线没有帮助。正确做法是修正时间、服务器名称及配置来源，必要时向服务提供方确认入口是否仍有效。若只有旧内核报不支持字段，应先到下载页选择合适的客户端，再检查实际运行的内核，不能只看图形界面已更新就认为内核能力相同。

订阅失败：分清获取、解析与启用

先保留旧节点，检查订阅来源

订阅更新包含三个独立环节：请求订阅地址、解析返回内容、把结果写入对应分组。更新失败时，不要立即清空旧节点。旧节点仍可能可用，可以帮助恢复网络或为订阅请求提供代理出口。先打开订阅分组设置，确认当前更新的是哪一个分组，再查看失败日志。分组名称相似时，很容易把已经过期的地址与正在使用的地址混淆。

重新从服务提供方获取完整订阅地址，检查复制过程中是否截断查询参数、混入换行或附带多余标点。订阅地址通常包含账户授权信息，不应粘贴到公共在线转换工具或公开截图中。若浏览器打开后出现登录页、到期提示或网页错误，而不是客户端可识别的订阅内容，说明请求已经到达网站，但返回内容并不是有效节点清单，单纯重复更新没有作用。

根据状态和内容分别处理

请求超时通常应检查网络路径与域名解析；返回未授权或禁止访问时，应检查订阅权限、地址是否被重置以及账户状态。遇到请求过于频繁的响应，应停止手动连点，等待服务端允许后再试。返回成功状态也不代表内容正确：一些入口会返回网页验证、登录表单或维护页面，客户端随后报告解析失败。判断时必须同时看请求结果和内容类型。

如果日志显示格式无法识别，先确认该订阅提供的是当前客户端支持的格式。普通分享链接集合、编码后的链接内容与其他配置体系并不等价。不要仅凭文件扩展名判断兼容性，也不要手工删除看不懂的字段后覆盖原订阅。优先向提供方索取适用于 v2rayN、v2rayNG 或 v2flyNG 的地址；一次只在一个测试分组导入，验证成功后再决定是否替换原分组。

检查更新请求走直连还是代理

客户端通常提供通过代理更新与不通过代理更新等选项，具体入口依界面而异。若订阅地址直连不可达，可在已有可用节点运行时尝试代理更新；若当前节点已失效，而订阅更新又强制依赖该节点，就会形成恢复路径上的循环。此时应先尝试直连更新、改用仍可用的旧节点，或更换接入网络，而不是持续在失败节点上重试。

更新成功后仍找不到节点，要检查分组筛选、搜索条件、列表排序和导入数量提示。若启用了名称过滤，服务端返回的节点可能全部被排除；若更新策略会替换原内容，原先正在使用的条目也可能已经失效。选择一个新条目设为活动节点，再执行真连接测试。订阅更新成功只证明配置已经取得，不代表所有节点都在线，也不代表系统代理已经自动开启。

如果只有自动更新失败，记录任务执行时的网络状态、活动节点和代理模式，并与手动更新使用的路径比较。电脑启动后网络尚未就绪、设备刚从休眠恢复、节点正在切换，都可能造成一次临时失败。保留失败时间而不是只保留最后一行报错，才能判断是否与网络事件重合。相关设置思路见订阅更新失败与自动更新间隔。

速度慢：区分握手等待与持续传输

先描述慢发生在哪个阶段

“速度慢”至少包含三种不同现象：首次打开网页等待长、页面资源陆续加载慢、持续下载吞吐低。首次等待往往与 DNS、连接建立、TLS 握手或重试有关；持续下载更容易受到线路拥塞、服务器出口、账户限制和本地带宽影响。先用同一网站连续请求两次，再观察大文件传输，不要拿某个节点的单次延迟值推断全部性能。低延迟也可能对应很低的可用吞吐。

测试前暂停其他下载、云同步与系统更新，确认无线信号和本地网络稳定。只保留一个客户端以及一种接管方式，避免多个代理程序相互转发。随后固定节点、测试目标和时间范围，再更换一个变量做对照。使用不同网站进行比较时，目标服务器位置、缓存命中和内容大小都可能变化，因此结果只能说明具体访问路径，不能直接成为节点的统一排名。

比较直连、系统代理与 TUN

如果基础网络本身也慢，先处理本地网络；如果只有代理访问慢，再检查节点与远端线路。系统代理正常而 TUN 慢时，应关注接管范围、DNS 路径、其他虚拟网卡及应用协议差异。TUN 会让更多程序的流量进入客户端，后台更新和同步因此可能参与竞争。不要仅因 TUN 下总流量增加，就认定内核效率下降，先确认测试时有哪些进程正在使用网络。

网页主文档很快但图片或视频卡住，可能是不同资源域名匹配了不同路由。打开浏览器网络面板，观察等待集中在哪些域名，再结合客户端日志查看它们使用的出站。某个资源域名被误判为直连，会造成整页看似缓慢。修改规则时应针对确认存在问题的域名范围，不应为了一个网站直接删除整套路由，否则其他应用的网络行为也会改变。

谨慎处理多路复用、UDP 与 MTU

多路复用并不是任何协议都适用的提速按钮。它可能减少重复建立连接的成本，也可能让多条请求共享某个底层连接的拥塞与故障。是否开启应遵循协议、流控和内核的实际兼容要求。进行对照时只切换这一项，观察相同场景，不要同时修改并发、传输方式和 DNS。若服务提供方没有明确要求，先使用客户端和节点配置的默认行为。

某些应用优先尝试基于 UDP 的传输，而当前接管方式或远端不支持对应路径，应用可能等待失败后再回退，表现为开头卡顿。应检查日志和应用协议，而不是盲目关闭全部 UDP。类似地，只有部分网站卡在加载、且 TUN 或特定接入网络下才出现时，才值得进一步检查路径 MTU。调整前记录原值，按小步测试；随意套用网上的固定数值容易制造新的兼容问题。

最后做跨时段与跨网络验证。如果同一节点在多个目标上持续慢，而更换节点后恢复，向服务提供方反馈具体时段、目标类型和测试条件更有效。如果多个节点只在同一无线网络下慢，则优先检查接入网络和设备。不要为了追求某一次测试结果反复切换节点；持续、可重复的对照才有助于区分短时波动与稳定故障，也能减少不必要的配置变更。

DNS 问题：核对解析者与查询路径

区分系统、浏览器和内核解析

同一台设备上可能同时存在系统解析器、浏览器安全 DNS、客户端内核 DNS 以及 TUN 的 DNS 接管。浏览器能解析某个域名，并不代表内核使用了相同结果；系统命令查询失败，也不必然意味着代理请求一定失败。先明确故障出现在哪个程序、哪种代理模式以及哪个域名，再检查对应解析路径。把所有 DNS 设置同时改成同一个地址，通常只会掩盖路径差异。

日志中的找不到主机、解析超时和连接目标地址失败属于不同阶段。前两者优先检查 DNS 查询，最后一种也可能是已经获得地址但无法建立连接。先通过系统工具查看域名是否返回记录，再用代理请求观察内核能否完成访问。Windows 可使用 nslookup example.com，其他系统可使用已安装的解析工具。系统查询结果只是基线，不代表浏览器或内核实际采用了该答案。

理解路由解析和代理解析的区别

路由的 domainStrategy 控制匹配规则时如何使用域名和 IP，不等于全局 DNS 开关。采用 IPIfNonMatch 时，先尝试域名相关匹配，未命中后才按需要解析并继续匹配 IP 规则。它不会让所有请求都提前解析，也不会保证最终目标一定使用某个 DNS 服务。若日志显示请求进入了错误出站，应同时检查规则顺序、域名条件和解析后的地址类别。

下面是供自定义配置参考的 Xray DNS 对象片段，不是完整客户端配置，也不应覆盖客户端生成的整个文件。它使用明确的查询策略，便于说明字段作用；公共解析器的可达性仍取决于当前网络。使用图形客户端时，优先在 DNS 设置中修改相应选项，然后查看生成配置是否符合预期。若客户端会重建配置，直接修改临时文件通常不能持久保存。

{
  "dns": {
    "servers": [
      "1.1.1.1"
    ],
    "queryStrategy": "UseIPv4"
  }
}

检查 IPv6、缓存与加密 DNS 引导

某些网络会返回 IPv6 地址，但设备到目标的 IPv6 路径不可用，因此出现间歇等待。可以暂时采用只查询 IPv4 的策略做对照，但这只是定位方法，不是所有网络都应长期关闭 IPv6。还要区分 DNS 查询偏好与实际出站拨号策略，它们位于不同层。若修改后仍旧失败，检查缓存是否保留旧答案，并重新建立请求，避免已有连接继续使用之前的地址。

使用加密 DNS 时还要考虑引导过程：解析器自身的域名也需要先解析。若这个解析步骤依赖尚未建立的代理，而代理服务器地址又依赖该解析器，就可能形成循环。检查客户端是否支持独立的引导解析设置，并确认查询究竟走直连还是代理。不要只把一个加密 DNS 地址填入所有输入框；不同输入框可能要求服务器地址、URL、规则或策略，含义并不一致。

TUN 下出现虚拟地址映射时，系统工具看到的地址可能是客户端维护的映射结果，而非目标站点的真实地址。这种情况下，应结合客户端的 DNS 模式判断，不能仅凭地址陌生就认定解析被篡改。反之，应用缓存了映射地址但请求没有进入对应 TUN，也可能访问失败。切换接管方式后，关闭并重新打开测试应用，必要时清理相关缓存，再对照同一域名验证。

系统代理不生效：检查应用是否读取设置

系统代理并不接管全部连接

系统代理是一组供应用读取的网络设置，不是自动重定向所有数据包的规则。浏览器可能遵循系统设置，命令行工具可能只读取环境变量，部分应用则有独立代理入口。因此，浏览器可用而终端失败并不罕见。先用显式代理命令证明本地入口和远端链路可用，再决定应修改应用设置还是启用适合场景的 TUN，避免把应用行为误判为内核故障。

在 v2rayN 中确认系统代理状态不是清除或保持原样，然后打开操作系统的网络代理设置核对结果。Windows 可检查“设置 → 网络和 Internet → 代理”；macOS 检查当前网络服务的代理选项；Linux 桌面环境通常在网络设置中提供代理入口。地址应与本地监听一致，端口应取自客户端实际入站。切换网络适配器后，也应确认当前使用的网络服务应用了正确设置。

逐一排除覆盖与绕过

浏览器代理扩展、自动代理脚本、组织策略以及应用内置代理，都可能覆盖系统设置。先在测试浏览器中暂时停用相关扩展，并检查是否存在单独的代理模式。自动代理脚本会根据地址决定直连或代理，其结果并不等同于全部使用本地端口。若只有个别域名绕过，应检查绕过列表和脚本规则，而不是反复点击客户端的开启按钮。

终端还要检查 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY 与 NO_PROXY 等环境变量。不同工具支持的变量名称与优先级不完全一致，旧变量可能仍指向已经关闭的端口。不要在不了解工具行为时批量写入永久环境变量。临时诊断优先使用命令自己的代理参数，确认可用后再按工具说明配置，并检查是否有绕过本地或特定域名的规则。

下面的 SOCKS 测试同样假设实际 SOCKS 入站为 10808。参数中的 socks5h 表示把目标域名交给代理端处理，有助于与本地解析路径作对照；这不等于系统 DNS 已经修复。若 SOCKS 测试成功而普通访问失败，应回到应用代理设置或本地解析分支继续检查，而不是继续更换远端节点。

curl.exe --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 25 -I https://example.com/

TUN 适用于另一类接管需求

需要让不读取系统代理的应用进入代理链路时，可检查 TUN 是否适合当前平台。TUN 依赖虚拟网络接口、权限和路由设置，与系统代理不是同一个开关。开启后先观察是否创建接口、是否成功写入路由、DNS 是否按预期处理，再测试原先失败的应用。若启动时已经报权限错误，继续修改节点不会解决接管失败；应先按客户端提示完成授权。

同时运行其他虚拟专用网络、虚拟网卡工具或另一套 TUN，可能导致路由争抢。诊断时一次只保留一套接管程序，退出后确认原路由已经恢复。也不要把服务端口绑定到所有网络接口来修复本机访问：本机代理通常使用回环地址即可，扩大监听范围会改变网络暴露边界。若确实需要局域网共享，应单独配置访问控制和防火墙，而不是混入本次本机排错。

客户端崩溃：区分界面、内核与系统环境

先判断退出的是哪个进程

窗口仍在但无法连接，可能只是内核启动失败；整个窗口消失，才需要进一步检查界面进程崩溃。先查看客户端日志、系统事件和进程状态，记录退出发生在启动、切换节点、开启 TUN 还是更新订阅时。界面正常不代表内核正常，内核正常也不代表系统代理已生效。按发生阶段分类，比直接删除整个程序目录更容易保留诊断线索。

先正常退出客户端，确认后台没有残留进程，再备份用户配置与订阅分组信息。备份应保存在受控位置，因为其中可能包含完整订阅地址和认证参数。不要公开上传整个数据目录，也不要把备份直接放入网站目录。若准备重装，保留原始副本，在新的配置环境中测试；直接覆盖旧目录可能把新旧文件混合，导致无法判断问题是否来自历史配置。

核对平台、架构与写入权限

从下载页重新确认包类型。Windows 的 v2rayN 桌面版与经典 WPF 版是不同界面入口；macOS 应区分 Apple Silicon 与 Intel；Linux 应同时匹配处理器架构及发行版包格式。错误架构、缺少运行环境或安装不完整都可能导致无法启动。具体依赖以安装程序和系统错误提示为准，不应凭旧教程随意下载来历不明的运行组件。

配置和日志需要能够写入用户数据位置。若程序位于受限目录、只读介质或同步工具反复锁定的位置，可能出现保存失败、配置回退或启动异常。先确认客户端实际使用的数据目录，而不是只检查可执行文件所在目录。不要把所有文件权限开放给所有用户；应修复对应用户目录的访问权限。需要管理员权限的操作与普通配置写入，也应分开判断。

内核启动失败优先看第一条错误

地址已被使用通常表示入站端口被其他进程占用，或前一个实例没有退出。Windows 可用系统资源监视工具检查监听进程，也可通过下面的命令查看示例端口；读取进程信息时注意权限。确认占用者后正常退出冲突程序，或在客户端改用空闲端口，并同步更新系统代理和应用设置。不要结束不认识的系统进程，更不要只改系统代理端口而忘记内核入站。

netstat -ano | findstr :10808

配置解析错误应从日志最早出现的字段或行号查起，后续“连接失败”可能只是连锁结果。手动编辑 JSON 时，检查多余逗号、引号和字段类型；对自动生成配置，应回到对应的图形设置修改来源。GeoIP 或 GeoSite 文件找不到时，检查路径、文件是否存在及客户端是否能读取，再使用客户端提供的更新入口恢复。随意从其他程序复制数据库，可能引入标签或格式差异。

如果问题紧接着自定义规则修改出现，可在测试配置中恢复默认路由，只导入一个已知有效节点。若最小配置运行正常，再逐项恢复原设置。这样能区分配置问题与安装环境问题，也避免每次恢复整个旧目录后重新触发崩溃。涉及内核兼容性时，可阅读Xray-core 与 V2Fly 差异，不要假设两个内核支持完全相同的字段。

安卓专项：检查授权、后台与应用范围

VPN 图标只能证明接管入口存在

v2rayNG 与 v2flyNG 通过安卓的 VPN 服务接管设备流量。首次启动连接时，需要在系统弹窗中明确授权；如果授权被取消，节点导入成功也不能建立接管。状态栏出现 VPN 标识后，还要观察客户端日志和实际请求，它只说明系统建立了相应服务，不证明远端认证、DNS 和路由全部成功。先选定一个节点测试，避免同时启用复杂的按应用规则。

安卓通常只允许同一用户或配置空间中的一项 VPN 服务处于活动状态。另一个代理、使用 VPN 接口的防火墙或过滤工具，可能替换当前连接。先退出其他同类服务，再启动目标客户端。若系统设置启用了始终开启的 VPN 或阻止未使用 VPN 的连接，也应确认它们指向当前客户端；否则在客户端停止或授权失败时，设备可能按系统策略阻断网络。

亮屏正常、锁屏断线先查后台限制

如果只有锁屏后失联，优先检查系统电池管理、后台运行和自动启动限制。允许客户端保持必要的后台活动，并确认系统没有因省电模式停止前台服务。不同设备的设置名称差异很大，应从应用信息页进入电池或后台管理，而不是照搬其他品牌的菜单。调整后进行一次锁屏等待与唤醒复测，记录服务是否仍在、通知是否保留，以及日志是否出现网络重连。

后台限制与远端会话超时也可能同时存在。若客户端服务仍在，唤醒后只有首个请求较慢，可能是在重建连接；若整个服务消失，则更接近系统回收或应用退出。不要为了修复锁屏问题无限增大所有连接超时，也不要把频繁执行全列表测速当成保活方法。应先找到服务退出或连接重建的证据，再调整对应设置，避免增加电量消耗却没有解决原因。

按应用代理与网络切换分别复测

浏览器能用而某个应用不能用时，检查按应用代理名单，以及当前名单表示“只代理所选应用”还是“绕过所选应用”。这两种方向相反，勾选同一应用会产生不同结果。修改后彻底结束并重新打开测试应用，使它重新建立连接。工作资料、分身应用或其他用户空间还可能有独立网络边界，主空间中的 VPN 不一定能按相同方式接管，应以系统权限范围为准。

从无线网络切换到移动网络后出现异常，应先确认新网络自身可用，再停止并重新启动一次客户端连接。网络切换会改变地址、路由和既有会话，旧连接未必能够继续使用。若只在其中一种网络失败，保持节点不变，检查该网络的 DNS、IPv6 与 UDP 路径。若节点域名在新网络下解析不同，也应结合日志判断，而不是直接把移动网络故障归结为客户端版本。

客户端选择以协议需求为准

安卓端通常先使用 v2rayNG；需要 V2Fly 内核配置时再考虑 v2flyNG。两者不是把名称互换就完全等价，订阅中的协议和字段需要对应内核支持。安装包优先按设备处理器架构选择，主流较新设备通常使用 arm64；不确定时查看设备信息，必要时选择通用包。具体入口见安卓下载选项，不要用反复覆盖安装代替配置兼容性检查。

最后用一个节点、一个浏览器、默认路由和稳定网络建立最小测试环境。最小环境正常后，再依次恢复按应用规则、自定义 DNS 和其他选项，每恢复一项就复测。如果仍失败，整理授权状态、网络类型、内核错误与复现步骤，并删除截图中的订阅和认证信息。需要重新核对导入与连接顺序时，回到快速上手教程；涉及术语含义时，再查术语表，避免凭相似名称修改不同层的设置。