Sing-box 高级配置实战手册

一 为什么传统分流引擎在复杂网络环境下失效

分流引擎的设计目标始终围绕一个核心命题展开，即在尽可能短的时间内对每一条连接做出准确的出站决策。早期基于规则列表的引擎在规则规模较小、网络拓扑简单的年代表现尚可，但当规则集膨胀到数万条、协议栈扩展到多路复用与 UDP 转发、终端环境横跨移动端与软路由时，传统引擎的结构性缺陷便集中暴露。本章从五个维度拆解这些失效模式，为后续章节引入 Sing-box 的新架构建立问题基线。

1.1 域名匹配与 IP 匹配的时序冲突

传统引擎在一条连接的生命周期内通常只做一次决策，决策依据要么是域名要么是目的 IP。问题在于这两类信息在时间轴上并不同步。以一次 HTTPS 访问为例，客户端先发起 DNS 查询拿到 IP，再向该 IP 发起 TCP 握手，TLS 握手完成后才能通过 SNI 拿到域名。若引擎在 TCP 握手阶段就依据 IP 做出直连决策，后续即使嗅探出域名属于代理规则集也无法回溯改写路由结果。反之若引擎等待 SNI 再决策，则首包已被延迟。这种时序冲突在 CDN 场景下尤为严重，同一 IP 可能承载数百个域名，其中既有需要直连的国内站点也有需要代理的境外站点，纯 IP 匹配必然误判。

1.2 规则线性遍历带来的首包延迟放大

多数传统引擎采用数组顺序遍历的匹配方式，规则数量与单次匹配耗时呈线性关系。当规则集达到 5 万条量级时，单条连接的平均匹配耗时可达数百微秒，叠加 DNS 查询、TLS 握手后首包延迟被显著放大。更关键的是这种开销发生在每一条新建连接上，对于浏览器并发加载数十个资源的场景，累计延迟足以让页面可交互时间翻倍。线性遍历还带来一个隐性成本，即规则顺序的微小调整可能引发命中率剧烈波动，运维人员不得不反复调优规则排列。

1.3 GeoIP 数据库陈旧导致的误判链路

GeoIP 判定依赖本地数据库文件，而 IP 段的归属变更频繁发生。云厂商的弹性 IP 池、CDN 的任播地址、跨境专线的中转段都会让数据库在数周内失真。一旦某段 IP 从境外划归境内而数据库未更新，引擎会将该段流量错误地送入代理出站，造成不必要的跨境绕行。反之境内 IP 被误判为境外则直接导致访问失败。传统引擎缺乏对 GeoIP 判定结果的置信度标注，运维人员难以定位是哪一段 IP 引发了误判。

1.4 DNS 泄漏与分流决策的耦合缺陷

分流决策依赖域名，域名依赖 DNS 解析，而 DNS 查询本身也需要分流。传统引擎往往把 DNS 查询与业务连接放在同一套规则下处理，导致两个后果。其一是 DNS 查询走了代理但业务连接走了直连，或者反过来，形成决策不一致。其二是本地 DNS 查询在系统层面直接发出，绕过了引擎的规则，真实域名暴露给本地运营商。这种耦合缺陷在双栈网络下进一步放大，AAAA 查询与 A 查询可能走不同的路径。

1.5 多协议共存下的规则优先级混乱

当引擎同时承载 VLESS、Hysteria 2、TUIC、WireGuard 等多种出站协议时，每条连接需要先选定协议再选定具体节点。传统引擎通常把协议选择与节点选择混在同一张规则表里，规则之间缺乏明确的优先级语义。运维人员很难表达"国内域名走直连、流媒体走 Hysteria 2 的香港节点、其余走 VLESS 的日本节点"这类多层意图，规则冲突时只能靠排列顺序碰运气。

flowchart TD
    A["客户端发起连接"] --> B["DNS 查询阶段"]
    B --> C{"DNS 走本地还是远程"}
    C -->|"本地"| D["运营商 DNS 返回 IP"]
    C -->|"远程"| E["加密 DNS 返回 IP"]
    D --> F["TCP 握手 依据 IP 匹配"]
    E --> F
    F --> G{"IP 规则命中"}
    G -->|"命中直连"| H["直连出站 域名信息丢失"]
    G -->|"命中代理"| I["代理出站"]
    H --> J["TLS 握手 嗅探 SNI"]
    J --> K{"SNI 与 IP 判定冲突"}
    K -->|"冲突"| L["无法回溯 决策失效"]
    K -->|"一致"| M["连接建立"]
    I --> M

二 Sing-box 新一代分流引擎的架构解析

Sing-box 的分流架构与传统引擎的根本差异在于把入站、路由、DNS、出站四个模块彻底解耦，每个模块只负责单一职责，模块之间通过明确定义的数据结构通信。这种设计让决策可以在连接生命周期的多个时间点分别进行，避免了单点决策的时序冲突。

2.1 路由模块与入站出站解耦设计

在 Sing-box 中，入站负责接收流量并完成协议解析与嗅探，路由模块负责依据连接元数据选择出站，出站负责实际的协议封装与传输。三者之间不共享状态，路由模块只读取入站填充的连接元数据（目的地址、嗅探域名、进程名、用户 ID 等），只输出出站标签。这种解耦带来的直接好处是路由规则可以独立于协议配置进行版本管理，更换出站协议不需要改动路由表，调整路由规则也不需要触碰入站参数。

2.2 Rule Set 二进制格式 SRS 的加载机制

Sing-box 引入 SRS 作为规则集的编译格式。SRS 在构建阶段就把域名后缀、关键词、正则、IP CIDR 等规则预编译为紧凑的二进制结构，加载时通过内存映射直接读取，无需逐条解析文本。加载完成后规则以匹配树的形式驻留内存，单条规则的匹配退化为若干次哈希查找与位比较。相比逐行解析 JSON 或 YAML，SRS 的冷启动时间可降低一个数量级，这对软路由这类 CPU 较弱的设备意义重大。

2.3 规则匹配树与短路求值原理

规则在内存中按类型分层组织，域名规则进入域名匹配树，IP 规则进入前缀树，进程规则进入哈希表。匹配时引擎按规则集在路由配置中的声明顺序依次查询各棵树，一旦某条规则命中且其目标出站已确定，立即短路返回，不再查询后续规则集。短路求值让高频命中的规则集可以前置，低频规则集后置，整体匹配复杂度从线性降为近似常数。

2.4 DNS 模块独立于路由的决策流

DNS 模块拥有独立的服务器分组与匹配规则，不依赖路由模块的决策。一次 DNS 查询先由 DNS 规则选定上游服务器，再发起查询，查询结果可以选择性地写回路由模块的域名映射表。这种独立设计让 DNS 查询与业务连接可以走不同的出站，例如 DNS 查询走 DoH 直连而业务连接走代理，从而避免 DNS 泄漏同时不引入额外延迟。

2.5 内存占用与规则规模的非线性关系

