V2Ray 运行日志怎么看：常见报错含义与定位方法

先分清日志记录的是哪一步

V2Ray 或 Xray 的一次连接并不是单个动作。应用先把请求交给本地监听端口，内核读取路由规则，再解析目标域名、选择出站、连接远端服务器，随后完成协议认证和传输握手。日志通常只写出失败所在的环节，不会直接给出一整套修复答案。排查时要把报错放回连接流程中，而不是看到一行红字就立即重装客户端。

最实用的读法是从时间接近、属于同一次操作的多行记录一起看。先清空或暂停旧日志，打开一个明确的网址或启动一个明确的应用，然后立即查看新出现的内容。这样可以避免把数小时前的订阅更新错误、后台探测结果和当前连接失败混在一起。

日志级别也要一起看。info 常用于记录正常启动、接收连接和路由结果；warning 表示存在异常条件，但不一定导致全部连接失败；error 才是当前任务明确失败的重点。某条连接报错后，浏览器可能自动重试并成功，因此还要结合网页是否能打开、节点测试是否通过以及错误是否持续重复来判断。

v2rayN 与 v2rayNG 在哪里查看日志

v2rayN：先看内核输出，再看客户端提示

v2rayN 的界面会随版本和布局设置略有差异。一般可以在主窗口下方的日志或信息区域查看运行输出；如果该区域被折叠，可从主界面的查看、日志或相关菜单重新打开。启动节点、更新订阅、测试延迟和切换系统代理时，客户端提示与内核日志可能出现在不同区域，排查连接问题时应优先看带有 Xray、V2Ray、inbound、outbound、transport 等字样的内核运行记录。

如果点击启动后完全没有新增日志，先确认内核进程是否真正启动。配置生成失败、本地监听端口被其他程序占用、文件访问权限异常，都可能使流程停在连接之前。此时反复测速不会得到有效结论，应先解决启动阶段出现的第一条错误。

若日志出现 accepted，并显示来自本机地址的连接，说明浏览器或应用已经把流量交给本地代理。之后才出现的 timeout、rejected 或握手失败，通常应继续检查节点参数、网络路径或远端服务。相反，如果浏览器持续报错，但日志中没有对应的新连接，重点就在系统代理状态、应用是否遵循系统代理，以及本地监听端口是否与应用填写的一致。

v2rayNG：从侧边菜单进入日志页

v2rayNG 通常可从侧边菜单进入日志页面。开始排查前先启动配置，再切回目标应用制造一次连接请求，然后立即返回日志页查看末尾内容。安卓系统后台管理可能让应用暂停或重建网络连接，所以需要同时确认 v2rayNG 的运行状态仍然有效。

v2rayNG 使用 Xray 内核时，协议连接、DNS、路由和传输错误会由内核输出。系统网络切换、虚拟网络接口状态等信息可能与内核记录交错出现。判断时仍然使用相同原则：找到首次失败的时间点，从最早出现的错误向后看，不要只截取最后一行。

若 v2rayNG 日志里能看到本地请求已进入，但每个节点都在相同阶段超时，先切换一次当前网络并重新测试；若只有一个节点失败，而同一订阅中的其他节点正常，则应优先核对该节点自身参数或状态。这个对照比单独盯着一条报错更有效。

rejected：请求在哪一端被拒绝

rejected 的字面意思是请求被拒绝，但拒绝者不一定是远端服务器。它可能来自本地路由规则、目标主机、代理协议认证、传输层握手，或对端主动关闭连接。必须结合这一行前后的模块名和附加信息判断。

如果日志同时出现 blocked、路由规则名称或明确的阻断出站，说明请求可能被本地规则送进了阻断出口。例如自定义规则把某个域名归入拒绝列表，或者规则顺序导致目标在到达代理出站前就被匹配。此时应检查当前路由模式，把目标域名临时设为代理或直连进行对照，而不是更换 UUID。

如果出现 connection refused，通常表示到目标 IP 的网络连接已经得到明确拒绝。常见原因包括远端端口没有监听、服务器服务未启动、端口填写错误，或者中间网络设备明确返回拒绝。它和单纯超时不同：拒绝往往很快返回，超时则通常等待数秒甚至更久。

当 rejected 与 handshake、authentication、invalid user 等信息一起出现时，重点转向节点参数与服务端配置是否一致。逐项比较协议类型、服务器端口、用户标识、传输方式、安全设置、主机名和路径。订阅导入的节点不建议手工猜改某个字段；应先更新订阅，再比较更新前后的配置。

