config.json 结构逐段解析:inbounds、outbounds 与 routing 各管什么

无论配置由 v2rayN 的订阅功能生成，还是由维护人员手工整理，核心结构都可以归纳为三个问题：流量从哪里进入、准备从哪里离开、匹配条件决定走哪一条出口。理解这三个问题后，排查“端口能连接但网页打不开”“直连域名仍然走代理”“拦截规则没有命中”等故障会更直接。

先建立完整流量链：入站、匹配、出站

应用不会直接“进入 routing”。浏览器或其他程序先把请求发送到本机监听端口，inbounds 接收连接并生成可供核心处理的目标信息；routing 再读取目标域名、目标 IP、端口、网络类型与入站标签；匹配成功后，规则里的 outboundTag 指向某个 outbounds 项。没有规则命中时，通常使用 outbounds 数组中的第一项作为默认出口，因此数组顺序同样属于配置逻辑。

可以把 config.json 看成一张有向连接图，而不是一组互不相关的参数。inbounds 中的 tag 用于标记流量来源，outbounds 中的 tag 用于命名出口，routing.rules 则引用这些名称完成连接。tag 本身不传输数据，也不会自动建立代理链；它只是核心内部稳定、区分大小写的引用键。

inbounds：定义本机怎样接收流量

inbounds 是入站数组，每一项代表一个监听入口。桌面端常见入口包括 SOCKS、HTTP 或由客户端管理的透明代理入口。最基础的 SOCKS 入站至少要明确 listen、port、protocol 与 settings。监听地址设为 127.0.0.1 时，仅允许本机程序访问；改成 0.0.0.0 会监听全部网络接口，局域网设备可能访问该端口，因此不能把两者当成等价写法。

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

逐字段读取入站配置

• tag：把该入口命名为 socks-in，后续规则可以通过 inboundTag 只处理来自这个入口的请求。
• listen：指定绑定地址。127.0.0.1 是本机回环地址，适合只供当前电脑使用的客户端配置。
• port：指定监听端口。示例使用 10808，浏览器或应用的 SOCKS5 代理端口也必须同步填写 10808。
• protocol：声明应用如何与本地核心通信。这里是 SOCKS，不代表远端节点也使用 SOCKS。
• settings.udp：允许 SOCKS 入站接收 UDP 请求。它只打开入站能力，最终是否可用还取决于远端协议、传输方式和目标应用。
• sniffing：从 HTTP 请求或 TLS 握手中恢复目标域名，让基于域名的分流规则有机会命中。

端口冲突发生在核心创建监听套接字时。如果 10808 已被另一个进程占用，inbounds 尚未开始接收流量，后面的 routing 与 outbounds 也不会执行。在 v2rayN 中可以进入「设置」→「参数设置」，调整本地 SOCKS 端口；修改为 10818 后，还要把浏览器代理、系统代理或其他应用中的端口同步改为 10818。

outbounds：定义代理、直连与拦截出口

outbounds 是出口数组。每个出口都要有唯一 tag，protocol 决定核心如何处理离站流量。远端代理出口包含服务器地址、端口、用户标识和传输参数；直连出口使用 freedom；主动终止连接的出口使用 blackhole。三者可以同时存在，再由 routing 选择具体出口。

