V2Ray 配置文件参考

一、JSON 结构与客户端边界

从图形设置到内核配置

v2rayN 是桌面端的优先选择，负责管理服务器、订阅分组、系统代理及内核启动参数；实际处理连接的是选定的内核。Android 端的 v2rayNG 使用 Xray 内核，v2flyNG 使用 V2Fly 内核。三款客户端的设置界面不完全相同，生成的 JSON 也不一定逐字一致。阅读文件前，先在客户端确认正在使用的内核，再确认这份文件是完整运行配置，还是单个服务器的分享内容。订阅地址、分享链接、客户端数据库和内核配置是不同的数据入口，不能仅因都包含服务器信息就互相替代。

一次普通连接可按“本机应用进入入站、路由选择出站、出站建立远端连接”的顺序理解。inbounds 定义接收方式，outbounds 定义发送方式，routing 将连接分配给指定出口。dns 为需要解析域名的环节提供解析设置，policy 调整连接计时和统计开关，log 决定记录哪些诊断信息。并非每份配置都需要写出全部顶层对象；省略字段意味着使用内核默认行为，不意味着这个功能在整条连接中不存在。

先读一份可运行的最小结构

下面的完整配置在本机回环地址提供 SOCKS 入口，所有连接直接访问目标。它用于观察配置结构和监听行为，不包含远端代理服务器，因此不会建立加密隧道。运行前确认端口没有被其他客户端占用。示例显式写出路由和出口标签，目的是让引用关系可见；实际只有一个出口时，仍可以按内核默认出口机制工作。后续章节的片段应合并到对应层级，不要把多个顶层对象直接粘在同一文件末尾。

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    }
  ],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "inboundTag": ["local-socks"],
        "outboundTag": "direct"
      }
    ]
  }
}

对象、数组与标签的读法

花括号表示对象，方括号表示数组。入站和出站通常都是数组，因为同一进程可以同时监听多个入口，也可以持有多个出口。端口应写成数字，开关应写成布尔值，不能把 true 写成字符串。JSON 的键名和字符串使用双引号，不接受行尾多余逗号，也不接受普通注释。界面允许填写的注释或备注，未必属于内核配置字段。遇到启动失败时，先排除语法问题，再讨论协议参数，能够减少无关修改。

tag 是配置内部的标识，不是服务器地址，也不是界面显示名称。路由里的 outboundTag 必须与某个出站的标签精确对应；大小写、空格及连字符的变化都会改变引用。建议使用简短稳定的标签，并在修改后检查所有引用位置。顶层对象的书写先后通常不表达执行顺序，但数组顺序可能有意义，尤其是路由规则和默认出口。不要通过交换顶层键的位置尝试修复路由。

导出配置前记录当前代理模式和活动服务器，导出后另存副本，再进行单项修改。文件可能包含订阅地址、用户标识和认证信息，向他人说明问题时只保留相关字段及脱敏日志。安装包与平台选择见安装包页面；如果尚未完成一次正常连接，先沿快速上手主线完成基础设置，再返回本页逐段阅读。

二、inbounds 入站监听与流量探测

监听地址决定入口可被谁访问

入站是内核接收连接的入口，不是远端服务器。listen 指定绑定地址，port 指定端口，protocol 决定入口协议。普通单机使用优先监听 127.0.0.1，这样只接收来自本机回环网络的连接。改为 0.0.0.0 会监听所有 IPv4 接口，可能让局域网其他设备访问入口；是否真的可达，还受防火墙、网络隔离及路由影响。需要局域网共享时，应同时评估认证和访问范围，而不是只打开客户端中的允许局域网连接开关。

端口一致只是连接成功的一项条件。应用填写 HTTP 代理时，必须连接 HTTP 入站；填写 SOCKS 代理时，必须连接 SOCKS 入站。某些客户端提供混合端口，会在界面层将不同代理协议汇总为一个入口；本文采用独立入站展示字段，避免把某个客户端的端口习惯当作所有内核的固定默认值。查看参数设置中的实际监听端口，再填写应用代理地址。不要同时启动两份配置去占用相同的地址和端口。