还要注意目标网站自身的拒绝。节点连接和代理通道可能已经正常，但特定目标返回访问限制或主动断开。判断方法是用同一节点访问多个不同站点：如果大部分目标正常，仅一个目标持续失败，就不应把问题直接归到 V2Ray 内核或节点认证。

timeout：先确认超时发生在哪一段

timeout 是最常见也最宽泛的错误。它只说明某个步骤在规定时间内没有完成。DNS 查询、TCP 建连、TLS 握手、WebSocket 连接、读取响应都可能超时。看到 timeout 后，先找同一行或上一层错误中的动词，例如 lookup、dial、connect、handshake、read，这些词能指出等待发生的位置。

连接服务器地址时超时

如果记录指向服务器 IP 和端口，并出现 dial 或 connect，说明本机已经尝试建立外部连接，但没有及时完成。先测试同一订阅里的其他节点，再切换当前网络测试。只有一个节点超时，通常偏向该节点状态或端口问题；所有节点在同一网络超时，但换网络后恢复，则更像当前网络路径问题；所有网络、所有节点都失败，还要回到本地配置和内核启动状态检查。

握手阶段超时

底层连接建立后，协议和传输还需要继续交换数据。若日志明确停在 TLS、WebSocket 或其他传输握手阶段，需核对服务器名称、传输类型、路径、主机字段和安全参数。服务器地址能连通，不代表上层参数一定匹配。时间设置偏差也可能影响依赖证书有效期或时间窗口的连接，因此桌面和安卓设备都应启用准确的系统时间。

读取数据时超时

read timeout 或上下文截止时间到达，可能表示连接已经建立，但后续数据未返回。若只在下载大文件或持续连接时发生，需要观察网络稳定性；若每次打开任意网页都在相同秒数后失败，则继续检查远端服务、传输参数和 DNS 结果。不要只用延迟测试代替真实访问测试，因为延迟探测与完整网页连接可能走不同的请求流程。

排查 timeout 的对照顺序
1. 同一节点，换一个目标网站
2. 同一网络，换一个订阅节点
3. 同一节点，切换当前网络
4. 更新订阅后重新选择节点
5. 对照日志中的 dial、handshake、read 或 DNS 阶段
6. 仅修改一个变量，再进行下一次测试

invalid user：认证信息与服务端不一致

invalid user 通常出现在 VMess 等需要识别用户身份的协议处理过程中，表示服务端无法把收到的认证信息匹配到有效用户。最常见的原因是 UUID 不一致、节点配置已经变更、订阅中的旧节点仍被使用，或者请求实际上到达了错误的服务器端口。

第一步应更新订阅，并确认当前选中的确实是更新后的节点。v2rayN 中可能同时保留旧分组、手工节点和新订阅节点；名称相近并不表示参数相同。v2rayNG 也可能存在重复配置，因此要检查当前运行项，而不是只看订阅更新提示是否成功。

如果节点由手工配置生成，应逐字核对 UUID、协议和端口。UUID 中多一个空格、少一个字符或复制到错误字段，都可能造成认证失败。不要把订阅链接本身填进节点地址，也不要把节点分享内容拆开后凭经验补字段。对于 VLESS，认证和请求解析失败时的具体文字可能不同，但排查重点仍是用户标识、流控、安全层、传输方式及服务端入口是否一致。

若多台设备使用同一份刚更新的配置，只有一台持续出现 invalid user，可以先删除该设备上的旧节点并重新导入订阅，再确认没有选中同名旧项。若所有设备从同一时间开始失败，且配置没有被本地修改，则应由服务提供方检查用户状态和服务端配置。

DNS 解析失败：域名没有转换成可用地址

DNS 负责把域名转换为 IP 地址。日志中的 failed to lookup、no such host、DNS query failed 或解析超时，说明连接可能尚未到达目标服务器。这里要先区分两类域名：一类是节点服务器地址，另一类是用户正在访问的目标域名。前者解析失败会让整个节点无法启动连接，后者失败可能只影响特定网站。

节点服务器使用域名时，如果该域名解析失败，日志通常会在连接远端之前报错。先检查域名拼写和当前网络是否能正常完成 DNS 查询，再更新订阅排除地址已变更。若服务器直接填写 IP，则这一步不涉及服务器域名解析，但目标网站仍然需要 DNS。

只有部分域名失败时，要检查路由规则与 DNS 规则是否配套。例如域名被判定为代理，但 DNS 查询被送往当前网络不可达的解析器；或者自定义规则返回了不适合当前连接的结果。临时切回客户端预设的基础路由和 DNS 配置，可以判断故障是否由自定义项引入。

