V2Ray 配置文件参考

JSON 结构总览与配置边界

先区分客户端设置与内核运行文件

V2Ray 生态中的配置通常分为两层。第一层是图形客户端保存的订阅、分组、界面偏好和代理模式；第二层是启动内核时生成的运行配置。二者可能都使用 JSON，但字段含义并不相同。订阅更新间隔属于客户端管理逻辑，不能直接添加到内核根对象。查阅文件前，先确认它是客户端数据库、订阅内容，还是实际交给内核读取的配置。文件扩展名相同，不代表能互相替换。

运行配置可以按数据路径理解：inbounds 接收应用连接，routing 决定连接交给哪个出站，outbounds 执行直连、代理或阻断，dns 提供内置解析设置，policy 调整连接策略。log 用于观察启动和运行情况。这些模块相互引用，但不要求每个功能都在最初启用。新增功能越多，需要同时验证的条件越多；排错时应保留最小链路，再逐项恢复。

最小配置：本机 SOCKS 入站与直连出站

下面是一个完整的基础配置，不依赖远端代理服务。应用明确使用本机 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": {}
    }
  ]
}

JSON 语法正确只是第一道检查

JSON 对象用花括号包围，数组用方括号包围，字段名和字符串使用英文双引号。数字端口不应写成带引号的文本，布尔值使用 true 或 false。正式文件不要加入注释、尾随逗号或单引号。阅读文章时看到的片段通常只包含一个模块，必须放回正确层级；把整个根对象塞进入站的 settings，即使语法仍然成立，也不符合内核的结构要求。

语法检查通过后，还要检查字段是否受当前内核支持、引用标签是否存在，以及外部文件路径能否访问。Xray 与 V2Fly 共享一部分配置概念，但新增协议、传输字段和测试参数并不完全一致。不要仅凭客户端名称判断兼容性，应查看当前实际启动的内核名称和日志。某个界面能导入分享链接，也不等于所选内核能够运行其中的全部传输参数；导入成功与连接成功属于不同阶段。

修改前保留一份可启动配置，并记录修改发生在客户端界面还是自定义文件。若运行文件由客户端自动生成，直接编辑它可能在切换节点或重启后被覆盖。正确路径是先在界面完成常规设置，再通过客户端明确提供的自定义配置入口添加扩展内容。无法确认入口时，先导出或查看当前生成结果，不要以反复修改临时文件代替持久设置。后续章节均沿用这一分层方法，避免把覆盖问题误认为字段失效。

inbounds 入站：监听地址、端口与协议

入站描述的是应用如何进入内核

inbounds 是数组，每个对象代表一个接收连接的入口。tag 是供路由引用的名称，listen 决定绑定的本地地址，port 决定监听端口，protocol 决定入口协议。应用配置成 HTTP 代理时，需要连接 HTTP 入站；应用配置成 SOCKS 代理时，需要连接 SOCKS 入站。两种入口不能仅靠端口号互换。端口能够建立连接，也不代表应用与入站使用了相同的代理握手方式。

仅供本机使用时，监听地址优先使用 127.0.0.1。它限制入口在 IPv4 回环接口，不会因为电脑接入其他网络就自动向局域网开放。0.0.0.0 表示绑定所有可用 IPv4 接口，适合经过明确评估的局域网共享场景，但还需要防火墙限制来源。监听地址不是远端服务器地址，也不是其他设备应填写的目标地址；其他设备应填写运行客户端那台电脑在同一局域网中的实际地址。

双入口示例与字段含义

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

示例给两个协议分配了不同端口，便于在应用设置中辨认。SOCKS 的 udp 开关允许入口处理相应的 UDP 请求，但不能单独保证整条链路都能传递 UDP。应用需要使用相应能力，出站协议和远端也需要支持，途中网络还可能限制数据包。若网页正常而某个实时应用异常，应分别核对应用是否走入站、是否发起 UDP，以及出站链路是否具备相应能力，而不是只反复切换入口开关。