SRS 的内存占用与规则数量并非严格线性。域名后缀规则因共享前缀可以大幅压缩，正则规则因需要保留状态机而占用较高，IP 前缀树在 CIDR 聚合良好时占用极低。实测表明 10 万条域名后缀规则经 SRS 编译后常驻内存约 8 至 12 MB，而同等规模的 JSON 规则在解析阶段峰值内存可达数百 MB。这一特性决定了软路由的容量规划应以 SRS 编译后体积为准而非源文件体积。

flowchart TD
    subgraph 入站层
        I1["TUN 入站"]
        I2["Mixed 入站"]
        I3["Sniff 嗅探填充元数据"]
    end
    subgraph 路由层
        R1["域名匹配树"]
        R2["IP 前缀树"]
        R3["进程哈希表"]
        R4["短路求值器"]
    end
    subgraph DNS层
        D1["DNS 规则匹配"]
        D2["上游服务器分组"]
        D3["缓存与 FakeIP"]
    end
    subgraph 出站层
        O1["VLESS 出站"]
        O2["Hysteria 2 出站"]
        O3["直连出站"]
    end
    I1 --> I3
    I2 --> I3
    I3 --> R1
    I3 --> R2
    I3 --> R3
    R1 --> R4
    R2 --> R4
    R3 --> R4
    D1 --> D2
    D2 --> D3
    D3 --> R1
    R4 --> O1
    R4 --> O2
    R4 --> O3

三 Rule Set 规则集的技术原理与格式选型

规则集是分流决策的知识库，其格式选型、版本管理、合并策略直接决定了引擎的准确性与可维护性。Sing-box 同时支持源格式与编译格式，理解两者的差异是工程落地的前提。

3.1 源格式 JSON 与编译格式 SRS 的差异

源格式采用 JSON 描述规则条目，可读性好便于人工编辑与代码审查，但加载时需要逐条解析并构建匹配结构，冷启动开销大。编译格式 SRS 是源格式经 sing-box rule-set compile 命令转换后的二进制产物，加载时直接映射为内存结构，冷启动极快但不可人工编辑。工程实践中源格式用于版本管理与审查，SRS 用于生产部署，两者通过 CI 流水线关联。

{
  "version": 3,
  "rules": [
    {
      "domain_suffix": [".cn", ".com.cn", ".gov.cn"],
      "domain_keyword": ["baidu", "taobao", "weixin"],
      "domain_regex": ["^api\\..*\\.qq\\.com$"]
    },
    {
      "ip_cidr": ["10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16"],
      "source_ip_cidr": ["192.168.1.0/24"]
    }
  ]
}

上述源格式中 domain_suffix 匹配后缀，domain_keyword 匹配子串，domain_regex 匹配正则，ip_cidr 匹配目的 IP 段，source_ip_cidr 匹配来源网段。编译为 SRS 后这些字段被折叠为匹配树节点，正则被编译为状态机。

3.2 远程规则集的版本管理与缓存策略

生产环境通常从远程 URL 拉取规则集，Sing-box 支持为每个远程规则集配置 update_interval 与本地缓存路径。合理的策略是设置较短的更新间隔（例如 24 小时）并启用本地缓存，使引擎在远程不可达时回退到缓存副本。缓存文件应放在持久化目录，容器化部署时需挂载独立卷，避免容器重建后缓存丢失导致冷启动。

{
  "route": {
    "rule_set": [
      {
        "tag": "geosite-cn",
        "type": "remote",
        "format": "binary",
        "url": "https://example.com/geosite-cn.srs",
        "download_detour": "direct",
        "update_interval": "24h",
        "path": "/var/lib/sing-box/geosite-cn.srs"
      }
    ]
  }
}

download_detour 指定下载规则集时使用的出站，设为直连可避免规则集更新本身走代理造成循环依赖。path 指定缓存位置，update_interval 控制刷新频率。

3.3 规则集合并与去重的工程方法

多个规则集之间常有重叠，例如 geosite-cn 与自定义国内域名集可能同时包含 .cn 后缀。合并时应先去重再编译，避免匹配树中出现冗余节点。工程上可用脚本读取各源格式 JSON，按 domain_suffix、domain_keyword、ip_cidr 分别求并集，再输出合并后的源格式供编译。去重后规则集体积通常可缩减 15% 至 30%，匹配树深度也随之降低。

3.4 自定义规则集的编写规范

自定义规则集应遵循三条规范。第一按业务域拆分，例如流媒体、办公协作、开发工具各成一个规则集，便于独立更新与灰度。第二避免在自定义集中重复公共规则集的内容，只写增量。第三正则规则控制在必要范围内，正则匹配开销远高于后缀匹配，能用后缀表达的不写正则。

3.5 规则集更新频率与失效风险控制

规则集更新存在两类风险。其一是远程源不可达导致更新失败，引擎回退缓存后规则可能陈旧。其二是远程源内容异常（例如误将大量国内域名加入代理集）导致分流错误。控制手段包括为每个远程规则集配置健康检查、在 CI 中对更新后的规则集做抽样校验、以及保留上一版本缓存以便快速回滚。

四 DNS 分流的核心机制与解析链路设计

DNS 是分流决策的信息源头，DNS 链路设计不当会让后续所有路由规则失去意义。Sing-box 的 DNS 模块提供了服务器分组、策略路由、FakeIP、加密传输等完整能力，本章逐项拆解。

4.1 DNS 服务器分组与策略路由

DNS 服务器按用途分组，常见分组包括本地运营商 DNS、国内公共 DoH、境外 DoH、以及 FakeIP 专用服务器。每个分组有独立标签，DNS 规则依据域名选择分组。策略路由的核心是把"查询哪个域名"映射到"用哪组服务器解析"，例如国内域名用国内 DoH，境外域名用境外 DoH，未知域名走兜底分组。

{
  "dns": {
    "servers": [
      {
        "tag": "dns-local",
        "address": "223.5.5.5",
        "detour": "direct"
      },
      {
        "tag": "dns-remote",
        "address": "https://1.1.1.1/dns-query",
        "detour": "proxy",
        "address_resolver": "dns-local"
      },
      {
        "tag": "dns-fakeip",
        "address": "fakeip"
      }
    ],
    "rules": [
      {
        "domain_suffix": [".cn"],
        "server": "dns-local"
      },
      {
        "rule_set": "geosite-cn",
        "server": "dns-local"
      },
      {
        "query_type": ["A", "AAAA"],
        "server": "dns-fakeip"
      }
    ],
    "final": "dns-remote"
  }
}

address_resolver 指定解析 DoH 服务器域名时使用的上游，避免 DoH 服务器域名本身需要远程解析造成的循环。final 指定兜底分组。

4.2 本地 DNS 与远程 DNS 的分流边界

本地 DNS 延迟低但明文传输且暴露查询内容，远程 DNS 加密但延迟高。合理边界是国内域名走本地或国内 DoH，境外域名走远程 DoH。判断依据是域名后缀与规则集，而非 IP，因为 IP 在查询阶段尚不可知。边界划分错误会导致两类问题，国内域名走远程 DoH 增加延迟，境外域名走本地 DNS 造成泄漏。

