ruleset/config/stash/111.MD

💡 direct-nameserver: - system direct-nameserver-follow-policy: false stash ios客户端支持吗

Stash iOS 客户端部分支持该字段，具体取决于你的版本。 由于 Stash 的内核深度兼容 Mihomo (Clash.Meta) 语法，这两个字段的支持情况如下：

1. direct-nameserver结论：支持。说明：Stash 早已支持该字段。当你配置 - system 时，针对 DIRECT（直连）出口的域名，Stash 会直接使用 iOS 系统当前网络（如 Wi-Fi 或蜂窝网络）的底层 DNS 进行解析。
2. direct-nameserver-follow-policy结论：较新版本支持。说明：该字段属于 Mihomo 较新引入的 DNS 进阶特性（默认值为 false）。如果你的 Stash 客户端保持在较新版本，它能够正常识别并读取该配置。

💡 nameserver-policy: 'geosite:geolocation-!cn': ['tls://1.1.1.1', 'tls://8.8.8.8'] #🚀节点选择这个规则是不是无效的，nameserver‑policy 执行时机：DNS 请求刚进来，只有域名，还没有解析出 IP。 geolocation‑!cn 需要拿到解析后的 IP 才能判断 “是不是境外”，DNS 阶段没有 IP 数据，**完全无法完成匹配，这条 key 永远不会命中任何域名， 我的理解有问题吗，我需要删除这条规则吗

你的理解完全正确！在概念和原理上，你抓住了网络分流最核心的痛点。 你分析得非常准：nameserver-policy 发生在 DNS 解析前（只有域名），而类似 geoip:cn 这种规则，必须要先拿到 IP 地址 才能进行地理位置判断。 但是，在这条特定规则里，有一个绝大多数人都容易混淆的细节： 核心误区：你把 GEOSITE 和 GEOIP 搞混了❌ GEOIP： 基于 IP 的地理位置划分（需要先解析出 IP，DNS 阶段确实无法直接使用）。 GEOSITE：基于 域名 的分类预设列表。它不需要 IP！ geosite:geolocation-!cn 是由 V2Ray / Mihomo 社区维护的一个域名列表文件（文本文件）。 这个列表中收集了数万个明确属于海外（非中国大陆地区）的域名（例如 google.com、youtube.com、twitter.com）。 虽然名字叫 geolocation-!cn（地理位置非中国），但它本质上是一堆域名的死数据，而不是动态去探测 IP。

💡 结论：这条规则不是无效的，它能正常命中当一个 DNS 请求（比如 youtube.com）进来时： Stash 会去翻内置的 geosite 数据库。 发现 youtube.com 赫然写在 geolocation-!cn 这个域名列表里。 匹配成功！Stash 就会用你指定的 tls://1.1.1.1 去解析它。 所以，你不需要删除它，它是可以正常工作的。

💡 为什么现在不推荐这么写？（优化的理由） 虽然这条规则有效，但从配置优化的角度来看，依然建议你精简或修改它。

1. 体积过大，浪费手机内存（iOS 痛点）geolocation-!cn 包含了几乎大半个国外的域名，列表极大。iOS 客户端（如 Stash）受到系统 Network Extension 的严格内存限制（通常不能超过 50MB）。在 DNS 阶段让 Stash 去反复匹配这么庞大的域名数据库，会增加内存开销和解析延迟。
2. 逻辑重复（如果是 Fake-IP 模式）如果你使用的是 enhanced-mode: fake-ip：国外域名的 DNS 解析结果在本地根本不重要，因为 Stash 会直接返回一个 198.18.x.x 的虚假 IP。真正的 DNS 解析是在你远端的代理服务器上完成的。在本地大费周章用加密 DNS（DoT）去解析国外域名，属于“脱裤子放屁”，没有任何实质收益。

🛠️ 最佳实践：怎么改最清爽？ 在目前主流的 Fake-IP 架构下，DNS 的核心原则是：“国内域名精准分流，国外域名不闻不问（交给默认/代理处理）”。 建议将你的 nameserver-policy 精简为只管国内和局域网，其余放行： nameserver-policy:

