JSON 配置参考

JSON 结构总览

先确认正在阅读哪一种配置，再解释字段。v2rayN 保存的界面设置、订阅内容与内核运行配置不是同一份文件。订阅提供服务器连接参数；客户端结合当前服务器、路由模板和监听设置，生成交给内核的配置。修改生成文件可能只影响本次运行，下一次切换服务器或重启内核就会被覆盖。需要长期保留的设置，应优先回到客户端对应入口修改。

对象、数组与字段类型

JSON 顶层是对象，使用花括号包围。对象内的字段由双引号名称、冒号和值组成，多个字段之间用逗号分隔。数组使用方括号，适合描述多个入站、多个出站或有顺序的规则。字符串、数字与布尔值不能互换：监听端口写数字，开关写 true 或 false，协议名写字符串。最后一个成员后面不加逗号，也不要在严格 JSON 中插入注释。

下面是一份可由常见 V2Ray 与 Xray 内核理解的本地直连基线。它只在回环地址提供 SOCKS 入口，不包含远程代理服务器。应用主动连接该入口后，由本机直接访问目标。示例的作用是分离本地监听问题与远端连接问题，不代表导入后已经建立远程代理链路。

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "socks-in",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    }
  ]
}

顶层配置段的职责

这些段落通过引用协作，而不是按文本出现位置顺序执行。路由中的 outboundTag 指向出站的 tag；策略等级对应协议用户的 level。对象字段的书写顺序通常不改变含义，但数组顺序可能改变行为，尤其是路由规则与默认出站。阅读配置时，应先找引用关系，再看单个值。

完整文件与局部片段

本页后续示例多数是顶层片段，用于替换或合并同名配置段。不要把两个带有 routing 的对象直接首尾拼接，也不要保留两个同名顶层键。部分解析器会接受重复键并采用其中一个值，这种结果不适合依赖。合并时保留一个顶层对象，将目标段落放到正确层级，再检查括号、数组和逗号。

内核之间有共同概念，但不保证所有扩展字段都一致。传输实现、DNS 选项与用户等级支持情况，应以当前实际运行的内核为准。先建立最少字段的可运行配置，再增加单个能力，比一次导入大量来源不同的片段更容易判断差异。客户端升级后也应重新查看生成结果，不能只凭旧截图认定字段没有变化。

记录配置时建议同时保存内核名称、客户端入口和修改目的。敏感的服务器凭据不要放入公开截图或公开文档。遇到错误先区分语法无法解析、字段不受支持和运行连接失败三个层次，后文会按同一顺序展开。这样可以避免把端口占用误判为协议问题，或把规则未命中误判为 JSON 写错。

inbounds：本地入站监听

入站定义应用如何把连接交给内核。桌面环境常见做法是让应用使用本地 SOCKS 或 HTTP 代理，客户端负责启动对应监听。应用配置的地址、端口与协议必须和入站一致。能看到客户端窗口，并不等于内核已经成功监听；判断入口是否存在，应查看启动日志和实际端口占用，而不是只看系统托盘图标。

监听地址与协议选择

listen 是本机绑定地址，不是远端服务器地址。使用 127.0.0.1 时，入口只接受本机回环连接。改成 0.0.0.0 会扩大到 IPv4 网络接口，局域网设备可能访问该端口，因此还需要认证、防火墙与网络边界共同限制。仅仅打开客户端的局域网开关，并不能保证其他设备一定连得上。

{
  "inbounds": [
    {
      "tag": "socks-in",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      },
      "sniffing": {
        "enabled": true,
        "destOverride": ["http", "tls"],
        "routeOnly": true
      }
    },
    {
      "tag": "http-in",
      "listen": "127.0.0.1",
      "port": 10809,
      "protocol": "http",
      "settings": {}
    }
  ]
}

此例中的 routeOnly 按 Xray 配置语义使用：嗅探获得的信息用于路由，不直接替换原始目标。切换到其他内核前，应检查该字段是否被支持。若只需确认本地入口工作，可先移除整个 sniffing 段，保留基础监听；入口稳定后再测试嗅探与域名规则，避免同时引入两类变量。

SOCKS 与 HTTP 是两个不同入口协议。应用只支持 HTTP 代理时，应填写 HTTP 入站端口，不能因为两个端口都在本机就随意互换。SOCKS 入站开启 udp 只表示允许相应的 UDP 转发能力，应用还必须通过支持的方式提交 UDP 流量，远端链路也要具备对应能力。普通 HTTP 代理入口不等价于接管全部 UDP。