4.3 FakeIP 模式的工作原理与适用场景

FakeIP 模式为每个查询域名分配一个保留网段的虚拟 IP（默认 198.18.0.0/15），客户端拿到虚拟 IP 后发起连接，引擎在 TUN 层拦截该连接并依据虚拟 IP 反查真实域名，再用真实域名做路由决策。FakeIP 的优势是彻底消除 DNS 查询对首包延迟的影响，因为客户端无需等待真实解析即可发起连接。适用场景是 TUN 模式下的浏览器访问，不适用于需要真实 IP 做证书校验或直连的场景。

4.4 DNS over HTTPS 与 DNS over TLS 的接入配置

DoH 与 DoT 都是加密 DNS 传输方式，DoH 走 443 端口伪装为 HTTPS 流量，DoT 走 853 端口。Sing-box 中 DoH 以 https:// 前缀声明，DoT 以 tls:// 前缀声明。配置时需为加密 DNS 服务器指定 detour，通常走代理出站以避免本地运营商干扰，同时用 address_resolver 指定解析该服务器域名时使用的本地 DNS。

# 验证 DoH 服务器可达性与响应时间
curl -w "dns_lookup %{time_namelookup} connect %{time_connect} total %{time_total}\n" \
  -H "accept: application/dns-json" \
  "https://1.1.1.1/dns-query?name=example.com&type=A"

# 验证 DoT 握手与证书链
openssl s_client -connect 1.1.1.1:853 -servername cloudflare-dns.com -brief

上述命令用于在部署前验证加密 DNS 服务器的可达性与握手耗时，避免配置错误导致 DNS 链路整体失效。

4.5 DNS 缓存与 TTL 处理策略

Sing-box 内置 DNS 缓存，缓存条目遵循上游返回的 TTL，同时支持配置最小与最大 TTL 覆盖。过短的 TTL 会让缓存失效频繁，过长的 TTL 会让 IP 变更后客户端仍指向旧地址。工程上通常设置最小 TTL 为 60 秒、最大 TTL 为 3600 秒，并在 FakeIP 模式下为虚拟 IP 映射设置独立的长缓存，避免映射频繁重建。

4.6 域名嗅探与 DNS 决策的协同

嗅探在连接建立后从 TLS ClientHello 或 HTTP Host 头中提取域名，填充到连接元数据供路由使用。嗅探与 DNS 决策的协同体现在两个方向。其一 DNS 阶段已解析的域名可写入映射表，嗅探阶段直接复用避免重复解析。其二嗅探出的域名若与 DNS 阶段的判定冲突，路由模块以嗅探结果为准，因为嗅探来自实际流量而非查询意图。协同配置的关键是开启 sniff 并在入站层设置 sniff_override_destination，让嗅探结果可以覆盖目的地址。

sequenceDiagram
    participant C as "客户端"
    participant S as "Sing-box DNS 模块"
    participant U as "上游 DNS 分组"
    participant T as "TUN 入站"
    participant R as "路由模块"
    C->>S "查询 example.com A 记录"
    S->>S "匹配 DNS 规则选定分组"
    S->>U "转发查询至选定上游"
    U-->>S "返回真实 IP 或 FakeIP"
    S-->>C "返回解析结果"
    C->>T "向解析结果发起连接"
    T->>T "嗅探 TLS SNI 提取域名"
    T->>R "提交元数据 目的地址 嗅探域名"
    R->>R "域名匹配树查询 短路求值"
    R-->>T "返回出站标签"
    T->>T "按出站标签转发连接"

案例 1 规则集远程加载超时导致全量流量走直连

某企业旁路由部署 Sing-box 后，运维人员发现所有境外流量均走直连，代理出站完全未被使用。排查日志发现启动阶段远程规则集 geosite-cn.srs 与 geosite-geolocation-!cn.srs 均加载超时，路由模块因规则集缺失导致所有域名规则失效，仅剩兜底规则生效，而兜底规则被配置为直连出站。根因是规则集 URL 指向的 CDN 在启动时段不可达，且未配置本地缓存回退。修复方案为每个远程规则集配置 path 本地缓存、设置 download_detour 为直连、并将兜底出站改为代理出站以在规则集缺失时仍能保障境外访问。修复后再次模拟远程不可达，引擎正确回退缓存副本，分流恢复正常。

案例 2 FakeIP 缓存污染引发特定域名解析异常

某用户在 TUN 模式下启用 FakeIP 后，访问某国内办公系统时持续报证书错误。抓包发现该域名被解析为 198.18.x.x 虚拟地址，但该域名属于国内直连规则集，连接被 FakeIP 拦截后反查域名失败，导致连接被错误地送入代理出站，代理出站返回的证书与目标域名不匹配。根因是 FakeIP 规则未排除国内域名，且 FakeIP 映射表在引擎重启后未持久化，反查时映射已丢失。修复方案为在 DNS 规则中把国内域名规则集前置到 FakeIP 规则之前，并为 FakeIP 映射启用持久化存储，同时在路由层为 FakeIP 网段配置专用出站以处理反查失败的兜底连接。

案例 3 TUN 模式 MTU 设置不当造成大包分片丢包

某软路由 TUN 入站 MTU 默认设为 9000，用户在访问境外视频站点时出现画面卡顿与部分分片加载失败。抓包显示大尺寸 TLS 记录被分片后部分分片丢失，TCP 重传率显著上升。根因是 TUN 虚拟网卡 MTU 远大于底层物理链路 MTU，引擎未做路径 MTU 发现，大包在物理链路被分片后丢包。修复方案为将 TUN 入站 MTU 设为 1420（为底层 1500 减去 PPPoE 与隧道封装开销预留余量），并在出站启用 TCP 快速打开与合适的拥塞控制算法，重传率恢复正常，视频加载流畅。

# 查看 TUN 接口 MTU 与底层物理接口 MTU
ip link show tun0
ip link show eth0

# 测试到目标的最大不分片包尺寸
ping -M do -s 1400 -c 3 203.0.113.10

# 调整 TUN 接口 MTU
ip link set dev tun0 mtu 1420

上述命令用于定位 MTU 不匹配问题，-M do 禁止分片，逐步调整 -s 值可测出路径 MTU，据此设定 TUN 接口 MTU 以预留封装开销。

常见问题 1 Sing-box 的 Rule Set 规则集是什么

Sing-box 的 Rule Set 规则集是一组预定义的匹配条件集合，包含域名后缀、域名关键词、域名正则、IP CIDR、来源 IP CIDR、进程名等条目，以源格式 JSON 或编译格式 SRS 存储。路由模块通过引用规则集标签把大量匹配条件组织为可复用、可独立更新、可远程加载的单元，避免在路由配置中内联海量规则。

常见问题 2 Sing-box 的 DNS 分流如何避免泄漏

