v2rayN 内核启动排查

先区分内核没启动与节点连不上

v2rayN 是客户端界面，Xray 或 V2Ray 等内核负责读取配置、建立本地监听和处理连接。主窗口能显示服务器列表，不代表内核已成功运行；系统代理开关变为开启，也不代表对应的本地端口已经有人监听。诊断起点应是本次启动日志，而不是浏览器的“无法访问此网站”。

如果日志显示配置读取后立即退出，并出现 Failed to start、failed to load config 或绑定端口失败的文字，优先检查本机配置。如果内核持续运行，本地代理端口已监听，只在访问目标时出现超时、证书错误或连接被拒绝，就应转向节点地址、TLS 与网络链路排查。日志措辞会随内核版本变化，下面使用的是常见错误片段，不要求整行逐字一致。

• 配置加载阶段：关注 config、json、line、offset，此时通常还没建立代理监听。
• 监听创建阶段：关注 listen、bind、本地地址与端口，优先排查端口占用和监听地址。
• 请求处理阶段：关注目标域名、远端端口、timeout、x509，不要先去修改 JSON 标点。

保留本次日志与实际配置路径

先记录 v2rayN「帮助」→「关于」中的客户端版本，再记录启动日志中的内核名称、版本与配置文件路径。桌面版和 WPF 版的部分入口位置不同；本文涉及的参数项以「设置」→「参数设置」为入口，具体分组名称以当前界面为准。不能只凭界面版本推断内核版本，也不能在安装目录里找到一个同名文件就认定它是本次加载的配置。

1. 保存旧日志

   复制当前错误到本地文本，再清空主窗口日志显示区。重新选择当前服务器并设为活动服务器，触发一次内核重启，只保留这一次操作产生的连续日志。

2. 确认内核

   查看启动行中的可执行文件名与版本。若刚修改过内核选择，打开「设置」→「参数设置」中的内核相关项核对；以实际启动输出为准。

3. 定位文件

   记录加载配置的完整路径。普通节点生成的配置与自定义配置处理方式不同；先复制一份正在报错的文件作诊断副本，不直接覆盖客户端的持久设置。

4. 读取末端

   沿同一条错误链从外层提示读到末端原因。例如“配置加载失败”后面的“文件不存在”才是修复目标，不要只截取最前面的失败提示。

普通节点的运行配置可能在重新设为活动服务器、切换路由或重启时重新生成。直接修改生成的 config.json，常会出现“刚修好又恢复”的现象。确认原因后，应回到节点编辑、路由设置或参数设置修正来源；只有明确使用自定义配置时，才维护该自定义文件。

端口占用：先找监听者再改端口

最典型的情况是另一份客户端或残留内核占用了本地监听端口。以下以 Windows 上的 127.0.0.1:10808 为例；这只是排查示例，不表示每个版本都使用该值。请在「设置」→「参数设置」中核对本地监听端口，若当前界面分列 SOCKS、HTTP 或混合端口，逐项检查，不要照抄示例数字。

在 PowerShell 中执行下面的命令，只筛选 TCP 监听连接，避免把远端连接中碰巧出现的同号端口误认为占用。输出的 OwningProcess 是进程编号；先查看进程名称与程序路径，再决定是否关闭。

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

Get-NetTCPConnection -State Listen -LocalPort 10808 |
  ForEach-Object { Get-Process -Id $_.OwningProcess }

如果没有结果，表示查询时没有发现该端口的 TCP 监听，并不自动证明配置完全正确。还要检查日志中的实际地址、是否另有 UDP 冲突，以及是否出现 access permissions 一类系统限制。若将端口改为 10809，需同步更新手动填写代理的浏览器和终端；系统代理由客户端管理时，重新设置系统代理以刷新端口。测试前也要确认备用端口未被占用。

JSON 语法错误：先修结构再看参数

JSON 解析失败通常发生在手写自定义配置、复制片段或编辑路由规则之后。常见问题是对象成员之间漏逗号、字符串使用中文引号、括号没有闭合，以及最后一项后面多出逗号。不同加载器对注释等扩展语法的支持不一致；用于跨版本排错的副本建议先写成严格 JSON。

