V2Ray config.json 逐段拆解:inbounds、outbounds 与 routing 怎么写

1. config.json 顶层结构与请求路径

config.json 是内核读取的配置文件名之一，不是固定的存储位置。v2rayN 等客户端可能生成临时运行配置；手动修改生成文件，下一次切换节点时可能被覆盖。先确认当前运行的是 Xray 还是 V2Fly，再查看实际加载的配置文件与启动日志。

inbounds 与 outbounds 都是数组，分别允许配置多个入口和出口。routing 是对象，其中的 rules 才是规则数组。tag 是配置内部引用的名字，不是服务器地址；规则通过 outboundTag 指向某个出站。

下面是仅用于本地直连测试的完整基础配置。它在回环地址开放 SOCKS 服务，所有未被规则处理的请求使用第一个出站 direct。这份配置没有远端代理节点，也不会自动修改系统代理。

{
  "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": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": []
  }
}

2. inbounds：监听地址、端口与本地协议

入站决定“应用怎样把流量交给内核”。上例中的 127.0.0.1:10808 是本机 SOCKS 入口，不是远端节点端口。浏览器、命令行工具或其他支持 SOCKS 的程序，需要明确使用这个入口，流量才会进入内核。

10808 和 10809 是本文选用的示例值，不是每个版本的固定默认值。将应用中的 HTTP 代理直接指向 SOCKS 端口，会造成协议不匹配。客户端如果提供混合入口，应以该入口的实际协议能力为准，不要由端口号猜测。

• listen: "127.0.0.1" 限制为本机访问，适合个人桌面测试。
• listen: "0.0.0.0" 会监听所有 IPv4 网卡。局域网共享还涉及认证与防火墙，不应仅改地址就开放。
• settings.udp: true 允许 SOCKS UDP 转发，但应用须支持 SOCKS5 UDP，后续出站与服务端也须支持相应流量。
• 系统代理是操作系统层面的入口设置，TUN 是虚拟网卡接管方式，两者都不等同于一个普通 SOCKS 入站。

用下面的命令检查应用是否能通过示例入口发起 HTTPS 请求。Windows 可使用 curl.exe，macOS 与 Linux 可使用 curl。其中 socks5h 表示把目标域名交给代理端处理；代理端最终怎样解析，还取决于配置。

curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 -I https://example.com

3. outbounds：远端节点与传输参数

出站决定“内核从哪里连接目标”。freedom 表示直连，blackhole 用于阻断，vmess 则需要远端服务端配合。入站可以是 SOCKS，出站可以是 VMess；它们不需要同名，因为服务的是连接链路的不同位置。

下面是替换顶层 outbounds 的演示片段。192.0.2.10 是文档示例地址，UUID 与域名也仅用于解释结构，不能直接连接。实际使用时，地址、端口、用户标识、传输与 TLS 参数必须取自已获授权的服务端配置，不能只替换其中一个字段。

{
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vmess",
      "settings": {
        "vnext": [
          {
            "address": "192.0.2.10",
            "port": 443,
            "users": [
              {
                "id": "b43b4b90-a710-4ee4-883d-b8c574099d11",
                "alterId": 0,
                "security": "auto"
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "tcp",
        "security": "tls",
        "tlsSettings": {
          "serverName": "proxy.example.net"
        }
      }
    },
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ]
}

v2rayNG 使用 Xray 内核，v2flyNG 使用 V2Fly 内核；v2rayN 的可用内核以实际安装与选择为准。相似的顶层结构不代表扩展字段完全兼容，尤其是 VLESS 的特定安全组合。本文的 TCP 字段写法用于解释常见配置，实际字段名称与兼容性应结合所装内核版本核对。

4. routing：规则顺序、标签引用与默认出口

路由不是把几个域名分组后自动生效，而是按顺序检查规则。通常先命中的规则决定出口；一条规则中的不同条件需要同时满足，同一条件数组内的多个值则表示可选匹配项。outboundTag 必须与现有出站的 tag 精确一致。

下面的片段依赖上一节的 proxy、direct、block 三个出站。它先阻断一个演示域名，再让私有地址直连，最后将其余流量交给代理。两个域名都只是规则示例，不代表实际访问建议。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["full:blocked.example.org"],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "ip": ["10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["domain:example.org"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

1. full:blocked.example.org 只匹配该完整域名。它虽然也属于 example.org 的子域名，但阻断规则靠前，因此优先阻断。
2. 私有网段规则处理目标 IP 落入相应范围的请求。它不是一份完整的特殊地址清单，也不自动涵盖 IPv6 本地地址。
3. domain:example.org 匹配该域名及其子域名，不等同于任意字符串包含。
4. 最后的 network: "tcp,udp" 是本例的兜底规则，必须放在具体规则之后，否则前面的分流意图可能被提前截走。

如果没有任何规则命中，通常使用 outbounds 数组的第一个出站。第一节的第一个出站是 direct，第三节改成了 proxy，因此仅调整数组顺序也可能改变默认行为。不要用“数组里有代理节点”来判断所有请求都经过代理。

5. dns、日志与客户端生成配置的边界

routing.domainStrategy 控制路由匹配阶段如何处理域名，不是 DNS 服务器地址，也不是完整的 DNS 分流策略。AsIs 尽量保留原目标进行匹配；IPIfNonMatch 在域名规则未匹配时尝试解析后继续检查 IP 规则；IPOnDemand 则可能在检查 IP 规则时触发解析。

下面的片段仅增加内置 DNS 设置，不会自动修改操作系统 DNS，也不保证每个应用的查询都进入内核。若应用在连接前已完成本地解析，内核可能只收到 IP；若使用代理协议传递域名，最终解析位置还可能由出站和服务端决定。

{
  "dns": {
    "servers": ["localhost"]
  }
}

• 订阅：是客户端获取节点资料的入口，不是可以直接写进 outbounds 的通用内核字段。
• 系统代理：告诉遵循系统代理设置的应用使用本地入口，不代表所有进程都被接管。
• TUN：由客户端及其网络组件协同管理，不能把界面中的 TUN 开关直接翻译成一个通用 JSON 字段。
• 日志：排查时可将 log.loglevel 暂时改为 info，重新加载后复现一次；完成后再恢复 warning。

阅读客户端导出的配置时，先定位 inbounds[].port、outbounds[].tag 和 routing.rules，再追踪 DNS 与传输细节。不要直接删除不认识的管理入口或附加字段；它们可能服务于客户端统计、控制接口或运行时功能。分享日志前也应移除用户标识、订阅地址和服务器资料。

6. 配置修改后的检查顺序与常见问题

修改前保留一份可恢复的配置，每次只改一个层面。先验证 JSON 和内核字段，再确认端口监听，最后测试远端连接与规则命中。下面的检查命令适用于提供相应命令行接口的较新内核；实际参数以已安装程序的帮助输出为准，客户端托管配置应使用它实际加载的文件路径。

xray run -test -config config.json
v2ray test -c config.json

测试命令通过，不代表节点可用。它主要检查配置能否被当前内核接受，不会替代远端认证、TLS 握手和目标访问测试。若内核能启动但应用仍连接失败，应沿“本地入口、远端出口、路由结果”的顺序缩小范围。