域名从哪里进入规则

应用可能把域名交给代理，也可能先在本地解析，再把目标 IP 交给代理。前一种情况可直接使用域名规则；后一种情况需要结合已有目标信息或嗅探结果判断。嗅探读取的是可识别的协议特征，不是通用的内容解密工具。连接没有可用域名特征、握手被其他机制保护，或协议不在覆盖范围时，不能期待它补出准确域名。

destOverride 中的 http 与 tls 是嗅探目标协议类别，不是对出站传输方式的选择。开启嗅探也不会自动开启 TLS，更不会修复服务器证书问题。检查域名分流时，应同时确认应用有没有传递域名、当前入口是否启用嗅探，以及规则实际拿到了域名还是 IP，不能只检查一个开关。

端口冲突与局域网访问

两个进程不能随意占用同一监听地址与端口。客户端启动时报地址已被使用，先退出重复运行的实例，再检查是否有其他程序监听相同端口。改变入站端口后，需要同步修改应用代理与系统代理设置；否则新内核虽然正常运行，应用仍会连接旧端口。保存配置前可先记下旧值，测试失败时按原路径恢复。

需要让局域网设备使用入口时，先确认设备处于可互访的网络，再确认绑定地址、系统防火墙和访问认证。不要直接把 noauth 的本机示例扩大到不受信任的网络。仅允许特定设备访问通常比开放整个接口更稳妥。来自其他设备的连接进入后，也会经过路由规则，所以入口连通与目标可达仍需分开验证。

入站标签适合保持稳定、清晰且唯一。例如为浏览器与测试程序建立不同标签，再用路由的 inboundTag 观察不同入口行为。标签不承担身份认证，也没有预设魔法含义。它只是配置中的引用名称，拼写变化会影响相关规则；排错时应逐字核对，而不是根据名称看起来相似就认为已经关联。

outbounds：出站与协议参数

出站决定内核如何建立下一段连接。直连出站、阻断出站和远程代理出站都属于这一层，但承担不同职责。出站存在不意味着会被使用，还要看路由是否选中它，以及未命中规则时默认落到哪个出站。通常应把预期默认出站放在数组首位，并为需要被规则引用的出站设置唯一标签，避免依赖难以辨认的位置关系。

协议与传输分层

protocol 描述出站使用的代理协议或处理方式。远端地址、端口和用户参数通常在 settings 中，传输与连接安全设置通常在 streamSettings 中。协议、传输和安全层是相互配合的三个维度，不应把某个协议名称当成完整连接方案。两端即使协议一致，传输路径、服务名称或安全参数不一致，仍可能握手失败。

{
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ]
}

这段示例不包含远程服务器，可用于理解出站引用。freedom 由本机建立目标连接，是否解析域名及如何选用地址还受相关配置影响。blackhole 用来丢弃匹配流量，适合明确需要阻断的范围。默认行为下，应用可能表现为连接失败或超时，不应把它解释成目标网站故障。诊断时需要先看连接是否被规则送入阻断出站。

VLESS 字段的对应关系

VLESS 的远端连接参数需要由服务端配置或可信的分享信息提供。vnext 描述服务器列表，其中的 address 与 port 指定连接目标；users 内的 id 标识用户。不要凭示例生成真实连接凭据，也不要把订阅分组名称填成服务器地址。地址、用户参数与传输安全设置必须来自同一套服务端配置。

使用 VLESS 时，encryption 的常见取值 none 属于协议用户配置，不等于整条连接没有传输安全层。TLS 与 REALITY 等连接安全方式在对应内核支持的传输配置中处理，二者参数不能混用。服务器名称、证书验证、公钥与标识参数都有各自语义；不知道某字段含义时，应回查原始分享信息，而不是通过关闭验证绕过报错。

VMess、VLESS 与 Trojan 的认证结构也不同。不要把一个协议的用户对象原样复制到另一个协议下面。最稳妥的流程是先让客户端导入有效分享链接，再查看生成结果，理解每项连接参数落在哪一层。需要比较协议概念时，可查阅术语手册；本页重点是字段位置与引用关系，不给不同场景下的协议作绝对排名。

默认出站与连接验证

如果已配置代理出站，但没有任何规则指向它，且它也不是默认出站，流量就不会自动使用该服务器。反过来，把代理出站放在首位，会让未命中其他规则的连接走代理。调整数组顺序会改变兜底行为，因此每次修改前应先用一句话写清预期：哪些连接明确直连，哪些明确阻断，其余连接交给谁。这句话应能对应到实际数组与规则。