{
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vmess",
      "settings": {
        "vnext": [
          {
            "address": "node.example.net",
            "port": 443,
            "users": [
              {
                "id": "11111111-1111-4111-8111-111111111111",
                "security": "auto"
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "ws",
        "security": "tls",
        "wsSettings": {
          "path": "/connection"
        }
      }
    },
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ]
}

上面的域名、用户标识与路径用于展示结构，不能替代订阅中的真实节点参数。VMess 的 settings 描述用户与服务器，streamSettings 描述传输层。即使地址和端口正确，只要 WebSocket 路径、TLS 设置或用户标识不一致，连接仍会失败。

routing：按条件把请求交给指定出口

routing 不负责创建监听，也不保存远端节点凭据。它的职责是读取请求特征并返回一个出站标签。rules 数组按照从上到下的顺序匹配，通常在第一条有效规则命中后停止继续查找。因此，应把范围小、优先级高的规则放在前面，把覆盖面大的兜底规则放在后面。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": [
          "geosite:category-ads-all"
        ],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "inboundTag": [
          "socks-in"
        ],
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

三条规则分别解决什么问题

1. 第一条读取 GeoSite 分类，匹配广告域名后交给 block。该规则依赖本地 GeoSite 数据能够被核心正常读取。
2. 第二条匹配私有 IP 范围并交给 direct，用于避免局域网地址绕到远端代理出口。
3. 第三条限定来源为 socks-in，并把剩余 TCP、UDP 请求交给 proxy。它的范围较大，所以放在精确规则之后。

domainStrategy 控制域名与 IP 规则之间的解析策略。AsIs 优先按原始域名进行匹配，不会为了所有 IP 规则主动解析域名；IPIfNonMatch 会先尝试域名规则，未匹配时再解析 IP 并继续检查 IP 规则；IPOnDemand 会在匹配过程中更积极地触发解析。普通分流配置常从 IPIfNonMatch 开始，既保留域名分类能力，也让私有 IP 等规则有机会生效。

tag 怎样把三段配置串成完整链路

tag 的关键要求是“定义存在、拼写一致、用途明确”。假设入站标签是 socks-in，三个出站标签分别为 proxy、direct 与 block，那么 routing 只能引用这四个已经定义的名称。把 outboundTag 写成 Proxy 或 proxy-main 都不会自动关联到 proxy。

inbounds[0].tag = "socks-in"
routing.rules[2].inboundTag = ["socks-in"]

outbounds[0].tag = "proxy"
routing.rules[2].outboundTag = "proxy"

outbounds[1].tag = "direct"
routing.rules[1].outboundTag = "direct"

outbounds[2].tag = "block"
routing.rules[0].outboundTag = "block"

按请求实际经过的顺序检查

1. 确认应用代理类型为 SOCKS5，地址是 127.0.0.1，端口与 inbounds.port 相同。示例端口为 10808。
2. 确认核心日志中没有“地址已被占用”或配置解析失败信息。监听失败时不要继续检查远端协议。
3. 确认请求来自预期入站。如果规则限制了 inboundTag，从另一个 HTTP 入站进入的请求不会命中该规则。
4. 按 routing.rules 的排列顺序寻找第一条匹配项，记录其 outboundTag。
5. 在 outbounds 中寻找完全同名的 tag，并检查对应 protocol、服务器地址、端口及 streamSettings。
6. 若没有任何规则命中，检查 outbounds 第一项是否确实是计划使用的默认出口。

如果要按来源区分策略，可以设置多个入站。例如 10808 的 socks-in 默认走 proxy，10818 的另一个 SOCKS 入站默认走 direct。此时两个入口必须使用不同 port 和不同 tag，再分别编写带 inboundTag 的规则。只复制一份入站却保留相同端口，会在启动阶段直接产生监听冲突。

修改配置时的安全步骤与常见问题

v2rayN 会根据当前节点、路由设置与核心选项生成运行配置。直接编辑生成文件可能只在当前进程周期内有效，切换节点、更新订阅或重启客户端后，文件可能再次生成。需要长期保留的路由逻辑，应优先在客户端提供的路由设置中维护；需要调整本地端口时，使用「设置」→「参数设置」，并同步所有调用该端口的应用。

• 修改前保存当前可用配置副本，每次只调整一个字段组。
• 编辑 JSON 后先检查逗号、引号、数组和对象闭合关系，再启动核心。
• 调整 outbounds 顺序时，记录第一项的 tag，因为它关系到未命中规则时的默认出口。
• 调整 routing.rules 时，从精确规则到宽泛规则排列，并逐条记录预期出口。
• 更新订阅后重新检查协议、传输、TLS、服务器端口与用户标识是否完整导入。
• 路由分类结果异常时，检查 GeoIP 与 GeoSite 数据是否能被当前核心读取。

读懂 config.json 的重点不是记忆全部字段，而是保持固定排查路径：入站是否监听、请求带着什么目标信息、哪条规则先命中、outboundTag 指向哪个出口、该出口能否完成连接。沿着这条链逐段验证，比同时修改端口、协议和路由更容易定位根因。