Sing-box 通过三方面避免 DNS 泄漏。第一 DNS 模块独立于系统 DNS，所有查询经引擎规则选定上游，境外域名强制走加密 DoH 或 DoT。第二 TUN 模式下劫持全部 53 端口流量进入 DNS 模块，阻止应用绕过引擎直发查询。第三为加密 DNS 服务器指定 detour 走代理出站，并用 address_resolver 指定本地解析其域名，防止解析链路自身泄漏。

常见问题 3 Sing-box 的 TUN 模式与系统代理有何区别

TUN 模式创建虚拟网卡并接管系统路由表，所有 IP 层流量进入引擎，可处理 UDP、ICMP 与不遵循系统代理设置的应用。系统代理模式仅在应用主动读取代理环境变量或系统代理配置时生效，UDP 与部分原生应用无法覆盖。TUN 模式的吞吐略低于系统代理但覆盖完整，系统代理开销低但存在覆盖盲区。

常见问题 4 SRS 格式相比 JSON 规则集有何优势

SRS 是规则集的编译格式，加载时直接映射为内存匹配树，冷启动时间相比逐条解析 JSON 降低一个数量级。SRS 体积远小于源格式，10 万条域名规则编译后常驻内存约 8 至 12 MB。SRS 不可人工编辑，适合作为生产部署产物，源格式 JSON 保留用于版本管理与审查。

常见问题 5 Sing-box 如何实现应用程序级别的分流

Sing-box 在入站层通过 process_name 与 process_path 填充连接元数据，路由模块的进程哈希表依据元数据匹配规则并选定出站。该能力在桌面端与部分支持进程信息采集的平台上可用，移动端受系统限制通常不可用。配置时在路由规则中声明 process_name 列表并指定目标出站即可实现按应用分流。

常见问题 6 Sing-box 配置生成有哪些关键参数

关键参数包括入站的 type、listen、sniff、sniff_override_destination，出站的 type、server、server_port、tls、multiplex，DNS 的 servers、rules、final、fakeip 网段，路由的 rules、rule_set、final、auto_detect_interface。生成配置时应确保 DNS 规则与路由规则的域名判定一致，兜底出站具备可用性，远程规则集配置本地缓存。

常见问题 7 Sing-box 规则集更新失败如何排查

排查顺序为四步。第一检查远程 URL 可达性与证书有效性。第二检查 download_detour 指定的出站是否可用，避免下载链路自身依赖待更新规则集造成循环。第三检查本地缓存路径的写权限与磁盘空间。第四查看引擎日志中规则集加载的错误码，区分网络超时、格式错误与版本不兼容。修复后应验证缓存副本已更新且路由规则集标签引用一致。

五 TUN 模式底层原理与系统集成

TUN 虚拟网卡是 Sing-box 接管系统流量的物理基础。理解数据包从网卡驱动到用户态进程的完整路径，是排查吞吐瓶颈与丢包问题的前提。

5.1 TUN 虚拟网卡的数据包流转路径

TUN 设备工作在 OSI 三层，内核将 IP 数据包直接写入字符设备，用户态进程读取后完成协议解析与转发。完整路径如下

应用进程 write() → 内核协议栈路由决策 → TUN 设备队列 → Sing-box 用户态读取
→ 规则匹配 → 出站封装 → 物理网卡 send() → 远端服务器

关键点在于内核协议栈的路由决策发生在数据包进入 TUN 之前。若系统路由表未正确注入，数据包会走物理网卡直连，TUN 完全收不到流量。Sing-box 启动时通过 auto_route 自动注入默认路由与策略规则，将目标流量导向 TUN 设备。

5.2 路由表注入与策略路由配置

Linux 下 Sing-box 依赖 iproute2 完成路由注入。核心操作包括创建独立路由表、添加默认路由指向 TUN、设置 fwmark 规则避免回环。以下为手动验证路由注入的脚本

#!/bin/bash
# 查看 Sing-box 创建的 TUN 设备与路由表
ip link show | grep -i tun
ip rule show | grep -E "fwmark|lookup"
ip route show table all | grep -E "tun|default"

# 验证特定目标 IP 的实际出口
ip route get 8.8.8.8
# 输出应显示 dev sing-tun 而非物理网卡

# 检查 fwmark 是否生效 防止代理流量回环
nft list ruleset | grep -A5 "mark"

auto_route 开启后 Sing-box 会自动处理上述逻辑，但旁路由场景下需手动指定 route_address 与 route_exclude_address 避免内网流量被劫持。

5.3 Windows 与 Linux 下的 TUN 差异

Windows 下 wintun 驱动版本与 Sing-box 版本需匹配，否则出现设备创建成功但无流量通过的静默故障。

5.4 与系统代理模式的性能对比

系统代理模式仅接管遵循系统代理设置的应用，TUN 模式在网络层接管全部流量。性能差异体现在三处。系统代理需应用层解析 HTTP CONNECT，TUN 在内核层截获原始 IP 包。系统代理对 UDP 支持依赖 SOCKS5，TUN 原生支持 UDP。系统代理的 DNS 解析由应用自行发起易泄漏，TUN 可强制劫持 53 端口。

5.5 TUN 模式下的 DNS 劫持与防泄漏

TUN 模式下 DNS 泄漏的根源是应用绕过系统 DNS 直连外部解析器。Sing-box 通过 dns_hijack 将发往任意地址的 53 端口流量重定向至内置 DNS 模块。配置片段如下

{
  "inbounds": [
    {
      "type": "tun",
      "inet4_address": "172.19.0.1/30",
      "auto_route": true,
      "strict_route": true,
      "sniff": true,
      "sniff_override_destination": false,
      "domain_strategy": "prefer_ipv4"
    }
  ],
  "dns": {
    "servers": [
      { "tag": "remote", "address": "https://1.1.1.1/dns-query", "detour": "proxy" },
      { "tag": "local", "address": "223.5.5.5", "detour": "direct" }
    ],
    "rules": [
      { "geosite": ["cn"], "server": "local" }
    ],
    "final": "remote"
  }
}

strict_route 在 Linux 下额外注入防火墙规则阻断绕过 TUN 的流量，是防泄漏的关键开关。

六 入站配置调优实战

入站配置决定流量进入 Sing-box 的方式与初始处理逻辑。参数选择直接影响吞吐、延迟与兼容性。

6.1 TUN 入站的 MTU 与栈类型选择

MTU 设置需匹配底层物理链路。以太网标准 1500，PPPoE 拨号环境实际可用 1492，部分移动网络低至 1400。MTU 过大导致分片丢包，过小增加协议头开销。推荐值 1400 至 1420 区间兼顾兼容性与效率。

栈类型三选一。system 使用内核协议栈性能最高但功能受限。gvisor 用户态实现功能完整但吞吐略低。mixed 混合模式在 Linux 下兼顾两者。高吞吐场景选 system，需要完整 UDP 与 ICMP 支持选 gvisor。

6.2 Mixed 入站的协议复用配置

Mixed 入站同时监听 HTTP 与 SOCKS5，通过首字节特征自动识别协议。配置示例

{
  "type": "mixed",
  "tag": "mixed-in",
  "listen": "127.0.0.1",
  "listen_port": 2080,
  "sniff": true,
  "sniff_override_destination": true,
  "users": []
}