验证远端连接时，先看本机是否能建立到服务器地址与端口的连接，再看传输握手，最后看目标请求。服务器端口可达只说明网络层有响应，不代表认证成功。证书名称错误、传输参数不一致、用户标识无效，都会在后续阶段失败。客户端显示的延迟结果也不能替代完整应用请求，应结合日志中的错误阶段判断。

切换内核后，先检查协议与传输是否均被当前内核支持，再检查生成配置是否仍保留所需选项。不能只因为界面中还显示同一服务器名称，就认定底层参数完全一致。对于自定义出站，保留原始导入信息和可工作的配置副本，有助于区分导入转换问题、内核差异与服务器配置变化。

routing：规则匹配与分流

路由的结论是选择出站，不是修改远端服务器配置。规则按数组顺序检查，通常由第一个匹配规则决定去向；没有匹配时，使用默认出站。设计规则时先放范围窄、意图明确的例外，再放覆盖范围大的规则。若前面已经匹配全部目标，后面的规则即使语法正确也没有机会生效，排错不能只看某条规则是否存在。

域名规则与 IP 规则

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": ["full:example.com"],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

此片段要求配置中存在 block 与 direct 两个出站。full:example.com 只匹配该完整域名，不自动包含全部子域名；需要覆盖域名及其子域名时，应使用相应的 domain: 形式。没有前缀的字符串在常见实现中可能按关键词处理，因此写规则时应明确表达匹配方式，避免误把相似名称包含进来。

geosite:cn 与 geoip:private 引用的是规则数据类别，不是运行时从名称猜测出来的集合。它们依赖内核可读取的对应数据文件及其中存在的条目。数据缺失可能导致启动失败，数据更新也可能改变实际覆盖范围。遇到某个域名分流结果与预期不同，应先用明确域名规则验证，再判断是数据分类还是规则顺序造成差异。

domainStrategy 的作用边界

AsIs 表示路由阶段主要按已有目标信息匹配，不为了 IP 规则主动解析域名。IPIfNonMatch 在域名未匹配规则时尝试解析，再利用结果检查相关规则。IPOnDemand 会在匹配过程遇到需要 IP 信息的条件时触发解析。三者影响的是路由匹配阶段，不是系统 DNS 的总开关，也不保证其他应用的解析请求进入内核。

同一条规则里不同类别的条件通常需要同时满足；同一类别的多个候选值通常表示任一命中即可。例如同一条规则同时写域名与端口，表示该域名在指定端口上的连接，而不是域名命中或端口命中均可。需要表达两种独立情况时，应拆成两条规则。规则越短，越容易从日志与测试结果判断真正命中的条件。

兜底规则与回滚方法

路由模板常见问题是兜底规则放得过早、标签拼错，或者把目标端口误当成入口端口。先用单个测试域名建立最小规则，确认能被送往指定出站，再扩展到数据类别与多个条件。每次只改一个规则集合，测试后记录命中的出站标签。若把多个来源的规则一次性合并，规则相互遮蔽时很难判断是哪次修改改变了行为。

私有地址直连也需要结合网络用途判断。局域网服务可能使用内部域名，应用又可能先解析成私有地址；只写公开域名规则不一定覆盖这些连接。反过来，扩大私有网段匹配范围前，也应确认不会把本来需要特殊路径的内部网络流量送错位置。规则表达的是实际网络边界，不是看到“私有”二字就可以忽略所有访问控制。

客户端内的全局、绕过或规则模式可能通过不同模板生成路由，名称相近不保证配置完全一致。切换模式后应重新查看生成配置，而不是继续分析切换前的文件。路由与 DNS 的关系也要一起检查：路由可能请求解析结果，解析服务器本身又需要出站可达，两者形成依赖时必须有清晰的基础网络路径。

dns：解析路径与地址选择

内核 DNS 负责向使用它的内部流程提供解析结果，不会因为顶层出现 dns 就自动替换系统解析器。应用若先通过系统 DNS 得到地址，再把 IP 交给代理，内核看到的可能只有地址。应用若把域名交给代理，路由或出站则可能调用内置 DNS。分析解析问题必须先确定查询由谁发起，再确定查询交给哪台服务器。

静态映射与服务器范围

{
  "dns": {
    "hosts": {
      "local.test": "127.0.0.1"
    },
    "servers": [
      {
        "address": "223.5.5.5",
        "domains": ["geosite:cn"]
      },
      "1.1.1.1"
    ],
    "queryStrategy": "UseIPv4"
  }
}

