sing-box 1.14.0-rc.1 已于 2026 年 8 月 24 日发布，版本阶段从 beta 推进到 RC（Release Candidate，发布候选版）。受影响的是准备从 1.13 稳定分支或 1.14 beta 升级的客户端、服务器与配置维护者。合理动作不是立即覆盖生产环境，而是先确认自己是否依赖旧 DNS 规则、缓存字段或内联 ACME 配置，再决定小范围测试还是继续等待稳定版。
对于搜索“sing-box 1.14.0-rc.1 升级”的用户，最重要的结论是：官方发布页仍明确标记为 Pre-release，发布说明只有“修复与改进”，没有承诺稳定版级别的兼容性。生产链路运行正常、又没有 1.14 特性需求时，可以等待；需要提前验证 1.14 配置的管理员，应先备份、静态检查、分阶段迁移，再在可回滚设备上观察 DNS、路由和证书续期。
先看结论：谁该测试，谁该等待
- 适合测试：已经使用 1.14 beta、需要验证 1.14 DNS 行为或 ACME 新结构，并且有独立测试环境与回滚包的用户。
- 建议等待：生产环境依赖稳定连接、无人值守证书续期，或无法快速恢复旧二进制与旧配置的用户。
- 升级前必查：DNS 规则中的旧地址过滤、
independent_cache、store_rdrc、内联tls.acme，以及ip_version、query_type的实际匹配范围。 - 核验原则：RC 表示接近正式发布，不等于稳定版，也不代表所有第三方客户端已经同步兼容。
1.14.0-rc.1 到底改变了什么
SagerNet 的 1.14.0-rc.1 发布页确认版本在 8 月 24 日发布，签名提交对应版本标签，并提供多平台发布资产；但页面对本次 RC 的功能描述仅为修复与改进。因此，不能仅凭 RC 编号推断某个具体故障已经修复，也不能把它描述成稳定版。
真正影响升级决策的是 1.14 系列累积的配置语义变化。官方 Migration 文档为 1.14.0 单列了五类迁移：内联 ACME、DNS 地址过滤、独立 DNS 缓存、store_rdrc，以及 DNS 规则中 ip_version 与 query_type 的行为变化。这些项目应当逐项核对，而不是只看程序能否启动。
如果你此前已经跟随 beta 版本调整过规则集和 DNS，可以先回顾站内的 sing-box 1.14 beta 规则集与 DNS 核验指南；若配置由编辑器维护，也可配合 sing-box JSON Schema 配置校验方法找出字段拼写和结构问题。这里的编辑建议是：RC 阶段优先验证兼容性，不要同时重写全部路由策略。
四类配置需要重点检查
1. DNS 地址过滤要改为显式响应匹配
官方迁移页说明，DNS 规则里未配合 match_response 使用的旧 ip_cidr、ip_is_private 地址过滤字段已经弃用；引用仅含 IP CIDR 的规则集也可能在关闭旧 DNS 模式后被启动检查拒绝。1.14 的迁移方向是先用 evaluate 获取响应，再通过 match_response 明确匹配响应内容。
这不是简单的字段改名。规则的先后顺序、用于求值的 DNS 服务器、未命中后的去向都可能改变结果。先复制一份配置，只迁移一个规则组，然后检查常用域名、内网名称和仅有 IPv4 或 IPv6 的目标。想先理解 Fake DNS、远程 DNS 与 DoH 的职责边界，可参考 代理客户端 DNS 技术配置指南。
2. independent_cache 应移除
官方文档称 DNS 缓存现在始终按传输名称区分键，因此 independent_cache 已无必要，迁移方式是删除该字段。删除前仍应保留旧配置副本；如果升级后出现解析结果与预期不一致，应对照实际使用的 DNS transport、规则命中日志和缓存状态，而不是反复切换节点。
3. store_rdrc 改为 store_dns
store_rdrc 已弃用，官方给出的替代字段是 store_dns，后者把完整 DNS 缓存持久化到缓存文件。两者含义并非完全相同，因此迁移后要验证重启前后解析是否符合预期，并留意旧缓存对测试结果的干扰。排障时可以在可控窗口清理测试实例的缓存，但不要在未备份的生产实例上边改字段边删除数据。
4. 内联 tls.acme 迁移到证书提供器
对于自建 Trojan 等启用 TLS 的入站，官方把内联 tls.acme 标为弃用，推荐迁移为 certificate provider。多数 ACME 字段可以移动到新的提供器结构中，也可以定义顶层证书提供器后由入站引用。迁移前记录域名、邮箱、DNS 挑战参数、证书存储路径与当前到期时间；迁移后不仅要确认进程启动，还要验证证书加载和下一次续期路径。
DNS 行为变化为什么可能“能启动但结果不同”
官方迁移文档指出，在 sing-box 1.14.0 中，DNS 规则的 ip_version 与 query_type 会作用于每一次 DNS 规则求值。旧版本中，一些不是直接来自客户端、也未指定具体 DNS 服务器的内部域名解析可能忽略这些字段；1.14 不再如此。涉及 route 的 resolve、某些端点自身域名解析或 SOCKS4 本地解析的配置尤其值得检查。
此外，把这些字段与旧地址过滤、旧 strategy 动作选项等混用，可能导致启动时被拒绝。这里需要区分官方事实和编辑判断：官方明确描述了行为与不兼容组合；“是否影响你的配置”取决于实际规则。最可靠的方法是搜索配置字段、运行当前二进制的配置检查，再用固定域名集合比较升级前后的解析与路由。
安全的升级与回滚清单
- 记录当前 sing-box 版本、运行平台、安装来源和服务启动方式。
- 备份二进制、完整 JSON 配置、规则集引用、证书与缓存文件；确认备份可读取。
- 搜索
tls.acme、independent_cache、store_rdrc、ip_cidr、ip_is_private、ip_version和query_type。 - 按照官方 Migration 页面逐项迁移，每完成一类就做一次配置检查，避免一次修改过多。
- 先在备用设备、容器或非关键实例运行 1.14.0-rc.1，不直接覆盖唯一生产实例。
- 验证启动日志、DNS 解析、规则命中、TCP 与 UDP 连接，以及使用 ACME 时的证书加载状态。
- 用 NetScope 网络诊断工具或等价的本地诊断方法记录升级前后 DNS、连通性与路径差异，但不要把单次结果当作性能结论。
- 若出现异常，保存日志与修改差异，恢复旧二进制和对应旧配置；不要让新二进制继续读取已部分迁移的混合配置。
Windows TUN 用户还应把此前的路由问题与本次 RC 迁移分开判断。站内的 sing-box 1.13.18 Windows TUN 修复核验指南可作为稳定分支对照，但不能证明 1.14 RC 在你的系统上具有相同行为。
常见问题
sing-box 1.14.0-rc.1 是稳定版吗？
不是。官方 GitHub 发布页将其标为 Pre-release。RC 通常表示进入发布候选阶段，但是否用于生产仍应依据变更、测试覆盖、第三方客户端兼容性和回滚能力判断。
从 1.13 升级一定会启动失败吗？
不一定。是否失败取决于配置是否包含被拒绝的旧字段组合；即使能启动，DNS 规则语义也可能改变。应先用备份配置做静态检查，再验证解析和路由结果。
只使用订阅配置，也需要检查迁移吗？
需要，但责任边界不同。订阅提供方可能生成 DNS、缓存或路由字段，而客户端外壳也可能暂未同步 1.14。先确认实际运行的核心版本并导出最终配置；无法查看最终配置时，等待客户端维护者明确支持通常更稳妥。
升级后 DNS 异常，应该先换节点吗？
不应把换节点作为第一步。先比较 DNS 规则、transport、evaluate 与 match_response 的顺序，检查缓存持久化和日志，再用固定域名测试。节点连通与 DNS 规则是不同层面的问题。
RC 发布是否意味着 1.14 正式版马上发布？
官方页面没有给出正式版日期，因此不能据此承诺时间。可以订阅官方 Release 与 Change Log，待稳定标签和对应说明出现后再重新评估。
官方来源与核验入口
- SagerNet，Release 1.14.0-rc.1 · SagerNet/sing-box · GitHub，2026-08-24：核验版本标签、预发布状态与发布日期。
- SagerNet，Migration - sing-box，访问于 2026-08-25：核验 1.14.0 的 DNS、缓存与 ACME 迁移规则。
- SagerNet，Change Log - sing-box，访问于 2026-08-25：核验 1.14 系列累计变化与版本说明。
关于作者
