Mihomo 线路鸡 + 落地机分流方案：Cloudflare Worker 远程管理教程

基于本目录代码整理：线路鸡（入口 VPS）跑 Mihomo 做统一分流，按规则把流量甩给不同落地机（US / AI 专用出口）或本机直出；再用 Cloudflare Worker + R2 作为「云端配置中心」，实现规则在线编辑、节点订阅动态下发、一键热更新，全程无需登录 VPS。

一、整体架构

                        ┌─────────────────────────────────────────┐
                        │           Cloudflare 侧                  │
                        │                                          │
  手机/电脑浏览器 ──────►│  Worker A（管理面板 index.js）            │
  （编辑规则/刷节点）     │      │ 读写                              │
                        │      ▼                                   │
                        │  R2 存储桶 MY_SG_R2_BUCKET               │
                        │   ├─ my_custom_us.txt      (US 规则)     │
                        │   ├─ my_custom_ai.txt      (AI 规则)     │
                        │   ├─ my_custom_direct.txt  (直连规则)    │
                        │   ├─ my_custom_sync_node.json  (节点密钥)│
                        │   └─ my_custom_sync_proxy.json (同步目标)│
                        │      ▲                                   │
                        │      │ 读                                │
                        │  Worker B（订阅生成 proxy.js）            │
                        └──────┬───────────────────────┬───────────┘
                               │ proxy-providers        │ PUT 热更新
                               │ rule-providers 拉取    │ (external-controller)
                               ▼                        ▼
                        ┌─────────────────────────────────────────┐
                        │  线路鸡（入口 VPS，运行 Mihomo）          │
                        │   ├─ SS2022 入站 :8080                   │
                        │   ├─ SOCKS5 入站 :8081                   │
                        │   ├─ external-controller :9090           │
                        │   └─ 按规则分流：                        │
                        │       ├─ US-Out / AI-Out ──► 落地机      │
                        │       └─ LUODI-Out（本机即落地，直出）    │
                        └─────────────────────────────────────────┘

数据流：

你在手机浏览器打开 Worker A 的管理页面，编辑分流规则（如 DOMAIN-SUFFIX,openai.com）。
点击「保存并同步规则」→ Worker A 把规则写入 R2，并对每台 VPS 的 external-controller 发 PUT /providers/rules/<name>，Mihomo 立即重新拉取规则，无需重启。
点击「刷节点」→ Worker A 对 VPS 发 PUT /providers/proxies/<name>，强制刷新代理订阅。
VPS 上的 Mihomo 通过 proxy-providers（指向 Worker B）拉节点，通过 rule-providers（指向 R2 公开地址或 Worker）拉规则。

二、文件说明

文件	作用
`index.js`	Worker A：管理面板后端。GET 渲染编辑页面；POST 保存规则到 R2 / 触发 VPS 热更新
`template.html`	管理面板前端（iOS 风格），编译时被 `import` 进 index.js
`proxy.js`	Worker B：订阅生成器。按 `?node=us/ai/all` 输出 Clash 格式的 `proxies:` YAML
`mihomo.yaml`	VPS 上 Mihomo 的完整配置（入口 + 分流 + 远程 providers）
`my_custom_sync_node.json`	节点凭据（SS2022 的 server/port/password），存在 R2，Worker B 读取
`my_custom_sync_proxy.json`	「刷节点」按钮的目标列表 + 保存规则后要同步的 VPS controller URL 列表
`my_custom_us.txt` / `ai.txt` / `direct.txt`	各分组的 classical 文本规则，存在 R2

三、部署步骤

3.1 前置条件

一个 Cloudflare 账号（免费版即可，Worker 免费额度足够个人使用）
至少一台 VPS，安装好 Mihomo（Clash Meta 内核）
本机安装 wrangler CLI：npm install -g wrangler，并 wrangler login

3.2 创建 R2 存储桶

wrangler r2 bucket create my-mihomo-config

上传初始文件有两种方式：

方式一：Cloudflare 网页控制台直接上传（R2 → 存储桶 → 上传对象）。简单直观，但注意字符集：网页上传不会自动设置 charset=utf-8，含中文注释的 .txt 规则文件可能出现乱码。上传后建议在对象详情里把 HTTP 元数据的 Content-Type 手动改为 text/plain; charset=utf-8（JSON 文件同理设为 application/json; charset=utf-8），并确保本地文件本身是 UTF-8（无 BOM） 编码。

之后通过管理面板保存的规则不受此影响 —— index.js 写入 R2 时已显式指定 text/plain; charset=utf-8。

方式二：wrangler CLI 上传（可显式指定 Content-Type，推荐）：

