Stash DNS 跟随规则打开后为什么域名还是命中异常？

它只解决 DNS 查询跟随规则选择的问题，不会自动修正错误 rule-set、旧 Override 或过多 DNS 服务器。先用同一域名同时看连接策略、DNS 结果和规则日志。

Stash iOS 上 DoQ 超时应该继续调参数吗？

先别调复杂参数。用 DoH、DoT 或普通 UDP nameserver 做对照；若只在 DoQ 失败，优先视为协议或服务端响应问题，再看 Stash 版本是否已包含超时修复。

classical text rule sets 能不能大量使用？

不适合大量堆叠。Stash FAQ 明确提醒大量 classical 规则集会显著增加内存占用；移动端优先把可拆的内容改成 domain 或 ipcidr。

Stash iOS DNS 跟随规则怎么开 | DoQ 超时、规则集和 Override 更新排查 2026

Stash 开了规则分流后，网页能进预期策略组，不代表 DNS 查询也一定跟着同一条规则走。尤其是 iOS 上同时堆了多个 nameserver、DoQ、远程 rule set 和 .stoverride 时，连接日志和 DNS 结果可能出现两套答案。

先判断是哪一类 Stash DNS 跟随规则问题？

现象	更可能原因	第一处检查
网页策略正确，DNS 返回不符合预期	DNS query following rules 未生效或规则未覆盖该域名	Stash 版本、DNS 设置、规则日志
只有 DoQ nameserver 经常超时	DoQ 服务端响应慢、移动网络抖动或旧版本缺陷	改用 DoH/DoT/UDP 做对照
更新 rule set 后部分域名忽左忽右	rule set 类型混用、classical 文件过多或旧缓存	rule-providers、behavior、更新时间
Override 更新后策略命中变化	覆写改了 rules、proxy-groups 或 DNS 段	最近更新的 `.stoverride`
一键更新后某个 Override 不生效	同名 Override、安装失败或缓存残留	Override 列表、名称、更新时间

这张表的重点是把「DNS 查询」和「网页连接」拆开看。一个域名至少记录 3 个信号：DNS 查询进入哪个策略、最终连接进入哪个策略、规则日志命中了哪条规则。

DNS query following rules 到底解决什么？

Stash iOS release notes 在 v2.6.0 记录了「DNS query following rules」。对应到配置里，核心开关是 dns.follow-rule：默认关闭时 DNS 查询直接发出；设置为 true 后，DNS 查询才按代理规则转发。

dns:
  enable: true
  follow-rule: true

这不是万能加速项，Stash DNS 文档也提醒只在必要时启用，因为它可能影响 CDN 优化并带来一点延迟。它解决的是「解析请求走哪边」的问题，不解决「规则写得对不对」的问题。如果 DOMAIN-SUFFIX,example.com,Proxy 没覆盖到 api.example.net，DNS 跟随规则也不会凭空命中。

还有一个容易踩的点：如果代理端点或 DNS 服务器本身写成域名，先确认不会触发递归解析。排错阶段能用 IP 写清楚的上游就先用 IP，等规则稳定后再恢复长期配置。

排查时建议只拿 1 个域名做样本。例如固定测试 api.example.net，连续查看 DNS 日志、连接记录和最终策略组。不要一边换域名，一边换 DNS，一边改 Override；这样只会把证据打散。

iOS 上 DNS 服务器为什么要控制到 1-2 个？

Stash 的高效配置 FAQ 给了很实用的移动端原则：DNS 服务器不要堆太多，移动端建议 1-2 个。原因是 Stash 会并行查询配置的 DNS，服务器越多，资源消耗和排错分支越多。

一个排错基线可以这样写：

dns:
  enable: true
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://doh.pub/dns-query

这不是说只能用这两个地址，而是先让变量变少。若你同时写了 4 个 DoH、2 个 DoT、1 个 DoQ 和 fallback，某个域名解析结果变化时，很难判断是谁返回了差异结果。

DNS 配置	移动端排错价值	风险
1 个普通 UDP	最容易判断是否为 Stash 规则问题	加密能力弱，适合短时对照
1-2 个 DoH/DoT	兼顾可用性和排错清晰度	仍要看服务端响应速度
多个 DoH + DoT + DoQ	看似冗余，实际变量过多	并行查询、缓存和超时更难定位
大量 fallback	适合复杂网络，不适合第一轮排错	返回结果可能前后不一致

DoQ 超时要先换 DNS 还是先升级 Stash？

先做协议对照，再看版本。Stash iOS v2.6.0 release notes 里有「Fixed an issue with DNS over QUIC response timeouts」，中文更新日志也写了修复 DoQ 响应超时的问题。这个事实说明 DoQ 超时曾经是客户端层面记录过的修复项。

实操顺序是：

保留同一个测试域名和同一条规则。
把 DoQ nameserver 暂时换成 DoH 或 DoT。
如果 DoH/DoT 正常、DoQ 异常，再检查 Stash 是否为较新版本。
如果三种协议都异常，再回到规则集、Override 和系统网络。

