Quantumult X 规则 2026：配置导入、分流优先级与失效排查

更新于 2026-11-02 · v2xo.shop

简答：Quantumult X 规则配置不能只复制一段分流列表：至少要同时确认策略名称、节点资源、规则资源和 Final 兜底是否存在。最快的做法是先备份当前配置，再只启用一个已知可访问的节点订阅和一条本地规则，确认请求记录能看到命中的规则与最终策略后，再逐步加入远程规则。本文按 2026 年 11 月 2 日可核验的官方 sample.conf 结构整理，版本号本身请以当前 App Store 页面为准。

定义：Quantumult X 规则是按域名、IP、用户代理等条件匹配网络请求，并将请求交给 direct、某个节点或其他策略的配置条目；节点订阅、分流规则和重写脚本属于不同资源。

先试这一步：用最小配置确认规则链路

本文是第三方使用指南，不是该客户端的官方网站。先在 Quantumult X 中导出或复制当前配置作为备份，不要直接覆盖原文件。官方 sample.conf 将配置拆分为 [general]、[dns]、[policy]、[server_remote]、[server_local]、[filter_local]、[filter_remote] 和 [rewrite_remote] 等区段；官方样例没有独立的 [proxy] 区段，因此不要把其他客户端的 [proxy] 段直接粘贴进来。可先参考官方 sample.conf 中的区段和字段示例。

如果只是想测试语法，可使用下面的结构示例。它不会提供可用节点，也不能直接连接；所有尖括号内容都必须替换，示例中的域名、账号、密码和远程地址均为占位符。

[general]
server_check_url = http://example.com/check

[policy]
static = Proxy, NODE_TAG

[server_remote]
https://your-subscription.example/sub, tag=SUBSCRIPTION_TAG, enabled=true

[filter_local]
host-suffix, example.net, Proxy
host-suffix, local.example, direct
final, Proxy

其中 NODE_TAG 必须与节点或订阅解析后的 tag 一致，Proxy 必须与 [policy] 中的策略名称一致。若这两个名称不一致，配置可能能够保存，但规则不会按预期分流。

2026 年规则配置应先分清四类资源

1. 节点资源：[server_local] 用于写入本地节点，[server_remote] 用于加载远程节点片段或订阅。官方样例在 [server_remote] 中展示了远程地址、tag、opt-parser、update-interval 和 enabled 等参数。远程地址返回的内容必须符合 Quantumult X 能解析的节点格式，不能仅凭“订阅链接能打开”判断格式兼容。

2. 策略：[policy] 负责把策略名称映射到一个或多个候选节点。官方样例列出了 static、available、round-robin、ssid、dest-hash 和 url-latency-benchmark 等类型。static 适合手动固定节点；available 会在候选节点中选择可用项；其他类型应根据实际用途逐项验证，不要把策略类型名称当成速度保证。

3. 分流规则：[filter_local] 写本地规则，条件可以是 host、host-suffix、host-keyword、IP 段、geoip 等，末尾通常需要保留 final 兜底。[filter_remote] 用来加载远程规则资源，可附加 tag、force-policy 和 enabled。官方 sample.conf 明确说明，设置 force-policy 后，远程规则文件中原本写入的策略会被忽略，改用该条目的 force-policy；这是字段功能说明，不等于所有规则冲突都由该字段造成。

4. 重写脚本：[rewrite_remote] 和本地重写规则处理的是请求、响应或脚本逻辑，不等于分流规则。没有明确用途时可以不启用 MitM、证书或重写脚本。官方 rewrite 示例展示了请求头、响应体和 JavaScript 重写形式，使用前应确认脚本来源、匹配范围和隐私风险，避免把重写资源当作普通分流列表导入。

截至 2026 年 11 月 2 日，本文不写未经官方页面实际核验的客户端版本号。当前版本、系统要求和菜单名称请在 App Store 与应用内页面再次核对。

Quantumult X 规则导入步骤：备份、导入、启用、验证