wrangler r2 object put my-mihomo-config/my_custom_us.txt --file ./my_custom_us.txt --content-type "text/plain; charset=utf-8"
wrangler r2 object put my-mihomo-config/my_custom_ai.txt --file ./my_custom_ai.txt --content-type "text/plain; charset=utf-8"
wrangler r2 object put my-mihomo-config/my_custom_direct.txt --file ./my_custom_direct.txt --content-type "text/plain; charset=utf-8"
wrangler r2 object put my-mihomo-config/my_custom_sync_node.json --file ./my_custom_sync_node.json --content-type "application/json; charset=utf-8"
wrangler r2 object put my-mihomo-config/my_custom_sync_proxy.json --file ./my_custom_sync_proxy.json --content-type "application/json; charset=utf-8"

my_custom_sync_node.json — 填入真实节点凭据（这份文件只放 R2，不要提交到 git）：

{
    "sg": {
        "name": "vps-sg",
        "type": "ss",
        "server": "你的SG节点IP或域名",
        "port": 8080,
        "password": "SS2022密码(base64)",
        "cipher": "2022-blake3-aes-256-gcm",
        "udp": true
    },
    "us": { "...": "同上，US 节点" }
}

my_custom_sync_proxy.json — 声明「刷节点」目标和规则同步目标：

{
    "proxy": [
        {
            "id": "ai",
            "name": "综合所有",
            "server": "http://<VPS地址>:9090/",
            "proxy": "SG-PROXY",
            "other": [
                { "server": "http://<VPS地址>:9090/", "proxy": "US-PROXY" },
                { "server": "http://<VPS地址>:9090/", "proxy": "AI-PROXY" }
            ]
        }
    ],
    "rules": [
        { "name": "SG-US", "url": "http://<VPS地址>:9090/providers/rules/us-rule" },
        { "name": "SG-AI", "url": "http://<VPS地址>:9090/providers/rules/ai-rule" }
    ]
}

server 指向各台 VPS 的 external-controller；proxy 是 mihomo.yaml 中 proxy-provider 的名字；rules[].url 是保存规则后要 PUT 刷新的 rule-provider 端点。

3.3 部署 Worker A（管理面板）

wrangler.toml：

name = "mihomo-manager"
main = "index.js"
compatibility_date = "2026-01-01"

[[r2_buckets]]
binding = "MY_SG_R2_BUCKET"
bucket_name = "my-mihomo-config"

# 让 import TEMPLATE from "./template.html" 生效
[[rules]]
type = "Text"
globs = ["**/*.html"]
fallthrough = true

设置密钥（即 Mihomo external-controller 的 secret，切勿写进代码）：

wrangler secret put VPS_SECRET

部署：

wrangler deploy

3.4 部署 Worker B（订阅生成器）

单独一个 Worker 项目，main = "proxy.js"，同样绑定 R2 桶 MY_SG_R2_BUCKET，然后 wrangler deploy。

访问方式：

https://<worker-b域名>/?node=us    # 只输出 us 节点
https://<worker-b域名>/?node=ai    # 输出 ai（默认）
https://<worker-b域名>/?node=all   # 输出全部节点

返回的是标准 Clash proxies: YAML，可直接被 Mihomo 的 proxy-providers 消费。

3.5 配置 VPS 上的 Mihomo

以 mihomo.yaml 为模板，关键段落解释：

入站（把 VPS 当作入口/中转机）

listeners:
  - name: ss22-in            # SS2022 入站，客户端连这个
    type: shadowsocks
    port: 8080
    listen: 0.0.0.0
    password: "<openssl rand -base64 32 生成>"
    cipher: 2022-blake3-aes-256-gcm
    udp: true

  - name: my-socks5          # 备用 SOCKS5 入站（带用户名密码）
    type: socks
    port: 8081
    listen: 0.0.0.0
    users:
      - username: "<用户名>"
        password: "<密码>"

外部控制（热更新的关键）

external-controller: 0.0.0.0:9090
secret: "<与 Worker 的 VPS_SECRET 一致>"

Worker 保存规则后就是对这个端口发：

PUT http://<VPS>:9090/providers/rules/us-rule
Authorization: Bearer <secret>

DNS 与嗅探

dns:
  enhanced-mode: fake-ip          # fake-ip 提升匹配效率
  nameserver:
    - https://1.1.1.1/dns-query   # DoH，避免污染
sniffer:
  enable: true                    # 关键！下游流量常只带 IP，
  override-destination: true      # 不嗅探 SNI 的话域名规则匹配不到
  sniff:
    TLS:  { ports: [443] }
    QUIC: { ports: [443] }

远程节点（指向 Worker B）

proxy-providers:
  US-PROXY:
    type: http
    url: "https://<worker-b域名>/?node=us"
    interval: 86400               # 平时一天拉一次，改动时靠面板热刷
    path: ./proxies/us-proxy.yaml
    health-check:
      enable: true
      interval: 3600
      url: http://www.gstatic.com/generate_204

远程规则（指向 R2 / Worker 提供的文本）