SOCKS 与 HTTP 的独立示例

下面片段替换顶层 inbounds 数组，可以分别提供 SOCKS 和 HTTP 入口。SOCKS 的 udp 允许处理相应的 UDP 转发请求，但应用还必须实际使用 SOCKS 的 UDP 机制，后续出口也必须支持该流量。仅打开这一字段，不会让所有系统应用自动获得 UDP 代理。HTTP 入站适合显式配置 HTTP 代理的应用；应用是否遵循系统代理，仍由应用自身决定。

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

sniffing 只解决连接识别的一部分

流量探测会尝试从协议握手中提取域名等信息。例如，应用只提交了目标 IP，内核仍可能从可识别的 HTTP 主机字段或 TLS 握手中得到域名，从而让域名规则参与判断。destOverride 指定允许探测的协议类别，不是让内核解密任意内容。加密握手、应用协议及内核实现都会限制可识别的信息。无法探测到域名时，应回到应用交付的原始目标和 IP 规则排查，不能假定每条连接都有可用的域名。

routeOnly 用于将探测结果主要用于路由判断，而不直接据此替换连接目标。这样可以区分“用哪个名字匹配规则”和“最终向哪里建立连接”。该字段及探测支持范围应以当前内核为准；不识别字段时，不要凭相似名称另造键名。关闭探测后域名分流表现变化，说明规则可能依赖探测信息，下一步应检查 DNS 交付方式及应用是否保留目标域名，而不是直接认定服务器异常。

系统代理开关属于客户端对操作系统的设置，不是这里的入站字段。关闭系统代理后，手动填写 SOCKS 地址的应用仍可能继续连接入站；开启系统代理后，不遵循该设置的应用仍可能直接访问网络。TUN 则涉及虚拟网卡、路由接管和权限，不能通过增加一个普通 SOCKS 入站来替代。排查时先明确应用采用哪种接入方式，再检查对应入口，避免同时调整三个互不等价的开关。

三、outbounds 出站协议与标签关联

出口定义与路由选择分开阅读

出站负责把连接发送到下一跳。protocol 决定使用直连、阻断或某种代理协议，settings 保存该协议专属参数，streamSettings 描述与远端之间的传输和安全层。路由只负责选中出口，不会自动补齐认证信息。即使路由日志显示命中了代理标签，服务器地址、端口或安全参数错误时，连接仍会失败。因此应把“选中了正确出口”和“出口成功建立连接”作为两个独立检查点。

freedom 表示从当前设备直接连接目标，blackhole 用于终止相应流量。它们都是本地处理方式，不需要订阅提供远端地址。下面片段给出两个可复用出口，可以与第一章的入站组合使用。标签命名没有特殊魔法：把直连标签改成别的名字，不会改变协议行为；真正决定行为的是 protocol。但改名后必须同步更新路由、代理链及其他引用位置，否则配置可能无法启动或不能按预期转发。

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

远端出站需要成组核对参数

实际代理出口应由已有的服务器信息生成。不同协议的 settings 结构不同，不能把一个协议的用户字段直接移到另一个协议下面。阅读 VLESS 出站时，通常会遇到服务器列表、地址、端口、用户标识及加密声明等参数；阅读 Trojan 出站时，认证结构又不同。服务器地址决定连接位置，用户标识或口令决定身份，TLS 或 REALITY 参数决定安全握手。这几组字段互相配合，单独改一个值可能让整个组合不再匹配。

图形客户端的服务器编辑窗口更适合维护这些关联参数。先导入可信来源提供的完整分享内容，再对照导出的出站对象阅读，通常比手工从空文件构造更容易保持一致。本文不放能够被误当成真实服务器的账号示例。若需要向维护者描述问题，应说明协议名、传输类型、是否启用安全层以及错误发生的阶段，删去认证内容。不要把含有完整用户信息的出站对象直接贴到公开讨论中。

