V2Ray 内核启动排错

先判断失败发生在哪一步

“网页打不开”不等于“内核没启动”。客户端界面能打开，也不代表后台内核已经成功运行。启动阶段需要先读取配置、构建入站与出站，再创建本地监听；只有这些步骤完成，应用请求才有机会进入路由匹配。

• 启动即退出：优先找 Failed to start、failed to load、failed to listen 等片段，检查本地配置和监听条件。
• 启动后有请求日志：通常已经进入运行阶段。此时出现远端超时、证书错误或连接拒绝，应转向节点地址、传输参数和网络连通性。
• 日志完全为空：先确认是否打开了内核日志，而不是仅查看订阅更新日志。还要核对客户端是否实际执行了内核程序，以及日志输出位置是否可写。

v2rayN 是桌面客户端，具体可用字段由当前选用的内核决定。v2rayNG 使用 Xray，v2flyNG 使用 V2Fly；两者配置存在交集，但不能据此认定所有扩展字段都能互换。排错记录应同时包含客户端版本与内核版本，不能只写“最新版”。

保留一次完整启动日志

先停止重复点击连接，备份当前配置，再清空日志显示区域或记下时间。只执行一次启动，保留从内核版本行到退出信息之间的内容。v2rayNG 可从侧栏进入「日志」；v2rayN 应查看主窗口的信息输出区域，具体入口和布局随版本变化，以内核启动信息为准。

自定义 JSON 可临时将 log.loglevel 设为 debug。这只提高日志详细程度，不会修复错误；如果 JSON 根本无法解析，该设置也可能尚未生效，仍需读取进程输出或客户端捕获的标准错误。

{
  "log": {
    "loglevel": "debug"
  }
}

日志里的时间戳和连接编号用于关联同一次操作；带有多个 > 的报错通常是一条逐层包装的错误链。先找到首条与本次启动有关的失败，再读到错误链末端的具体原因。不要只截取最外层的 Failed to start，也不要把此前另一条请求的超时混进来。

JSON 语法错误：先修结构再看字段

JSON 解析失败时，协议、DNS 和路由通常还没有进入有效构建阶段。常见诱因是末尾多余逗号、漏掉双引号、复制时混入中文引号，或者把数字字段写成了字符串。错误位置有时落在问题之后：解析器在读到下一个字符时，才发现前面的结构不完整。

这里引用的是常见错误片段，完整前缀、大小写和字段路径会随内核版本变化。修复时不要只做全局替换：端口字段需要数字，不代表所有包含数字的内容都应去掉引号，UUID、地址和标签仍是字符串。

1. 用支持 JSON 检查的本地编辑器打开实际被读取的文件。
2. 先处理编辑器指出的第一处语法错误，重新检查后再处理下一处。
3. 标准 JSON 不允许尾逗号和注释。即使某些加载器接受扩展语法，排错时也优先采用标准 JSON。
4. 若使用客户端表单生成配置，应返回对应设置项修改；直接编辑临时生成文件，可能在下一次启动时被覆盖。

端口被占用：定位进程而不是盲目提权

入站创建失败常见于两个客户端同时监听同一地址与端口，或者上次启动遗留的进程尚未退出。以下端口是本文演示值，不是对所有客户端默认值的声明。先从日志或当前配置读取实际端口，再替换命令中的数字。

Windows：检查监听 PID

Get-NetTCPConnection -LocalPort 10808 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

在 PowerShell 执行后，用任务管理器「详细信息」中的 PID 对照进程。确认归属再退出程序；不要按端口批量结束未知系统进程。若没有任何监听结果，检查完整日志是否实际报告权限或地址不可用，而非占用。

Linux 与 macOS：查看监听者

# Linux
ss -ltnp 'sport = :10808'

# macOS
lsof -nP -iTCP:10808 -sTCP:LISTEN

普通用户可能看不到其他用户进程的全部信息。必要时只为查询命令提升权限，不要直接将整个客户端长期以高权限运行。若本地端口从 10808 改为 10810，浏览器、系统代理或其他手动配置的应用也要跟随更新。

协议与字段错误：确认实际使用的内核

JSON 格式正确，只说明文件能被解析，不说明内核理解其中的协议。protocol 值需要准确拼写，例如 vmess、vless、socks、freedom。入站和出站的 settings 结构不同，不能把服务端接收用户的字段直接粘到客户端出站中。

• 先核对版本：记录启动日志中的 Xray 或 V2Fly 名称和版本。客户端界面版本与内核版本是两个独立信息。
• 再核对方向：出站配置远端服务器，入站配置本地监听。名称相同的协议，其两侧字段也未必相同。
• 最后核对扩展：传输层、安全层和协议扩展有各自的支持范围；将配置交给另一内核前，要逐项核对，而非只改程序名。

“未知协议”不一定表现为统一的一行错误，可能被包装在入站或出站加载失败中。沿错误链找到具体的 protocol 值，再与实际配置对照。如果某个陌生字段没有报错，也不能推断它已经生效：部分未知 JSON 字段可能被忽略，必须用当前内核文档和行为验证。

路由错误：检查条件与出站标签

路由规则的任务是将已进入内核的连接交给某个出站。routing.rules 按顺序匹配；宽泛规则放在前面，可能遮住后续更具体的规则。这类配置即使能启动，也可能出现“全部直连”或“某个域名走错出口”，需要与导致启动失败的结构问题分开处理。

下面是一份用于隔离测试的完整精简配置：只在本机 127.0.0.1:10808 提供 SOCKS 入站，将 example.com 及其子域名交给阻断出站，其余流量使用第一个直连出站。它不包含远端代理节点，不应替代正式节点配置。

{
  "log": {
    "loglevel": "info"
  },
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": false
      }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "blocked",
      "protocol": "blackhole",
      "settings": {}
    }
  ],
  "routing": {
    "rules": [
      {
        "type": "field",
        "domain": ["domain:example.com"],
        "outboundTag": "blocked"
      }
    ]
  }
}

1. 逐字比较 outboundTag 与 outbounds[].tag，包括大小写。标签不存在时，表现可能随版本和路径不同，不能仅凭启动成功判断正确。
2. 域名和 IP 匹配条件使用数组，单条规则中的不同条件通常需要同时满足；不要把“增加条件”误认为“增加任选项”。
3. 若报错直接指向 geosite.dat 或 geoip.dat，检查当前内核的资源目录、文件可读性以及规则引用的分类是否存在。
4. 隔离资源问题时，可暂用上述明确域名规则代替资源分类；验证通过后再逐条恢复原规则。

修复后分两次验收

第一轮只验证配置能否被内核接受。使用 Xray 命令行时，可在配置所在目录执行下列测试命令；可执行文件必须是客户端实际使用的同一版本。Windows 可将命令开头的 xray 改为 .\xray.exe。

xray run -test -config ./config.json

配置测试成功不等于端口一定能够绑定，也不等于远端服务器能够连接。第二轮必须实际启动客户端，确认没有新的监听错误，再让一个应用通过正确的本地代理端口发起请求。示例配置刻意阻断了 example.com，因此不能用该域名作为“应该访问成功”的验收目标。

可复现的排错记录应包含操作时间、客户端与内核版本、读取的配置路径、第一条失败日志、此次只修改的字段，以及复测结果。一次只改变一个变量，能避免端口修好了却同时引入路由错误。需要进一步理解字段层级时，可对照配置参考逐段检查。