嗅探、系统代理与 TUN 不属于同一个开关

入站可按内核能力配置 sniffing，从部分协议握手中识别目标域名等信息。这有助于基于域名的路由判断，但不是通用的内容解析工具。加密握手特征、应用实现和内核设置都会影响可获得的信息。嗅探还可能影响原始目标与识别域名的使用关系，因此不应把它当成所有分流问题的默认修复。先确认应用传入的是域名还是 IP，再决定是否需要启用，并检查所用内核对相关选项的解释。

系统代理是操作系统向遵循该设置的应用公布代理入口；它本身不等于创建入站。TUN 则涉及虚拟网络接口、路由接管和 DNS 配合，不能通过在上述 JSON 中添加一个同名布尔字段完成。具体能力取决于客户端、所选内核和配套实现。检查时先确认本地端口已经监听，再确认系统代理指向该端口，最后检查目标应用是否遵循系统设置。把这三个步骤拆开，能避免把应用直连误判为内核路由错误。

局域网共享还要考虑设备地址变化、访客网络隔离和电脑休眠。手机与电脑名称相近或连接同一接入点，并不能证明它们可以互相访问。先验证同网段可达性，再开放必要端口，测试结束后收回不需要的入口。完整操作可参阅v2rayN 允许局域网连接设置。不要为了排错长期关闭整台设备的防火墙；优先建立限定端口、限定来源网络的规则，并记录其用途。

outbounds 出站：目标连接与标签引用

出站负责执行连接，不负责整理订阅

outbounds 也是数组，每个对象描述一种离开内核的方式。常见的 freedom 表示直接建立目标连接，blackhole 表示阻断，代理协议则需要与远端匹配的连接参数。tag 是路由选中出站时使用的名字，不是协议本身。把一个标签命名为 proxy 不会自动让它获得远端代理能力；真正行为由 protocol、settings 以及适用的传输设置共同决定。

没有规则命中时，通常使用出站数组中的第一个出站，因此数组顺序具有实际意义。准备默认走代理时，应确认首项就是期望的代理出站；准备默认直连时，首项可以是直连。不要假定所有未匹配连接会自动寻找名为 proxy 的对象。图形客户端可能根据当前模式重排或重新生成出站，检查时以运行配置为准，而不是以订阅列表中的显示顺序推断实际默认行为。

用本地上游演示代理、直连与阻断

下面的片段使用另一个本机 SOCKS 服务作为上游，避免把教学配置与真实远端凭据混在一起。只有当本机 127.0.0.1:10810 确实存在可用的 SOCKS 服务时，首个出站才能完成连接。它不能指回自己的入站端口，否则可能形成回环。若只是测试第一章的直连链路，不需要使用这个片段；在引入上游前，先证明上游本身可以独立处理请求。

{
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "socks",
      "settings": {
        "servers": [
          {
            "address": "127.0.0.1",
            "port": 10810
          }
        ]
      }
    },
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ]
}

协议参数与传输参数分层检查

VMess、VLESS、Trojan 和 Shadowsocks 的认证结构不同，不能把一个协议的设置对象直接复制到另一个协议下面。服务器地址和端口一致，只能说明目标入口相同，不能证明认证参数正确。若节点由订阅提供，应先完整保留导入参数，核对客户端是否识别了协议，再检查传输类型、安全层和服务器名称。排错时一次只调整一个已确认错误的字段，避免同时改变协议、传输和路由后失去可比较的结果。

streamSettings 用于适用的传输与安全设置，但其内部结构随协议和内核能力变化。WebSocket 的路径、TLS 的服务器名称、REALITY 相关参数都不是可以互相替代的文本。传输方式应与服务端一致，安全层也应与服务端配置相符。不要通过关闭证书验证来掩盖名称或时间错误；应先检查系统时间、服务器名称和服务端证书条件。连接失败若发生在握手阶段，改变路由列表通常不能修复远端参数不匹配。