默认出口与数组顺序

在常见单一路由配置中，连接未匹配任何规则时会使用出站数组中的第一个出口。因此把直连放在首位和把代理放在首位，会产生不同的兜底结果。界面里的“全局”“绕过局域网”等模式可能重建规则或调整出口排列，不能只凭模式名称判断最终配置。导出文件后检查第一项，再检查是否存在覆盖全部连接的末尾规则。如果配置使用负载均衡或出站链，应继续读取相应引用，不能把这种结构简化为单出口情况。

多出口并不意味着同时连接所有服务器。普通路由命中一个出站标签后，连接交给该出口处理；服务器测速、自动选择、故障转移则需要客户端或内核的对应机制。把两个代理对象并排写进数组，并不会自动实现按速度选择。共享同一标签还会造成歧义或配置错误，应保持每个逻辑出口的标识唯一。需要多设备同步时，可参考订阅、二维码与配置导出的同步说明，先区分服务器资料同步和路由设置同步。

从能直连的最小配置扩展时，建议先保留一个已知可用入口，只增加一个远端出口，再加一条指定该入口的规则。连接成立后才追加分流。这样可以把入口、协议参数和规则三类问题拆开。若客户端对自定义配置与内置服务器模式采用不同启动方式，应先确认当前模式确实使用了这份文件；编辑一份未被加载的配置，不会改变正在运行的连接。

四、routing 规则顺序与匹配条件

规则按数组顺序判断

路由把已经进入内核的连接送往指定出口。常用的字段规则使用 type: "field"，通过目标域名、目标 IP、端口、网络类型或入站标签进行筛选。规则通常从上到下判断，命中可用规则后选定出口；因此应先放范围明确的例外，再放覆盖范围较大的兜底。把广泛匹配规则放在首行，后面的细分规则可能始终没有机会参与。阅读路由时，不能只搜索目标域名是否出现，还要检查此前是否已有规则截走连接。

同一条规则中的不同条件通常需要同时满足，例如同时写 inboundTag 和 domain，表示既来自指定入站，又匹配指定域名。一个域名数组中的多项则用于表达可接受的多个匹配值。不要把跨字段的关系误读成任选其一。需要表达两种互不依赖的条件时，拆成两条规则更清楚。规则里使用的入站标签与出站标签必须已经存在；注释式的中文说明不能代替真实标签引用。

域名精确匹配、后缀匹配与地址段

full: 用于精确域名匹配，适合只处理某个完整主机名；domain: 用于匹配指定域名及其子域，适合一组同属某个域的服务；regexp: 表示正则表达式，适合确实需要模式识别的情况。普通字符串的匹配范围也应按内核文档核对，不能默认等于精确匹配。正则表达式进入 JSON 后需要再次处理反斜杠转义，写错时可能语法有效但匹配无效。能用明确域名表达的规则，通常不必改用复杂正则。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["full:blocked.example"],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "ip": [
          "127.0.0.0/8",
          "10.0.0.0/8",
          "172.16.0.0/12",
          "192.168.0.0/16",
          "::1/128",
          "fc00::/7"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "inboundTag": ["local-socks", "local-http"],
        "network": "tcp,udp",
        "outboundTag": "direct"
      }
    ]
  }
}

该片段配合前文的直连和阻断出口使用。保留域名仅用于演示精确匹配；私有地址段规则用于说明 IP 条件；末尾规则将两个本地入口的其他连接送往直连。它不是一份代理分流方案。若要改为代理兜底，必须先加入真实且可用的代理出口，再修改末尾标签。域名指向私有地址时，是否会被 IP 规则识别，还取决于当时是否已有目标 IP，以及域名策略是否触发解析。

domainStrategy 与规则数据文件

AsIs 尽量使用连接已有的信息匹配，不为了域名路由主动进行额外解析。IPIfNonMatch 会在域名未匹配时尝试解析，再用 IP 条件判断。IPOnDemand 则可能在遇到需要 IP 的规则时触发解析。选择后两者会增加对 DNS 的依赖，也可能改变匹配结果。这里的策略服务于路由判断，不等于出站建立连接时的解析策略，更不能替代操作系统的 DNS 设置。

