sing-box 配置文件看起来复杂，真正需要先搞清的其实只有几块：DNS 怎么解析、TUN 怎么接管流量、Outbound 怎么定义出口、Route 怎么分流、Rule Set 怎么维护规则。截至 2026 年 9 月，sing-box 当前稳定版已经进入 1.14 系列，旧教程里常见的 FakeIP、旧式 DNS Server、inbound 中的 sniff 字段等写法已经发生明显变化。
这版内容按 sing-box 1.14.1 稳定版重新核对，重点解决“配置文件现在应该怎么读、旧配置为什么报错、DNS/TUN/分流规则应该放在哪里”这几个问题。示例用于理解结构和字段关系，实际节点参数、证书、域名和规则集地址仍应按你的环境填写。
版本提醒：本文按 sing-box 1.14.1 稳定版整理。旧教程中的 FakeIP、legacy DNS Server、inbound sniff 和 download_detour 等写法已经发生变化，旧配置请参考文末“1.14 迁移”章节。
目录
30 秒先看懂：sing-box 配置文件骨架
sing-box 使用 JSON 作为配置格式。当前官方配置结构可以先简化理解为下面几部分：
{
"$schema": "https://sing-box.sagernet.org/schema.json",
"log": {},
"dns": {},
"http_clients": [],
"inbounds": [],
"outbounds": [],
"route": {},
"experimental": {}
}完整配置可以先按这些模块理解；实际修改后，建议再用 sing-box check 检查配置是否合法。
一、sing-box LOG 日志配置：日志级别与排错
日志模块负责记录 sing-box 的运行状态。日常使用可以先从 info 级别开始，遇到连接、DNS 或规则匹配问题时，再临时提高日志详细度，而不是长期把调试日志全部打开。
"log": {
"level": "info",
"timestamp": true
}
排错时重点看三类信息：节点是否成功建立连接、DNS 请求走到了哪个服务器、Route 规则最终把连接送到了哪个 Outbound。日志越详细并不等于配置越好，定位完问题后可以恢复到正常级别。
二、sing-box DNS 配置：新版解析与分流怎么写
1.14 最重要的变化之一就是 DNS。旧教程常见的 "address": "https://..."、FakeIP Server 等写法已经不适合作为当前模板。新版 DNS Server 需要明确类型，例如 local、https、tls。
"dns": {
"servers": [
{
"type": "local",
"tag": "local"
},
{
"type": "https",
"tag": "remote",
"server": "1.1.1.1",
"path": "/dns-query",
"detour": "proxy"
}
],
"rules": [
{
"rule_set": "geosite-cn",
"action": "route",
"server": "local"
}
],
"final": "remote"
}注意：这是 DNS 模块示例，不是完整可运行配置；其中 proxy 和 geosite-cn 等 tag 需要在 Outbound / Rule Set 中预先定义。
Local DNS：处理本地或指定规则集
type: "local" 使用当前系统或平台提供的本地解析能力。你可以通过 DNS rules 把指定域名或规则集交给 local，而不是把所有请求都固定走同一套 DNS。
Remote DNS：用 HTTPS / TLS 明确上游
如果使用 DoH，可以设置 type: "https"。当 DNS 请求需要经过指定代理出口时，可以使用 Dial Fields 中的 detour。如果 server 使用域名，还需要同时考虑 domain_resolver。
FakeIP 为什么删掉？
FakeIP 旧配置从 1.12 开始废弃，并在 1.14 正式移除。因此这篇不再把 FakeIP 当成当前分流核心，也不再使用 198.18.0.0/15 作为新版 Route 示例。当前配置重点放在 DNS rules、Route rules、Rule Set 和 TUN 自身的 DNS 处理能力上。
三、sing-box TUN 配置：入站、自动路由与权限
TUN 可以理解为系统级虚拟网络接口。开启后，系统流量进入 TUN，再由 sing-box 按 Route 规则决定直连、代理或拒绝。1.14 的 TUN 还增加了 dns_mode 等 DNS 处理能力。
"inbounds": [
{
"type": "tun",
"tag": "tun-in",
"address": [
"172.19.0.1/30"
],
"auto_route": true,
"strict_route": true,
"dns_mode": "hijack"
}
]注意：这是 TUN 模块示例，需要和 Route、DNS、Outbound 一起组成完整配置；不同系统的权限、接口和路由环境也会影响最终行为。
auto_route 会设置到 TUN 的默认路由；strict_route 会进一步强制严格路由。在 Windows 上，它还会影响多宿主 DNS 行为；在 Linux 等平台上则需要结合当前路由、接口和权限环境判断。
还要注意一个实际配置问题：开启 auto_route 后，应根据运行环境设置 route.auto_detect_interface、route.default_interface 或 outbound.bind_interface 之一，避免代理出站再次被 TUN 捕获形成流量环回。
不要再把旧配置中的 sniff、sniff_override_destination 塞进入站。嗅探现在应该放到 Route Rule，通过 action: "sniff" 执行。
四、sing-box Outbound 配置：节点与 urltest 自动切换
Outbound 定义真正的出口。可以是 direct、VLESS、Shadowsocks、Hysteria2 等，也可以用 urltest 把多个节点放进自动测速组。
{
"type": "urltest",
"tag": "proxy",
"outbounds": [
"node-a",
"node-b"
],
"url": "https://www.gstatic.com/generate_204",
"interval": "3m",
"tolerance": 50,
"idle_timeout": "30m",
"interrupt_exist_connections": false
}注意：这是 urltest 模块示例；node-a、node-b 必须先在 outbounds 中定义，测试地址和间隔也应按实际网络调整。
tolerance 用来避免延迟差很小时频繁切换；idle_timeout 控制空闲多久后暂停周期测试；interrupt_exist_connections 决定切换选中出站时是否中断已有入站连接。这里不再写成“切换一定无感”——实际体验还会受到协议、已有连接和应用行为影响。
VLESS / Reality 节点怎么放？
具体节点仍放在 outbounds 里，再让 urltest 引用这些 tag。Reality 的 server name、公钥、short ID、UUID 等必须和服务端一致。文章不再提供固定“伪装域名”模板，避免用户直接复制与自己服务端不匹配的参数。
HTTP / SOCKS5 代理怎么作为 Outbound？
如果上游提供的是普通 HTTP 或 SOCKS5 代理，也可以直接作为 sing-box Outbound。官方当前同时支持 HTTP Outbound 和 SOCKS Outbound。如果供应商给的是服务器地址、端口、用户名和密码，可以映射到对应字段。
"outbounds": [
{
"type": "http",
"tag": "http-proxy",
"server": "proxy.example.com",
"server_port": 8080,
"username": "your-username",
"password": "your-password"
},
{
"type": "socks",
"tag": "socks5-proxy",
"server": "proxy.example.com",
"server_port": 1080,
"version": "5",
"username": "your-username",
"password": "your-password"
}
]注意：这是 Outbound 结构示例，proxy.example.com、端口和认证信息都要替换成实际代理参数；SOCKS 的 network、UDP 等能力还要按供应商和使用场景确认。
这样后面的 Route 就可以直接把特定流量送到 http-proxy 或 socks5-proxy。如果你接入的是住宅代理，最终是否能用 HTTP / SOCKS5、认证方式和可用端口，应以代理服务商实际提供的参数为准。
五、sing-box 分流规则：Route、DNS 劫持与流量匹配
Route 决定流量最终走向。当前配置的重点不是旧版 sniff_override_destination，而是把“嗅探、DNS 劫持、路由、拒绝”都明确写成规则动作。
"route": {
"rules": [
{
"action": "sniff"
},
{
"rule_set": "geosite-cn",
"action": "route",
"outbound": "direct"
},
{
"rule_set": "geosite-global",
"action": "route",
"outbound": "proxy"
}
],
"final": "proxy"
}注意：这是 Route 模块示例，不是完整可运行配置；其中 geosite-cn、geosite-global、direct、proxy 等 tag 需要在对应 Rule Set / Outbound 中定义。
流量嗅探：action: sniff
action: "sniff" 是非最终动作，用于识别 DNS、TLS、HTTP、QUIC 等协议相关信息，再交给后续规则继续判断。它替代的是旧 inbound 里的 sniff 字段，不要把两种写法混在同一份新版配置里。
什么时候需要显式 action: hijack-dns？
如果 TUN 已使用 dns_mode: "hijack"，且没有显式设置 dns_address，sing-box 会自动把派生出的 DNS 地址流量交给 DNS 模块，效果等价于 action: "hijack-dns"。因此基础 TUN 配置里不需要再机械重复一条 hijack-dns。只有在显式设置 dns_address 后仍需要相同劫持行为，或你的接入方式没有依赖这套 TUN 自动劫持时，再单独写显式 Route Action。
分流：Rule Set + route
规则集命中后，用 action: "route" 和目标 outbound 指定直连或代理。相比在正文里维护一长串站点名称，这种方式更容易长期维护。
QUIC 要不要屏蔽？
不建议把“拒绝 UDP 443”写成所有用户都应该照搬的固定规则。它确实可以让部分 HTTP/3 流量回退到 TCP，但是否需要取决于代理协议、UDP 支持和实际网络。只有已经确认 QUIC 导致特定兼容问题时，再针对性增加 reject 规则。
六、sing-box Rule Set：远程规则集怎么配置
官方名称是 Rule Set，不是 RAWSET。远程规则集可以使用 source 或 binary 格式；如果使用 .srs，通常对应 binary 规则集。开启 cache_file 后，远程 Rule Set 也可以被缓存。
1.14 需要特别注意：旧的 download_detour 已废弃，官方 Rule Set 文档推荐改用 http_client。同时，官方也开始要求更明确地定义用于下载远程资源的 HTTP Client，避免继续依赖旧的隐式默认行为。
"route": {
"rule_set": [
{
"type": "remote",
"tag": "geosite-cn",
"format": "binary",
"url": "https://example.com/geosite-cn.srs",
"http_client": {
"detour": "proxy"
},
"update_interval": "1d"
}
]
}注意：这是 Rule Set 下载结构示例；proxy 必须是已定义的 Outbound，example.com 需要替换成真实可信的规则集地址。
示例 URL 使用 example.com 只是为了展示结构。这里使用 inline http_client 指定下载走 proxy；规则集较多时，也可以在顶层集中定义 http_clients，再通过 route.default_http_client 复用。真正上线时应替换成你实际维护或确认可信的 Rule Set 来源。
七、cache_file 与实验性功能怎么配置
experimental.cache_file 仍然是当前可用功能。它可以保存部分运行数据和远程规则集缓存；从 1.14 起还增加了 store_dns，用于把 DNS 缓存持久化到缓存文件。
"experimental": {
"cache_file": {
"enabled": true,
"path": "cache.db",
"store_dns": true
}
}注意：这是 cache_file 模块示例；缓存路径和是否持久化 DNS 应按运行环境设置。
旧配置中的 store_rdrc 已在 1.14 废弃，官方迁移方向是使用 store_dns。缓存可以减少重复下载和部分重复解析，但不能把它理解成“开启后一定更稳定”；缓存内容是否有效仍取决于当前配置、规则集和网络状态。
八、旧版 sing-box 配置迁移到 1.14 要改什么
如果你手里还是 1.11、1.12 或更早教程里的配置，不建议直接复制到 1.14 后逐个修报错。更快的顺序是先检查下面几项：
- 删 FakeIP：1.14 已移除。
- 重写 DNS Server：旧的 address 形式迁移到 type: local / https / tls 等新版结构。
- 迁移 sniff：从 inbound 字段迁移到 Route Rule 的 action: sniff。
- 迁移 DNS 劫持：按当前 TUN dns_mode 或 action: hijack-dns 处理。
- 改 Rule Set 下载方式：download_detour 改成 http_client。
- 更新缓存字段：需要持久化 DNS 时使用 store_dns，不再继续依赖 store_rdrc。
改完以后先运行 sing-box check。如果仍然报错，再根据错误路径回到对应模块排查，不要一开始就把 DNS、Route、TUN 和 Outbound 同时全部改动。
先运行 sing-box check 检查配置合法性；如果报错，再根据错误路径定位到 DNS、Inbound、Outbound、Route 或 Rule Set 对应模块。格式混乱时可以先用 sing-box format 整理配置。
九、sing-box 1.14 配置常见问题
sing-box 1.14 为什么旧配置会报错？
因为 1.14 已移除或调整了一批旧字段和机制，例如 FakeIP、legacy DNS Server，以及旧 inbound sniff 写法。升级时应先按模块迁移，而不是直接把旧 JSON 原样复制到新核心。
sing-box 1.14 还能使用 FakeIP 吗？
不能继续按旧教程使用。FakeIP 从 1.12 开始废弃，并在 1.14 正式移除。当前配置应改用新版 DNS、Route Rule、Rule Set 和 TUN 的 DNS 处理能力。
dns_mode: hijack 和 hijack-dns 要同时配置吗？
通常不需要。TUN 使用 dns_mode: hijack 且未显式设置 dns_address 时，会自动完成对应 DNS 劫持；如果显式设置 dns_address 后仍需要相同行为，再增加 hijack-dns Route Action。
sing-box 配置修改后怎么检查是否正确？
先运行 sing-box check 检查配置合法性；如果报错，再根据错误路径定位到 DNS、Inbound、Outbound、Route 或 Rule Set 对应模块。格式混乱时可以先用 sing-box format 整理配置。
结语：先确认版本，再谈“配置能不能直接用”
sing-box 配置真正容易出问题的地方，往往不是 JSON 本身，而是拿旧版本字段套到当前核心。1.14 已经把 FakeIP、旧 DNS Server 和部分旧入站字段清理掉，同时把 DNS、Route Action、Rule Set 和 TUN 的职责划得更清楚。
如果只是想在 Android 上选择 sing-box 客户端，可以继续看 安卓与 iPhone 手机代理软件对比；如果已经进入配置阶段，这篇可以作为 1.14 的结构参考，再结合官方文档和自己的节点参数完成最终配置。
sing-box 只负责客户端侧的接入、解析和路由，最终出口质量仍取决于实际代理资源。如果你的配置需要接入住宅代理，可根据场景查看 IPWeb 的 动态住宅代理 或 静态住宅代理，再按客户端支持的协议完成接入。