sniff_override_destination 开启后嗅探到的域名会覆盖原始目标地址，使域名规则生效。该参数在目标为 IP 直连但实际访问域名的场景下至关重要。

6.3 入站嗅探参数的精细化设置

嗅探模块支持 http、tls、quic 三类协议识别。tls 嗅探提取 SNI，quic 嗅探提取 Initial 包中的 SNI。对 QUIC 流量嗅探需确保 udp 转发链路完整。嗅探超时默认 300ms，高延迟链路可适当放宽至 500ms 避免误判为直连。

6.4 多用户入站与流量隔离

多用户场景通过 users 数组为每个用户分配独立 UUID 与流量统计标签。结合 clash_api 的 /connections 接口可按用户维度统计流量。隔离依赖出站侧的 routing_mark 或独立出站绑定，确保用户流量不交叉。

6.5 入站连接超时与并发控制

tcp_fast_open 开启可降低握手延迟。detour 参数可将入站流量预路由至指定出站。并发控制依赖系统 ulimit 与 Sing-box 的 max_connections 参数，高并发场景需同步调高文件描述符上限。

七 出站配置调优实战

出站配置决定流量的最终出口与封装方式，是跨境链路质量的核心变量。

7.1 VLESS 与 Hysteria 2 出站的参数调优

VLESS 依赖 TCP 或 WebSocket 传输，参数调优集中在 flow 与 packet_encoding。xtls-rprx-vision 流控可减少 TLS 握手开销。Hysteria 2 基于 QUIC，参数调优集中在 up_mbps、down_mbps 与 obfs。带宽参数需如实填写，虚报会导致拥塞控制失准。

{
  "type": "hysteria2",
  "tag": "hy2-out",
  "server": "example.com",
  "server_port": 443,
  "up_mbps": 50,
  "down_mbps": 200,
  "obfs": { "type": "salamander", "password": "secret" },
  "tls": { "enabled": true, "server_name": "example.com" }
}

7.2 出站复用与多路复用配置

多路复用将多条逻辑连接复用至单条物理连接，降低握手开销。multiplex 配置中 protocol 选 h2mux 或 smux，max_streams 控制单连接并发流数。高延迟链路建议开启，低延迟链路开启反而增加队头阻塞风险。

7.3 出站健康检查与故障切换

urltest 出站组通过周期性探测自动选择最低延迟节点。探测间隔与容差参数需匹配链路稳定性。fallback 组在主节点不可用时切换备用节点。配置示例

{
  "type": "urltest",
  "tag": "auto",
  "outbounds": ["hk-01", "jp-01", "sg-01"],
  "url": "https://www.gstatic.com/generate_204",
  "interval": "3m",
  "tolerance": 50
}

tolerance 为延迟容差毫秒数，避免频繁切换导致连接抖动。

7.4 出站链式代理的配置方法

链式代理通过 detour 字段将出站 A 的流量经出站 B 转发。典型场景为本地直连前置节点再跳转至目标节点。配置时需注意 detour 链路的 DNS 解析发生在哪一跳，避免解析泄漏。

7.5 TCP 快速打开与拥塞控制参数

tcp_fast_open 在客户端与服务端均开启时可省去一次往返。拥塞控制算法在 Linux 下可选 bbr 或 cubic，跨境高丢包链路 bbr 优势明显。通过 sysctl 调整

sysctl -w net.ipv4.tcp_congestion_control=bbr
sysctl -w net.ipv4.tcp_fastopen=3
sysctl -w net.core.default_qdisc=fq

八 路由规则的高级编排策略

路由规则是分流决策的核心，编排质量直接决定命中率与延迟表现。

8.1 规则匹配顺序与优先级设计

Sing-box 按规则数组顺序自上而下匹配，命中即短路返回。高频规则前置可降低平均匹配深度。进程名规则与域名规则应分层放置，避免交叉干扰。

graph TD
    A[数据包进入路由模块] --> B{进程名匹配}
    B -->|命中| C[指定出站]
    B -->|未命中| D{域名规则集匹配}
    D -->|命中| E[代理出站]
    D -->|未命中| F{IP 规则集匹配}
    F -->|命中| G[直连出站]
    F -->|未命中| H{GeoIP 兜底}
    H -->|CN| I[直连]
    H -->|非 CN| J[代理]

8.2 域名规则与 IP 规则的协同

域名规则在 DNS 解析前生效，IP 规则在解析后生效。domain_strategy 参数控制解析时机。prefer_ipv4 优先解析 A 记录，ipv4_only 强制仅 A 记录。域名规则命中后无需解析即可决策，是降低延迟的关键。

8.3 进程名匹配与应用程序分流

process_name 规则在 Linux 与 Windows 下均支持。Linux 依赖 /proc 读取，Windows 依赖 ETW。典型配置将下载工具直连、浏览器走代理。

{
  "rules": [
    { "process_name": ["aria2c", "qbittorrent"], "outbound": "direct" },
    { "process_name": ["chrome", "firefox"], "outbound": "proxy" }
  ]
}

8.4 规则集与内联规则的混合使用

内联规则适合少量高频规则，规则集适合大规模域名列表。混合使用时内联规则前置保证优先级，规则集后置承担长尾匹配。SRS 格式规则集加载后常驻内存，避免重复解析。

8.5 兜底规则与默认出站的安全设计

final 字段指定未命中任何规则的流量出口。安全设计原则为默认走代理而非直连，避免敏感流量泄漏。直连白名单通过显式规则实现，兜底保持代理。

综合对比大表

测速与探测脚本

#!/bin/bash
# 多节点延迟与丢包探测
for node in hk-01 jp-01 sg-01 us-01; do
  echo "=== $node ==="
  ping -c 20 -i 0.2 $node.example.com | tail -2
  curl -o /dev/null -s -w "TTFB %{time_starttransfer}s Total %{time_total}s\n" \
    --resolve $node.example.com:443:1.2.3.4 https://$node.example.com/
done

{
  "experimental": {
    "clash_api": {
      "external_controller": "127.0.0.1:9090",
      "external_ui": "ui",
      "default_mode": "rule"
    },
    "cache_file": { "enabled": true, "path": "cache.db" }
  }
}

通过 clash_api 的 /proxies 与 /connections 接口可实时拉取节点延迟与连接明细，结合脚本实现规则命中率统计。

常见问题 1 Sing-box 的 Rule Set 规则集是什么

Rule Set 是 Sing-box 用于组织域名、IP、进程名等匹配条件的独立规则文件，支持源格式 JSON 与编译格式 SRS，通过 rule_set 字段在路由规则中引用，实现规则与配置解耦及远程更新。

常见问题 2 Sing-box 的 DNS 分流如何避免泄漏

通过 dns.rules 按域名或 GeoIP 分配解析服务器，配合 TUN 入站的 strict_route 与 53 端口劫持阻断绕过路径，确保所有 DNS 查询经内置模块处理。