geoip: 与 geosite: 形式依赖可用的规则数据文件及其中存在的分类。配置字符串写对，并不保证客户端已携带相应数据。启动时提示找不到文件或分类，应先检查内核资源目录和客户端的规则数据管理入口，而不是把分类名随意换成看起来相近的词。跨设备迁移自定义配置时，也要同步考虑这些外部依赖，不能只复制一个 JSON 文件后就认定环境一致。

定位规则问题时，先记录应用交给入站的目标是域名还是 IP，再查看流量探测是否补充了域名，最后按顺序逐条推演条件。临时将一条明确的域名规则移到前面，能够帮助判断是否被前置规则覆盖，但测试后应恢复合理顺序。规则改动通常只影响新连接；浏览器或应用复用旧连接时，观察结果可能滞后。重新建立测试连接后再判断，避免因旧会话仍在运行而重复修改配置。

五、dns 解析路径与分流边界

先确认是谁在解析域名

一次访问可能涉及操作系统解析器、应用自己的解析器、内核内置 DNS，以及远端服务器的解析过程。顶层 dns 只定义内核需要解析时如何查询，并不会自动接管系统中所有 DNS 请求。应用如果先把域名解析为 IP，再把 IP 交给 SOCKS 入站，内核看到的原始目标就不再是域名；应用如果把域名交给代理，后续解析位置又可能不同。排查时应先确认输入形态，不能仅根据配置里存在 DNS 对象就认定所有查询都经过它。

以下示例使用普通 DNS 地址展示字段层级，不代表针对某种网络环境的优选方案。servers 是解析服务器列表，既可以写简单地址，也可以写带有匹配条件的对象。hosts 可把指定名称静态映射到地址，适合临时定位或固定内部服务；映射内容不会自动跟随服务地址变化。示例中的测试域名与文档地址用于说明格式，不应作为真实网站记录长期保留。

{
  "dns": {
    "hosts": {
      "full:service.example": "192.0.2.10"
    },
    "servers": [
      "1.1.1.1",
      "8.8.8.8"
    ],
    "queryStrategy": "UseIP"
  }
}

查询策略不等于连接策略

queryStrategy 控制内核 DNS 查询使用的地址族。UseIP 允许 IPv4 和 IPv6 结果，UseIPv4 或 UseIPv6 则限制查询范围，具体支持情况需按当前内核确认。限制为 IPv4 可以帮助定位某些 IPv6 路径问题，但不能修复服务器握手参数错误。相反，设备网络仅能通过特定地址族到达服务时，过度限制解析结果会让原本可用的目标失去可达地址。

路由中的域名策略、DNS 中的查询策略，以及出站自己的域名解析选项，作用阶段不同。路由可能为了匹配 IP 规则先解析一次，出站连接时又按其自身逻辑处理目标；如果两处策略不同，观察到的地址可能不一致。应先写明希望“用域名选出口”还是“用解析后的地址选出口”，再决定哪些环节需要解析。不要为了让字段看起来统一，就把多个位置的策略设置成名称相近的值。

解析服务器本身也需要可达路径

普通 DNS 查询和加密 DNS 请求都需要到达解析服务器。不同内核对 DNS 地址格式、直连模式及查询路由方式有不同实现，不能把一种地址写法机械迁移到另一种内核。使用以域名表示的解析服务时，还要考虑首次访问解析服务本身需要怎样解析，这就是引导解析问题。如果解析服务只能经由某个代理访问，而代理服务器的地址又依赖同一解析服务，就可能形成循环依赖。应为其中一段保留独立可达的启动路径。