这个片段演示内核内部的静态映射、域名优先服务器与查询地址族，不会向系统 hosts 文件写入记录。local.test 只用来说明映射层级，能否被应用访问还取决于应用是否经过内核解析。domains 指定相应服务器优先处理的域名范围，但不等同于一条阻止其他解析路径的网络防火墙规则。

多个 DNS 服务器的选择还受内核实现与回退选项影响，不能简单理解为“第一台失败后才顺序尝试下一台”。需要严格限定某类域名的解析去向时，应继续检查所用内核的回退与匹配行为，并用实际查询结果验证。示例里的公共解析地址只是展示字段形式，部署时应选择在当前网络可达、并符合实际需求的解析服务。

DNS 与路由的双向依赖

当路由使用 IPIfNonMatch，一次域名连接可能先进入域名规则，未命中后请求解析，再用地址继续匹配。解析失败会让后续决策缺少信息，表现却可能像普通连接超时。另一方面，DNS 请求自身也需要网络路径；不同解析方式可能经过内核路由，也可能采用本地路径。不要假定设置了解析地址，就已经指定了解析流量使用哪个出站。

使用加密解析服务时，还要考虑解析服务器名称的初始解析。如果访问解析服务需要先解析其域名，而这个解析步骤又依赖尚未建立的代理连接，就可能产生循环依赖。先为基础解析或服务器地址提供可用路径，再逐步加入分流。排错时可以暂时使用明确的可达地址，判断故障是在名称解析、传输建立还是目标服务器响应阶段。

hosts 适合处理少量明确的内部映射或测试覆盖，不适合长期手工维护大量经常变化的公共服务地址。服务地址可能随区域、负载与网络变化而调整，固定映射过久可能连接到不合适的目标。添加映射前记录目的，测试结束后及时清理；否则日后即使修改了服务器配置，也可能一直被旧映射优先覆盖。

IPv4、IPv6 与目标连接

queryStrategy 控制内置解析器请求或选用的地址类型。示例中的 UseIPv4 适合用来隔离 IPv6 路径问题，但不是所有网络的长期最佳选择。解析得到 IPv6 地址，不代表当前出站具备可用 IPv6 连通性；只获得 IPv4 地址，也不意味着应用没有通过其他解析路径得到 IPv6。需要分别验证查询结果与连接结果。

路由的 domainStrategy、DNS 的 queryStrategy 与直连出站中的地址策略属于不同层级。它们名称相似，但作用对象不同。遇到“改了策略仍然没有变化”，先检查字段放在哪一段，以及对应代码路径是否被实际调用。若应用传入的已经是 IP，继续修改某个未参与处理的 DNS 服务器条目通常不会改变这条连接。

常见的收敛顺序是：确认服务器地址能解析，确认解析服务可达，确认目标获得预期地址，再确认路由选中正确出站。不要同时切换多个解析服务、修改地址族并重排所有路由。每次保留一项变化，记录失败阶段，才能区分解析器故障、地址不可达与出站本身的握手问题。

policy、日志与连接策略

策略用于管理连接的生命周期和统计行为，不负责选择代理服务器，也不会自动提升网络质量。调整之前应先确认问题发生在连接建立、空闲保持还是上下行结束阶段。把所有超时同时调大，可能只是让失败更晚出现；把所有值调小，则可能让正常的弱网请求提前结束。策略参数应服务于可描述的应用行为，而不是作为通用加速开关。

用户等级与连接时间

{
  "policy": {
    "levels": {
      "0": {
        "handshake": 4,
        "connIdle": 300,
        "uplinkOnly": 2,
        "downlinkOnly": 5,
        "statsUserUplink": false,
        "statsUserDownlink": false
      }
    },
    "system": {
      "statsInboundUplink": false,
      "statsInboundDownlink": false,
      "statsOutboundUplink": false,
      "statsOutboundDownlink": false
    }
  }
}

这里的时间单位为秒，数值用于展示常见字段组合，不是适合所有应用的推荐参数。handshake 约束协议握手允许的时间；connIdle 描述连接空闲容忍时间；上下行单向阶段的保持由 uplinkOnly 与 downlinkOnly 等字段参与控制。具体生效还与协议实现及连接状态有关，不能将其当成操作系统所有套接字的统一超时。

levels 的键使用字符串形式的等级编号。它应与支持用户等级的协议对象中的 level 对应。增加一个等级定义，并不会自动把所有连接移到该等级。若修改后行为没有变化，应先检查当前协议是否使用该策略、用户等级是否匹配，再考虑数值大小。不同入口与协议的支持范围需要按所用内核核对。