局域网和国内域名，用国内最快的传统 DNS 解析（保证国内 cdn 体验）

  "geosite:private,cn":
    - 223.5.5.5
    - 119.29.29.29

至于国外的域名，直接不写。

它们会自动走到你的默认 nameserver 或者直接被 fake-ip 接管，省电、省内存、速度最快。

这样修改后，Stash 只需要常驻一个很小的国内域名审计表（geosite:cn），手机会显著更省电、更稳定。

💡 放行后走哪个dns解析国外域名，nameserver吗 是的，完全正确。放行（不写）后，国外域名默认会走你的 nameserver 进行解析。 在 Stash (Mihomo) 的 DNS 匹配逻辑中，有一套极其严格的兜底和优先级链条。当一个国外域名进来时，它的解析流程如下： 🔄 国外域名的 DNS 匹配三步走第一步：

1. 看 nameserver-policy（特需分配）
   1. Stash 检查这个域名在不在你指定的 geosite:cn 或 geosite:private 列表里。
   2. 结果：它是国外域名，不在列表里，未命中，放行.
2. 第二步：看 fallback-filter（如果配置了 fallback）
   1. 如果你配置了 fallback 服务器和对应的过滤规则（如 geoip 或 ipcidr），Stash 可能会同时并发向 nameserver 和 fallback 发起请求，并根据解析出来的 IP 是否是国外 IP 来决定用谁的结果。
3. 第三步：默认兜底（最终归宿）
   1. 如果没有触发任何特殊过滤，它就会完全由 nameserver 列表中的 DNS 服务器来负责解析。

⚠️ 关键看点：你用的是 Fake-IP 还是 Redir-Host？ 国外域名虽然落到了 nameserver 上，但在不同模式下，手机的实际网络动作完全不同： 模式 A：如果你是 fake-ip（强烈推荐） 实际过程：Stash 收到国外域名请求后，根本不会真的去问 nameserver，而是直接在手机本地生成一个假的 IP（如 198.18.0.5）返回给系统。 远端解析：真正的 DNS 解析请求，会被加密打包发送到你的海外代理节点，由代理节点在海外当地去解析（比如在新加坡节点上解析 Google）。 结论：在这种模式下，本地的 nameserver 填什么都无所谓，它只是一个“摆设”，完全不影响国外网站的访问速度和防污染效果。 模式 B：如果你是 redir-host 实际过程：Stash 真的会拿着这个国外域名，去向你的 nameserver（通常是国内 DNS 如 223.5.5.5）发起查询。 痛点：国内 DNS 查询国外域名，100% 会遭遇 DNS 污染，返回一个错误的 IP，导致你无法翻墙。 如何解决：如果你坚持用 redir-host，你就必须配置 fallback（填入 tls://1.1.1.1 等海外加密 DNS），或者在 nameserver 里直接填入无污染的海外 DoT/DoH 服务。 🛠️ 最终配置抄作业（以 Fake-IP 为例）

dns:
  enable: true
  enhanced-mode: fake-ip
  
  #### 直连域名（如被 direct 规则命中的域名）去这里解析
  direct-nameserver:
    - system
    - 223.5.5.5
    
  #### 默认的名称服务器：主要用于解析策略组里的“节点域名”（如 ://example.com）
  #### 以及未命中 policy 的域名兜底（fake-ip 下仅做占位和基础解析，绝不影响翻墙）
  nameserver:
    - 223.5.5.5
    - 119.29.29.29

  #### 精准策略：只把中国大陆的域名和局域网挑出来，给国内 DNS 快速解析
  nameserver-policy:
    "geosite:private,cn":
      - 223.5.5.5
      - 119.29.29.29

💡 会被加密打包发送到你的海外代理节点，按怎么规则走代理节点，如果我有20个国家代理节点，随机的吗

不是随机的，它是严格按照你的分流规则（rules）以及你选择的策略组（Proxy Groups）来决定的。 当 Fake-IP 帮你的手机拿到假 IP 并建立连接后，Stash 会把带有真实域名的流量扔进它的路由引擎（Rules 模块）进行匹配。 以下是流量到底走这 20 个国家中哪一个的完整决定过程： 🗺️ 第一步：看你的规则（rules）匹配到哪条 Stash 会从上到下一行一行匹配你的 rules。不同的规则会把你引向不同的策略组（也就是装有你节点的“篮子”）。 情况 A（命中特定国家）：