rule-providers:
  ai-rule:
    type: http
    behavior: classical           # 文本里直接写 DOMAIN-SUFFIX,xxx 这类完整规则
    format: text
    url: "https://<规则文件地址>/my_custom_ai.txt"
    interval: 86400
    path: ./ruleset/ai-rule.yaml

分流策略

proxy-groups:
  - name: "US-Out"                # 美区服务走 US 节点（url-test 自动选优）
    type: url-test
    use: [US-PROXY]
  - name: "AI-Out"                # AI 服务走 AI 专用节点
    type: url-test
    use: [AI-PROXY]
  - name: "AI-Fallback"           # AI 节点挂了自动降级到 US
    type: fallback
    proxies: [AI-Out, US-Out]
  - name: "LUODI-Out"             # 本机即落地出口，如 YouTube 直接本机出去
    type: select
    proxies: [DIRECT]

rules:
  - IP-CIDR6,::/0,REJECT                      # 禁 IPv6
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve  # 内网直连（含 10/8、172.16/12 等）
  - RULE-SET,direct-rule,DIRECT               # 自定义直连
  - RULE-SET,ai-rule,AI-Out                   # AI 服务
  - RULE-SET,us-rule,US-Out                   # 美区服务
  - MATCH,LUODI-Out                           # 兜底：本机直出

启动：

mihomo -d /etc/mihomo   # 目录下放 config.yaml
# 建议配 systemd 常驻

3.6 客户端接入

客户端（手机/电脑的 Mihomo/Clash）添加一个指向 VPS 入口的节点即可：

proxies:
  - name: "SG-Entry"
    type: ss
    server: <VPS地址>
    port: 8080
    cipher: 2022-blake3-aes-256-gcm
    password: "<与 listeners 中一致>"
    udp: true

分流逻辑全部在 VPS 侧完成，客户端只需一条规则全部转发给入口。

四、日常使用

改规则：浏览器打开 Worker A 地址 → 切换到对应 Tab（US 规则 / AI 规则 / 入口直连）→ 编辑 → 「保存并同步规则」。保存后 Worker 自动 PUT 所有 VPS 的 rule-provider 端点，秒级生效。
换节点/改密码：更新 R2 里的 my_custom_sync_node.json → 面板点「刷节点」→ Worker PUT 各 proxy-provider 端点，Mihomo 重新拉取订阅。

验证出口：

bash <(curl -Ls https://IP.Check.Place) -x "socks5://user:pass@<VPS>:8081"

五、安全注意事项（重要）

本方案有几个默认薄弱点，部署时务必处理：

管理面板无鉴权：index.js 对 GET/POST 没有任何身份验证，拿到 URL 的人就能改你的规则、触发刷新。建议至少加一层：
- Cloudflare Access（Zero Trust 免费版即可，绑定邮箱 OTP）；或
- 在 Worker 里校验一个 ?key= 查询参数 / Cookie。
订阅接口无鉴权：proxy.js 输出内容包含节点服务器地址和明文密码，且 Access-Control-Allow-Origin: *。任何知道 URL 的人都能拿到你的节点凭据。建议 URL 中加入长随机 token 路径（如 /sub/<32位随机串>?node=us）并在 Worker 中校验。
controller 走明文 HTTP：my_custom_sync_proxy.json 里的 http://<VPS>:9090 意味着 VPS_SECRET 以明文 Bearer 头在公网传输。建议用 Nginx/Caddy 给 9090 套 TLS，或用 Cloudflare Tunnel 暴露 controller。
9090 端口不要全网开放：external-controller: 0.0.0.0:9090 配合防火墙，只放行 Cloudflare 出口 IP 段，或改用 Tunnel。
密钥管理：VPS_SECRET、SS 密码只放 Worker Secret 和 R2，不要写进代码或提交 git（本目录文件已全部用 xxxx 脱敏，保持这个习惯）。
SS2022 密码：必须用 openssl rand -base64 32 生成（2022-blake3-aes-256-gcm 要求 32 字节 key），不要用弱口令。

六、常见问题

问题	排查
保存规则后不生效	检查 `my_custom_sync_proxy.json` 里 rules 的 URL 是否指向正确的 provider 名；`curl -X PUT -H "Authorization: Bearer <secret>" http://<VPS>:9090/providers/rules/ai-rule` 手动验证
域名规则匹配不到，全走了 MATCH	确认 `sniffer.enable: true`，下游 UDP/TCP 流量往往只带 IP
刷节点返回失败	VPS 9090 端口防火墙是否放行 Cloudflare；secret 是否与 Worker 的 `VPS_SECRET` 一致
proxy-provider 拉取失败	直接浏览器访问 Worker B 的 `?node=us` 看输出是否为合法 YAML
面板/规则里中文乱码	多半是网页上传 R2 时没带字符集：把对象的 `Content-Type` 改成 `text/plain; charset=utf-8`，并确认源文件为 UTF-8 编码