内核启动失败，先区分配置解析失败、本地监听失败与启动后的网络连接失败。本文适合遇到 v2rayN 内核退出、v2rayNG 服务启动异常的用户：从一次启动对应的日志开始，依次检查 JSON、协议字段、监听端口和规则数据文件，最后通过本地监听与实际请求确认修复结果。
一、先分清：内核没启动，还是请求没连通
v2rayN 是客户端界面，Xray、V2Fly 等内核负责读取配置、建立入站监听并执行出站连接。界面能够打开、订阅能够更新，不代表内核已经成功运行。反过来，浏览器打不开网页，也不一定是内核启动失败：远端连接超时、证书验证失败和 DNS 查询异常，都可能发生在内核启动以后。
这条链用于定位错误阶段，不代表所有内核版本的严格内部调用顺序。排查时先找启动失败日志中最深一层的具体原因；如果内核已经保持运行，再出现 connection refused 或 i/o timeout，应结合目标地址判断是本地接入问题还是远端连接问题，不能直接归类为 JSON 错误。
- 配置阶段：出现解析错误、协议无法识别、规则数据读取失败，通常需要先修配置或资源路径。
- 监听阶段：出现
bind、listen tcp等关键词，优先检查本地地址、端口占用和权限。 - 请求阶段：已经有入站接收记录，再出现远端超时，应检查节点、DNS、路由与服务器连通性。
二、收集一次完整启动日志
日志应从点击启动之前开始，到错误出现之后结束。不要只截“启动失败”四个字；上层提示通常只是结果，真正的原因藏在后面的 failed to、文件名或系统错误中。连续重复启动会把多次运行的信息混在一起，先停止服务，再做一次独立复现。
-
记录环境
记录操作系统、客户端版本、当前内核名称及内核版本。v2rayNG 使用 Xray，v2flyNG 使用 V2Fly；v2rayN 应以当前选中的内核为准，不要根据窗口名称推断。
-
打开日志
v2rayN 查看主窗口底部日志区域；若被折叠，先展开日志面板。v2rayNG 从主界面菜单进入「日志」。不同版本的入口位置可能变化，以当前界面标签为准。
-
单次复现
先停止连接，记下当前时间，再启动一次。保留启动前后的连续记录，重点保存第一条失败提示及其完整原因链，不只保留最后一行。
-
备份再改
备份自定义配置和路由规则，每轮只修改一个变量。分享日志前隐去订阅地址、节点凭据、UUID、服务器地址及个人目录名，但保留字段名、错误类型和端口。
如果客户端提示无法创建内核进程，而且完全没有内核输出，应先检查内核可执行文件是否存在、压缩包是否完整解压、系统安全记录是否拦截运行，以及安装包是否匹配处理器架构。这类问题发生在配置解析之前，反复修改节点参数通常没有作用。
三、端口被占用：先查监听进程，再改端口
本地代理需要绑定监听地址与端口。同一地址上的同一 TCP 端口通常不能被两个独立监听器同时占用。重复打开客户端、旧内核残留，或其他程序使用了相同端口，都可能导致新内核立即退出。不要把远端服务器端口和本地入站端口混为一谈。
报错：bind: address already in use
原因：目标监听地址与端口已经被占用。解法：查询占用进程，正常退出重复实例；若确需同时运行，给两个程序设置不同的本地监听端口。
报错：Only one usage of each socket address (protocol/network address/port) is normally permitted.
原因：Windows 拒绝重复绑定套接字地址。解法：从日志读取具体端口，再用监听表找到对应进程，不要直接结束名称不明的系统进程。
以上数字是排查示例，不是所有版本的默认值。假设日志显示 127.0.0.1:10808 绑定失败，在 Windows PowerShell 执行下面的命令，得到占用端口的进程编号后，再查询进程名称。
Get-NetTCPConnection -State Listen -LocalPort 10808 |
Select-Object LocalAddress, LocalPort, OwningProcess
Get-Process -Id (Get-NetTCPConnection -State Listen -LocalPort 10808).OwningProcessLinux 可执行 ss -ltnp 'sport = :10808'，macOS 可执行 lsof -nP -iTCP:10808 -sTCP:LISTEN。没有结果只表示查询时没有匹配的 TCP 监听，并不能排除启动瞬间冲突、UDP 冲突或权限限制；应结合日志中的网络类型判断。
- 发现旧内核进程时，先从所属客户端正常退出，确认端口释放，再启动目标客户端。
- 改为
10818前也要查询是否空闲；修改后同步更新手工配置的浏览器代理、终端代理或其他本地接入项。 - 日志若指向不存在的本机 IP，应修正监听地址。仅供本机访问时，可按实际需求使用
127.0.0.1，不要为了消除报错随意开放所有网络接口。
四、JSON 语法错误：区分“写错格式”和“字段不兼容”
严格 JSON 要求键名与字符串使用英文双引号，数组和对象之间的逗号位置也必须正确。中文引号、末尾多余逗号、复制时缺失括号，都会让配置在读取阶段失败。部分加载入口支持注释等扩展，其他入口未必支持；为减少差异，排查副本先使用严格 JSON。
报错：invalid character '}' looking for beginning of object key string
原因：对象结构不符合解析器要求，常见于最后一个字段后多写逗号。解法：检查错误位置附近以及前一行，删去尾逗号并核对括号配对。
报错：unexpected EOF
原因：输入在对象、数组或字符串尚未结束时提前终止。解法：检查文件是否复制完整、下载是否中断，再补齐缺失结构；不要只在文件末尾盲目追加括号。
下面是用于说明语法的片段，不是可直接运行的完整代理配置。loglevel 后没有多余逗号，外层对象与内层对象分别闭合：
{
"log": {
"loglevel": "warning"
}
}JSON 能通过格式检查，只能证明文本结构合法，不能证明协议名、传输配置和字段类型都正确。某些不受识别的字段还可能被忽略，而不是触发启动错误。因此需要继续使用当前实际内核做配置测试。
.\xray.exe run -test -config .\config.json- 上例适用于提供该命令的 Xray 版本；先运行
.\xray.exe help run核对参数。Linux、macOS 使用对应可执行文件路径。 config.json必须是本地实际存在的配置副本。客户端若自动生成配置，要确认测试对象就是当前节点运行时使用的内容。- 命令行测试与客户端启动可能使用不同的工作目录、环境变量及资源路径。测试通过后仍需回客户端复核。
- 不要把包含节点凭据的完整 JSON 上传到陌生在线格式化服务。优先使用本地编辑器与内核测试功能。
五、未知协议与字段错误：核对实际运行的内核
分享链接、订阅内容和原生配置不是同一种输入。vless:// 或 vmess:// 分享链接需要由客户端解析，不能直接保存成 JSON 配置交给内核读取。订阅中的节点存在于列表里，也不等于当前内核支持其全部传输和安全参数。
报错：unknown outbound protocol
原因：出站协议名称拼写错误，或当前内核不认识该协议。解法：检查 outbounds 内的 protocol，核对内核名称与版本，再修正配置或选用匹配的内核。
报错：json: cannot unmarshal string into Go value of type uint32
原因：某个应为数值的字段被写成字符串；具体目标类型与错误文案随内核实现变化。解法：按日志指出的字段核对类型，例如将数值端口写成 443 而不是 "443"。
VLESS 是协议名称，REALITY 是相关安全配置的一部分，两者不能互相替代为 protocol 的值。传输方式、安全设置、服务端名称与凭据应与服务器要求一致；仅仅把协议名改成一个能够启动的值，并不意味着节点可以连接。
- v2rayN：核对当前节点使用的内核及其启动日志。更换内核后重新生成配置，避免继续测试上一次遗留的配置文件。
- v2rayNG：以随客户端提供的 Xray 能力为准。若新参数无法识别，先确认客户端与内核版本，再判断是否需要更新。
- v2flyNG：以 V2Fly 的配置规范为准。不能默认把针对 Xray 的完整 JSON 原样导入后获得相同行为。
六、geo 文件缺失：检查数据名称、路径与规则引用
路由中的 geosite: 与 geoip: 引用依赖相应数据。配置本身语法正确，但运行环境找不到数据文件，或数据中没有引用的分类，也可能导致规则构建失败。先看错误指向的是“文件打不开”，还是“分类找不到”，两者修复路径不同。
报错：failed to load geosite
原因：域名规则数据无法加载，可能涉及文件缺失、路径错误、文件损坏或分类不存在。解法：继续读取后续原因，核对当前内核实际使用的资源目录和规则分类。
报错：no such file or directory
原因：日志所指路径不存在；只有同时指向 geo 数据文件时，才能判断为这类资源问题。解法：检查完整文件路径、文件名大小写及解压目录结构，按客户端的数据管理方式恢复资源。
- 记录报错中的文件名，例如
geosite.dat、geoip.dat，以及完整路径。不要只凭客户端安装目录猜测资源位置。 - 确认文件可读且不是空文件。Linux 对文件名大小写敏感，目录权限也会影响内核读取。
- 通过客户端提供的数据更新入口恢复适配的数据文件；若界面没有该入口，按该客户端的资源管理方式处理，不要随意混用不同格式。
- 如果文件存在但日志提示分类未找到，检查
geosite:后的分类拼写与当前数据内容。第三方分类名不是所有数据文件都具备。 - 备份后临时移除有问题的单条规则，再测试启动。若能启动，只说明范围缩小到该规则或资源，恢复正式配置前仍需补齐数据与规则。
排查期间删除全部分流规则会改变请求走向，可能把原本应直连的请求交给代理，或把代理请求交给直连出站。定位后应恢复原有路由意图，并检查 outboundTag 是否对应真实存在的出站标签。
七、Android 服务异常与修复后的验证
v2rayNG 在 Android 上使用系统 VPN 接口接入流量。VPN 授权失败与 Xray 配置解析失败属于不同层次：前者检查系统授权、其他 VPN 服务及设备策略，后者仍需回到日志定位 JSON、协议或资源问题。v2flyNG 使用 V2Fly 内核，排查时也要保留这一区分。
- 服务刚启就停：先查启动日志中的第一条错误，再确认系统 VPN 授权是否完成；不要只根据状态栏图标判断原因。
- 其他 VPN 正在运行：先停止冲突的 VPN 服务。Android 同一用户下通常只能由一个活动 VPN 服务接管流量。
- 锁屏后才断开：若启动时正常、后台运行一段时间后被停止，检查系统电池优化和后台限制；这不是典型的配置读取失败。
- 服务运行但无流量：检查应用代理范围、DNS 与路由，以及当前节点是否可达。系统 VPN 接口存在，不代表每个应用的请求都已进入目标出站。
完成修正后，使用同一节点和同一测试条件复核。先确认内核不会立即退出，再确认本地监听或 Android VPN 服务正常，最后才测试网页访问。系统代理、VPN 接入与内核进程分别属于不同环节，任何一个环节单独正常，都不足以证明整条链路可用。
-
重启复核
停止服务后重新启动一次，确认原始错误不再出现；若换成了另一条错误，按新错误所属阶段继续排查。
-
确认接入
桌面端核对实际监听端口与系统代理设置；Android 核对 VPN 服务及应用范围。端口发生变化时，更新所有手工接入设置。
-
发起请求
用浏览器访问已知可用的 HTTPS 页面，同时观察日志是否出现相应请求。若只有远端超时，应转查节点与网络，不再反复修改 JSON 标点。
-
恢复设置
恢复排查时暂时调整的路由和日志级别，保存最终配置副本。记录“错误原文、修改项目、验证结果”，便于下次更新后对照。