同一远端节点在不同内核中能否使用，需要同时看协议和传输特性。不要只按协议名称做选择，例如能够识别 VLESS 并不意味着支持该链接附带的所有安全参数。对两条内核分支的差异，可继续阅读Xray 内核与 V2Fly 内核区别。确认兼容性后再切换内核，并重新检查实际生成文件，防止客户端沿用旧设置或丢失无法表达的参数。

出站管理还应保留明确的回退方式。新增代理出站时，先保留可验证的直连和阻断标签，再用一条范围很小的规则指定测试目标。确认成功后才扩大规则范围。删除某个出站之前，搜索路由和其他模块中是否仍有引用；留下悬空标签会导致配置报错或连接无法按预期处理。连接复用、链式转发等扩展能力适合在基础连接稳定后单独评估，不应作为最小示例的默认组成部分。

routing 路由：匹配顺序与默认出口

按规则顺序匹配，不按文案理解优先级

路由解决的是连接应交给哪个出站，不是远端节点能否连接。rules 数组通常从前向后检查，命中适用规则后选择其目标出站。特定规则应放在宽泛规则之前，例如先处理局域网目标，再处理某类域名，最后才考虑覆盖更大范围的规则。若第一条已经匹配全部 TCP 和 UDP，后面的细分规则就没有机会发挥作用。规则数量多不代表分流更精确，关键是条件之间是否存在覆盖关系。

同一条规则中，不同类型条件通常需要共同满足；同一个条件数组中的多个值通常提供可选匹配项。例如同时写入 domain 和 port，表达的是目标域名满足条件且目标端口符合要求，而不是两者任意满足即可。需要“域名命中或 IP 命中”时，通常拆成两条规则更清楚。阅读导入规则时先把条件翻译成完整句子，可以较快发现把交集误写成并集的问题。

局域网直连与指定域名阻断

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["full:blocked.example"],
        "outboundTag": "block"
      }
    ]
  }
}

这段配置需要已有 direct 和 block 出站，并需要内核能够加载对应的地域 IP 数据。示例域名属于教学名称，不代表实际服务。未命中规则的连接使用默认出站；若按上一章将代理放在首位，其余流量会交给代理。注意 AsIs 不会为了 IP 规则主动解析一个域名目标，因此用域名访问内部服务时，不能仅凭私有 IP 规则推断一定直连。内部域名应另设域名规则，或明确评估解析策略。

域名规则、IP 规则与数据文件

full: 用于完整域名匹配，domain: 用于指定域及其子域的匹配，普通文本和正则规则有各自语义。需要限定一个具体主机时，完整匹配更容易审计；需要覆盖整个域时，再使用域匹配。正则表达式应在确认简单规则无法表达需求后使用，并注意 JSON 字符串中的反斜杠转义。把正则测试器中的文本原样贴进 JSON，可能因为转义层数不同而改变最终含义。

geosite: 和 geoip: 引用的是数据分类，不是实时查询服务。分类是否存在、包含哪些记录以及更新后是否变化，取决于实际加载的数据文件。规则名拼写正确仍可能因为文件缺失、路径错误或分类不存在而无法启动。使用客户端提供的数据更新入口后，应重新启动相关内核并查看日志。不要同时替换多个来源的数据文件后只凭网页结果判断成功；先确认内核加载的是预期文件和预期路径。

上述策略决定路由阶段何时需要解析，不等同于 DNS 模块的地址族选择，也不等同于直连出站最终如何建立连接。一个域名可能先用于规则判断，之后仍由出站或远端处理连接解析。排错时应区分“用于选路的地址”和“用于实际连接的地址”。如果两处解析来源不同，日志中的 IP 与最终访问路径未必完全相同；不要只看到一个解析结果就推断整条链路已经固定。

