多机场订阅 + 少量自建节点的组合，用传统“各家配置来回切换”的方式很快就会失控：命名混乱、规则不统一、节点重复，还要为自建节点额外维护一份配置。Sub-Store（Substore）的思路更像“订阅处理管线”：把多个订阅当作数据源导入 → 清洗/重命名 → 输出一份整合订阅或直接生成 Mihomo/Clash 配置。

下文把文章里涉及的 docker-compose、反代配置、脚本链接、覆写脚本链接与全部参数 都写全，照抄即可用。

一、Docker 部署 Substore（关键：随机后端路径 + 定时刷新）

作者建议直接使用 xream/sub-store 这个前后端一体镜像，并强调：公网部署一定要更改后端路径，否则配置可能被盗用。

1.1 docker-compose.yml（示例）

把下面内容保存为 docker-compose.yml（或合并到你的 compose 中）：

services:
  sub-store:
    image: xream/sub-store
    container_name: substore
    restart: always
    environment:
      - SUB_STORE_CRON=55 23 * * *
      - SUB_STORE_FRONTEND_BACKEND_PATH=/ #这是你的API安全路径，防止被扫描
    ports:
      - "3001:3001"
    volumes:
      - ./data:/opt/app/data

1Panel面板docker-compose.yml配置：

version: "3"
services:
  sub-store:
    image: xream/sub-store:latest
    container_name: sub-store
    restart: always
    environment:
      - SUB_STORE_CRON=55 23 * * *
      - SUB_STORE_FRONTEND_BACKEND_PATH=/ #这是你的API安全路径，防止被扫描
    ports:
      - "127.0.0.1:53001:3001"  # 端口映射
    volumes:
      - ./data:/opt/app/data  # 数据持久化
    networks:
      - 1panel-network
networks:
    1panel-network:
        external: true      

两个环境变量怎么理解：

• SUB_STORE_CRON=55 23 * * *：定时任务（cron），每天 23:55 触发刷新/处理（你可以按需要改时间）。
• SUB_STORE_FRONTEND_BACKEND_PATH=/super-random-path：后端路径前缀，建议改成更随机、更难猜的字符串（越长越好），防止被扫到。

1.2 反向代理（Caddy 示例）

Substore 默认对外暴露 3001 端口，反代即可访问前端（示例）：

sub-domain.example.com {
        reverse_proxy :3001
}

1.3 第一次进入前端：新增“后端地址”（别填错）

初次进入 Substore 前端后，需要新增后端地址；这个地址由你在 compose 里设置的 SUB_STORE_FRONTEND_BACKEND_PATH 决定。例如：

• https://sub-domain.example.com/super-random-path

二、组合订阅管理：把所有机场 + 自建节点合并，并统一命名

当你把所有机场上游订阅与自建节点都添加到 Substore 后，就可以把它们加入一个“组合订阅”。但默认命名会非常杂乱，甚至不同机场之间可能重名。

Substore 支持用脚本批量处理节点，比较省心的做法是先把命名统一下来。可以直接使用现成脚本来统一重命名：

• 节点批量重命名脚本（直接粘贴到“脚本操作”处）：
  https://raw.githubusercontent.com/Keywos/rule/main/rename.js

做完重命名后，你再按自己喜好做筛选/排序/分组等节点操作，就能得到一份命名统一、好找好用的节点列表。

三、生成 Mihomo/Clash 配置：用“覆写”把规则、分组一次性补齐

只有节点列表还不够——直接生成的配置文件通常不包含任何分流规则，你需要自己编写或引用第三方规则。

更推荐的工作流是：

1. 进入 Substore 的文件管理
2. 创建一份新的 Mihomo 配置
3. 「来源」选择你的组合订阅（订阅名称选择你的订阅组）
4. 在“脚本操作”里填入覆写配置（下面给出完整链接与参数）

四、覆写方案：JS 动态覆写优先，YAML 用于兼容