rules:
  - DOMAIN-SUFFIX,netflix.com,新加坡节点

如果访问 Netflix，它就会强行走到名为“新加坡节点”的策略组。

情况 B（命中通用海外）：

rules:
  - GEOSITE,geolocation-!cn,🟢 境外流量

如果访问 Google，它会走到你定义的通用海外策略组“🟢 境外流量”。

情况 C（没命中任何规则，兜底）：

rules:
  - MATCH,🐟 漏网之鱼

如果没有任何规则认识这个域名，它会走到最后的兜底策略组。

🎛️ 第二步：看对应策略组的“选择模式”（决定具体哪一个） 流量进到策略组后，到底挑 20 个国家里的哪一个，取决于你对这个策略组设置的 类型（type）：

1. 自动测试延迟模式（type: url-test）—— 最常用 机制：Stash 会在后台悄悄地对这 20 个节点进行延迟测试（每隔几分钟测一次）。 结果：谁的延迟最低，所有流量就自动全部走谁。 直到下次测试发现有更快的节点，才会切换。

2. 手动选择模式（type: select） 机制：你在 Stash 客户端的界面上，手动点击勾选了哪个国家的节点。 结果：绝对只走你选中的那一个。 你选日本就全走日本，你选美国就全走美国。

3. 负载均衡模式（type: load-balance） 机制：这 20 个节点被当成了打工人，共同分担流量。 结果：Stash 会用轮询（Round-Robin）或者哈希（Consistent-Hash）算法把连接分发给不同国家。只有在这种特定的极少数模式下，看起来才像是在“随机/轮流”使用不同国家。（但由于会频繁变动 IP，极易导致境外网站封号，普通用户不建议使用）。

💡 总结 你的 20 个节点绝不是无序乱撞。网络请求就像一件快递： Fake-IP 是打包员，把目的地写上真实域名。 Rules（规则） 是分拣员，根据域名决定把快递放进哪个策略组箱子（比如放进“境外流量”箱）。 策略组类型 是货车司机：如果设置是 select，就由你指定的车运走；如果设置是 url-test，就由开得最快的那辆车运走。

💡 如果我在rule-providers:启用了geolocation-!cn，比如1万条域名，并rule规则指定了代理组，那么本身就占用了手机内存，然后又在policy中添加了geosite:geolocation-!cn,是不是内存就不会翻倍了？ 是的，你的理解非常到位！内存不会翻倍。 在 Stash（包括 Mihomo 内核）的底层设计中，无论你在配置文件的多少个地方引用同一个数据库（比如 geosite 或 rule-providers 里的同一个文件），它在手机内存中只会被加载和解析一次。 所有的策略模块（rules 和 dns）都是通过“内存指针”去共享读取同一份数据，所以不会产生双倍的内存开销。

⚠️ 但是！这依然会引发另外两个潜在的“性能隐患” 虽然内存体积没有翻倍，但你同时在 rules 和 dns 中对同一个庞大的 geolocation-!cn 列表进行全面审计，依然属于低效配置。它会带来以下两个问题： 隐患 1：CPU 算力浪费与解析延迟（虽然内存没炸，但速度慢了） DNS 阶段：一个国外域名（如 google.com）进来。Stash 的 DNS 模块要在 1 万多条数据里完整检索一遍，确认它在 geolocation-!cn 里，然后拿出你指定的海外 DNS 进行解析（如果是 Fake-IP 模式，甚至只是生成一个假 IP）。 路由分流阶段：拿到 IP 准备发数据了，Stash 的路由（Rules）模块又要在这个 1 万多条数据的列表里重新检索一遍，确认它在里面，然后分流到代理策略组。 后果：手机 CPU 要对同一个域名进行两次大列表的字符串匹配。在日常高频刷新网页或刷社交软件时，会带来微小的卡顿感和额外的耗电。