全部域名解析超时，但直接访问已知 IP 仍有响应，通常应把重点放在 DNS 服务器可达性、系统网络和客户端 DNS 设置。若日志出现循环查询或请求不断重复，还应检查本地监听端口、系统 DNS 与代理 DNS 是否形成了相互转发。修改后需要重新启动内核，让旧连接和缓存退出。

域名能解析并不表示结果一定适合当前链路。若解析到的地址无法连接，日志可能先显示解析成功，随后在 dial 阶段超时。此时错误已经从 DNS 阶段转到网络连接阶段，应按 timeout 的方法继续比较节点、网络和目标地址。

配置、端口与资源文件错误

有些问题发生在内核启动前，网页自然无法产生任何代理连接。日志若出现配置解析失败、未知字段、缺少必要参数或无法加载文件，应先恢复可启动的配置。手工编辑 JSON 时，逗号、括号、字段层级和数据类型都必须符合格式；使用 v2rayN 或 v2rayNG 的订阅导入功能时，则应尽量在界面内完成修改，避免配置文件与客户端生成结果互相覆盖。

address already in use 或类似端口占用信息，表示本地 SOCKS、HTTP 或其他入站端口已被另一个进程监听。常见情况是旧内核没有退出、重复启动客户端，或其他本地服务使用了相同端口。先完全退出当前客户端，再重新启动；仍然报错时，再调整客户端本地端口，并同步更新依赖该端口的应用设置。

路由数据文件加载失败时，依赖 geosite 或 geoip 的规则可能无法工作，严重时会阻止配置启动。此类日志通常明确指出文件不存在、无法读取或规则名称无效。应使用与当前客户端和内核配套的资源文件，并检查自定义规则引用的分类名称是否存在。不要把资源文件错误误判为节点失效。

配置中出现未知字段，也可能是客户端与内核能力不匹配。先使用下载中心提供的当前客户端版本，并让客户端管理对应内核。若从旧配置迁移，建议先导入订阅生成一份基础配置，确认能够连接后，再逐项加入路由或 DNS 自定义内容。

如何区分本地问题、节点问题与服务端问题

单条日志只能指出一个失败现象，定位归属需要对照测试。最稳妥的方法是建立“节点、网络、设备、目标”四个变量，每次只改变一个。这样可以迅速缩小范围，而不会在多个设置同时变化后失去判断依据。

判断本地问题时，重点看内核能否启动、请求能否进入本地入站、路由是否命中预期出口。判断节点问题时，重点看同一客户端中其他节点是否正常。判断服务端问题时，则需要多个设备或网络得到一致结果，并且日志集中指向认证、远端端口或服务处理阶段。

“延迟显示正常但网页打不开”并不矛盾。延迟测试可能只验证某个端口可达或完成一次较短连接，而真实网页还要经过 DNS、路由、协议传输和目标访问。应以实际连接日志为准，继续寻找测试之后出现的握手、读取或目标连接错误。

一套可重复执行的日志排查流程

1. 确认客户端正在运行。查看 v2rayN 或 v2rayNG 的运行状态，确保内核启动后没有立即退出。
2. 更新订阅并选中明确节点。避免继续使用同名旧节点，记录当前节点名称和更新时间。
3. 清理旧日志。只保留一次新测试产生的内容，减少后台请求干扰。
4. 制造单一请求。打开一个确定可访问的站点，不要同时运行测速、订阅更新和大批量下载。
5. 寻找第一条错误。从首次出现 error 或 warning 的位置向上读几行，确认它属于配置、入站、路由、DNS、连接还是认证阶段。
6. 按错误类型处理。rejected 查拒绝来源，timeout 查超时动作，invalid user 查认证信息，DNS 错误查解析对象和解析器。
7. 每次只改一个变量。先换节点，再换网络，或先恢复路由，再重新测试，不要同时改多个字段。
8. 保存有用记录。记录时间、客户端版本、内核类型、错误片段和已做过的对照测试，同时移除认证信息。

日志排查的核心不是记住所有英文报错，而是确认失败发生在连接链路的哪一段。只要能判断请求是否进入本地代理、是否完成 DNS、是否连到服务器、是否通过认证，问题范围就会从“完全连不上”缩小到一个可操作的检查项。

如果当前配置已经经过多次手工修改，最省时间的做法通常是保留必要信息，重新导入订阅，以基础路由完成一次连接，再逐项恢复自定义设置。v2rayN、v2rayNG 与 v2flyNG 都应遵循同样的变量控制方法：先建立可工作的基线，再定位是哪一项改动引入错误。