适合处理 v2rayN、v2rayNG 与 v2flyNG 连接失败、网页打不开或订阅节点突然不可用的问题。读完可区分访问日志与错误日志，理解常见英文报错，并用端口、DNS、时间、协议参数和服务端状态逐层缩小故障范围。
先确认日志记录了哪一段连接
先定位连接阶段
一次代理请求不是客户端直接把网页交给远端节点。以 v2rayN 常见的本地 SOCKS 端口 127.0.0.1:10808 为例，浏览器或其他应用先连接本地入站，内核再解析节点域名、建立 TCP 或 UDP 连接、完成 TLS 或 REALITY 握手，最后执行 VMess、VLESS 等协议认证。任何一段失败，都可能在界面里显示为“连接失败”。
因此不要只截取日志末尾的一个单词。先找到点击“测试延迟”、打开网页或启动配置时对应的时间点，再向上读取 10 至 30 行。重复出现的 retry、failed to process outbound traffic 往往只是上层汇总，真正原因通常位于其前面的 dial、lookup、handshake 或 authentication 行。
访问日志用于确认请求是否进入内核，常见内容包括目标域名、目标端口、入站标签和选中的出站标签。错误日志用于说明连接在哪一步中断。若访问日志完全没有新增记录，应先检查系统代理、TUN 或应用自身代理设置；若访问日志出现了目标地址，而错误日志随后报告拨号失败，则把重点放到节点地址、端口和网络路径。
设置日志级别并保留有效上下文
日志级别通常分为 debug、info、warning、error 和 none。日常运行使用 warning 或 error 可以减少输出；定位连接问题时先切到 info，仍无法确认握手参数或路由命中情况时再临时使用 debug。完成排查后应恢复原级别，避免日志文件持续增长。
以 v2rayN 7.x 为例，先通过「设置」→「参数设置」→「Core 类型」确认当前节点调用的是 Xray 内核还是 V2Fly 内核，再在主界面的日志区域观察重启内核后的输出。切换日志级别或 Core 类型后，需要停止并重新启动当前配置，旧进程不会自动采用新参数。
固定测试时间
清空或记住当前日志末尾时间，在 10 秒内只执行一次“测试真连接延迟”或打开一次测试页面。
确认内核类型
在 v2rayN 7.x 打开「设置」→「参数设置」→「Core 类型」，核对节点实际使用的内核，避免读取错误进程的日志。
提高日志级别
先使用
info复现一次；只有在看不到路由、握手或 DNS 细节时才改为debug。重新启动内核
停止当前服务后重新启动，确认新日志中出现监听
127.0.0.1:10808或实际配置端口的信息。保存完整片段
保留错误前后各 10 至 30 行，并同时记录节点协议、传输方式、端口和复现动作。
如果需要直接检查生成的核心配置，可以关注顶层 log 对象。下面示例将错误与访问记录写到标准输出，具体文件位置由客户端接管；手动改动客户端生成的临时配置可能在下次启动时被覆盖，因此应优先使用客户端设置。
{
"log": {
"access": "",
"error": "",
"loglevel": "info"
}
}安卓端的 v2rayNG 1.10.x 与 v2flyNG 操作思路相同：启动目标配置后，从主界面菜单进入日志查看页，再立即复现问题。系统可能限制后台进程，若日志在切换应用后停止更新，应保持客户端位于前台完成一次测试，不要把“没有新日志”直接判断为节点正常。
按错误原文定位网络与端口问题
connection refused 表示 TCP 连接已经到达某个地址，但目标端口主动拒绝连接。它与单纯超时不同：拒绝通常很快返回，常见原因是服务端进程没有监听该端口、端口填错、域名解析到了错误主机，或本地入站端口被错误地当成远端端口使用。
context deadline exceeded 表示操作超过截止时间，可能发生在 DNS 查询、TCP 建连、TLS 握手或远端响应阶段。仅凭这一句无法认定节点失效，应查看它前面是否带有具体目标，例如 dial tcp、lookup 或 TLS handshake。
报错:connect: connection refused
原因与解法:目标主机明确拒绝指定 TCP 端口——核对订阅中的服务器地址和端口，用另一个网络复测；若所有网络都立即拒绝，联系节点提供方确认服务端监听状态。
报错:context deadline exceeded
原因与解法:解析、拨号或握手在期限内未完成——先看前一行确定超时阶段，再分别测试 DNS、切换网络并核对传输与安全参数。
报错:failed to find an available destination
原因与解法:内核未能得到可用目标地址或所有候选地址均连接失败——检查节点域名拼写、DNS 返回结果与路由规则，修改后重启内核。
报错:address already in use
原因与解法:本地监听端口已被其他进程占用——关闭重复运行的客户端进程，或在「设置」→「参数设置」中把本地 SOCKS 端口从 10808 改为未占用端口并同步应用代理设置。
报错:no such host
原因与解法:节点域名解析失败——检查域名是否多出空格或字符，切换可用 DNS 后重新解析；不要把订阅备注当成服务器地址。
判断超时位置时可比较耗时。局域网内端口冲突通常在启动后 1 秒内出现；远端端口拒绝也常在几百毫秒至数秒内返回；连续等待约 10 秒后才出现 deadline exceeded，更像网络路径丢包、防火墙静默丢弃或握手阶段无响应。这个时间差不能单独定论，但能帮助安排排查顺序。
| 日志特征 | 优先检查 | 建议动作 |
|---|---|---|
| 启动即报错 | 本地监听端口 | 检查 10808、10809 是否被占用，关闭重复进程 |
| 数百毫秒后拒绝 | 远端地址与端口 | 核对订阅参数，换网络复测同一节点 |
| 约 10 秒后超时 | DNS 与网络路径 | 检查解析结果、网络连通性和远端状态 |
| 只有域名失败 | DNS 与域名路由 | 对比 IP 目标，检查 DNS 出站和分流规则 |
处理 invalid user 与握手认证错误
invalid user、invalid account 或认证失败类信息，通常说明网络连接已经到达协议处理阶段，但客户端提交的身份信息与服务端配置不匹配。VMess 重点核对 UUID、服务端时间和节点是否已经停用；VLESS 重点核对 UUID、加密字段、Flow 与安全方式。复制节点时多一个空格，也可能让认证参数失效。
VMess 对系统时间较敏感。桌面或安卓设备时间偏差过大时，即使地址和端口正确，也可能无法完成认证。先开启系统自动日期、自动时间与自动时区，再重新启动客户端。不要仅在界面里手动把分钟调到接近值，时区和秒级偏差同样需要校正。
报错:invalid user
原因与解法:UUID 或账号状态与服务端不一致——重新更新订阅，不要手工补写缺失字符；若只有一个节点报错，确认该节点账号是否仍有效。
报错:invalid account
原因与解法:协议账号参数未通过校验——对照订阅原始内容核对 UUID、VMess alterId 或 VLESS Flow，并删除旧节点后重新导入。
报错:TLS handshake timeout
原因与解法:TCP 已连接但 TLS 握手未按时完成——核对服务器名称、系统时间和网络质量，切换网络后再次测试。
报错:bad certificate
原因与解法:证书校验与目标名称不匹配或证书状态异常——检查 TLS 服务器名称是否来自订阅，避免用节点 IP 替代要求的域名。
报错:rejected proxy request
原因与解法:服务端拒绝协议请求——核对 VMess、VLESS 类型及传输、安全、Flow 参数，确认客户端没有套用其他节点的旧配置。
使用 WebSocket、gRPC 或 REALITY 时，认证参数之外还要核对传输层。WebSocket 常见错误包括路径不一致、Host 不匹配和返回 HTTP 404；gRPC 需要核对 serviceName；REALITY 需要核对 serverName、公钥、shortId 与指纹。地址能连通只证明 TCP 路径存在，不代表这些字段正确。
- VMess：检查 UUID、alterId、加密方式、系统时间、传输类型与 TLS 设置。
- VLESS：检查 UUID、Flow、传输类型、安全方式以及服务端名称。
- WebSocket：检查 path 与 Host，路径中的斜杠和大小写应与服务端一致。
- gRPC：检查 serviceName，避免把节点备注或域名填入该字段。
- REALITY：检查 serverName、公钥、shortId、指纹与 Flow 的组合，不要单独修改其中一个字段后直接复用。
区分节点故障、订阅问题与路由分流
同一订阅中的所有节点同时失败，优先检查本地环境、订阅更新结果、DNS 和系统时间；只有单个节点失败，更可能是该节点地址、端口或账号状态变化。若节点测试可用但特定网站打不开，应把重点转向路由规则、DNS 分流与目标站点连接，而不是反复重新导入订阅。
路由问题的典型特征是日志中已经出现目标域名，但选中了不符合预期的出站标签。例如应走代理的域名被送到 direct，或局域网地址被送往代理出站。修改规则后必须重新载入配置，并再次观察同一目标对应的出站标签，不能只看客户端状态图标。
| 现象 | 判断方向 | 下一步 |
|---|---|---|
| 全部节点都无法启动 | 本地端口或内核 | 检查重复进程、Core 类型与配置生成错误 |
| 全部节点均拨号超时 | 当前网络或 DNS | 切换网络，检查节点域名是否能解析 |
| 仅一个节点 invalid user | 节点账号参数 | 更新订阅并核对 UUID、Flow 与账号状态 |
| 延迟测试成功但网页失败 | 系统代理或路由 | 检查应用代理、系统代理与出站标签 |
| 只有 UDP 应用异常 | UDP 转发与网络限制 | 确认入站启用 UDP，并检查节点协议支持情况 |
订阅更新成功只表示客户端拿到了订阅响应，不代表订阅里的每个节点都可连接。更新后应查看节点数量、更新时间和关键字段是否变化。如果更新后列表为空，先检查订阅分组筛选条件；如果仍保留旧节点，则确认客户端是否更新了正确的订阅分组。
用一组固定顺序完成最终排查
高效排错依赖顺序，而不是不断尝试随机设置。先确认内核是否成功监听本地端口，再确认请求进入入站，然后检查 DNS、远端拨号、传输握手和协议认证。只有前一阶段通过，下一阶段的日志才有分析价值。
例如日志先出现 accepted tcp:example.com:443，随后出现节点地址的 connection refused，说明应用到本地入站的链路已经正常，不必继续调整系统代理。此时应集中核对远端节点端口。反过来，如果点击网页后日志完全没有新增访问记录，就应先检查浏览器或系统是否实际指向 127.0.0.1:10808。
检查监听
启动客户端后确认日志没有
address already in use，并看到本地入站端口成功监听。检查请求
打开固定测试页面，确认访问日志出现目标域名与
443端口；没有记录就检查系统代理或应用代理。检查解析
搜索
lookup、no such host和节点域名，确认 DNS 返回了可用地址。检查拨号
根据 refused、timeout 或 unreachable 区分端口拒绝、链路超时与网络不可达。
检查握手
核对 TLS、REALITY、WebSocket 或 gRPC 参数，再检查 VMess、VLESS 认证字段。
恢复级别
问题定位完成后把
debug恢复为warning或原设置，并重新启动内核。
日志最后一行就是根因吗?
不一定。向上查看 10 至 30 行，优先找最早出现的 lookup、dial、handshake 或 authentication 错误，末尾常只是重试失败的汇总。
为什么延迟有数字但网页打不开?
延迟结果只说明某种测试得到响应。检查系统代理是否开启，再看访问日志是否出现目标域名，以及路由是否选中了正确出站。
更新订阅后还是 invalid user?
删除该订阅分组中的旧节点后重新更新，确认节点 UUID 与 Flow 已变化；若只有单节点持续报错，应确认账号状态。
切换网络后恢复说明什么?
说明客户端配置具备可用可能，原网络的 DNS、端口策略或链路质量更值得检查。回到原网络后用同一节点复测并对比日志阶段。
debug 日志需要一直开启吗?
不需要。只在复现问题时临时开启，保存有效片段后恢复 warning 或原级别，减少磁盘写入和无关输出。
向他人提供排查信息时，应包含客户端名称与版本系列、内核类型、节点协议、传输方式、错误发生时间和完整日志片段。账号凭据、订阅地址、UUID、公钥之外的私密连接信息应先做必要遮盖，但不要删掉错误前后的阶段标记、目标端口和出站标签。