下面是合法的局部对象，演示数字端口、字符串引号和数组闭合方式，不是可直接启动的完整配置。把规则片段拼进现有文件时，应确认它属于哪个父级字段，不能把两个完整 JSON 对象直接首尾相接。

{
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "udp": true
      }
    }
  ]
}

• 如果日志给出行列号，先检查该位置，再向前检查一行；解析器报告的位置可能只是“发现无法继续”的位置。
• 如果只有字节偏移量，不要把偏移量直接当成中文字符数。使用本地编辑器的 JSON 检查能力定位，避免手工数错。
• 不要把包含服务器地址、用户标识或订阅信息的完整配置提交到在线格式化工具。分享报错时保留结构与字段名，遮去凭据。

未知字段与不支持的配置值

JSON 能解析，只能证明文件结构成立，不代表内核支持其中的每个协议、传输方式或参数。v2rayN 的界面配置、V2Ray 配置和 Xray 配置不是同一种数据文件。把客户端保存的设置文件当作内核配置，或把另一种内核的配置直接导入，都可能造成加载失败或行为异常。

还要注意：未知字段并不总会报错，一些解析路径会忽略未识别的键。没有出现“unknown field”，不能据此判断拼写正确。实际更常见的是某个配置值不受支持，例如 unknown transport protocol，这时需要核对传输方式与实际运行的内核，而不是仅调整 JSON 标点。

• 先查层级：streamSettings 属于相应入站或出站配置对象，不能随意移动到配置根部。
• 再查类型：布尔值 true 与字符串 "true" 不等价；字段要求的对象、数组和数字应按对应内核定义填写。
• 最后查兼容：新字段可能要求较新的内核。更新时保持客户端与所需内核组件完整，不要仅替换来历不明的单个可执行文件。

VMess、VLESS 是协议名称，不能作为“试一试”的修复开关互相替换。服务端协议、传输方式和安全参数有明确对应关系。对于订阅导入的普通节点，优先重新导入有效配置并核对服务端要求；对于自定义配置，保留原文件，逐项比较可疑字段与当前内核支持范围。

geo 文件缺失：检查文件、路径和分类名

路由中使用 geoip:cn 或 geosite:cn 时，使用传统 DAT 数据的配置通常需要对应的 geoip.dat、geosite.dat。错误链可能先写“构建路由规则失败”，末尾才写数据文件打不开或分类不存在。前者属于结果，后者才决定该补文件还是改规则。

1. 从日志抄下完整资源路径，不假定工作目录就是程序目录。自定义启动方式和资源路径设置可能改变查找位置。
2. 文件不存在时，检查客户端资源更新入口和更新日志；必要时从完整客户端包恢复配套组件，再确认文件确实写入目标目录。
3. 文件存在但分类不存在时，核对规则中的分类名及数据来源。并非每份数据文件都包含相同分类，重命名文件不能增加分类内容。
4. 临时停用引用该分类的自定义规则后若能启动，可将故障范围缩小到规则与数据依赖；恢复业务前仍应补齐数据并重新验证分流。

修复后按同一顺序复测

每次只改一个变量，然后重新启动内核并保存新的日志。如果同时换节点、改端口、换内核和删除路由，即使恢复，也无法确定真正原因。对于自定义 Xray 配置，可以使用实际配套的 Xray 可执行文件做加载测试；下面命令应在诊断副本所在目录运行，文件名为 config.json。

.\xray.exe run -test -config .\config.json

该命令针对支持此命令行形式的 Xray；其他内核先查看自身帮助，不要照搬。测试时要使用与客户端相同的资源环境，否则可能因为 geo 文件查找路径不同而产生额外错误。配置测试通过不等于远端连接正常，也不保证实际运行时端口可绑定，仍需回到客户端验证。

• 第一关：配置可加载。日志不再出现解析失败、配置构建失败或数据文件加载失败。
• 第二关：监听已建立。用端口查询确认预期地址、端口和进程对应，且内核没有立即退出。
• 第三关：请求能通过。让应用使用正确的本地代理，再检查连接日志；此时出现的 TLS 或超时问题另行定位。
• 第四关：设置能保留。重新设为活动服务器并重启客户端，确认修复写回了配置来源，而不只是修改了一份临时文件。

内核启动失败常见问答