从一次失败请求开始，按时间、目标地址、出站标签和底层错误定位故障。本文适合已导入订阅、但连接失败或网页打不开的用户；读完可区分本地监听、节点连接、TLS 握手与 DNS 解析问题，并在图形客户端里逐项验证，避免同时改动多个设置。
先找对日志：客户端与内核分开看
区分“客户端操作失败”和“代理连接失败”。v2rayN 负责管理订阅、生成配置、启动内核与设置系统代理；实际处理连接的可以是 Xray 或 V2Fly 内核。订阅下载超时不等于节点握手失败，内核启动失败也不能靠切换网页来修复。
在 v2rayN 主窗口查看底部日志区域，先确认启动记录中的内核名称、版本和启动时间，再复现一次问题。不同版本的界面可能把日志放在底部页签或独立窗口，入口文字也可能变化。v2rayNG 使用 Xray 内核，v2flyNG 使用 V2Fly 内核，安卓端可从主界面菜单进入日志页面，不能直接照搬桌面端菜单位置。
- 订阅阶段：关注更新订阅的提示，判断地址请求、认证或内容解析是否失败；不要公开完整订阅链接。
- 启动阶段：关注配置读取、协议字段、监听端口及内核退出信息；尚未启动成功时，先不要排查远端网站。
- 访问阶段：关注入站请求、路由选择、远端连接和响应读取；把错误与刚刚访问的目标对应起来。
读懂级别、地址与错误链
先看错误属于哪一层，再看级别。Xray 与 V2Fly 常见日志级别包括 debug、info、warning、error，还可用 none 关闭相关日志输出。访问日志与错误日志并不总是同一个输出渠道；出现 accepted 只表示本地请求被接收，不表示远端页面已成功返回。
| 级别或记录 | 主要用途 | 操作建议 |
|---|---|---|
debug | 查看更细的内部处理过程 | 仅在短时间复现时开启，结束后恢复 |
info | 观察启动和部分运行信息 | 先用它核对内核是否启动、请求是否进入 |
warning | 提示异常或失败事件 | 结合目标地址判断是否影响当前访问 |
error | 记录更严重的错误 | 优先查看配置加载与监听失败 |
| 访问记录 | 显示来源、目标及路由标签 | 用于确认流量入口，不单独作为成功依据 |
下面是便于阅读的格式示意，不是实测结果；版本、内核和配置不同，字段顺序会变化。127.0.0.1:53124 是应用使用的临时来源端口，不能因此把客户端监听端口改成 53124。目标中的 443 是本次请求的目标端口，也不一定是节点服务器端口。
2026/08/14 10:15:30 from 127.0.0.1:53124 accepted tcp:example.com:443 [socks -> proxy]
[Warning] ... failed to process outbound traffic > ... dial tcp 192.0.2.10:443: connect: connection refused错误链通常从外层处理失败逐步补充到底层原因。先找末尾的具体错误，再回看它属于哪个目标、哪个出站。示意中的 192.0.2.10 为文档示例地址，不可作为节点填写。若日志带连接编号，可用同一个编号串起多行；没有编号时按时间和目标地址对应，避免把后台更新请求误当作浏览器请求。
连接被拒与超时：先核对出错地址
看到 connection refused，先检查冒号前的地址。若指向 127.0.0.1:10808，常见原因是应用仍使用旧代理端口，或本地内核没有监听；若指向节点地址和节点端口，则重点检查节点是否可用、订阅中的端口是否改变。10808 只是常见示例，以当前客户端实际监听值为准。
报错：connect: connection refused
原因：连接尝试收到了拒绝响应，可能是目标端口没有服务监听，也可能是网络设备主动拒绝。
解法：先区分本地地址与节点地址；本地问题核对监听与系统代理，节点问题更新订阅并用另一条已知可用节点对照。
报错：i/o timeout
原因：某次连接、读取或写入操作未在期限内完成，仅凭这句话不能断定是 DNS 故障。
解法：读取前面的模块和目标地址，先判断处于拨号还是读取阶段，再用同一节点切换网络进行对照。
报错：bind: address already in use
原因：本地监听地址与端口已被其他进程或另一个客户端实例占用。
解法：退出重复实例；仍冲突时进入「设置」→「参数设置」，查找本地监听端口项，修改后保存，并同步手动配置代理的应用。
Windows 上端口冲突也可能显示“通常每个套接字地址只允许使用一次”一类系统提示，含义与上述监听冲突相近。不要直接结束未知系统进程，也不要在没有检查的情况下连续尝试多个随机端口。
判断：本地监听失败时，先停在启动阶段
若内核未能绑定 10808，切换 VMess、VLESS 或远端 DNS 都不会修复这个监听冲突。先让启动日志不再出现绑定失败，再测试一次请求是否进入日志。
握手失败：分开检查 TLS 与传输参数
握手错误出现在建立连接之后，但不一定已经到达协议认证阶段。TLS 证书验证、传输路径和用户认证属于不同检查点。不要把所有握手错误都解释为“密码错误”，也不要把关闭证书验证当作通用解决办法。
报错：x509: certificate has expired or is not yet valid
原因：证书有效期与本机时间不匹配，可能是设备时钟错误，也可能是服务端证书过期。
解法：先开启系统自动时间并同步，再重试；时间正常仍报错时联系节点提供方处理证书。
报错：remote error: tls: handshake failure
原因：远端拒绝了 TLS 握手，可能涉及服务器名称、TLS 参数或服务端策略。
解法：打开节点编辑窗口，对照原始配置核对 TLS 开关与服务器名称 SNI，再用更新后的订阅复测。
报错：websocket: bad handshake
原因：WebSocket 升级没有得到预期响应，常见于路径、Host 或反向代理入口不一致。
解法：核对传输方式、路径及 Host，保留路径开头的斜杠和原有大小写，不把 SNI 与 Host 默认视为同一个字段。
- 先核对协议：VMess 与 VLESS 是不同协议，不能只修改协议名称就沿用全部参数。
- 再核对传输：WebSocket、gRPC 等传输配置需与服务端一致；gRPC 还应检查服务名称。
- 最后核对安全层：TLS、REALITY 等配置各有对应字段。使用 REALITY 的节点要按提供方信息检查公钥、短 ID 与服务器名称，不套用普通证书故障的处理步骤。
EOF 或 unexpected EOF 只说明连接结束或数据提前中断，不能独立证明认证失败。若日志只有这一句，应保留前后文，再对照传输类型和节点状态；不要反复生成新的用户标识尝试连接。
DNS 超时：区分节点域名与访问域名
同样是解析失败，发生的位置不同，修复方向也不同。节点地址本身是域名时，客户端需要先找到节点的 IP；访问目标是域名时，则可能由本地 DNS、内核 DNS 或远端处理。具体由配置决定，不能看到 DNS 字样就统一改成某个公共地址。
报错：lookup example.com: no such host
原因：解析器没有得到该域名的有效地址，可能是名称拼写错误、记录不存在或当前解析路径返回异常结果。
解法：先确认这是节点域名还是网页域名，再检查拼写和当前网络的解析结果，避免直接修改全部 DNS 规则。
报错：context deadline exceeded
原因：操作超过期限；只有前文明确来自 DNS 模块时，才应优先按解析超时排查。
解法：检查 DNS 请求走直连还是代理，以及该出口能否到达所选解析服务，再只改动对应解析设置。
| 观察到的现象 | 优先检查 | 验证方法 |
|---|---|---|
| 节点域名无法解析 | 节点连接前的解析路径 | 切换网络后重试同一节点，不同时换协议 |
| 只有个别域名打不开 | 对应域名规则及解析结果 | 对比失败域名与正常域名的出站标签 |
| 启用代理后 DNS 才失败 | DNS 出站依赖和路由环路 | 恢复已知可用的 DNS 配置，再逐项启用自定义规则 |
传统 DNS 常使用 UDP 53，DNS over HTTPS 常使用 TCP 443。端口可达并不代表解析内容正确，443 超时也不必然是网页访问故障。尤其要避免“连接节点要先通过代理解析节点域名，而代理又必须先连接该节点”的循环依赖。
按五步复测：一次只改一个变量
把日志变成可重复的操作记录。以下桌面流程以 v2rayN 为例，设置名称可能随版本调整，实际字段以当前界面为准；不需要手工编辑内核配置文件。若使用安卓客户端，保持相同的验证顺序，并检查连接时是否已经获得系统 VPN 授权。
-
记录当前状态
记下客户端和内核版本、选中节点、网络类型及失败时间。打开主窗口日志区域，保存原有错误后清空显示，减少历史记录干扰。
-
检查启动结果
进入「设置」→「参数设置」，核对实际监听端口；如需更详细信息，查找日志级别项，临时切到
info或debug。保存并按界面要求重启内核，先确认没有配置读取或端口绑定错误。 -
固定流量入口
在托盘菜单「系统代理」中选择「自动配置系统代理」，测试期间先关闭 TUN，避免两种入口叠加。系统代理只影响遵循系统代理设置的应用，另行配置代理的应用需单独核对。
-
复现单次请求
使用遵循系统代理的浏览器打开同一个 HTTPS 页面，记录请求时间，并在日志里找对应目标。如果完全没有记录，先检查应用入口和日志级别，不急着判断节点失效。
-
单项调整复测
根据错误链只调整一个项目，例如节点选择、SNI 或 DNS 路径。对比调整前后同一请求；确认恢复后，将详细日志调回原来的级别，保留最终有效配置。
如果访问记录显示请求走了 direct，但你预期它走代理，应检查路由规则和规则顺序，而不是修改节点证书。出站标签可自定义，proxy 与 direct 只是常见名称，最终要以当前生成配置与界面所选路由模式为准。
判断：比较同一请求的阶段变化
修改后从“节点连接超时”变成“TLS 握手失败”，说明失败位置发生了变化，不代表已经修复。继续检查新的最底层原因；只有同一页面能正常加载、相关请求不再持续报错，才算完成本轮验证。
日志排错常见问题
日志没有红字，为什么网页还是打不开？
先确认是否有对应目标的访问记录。没有记录时检查浏览器是否遵循系统代理、代理端口是否一致；有记录时再看出站标签与后续错误。日志级别过高或访问日志未启用，也可能让记录看起来很少。
一直出现 warning，需要把节点全部删掉吗？
不需要。先关闭正在后台请求网络的应用，再复现一个页面，找与该请求同时间的警告。少量失败可能来自已取消的请求或某个不可达目标，不能仅凭警告数量判断所有节点异常。
订阅更新失败，也要按握手报错处理吗？
先区分订阅下载与节点通信。查看「订阅分组」中的更新结果，确认订阅地址仍有效、访问方式符合当前网络条件。若界面提供通过代理更新的选项，只有在已有可用代理连接时再尝试，避免依赖尚未导入的节点。
延迟测试成功，为什么实际访问仍然超时？
延迟测试可能只覆盖连接或特定测试目标，不等于所有网站、DNS 和传输都正常。保持同一节点，用浏览器复现失败页面，对照域名、目标端口和出站标签，再检查真实请求的错误链。
给别人看日志时，应该保留哪些信息？
保留客户端与内核版本、错误时间、协议和传输类型、端口以及完整错误链。替换敏感地址时使用一致的“节点域名”“访问域名”标记，不要把不同目标都涂成同一个名称；订阅链接和用户凭据不要附在截图中。