验证新规则时，选一个明确目标，记录输入形式是域名还是 IP，并临时缩小规则范围。观察访问日志是否进入预期入站和出站，再恢复完整规则。应用缓存或已有长连接可能绕过新的连接决策，因此测试前应结束旧连接并重新发起请求。客户端若启用了自动更新路由模板，还要确认自定义规则是否在更新后保留。常见规则理解问题可与常见问题交叉查阅，而不必在多个模板之间反复切换。

dns 配置：解析来源、地址族与连接路径

先确认谁在解析域名

DNS 问题首先不是填写哪个服务器，而是确定解析发生在哪里。应用可以先通过系统解析得到 IP，再把 IP 交给代理；也可以把域名交给 SOCKS 或 HTTP 入口；内核还可能因为路由策略主动解析，远端代理也可能负责最终解析。只有请求实际使用内核 DNS 时，修改 dns 模块才会影响对应阶段。系统 DNS、浏览器自身的解析设置和内核 DNS 不是一个开关，不能用一次设置变化解释所有应用行为。

检查时记录目标输入、应用代理方式和路由策略。例如应用已经传入 IP，内核通常无法仅靠 DNS 配置恢复原始域名；嗅探可能提供部分线索，但并不保证每种连接都能识别。相反，应用传入域名时，AsIs 又可能让路由阶段不触发解析。先还原请求路径，再决定修改系统解析、应用设置还是内核模块，能避免把解析缓存、规则匹配和远端连接失败全部归为同一种 DNS 故障。

静态映射与解析服务器示例

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

这里的静态映射使用文档示例地址，不是可访问服务，可用于理解域名覆盖结构。两个服务器地址仅演示配置形态，不代表对任何网络都适用。多个 DNS 服务器的选择、并发与回退行为受配置形式和内核实现影响，不应把数组机械理解为浏览器收藏夹式的顺序尝试。正式使用前，需要确认服务器在当前网络可达，并检查请求是否经过预期路径。静态映射会改变对应域名的结果，测试结束后应删除不再需要的条目。

地址族策略与 IPv6 条件

queryStrategy 用于约束内置解析所查询或使用的地址族。UseIP 表示同时考虑 IPv4 和 IPv6，UseIPv4 或 UseIPv6 则用于明确限制。地址族设置应服从实际网络能力，而不是根据设备界面是否显示 IPv6 地址来判断。设备有本地 IPv6 地址，并不证明到目标网络的 IPv6 路由完整；反过来，仅为绕过一次超时而永久关闭整个系统的 IPv6，也可能影响其他正常应用。

当某些域名能解析却无法连接时，应比较返回地址族与出站可达性。若只在获得 IPv6 结果时失败，可以先在限定范围内测试 IPv4 解析，再检查本地路由、远端出口和服务端监听情况。若解析本身超时，则先验证 DNS 服务器的可达路径。不要把“解析出了地址”和“地址对应服务可用”当成同一件事；DNS 成功只能证明获得了回答，后续端口连接和安全握手仍需分别验证。

采用基于域名的 DNS 分流时，服务器对象可能包含匹配域名、期望 IP 范围和回退相关选项。它们的组合逻辑比简单服务器数组复杂，且不同内核的扩展字段存在差异。应先建立单一服务器的可用基线，再增加域名范围和回退条件。若一开始就同时加入多个分类、地址限制和回退开关，出现空回答时很难判断是上游不可达、回答被过滤，还是匹配条件没有覆盖当前目标。

加密 DNS 同样需要一条能够建立连接的网络路径。若解析某个上游主机需要先使用该上游，可能产生启动依赖；若代理节点地址也依赖同一条尚未建立的代理链路，问题会进一步叠加。配置前先画出“解析节点地址、连接节点、访问解析上游、解析业务域名”的顺序，确保没有互相等待的环节。不要把加密传输名称当成可达性的保证，实际仍受地址解析、路由和连接权限约束。