DNS 服务器列表不应被理解为固定的逐项容灾清单。是否并发查询、何时使用后备服务器、匹配域名的服务器是否排除默认回退，都与内核实现及对象字段有关。需要按域名选择解析服务器时，先在简单配置下确认每个服务器可达，再加入域名条件和回退控制。一次添加多个服务器并同时更改路由，会使超时原因难以归属。测试时记录查询对象、目标地址族及错误时间，区分解析超时和连接超时。

缓存也会影响观察。应用可能保留自己的域名结果，操作系统可能缓存记录，内核内部也可能复用解析信息。修改 DNS 后，已有连接不一定立即重建，旧地址也可能继续出现。先关闭测试应用的旧会话，再建立新请求；必要时通过客户端可用的重启内核操作清理运行状态。不要仅凭一次网页刷新就判断新的解析策略完全生效，更不要把缓存造成的短期差异误当成分流规则随机失效。

若域名访问失败而已知地址可达，仍需考虑证书与服务器名称，不能直接把网站 URL 改成 IP 当作等价测试。正确的排查顺序是确认解析返回、确认所选出口、确认该出口到目标地址可达，再检查握手阶段。记录这些层次后，DNS 错误与安全层错误才不会混在同一条“打不开”的描述里。

六、policy 连接计时与统计策略

策略按用户等级选择，不按界面分组选择

policy 管理连接生命周期和部分统计行为，不负责决定出口，也不负责修改协议认证。levels 的键是用户等级的字符串形式，例如 "0"；协议中支持的用户等级字段用于关联对应策略。这里的等级不是订阅分组，不是服务器优先级，也不是路由列表序号。仅建立一个等级对象，并不会让所有协议对象自动迁移到这个等级。阅读导出配置时，应同时检查用户对象中的等级及内核对该协议的支持情况。

下面示例展示等级策略和系统统计开关的结构。数值用于解释字段，不是针对所有设备的性能建议。多数普通使用场景可以先保留客户端默认值，只有在日志和连接表现指向计时问题时才调整。不同内核对默认值、缓冲分配及统计接口存在差异，因此迁移配置时，应先确认字段仍然受支持，再比较运行行为。把一组网络参数复制到所有设备，并不能保证相同效果。