统计开关与展示链路

策略中的统计布尔值只决定是否记录相应类别的数据，不等于已经具备可查询的统计服务。完整统计链路还可能涉及 stats、API 服务、标签和客户端的读取逻辑。只有其中一段打开时，界面未出现数据并不能证明流量没有经过内核。桌面客户端可能自行生成统计所需段落，自定义配置不应盲目覆盖这些内容。

面向用户的流量显示，也不适合直接作为计费或完整网络审计依据。连接经过哪些入口、是否包含直连流量、统计何时重置，都由实际实现决定。排错时更有用的是把统计作为辅助信号：规则命中后对应出站是否有活动，切换服务器后数据是否进入新出站。不要用一个累计数值替代对实际请求和日志的验证。

日志级别与敏感信息

{
  "log": {
    "loglevel": "warning",
    "dnsLog": false
  }
}

日常可以先保留警告级别，在复现问题的短时间窗口内提高日志详细程度。日志越详细，越可能包含目标域名、连接地址与内部网络信息。提交问题前应移除服务器凭据、完整订阅地址和不必要的个人访问记录，同时保留错误类型、发生顺序与相关标签。删去所有上下文只剩“连接失败”，通常无法区分错误层次。

未设置文件路径时，日志可能写到进程输出，再由客户端收集。若显式配置文件输出，应确认目录存在且运行账户具有写入权限。客户端可写自身设置目录，不代表内核对任意路径都有权限。日志路径错误、磁盘空间不足或目录被其他程序限制，都可能让预期日志没有生成，不能因此直接认定内核未执行。

对于长连接中断，先比较应用自身超时、服务端空闲限制、网络设备连接保持与内核策略四个来源。只有证据指向内核空闲处理时，再调整 connIdle 等值。某些应用会主动发送保活请求，另一些应用不会；两者对相同策略的表现可能不同，因此一次测试结果不宜推广到全部程序。

对于启动失败，策略不是首要检查位置。先看 JSON 语法、字段兼容性和监听端口，再看资源路径与权限。若启动后只有特定请求失败，才进一步检查出站握手、DNS 和连接超时。按故障阶段安排检查顺序，可以减少没有依据的参数调整，也能保留一份真正可解释、可回滚的配置。

客户端设置与内核配置边界

客户端负责组织服务器、订阅、路由模板与运行方式，内核负责处理连接。桌面首推 v2rayN，Android 可按需求选择 v2rayNG 或以 V2Fly 为核心的 v2flyNG。三款客户端的入口名称与生成流程不完全相同，不能把桌面截图中的每个开关直接翻译成一个通用 JSON 字段。查阅时先确定设置属于客户端、系统还是当前内核。

订阅管理与生成文件

订阅是服务器信息的分发方式，不是 V2Ray 顶层的 subscription 配置段。v2rayN 中的订阅分组、自动更新间隔与更新请求方式由客户端保存；内核通常接收的是解析后生成的出站参数。修改订阅更新间隔不会改变现有连接的超时策略，修改出站用户参数也不会自动修复一个失效的订阅地址。

更新订阅前应保留当前可用配置。更新后检查分组、服务器数量变化与当前选中项，特别留意原选中服务器被删除或名称改变的情况。手工修改由订阅管理的条目，下一次更新时可能被覆盖。长期自定义参数应使用客户端支持的持久设置或独立自定义配置，避免把运行文件当作订阅数据库。

遇到更新失败，先区分请求地址不可达、服务返回错误和内容格式不被识别。浏览器能打开某个页面，不代表该页面就是客户端能解析的订阅内容。完整链接中可能含访问凭据，不要公开粘贴。导入路径与分享链接格式可继续阅读订阅链接导入方法，首次操作仍建议按教程主线完成。

TUN 模式与流量接管

TUN 通过虚拟网络接口接收网络层流量，涉及系统路由、权限、DNS 接管与排除规则，不是给普通 V2Ray 顶层对象加一个 tun 字段。客户端可能调用另一套内核配置实现这项能力，其字段结构与本页常规 V2Ray、Xray 配置并不相同。应从 v2rayN 的 TUN 模式入口查看实际生成内容与相关日志。

开启前先确认普通代理入口工作，再确认权限、虚拟接口与系统路由是否成功建立。若普通代理可用而 TUN 不可用，优先检查接管链路，不要立即重写远端协议参数。还应检查服务器连接本身是否被错误送回虚拟接口形成循环，以及局域网服务是否需要排除。与其他虚拟网络程序同时运行时，路由优先级也可能影响结果。

