在 Clash Verge 中通过全局扩展脚本，让不同网站走不同代理

为什么要单独给网站指定代理

不同代理节点访问不同服务时，实际表现可能差异很大。例如：

• 某些节点访问 Gemini 比较稳定
• 某些节点访问 Google Scholar 更快
• Google API 对出口 IP、地区和网络质量更敏感
• 某些服务可能需要固定地区节点

如果所有流量都交给同一个代理组，往往很难同时兼顾这些网站。因此更实用的做法是：

Clash 的规则本身就支持这种分流，而全局扩展脚本可以让这些规则在所有订阅上持续生效。

在 Clash Verge 中添加全局扩展脚本

进入 Clash Verge 的全局扩展脚本配置后，可以加入类似下面的代码：

const prependRule = [
  // Gemini
  "DOMAIN,gemini.google.com,GeminiProxy",

  // Google Cloud Code / Google API
  "DOMAIN,daily-cloudcode-pa.googleapis.com,Auto",
  "DOMAIN,cloudcode-pa.googleapis.com,Auto",
  "DOMAIN,daily-cloudcode-pa.sandbox.googleapis.com,Auto",
  "DOMAIN-SUFFIX,googleapis.com,Auto",

  // Google Scholar
  "DOMAIN,scholar.google.com,ScholarProxy",
  "DOMAIN-SUFFIX,scholar.googleusercontent.com,ScholarProxy",

  // Google 登录和资源
  "DOMAIN,accounts.google.com,Auto",
  "DOMAIN-SUFFIX,gstatic.com,Auto",
  "DOMAIN-SUFFIX,googleusercontent.com,Auto",
];

function main(config, profileName) {
  config.rules = prependRule.concat(config.rules || []);
  return config;
}

这里最重要的不是 JavaScript 本身，而是每条规则最后面的代理组名称。例如：

• DOMAIN,gemini.google.com,GeminiProxy 表示访问 gemini.google.com 时，使用 GeminiProxy 代理组。
• DOMAIN,scholar.google.com,ScholarProxy 表示 Google Scholar 使用 ScholarProxy。
• DOMAIN-SUFFIX,googleapis.com,Auto 表示 googleapis.com 以及它下面的子域名统一交给 Auto。

代理组名称必须和订阅一致

这是最容易出问题的地方。脚本里的：

• GeminiProxy
• ScholarProxy
• Auto

并不是 Clash 内置的固定名称，而是你当前配置中的代理组名称。

假设你的订阅里只有：

• 节点选择
• 自动选择
• 香港节点
• 美国节点
• 日本节点

那么规则应该写成：

const prependRule = [
  "DOMAIN,gemini.google.com,美国节点",

  "DOMAIN,scholar.google.com,香港节点",
  "DOMAIN-SUFFIX,scholar.googleusercontent.com,香港节点",

  "DOMAIN-SUFFIX,googleapis.com,自动选择",
];

也就是说，最终可以做出这样的分流：

如果订阅更新以后代理组名称发生变化，也要同步修改脚本。

DOMAIN 和 DOMAIN-SUFFIX 怎么选

实际使用时主要会遇到这两种规则。

如果只想匹配一个明确的网站，可以用：

DOMAIN,gemini.google.com,美国节点

它针对的是：gemini.google.com。

如果希望某一整类子域名都使用同一个代理，可以用：

DOMAIN-SUFFIX,googleapis.com,自动选择

这样很多 Google API 域名都可以统一处理。例如：

• cloudcode-pa.googleapis.com
• generativelanguage.googleapis.com

都属于 googleapis.com。

通常比较好维护的方式是：已知的重要网站使用 DOMAIN，范围比较大的服务使用 DOMAIN-SUFFIX 兜底。

为什么要使用 prepend

脚本真正关键的是这一句：

config.rules = prependRule.concat(config.rules || []);

它会把我们的规则放到订阅原规则的前面。最终效果大概是：

Gemini 自定义规则
Google Scholar 自定义规则
Google API 自定义规则
-------------------
订阅原来的规则
-------------------
MATCH / 最终兜底规则

这很重要，因为 Clash 的规则是按照顺序进行匹配的。

如果订阅原本已经存在类似：Google → Proxy，而我们的 Gemini 规则排在它后面，那么 Gemini 很可能已经提前被订阅规则匹配掉了。

把自定义规则放到最前面，就可以先处理这些需要特殊分流的网站。

怎样确认规则真的生效

修改脚本后，不建议只通过“网站能不能打开”判断。更直接的方法是进入 Clash Verge 的连接页面。

然后访问目标网站，例如：https://gemini.google.com/，在连接列表中搜索：gemini。

如果看到：gemini.google.com，并且最终使用的是：美国节点，就说明规则已经匹配成功。

Google Scholar 也可以类似检查：scholar.google.com。

这样很容易确认问题到底出在：

• 规则没有生效
• 代理组写错
• 节点本身不可用
• 流量根本没有进入 Clash

为什么我更喜欢全局扩展脚本

直接改订阅文件虽然也能实现，但维护起来比较麻烦。全局扩展脚本的好处在于：订阅和自己的规则相互独立。

订阅负责：

• 节点
• 代理组
• 规则集
• 默认分流

而自己的脚本只负责：我特别关心的网站应该走哪里。比如：

• Gemini → 美国
• Scholar → 日本
• GitHub → 香港
• 其他 → 订阅默认规则

以后更新订阅时，也不需要重新手工修改整个配置。

对于长期使用 Clash Verge 的人来说，这种方式会比直接维护一份巨大 YAML 配置轻松很多。

最后

这套方法的核心其实很简单：

1. 网站域名
2. Clash 自定义规则
3. 指定代理组
4. 具体代理节点

通过 Clash Verge 的全局扩展脚本，我们可以把自己的规则插入订阅规则最前面，从而给不同网站指定不同的代理线路，同时继续保留订阅本身的节点和规则体系。

对于 Gemini、Google Scholar、GitHub、AI API 等对网络线路比较敏感的服务，这种方式尤其方便。

最终你只需要维护类似这样的映射关系：

而不需要为了几个特殊网站重新维护整套 Clash 配置。