服务器代理分流:从订阅到全规则体系
为什么需要服务器代理
本地代理(如 Clash Verge、Surge)已经能解决大部分日常需求——浏览器访问、终端命令、ChatGPT 对话。但当你的工作负载开始转移到服务器上时,场景就变了:
- 你在服务器上跑 AI 项目,需要稳定调用 OpenAI/Claude API
- CI/CD 流水线需要拉取 Docker 镜像、npm 包
- 爬虫脚本需要出口 IP
- Telegram bot 需要保持长连接
本地 TUN 模式管不到服务器。在服务器上跑一个独立的 Mihomo(Clash Meta)核心,配上完善的订阅节点和分流规则,就能把代理能力从个人桌面延伸到基础设施层。
这篇文章完整记录了一套生产级服务器代理配置——从订阅节点拉取、区域自动测速、多层分流规则链,到与本地 Clash Verge 的协作。配置本身来自真实部署,可以直接复用。
整体架构
核心思路是:一个订阅源 → 四个区域节点池 → URLTest 自动择优 → 九条分流线路。
订阅节点
proxy-providers:
outsider:
type: http
path: /etc/mihomo/proxy-providers/outsider.yaml
url: https://liangxin.xyz/link/jao7wOUNe3jPLlwj?clash=3&n=1
interval: 3600
health-check:
enable: true
url: https://www.gstatic.com/generate_204
interval: 300订阅源来自 liangxin.xyz,每一小时拉取一次节点列表,每五分钟做一次健康检查。健康检查的 URL 用的是 Google 的 generate_204——轻量、全球可访问、返回 204 说明代理链路正常。
实际部署中你可能需要根据自己的订阅链接替换这个 provider。
区域自动测速组
节点分四个区域,每个区域用 URLTest 自动选延迟最低的:
proxy-groups:
- name: "🌏 新加坡 AUTO"
type: url-test
url: https://www.gstatic.com/generate_204
interval: 300
tolerance: 50
use:
- outsider
filter: "^(?=.*(?i)(新加坡|Singapore|SG))"
- name: "🇯🇵 日本 AUTO"
type: url-test
url: https://www.gstatic.com/generate_204
interval: 300
tolerance: 50
use:
- outsider
filter: "^(?=.*(?i)(日本|Japan|JP|东京|大阪|Tokyo|Osaka))"
- name: "🇭🇰 香港 AUTO"
type: url-test
url: https://www.gstatic.com/generate_204
interval: 300
tolerance: 50
use:
- outsider
filter: "^(?=.*(?i)(香港|Hong Kong|HK|HongKong))"
- name: "🇺🇸 美国 AUTO"
type: url-test
url: https://www.gstatic.com/generate_204
interval: 300
tolerance: 50
use:
- outsider
filter: "^(?=.*(?i)(美国|美国|US|United States|洛杉矶|Los Angeles))"关键参数:
tolerance: 50:延迟差在 50ms 以内的节点视为等价,不频繁切换filter:正则匹配节点名,不同订阅商的节点名格式不同,需要根据实际情况调整正则- 四个区域组每个都针对不同的使用场景:新加坡连 AWS/GCP 就近,日本游戏延迟低,香港连内地快,美国服务覆盖最广
核心分流组设计
主出口
- name: "🚀 主出口"
type: select
proxies:
- "🔰 国外流量"
- "🤖 AI服务"
- "📽 哔哩哔哩"
- "✈️ Telegram"
- "🎮 游戏平台"
- "🍟 谷歌服务"
- "Ⓜ️ 微软服务"
- "🍎 苹果服务"
- "🎬 Youtube"
- "📹 Netflix"
- "🎬 国外媒体"
- "⚓️ 其他流量"主出口是所有流量的总入口。它不直接选择节点,而是在 11 个分流组之间手动切换。这意味着你可以一键切换所有 AI 流量或所有游戏流量的出口。
分流子组
接下来是具体的分流组。每个组都对应一类特定服务:
- name: "🔰 国外流量"
type: select
proxies:
- "🌏 新加坡 AUTO"
- "🇯🇵 日本 AUTO"
- "🇭🇰 香港 AUTO"
- "🇺🇸 美国 AUTO"
- "🚀 主出口"
- name: "🤖 AI服务"
type: select
proxies:
- "🇺🇸 美国 AUTO"
- "🌏 新加坡 AUTO"
- "🇯🇵 日本 AUTO"
- "🇭🇰 香港 AUTO"
- "🔰 国外流量"
- "🚀 主出口"
- name: "📽 哔哩哔哩"
type: select
proxies:
- "🇭🇰 香港 AUTO"
- "🌏 新加坡 AUTO"
- "🇯🇵 日本 AUTO"
- "🇺🇸 美国 AUTO"
- "🔰 国外流量"
- "🚀 主出口"
- name: "✈️ Telegram"
type: select
proxies:
- "🌏 新加坡 AUTO"
- "🇯🇵 日本 AUTO"
- "🇭🇰 香港 AUTO"
- "🇺🇸 美国 AUTO"
- name: "🎮 游戏平台"
type: select
proxies:
- "🇯🇵 日本 AUTO"
- "🇺🇸 美国 AUTO"
- "🌏 新加坡 AUTO"
- "🇭🇰 香港 AUTO"
- "🔰 国外流量"
- name: "🍟 谷歌服务"
type: select
proxies:
- "🇺🇸 美国 AUTO"
- "🌏 新加坡 AUTO"
- "🇯🇵 日本 AUTO"
- "🇭🇰 香港 AUTO"
- "🔰 国外流量"
- name: "Ⓜ️ 微软服务"
type: select
proxies:
- "🇺🇸 美国 AUTO"
- "🌏 新加坡 AUTO"
- "🇯🇵 日本 AUTO"
- "🇭🇰 香港 AUTO"
- "🔰 国外流量"
- name: "🍎 苹果服务"
type: select
proxies:
- "🇺🇸 美国 AUTO"
- "🌏 新加坡 AUTO"
- "🇯🇵 日本 AUTO"
- "🇭🇰 香港 AUTO"
- "🔰 国外流量"
- name: "🎬 Youtube"
type: select
proxies:
- "🇺🇸 美国 AUTO"
- "🌏 新加坡 AUTO"
- "🇯🇵 日本 AUTO"
- "🇭🇰 香港 AUTO"
- "🔰 国外流量"
- name: "📹 Netflix"
type: select
proxies:
- "🇺🇸 美国 AUTO"
- "🌏 新加坡 AUTO"
- "🇯🇵 日本 AUTO"
- "🇭🇰 香港 AUTO"
- "🔰 国外流量"
- name: "🎬 国外媒体"
type: select
proxies:
- "🇺🇸 美国 AUTO"
- "🌏 新加坡 AUTO"
- "🇯🇵 日本 AUTO"
- "🇭🇰 香港 AUTO"
- "🔰 国外流量"
- name: "⚓️ 其他流量"
type: url-test
url: https://www.gstatic.com/generate_204
interval: 300
tolerance: 50
use:
- outsider
filter: "^(?=.*(?i)(新加坡|Singapore|SG|日本|Japan|JP|香港|Hong Kong|HK|美国|US|United States))"注意到 ⚓️ 其他流量 是 url-test 类型,它会自动选择整个代理池中延迟最低的节点。这是兜底组——前面所有规则都没命中时,流量走这里自动择优。
每个组的 proxy 列表顺序就是推荐优先级。比如 AI 服务默认先用美国节点(因为 OpenAI/Claude 对美西节点延迟最低),哔哩哔哩优先香港节点(到内地延迟最优),游戏平台优先日本节点。
另外,所有选择型组都保留了一个 🔰 国外流量 甚至 🚀 主出口 的回退选项。这样可以手动控制:如果你发现当前 AI API 延迟异常,可以在 🤖 AI服务 组中临时切换到 🌏 新加坡 AUTO,但不影响其他流量。
Rule-Providers:规则的外部化管理
规则如果全部写在主配置里,维护起来就是噩梦。rule-providers 让规则可以从远程拉取,独立更新:
rule-providers:
# AI 服务规则
openai:
type: http
behavior: domain
url: "https://cdn.jsdelivr.net/gh/blackmatrix7/ios_rule_script@master/rule/Clash/OpenAI/OpenAI_Domain.yaml"
path: /etc/mihomo/rule-providers/openai.yaml
interval: 86400
anthropic:
type: http
behavior: domain
url: "https://cdn.jsdelivr.net/gh/blackmatrix7/ios_rule_script@master/rule/Clash/Anthropic/Anthropic_Domain.yaml"
path: /etc/mihomo/rule-providers/anthropic.yaml
interval: 86400
gemini:
type: http
behavior: domain
url: "https://cdn.jsdelivr.net/gh/blackmatrix7/ios_rule_script@master/rule/Clash/Gemini/Gemini_Domain.yaml"
path: /etc/mihomo/rule-providers/gemini.yaml
interval: 86400
copilot:
type: http
behavior: domain
url: "https://cdn.jsdelivr.net/gh/blackmatrix7/ios_rule_script@master/rule/Clash/Copilot/Copilot_Domain.yaml"
path: /etc/mihomo/rule-providers/copilot.yaml
interval: 86400AI 服务规则我用的是 blackmatrix7 维护的规则集。每天更新一次,包含所有 AI 相关的域名——chatgpt.com、api.openai.com、anthropic.com、gemini.google.com 等。
游戏平台的规则也是同一个来源:
steam:
type: http
behavior: domain
url: "https://cdn.jsdelivr.net/gh/blackmatrix7/ios_rule_script@master/rule/Clash/Steam/Steam_Domain.yaml"
path: /etc/mihomo/rule-providers/steam.yaml
interval: 86400
epic:
type: http
behavior: domain
url: "https://cdn.jsdelivr.net/gh/blackmatrix7/ios_rule_script@master/rule/Clash/Epic/Epic_Domain.yaml"
path: /etc/mihomo/rule-providers/epic.yaml
interval: 86400
sony:
type: http
behavior: domain
url: "https://cdn.jsdelivr.net/gh/blackmatrix7/ios_rule_script@master/rule/Clash/Sony/Sony_Domain.yaml"
path: /etc/mihomo/rule-providers/sony.yaml
interval: 86400
nintendo:
type: http
behavior: domain
url: "https://cdn.jsdelivr.net/gh/blackmatrix7/ios_rule_script@master/rule/Clash/Nintendo/Nintendo_Domain.yaml"
path: /etc/mihomo/rule-providers/nintendo.yaml
interval: 86400平台服务(Google/Microsoft/Apple)的规则用于精确控制、流媒体解锁和下载优化:
google:
type: http
behavior: domain
url: "https://cdn.jsdelivr.net/gh/blackmatrix7/ios_rule_script@master/rule/Clash/Google/Google_Domain.yaml"
path: /etc/mihomo/rule-providers/google.yaml
interval: 86400
microsoft:
type: http
behavior: domain
url: "https://cdn.jsdelivr.net/gh/blackmatrix7/ios_rule_script@master/rule/Clash/Microsoft/Microsoft_Domain.yaml"
path: /etc/mihomo/rule-providers/microsoft.yaml
interval: 86400
apple:
type: http
behavior: domain
url: "https://cdn.jsdelivr.net/gh/blackmatrix7/ios_rule_script@master/rule/Clash/Apple/Apple_Domain.yaml"
path: /etc/mihomo/rule-providers/apple.yaml
interval: 86400国内流量规则用的是 Loyalsoldier 的经典规则集:
direct:
type: http
behavior: domain
url: "https://cdn.jsdelivr.net/gh/Loyalsoldier/clash-rules@release/direct.txt"
path: /etc/mihomo/rule-providers/direct.yaml
interval: 86400
private:
type: http
behavior: ipcidr
url: "https://cdn.jsdelivr.net/gh/Loyalsoldier/clash-rules@release/private.txt"
path: /etc/mihomo/rule-providers/private.yaml
interval: 86400
cncidr:
type: http
behavior: ipcidr
url: "https://cdn.jsdelivr.net/gh/Loyalsoldier/clash-rules@release/cncidr.txt"
path: /etc/mihomo/rule-providers/cncidr.yaml
interval: 86400direct 包含国内可直接访问的域名(如百度、淘宝),private 包含内网地址段,cncidr 包含中国 IP 段。
规则顺序:最关键的设计决策
Mihomo 匹配规则是从上到下、首条命中。规则顺序直接决定了分流效果。这是整套配置中最容易踩坑的地方。
规则分为六个优先级层级:
第一层:AI 服务(最高优先级)
- RULE-SET,openai,🤖 AI服务
- RULE-SET,anthropic,🤖 AI服务
- RULE-SET,gemini,🤖 AI服务
- RULE-SET,copilot,🤖 AI服务AI 规则必须放在最前面。为什么?因为很多 AI 服务的域名同时被其他规则集覆盖——比如 googleapis.com 既在 Gemini 规则中,也在 Google 规则中。如果 Google 规则排在 AI 之前,Gemini API 请求就会被路由到 Google 服务组而非 AI 组。
同样的道理,api.openai.com 可能被 CDN 规则或通用国外流量规则先匹配。把 AI 规则放在第一名确保所有 AI API 请求走预期的线路,而不是被"看起来差不多"的规则截胡。
第二层:平台服务
- RULE-SET,google,🍟 谷歌服务
- RULE-SET,microsoft,Ⓜ️ 微软服务
- RULE-SET,apple,🍎 苹果服务Google 服务包括 Google Search、Google Cloud、Google Ads 等全套产品。微软服务覆盖 Azure、Office 365、Windows Update、Visual Studio Code 等。
第三层:游戏与流媒体
- RULE-SET,steam,🎮 游戏平台
- RULE-SET,epic,🎮 游戏平台
- RULE-SET,sony,🎮 游戏平台
- RULE-SET,nintendo,🎮 游戏平台
- RULE-SET,youtube,🎬 Youtube
- RULE-SET,netflix,📹 Netflix
# ... 其他国外媒体规则游戏平台规则优先于流媒体,因为游戏对延迟敏感。如果把 Netflix 放在 Steam 前面,打开 Steam 商店时可能先命中流媒体规则去走美西节点——但 Steam 下载用日本节点延迟更低。
第四层:社交与通讯
- DOMAIN-SUFFIX,bilibili.com,📽 哔哩哔哩
- DOMAIN-SUFFIX,bilibili.tv,📽 哔哩哔哩
- DOMAIN-KEYWORD,bilibili,📽 哔哩哔哩
- DOMAIN-SUFFIX,t.me,✈️ Telegram
- DOMAIN-SUFFIX,telegra.ph,✈️ Telegram
- DOMAIN-KEYWORD,telegram,✈️ Telegram
- DOMAIN-SUFFIX,discord.com,🔰 国外流量
- DOMAIN-SUFFIX,twitter.com,🔰 国外流量哔哩哔哩用香港节点可以解除区域限制看到港澳台限定内容,同时延迟又远低于美国节点。
第五层:开发者基础设施
- DOMAIN-SUFFIX,docker.com,🔰 国外流量
- DOMAIN-SUFFIX,docker.io,🔰 国外流量
- DOMAIN-SUFFIX,github.com,🔰 国外流量
- DOMAIN-SUFFIX,jsdelivr.net,🔰 国外流量
- DOMAIN-SUFFIX,npmjs.org,🔰 国外流量
- DOMAIN-SUFFIX,pypi.org,🔰 国外流量
- DOMAIN-SUFFIX,nuget.org,🔰 国外流量
- DOMAIN-SUFFIX,maven.org,🔰 国外流量
- DOMAIN-SUFFIX,rust-lang.org,🔰 国外流量
- DOMAIN-SUFFIX,crates.io,🔰 国外流量
- DOMAIN-SUFFIX,go.dev,🔰 国外流量
- DOMAIN-SUFFIX,debian.org,🔰 国外流量
- DOMAIN-SUFFIX,ubuntu.com,🔰 国外流量
- DOMAIN-SUFFIX,archlinux.org,🔰 国外流量
- DOMAIN-SUFFIX,alpinelinux.org,🔰 国外流量Docker、GitHub、各大包管理器和 Linux 发行版镜像站走 🔰 国外流量 组。服务器上最常访问的就是这些域名。
第六层:兜底与国内规则
- RULE-SET,direct,DIRECT
- GEOSITE,CN,DIRECT
- RULE-SET,private,DIRECT
- GEOIP,CN,DIRECT
- MATCH,⚓️ 其他流量兜底规则处理未被上述规则匹配的所有流量。国内域名走直连,剩余的国外流量走 ⚓️ 其他流量 自动测速。
关键冲突修复
1. GEOSITE,CN 不能放在最前面
这是最容易踩的坑。很多人习惯把 GEOSITE,CN 放在规则列表头部,认为"国内流量先走直连"。但这个做法在接入 AI 规则后会导致严重问题:
❌ 错误的顺序:
GEOSITE,CN,DIRECT # 国内域名直连
RULE-SET,openai,🤖 AI服务 # 这条永远不会命中因为很多 AI 服务的 CDN 域名(如 cloudfront.net、fastly.net)被归类为 GEOSITE:CN——CDN 节点在全球都有部署,但域名分类时被认为是"属于中国的 CDN"。
正确的做法是把 GEOSITE,CN 放到 AI 规则后面、兜底规则前面:
✅ 正确的顺序:
RULE-SET,openai,🤖 AI服务
RULE-SET,anthropic,🤖 AI服务
...
GEOSITE,CN,DIRECT # AI 规则之后才处理国内直连
RULE-SET,private,DIRECT
GEOIP,CN,DIRECT
MATCH,⚓️ 其他流量这样 AI API 请求先被 AI 规则捕获,不会误入国内直连。
2. 哔哩哔哩不从 domestic DIRECT 排除
另一个常见做法是把 bilibili 放到 direct 规则集(国内直连)。但如果你有港澳台限定内容的需求,bilibili 应该单独走代理。解决方法:为 bilibili 创建专属的分流组 📽 哔哩哔哩,使用香港节点,放在 AI 和平台规则之后、RULE-SET,direct 之前。
3. Microsoft Update 规则优先于通用 KEYWORD
微软更新(windowsupdate.com、update.microsoft.com)经常被泛域名规则或 KEYWORD,microsoft 提前捕获。如果微软更新走代理线路,下载速度反而可能变慢。解决方案:将 RULE-SET,microsoft 放在靠前位置(结合 DIRECT 或优质节点),确保更新流量先被精确规则处理,而不是被后面的兜底规则或关键字规则随便分配。
完整的 rules 段落
把上述所有规则组合起来,最终的 rules 段落如下:
rules:
# === AI 服务(最高优先级)===
- RULE-SET,openai,🤖 AI服务
- RULE-SET,anthropic,🤖 AI服务
- RULE-SET,gemini,🤖 AI服务
- RULE-SET,copilot,🤖 AI服务
# === 平台服务 ===
- RULE-SET,google,🍟 谷歌服务
- RULE-SET,microsoft,Ⓜ️ 微软服务
- RULE-SET,apple,🍎 苹果服务
# === 游戏平台 ===
- RULE-SET,steam,🎮 游戏平台
- RULE-SET,epic,🎮 游戏平台
- RULE-SET,sony,🎮 游戏平台
- RULE-SET,nintendo,🎮 游戏平台
# === 流媒体 ===
- RULE-SET,youtube,🎬 Youtube
- RULE-SET,netflix,📹 Netflix
# 其他国外媒体规则...
# === 社交与通讯 ===
- DOMAIN-SUFFIX,bilibili.com,📽 哔哩哔哩
- DOMAIN-SUFFIX,bilibili.tv,📽 哔哩哔哩
- DOMAIN-KEYWORD,bilibili,📽 哔哩哔哩
- DOMAIN-SUFFIX,t.me,✈️ Telegram
- DOMAIN-SUFFIX,telegra.ph,✈️ Telegram
- DOMAIN-KEYWORD,telegram,✈️ Telegram
- DOMAIN-SUFFIX,discord.com,🔰 国外流量
# === 开发者基础设施 ===
- DOMAIN-SUFFIX,docker.com,🔰 国外流量
- DOMAIN-SUFFIX,github.com,🔰 国外流量
- DOMAIN-SUFFIX,jsdelivr.net,🔰 国外流量
# === 兜底与国内 ===
- RULE-SET,direct,DIRECT
- GEOSITE,CN,DIRECT
- RULE-SET,private,DIRECT
- GEOIP,CN,DIRECT
- MATCH,⚓️ 其他流量与本地 Clash Verge 的集成
这套服务器代理不是你日常浏览用的代理。本地电脑上仍然运行 Clash Verge(或 Clash Meta for Android),开启 TUN 模式接管所有流量。
两者的分工很清晰:
| 场景 | 代理方式 |
|---|---|
| 日常浏览、ChatGPT 聊天 | 本地 Clash Verge(TUN 模式) |
| 服务器上跑 AI API 调用 | 服务器 Mihomo |
| 服务器拉 Docker 镜像 | 服务器 Mihomo |
| CI/CD 构建时拉依赖 | 服务器 Mihomo |
| SSH 到服务器的管理流量 | 直连 |
服务器上的 Mihomo 不需要 TUN 模式——它通过 redir-host 或 tproxy 模式运行,配合 iptables 规则透明代理所有出站流量。也可以配置成 SOCKS5/HTTP 混合代理,让特定服务通过环境变量 http_proxy 使用。
实际部署中我推荐写一个 systemd service:
[Unit]
Description=Mihomo Daemon
After=network.target
[Service]
Type=simple
ExecStart=/usr/local/bin/mihomo -d /etc/mihomo
Restart=on-failure
RestartSec=5
[Install]
WantedBy=multi-user.target可视化面板
配置写好之后,怎么确认分流生效了?Mihomo 提供了 Yacd(Yet Another Clash Dashboard),部署后可以通过网页实时查看:
https://proxy.outsider-studio.cloud/ui/在 Yacd 面板上你可以:
- 查看当前所有节点的延迟
- 实时追踪每个连接的命中的规则和代理组
- 手动切换某个分流组的出口节点
- 查看实时流量统计
这是排查分流问题的得力工具。比如当你发现某个 AI API 请求没有走 AI 服务组而是走了 Google 服务组,在 Yacd 的连接列表里一目了然——Source、Destination、Rule 三列直接告诉你问题出在哪条规则上。
部署检查清单
部署完成后,执行以下验证步骤:
# 检查配置语法
mihomo -t -d /etc/mihomo
# 验证节点是否在线
curl -x http://127.0.0.1:7890 https://www.google.com
# 验证 AI API 可达
curl -x http://127.0.0.1:7890 https://api.openai.com/v1/models
# 验证国内网站直连(不走代理)
curl -x http://127.0.0.1:7890 https://www.baidu.com
# 确认公网 IP 已被代理
curl -x http://127.0.0.1:7890 https://api.ip.sb/geoip总结
这套配置的核心设计理念是:精确匹配优先于通用规则,AI 服务优先级高于一切。
从升级依赖的角度看,这套体系的关键收益有:
- 订阅与规则分离:节点和规则都支持远程拉取、自动更新,配置本身只负责"如何组合"
- 分层分流:主出口 → 区域自动测速 → 服务分流组,三个层级互不干扰
- AI 优先:规则顺序确保 AI API 调用始终走最合适的线路,不与其他规则冲突
- 可视化运维:Yacd 面板让流量的每一跳都能被追溯,排障成本大幅降低
当然,这套配置不是一成不变的。如果你接入新的订阅商,需要调整 filter 正则;如果新增了服务类型,需要添加对应的 rule-provider 和 proxy-group。分流配置的本质是一个持续演进的系统工程——但有了清晰的架构和规则哲学,每次调整都有章可循。