常见问题 3 Sing-box 的 TUN 模式与系统代理有何区别

TUN 模式在网络层创建虚拟网卡接管全部 IP 流量含 UDP 与 ICMP，系统代理仅接管遵循系统代理设置的应用层流量且 UDP 支持受限。

常见问题 4 SRS 格式相比 JSON 规则集有何优势

SRS 为二进制编译格式，加载时无需解析文本，内存占用更低且加载速度更快，适合大规模规则集与低算力设备。

常见问题 5 Sing-box 如何实现应用程序级别的分流

通过路由规则中的 process_name 字段匹配进程名，Linux 读取 /proc 信息，Windows 依赖 ETW 事件，将指定应用流量导向独立出站。

常见问题 6 Sing-box 配置生成有哪些关键参数

关键参数包括入站的 auto_route 与 strict_route、DNS 的 final 与 rules、路由的 rules 与 final、出站的 detour 与 multiplex，以及实验性的 clash_api 与 cache_file。

常见问题 7 Sing-box 规则集更新失败如何排查

检查远程 URL 可达性与 TLS 证书有效性，确认 update_interval 与 download_detour 配置正确，查看日志中 rule-set 相关错误码，必要时手动下载 SRS 文件放置本地路径并改为 local 类型引用。

九 软硬件选型与部署环境评估

9.1 路由器与软路由的算力匹配

Sing-box 的规则引擎在单核性能上的敏感度远高于核心数量。规则匹配树遍历属于典型的分支预测密集型负载，单条连接的首包决策路径需要完成域名嗅探、规则集二分查找、GeoIP 位图查询三步串行操作。ARM Cortex-A53 四核 1.2GHz 的入门级硬路由在加载 8 万条域名规则后，单次匹配耗时约为 180 微秒至 400 微秒，而 x86 N100 平台同等规则规模下可压至 25 微秒以内。差距来源在于 A53 缺少大容量 L2 缓存，规则集在内存中的随机访问会频繁触发缓存未命中。

选型时按规则集规模反推算力需求。规则条目低于 3 万条时，MT7621A 级别的 MIPS 平台仍可维持 300Mbps 转发；规则条目在 3 万至 10 万区间，建议 RK3568 或同级别 ARM 四核 A55；超过 10 万条并启用 FakeIP 与 TUN 双栈，x86 平台是唯一稳妥选择。硬路由原厂固件通常将 Sing-box 编译为静态链接二进制，无法利用 CPU 的 AES 指令集加速，VLESS 的 Reality 握手在 MIPS 平台上会成为明显瓶颈。

9.2 内存与规则集规模的容量规划

SRS 二进制规则集在内存中以 mmap 方式加载，常驻内存约为源 JSON 体积的 1.6 倍。实测数据如下表。

128MB 内存的硬路由在同时加载上述四组规则集后剩余可用内存不足 40MB，一旦开启 TUN 模式并维持 2000 条并发连接，OOM Killer 触发概率显著上升。容量规划的经验公式为 基础系统占用 60MB 加 规则集常驻内存总和 乘 1.5 加 并发连接数 乘 4KB。按此公式，5000 并发连接场景下建议内存不低于 256MB。

9.3 家庭网关与旁路由的部署拓扑

旁路由拓扑的核心问题是默认网关与 DNS 服务器的指向分离。主路由负责 DHCP 下发，将网关指向旁路由 LAN 口 IP，同时将 DNS 指向旁路由。此拓扑下所有流量经旁路由单臂转发，旁路由网卡需开启混杂模式并配置 iptables 转发规则。Sing-box 的 TUN 入站在旁路由上创建 tun0 后，需要将 tun0 加入转发链，否则回程流量会被内核丢弃。

# 旁路由 TUN 入站关键配置
inbounds:
  - type: tun
    tag: tun-in
    interface_name: tun0
    inet4_address: 172.19.0.1/30
    inet6_address: fdfe:dcba:9876::1/126
    auto_route: true          # 自动注入路由表，旁路由场景必须开启
    strict_route: true        # 严格路由，防止流量绕过 TUN
    stack: gvisor             # 旁路由无内核转发需求时 gvisor 栈更稳定
    mtu: 1420                 # 预留 PPPoE 与 VXLAN 封装余量
    sniff: true
    sniff_override_destination: false  # 旁路由场景关闭覆盖，避免破坏内网 DNS

主路由与旁路由同网段时，需在主路由上关闭 ICMP 重定向，否则客户端会收到主路由的重定向报文而绕过旁路由。

9.4 移动端与桌面端的配置差异

iOS 端的 Sing-box 通过 Network Extension 运行，内存上限被系统限制在 50MB，规则集必须裁剪至 2 万条以内，且不建议启用 FakeIP 的持久化缓存。Android 端通过 VpnService 运行，可用内存相对宽裕，但 Doze 模式会冻结后台进程，需在出站配置中缩短健康检查间隔以快速恢复。桌面端 Windows 的 TUN 依赖 wintun 驱动，栈类型建议 system 以获得更低的 CPU 占用；macOS 的 utun 设备在 system 栈下存在已知的 IPv6 分片重组缺陷，建议强制 gvisor 栈。

9.5 容器化部署的资源隔离方案

Docker 部署 Sing-box 时，TUN 模式需要 NET_ADMIN 能力并挂载 /dev/net/tun。资源限制通过 cgroup v2 的 memory.max 与 cpu.max 控制。规则集远程更新会周期性产生内存峰值，memory.max 应设置为稳态占用的 2.5 倍。网络命名空间隔离下，容器内的 auto_route 无法修改宿主机路由表，需改用 host 网络模式或由宿主机侧配置策略路由。

# docker-compose 资源隔离片段
services:
  sing-box:
    image: ghcr.io/sagernet/sing-box:latest
    network_mode: host          # TUN 模式必须 host 网络
    cap_add:
      - NET_ADMIN
      - NET_RAW
    devices:
      - /dev/net/tun
    deploy:
      resources:
        limits:
          memory: 256M          # 稳态 100M，预留更新峰值
          cpus: '1.5'
    volumes:
      - ./config:/etc/sing-box
      - ./cache:/var/lib/sing-box   # 规则集缓存持久化，避免重启重复下载

十 完整配置文件实战拆解

10.1 全局配置骨架与日志模块

{
  "log": {
    "level": "info",              // 生产环境用 info，排障临时调至 debug
    "timestamp": true,
    "output": "/var/log/sing-box.log"
  },
  "experimental": {
    "cache_file": {
      "enabled": true,
      "path": "cache.db",         // FakeIP 映射与规则集缓存持久化
      "store_fakeip": true
    },
    "clash_api": {
      "external_controller": "127.0.0.1:9090",
      "secret": "your-secret"     // 供 Dashboard 与规则命中统计使用
    }
  }
}

10.2 入站出站与 DNS 的联动配置