{
  "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 表示入站协议握手阶段的时间限制，单位为秒。它不等于网页完整加载时间，也不是可以覆盖所有远端 TLS 握手行为的统一开关。握手前就遭遇本地端口不可达时，调大这个值没有帮助；远端出站因为认证错误失败时，也不能指望延长入站握手时间修复。必须先根据日志确认卡在哪一段，再决定是否存在合理的时间余量需求。

connIdle 用于限制连接在没有数据活动时持续等待的时间。设得过短，可能影响间歇发送数据的长连接；设得很长，则可能让空闲连接占用资源更久。应用层心跳、服务器空闲策略和中间网络设备的超时同样会影响连接存续，单独延长客户端计时无法覆盖其他环节。排查周期性断开时，应记录断开前是否有数据交换，以及客户端和服务器两侧是否存在不同的超时限制。

uplinkOnly 与 downlinkOnly 处理连接一侧结束后，另一方向仍可继续传输的等待阶段。这类半关闭状态不同于整条连接都空闲：上传结束不代表下载一定结束，下载一侧结束也不意味着所有应用都已完成发送。过于激进的值可能截断需要收尾的传输，盲目增大又可能延长残留会话。遇到大文件或请求尾部异常时，应结合应用协议与日志观察，不要把这两个字段当作上下行速度限制。

开启统计不等于界面立即显示数据

用户统计需要相应用户身份标识及内核支持，系统统计则围绕入站和出站对象计数。设置为 true 只是允许采集对应统计，不会自动建立读取接口，也不会自动在客户端增加面板。部分场景还需要顶层统计模块、API 服务及调用方配合。图形客户端可能已经管理相关配置，手工加入重复的 API 入站或统计服务可能产生端口冲突。只需要查看日常连接信息时，优先使用客户端现成的日志和状态入口。

策略中的缓冲相关字段也不应被当成通用加速按钮。缓冲大小、并发连接数、设备内存和协议行为共同决定资源占用；更大的缓冲可能增加内存压力，并不能改变远端线路容量。除非能复现具体瓶颈，并有明确的内核文档依据，否则先保留默认值。尤其在移动设备上，后台限制和系统节电可能才是中断来源，内核策略无法代替系统对后台运行的授权。

修改策略时只改变一项，并保留原来的有效配置。测试对象应包含短请求、持续传输和空闲后恢复三种行为，分别观察是否出现异常。若客户端会重新生成文件，应在它支持的高级设置入口保存，而不是反复修改临时运行文件。配置启动成功只说明语法和部分语义被接受，并不证明计时策略适合当前应用；仍需通过真实操作确认边界。

七、传输、安全层与内核差异

代理协议之外还有传输组合

服务器条目通常同时包含代理协议、传输方式和安全层。代理协议负责认证及代理语义，传输方式决定字节如何承载，安全层负责相应的握手保护。它们在界面中可能相邻，但不是同一个字段。出站的 protocol 与 streamSettings.network 各有用途；把界面的传输类型填到代理协议位置，会得到错误结构。遇到某条配置只在一个客户端可用时，先比较这三个层次，再比较内核是否接受对应语法。

下面是 WebSocket 与 TLS 的传输片段，应放在一个具有真实服务器参数的出站对象内部，而不是直接放在 JSON 顶层。示例使用保留域名说明字段位置，不是可直接连接的服务器资料。它还必须与服务器端的传输方式、路径和证书名称对应。仅复制这段而没有正确的出站协议与认证设置，不能建立有效连接。

{
  "streamSettings": {
    "network": "ws",
    "security": "tls",
    "tlsSettings": {
      "serverName": "edge.example",
      "allowInsecure": false
    },
    "wsSettings": {
      "path": "/connect",
      "headers": {
        "Host": "edge.example"
      }
    }
  }
}

地址、serverName 与 Host 不能混为一谈

出站服务器地址决定向哪个主机建立网络连接。serverName 参与 TLS 握手及证书名称判断，WebSocket 的 Host 则是 HTTP 握手中的主机信息。三者在某些部署中相同，在另一些部署中由服务端明确要求不同。不要为了看起来整齐把它们强行改成一个值。证书错误应先检查设备时间、服务器名称与服务端证书配置，而不是关闭证书验证。关闭验证会改变连接的信任条件，也可能掩盖填错目标的问题。

WebSocket 路径用于匹配服务器上的传输入口，大小写和路径内容应与服务端配置一致。它不是网页地址栏中的随意目录，也不应从其他服务器条目借用。若返回的内容像普通网页或出现握手状态错误，可能连接到了同一主机上的其他服务。此时应检查传输方式、路径和主机字段，不要只重复更换用户标识。普通端口连通测试只能证明某个端口响应，不能证明该端口后面的代理协议组合正确。

REALITY 与内核选择

REALITY 是安全层相关能力，不是顶层代理协议名，也不是可以随意打开的通用增强开关。使用时要核对实际内核支持，以及服务端提供的服务器名称、公钥材料、短标识和其他必需参数。不同内核或配置代际可能采用不同字段表示，不能通过猜测键名解决兼容问题。本文不提供脱离服务端资料的 REALITY 通用模板；应以客户端能正确识别的完整分享内容为起点，再对照实际生成的出站对象。

v2rayN 的具体能力取决于所选内核和客户端适配，v2rayNG 与 v2flyNG 也不能因为界面接近就视为完全等价。需要某项协议或安全层时，先确认该内核实现了它，再决定客户端。更换内核后，旧配置中的字段可能被拒绝，或者有不同的默认行为。应保存原配置，通过客户端支持的方式重新生成，再对比关键参数。相关背景见Xray 内核与 V2Fly 内核区别。

Mux 多路复用属于另一类连接组织机制，不能修复安全握手或认证错误，也不保证对所有应用都有收益。客户端中的 Mux 开关可能影响生成的出站配置，使用前应核对协议组合及内核限制。排查时先关闭额外的连接组织选项，以基础组合完成测试，再逐项恢复。不要在协议尚未连通时同时调整 Mux、DNS、路由和探测，否则即使偶然恢复，也难以解释是哪一项产生影响。

跨平台迁移还要留意系统环境。Windows、macOS、Linux 的系统代理机制不同，Android 的 VPN 接入与分应用选择也不是 JSON 传输字段的一部分。传输配置正确但应用没有进入入站时，仍不会产生预期连接。macOS 首次运行涉及系统放行或网络权限时，可查阅安装放行与网络权限说明，不要通过修改协议参数处理系统权限问题。

八、配置检查、日志阅读与回退

按语法、启动、入口、出口逐层确认

配置排错首先需要一份可以回退的有效副本。保存当前客户端设置和自定义配置后，只修改一个层次，重新启动对应内核，再建立新连接。若无法启动，先查看第一条有意义的错误：缺少逗号属于 JSON 语法问题，未知字段或协议属于配置兼容问题，监听失败常见于地址或端口冲突。它们都发生在正常转发之前，不应先从远端服务器速度或网站可用性入手。修复最前面的错误后，再观察后续日志，避免追逐连带报错。

下面片段可临时替换顶层日志对象，用于增加诊断信息。日志等级使用 debug 时内容较多，可能包含目标地址和连接特征；完成排错后应恢复适合日常使用的等级。示例不指定文件路径，具体输出位置由启动方式和客户端管理。若界面没有显示新增日志，应确认客户端是否支持该等级，以及当前运行进程是否加载了修改后的文件，而不是马上怀疑日志模块本身失效。

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

通过错误发生的位置缩小范围

内核正常启动后，先检查应用是否真的产生入站连接。没有对应记录时，核对应用代理地址、代理协议、系统代理模式及分应用设置；有记录但选择了错误出口时，检查标签、规则顺序和目标形态；出口正确却连接失败时，再检查远端地址、认证、传输和安全层。若能建立连接但只有个别域名异常，才进一步核对 DNS、域名匹配及目标服务。这个顺序可以避免把所有问题都归类为“节点不能用”。

端口拒绝连接通常意味着目标端口未监听或主动拒绝，不等同于 DNS 失败；解析超时发生在得到地址之前；握手失败说明已经进入某种协议协商阶段，但具体原因仍需结合日志。超时本身不是明确结论，可能出现在建立连接、协议握手或等待响应的不同阶段。向他人说明情况时，应写清发生阶段和可复现步骤，而不是只提供一行笼统错误。日志中的时间有助于把一次操作与对应记录联系起来。

建立可解释的最小复现

先选一个活动服务器，使用一个明确入口和一个简单出口规则，暂时移除额外分流。确认基础连接后，再依次恢复域名规则、IP 规则、DNS 条件和高级策略。恢复某一层后问题出现，就保留这一层的最小相关条件继续调查。若配置依赖规则数据文件，应同时说明文件是否存在及分类是否有效。不要用一份包含大量无关规则的完整导出文件作为第一份排错材料，信息过多会掩盖实际关联。

客户端重新生成配置是常见变量。修改后短暂有效、切换服务器后失效，往往说明编辑的是临时文件，或者当前模式没有保存自定义内容。回到客户端支持的设置入口确认保存位置，再对照重新导出的配置。订阅更新只负责更新它所管理的服务器资料，不能假定会保留所有手工写入的字段。阅读主窗口入口可参考服务器列表、日志面板与参数设置速览，结构理解可继续看config.json 逐段拆解。

常见边界问题

回退时恢复最后一份已知有效的客户端设置或完整配置，重新启动内核并确认活动服务器、代理模式及入口端口。若仍有异常，说明问题可能不只来自本次 JSON 修改，还应检查系统网络、权限和服务端状态。基础操作顺序回到快速上手核对；需要重新选择设备对应客户端时使用安装包页面，不要用反复更换客户端代替对错误阶段的定位。