不要把 DoQ 超时直接归因给规则分流。DNS 协议握手、移动网络、服务端响应和客户端版本都可能让 DoQ 看起来像「规则没跟随」。

classical text rule sets 什么时候该少用？

Stash v2.6.0 加入 classical text rule sets 支持，这让一些旧 Clash 规则文本更容易接入。但 Stash FAQ 同时提醒：大量 classical 规则集会明显增加内存压力，移动端更推荐 domain / ipcidr 规则集。

可以按下面的规则整理：

规则集类型	适合放什么	Stash iOS 建议
domain	域名、后缀、关键词类规则	首选，适合大多数站点分流
ipcidr	IP 网段规则	首选，和域名规则分开管理
classical	混合 DOMAIN、IP-CIDR、PROCESS 等旧格式	少量保留，别当通用容器
script / rewrite 相关覆写	需要 Stash 特有能力的修改	单独放 Override，便于禁用

如果一个 classical 文件里既有域名又有 IP，又被多个 Override 引用，DNS 命中异常时很难判断是解析阶段、规则匹配阶段还是覆写阶段出错。先把能拆的规则拆成 domain 和 ipcidr，排错会清楚很多。

Override 一键更新后怎么排查域名命中变化？

v2.6.0 release notes 还记录了「one-click update for all overrides」和「same-name Override install fix」。这两个点很容易被忽略：Override 更新能力增强后，旧覆写、同名覆写、缓存和规则集同时变化，域名命中就可能看起来忽然变了。

推荐按这个顺序排：

在更新前导出当前 Profile 或至少截图 Override 列表。
使用一键更新全部 Override 后，记录更新时间。
只拿一个失败域名复测，不要换测试样本。
禁用最近更新的 Override，观察 DNS 和连接策略是否回到旧表现。
若存在同名 Override，改名后重新安装，避免误判当前启用的是旧文件。

Override 最容易改到 dns、rules、rule-providers、proxy-groups 四块。只要其中一块被替换，DNS 查询跟随规则的结果就会跟原订阅不同。

哪些不是 Stash 配置问题？

有些现象不是 Stash DNS 跟随规则本身能修的。比如订阅源返回 HTML 登录页、远程 rule set 的 raw 地址 404、网络出口频繁切换、DNS 服务商对 DoQ 响应慢，这些都在 Stash 配置外面。

跨设备维护时，最怕的是 iPhone、iPad、Mac 各用一份不同模板：一台开 DoQ，一台堆 fallback，一台覆盖 Override。此时排错不是看谁「更快」，而是先选一份兼容 Clash / Singbox / V2Ray 的订阅做基线输入，再逐台确认 Stash 本机的 DNS、规则集和 Override 差异。

也不要把「测速失败」当成 DNS 故障。测速请求可能走的是固定 URL，不能代表所有域名的 DNS 查询都跟随规则。要用真实失败域名复测。

如何确认 Stash DNS 已经恢复？

修完以后，不看一句「能打开」就结束。用同一个域名做 3 轮验证：

验证项	正常信号	异常信号
DNS 日志	查询进入预期策略或预期 nameserver	同一域名前后进入不同路径
连接记录	Web 请求进入预期策略组	DNS 对了，连接落到兜底
rule set 时间	rule-provider 更新时间已变化	仍显示旧缓存时间
Override 状态	最近更新的覆写可单独禁用复现差异	禁用后无变化但日志仍引用旧名称
DoQ 对照	DoH/DoT/DoQ 结果能解释	只有 DoQ 超时且版本较旧

最后保留一行记录：Stash 版本、iOS 版本、测试域名、DNS nameserver 数量、启用的 Override 名称、失败前后的规则集更新时间。下次更新 rule set 或 Override 时，这行记录比重新猜一遍快得多。

FAQ

Stash DNS 跟随规则必须打开吗？

如果你依赖规则分流处理不同域名的解析路径，就应该确认该能力可用。只做简单全局代理时，它的收益没那么明显，反而更要保持 DNS 配置简单。

DoQ、DoH、DoT 哪个更适合 Stash iOS？

排错阶段优先用 DoH 或 DoT 做基线，因为可用性和日志判断更直观。DoQ 可以保留为长期选项，但一旦出现超时，先用同一域名切回 DoH/DoT 对照。

为什么 rule set 更新成功，DNS 还是旧结果？

rule set 更新成功只说明文件被拉取，不代表 DNS 缓存、Override 引用和规则命中都变了。重启 Stash、清理相关缓存，再用固定域名查看日志。

classical text rule set 和 domain rule set 能混用吗？

可以混用，但不要把 classical 当作所有规则的容器。移动端配置越重，内存压力越大；能拆成 domain 和 ipcidr 的内容尽量拆开。

Override 一键更新安全吗？

功能本身是为了减少逐个更新的成本，但批量更新会让多个变量同时变化。第一次排错时先记录旧列表；出问题后按最近更新时间逐个禁用，而不是立刻重装 Stash。