本文适合已经导入订阅、但遇到节点超时、网页打不开或连接不稳定的用户。先分清客户端日志与内核日志，再沿着请求时间、目标地址、出站标签和最终错误逐层查找，就能判断问题更接近系统代理、本地端口、DNS、节点参数还是远端服务器。
先分清客户端日志、access 与 error
排查前先确认正在看的日志属于哪一层。v2rayN 和 v2rayNG 是负责管理订阅、节点、系统代理与内核进程的客户端；Xray 或 v2fly 内核负责实际接收连接、执行路由并建立出站。客户端界面提示“启动成功”，只说明内核进程已经被拉起，不等于某个节点一定能够连接。
access 记录请求经过了哪个入站、访问了什么目标，以及最后选择了哪个出站。它适合回答“请求有没有进入内核”“域名被哪条规则处理”这类问题。看到一条 access 记录，通常代表浏览器或应用已经把流量送到了本地代理端口。
error 更接近故障原因，常见内容包括域名解析失败、连接超时、端口占用、协议握手失败和远端主动断开。日志级别通常有 debug、info、warning 与 error。日常使用保持 info 即可；需要复现疑难问题时再临时切到 debug，因为 debug 会快速产生大量记录。
| 日志来源 | 主要内容 | 优先检查的问题 |
|---|---|---|
| 客户端日志 | 配置生成、内核启动、订阅更新、系统代理切换 | 内核文件、配置格式、进程状态与订阅地址 |
| access 日志 | 请求目标、入站标签、路由结果与出站标签 | 应用是否进入代理、分流规则是否符合预期 |
| error 日志 | 连接、解析、握手、传输与监听失败 | 本地端口、DNS、节点参数、网络和远端状态 |
在 v2rayN 与 v2rayNG 中取得有效日志
日志只有和一次明确操作对应起来才有价值。开始前先停止连续测速、自动更新订阅和后台下载，避免几十个并发请求混在一起。然后选择一个节点，打开日志窗口，只复现一次问题。例如只访问一个确定可用的 HTTPS 页面，或只执行一次真实连接测试。
以 v2rayN 7.x 为例，可先在主界面确认当前活动服务器，再进入「设置」→「参数设置」→「Core 类型」，检查所选内核与当前配置相符。随后回到主界面的日志区域观察启动信息。如果要提高记录粒度，可在参数设置中找到日志级别，将 info 临时改为 debug，保存后重启内核。
-
确认活动节点
在 v2rayN 主列表中查看当前活动服务器，记录地址、端口和协议。常见远端端口包括 443、8443 与服务提供方指定的其他端口，不能用本地监听端口替代。
-
重启内核
保存设置后执行一次「重启服务」。先确认日志出现配置载入和本地监听成功，再进行网页访问，避免把旧进程留下的记录当作本次结果。
-
单次复现
打开一个网页或运行一次连接测试，等待 10 至 15 秒后停止操作。若同时测试 20 个节点，会生成多组 timeout，难以确认哪一条对应当前节点。
-
复制上下文
从第一条目标请求开始，连同其后 10 至 20 行一起保存。不要只截取最后一行，因为最后的 context canceled 往往只是前一个连接失败后的清理结果。
在 v2rayNG 中，可从侧边菜单进入「日志」查看运行记录。v2rayNG 使用 Xray 内核时，日志会同时包含 Android 侧的启动信息和内核输出。排查时重点找当前节点名称、目标域名、出站标签以及失败发生的时间，不必从第一行开始逐字阅读。
默认本地 SOCKS 端口经常使用 10808，HTTP 端口经常使用 10809，但实际值应以客户端当前设置为准。如果其他应用手动填写了 127.0.0.1:10809，而客户端已经改成 10811，应用请求根本不会进入当前内核，这时 error 日志可能没有任何对应记录。
2026/07/15 14:32:10 [Info] transport/internet/tcp: listening TCP on 127.0.0.1:10808
2026/07/15 14:32:12 from 127.0.0.1:53142 accepted tcp:example.com:443 [socks -> proxy]
2026/07/15 14:32:22 [Warning] app/proxyman/outbound: failed to process outbound traffic
2026/07/15 14:32:22 [Warning] common/retry: all retry attempts failed这组记录说明本地 10808 已经开始监听，来自 53142 临时端口的请求也进入了 SOCKS 入站，并被送往名为 proxy 的出站。问题发生在出站建立连接之后，因此排查重点应转向节点地址、远端端口、网络可达性和协议参数，而不是继续切换浏览器代理设置。
按一条请求的链路阅读日志
一条代理请求通常会经过应用、本地入站、路由判断、代理出站和远端目标几个阶段。日志里的顺序不一定严格逐行对应，因为多个连接可能并发执行，但同一时间窗口内出现的目标域名、连接标识和出站标签仍能帮助还原路径。
第一步看有没有 accepted。如果刷新网页后完全没有新 access 记录，通常是系统代理没有开启、应用不读取系统代理，或应用填写了错误端口。v2rayN 中还要区分“启动内核”和“设置系统代理”：前者只让本地端口开始监听，后者才会把支持系统代理的应用流量指向该端口。
第二步看目标是否正确。日志可能显示 tcp:example.com:443，也可能显示解析后的 IP。端口 443 通常对应 HTTPS，端口 80 通常对应 HTTP。如果访问网页时日志里只有局域网地址或完全无关的域名，应先关闭其他后台应用，再做一次单独复现。
第三步看方括号中的路由结果。例如 [socks -> proxy] 表示请求从 socks 入站进入并交给 proxy 出站；[socks -> direct] 表示规则让它直连。若目标本应代理却进入 direct，应检查当前路由模式、域名规则和规则顺序，而不是修改 VMess 或 VLESS 节点参数。
- 没有 access 记录：检查系统代理状态、本地监听地址以及应用使用的端口。
- 进入 direct 后失败：检查路由分流是否把目标误判为直连。
- 进入 proxy 后 timeout：检查节点地址、远端端口、本地网络与服务器状态。
- 很快出现握手错误：对照订阅中的协议、安全类型、传输方式、Host、路径与 SNI。
- 成功连接后频繁断开：观察是否只有特定网络、特定节点或大流量传输触发。
高频报错的含义与处理顺序
一段 error 日志常包含多层包装信息。外层可能只写 failed to process outbound traffic，真正原因通常位于后面的 caused by、dial、lookup 或 handshake 附近。阅读时从末端具体原因向前回看，比只搜索第一行更有效。
报错:context canceled
原因与解法:当前请求被上层取消，常见于切换节点、重启内核、关闭页面或前序连接失败后的清理。先向上查看同一时间前 5 至 20 行；如果刚执行过重启且之后连接正常，这条记录通常无需单独处理。
报错:i/o timeout
原因与解法:在规定时间内没有完成连接或读写。先确认普通网络可用，再核对节点地址与远端端口，随后换同订阅中的另一个节点测试。多个节点同时超时更应检查本地网络、系统时间和 DNS。
报错:connection refused
原因与解法:目标主机明确拒绝了对应端口的连接，可能是远端服务未监听、端口填写错误，也可能是本地应用连接了未启动的 10808 或 10809。根据日志中的目标 IP 判断拒绝发生在本地还是远端。
报错:failed to find an available destination
原因与解法:内核未能得到可用目标，常与节点域名解析失败或目标配置异常有关。检查服务器地址是否含空格和多余字符，切换可用 DNS 后重启内核，再观察是否出现更具体的 lookup 错误。
报错:rejected
原因与解法:请求被路由规则、协议检查或目标策略拒绝。先查看同一行附近的出站标签与原因；若显示进入 block 出站，应调整路由规则，若伴随 invalid request 或认证信息，则重新从有效订阅导入节点参数。
报错:EOF
原因与解法:连接对端在预期数据完成前关闭了连接。偶发一次可能只是网页取消请求；若每次连接同一节点都立即出现，应核对 VMess 或 VLESS 的传输方式、TLS、安全设置、Host、路径与 SNI。
rejected 不能一律理解为节点失效。例如路由配置把广告域名送入 block 出站时，拒绝正是预期行为。判断它是否属于故障，要同时看目标域名和出站标签。如果只有某个被规则屏蔽的请求 rejected，而主要页面已经正常加载，就不需要改节点。
context canceled 也经常是结果而不是原因。用户在测速未完成时切换节点，旧连接会被取消；客户端重启核心时，正在进行的 DNS 查询和出站连接同样会结束。只有在没有任何手动操作、并且每次请求都被取消时，才需要继续检查进程反复重启、配置自动刷新或网络切换。
从日志缩小到 DNS、端口、参数或远端状态
发现错误后不要同时修改多个设置。一次只验证一个假设，才能知道哪项操作真正有效。建议先确认本地链路，再确认域名解析，然后比较多个节点，最后才逐项检查协议参数。直接删除全部配置重新导入，可能暂时恢复，却会丢失定位线索。
如果日志出现 lookup、no such host 或无法得到目标地址，优先检查 DNS。先确认节点服务器地址没有复制错误，再比较域名节点与 IP 节点的表现。只有域名节点失败而 IP 节点可用时，DNS 线索更明确；所有节点都失败则还要检查本地网络和内核启动状态。
| 观察结果 | 更可能的范围 | 下一步验证 |
|---|---|---|
| 10808 监听失败 | 本地端口被占用 | 退出旧进程或改用未占用端口，重启后确认 listening 记录 |
| 无 access 新记录 | 系统代理或应用代理设置 | 核对应用填写的 127.0.0.1 与实际 HTTP、SOCKS 端口 |
| 多个域名节点均 lookup 失败 | DNS 或当前网络 | 切换稳定网络并重新解析，避免同时改节点协议参数 |
| 只有一个节点持续 timeout | 节点端口或远端服务 | 使用同订阅其他节点对照，确认是否为单节点问题 |
| 所有节点立即握手失败 | 系统时间或参数不匹配 | 同步系统时间，再重新更新订阅并核对传输参数 |
| proxy 成功但特定域名走 direct | 路由分流 | 检查域名规则、规则优先级和当前代理模式 |
端口问题需要区分本地端口与远端端口。本地 10808、10809 用于应用连接客户端；节点的 443、8443 等端口用于内核连接服务器。日志若写着无法监听 127.0.0.1:10808，应处理本机端口占用；若写着连接某个服务器地址的 443 超时，则修改本地 SOCKS 端口通常没有作用。
协议参数问题通常表现为 TCP 已经连上，但握手很快失败。VMess 需要正确的用户标识、传输方式与安全设置；VLESS 需要正确的用户标识、传输层参数以及与服务端一致的 TLS 或其他安全配置。WebSocket 场景还要核对路径与 Host，使用 TLS 时要核对 SNI。最稳妥的处理是更新有效订阅，不要凭猜测补写参数。
几个容易误判的日志问题
日志里出现 warning 不代表所有连接失败。浏览器打开一个页面时会并发请求图片、脚本、统计地址和后台接口，其中某个次要请求超时，主页面仍可能正常。判断影响范围时，要同时观察目标域名、失败次数和实际页面表现。
日志一直刷 timeout，是订阅失效了吗？
先停止批量测速，只选一个节点访问一个页面。若该节点失败，再测试同订阅中的第二个节点。只有多个节点在同一网络下都超时，才继续检查订阅有效性、本地网络、系统时间和 DNS。
出现 context canceled 要换节点吗？
先看出现前是否切换节点、重启服务或关闭测试页面。如果有这些操作，它多半是连接清理信息。若没有手动操作，则向前查找首次出现的 timeout、EOF 或进程退出记录。
内核显示启动成功，网页为什么打不开？
检查刷新网页时是否产生 access 记录。没有记录就核对系统代理与 10808、10809 等实际监听端口；有记录则继续看请求进入 direct、proxy 还是 block 出站。
只有一个网站打不开怎么查？
在清空当前日志后只访问该网站，记录目标域名和出站标签。若它被送入 direct，可临时调整对应域名规则验证；若进入 proxy 后失败，再检查 DNS 结果与目标站连接记录。
v2rayN 能用，v2rayNG 却超时怎么办？
不要直接认定节点故障。先确认两端使用同一条最新订阅和同一个节点，再比较网络环境、系统时间、Xray 内核版本、传输参数与 DNS 设置。不同网络下的结果不能直接互相替代。
另一个常见误区是只看延迟测试。延迟数值能反映一次探测的耗时，但不能完整验证实际代理链路。某节点显示 180 毫秒，不代表它的协议握手、TLS 参数和网页传输一定正常；反过来，某种测试方式超时，也不一定代表真实连接不可用。最终应以实际访问与对应日志为准。
完成排查后，把 debug 日志级别恢复为 info，并保留一份简短结论。例如“本地 10808 正常监听，access 进入 proxy，两个节点均在连接远端 443 后约 10 秒 timeout”。这样的记录比“客户端不能用”更容易在下次出现相似问题时快速对照。