Surge / Quantumult X / Loon 规则转换通用方案：三端互转与 Sub-Store 统一管理

最后更新于：2026年7月

iOS 上的三款代理客户端——Surge、Quantumult X（圈x）、Loon——功能都很强，但它们的分流规则格式互不兼容。很多用户在换手机、换 App，或者想把别人写好的精致规则集搬进自己的客户端时，都会卡在同一个地方：复制进去直接报错，或者导入后规则整段失效。

本文把这三端的规则语法差异、互相转换的手工方法、以及用 Sub-Store 实现「一套规则、多端通用」的终极方案，一次性讲透。无论你是从 Surge 迁到 Loon，还是想把 QX 规则搬进 Surge，都能在这里找到可直接照抄的模板。

一、为什么三端规则不能直接通用？

要搞懂转换，先搞懂它们的「血缘关系」：

• Surge 是 iOS 代理客户端的老祖宗之一，它定义的 DOMAIN-SUFFIX,example.com,Policy 这套语法，后来被很多人当成「事实标准」。
• Loon 在规则语法上高度克隆了 Surge（可理解为 Surge 4 兼容层），所以 Surge 的规则贴进 Loon 基本能跑——这也是为什么 Loon 用户迁移成本最低。
• Quantumult X 走了另一条路，它用 host-suffix,example.com,policy 这种「逗号三段、全小写动作」的写法，和 Surge 体系不是一回事，必须做格式翻译。
• Shadowrocket（小火箭） 则有自己独立的 .conf 体系（大写 PROXY/DIRECT），这部分在《Shadowrocket 规则集导入失败？》里专门讲过，本文聚焦上面三巨头。

一句话总结难度排序：

Surge ↔ Loon：近乎 1:1，最轻松 Surge/Loon ↔ Quantumult X：需要逐条翻译，最麻烦 任何一端 → Shadowrocket：见前文专文

二、四大客户端规则语法速查表（核心映射）

这是全文最重要的一张表。左边是「语义」，右边是各客户端对应的写法。注意动作（policy/出站）的大小写差异是报错重灾区。

三、Surge ↔ Loon 互转（最容易，近乎 1:1）

3.1 为什么几乎不用改？

Loon 的 [Rule] 段语法和 Surge 一模一样，连 [Proxy Group]、[Proxy]、[General] 这些段名都通用。真正的差异只有两点：

1. 策略组名：你订阅里的节点名、组名在两端可能不完全一致，需要统一重命名。
2. 远程规则集的写法：Surge 用 RULE-SET,url,Policy 直接写在 [Rule] 里；Loon 也支持这种内联写法，但 Loon 还有个独立的 [Remote Rule] 段（旧式），现代 Loon 已兼容内联写法，优先用内联即可。

3.2 Surge → Loon 实操

假设你有一段 Surge 规则：

[Rule]
RULE-SET,https://raw.githubusercontent.com/Loyalsoldier/surge-rules/release/reject.txt,REJECT
DOMAIN-SUFFIX,google.com,节点选择
DOMAIN-SUFFIX,youtube.com,节点选择
GEOIP,CN,DIRECT
FINAL,节点选择

直接贴进 Loon 的 [Rule] 段即可，几乎零改动。唯一要核对的是：节点选择、DIRECT、REJECT 这几个策略组 / 动作在 Loon 配置里确实存在。如果 Loon 里你的组叫 Proxy 而不是 节点选择，就把规则里的 节点选择 全局替换成 Proxy。

3.3 Loon → Surge 反向

同理，把 Loon 的 [Rule] 整段复制到 Surge 的 [Rule] 段，确认组名一致即可。但要注意：Loon 的「模块（.plugin）」和 Surge 的「模块（.sgmodule）」不互通，模块部分需要另找对应版本，不能一起搬。

四、Surge → Quantumult X（最难，需要逐条翻译）

QX 是真正需要「翻译」的一端。下面给一套可机械执行的替换规则。