1. 备份：先导出当前配置，至少保留原始配置文件和远程资源列表。不要在未备份时同时替换节点、规则、DNS 和重写。
2. 确认节点入口：先单独添加节点订阅到 [server_remote]，或使用应用内的远程资源入口。导入后观察是否生成节点 tag；没有节点 tag 时，先处理订阅格式或解析问题，不要继续排查分流。
3. 建立策略：在 [policy] 中使用已经出现的节点 tag。策略名和节点名区分大小写、空格及符号时，应以列表中实际显示的名称为准。
4. 加入一条本地规则：先只加入一条容易识别的 host-suffix 或 host 规则，并把它指向已经存在的策略。不要一开始导入几十个远程资源。
5. 启用 Tunnel：在应用内启用 Quantumult X Tunnel。具体菜单名称可能随系统和客户端版本变化，以当前界面为准。
6. 观察请求记录：打开请求记录或活动记录，记录测试域名、命中的规则类型、最终策略、节点 tag、DNS 结果和错误信息。只看到出口 IP 变化，不能单独证明每个应用和每个域名都按照预期分流。
7. 加入远程规则：确认本地规则生效后，再将规则移动到 [filter_remote]。每次只加入一个远程资源，更新后检查资源状态、规则数量或请求命中情况。
8. 复测并回滚：分别测试直连域名、需要代理的域名和未列入规则的域名。若新增资源后出现连接异常，先禁用最近加入的条目，再恢复备份配置。

官方 URL Scheme 文档还展示了通过 add-resource 或 update-configuration 添加远程资源的结构，但其中的示例地址只是官方演示资源，不代表适合你的实际配置；可参考官方 URL Scheme 文档中的远程资源字段。

规则优先级、force-policy 与 Final 怎么判断

本地规则的核心是“先匹配具体条件，再由后续兜底处理未命中请求”。例如，同一域名同时符合 host-suffix 和较宽泛的关键词条件时，应先保留更具体、目的更明确的规则，并在请求记录中确认最终策略。不要只根据配置文件的视觉顺序推断结果，必须用一个明确域名实际请求验证。

force-policy 的含义要单独看待：官方 sample.conf 说明它会让远程规则文件中定义的策略被忽略，并使用当前远程资源条目指定的策略。因此，如果远程规则原本想把不同域名分到不同策略，给整个资源设置一个统一的 force-policy 可能会改变该资源的策略安排。这里是字段行为推断，最终仍应以请求记录中的命中规则和最终策略为准。

final 是未匹配规则的兜底条目。官方样例使用 final, proxy 作为最后一条规则。实际使用时，proxy 必须替换成你自己的策略名称；如果写成不存在的名称，未匹配请求就可能失败或表现异常。若希望默认直连，应使用已经存在的 direct 策略或当前版本支持的对应策略写法，并先用请求记录验证。

不要把“节点延迟低”直接等同于“规则一定生效”。官方 sample.conf 说明节点检查使用测试网址进行 HTTP 响应性测试，显示的延迟是测试请求的响应时间；它只能帮助判断测试路径，不能证明所有域名、DNS 查询和应用请求都采用同一策略。

常见失效场景：从资源、策略、规则三层分流

官方 sample.conf 的 [general] 还涉及 server_check_url、DNS 排除、UDP 列表和路由排除等选项。修改 DNS 或 UDP 相关字段后，应记录修改前后的请求表现；不要用一次网页打开结果断言 DNS 或全部流量已经按预期处理。

基础版与进阶版：先稳定分流，再增加资源

基础版适合：只有一个节点订阅、需要少量国内直连和指定域名策略、希望方便回滚的用户。配置只保留一个策略组、少量本地规则和一条 Final，暂时不加入脚本、MitM 和大量远程规则。

进阶版适合：需要按办公系统、流媒体、不同网络环境或多个节点进行分组的用户。可以使用多个策略和远程规则，但应为每个资源记录来源、更新时间、启用状态、策略覆盖方式和回滚方法。远程规则的维护状态无法仅凭链接名称判断，导入前应查看资源内容、最近提交或维护说明；查不到的维护状态写“未核实”。

规则来源方面，优先对照官方 sample.conf确认字段结构，再检查第三方规则仓库的原始文件、提交时间和实际内容。不要因为某个页面标题写着“2026 最新”就直接判断资源仍然可用，也不要把别人配置中的节点、策略名和脚本一起复制。

如果你只需要基础分流，可以完全不启用 MitM。官方 sample.conf 提醒应妥善保管 CA 密码和 p12 私钥；因此，除非确实需要处理 HTTPS 重写并理解证书风险，否则建议保持相关配置关闭。