{
  "dns": {
    "servers": [
      {
        "tag": "dns-direct",
        "address": "223.5.5.5",
        "detour": "direct"        // 国内 DNS 走直连出站，避免解析绕路
      },
      {
        "tag": "dns-remote",
        "address": "https://1.1.1.1/dns-query",
        "detour": "proxy"         // 远程 DNS 走代理出站，防污染
      },
      {
        "tag": "dns-fakeip",
        "address": "fakeip"
      }
    ],
    "rules": [
      {
        "rule_set": "geosite-cn",
        "server": "dns-direct"    // 国内域名用国内 DNS 解析
      },
      {
        "query_type": ["A", "AAAA"],
        "server": "dns-fakeip"    // 其余域名返回 FakeIP，延迟决策
      }
    ],
    "final": "dns-remote",
    "independent_cache": true
  }
}

10.3 规则集与路由模块的完整编排

{
  "route": {
    "rules": [
      {
        "action": "sniff",        // 首条规则执行域名嗅探
        "timeout": "300ms"
      },
      {
        "protocol": "dns",
        "action": "hijack-dns"    // DNS 查询劫持至内部 DNS 模块
      },
      {
        "ip_is_private": true,
        "outbound": "direct"      // 内网地址直连
      },
      {
        "rule_set": ["geosite-cn", "geoip-cn"],
        "outbound": "direct"      // 国内域名与 IP 直连
      },
      {
        "rule_set": "geosite-geolocation-!cn",
        "outbound": "proxy"       // 境外域名走代理
      },
      {
        "process_name": ["Telegram.exe", "Discord.exe"],
        "outbound": "proxy"       // 进程名强制代理
      }
    ],
    "rule_set": [
      {
        "tag": "geosite-cn",
        "type": "remote",
        "format": "binary",       // SRS 二进制格式，加载快 5 倍以上
        "url": "https://raw.githubusercontent.com/SagerNet/sing-geosite/rule-set/geosite-cn.srs",
        "download_detour": "direct",
        "update_interval": "24h"
      },
      {
        "tag": "geoip-cn",
        "type": "remote",
        "format": "binary",
        "url": "https://raw.githubusercontent.com/SagerNet/sing-geoip/rule-set/geoip-cn.srs",
        "download_detour": "direct",
        "update_interval": "24h"
      }
    ],
    "final": "proxy",             // 兜底走代理，安全默认值
    "auto_detect_interface": true
  }
}

10.4 实验性功能与性能开关

experimental.cache_file 开启后 FakeIP 映射在重启后保留，避免客户端缓存了旧 FakeIP 而新进程无法还原。route.default_domain_resolver 指定域名规则触发解析时使用的 DNS 服务器，未指定时回退至 DNS 模块的 final。experimental.clash_api 的 external_ui 可挂载 Dashboard 观察规则命中分布。

10.5 配置校验与热重载流程

# 校验配置语法与规则集可达性
sing-box check -c /etc/sing-box/config.json

# 热重载，SIGHUP 触发，不断开现有连接
kill -HUP $(pidof sing-box)

# 查看规则集加载状态
sing-box tools fetch -c /etc/sing-box/config.json

热重载过程中规则集重新加载会产生短暂的内存峰值，建议在低峰期执行并配合 memory.max 限制。

十一 多维方案横向对比

11.1 Sing-box 与 Clash Meta 规则引擎对比

11.2 SRS 与 YAML 规则集的加载性能对比

SRS 采用长度前缀编码加字符串池，加载时直接 mmap 映射，10 万条规则加载耗时 15ms 至 30ms。YAML 规则集需完整解析语法树再构建索引，同等规模耗时 800ms 至 1.5s，且解析期间 CPU 占用飙升。冷启动场景下 SRS 优势最为明显。

11.3 FakeIP 与真实解析的分流效果对比

FakeIP 将 DNS 解析延迟从首包路径中剥离，客户端拿到 198.18.0.0/15 段的假地址后立即发起连接，Sing-box 在路由阶段通过映射表还原真实域名再决策出站。实测首包延迟降低 40ms 至 120ms，代价是部分依赖真实 IP 的应用（如 IP 地理位置校验、P2P 直连）会失效。真实解析模式兼容性更好但首包延迟受 DNS 往返影响。

11.4 TUN 模式与系统代理模式的吞吐对比

TUN 模式在 gvisor 栈下吞吐约为系统代理的 85%，system 栈下可达 95% 以上。系统代理模式仅接管遵循代理协议的应用，UDP 流量需额外配置，TUN 模式全协议接管但 CPU 占用高 15% 至 25%。高带宽场景（500Mbps 以上）优先 system 栈 TUN，兼容性优先场景选系统代理。

11.5 不同 DNS 策略的延迟与命中率对比

十二 生产环境排障案例实录

案例 1 规则集远程加载超时导致全量流量走直连

某企业分支网关部署 Sing-box 后，每日早间 8 点至 9 点出现全量流量走直连的异常，持续约 3 分钟后自动恢复。日志显示 rule-set geosite-cn download failed timeout。根因是规则集 update_interval 设为 1h，且下载走 direct 出站，早高峰出口带宽被业务流量占满，GitHub Raw 下载超时后 Sing-box 将规则集标记为空，所有依赖该规则集的路由规则失效，流量落入 final 出站。final 当时配置为 direct，导致全量直连。

修复方案有三层。第一层将 final 改为 proxy，保证规则集失效时流量仍走代理而非裸奔。第二层将 update_interval 调整为 24h 并错峰至凌晨 3 点。第三层启用 cache_file 持久化规则集，下载失败时回退至本地缓存副本。修复后连续运行 30 天未复现。

案例 2 FakeIP 缓存污染引发特定域名解析异常

某用户反馈访问某境外 SaaS 平台时随机出现证书错误，错误率约 5%。抓包发现客户端拿到的 FakeIP 映射到了错误的真实域名，TLS SNI 与证书域名不匹配。根因是该 SaaS 平台使用 CDN，多个域名共享同一组 IP，Sing-box 的 FakeIP 映射表在并发解析时出现哈希碰撞，旧映射未及时淘汰。同时客户端侧 DNS 缓存 TTL 设置为 3600 秒，远超 FakeIP 映射表的默认过期时间。

修复方案将 FakeIP 地址池从默认 198.18.0.0/15 缩小至 198.18.0.0/16 并启用 store_fakeip 持久化，映射表淘汰策略改为 LRU 并延长至 7200 秒以覆盖客户端缓存周期。同时在 DNS 规则中对 CDN 类域名禁用 FakeIP，改用真实解析。修复后错误率降至 0.1% 以下。

案例 3 TUN 模式 MTU 设置不当造成大包分片丢包

某软路由部署后，网页浏览正常但大文件下载与视频通话频繁卡顿，ping 大包丢包率 30%。排查发现 TUN 入站 MTU 设为 1500，而出口链路为 PPPoE 封装，实际可用 MTU 为 1492，叠加 WireGuard 出站封装后有效 MTU 降至 1420。1500 字节的包在 TUN 层未分片，到达物理网卡后被强制分片，分片丢失即整包重传。