4.1 规则行翻译对照

把 Surge 的每一行，按下面的映射重写（注意动作变小写）：

4.2 策略组（[Proxy Group] → [policy]）翻译

这是第二道坎。Surge 的 [Proxy Group] 段：

[Proxy Group]
节点选择 = select, 香港节点, 日本节点, DIRECT
自动选择 = url-test, 香港节点, 日本节点, url=http://www.gstatic.com/generate_204, interval=300, tolerance=100

翻译成 QX 的 [policy] 段（段名和语法都不同）：

[policy]
static=节点选择, 香港节点, 日本节点, direct
url-test=自动选择, 香港节点, 日本节点, url=http://www.gstatic.com/generate_204, interval=300, tolerance=100

差异要点：

• select → static
• = 前的组名移到 = 后第一个参数
• DIRECT → direct（小写）
• QX 的 static 末尾要带 direct 作为兜底（部分版本要求）

4.3 远程规则集（RULE-SET → filter_remote）

Surge 内联的 RULE-SET 行，在 QX 里要改成独立的 [filter_remote] 段：

[filter_remote]
https://raw.githubusercontent.com/Loyalsoldier/surge-rules/release/reject.txt, tag=广告拦截, force-policy=reject, enabled=true
https://raw.githubusercontent.com/Loyalsoldier/surge-rules/release/proxy.txt, tag=代理列表, force-policy=节点选择, enabled=true

然后在 QX 的 [filter] 或主配置里引用这些 tag。QX 的规则顺序是「先 filter_remote 里声明的，再主规则」。

4.4 完整示例（Surge → QX）

Surge 原版：

[Proxy Group]
节点选择 = select, 香港, 日本, DIRECT
[Rule]
DOMAIN-SUFFIX,google.com,节点选择
GEOIP,CN,DIRECT
FINAL,节点选择

翻译后的 QX 版：

[policy]
static=节点选择, 香港, 日本, direct

[filter_remote]
https://raw.githubusercontent.com/Loyalsoldier/surge-rules/release/direct.txt, tag=直连, force-policy=direct, enabled=true

[rule]
host-suffix,google.com,节点选择
geoip,cn,direct
final,节点选择

五、Quantumult X → Surge（反向翻译）

把第四节的映射反过来即可，重点提醒几处：

1. 动作全部大写：direct → DIRECT，reject → REJECT，proxy → 你的策略组名。
2. [policy] → [Proxy Group]，且 static= 改 select，组名从等号后挪到等号前：
   INI

   折叠 复制

   # QX
   static=节点选择, 香港, 日本, direct
   # Surge
   节点选择 = select, 香港, 日本, DIRECT

3. filter_remote → RULE-SET 内联行：把每个 filter_remote 条目翻译成 [Rule] 段里的一行：
   INI

   折叠 复制

   RULE-SET,https://raw.githubusercontent.com/.../reject.txt,REJECT

4. QX 的 url-test / fallback 语法和 Surge 基本一致，段名改回 [Proxy Group] 后通常可直接复用。

六、策略组（Policy Group）转换要点

策略组是「规则指向的目标」，转换时最容易出「规则引用了不存在的组」这种错误。三端的策略组类型对照：

关键检查：转换完务必「全文搜一遍」——每条规则里出现的策略组名，都必须在 [Proxy Group] / [policy] / [Proxy Group] 里有定义。漏一个，那部分流量就会按 FINAL 处理，甚至直接断流。

七、用 Sub-Store 实现跨客户端统一管理（终极方案）

手工逐条翻译只适合「一次性小规则」。如果你维护的是长期、多端、带远程规则集的配置，正确做法是上 Sub-Store——一个订阅管理器，核心理念是：

一份节点订阅 + 一套远程规则集 → 一键输出成 Surge / QX / Loon / Clash / 小火箭 任意格式

你再也不用为「换客户端就重写规则」头疼。