验证 DNS 更改时，还要处理缓存。系统、浏览器、应用和内核可能各自保存结果，已有连接也可能继续使用旧地址。优先用新建连接和明确测试域名观察日志，必要时按对应平台的正常操作清理缓存或重启应用。不要在不清楚缓存层级时连续改动多个服务器；这种做法容易让较早的设置恰好在较晚的测试中生效，形成错误结论。保留测试时间和当时配置，比单纯比较网页是否打开更有参考价值。

policy 策略：连接生命周期与统计条件

策略不是线路选择器

policy 调整连接处理和统计行为，不负责把某个域名分配给代理节点。常见结构包括按用户等级组织的 levels，以及全局系统统计设置 system。等级键以 JSON 字符串表示，例如 "0"；相关用户使用哪个等级，取决于其协议配置与内核解释。没有明确需要时，不必为了让配置看起来完整而增加多个等级。先保持默认行为，再针对日志中可复现的连接问题调整少量参数。

理解策略前，要区分握手阶段、正常传输阶段和单向结束阶段。握手超时针对初始协商，空闲超时针对一段时间没有活动的连接，而单向结束后的等待涉及另一方向的数据是否仍需要继续传递。把所有值都设得很小可能导致正常长连接被关闭；把所有值都放大也可能延长异常连接占用资源的时间。策略值并不是越大越稳定，应依据应用连接方式和实际故障现象选择。

等级策略与系统统计片段

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

片段中的时长按秒理解，用于展示字段组织，不是针对所有应用的调优建议。handshake 限制适用连接的握手等待，connIdle 约束空闲连接，uplinkOnly 和 downlinkOnly 涉及一个方向结束后的等待。具体生效范围应结合协议与内核实现确认。若调整后出现上传结束即中断下载、后台连接定期重建等现象，应先恢复原值，再根据连接日志缩小问题范围，而不是继续叠加更多策略。

统计开关与数据展示分开理解

启用统计开关并不代表客户端会立即显示所有数值。统计模块、查询接口以及客户端读取逻辑需要配合，用户级统计还与协议支持的用户标识等条件有关。示例显式关闭用户上下行统计，仅演示系统入站与出站统计开关。若客户端已经自动生成统计和接口配置，不要再盲目添加另一套同名模块；重复配置可能冲突，也可能让界面继续读取旧接口，从而出现内核已运行但显示区域没有变化的情况。

空闲连接与慢速连接也不是同一概念。连接仍持续传输少量数据时，是否被判定为空闲要看内核的活动判断；应用层心跳如何发送，也会影响连接维持情况。排查周期性断开时，应比较应用日志中的重连时间、内核关闭连接的原因与系统休眠记录。电脑进入睡眠、无线网络切换或移动端后台限制，都可能造成相似表现。仅看到连接在某个时间点中断，不能直接推断是 connIdle 设置不合适。

如果需要查询统计，应优先使用客户端已有的状态界面和受限本地接口。不要为了查看数字把管理接口暴露到所有网络接口；接口是否存在、监听在哪里以及谁能访问，都属于独立的安全边界。普通桌面使用不需要为了阅读本章而自行搭建远程管理入口。统计结果还可能在内核重启后重新开始，不能把客户端历史汇总与本次进程计数直接相减，进而推断配置丢失或连接绕过。

策略修改的合理流程是先描述现象，再选择字段，最后验证副作用。例如确认某个应用在空闲后被内核主动结束连接，才评估相关空闲等待；如果失败发生在认证阶段，则应回到出站参数检查。每次保存原值、修改值和测试条件，保持其他设置不变。需要回退时直接恢复整段已验证配置，比凭记忆逐个改回更可靠。策略属于后期细化，不应先于入站可达、出站可用和路由正确这三项基础条件。

客户端衔接：生成文件、订阅与内核切换

以客户端持久设置作为修改入口

