Clash订阅更新了列表却没变：代理集合、策略组引用与显示名称核对

2026年10月23日 · Clash / Mihomo 使用指南

用两个既有代理集合的具体例题，分清Mihomo来源更新、策略组use引用、全部集合引入与名称前缀，判断列表不变是否符合配置预期。

客户端提示订阅更新成功，打开常用策略组却还是旧列表，先别急着删配置。你可能更新了另一个代理集合，当前组根本没有引用它；也可能列表名称经过前缀或筛选，与你在源内容中找的名字不同。本文以明确采用 Mihomo 配置结构的现有客户端为例，核对代理集合与策略组的引用关系；不把所有带 Clash 名字的软件当成同一版本，也不提供订阅服务、节点地址或访问限制绕过方法。

把“订阅”具体到对象，才知道更新了哪里

有人把完整配置文件叫订阅，也有人把配置中的一个远程代理集合叫订阅。前者可能包含策略组、规则和其他设置，后者只是被策略组引用的一份代理来源。客户端的更新按钮到底处理哪一层，要结合当前客户端说明和实际条目名称确认，不能只看按钮上有“更新”两个字。

在 Mihomo 配置里，proxy-providers 用于定义代理集合；proxy-groups 中的 use 可以引用这些集合。策略组还可以通过 proxies 引入代理或其他组。这些名字是一层层的关系，不是“下载完就自动放到每一个组”。先记录当前选中的完整配置名称、更新的集合名称、你正在查看的策略组名称，避免三者混成一句“这个订阅”。

核对来源时不需要公开完整订阅地址。地址可能带有个人令牌，配置或请求头也可能有凭据。对外反馈可以只用本地代号说明关系，例如配置 Q-1106、集合 demo-main、策略组“日常选择”，不贴可复用的真实链接和认证字段。

用两个既有集合，看懂为什么列表可以不变

虚构的 Q-1106 配置已经有两个有效代理集合：demo-main 内有 M-A、M-B；demo-lab 内有 T-A。日常选择组只引用 demo-main，没有额外静态代理、全部来源开关或筛选条件。此时更新 demo-lab 后增加 T-B，日常选择仍显示 M-A、M-B，是符合引用关系的结果，不单凭这个现象认定更新失败。

下面只是阅读关系的局部示意，省略了已有代理集合的合法定义和其他必要配置，不能作为完整配置直接覆盖现有文件。组里只指定 demo-main，并明确没有启用引入全部来源的字段：

proxy-groups:
  - name: "日常选择"
    type: select
    use:
      - demo-main
    include-all: false
    include-all-proxies: false
    include-all-providers: false

先在当前实际配置中找到对应组的 use，不凭本地缓存文件名猜。若你确实希望查看 demo-lab，应研究哪个获准的策略组引用它，而不是在不清楚用途时把所有来源都塞进日常组。只有业务上需要变更引用，才修改相关部分；本篇例子首先用于读懂配置，不要求你为了测试增加新订阅。

use 看着正确，也要看是否引入了全部集合

Mihomo 官方文档还提供 include-all、include-all-providers 等字段。尤其 include-all-providers 用于引入全部代理集合，会改变仅按 use 列表理解来源的方式。阅读一段截取配置时，别只看到 use 的一个名字就结束，应把这个策略组的其他引入字段一起看完。

例如某组原本只列 demo-main，后来启用了全部集合，列表里可能出现测试来源。此时删除一条显示出来的节点名称，未必解决其再次出现的问题，因为来源关系还在。先确认是否确实需要全部来源，再由有权维护配置的人调整，不把显示结果当成独立于配置的手工清单。

若配置由客户端生成、远程下载或合并产生，直接修改某个输出文件，后续是否会被更新覆盖由该客户端机制决定。先查它实际支持的本地覆写或合并方式，再决定长期改在哪里。Mihomo 支持一个字段，并不证明每个外壳客户端都有同名编辑按钮；没有确认保存层，就不要反复改缓存并把短时变化当永久设置。

节点名称变了，先区分显示处理与真实连接参数

代理集合的 override.additional-prefix 和 additional-suffix 可以给节点名称加固定前后缀。例如已有 demo-main 的显示名增加“日常-”前缀后，M-A 可能显示为“日常-M-A”。这是帮助辨认来源的名称变化，不意味着服务器、协议或账号已经更换，也不证明该节点更快。

只为核对身份时，记录“源名称—显示名称”的对应即可，不要顺手改协议、端口或证书校验。若已有规则或组选择依赖具体名称，重命名前先查看这些引用，并在副本中评估影响；不能为了让列表好看，造成其他位置找不到原名。当前字段支持范围仍以所用核心版本和官方文档为准。

列表少了条目，还应查看集合层或组层是否有 filter、exclude-filter 等筛选。它们可能让来源已经包含的项目没有出现在当前视图中。先对照筛选目标与实际名称，不通过关闭所有筛选、导入更多未知来源来“凑齐数量”。数量更多不是配置正确的验收标准。

什么结果才支持“这一层已经更新”

分三层写结果。来源层关注你更新的是哪个集合、是否有明确错误和可核对的新条目；组层关注当前完整配置中的引用、全部来源开关与筛选；显示层关注客户端当前打开的组及名称处理。来源层成功不自动替代后两层，组列表变化也不等于网络访问已经成功。

Q-1106 的一次有用记录可以写：“更新对象 demo-lab，预期增加 T-B；日常选择仍只用 demo-main，因此不要求该组出现 T-B；接下来查看获准的测试组是否引用 lab。”这里的每项结果要由自己的实际配置填写，不能把虚构例题当成测试日志。必要时在已获准的环境中加载副本检查，不拿正在承担重要任务的唯一配置试错。

完整配置替换前，可结合本站配置备份与回退准备说明保留原状态；如果来源、引用都正确，实际网页仍失败，那已经是另一个问题，可从安装后访问异常的诊断入口继续，不把刷新列表当成通用联网修复。

常见问题

点更新显示成功，是否证明已经切换到新配置？

不一定。某个下载或集合更新完成，与当前选择哪个完整配置是不同状态。重新确认正在使用的配置身份和组定义，再判断预期。不要在同名配置之间仅凭显示位置切换。

能把示例直接粘贴成完整配置吗？

不能。示例故意省略实际来源定义、规则与必要字段，只用于理解 use 的关系。它没有订阅地址、节点或可供直接运行的连接信息。将局部示例覆盖整个配置，会丢掉原本必需内容。

只想求助，需要发什么？

说明核心与客户端版本、当前配置代号、更新集合、查看策略组、预期的新名称和实际现象；配置片段只保留必要引用关系并去掉凭据。能用“main 与 lab 的引用不同”解释，就不需要把全配置、全部日志和私人订阅一起公开。

参考：Mihomo：代理集合与名称覆写、Mihomo：策略组 use、全部引入与筛选。