客户端显示“已连接”，只代表内核已经启动或本地代理端口已经监听，并不等于目标网站、节点服务器和远端出站全部可达。真正有定位价值的信息通常藏在日志末尾：请求从哪个入站进入、匹配了哪条路由、连接哪个地址失败，以及失败发生在域名解析、TCP 建连、TLS 握手还是用户认证阶段。
本文适合正在使用 v2rayN、v2rayNG 或 v2flyNG 排查连接问题的用户。阅读后可以区分访问日志与错误日志，识别常见英文报错的责任环节，并通过端口测试、时间核对、DNS 对照和最小化路由逐步缩小故障范围。
先分清访问日志、错误日志与客户端输出
V2Ray 或 Xray 内核处理一次请求时，会经过本地应用、入站代理、路由匹配、出站协议和远端目标等多个环节。日志类型不同，回答的问题也不同。只盯着一行红色文本，容易把结果当成原因；正确做法是先确认这行日志属于哪一类，再沿着时间相邻的上下文阅读。
| 日志类型 | 主要内容 | 适合回答的问题 | 常见特征 |
|---|---|---|---|
| 访问日志 | 来源、目标地址、端口与选用的出站 | 请求有没有进入内核，路由把它送到哪里 | 常见 accepted、tcp、udp、域名和端口 |
| 错误日志 | 连接、握手、认证、解析和配置异常 | 请求在哪个处理阶段失败 | 常见 failed、rejected、timeout、invalid |
| 客户端输出 | 内核启动、配置生成、订阅更新与端口状态 | 客户端是否成功拉起内核，配置是否能被读取 | 包含核心版本、配置路径、监听端口和退出状态 |
访问日志里出现目标域名，只能证明请求到达了本地内核。随后如果紧跟 failed to dial，问题仍然发生在出站连接。相反，点击网页后完全没有新增访问记录，应先检查系统代理、浏览器代理或分应用规则，而不是立即修改节点参数。
在 v2rayN、v2rayNG 与 v2flyNG 中找到有效日志
排查前先把场景固定下来：选择一个节点，记录当前时间，关闭会持续联网的下载工具，再访问一次固定页面。这样能够减少后台请求造成的噪声。日志等级建议先用 warning 或 info；debug 会产生大量连接细节，更适合常规信息不足时短时开启。
-
确认当前内核
在 v2rayN 7.x 打开「设置」→「参数设置」→「Core 类型」，记录当前配置使用的是 Xray 还是 v2fly。协议能力与报错措辞可能随内核不同而变化。
-
打开信息面板
返回 v2rayN 主窗口查看底部信息区域，先执行一次「重启服务」，确认能看到核心启动、配置加载和本地端口监听记录。
-
复现单次请求
保持日志窗口可见，只访问一次目标页面。若本地 HTTP 端口为 10809，应先确认日志中是否出现发往目标域名的请求。
-
查看安卓日志
在 v2rayNG 1.9.x 或 v2flyNG 主界面连接节点后，打开右上角菜单中的「日志」。先清除旧内容，再回到目标应用复现一次。
-
短时提高等级
warning 没有给出失败链时，再把日志等级调整为 info 或 debug，重启内核后复现。记录完成后恢复原等级，避免日志持续快速增长。
如果客户端界面只显示简化输出，也可以在自定义配置中明确指定日志文件。下面是通用结构示意，路径需要换成当前账户有写入权限的目录。修改后必须重新加载配置，否则仍然查看的是旧进程输出。
{
"log": {
"access": "D:/v2ray-logs/access.log",
"error": "D:/v2ray-logs/error.log",
"loglevel": "warning"
}
}日志文件没有生成时，优先检查目录是否存在、进程是否有写入权限，以及客户端是否覆盖了自定义 log 配置。不要为了获取更多信息一次修改协议、DNS、路由和端口；变量同时变化后，即使恢复连接，也无法判断究竟是哪一步生效。
读懂一条报错的结构：从最后一层向前追
V2Ray 与 Xray 的错误经常由多个模块逐层包装，一条日志里可能连续出现 transport、proxy、common 和 internet 等模块名称，并用大于号串起调用链。阅读时先抓住时间、目标地址和最末端原因，再向前确认它属于哪个协议或传输阶段。
2026/06/02 10:18:42 [Warning] transport/internet/websocket:
failed to dial WebSocket > transport/internet:
failed to dial to (wss://node.example:443/path):
dial tcp 203.0.113.20:443: i/o timeout| 片段 | 可以确定的事实 | 下一步检查 |
|---|---|---|
| 10:18:42 | 错误发生时间 | 与刚才的复现操作对齐，排除后台旧请求 |
| websocket | 正在建立 WebSocket 传输 | 核对传输类型、路径、Host 与 TLS 设置 |
| 203.0.113.20:443 | 域名已经得到地址，并尝试连接 443 端口 | 测试该地址和端口是否能在当前网络建立 TCP 连接 |
| i/o timeout | 规定时间内没有完成网络操作 | 检查节点在线状态、线路丢包、防火墙与网络出口 |
这条示例中已经出现数值地址，因此“本机完全无法解析该节点域名”不是首要方向。末尾是 TCP 连接超时，也尚未进入 VMess 或 VLESS 用户认证。此时反复修改 UUID 通常不会改变结果，应先确认 443 端口能否到达。
如果末尾原因是 connection reset by peer，说明连接建立后被对端或中间设备主动重置；如果是 connection refused，通常表示目标主机可达，但对应端口没有服务监听或被策略明确拒绝。timeout、reset 与 refused 表示的网络状态不同，不能统一归结为“节点失效”。
failed to dial、rejected 与 invalid user 分别查什么
高频报错应按最末端原因分类，而不是只搜索最外层的 failed to process outbound traffic。外层文本往往只是“出站处理失败”的总结，真正决定排查方向的是最后几段。下面列出常见原文与优先操作。
报错：failed to dial WebSocket
原因与解法：WebSocket 传输未能建立。先看末尾是 timeout、refused、TLS 还是 bad handshake，再逐项核对地址、端口、传输路径、Host 和 TLS 开关，不要只改其中一个字段反复尝试。
报错：dial tcp: i/o timeout
原因与解法：TCP 连接在超时时间内没有完成。用另一条网络做一次对照，检查节点端口是否在线；若晚间持续 8 至 15 秒后超时、其他时段正常，还要考虑线路拥塞与丢包。
报错：connect: connection refused
原因与解法：地址通常已经可达，但目标端口明确拒绝连接。核对订阅中的端口是否更新，确认服务端监听端口与客户端一致，并排查端口映射或防火墙规则。
报错：connection reset by peer
原因与解法：现有连接被远端或链路设备重置。先降低变量，关闭额外传输选项并测试同节点基础配置；如果只在特定网络出现，用另一网络对照可快速区分服务端与本地链路问题。
报错：connection rejected
原因与解法：请求被入站、出站或远端策略拒绝。读取 rejected 前后的模块名和目标端口；若同一节点所有目标均被拒绝，检查认证参数，若只有单个域名被拒绝，则检查路由阻断规则。
报错：invalid user
原因与解法：VMess 等认证信息未被服务端接受。重新从订阅更新节点，核对 UUID 是否完整，并把系统时间设为自动同步；VMess 对明显的时间偏差敏感，日期、时区或分钟偏差都要检查。
报错：failed to find an available destination
原因与解法：内核没有得到可用目标地址，常见于域名解析失败或地址列表均不可用。检查节点地址拼写，切换 DNS 后重启内核，并观察日志中是否重新出现 IPv4 或 IPv6 地址。
报错：context deadline exceeded
原因与解法：某个操作超过上下文规定的等待时间。结合前一行判断是 DNS、TCP、TLS 还是订阅请求超时；单独这一句信息不足，必须保留至少前后 10 行。
报错：address already in use
原因与解法：本地监听端口被另一个进程占用。退出重复启动的客户端，或修改 SOCKS、HTTP 入站端口；改端口后还要同步更新系统代理，避免系统继续指向旧的 10808 或 10809。
VLESS 本身不采用 VMess 的时间认证机制，因此看到 invalid user 时，应先确认实际使用的协议和日志所属节点。订阅中可能同时包含 VMess、VLESS 等多种节点，客户端当前选中的条目才是本次日志的上下文。
按请求链逐层定位，避免同时修改全部配置
一条请求从浏览器到远端目标至少经过五层。最有效的办法是从离自己最近的一层开始验证，每次只确认一个事实。上一层没有通过，就暂时不要调整下一层的参数。
- 验证系统代理。打开 v2rayN 后确认系统代理处于预期模式。访问网页时日志完全没有新增记录，说明请求可能没有进入 127.0.0.1 的本地代理端口。
- 验证本地监听。以客户端状态栏显示值为准。常见配置会使用 SOCKS 10808、HTTP 10809，但端口可以被用户修改，不能仅凭教程中的默认值判断。
- 验证路由结果。暂时切换到较简单的全局代理测试。如果全局模式可用而规则模式失败，重点检查域名规则、IP 规则、block 出站与最终匹配顺序。
- 验证节点连接。日志出现目标节点地址后，观察失败是在 DNS、TCP、TLS、WebSocket、gRPC 还是用户认证阶段。
- 验证目标差异。多个常见站点都失败，更像节点或本地链路问题；仅一个域名失败，则优先查看 DNS 结果、路由匹配和目标站点自身状态。
本地端口可以用 curl 做最小请求测试。下面分别通过 HTTP 代理端口 10809 与 SOCKS 端口 10808 请求本站，请以客户端显示的实际端口替换。10 秒上限有助于区分快速拒绝和持续超时。
curl --proxy http://127.0.0.1:10809 https://v2help.com -I --max-time 10
curl --proxy socks5h://127.0.0.1:10808 https://v2help.com -I --max-time 10若命令立即提示无法连接 127.0.0.1，问题在本地监听或端口填写；若本地端口可连接，但约 10 秒后超时，应回到核心日志查看远端连接；若能收到 HTTP 响应头，而浏览器仍打不开，重点检查浏览器代理覆盖、扩展设置或系统代理是否被其他程序改写。
DNS、路由与时间问题在日志中的典型表现
DNS 问题不只表现为“域名不存在”。同一个节点域名可能返回 IPv4 与 IPv6，不同网络对两类地址的可达性也不同。日志反复尝试某个 IPv6 地址并超时，而切换到 IPv4 后恢复，说明解析本身成功，但当前网络到该地址族的路径不可用。
日志写着 no such host，应该先改什么？
先核对节点地址是否带有多余空格或错误字符，再切换客户端 DNS 设置并重启内核。若订阅刚更新，重新选择节点，避免当前运行实例仍引用旧配置。
只有部分网站失败，节点测试却正常？
把路由模式暂时切到全局代理并复测。全局模式可用时，查看访问日志中的 outboundTag，确认失败域名是否误入 direct 或 block 出站。
invalid user 偶尔出现，重连又恢复？
先开启系统自动设置时间与时区，手动触发一次时间同步，再重新连接。随后更新订阅，排除服务端已经更换 VMess 用户信息而本地仍保留旧节点。
订阅更新超时和节点超时是一回事吗？
不是。订阅更新属于客户端获取配置的请求，节点连接属于核心出站。查看日志来源与目标地址；必要时先连接一个可用节点，再在订阅设置中启用通过代理更新。
安卓后台切回应用后才出现大量错误？
先确认 v2rayNG 或 v2flyNG 的连接状态，再检查系统省电策略是否暂停了后台网络。将客户端加入省电白名单后，连续锁屏 10 分钟做一次对照测试。
路由误判通常具有明显的“选择性”：某些域名始终正常，某些域名每次都进入 direct 或 block。访问日志中的出站标签比错误日志更重要。修改规则后要重启或重新加载配置，并确认新请求对应的时间戳已经变化。
时间问题主要影响需要时间校验的认证过程。检查的不只是钟表显示，还包括日期、时区和自动同步状态。即使屏幕上的小时数看起来正确，错误时区配合手动时间仍可能造成实际时间偏差。
整理日志时保留哪些内容，哪些信息需要隐藏
向他人描述问题时，完整环境比单独截取 failed 更有价值。至少写明客户端名称与版本、使用的内核、节点协议、问题出现时间、是否所有节点都失败、当前网络类型，以及执行过哪些对照测试。这样可以避免重复询问，也能判断报错是否来自同一次操作。
- 保留：错误发生时间、日志等级、模块名称、错误链、目标端口、传输类型和本地监听端口。
- 保留：v2rayN 7.x、v2rayNG 1.9.x 等客户端版本范围，以及 Xray 或 v2fly 内核类型。
- 隐藏：完整订阅地址、UUID、密码、认证字符串、节点域名和可识别个人网络的信息。
- 说明：节点地址可替换为 node.example，但端口、协议、TLS 开关和路径是否一致应明确写出。
- 附带：复现步骤与结果，例如“全局模式成功，规则模式失败”或“HTTP 10809 可连接，远端 443 超时”。
日志定位的核心不是记住所有英文，而是识别失败发生在哪一层。没有访问记录先查代理入口；出现 no such host 先查 DNS；出现 timeout、refused 或 reset 先查网络与端口；进入 TLS 或传输握手后再核对对应参数；出现 invalid user 才回到认证信息和时间同步。
完成一次修改后，应使用相同目标、相同节点和相同测试方式重新复现，并比较新旧日志。只有控制变量，才能确认问题真正解决，而不是暂时绕过或被另一个后台请求掩盖。