v2rayN 是桌面端的主要选择，覆盖 Windows、macOS 和 Linux；Android 可按配置需求选择 v2rayNG 或 v2flyNG。安装入口统一在客户端下载页。这些客户端负责把节点、模式和路由选项组织成可运行配置，因此用户看到的界面结构不必与 JSON 一一对应。查阅本手册时，应先找到当前客户端提供的配置预览、日志或自定义配置功能，再判断某项修改应留在界面还是交给独立文件。

导入订阅后，客户端通常保存来源信息和节点列表，再依据当前选择生成运行配置。节点分组、过滤关键字和自动更新属于客户端层，不是通用的 routing 或 policy 字段。直接在内核文件里添加分组名称，不会让订阅列表自动归类；直接修改订阅生成的节点参数，也可能在下一次更新时被替换。长期调整应明确区分来源数据与本地覆盖，确保更新订阅不会悄悄改变正在验证的配置。

查看生成结果时核对四个对应关系

第一，界面中的当前节点是否对应实际出站。第二，系统代理或应用设置是否指向实际入站端口。第三，当前路由模式是否产生了预期规则和默认出站。第四，界面选择的内核是否与启动日志一致。完成这四项核对后，再深入检查协议参数。它们能解释许多“配置看起来正确但行为不符”的情况，例如节点已经切换，旧连接仍在使用原出口，或另一个后台实例仍占用系统代理所指向的端口。

{
  "inbounds": [
    {
      "tag": "local-http",
      "listen": "127.0.0.1",
      "port": 10809,
      "protocol": "http",
      "settings": {}
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    }
  ],
  "routing": {
    "rules": [
      {
        "type": "field",
        "inboundTag": ["local-http"],
        "outboundTag": "direct"
      }
    ]
  }
}

这个独立示例把 HTTP 入站明确映射到直连出站，展示界面端口与标签之间的对应关系，并非要求替换现有订阅。若客户端自定义配置模式会接管整份运行文件，应先确认该模式是否仍自动设置系统代理、更新端口或生成统计接口。不同功能入口的职责不同；一个用于追加路由的输入框，不应粘贴包含全部入站和出站的完整文件。保存前阅读入口说明，保存后查看实际生成结果，而不是仅确认界面提示成功。

切换内核与切换接管模式分别验证

Xray 与 V2Fly 的配置兼容性不能由共同字段名称完全推断。切换内核前，先确认协议和传输所需能力，再保留旧配置。切换后应重新启动并查看日志中的内核标识，接着核对生成配置是否改变。若使用自定义文件，客户端未必会自动把专属字段转换成另一分支支持的结构。出现未知字段或未知协议时，应先回退到原内核，确认基础连接恢复，再逐项建立兼容配置，而不是直接删除所有报错字段。

系统代理和 TUN 也应分别建立测试基线。先在不接管全部流量的条件下验证本地代理端口，然后启用系统代理测试遵循该设置的应用，最后才评估 TUN。TUN 可能需要额外权限、虚拟接口、路由和 DNS 设置，且能力取决于当前客户端及配套内核。若启用后局域网访问异常，应检查接管范围与私有网络规则；若只是某个应用不走系统代理，则不应先怀疑订阅损坏。

多个订阅源并存时，建议先整理来源和分组，再处理复杂自定义配置。这样可以在节点更新后快速辨认参数来源，也便于回退到已知可用的项目。具体整理方法见v2rayN 订阅分组与节点过滤。桌面权限问题则应回到平台安装路径处理，例如macOS 安装与网络权限说明。权限未获得时反复调整 JSON，通常无法改变系统拒绝网络接管的结果。

需要迁移设置时，应分开记录订阅来源、自定义规则和当前平台相关选项。不同平台的配置目录、文件权限及网络权限不同，不能直接复制一个绝对路径后假定可用。迁移完成先验证单个节点，再恢复路由和 DNS 扩展，最后检查接管模式。首次操作顺序仍以快速上手主线为准；本页提供字段解释，不替代客户端当前界面的操作说明。

