sing-box 规则不生效怎么办？按命中、DNS、TUN 与 rule-set 排查
简答：sing-box 规则不生效，先看有没有目标连接日志：没有日志先查系统代理、Mixed 入站或 TUN 接管；有日志但未按预期分流，再查规则顺序、域名识别和 rule-set；已经命中规则仍失败，最后检查 outbound、DNS 和实际连接错误。不要同时修改 DNS、TUN 和规则集，先用一个域名和一个出站做对照。
定义：sing-box 规则不生效，是指配置能够启动或客户端显示运行，但目标流量没有按 route.rules、rule-set 和对应 outbound 的预期路径处理。
30 秒分流卡：先判断卡在哪一层
本文是 acaisbest.shop 的第三方使用指南，不代表 sing-box 官方。菜单名称会因桌面端、移动端和封装客户端不同而变化；下面优先使用核心配置和可观察结果，不把某个客户端界面当成所有平台都适用。
| 现象 | 先做什么 | 通过标准 | 停止条件与下一步 |
|---|---|---|---|
| 核心无法启动或立即退出 | 备份配置后，用命令行核心尝试 sing-box check -c config.json | 没有配置解析或字段错误 | 命令不可用时，不要因此判定配置错误；改看封装客户端启动日志 |
| 客户端显示运行，但没有目标连接日志 | 只测试一个浏览器或应用，检查系统代理、Mixed 端口或 TUN 状态 | 日志或客户端面板至少出现一条新连接 | 仍无连接就先查流量接管，不要继续改规则 |
| 有连接，但没有按预期分流 | 用一个明确域名规则临时放在规则列表前部 | 日志或面板能确认目标域名、入站或最终出站发生变化 | 无法显示命中规则时，用前后对照测试间接确认 |
| 规则看似命中，但连接失败 | 核对规则动作、outbound 标签、DNS 请求和连接错误 | 能区分是路由选择错误还是出站连接错误 | 先验证出站本身，再判断是否仍是规则问题 |
| rule-set 下载或更新失败 | 检查启动、更新和解析日志，再用本地或 inline 规则集对照 | 本地规则集能读入并参与匹配 | 本地能用而远程不能用，重点查 URL、HTTP 客户端和缓存 |
配置检查通过，只能说明核心能够解析并接受相关字段，不能证明目标流量进入了正确 inbound、规则已经命中、outbound 能连接或网页一定可用。核心命令是否由当前发行版提供，也取决于你使用的是命令行核心还是封装客户端。可先核对sing-box 配置总览。
先做最小化测试：只保留一个域名和一个出站
复杂配置同时包含多个入站、DNS 分流、远程 rule-set 和 TUN 时，很难判断是哪一层出了问题。先备份原文件，再临时建立一个最小路由片段，用于验证规则结构，不要把它当成可独立启动的完整配置。
{"route":{"rules":[{"domain":["example.com"],"action":"route","outbound":"proxy"}],"final":"direct"}}
- inbound 必须真实存在：浏览器走系统代理时，要指向 HTTP 或 Mixed 入站；TUN 流量则必须确实进入 TUN 入站。
- outbound 标签必须真实存在：
proxy只是示例，必须替换为outbounds[].tag中完全一致的字符串。 - 规则动作要符合当前版本：当前官方文档将路由写为
action":"route"，并在动作中指定目标 outbound；旧教程里的顶层outbound不应直接照抄。 - final 只是兜底：
final负责没有更早规则处理时的默认出站，不会自动修复未命中的规则。
测试时固定同一个域名、同一个应用和同一个出站，只修改一项并重新启动。若单域名规则可以改变结果，说明基础路由链路大体可用，再逐步加入 rule-set、DNS 和其他规则。路由字段与匹配逻辑以官方 Route Rule 文档为准。
规则顺序并非唯一原因：还要看 action 是否继续处理
常规排查可以先按“规则列表从前往后”理解，但不能简单说成所有规则都只命中一次。官方规则动作中，route 是最终动作；sniff、resolve 和 route-options 属于非最终动作，可能先补充连接信息或解析结果，再影响后续处理。因此，前面的规则可能不是直接把流量送走，而是先执行嗅探或解析。
- 先排查宽泛规则：临时把单域名规则放到前面，避免它被范围更大的直连、代理或 rule-set 条件影响。
- 确认字段组合：官方默认匹配逻辑中，域名类字段之间通常是“或”关系，而端口、来源、其他字段会形成组合条件。不要把多个字段都填上后，误以为它们一定是独立的多条规则。
- 确认动作与标签：当前版本应检查
action":"route"和对应的 outbound；标签区分大小写，proxy、Proxy与proxy-out不是同一个值。 - 看结果而不是猜命中：如果日志或面板不显示具体规则编号，可临时让测试规则指向另一个已确认存在的出站，或者与
final不同的结果做前后对照。这个方法只能间接确认路径变化，不能替代完整命中日志。
截至 2026-10-31，官方路由规则页面仍将 geosite、geoip 标为废弃，并列出多个版本新增或调整的字段；迁移旧配置时应以当前核心版本对应的官方迁移说明为准，不要据此推断所有旧字段会在同一版本立即失效。
只有 domain 或 domain_suffix 不生效：检查 sniff、DNS 与 Fake-IP
如果 IP 规则或端口规则能改变结果，但域名规则没有变化，常见方向是路由阶段没有可用的域名信息。协议嗅探可以从 HTTP Host、TLS Server Name 和部分 QUIC 流量中识别域名，但是否能识别取决于实际流量和入站类型，不能保证所有连接都出现域名。
- 先看日志中的目标形态：目标显示为原始域名，说明路由阶段至少拿到了域名线索；目标只显示真实 IP，需继续检查应用解析、DNS 路径或 sniff；目标显示为配置中的 Fake-IP 地址段，则先核对 Fake-IP 映射、DNS 返回和 TUN 路由是否属于同一套配置。
- 检查 sniff 是否真正执行：当前文档使用
action":"sniff"表示嗅探；旧版入站嗅探字段可能处于迁移范围。若日志没有嗅探到域名，不要仅凭配置里写过 sniff 就判断它已生效。 - 检查 DNS 请求是否经过预期模块：DNS 查询成功不等于路由规则命中。分别观察 DNS 请求、返回地址和后续连接目标，确认应用没有绕过 sing-box 直接使用系统解析。
- 区分 Fake-IP 与真实 IP：同一域名连续测试时，记录 DNS 返回和连接日志中的目标地址。如果 DNS 返回的是 Fake-IP 而连接阶段没有恢复到原始域名，问题可能在 Fake-IP 映射或 TUN 接管；如果 DNS 返回真实 IP但域名规则仍不命中，则重点检查 sniff 或应用是否自行解析。
上述判断只能缩小范围，不能仅凭浏览器能打开页面证明规则已按预期工作。可对照官方 Protocol Sniff 文档与官方 DNS 配置文档核对当前版本字段。
rule-set 加载失败：区分 URL、格式、HTTP 客户端和缓存
rule-set 不是一个笼统的“规则文件”。排查时要拆成四项：下载地址、文件格式、下载所用的 HTTP 客户端，以及启动时可用的本地内容。
- URL：远程 rule-set 的
url必须能返回实际规则文件，而不是登录页面、错误页或需要额外交互的页面。 - 格式：官方文档区分
source和binary；文件扩展名有时可以帮助判断，但不能替代配置中的格式核对。 - HTTP 客户端：当前文档使用
http_client处理远程 rule-set 下载；旧的download_detour已标记为废弃，迁移时应以当前版本文档为准。 - 初始文件与缓存：
initial_path用于没有可用缓存时的启动内容；缓存存在，只能说明曾经保存过内容，不能证明本次远程更新成功。
查看日志时，重点找与 rule-set 标签、download、update、parse、HTTP 状态、TLS 或 cache 相关的行。不同封装客户端的关键词和展示位置可能不同；如果日志不显示细节，先用一个本地或 inline rule-set 替换远程版本。若本地能够命中而远程不能，问题范围就缩小到 URL、格式、HTTP 客户端、证书、下载路径或远程文件内容。字段定义以官方 rule-set 文档为准。
系统代理、Mixed 与 TUN：规则正确也可能没有流量进入
| 运行方式 | 需要核对 | 可观察结果 | 停止条件 |
|---|---|---|---|
| 系统代理 | 系统代理地址、端口是否指向 HTTP 或 Mixed 入站；目标应用是否遵守系统代理 | 该应用发起连接后，日志出现对应入站或目标 | 没有连接就先查应用是否绕过系统代理 |
| Mixed 入站 | 监听地址、端口、协议类型和端口占用 | 客户端面板或日志出现真实连接 | 端口能监听不等于应用已经接入 |
| TUN 入站 | 虚拟接口、权限、自动路由、系统 VPN、排除项与 DNS 模式 | 目标应用流量能在 TUN 相关日志或面板中出现 | TUN 未创建、应用被排除或权限被拒绝时，不要继续改规则 |
官方文档说明，TUN 的 auto_route 会设置默认路由，同时要关注路由回环；可核对 route.auto_detect_interface、默认网卡或出站绑定接口。Windows、macOS、Linux、Android 的权限和接管机制不同，不能用一条系统命令代表所有平台。移动端封装客户端也可能不提供完整核心命令行入口。可参考官方 TUN 入站说明。
如果规则在 Mixed 模式下有效、TUN 模式下无效，优先比较两种模式的入站日志、DNS 处理和路由接管范围；如果两种模式都没有目标连接，则先回到系统代理、端口或权限问题。
版本迁移与回滚：只改一项，保留可复现证据
版本敏感字段不要只看旧教程。官方页面列出的迁移变化包括：规则中的传统 outbound 已迁移到规则动作；远程 rule-set 的 download_detour 在 1.14.0 标记为废弃；TUN 的 stack 在 1.15.0 标记为废弃。这里的版本信息只用于提醒核对，实际是否可用仍取决于当前核心版本和封装客户端，请以对应版本官方文档为准。
- 恢复原始配置和规则集文件，确认问题没有因多项修改叠加而扩大。
- 只保留一个 inbound、一个已确认存在的 outbound、一个域名规则和一个
final。 - 运行命令行核心时再尝试
sing-box check -c config.json；封装客户端没有该命令时，使用它自己的配置校验或启动日志。 - 启动后只测试一个域名，记录目标地址、是否出现 DNS 请求、是否出现入站连接、是否能看到最终出站。
- 逐项恢复 rule-set、sniff、DNS 分流和 TUN 设置，每次只改变一项。
反馈或自查时，只保留核心版本、操作系统、入站类型、脱敏后的错误日志、目标地址形态、规则标签和最终出站。不要公开订阅地址、访问令牌、私钥、用户名密码或完整节点配置。
常见问题
sing-box check 通过了，为什么规则还是不生效？
check 主要说明核心能够解析和接受配置，不能证明目标流量进入正确 inbound、规则已经命中或 outbound 可以连接。下一步应观察连接日志或客户端面板，并用一个域名和一个出站做前后对照。
sing-box 规则是不是越靠前越优先？
常规排查可以按规则列表顺序理解，但不能把所有规则都看成只匹配一次。route 是最终动作，sniff、resolve 和 route-options 等动作可能先补充信息或改变后续处理。应以当前版本的规则动作文档和实际日志为准。
为什么 IP 规则有效，domain_suffix 却不生效？
常见方向是路由阶段只有 IP、应用绕过了 sing-box DNS、入站没有获得可用域名，或 sniff、Fake-IP 与 TUN 链路不一致。请比较 DNS 返回、连接日志中的目标地址和是否出现嗅探结果。
rule-set 下载失败会导致全部规则失效吗？
不一定。影响范围取决于哪些规则引用该 rule-set，以及是否存在 initial_path 或缓存。先查看下载、更新、解析和 HTTP 错误日志，再用本地或 inline rule-set 做对照。
为什么桌面端没有 sing-box check 命令？
部分桌面端或移动端只是封装客户端，不一定暴露完整核心命令行。命令不可用时，不要直接判定配置错误，应使用客户端提供的校验功能或启动日志；能运行命令行核心时，再使用对应版本的 check。
sing-box 规则已经命中，但网页仍然打不开怎么办？
这时问题可能已经从规则层转到 outbound、DNS、TLS 或连接路径。先确认命中的 outbound 标签存在，再单独测试该出站和 DNS 请求，不要把网页打不开直接归因于规则未生效。