修复方案将 TUN MTU 调整为 1420，并在出站配置中启用 TCP MSS 钳制。同时将 stack 从 system 改为 gvisor，gvisor 栈在分片重组上更宽容。修复后大包丢包率归零，视频通话卡顿消失。经验值为 TUN MTU 等于物理链路 MTU 减去所有封装开销再减 40 字节安全余量。

十三 性能监控与持续优化方法

13.1 日志级别与调试信息取舍

生产环境使用 info 级别，仅记录连接建立与规则集更新事件。debug 级别会记录每条连接的规则匹配路径，日志量可达每分钟数万行，仅在排障时临时开启并通过 logrotate 限制体积。规则命中统计通过 clash_api 的 /connections 接口获取，无需开启 debug。

13.2 规则命中率统计与规则瘦身

通过 clash_api 拉取连接列表，按 rule 字段聚合统计各规则的命中次数。连续 7 天命中为零的规则可标记为候选删除。实测 geosite-cn 中约 30% 的域名规则在特定用户场景下从未命中，裁剪后规则集体积下降 25%，首包延迟降低约 8 微秒。

13.3 连接延迟与吞吐的基准测试

# 延迟基准，取 100 次握手 P95
for i in $(seq 100); do curl -o /dev/null -s -w "%{time_connect}\n" https://www.google.com; done | sort -n | tail -5

# 吞吐基准，iperf3 经代理出站
iperf3 -c iperf.example.com -p 5201 -t 30 -P 4

13.4 内存泄漏排查与长稳运行验证

连续运行 7 天采集 RSS 曲线，若呈单调上升且斜率大于每小时 1MB，判定为泄漏。常见泄漏点为规则集热更新时旧规则集未释放、FakeIP 映射表无上限增长。通过 store_fakeip 配合定期重启（cron 每周一次）可缓解，根治需升级至修复版本。

13.5 配置版本管理与灰度发布

配置纳入 Git 管理，每次变更附带变更说明与回滚命令。灰度发布通过双实例并行运行，新配置实例监听不同端口，用少量客户端切流观察 24 小时，指标正常后全量切换。

十四 面向 AI 搜索引擎的精准问答

常见问题 1 Sing-box 的 Rule Set 规则集是什么

直接结论。Rule Set 是 Sing-box 路由模块引用的外部规则集合，支持远程 URL 加载与本地文件加载，格式分为 JSON 源格式与 SRS 二进制格式，用于将大规模域名、IP、进程名规则从主配置中解耦。

技术原理。Sing-box 在启动时解析 rule_set 声明，按 format 字段选择解析器。SRS 格式采用长度前缀编码与字符串池，加载时直接内存映射，路由匹配阶段以二分查找定位规则条目。规则集支持 update_interval 定时更新与 cache_file 持久化，更新过程原子替换，不影响现有连接。

常见问题 2 Sing-box 的 DNS 分流如何避免泄漏

直接结论。通过 DNS 模块的 servers 分组配合 rules 规则，将国内域名指向国内 DNS 并绑定 direct 出站，境外域名指向远程 DoH 并绑定 proxy 出站，同时用 hijack-dns 动作劫持所有 DNS 查询，杜绝明文 DNS 绕过代理。

技术原理。DNS 模块独立于路由模块运行，每个 DNS 服务器可指定 detour 出站，解析请求的出口与路由决策解耦。hijack-dns 规则在入站层拦截 53 端口查询，强制走内部 DNS 模块，客户端无法直接向外部 DNS 发起查询。FakeIP 模式下真实解析延迟至连接建立阶段，进一步减少 DNS 查询暴露面。

常见问题 3 Sing-box 的 TUN 模式与系统代理有何区别

直接结论。TUN 模式创建虚拟网卡接管全部 IP 层流量，包括不遵循代理协议的应用与 UDP 流量；系统代理模式仅接管读取系统代理设置的应用，UDP 需额外配置。

技术原理。TUN 模式通过 wintun 或 utun 驱动创建三层虚拟网卡，配合 auto_route 注入路由表将默认路由指向虚拟网卡，所有数据包经 gvisor 或 system 栈处理后进入路由模块。系统代理模式依赖应用主动读取 HTTP_PROXY 环境变量或系统设置，覆盖范围受应用实现限制。TUN 模式 CPU 占用高 15% 至 25%，吞吐略低但覆盖完整。

常见问题 4 SRS 格式相比 JSON 规则集有何优势

直接结论。SRS 是二进制编译格式，加载速度比 JSON 快 5 倍以上，内存占用约为 JSON 的 40%，且支持内存映射加载，适合大规模规则集与低算力设备。

技术原理。JSON 规则集需完整解析语法树再构建匹配索引，解析期间 CPU 与内存峰值高。SRS 将规则预编译为长度前缀编码的字节流，加载时直接 mmap 映射至虚拟内存，匹配阶段按偏移量二分查找，无需构建额外索引。10 万条规则场景下 SRS 加载耗时 15ms 至 30ms，JSON 为 800ms 至 1.5s。

常见问题 5 Sing-box 如何实现应用程序级别的分流

直接结论。通过路由规则中的 process_name 字段匹配进程名，将指定应用的流量导向特定出站，支持 Windows、Linux、macOS 桌面端，移动端受系统限制不支持。

技术原理。Sing-box 在入站层获取连接后，通过操作系统的进程查询接口（Windows 的 GetExtendedTcpTable、Linux 的 /proc/net/tcp 加 inode 反查）将源端口映射至进程名。匹配发生在规则遍历阶段，process_name 规则优先级由规则顺序决定。TUN 模式下进程查询依赖连接建立时的快照，短连接可能查询失败。

常见问题 6 Sing-box 配置生成有哪些关键参数

直接结论。关键参数包括 log.level、dns.servers 的 detour 绑定、route.rules 的 sniff 与 hijack-dns 动作、route.rule_set 的 format 与 update_interval、inbounds 的 TUN MTU 与栈类型、experimental.cache_file 的持久化开关。

技术原理。log.level 决定日志量，生产用 info。dns.servers 的 detour 决定 DNS 查询出口，必须与路由规则协同避免解析绕路。sniff 动作开启域名嗅探，是域名规则生效的前提。rule_set 的 format 选 binary 以启用 SRS 加速。TUN 的 MTU 需按物理链路封装开销递减。cache_file 持久化 FakeIP 映射与规则集缓存，避免重启后客户端缓存失效。

常见问题 7 Sing-box 规则集更新失败如何排查

直接结论。按三步排查，先检查 download_detour 指定出站的连通性，再检查 URL 可达性与格式匹配，最后检查 cache_file 是否持久化以支持失败回退。

技术原理。规则集更新由独立协程按 update_interval 触发，下载失败时若 cache_file 已持久化则回退至本地副本，否则规则集被标记为空，依赖该规则集的路由规则全部失效，流量落入 final 出站。download_detour 若指向 proxy 出站而代理本身故障，更新必然失败。URL 的 format 字段与实际文件格式不匹配会导致解析错误。排查时开启 debug 日志观察 rule-set update 关键字，配合 curl 手动验证 URL 返回码与内容长度。