验证与排错：从文件读取到目标连接

按失败阶段缩小范围

配置排错应沿启动、监听、接入、选路、解析和远端连接的顺序进行。内核没有启动时，网页结果不能说明路由对错；应用没有进入入站时，修改出站也没有验证意义。先打开客户端日志，重新启动一次内核，找到本次启动最早出现的错误，而不是从大量后续重试中随机挑一行。早期错误可能引发多个连锁提示，先修复第一个明确失败点，通常比同时处理所有警告更有效。

文件读取阶段重点检查 JSON 结构、字段类型与路径。报错提到某个字段附近时，错误也可能在它之前，例如上一行缺少逗号、字符串没有闭合或数组结束位置不对。不要只删除报错行；先把最外层对象与模块层级理清，再比较最近修改的部分。需要使用编辑器辅助检查时，应在本地处理包含节点信息的文件，不要把完整配置上传到不明确的数据处理页面，日志分享前也要去除地址和认证信息。

测试模式先于长期运行

自行管理内核文件时，可以先运行当前内核支持的配置测试命令。下例面向 Xray 的命令形式，要求系统能找到对应可执行程序，且工作目录中存在目标文件。V2Fly 的命令参数可能不同，应先查看本机程序帮助，不要把一个内核的参数原样套给另一个。图形客户端用户优先使用客户端日志与其提供的检查入口；没有独立维护内核的需求时，不必为了执行命令额外安装另一套运行环境。

xray run -test -config config.json

测试通过表示文件能够被当前程序接受，不代表远端可达，也不代表应用已使用代理。下一步检查端口监听是否成功。若出现地址已被占用，应确认是否存在重复客户端、旧内核进程或其他本地服务。不要为了避开冲突只在 JSON 中改端口，却忘记同步系统代理和应用设置；这种情况会让内核正常启动，但应用继续连接旧端口。端口变化后，应重新建立请求并核对入站日志。

用可观察日志验证链路

{
  "log": {
    "loglevel": "info"
  }
}

将日志级别临时调整为 info 可以增加运行信息，但实际可见内容取决于客户端如何捕获内核输出，以及是否另行配置访问日志。需要确认选路时，应观察客户端提供的连接记录或访问日志，区分入站标签、目标形式和出站标签。问题解决后恢复适合日常使用的日志级别。详细日志可能包含访问目标、设备地址和连接时间，不应长期无目的保存，也不应未经处理直接贴到公开讨论中。

若入站和路由都正确，再检查解析与远端握手。连接超时可能发生在访问远端端口，也可能发生在访问业务目标；认证失败、服务器名称不匹配与解析失败需要不同处理。对照日志中实际目标和发生阶段，不要仅凭“超时”两个字判断节点失效。若同一配置在不同网络表现不同，应记录网络切换、地址族和权限条件，保持配置本身不变进行比较，避免把网络差异与配置修改混在一次测试里。

逐项恢复是验证修复的最后一步。先用已知可用的最小配置完成一条连接，再加入目标出站，再加入一条路由，随后恢复 DNS 和策略扩展。每加一层都保存结果，出现异常时便能定位到最近变化。测试规则应覆盖预期命中和预期不命中两类目标，防止某条宽泛规则只是让单个网页可用，却把其余流量全部导向错误出口。已经建立的连接应结束后重试，确保新配置真正参与判断。

需要更细的日志阅读方法，可继续查看从日志定位 config.json 错误；重复出现的基础疑问可查阅常见问题，术语含义可回到术语手册。最终应保留一份经过验证的配置基线，并明确哪些部分由订阅更新、哪些部分由客户端生成、哪些部分由本地维护。后续升级或迁移先与基线比较，再判断是否需要调整字段，避免重新从整份文件猜测原因。