覆写的目的很明确：把“节点订阅”变成“能直接用的完整配置”。一套好用的覆写通常会包含：

• 聚合多套规则集，增强广告拦截、隐私保护与分流精度；
• 补充常见但容易漏掉的分流场景；
• 移除冗余规则，降低冲突与维护成本；
• 引入更完整的 GeoSite/GeoIP 数据；
• 对 IP 规则使用 no-resolve 等策略，减少本地解析带来的性能与泄露风险；
• 最关键的体验点：按节点实际分布动态建组（订阅里没有某地区节点，就不会生成对应代理组，节点变动时分组也会跟着变）。

五、 JavaScript 覆写（推荐）：一条链接 + #参数=true 即可定制

5.1 覆写脚本 raw 链接（基础版）

把这个 raw 链接粘贴到 Substore 文件管理里该 Mihomo 配置的“脚本操作”处：

• https://raw.githubusercontent.com/powerfullz/override-rules/refs/heads/main/convert.js

5.2 传参格式（固定写法）

参数通过 # 追加，格式如下：

https://raw.githubusercontent.com/powerfullz/override-rules/refs/heads/main/convert.js#参数1=true&参数2=true

5.3 支持的全部参数

参数	功能
loadbalance	启用国家/地区节点组的负载均衡
landing	启用落地节点功能
ipv6	启用 IPv6 支持
full	生成针对纯内核使用场景的完整配置
keepalive	启用 TCP KeepAlive

5.4 示例：同时开启负载均衡 + IPv6

最终覆写脚本链接写成这样：

• https://raw.githubusercontent.com/powerfullz/override-rules/refs/heads/main/convert.js#loadbalance=true&ipv6=true

把这条“最终链接”粘贴到脚本操作处，用 Substore 的生成预览确认无误后保存即可。

六、YAML 覆写（兼容方案）：32 份预生成文件 + 命名规则

如果你的客户端/转换服务不支持 JS 覆写，可以改用预生成的 YAML 覆写文件。通常这类仓库会通过 CI 自动从 JS 规则生成多份 YAML，放在 yamls/ 目录里，每次推送后自动更新覆盖。

6.1 YAML 文件命名规则

config_lb-{0|1}_landing-{0|1}_ipv6-{0|1}_full-{0|1}_keepalive-{0|1}.yaml

其中 0/1 分别对应关闭/开启（例如 lb-1 表示开启负载均衡）。

6.2 示例：只开启 full，其余关闭

https://raw.githubusercontent.com/powerfullz/override-rules/refs/heads/main/yamls/config_lb-0_landing-0_ipv6-0_full-1_keepalive-0_fakeip-0.yaml

6.3 YAML 的限制（重要）

YAML 覆写通常是基于“模拟代理数据”预生成的，因此很难做到 JS 那种“根据你真实订阅节点自动增删国家/地区代理组”的能力，往往只能把所有地区组都预先放进去。若你已经搭建 Substore，且希望获得“动态识别国家 + 传参”的省心体验，仍建议优先使用 JS 覆写。

七、生成“最终订阅链接”：把配置分享出去给客户端订阅

当 Mihomo 配置保存成功后，点击分享按钮生成分享链接，设置分享有效期并创建分享。生成出来的链接就是“最终成型的 Mihomo 配置文件”，把它作为订阅链接添加到你的代理软件里即可。

总结

这套流程的关键，是把“订阅管理”从手工切换升级为可持续维护的流水线：

1. Docker 部署 Substore，务必设置随机后端路径，并按需启用定时刷新；
2. 合并机场订阅与自建节点为组合订阅，用脚本统一命名；
3. 在文件管理创建 Mihomo 配置，以组合订阅为来源；
4. 优先使用 JS 覆写（支持 #loadbalance/landing/ipv6/full/keepalive 参数，且可动态按国家建组）；
5. 客户端不支持 JS 时，使用预生成 YAML 覆写文件；
6. 最后创建分享链接，把它当作订阅地址一键更新。