一分钟复测清单

• 是否已经备份原配置？
• 节点订阅是否生成了实际节点 tag？
• [policy] 中的策略是否引用了存在的节点 tag？
• 本地或远程规则是否指向存在的策略名称？
• 是否保留了有效的 final 兜底？
• 请求记录能否看到命中的规则、最终策略和错误原因？
• 新增远程资源后是否逐个复测，而不是一次性导入全部资源？
• 是否把 DNS、IPv6、应用内请求和节点延迟分开判断？
• 是否能通过禁用最近修改的条目恢复连接？

如果以上项目只有节点延迟测试通过，但请求记录、DNS 或应用连接仍异常，不要直接得出“规则已经生效”的结论，应回到资源格式、策略名称和实际命中结果逐层排查。

常见问题 FAQ

Quantumult X 有没有一个 2026 年通用可用的完整配置？

没有一份可以对所有用户直接使用的通用配置。完整配置至少依赖节点地址、认证信息、策略名称、规则来源和当前客户端语法；本文只提供可替换占位符的结构示例，不提供可用节点，也不保证任何第三方远程资源长期有效。

为什么订阅能打开，但导入后没有节点？

能打开订阅地址只说明请求取得了内容，不代表内容格式能被当前客户端解析。先查看远程资源返回内容是否是 Quantumult X 可识别的节点片段，再检查 tag、解析器选项和资源启用状态；必要时删除该资源，用一个已知格式的本地节点测试。

配置中为什么找不到 [proxy] 区段？

官方 sample.conf 展示的是 [server_local]、[server_remote] 和 [policy] 等区段，并没有独立的 [proxy] 区段。不要把其他客户端的配置段直接复制过来，应按 Quantumult X 当前 sample.conf 的字段结构重新映射节点和策略。

force-policy 会不会让远程规则失效？

它不一定让规则条件失效，但官方说明显示，设置后远程资源内部定义的策略会被忽略，改用 force-policy 指定的策略。若出现策略结果与远程文件说明不一致，应先检查该字段，再通过请求记录确认最终策略。

是否必须开启 MitM 和证书才能使用分流规则？

不必须。普通域名分流和节点策略可以先独立验证；MitM 主要涉及 HTTPS 请求处理、证书和重写功能。没有明确重写需求时建议关闭，避免引入额外证书和隐私风险。

只看出口 IP 能证明规则配置成功吗？

不能。出口 IP 只能反映某一次请求的外部地址，不能证明其他应用、DNS 查询、IPv6 请求或所有域名都使用相同策略。应同时查看请求记录中的命中规则、最终策略、DNS 结果和失败原因。

常见问题

Quantumult X 有没有一个 2026 年通用可用的完整配置？

没有。完整配置依赖节点、认证信息、策略名称、规则来源和客户端语法。本文只提供可替换占位符结构，不提供可用节点，也不保证第三方远程资源长期有效。

为什么订阅能打开，但导入后没有节点？

能打开地址不等于内容格式兼容。请检查返回内容、节点格式、解析器选项、tag 和资源启用状态，再用最小本地节点配置进行对照测试。

配置中为什么找不到 [proxy] 区段？

官方 sample.conf 展示了 server_local、server_remote 和 policy 等区段，没有独立的 proxy 区段。不要直接复制其他客户端的 proxy 配置。

force-policy 会不会让远程规则失效？

它可能改变远程规则原本指定的策略。官方说明是：设置 force-policy 后，远程资源中的策略会被忽略，改用该字段指定的策略。

是否必须开启 MitM 和证书？

不必须。普通分流可以先独立验证；只有明确需要 HTTPS 重写等功能时，再根据官方字段说明配置证书和 MitM。

只看出口 IP 能证明规则成功吗？

不能。还应查看请求记录中的命中规则、最终策略、DNS、IPv6 和错误原因。

相关阅读

• 连接问题排查指南
• 节点延迟、丢包与选择方法
• 各设备网络配置步骤
• 更多客户端使用指南

参考资料

1. Quantumult X 官方示例配置 sample.conf
2. Quantumult X 官方 URL Scheme 文档
3. Quantumult X 官方 Rewrite 示例