适合遇到“客户端已启动，但请求失败”的用户。先区分客户端日志、内核错误日志与访问日志，再按本地监听、DNS、远端连接、TLS 和协议认证逐层检查。报错是定位线索，不是最终结论；读到最内层原因，再决定修改哪个字段，通常比反复重装更有效。
一、先区分日志来源，再复现一次请求
v2rayN 是客户端，V2Ray 或 Xray 是实际处理连接的内核。订阅下载失败、界面设置保存失败属于客户端侧事件；监听端口失败、代理握手失败通常来自内核。安卓上的 v2rayNG 使用 Xray 内核，v2flyNG 使用 V2Fly 内核。不同内核与版本的日志措辞可能不同，不能只按整行文本搜索答案。
内核日志又分访问日志和错误日志。访问日志用于观察请求是否进入入站、访问哪个目标、匹配哪个出站；错误日志用于观察启动和连接阶段的异常。出现 accepted 通常只说明请求被入站接受，不代表远端连接成功，也不代表网页内容已经返回。
上面的链路用于划分排查阶段，并非所有连接都严格按同一顺序解析域名。DNS 可能在路由判断时发生，也可能交给远端处理。第一步应当找到失败请求停在哪一层，而不是同时修改 DNS、路由和节点参数。
- 保存当前配置，记下系统时间、所选节点和实际启用的内核。
- 打开客户端提供的日志视图，确认看到的是内核运行输出，而不只是订阅更新消息。
- 暂时停止其他应用的网络请求，访问一个固定目标，只复现一次失败。
- 保留失败前后的连续日志，按时间、目标地址和连接标识关联同一次请求。
二、loglevel 怎么选：日常 warning，排查临时 debug
log.loglevel 控制错误日志的详细程度，不是连接速度设置，也不等同于访问日志开关。日常可用 warning 降低噪声；复现问题时短暂切换到 info 或 debug。问题定位后恢复原级别，避免日志持续增长及暴露更多连接信息。
| 等级 | 记录范围 | 适用情形 |
|---|---|---|
debug | 调试细节及更高严重程度消息 | 短时间复现复杂连接问题 |
info | 一般运行信息、警告和错误 | 观察启动、连接和处理过程 |
warning | 警告与错误 | 日常运行，减少一般信息 |
error | 错误 | 只保留明确失败信息 |
none | 关闭错误日志输出 | 不适合正在定位故障时使用 |
下面是 V2Ray 风格配置中的顶层 log 对象片段，不是一份完整可运行配置。使用图形客户端时，优先通过日志设置调整；客户端生成的配置文件可能在下次启动时被覆盖。输出到文件还是控制台，还取决于日志路径设置与客户端的输出捕获方式。
{
"log": {
"loglevel": "debug"
}
}三、connection refused 与端口占用：先看地址属于哪一端
connection refused 表示连接被主动拒绝，常见于目标端口没有服务监听或防火墙主动拒绝。先读报错中的 IP 和端口：指向 127.0.0.1 时检查本机入口；指向节点服务器时检查远端服务。把这两类情况混在一起，会导致修改了节点却仍然无法连接本地代理。
报错：connect: connection refused
原因：该次 TCP 连接被目标端主动拒绝，不能仅凭这一句认定账号失效。
解法：核对同一行里的目标地址与端口；本机地址检查内核是否启动，远端地址检查节点端口及服务监听状态。
报错：bind: address already in use
原因：内核无法绑定监听地址，通常是该地址和端口已被另一个进程占用。
解法：查出占用进程，关闭重复启动的实例，或修改本地监听端口，并同步修改应用的代理地址。
以下数字仅用于说明常见配置组合，不代表当前版本的固定默认值。某些配置将 HTTP 与 SOCKS 合并到同一混合入口；始终以客户端实际显示的监听项为准。远端使用 443 也不自动证明其服务类型是 TLS。
Windows 可用下面的命令查找这两个本地端口。输出末列是 PID；重点看 TCP 行是否处于 LISTENING 状态。再到任务管理器的“详细信息”页核对进程名称，不要仅凭端口号结束陌生进程。
netstat -ano | findstr ":10808"
netstat -ano | findstr ":10809"- 完全没有监听：先解决内核启动错误，再测试浏览器或终端。
- 监听存在但协议不符：HTTP 代理地址不能随意指向只接受 SOCKS 的端口。
- 端口改成 10810 后：应用仍指向 10808 就会继续失败；系统代理与终端环境变量需要分别核对。
四、timeout 与 DNS 报错：从最内层原因判断
i/o timeout 说明某次读写超过了等待时间，context deadline exceeded 说明操作超过了截止时间。它们都不直接说明“节点已失效”。DNS 查询、TCP 建连、TLS 握手或等待响应，都可能超时。应当沿着错误链找到最具体的子错误，确认超时发生在哪个地址、哪个阶段。
报错：dial tcp ...: i/o timeout
原因：若上下文明确是 TCP 拨号阶段，表示连接未在期限内建立，可能涉及路由、丢包、过滤或远端不可达。
解法：核对远端地址与端口，分别测试当前网络和另一条可用网络，避免只增加等待时间掩盖问题。
报错：no such host
原因：域名解析未得到可用结果，可能是域名拼写、记录缺失或解析链路异常。
解法：先核对报错域名是节点地址还是访问目标，再检查相应解析器与域名记录。
报错：failed to find an available destination
原因：这是出站选择或连接失败的上层概括，单凭这一句不能断定为 DNS 故障。
解法：继续读取后续嵌套原因；出现解析错误查 DNS，出现拨号超时查远端可达性，出现拒绝连接查监听服务。
例如浏览器访问失败，而日志里只出现节点域名的解析错误，此时还没有建立到节点的连接，不应先修改目标网站的分流规则。反过来，若节点已经连通，只有某个目标域名失败，就应检查该目标的解析及路由结果。
- 确认节点的
address是域名还是 IP，端口是否与服务端一致。 - 对域名运行系统查询，初步确认本机解析是否正常；Windows 可用
nslookup后接实际节点域名。 - 系统查询成功不代表内核 DNS 一定成功。继续检查
dns.servers、解析器可达性及相关路由。 - 一次只更换一个变量，记录更改前后的报错，避免无法判断究竟是哪项设置起效。
五、TLS 握手失败：核对时间、证书名与传输参数
TCP 建连成功只代表远端端口可以连接。TLS 随后仍可能因为证书、服务器名称或协议协商失败而中断。检查 streamSettings.security 与服务端要求是否一致；使用常规 TLS 时，再检查 tlsSettings.serverName。服务器地址与证书名称可以不同，但必须符合服务端部署方式。
报错：x509: certificate has expired or is not yet valid
原因：系统时间不正确，或服务端证书不在有效期内。
解法：先校准系统日期、时间与时区；时间正常时由服务端维护者检查证书续期和实际部署状态。
报错：x509: certificate signed by unknown authority
原因：客户端无法把证书链验证到受信任的根证书，可能涉及服务端证书链缺失或本机信任环境。
解法：检查完整证书链和系统证书环境，不要把跳过验证设为日常解决办法。
报错：remote error: tls: handshake failure
原因：远端拒绝了 TLS 握手；这一句没有给出唯一原因。
解法：对照服务端核查 SNI、TLS 配置与端口，必要时结合服务端同一时刻的日志判断。
TLS 成功后仍可能发生传输或认证错误。WebSocket 的 path、请求 Host，以及 gRPC 的 serviceName 都需要与服务端对应。websocket: bad handshake 常见于路径、Host、反向代理转发或传输类型不匹配，不能简单归为证书问题。
六、从日志定位到配置字段：按失败阶段修改
字段应该跟着故障阶段走。启动时就报监听失败，先看入站；远端连接失败，先看出站地址；请求走错线路，再看路由标签。下面的对应关系以常见 V2Ray 风格 JSON 为例，具体结构需以所用内核和客户端生成的配置为准。
| 观察到的现象 | 优先检查字段 | 核对重点 |
|---|---|---|
| 启动时报绑定失败 | inbounds[].listen、inbounds[].port | 地址是否属于本机，端口是否占用 |
| 应用连接本地入口失败 | inbounds[].protocol | 应用所用 HTTP 或 SOCKS 是否对应 |
| 远端拒绝连接或拨号超时 | outbounds[].settings 中的地址和端口 | 节点信息、远端监听、网络路径 |
| 域名解析失败 | dns.servers 与相关解析策略 | 域名记录、解析器可达性、解析流量路径 |
| 证书名或 TLS 握手异常 | streamSettings、tlsSettings.serverName | 安全类型、SNI、证书与系统时间 |
| 请求进入了错误出站 | routing.rules[].outboundTag、outbounds[].tag | 规则顺序和标签是否正确对应 |
VMess、VLESS、Trojan、Shadowsocks 的认证字段并不相同。只有走到协议认证阶段后，才应核对 UUID、密码或加密方法；不要把所有错误都归结为“密码不对”。反复出现 EOF 也只表示读取时连接结束，需要结合它发生在握手之前还是数据传输之后判断。
- 改前：备份配置，保留报错原文和触发时间。
- 修改：只改与当前失败阶段直接相关的一项；订阅管理的节点还要注意更新可能覆盖手动修改。
- 验证：重启内核使配置生效，用同一应用、同一目标复测。
- 收尾：确认访问恢复后降低日志级别，并清理不再需要的诊断文件。
七、日志排查常见问答
日志空白，是不是请求根本没进代理？
先确认内核正在运行、错误日志级别不是 none，且当前视图确实显示内核输出。错误日志在没有异常时也可能没有新内容。需要确认请求入口时，临时查看访问日志，并核对应用代理地址与实际监听端口。
浏览器能打开，终端却一直报连接失败？
终端不一定读取系统代理。检查当前终端的代理环境变量是否指向正在监听的地址，并核对协议。例如只有在 10809 确实为 HTTP 入口时，才使用 http://127.0.0.1:10809。日志中没有对应请求时，应先排查应用到本地入口这段路径。
v2rayNG 息屏后断流，日志里没有 TLS 错误怎么办？
先检查安卓 VPN 连接是否仍在、客户端进程是否被停止，再查看该应用的电池使用与后台运行权限。若内核已被系统结束，日志可能直接中断；这与远端证书故障不同。调整后台限制后，锁屏复测并记录停止时间。
把 debug 日志发给别人之前，需要删掉什么？
移除订阅地址、UUID、密码、访问令牌，以及不希望公开的服务器地址、访问域名和个人路径。保留内核类型、错误关键词、端口用途与前后文顺序；地址可统一替换为“节点地址”或“目标地址”，不要只留一张截断的末行截图。