7.1 部署（Docker 一行起）

docker run -d --name sub-store -p 8080:8080 -v /your/path:/data \
  xream/sub-store:latest

浏览器打开 http://你的IP:8080 即可使用 Web 面板。

7.2 工作流

1. 添加订阅（Subscriptions）：把你机场的订阅链接粘进去，Sub-Store 会解析出节点。
2. 添加远程规则集（Collections → Artifacts / 过滤器）：把 Loyalsoldier、ACL4SSR 等规则集 URL 加为「过滤器」，它们会被自动附加到输出里。
3. 创建集合（Collections）并选择目标格式：
   • Target 选 surge → 生成 Surge 用订阅链接
   • Target 选 quantumult-x → 生成 QX 用链接
   • Target 选 loon → 生成 Loon 用链接
   • Target 选 shadowrocket → 生成小火箭用链接
4. 各客户端订阅对应的链接：以后规则集更新、节点变动，只需要在 Sub-Store 里改一次，所有端同步生效。

7.3 为什么比手工强？

• 格式自动翻译：Sub-Store 内置了各端语法映射，你不用记 host-suffix 还是 DOMAIN-SUFFIX。
• 规则集自动对齐：远程规则集按各端语法重新生成，不会出现「QX 里写了 RULE-SET」这种低级错误。
• 节点名统一：Sub-Store 可以给节点重命名、分组，解决「换端组名对不上」的问题。
• 多端零重复维护：一套源，N 端输出。

八、常见转换陷阱与 Debug 清单

按出现频率排序，遇到「规则失效 / 导入报错」先照这个查：

1. 动作大小写错（最高频）：Surge/Loon 用 DIRECT/REJECT，QX 用 direct/reject。
2. 策略组名不存在：规则里写了 节点选择，但 [Proxy Group] 里叫 Proxy。全文搜索核对。
3. IP-CIDR 漏 no-resolve：在 Surge/Loon 里，IP 规则建议写 IP-CIDR,1.2.3.0/24,Policy,no-resolve，否则会先尝试 DNS 解析导致误匹配或泄露。
4. GEOIP 无数据库：GEOIP,CN 需要客户端内置或配置 GeoIP 数据源，缺失会导致该规则永不命中。
5. RULE-SET / filter_remote URL 失效：远程规则集 404 或格式变了，整段规则被跳过。建议用 Loyalsoldier 等活跃维护的源。
6. QX 里写了 RULE-SET 内联：QX 不认内联 RULE-SET，必须放 [filter_remote]。
7. DNS 嗅探未开导致分流失效：部分客户端（尤其小火箭）需要开 DNS Sniffing，才能从加密流量里还原域名重新分流。
8. 模块 / 脚本不互通：Surge 的 .sgmodule、Loon 的 .plugin、QX 的 .js 重写脚本互相不兼容，规则能转，脚本得单独找对应端版本。

九、推荐工作流总结

• 只用 Surge + Loon：以 Surge 语法为母本，Loon 直接复用，零转换成本。
• 涉及 Quantumult X：准备一套「翻译对照表」（本文第二节），或者干脆用 Sub-Store 自动出 QX 格式，别手工硬改。
• 长期多端维护：直接上 Sub-Store，一份源输出全端，规则集更新一处搞定。
• 一次性小规则：用在线 subconverter（如 sub.tsutsu.one）选目标格式一键转，转完务必按第八节自查一遍。

记住一个核心原则：分流规则的本质是「匹配条件 + 出站动作」，三端只是把这两件事用不同语法包装。搞懂了映射关系，任何一端都能驯服。

相关推荐

• Shadowrocket 规则集导入失败？一文解决圈 x/Loon 规则转换与防污染冲突
• 代理分流规则完全指南：从原理到多客户端实战配置
• iOS 快捷指令 + 代理自动化实战：一键切换、自动签到与无感分流
• Surge macOS 完全配置指南（2026）