隐患 2：Fake-IP 模式下，DNS 阶段的检索完全是“无用功” 如果你使用的是 enhanced-mode: fake-ip： 国外域名的真实解析，永远发生在远端代理服务器上。 在手机本地，不管你用什么 DNS 去解析国外域名，Stash 吐给 iOS 系统的都只是一个本地的假 IP（例如 198.18.0.x）。 因此，在 nameserver-policy 里大费周章地把国外域名拦截下来，指定一个海外加密 DNS（如 tls://1.1.1.1），对翻墙速度、防污染、网络质量没有任何一丝一毫的提升。

🛠️ 终极省电、省内存的“无感翻墙”优化方案 最顶级的策略是 “DNS 阶段只抓国内，国外全放行；路由阶段精准分流”。 你可以把配置改成这样：

1. DNS 模块（极简、轻量）让 DNS 只去查包含几百个中国最常用域名的极小列表，其余全部放行。这样 DNS 匹配速度接近 0 毫秒：

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver-policy:
    #### 只针对国内域名进行精准 DNS 匹配，极小、极快
    "geosite:cn":
      - 223.5.5.5
      - 119.29.29.29
    #### 国外域名不写，直接放行触发 Fake-IP，绝不在这里浪费算力

2. Rules 路由模块（精准分流） 在这个阶段，再利用你的 rule-providers 去做大表的精准分流：

rules:
  #### 局域网和国内直连
  - GEOIP,lan,DIRECT,no-resolve
  - GEOSITE,cn,DIRECT
  
  #### 国外大表精细分流（在这里使用大列表是最合理的，因为必须决定流量走哪）
  - RULE-SET,geolocation-!cn,🟢 代理节点
  
  #### 兜底
  - MATCH,🐟 漏网之鱼

这样修改后，你的 DNS 阶段变得身轻如燕，只有在真正需要传输数据的路由阶段才会去检索大列表。手机的响应速度、耗电表现都会达到最佳状态。 你的 rule-providers 里的 geolocation-!cn 是通过 在线 URL 订阅 的，还是本地存放的 .yaml / .text 文件呢？我们可以检查一下它的更新频率（interval），避免频繁下载导致额外的流量消耗。

🛠️ 最佳配置：一刀切的终极完美方案 既然你已经拥有了高效率的 geolocation-!cn.mrs 路由规则，那么请立刻在 DNS 模块中删掉关于它的任何策略。 以下是为你量身定制的、兼顾“极致网速”与“极低内存”的完整配置结构：

dns:
  enable: true
  enhanced-mode: fake-ip  #### 核心：利用 Fake-IP 免去本地国外 DNS 解析
  
  nameserver:
    - 223.5.5.5
    - 119.29.29.29
    
  nameserver-policy:
    #### 极简：DNS 阶段只管国内域名，其余一律不看（直接吐出 Fake-IP）
    "geosite:cn":
      - 223.5.5.5
      - 119.29.29.29

rule-providers:
  geolocation-!cn:
    type: http
    behavior: domain
    format: mrs       #### 保持你优秀的二进制格式
    interval: 86400
    url: "https://gh.sswiwi.com/https://raw.githubusercontent.com/MetaCubeX/meta-rules-dat/meta/geo/geosite/geolocation-!cn.mrs"

rules:
  #### 1. 局域网和国内直连
  - GEOIP,lan,DIRECT,no-resolve
  - GEOSITE,cn,DIRECT
  
  #### 2. 路由阶段精准分流：在这里调用你高效的 MRS 规则集
  - RULE-SET,geolocation-!cn,🟢 代理节点
  
  #### 3. 兜底
  - MATCH,🐟 漏网之鱼

这样调整后的实际效果： 当访问国外网站（如 google.com）时，DNS 阶段 0 毫秒 瞬间返回 Fake-IP，不产生任何网络和 CPU 开销；随后流量进入路由阶段，Stash 用近乎零延迟的 .mrs 二进制算法瞬间精准分流到你的海外代理节点。这才是 Stash 在 iOS 端最高效的运行姿态。

除了国外域名，你的配置里有没有针对 国内特定服务（如 Apple 纯净分流、BT 下载、国内电商加速） 的 rule-providers 需求？如果有，我们可以用同样高效的 .mrs 格式帮你加进去。