多内核切换

内核选择不只是切换一个名称。它会影响协议支持、传输字段、规则数据与客户端生成器采用的配置格式。v2rayNG 常用 Xray，v2flyNG 使用 V2Fly；v2rayN 的实际可选项与安装组件有关。切换后应重新验证服务器参数、路由和 DNS，不要把一套内核扩展直接复制给另一套。生态关系见关于本站中的背景说明。

系统代理与应用行为

系统代理由客户端写入操作系统或桌面环境的代理设置，不属于内核通用顶层字段。它只对遵循这些设置的应用有效。某个应用仍然直连时，先看应用是否使用自己的代理配置，再看其流量类型。关闭内核后若系统代理仍指向原本地端口，应用可能持续报连接失败；此时应清理系统代理，而不是仅删除配置文件。

客户端升级或重置之前，分别备份订阅分组、路由模板和自定义配置。恢复时也分层进行：先恢复一个可用服务器，再恢复规则，最后恢复接管方式。若一次导入全部旧设置后故障重现，就难以判断是旧字段不兼容、生成过程改变，还是系统代理与虚拟网络状态没有恢复到预期。

配置验证与分层排错

验证配置应从“能解析”逐步推进到“结果符合预期”。语法正确只表示文件结构可以读取，不代表字段被支持；字段被支持也不代表远端服务器可达；连接成功更不代表所有规则都按预期分流。每一层都应有独立测试目标，上一层没有通过时，不要通过修改下一层参数尝试碰运气。

建立可恢复的测试基线

先保存当前可用配置及其对应客户端设置，记录正在使用的内核。测试副本只修改一个配置段，并明确成功标准，例如本地端口能接受请求、某个域名使用指定出站，或局域网地址保持直连。不要在测试过程中同时更新订阅、切换内核和重排规则。发生变化的因素越少，错误结果越容易解释。

客户端支持配置检查或生成配置查看时，优先使用这些入口。先核对运行配置是否真的包含刚才的修改，再检查错误输出。部分客户端会在启动内核之前生成临时文件，手工编辑旧文件并不会影响下一次启动。若保存后内容消失，应回查设置来源，不要反复修改同一个会被覆盖的文件。

按故障阶段缩小范围

语法错误先看报错附近的字段，但也要检查前一行是否漏逗号或多逗号。字段类型错误可能藏在看起来合理的值中，例如将数字端口写成不符合字段要求的文本。启动错误则应优先处理最早的实质错误，后续“进程退出”往往只是结果。把完整错误顺序保留下来，比只截取最后一句更有帮助。

如果内核已经运行，先让一个明确支持代理的应用直接使用本地入口，不依赖系统自动代理判断。该测试成功而其他应用失败，重点转向应用入口与系统代理；所有应用都无法连接，则继续检查监听与内核进程。若本地入口接通但目标失败，再看远端握手和路由，不要把两个阶段混为同一个“无法联网”。

用小范围规则验证实际去向

路由排错应选择一个能稳定复现的目标，将它临时放入靠前的明确域名规则，指向已知可用的出站。确认行为改变后，再逐项恢复原来的分类规则和附加条件。若明确规则也不生效，检查应用是否传入域名、是否走了预期入口，以及读取的是否为当前运行配置。此时继续扩大规则库通常不能解决根本问题。

DNS 排错要同时记录查询路径和连接目标地址。域名获得地址后仍不可达，应检查该地址族与出站连通性；只有解析失败时，再重点检查解析服务与基础网络路径。不要仅根据浏览器报错页面判断问题位置，同一个超时提示可能来自入口端口、解析请求、远端认证或目标服务。日志时间顺序是关联这些阶段的重要依据。

回滚与可复现记录

测试失败后恢复最近的可用设置，并重新启动相关内核，确认监听与系统代理状态一致。关闭 TUN 时还应确认虚拟接口与系统路由已经按客户端流程恢复。若客户端本身无法启动，可参考启动闪退处理文章，先区分运行环境问题与内核配置问题；窗口打不开并不一定是 JSON 导致。

最终保留的配置应当能回答三个问题：应用从哪个入口进入，规则为什么选择这个出站，域名在哪里解析。无法解释的字段先不要保留为长期设置。完成验证后回到日常使用教程管理连接与模式，需要更换安装平台时再进入客户端下载页。把日常操作与配置实验分开，后续更新和故障恢复会更清楚。