Gemma 4 与 Clash：AI Studio、Hugging Face 分流规则

1 热点背后：Gemma 4 带来的「试用 + 拉权重」双线流量

Gemma 4作为 2026 年春季最受关注的开放权重模型家族之一，把两类需求同时推到开发者面前：一是在 Google AI Studio 里快速对比不同尺寸与推理配置，体验面向 Agent 与长链路的交互；二是到 Hugging Face 模型仓库获取权重、分词器与示例代码，做本地评测或二次训练。前者更像「富前端 + 长连接 API」，后者则是「浏览器元数据 + 多段大文件下载」，对网络的要求并不相同，却共用一部分 Google 生态与全球 CDN。

若只写几条泛化的「海外代理」规则，常见症状是：Google AI Studio能打开外壳，却在加载实验卡片或流式输出时卡住；Hugging Face 网页能浏览，模型下载进度条却反复归零，因为 LFS 或分片实际命中了另一个未覆盖的主机名。把Clash 分流规则拆成「Google 试用面」与「HF 仓库面」两个可观测对象，并在日志里核对DOMAIN-SUFFIX命中，比盲目切换全局模式更能定位问题。

尚未安装客户端的用户，可先到本站下载页获取支持 Mihomo 与订阅管理的图形客户端，再把下文规则并入现有 Profile。开源仓库适合了解协议与参与贡献，日常安装包仍以本站为准。

心智模型 把 Gemma 4工作流看成「Google AI Studio 上的会话流量」加上「Hugging Face 上的元数据与 CDN 大文件」两套并行管道；Clash 负责让两条管道落在同一稳定出口族，而不是让其中一条悄悄直连。

2 与站内「Gemini 2.5 + AI Studio」专题如何分工

本站已发布《用 Clash 稳定访问 Gemini 2.5：Google AI Studio 分流规则配置教程》，其中系统讲解了 generativelanguage.googleapis.com、Google 账户与 Gemini API 的域名治理。本文不再重复那篇的 API 细节，而是把镜头拉近到 Gemma 4热点场景：抢鲜试用仍主要落在 AI Studio 与 Google 域族，拉取开放权重则强烈依赖 Hugging Face 及常见对象存储与 CDN 主机。

实践上推荐两篇配合阅读：先用 Gemini 专题把 PROXY_GOOGLE 一类策略组调通，再回到本文补齐 PROXY_HF 与下载相关后缀；这样关键词上与 ChatGPT、Claude、NotebookLM 等篇并列不撞题，又能承接同一批开发者流量。若你只做浏览器试玩、不下权重，可仅合并 Google 侧规则；若你主要做本地推理，请务必将 HF 与 LFS 段一并纳入。

3 Google AI Studio 侧：承接 Gemma 卡片与账户链路

在 Google AI Studio 中体验 Gemma 4时，浏览器仍会命中大量 *.google.com、*.googleapis.com、gstatic.com、googleusercontent.com 以及 ai.google.dev 等开发者入口。与纯「对话模型」场景相比，开放模型卡片往往附带更多静态资源与实验 iframe，对TLS 握手完整性与HTTP/2 多路复用更敏感。

建议把 AI Studio 相关域名继续挂在 Gemini 专题中已验证的 PROXY_GOOGLE（或等价策略组）下，保持与 Gmail、Drive 等是否直连的团队策略一致。若公司网络对 Google 账户有拆分策略，请特别注意 accounts.google.com 与 OAuth 回调路径不要被错误前置规则抢走，否则会出现「模型列表闪一下又退回登录」的假故障。

当你在同一台机器上同时打开 AI Studio 与 Hugging Face 标签页时，Clash 日志里会出现两类主机名交替出现；此时更依赖规则顺序清晰，而不是依赖「全局都能 magically 通」的侥幸心理。

4 Hugging Face、开放权重与模型下载域名

Hugging Face主站与 Hub API 常见后缀包括 huggingface.co、短链形态 hf.co，以及用于 Spaces、数据集与社区功能的子域。大文件模型下载往往不只在主域完成：仓库页面可能引用 cdn-lfs.huggingface.co 一类 LFS 入口，也可能根据时段解析到 Cloudflare、Backblaze、AWS 等第三方存储域名。只写 DOMAIN-SUFFIX,huggingface.co 而忽略这些外链主机，就会出现「元数据秒开、权重永远 0%」的经典症状。

排障时请在 Clash 连接日志中过滤 huggingface、hf.co、cloudflare、amazonaws.com 等关键词，把下载阶段实际命中的主机名记录下来，再决定是否用 DOMAIN-SUFFIX 增补，或把某些 CDN 段并入更宽的「开发者下载」Rule Provider。对团队环境，建议把 HF 相关策略组命名成独立的 PROXY_HF，与 PROXY_GOOGLE 并列，这样你可以在「HF 走低价大带宽节点、Google 走低延迟节点」之间手动权衡，而不必混在一个选择器里互相拖累。

使用 git clone 或 git lfs pull 拉取含 LFS 指针的仓库时，Git 进程往往不会自动尊重浏览器系统代理；这与 AI Studio 的纯浏览器栈不同，更凸显 TUN 或显式 HTTPS_PROXY 的必要性，详见下一节。

CDN 列表会随时间变化 Hugging Face 侧下载域名集合并非静态文档；请以你本机日志为准增量维护，并把易变段交给远程 Rule Provider 定期刷新，而不是把几十条 DOMAIN 永久写死在本地。

5 DOMAIN-SUFFIX 与 YAML 示意：Google + HF 双策略组

下面是一段示意性配置，演示如何用 DOMAIN-SUFFIX 为 Gemma 4相关试用与模型下载分别绑定 PROXY_GOOGLE 与 PROXY_HF。名称需与你现有 proxy-groups 对齐；合并到完整 rules: 时注意靠前优先，避免被订阅自带的宽泛 MATCH 提前吃掉。

config.yaml (snippet)

# Example only — merge with your full profile and proxy-groups
proxy-groups:
  - name: PROXY_GOOGLE
    type: select
    proxies: [AUTO-BEST, DIRECT]
  - name: PROXY_HF
    type: select
    proxies: [AUTO-BEST, DIRECT]

rules:
  # Google AI Studio & Gemma tryout stack (see also Gemini article)
  - DOMAIN-SUFFIX,google.com,PROXY_GOOGLE
  - DOMAIN-SUFFIX,googleapis.com,PROXY_GOOGLE
  - DOMAIN-SUFFIX,gstatic.com,PROXY_GOOGLE
  - DOMAIN-SUFFIX,googleusercontent.com,PROXY_GOOGLE
  - DOMAIN-SUFFIX,ai.google.dev,PROXY_GOOGLE

  # Hugging Face hub & common download faces
  - DOMAIN-SUFFIX,huggingface.co,PROXY_HF
  - DOMAIN-SUFFIX,hf.co,PROXY_HF
  - DOMAIN-SUFFIX,cdn-lfs.huggingface.co,PROXY_HF

下载阶段若日志出现其他存储或 CDN 后缀，可在 PROXY_HF 下继续追加 DOMAIN-SUFFIX，或改为引用远程 RULE-SET 把「机器学习常用 CDN」作为独立规则源。DNS 与 FakeIP 的协同请参阅《彻底防止 DNS 泄漏：Meta 内核 DoH + FakeIP 最佳实践配置》，避免解析阶段与连接阶段命中不同出口。

慎用过宽 KEYWORD 临时用 DOMAIN-KEYWORD,huggingface 排障可以，长期开启可能误伤无关站点；生产环境优先 DOMAIN-SUFFIX + 维护良好的 Rule Provider。

6 Rule Provider 更新策略：让规则跟上热点与 CDN 变化

Gemma 4发布后，模型卡片、文档镜像与下载端点可能在数周内多次调整；静态 YAML 若从不更新，很容易在下一轮模型迭代时再次失效。推荐把「Google 业务域」「开发者常用 CDN」「HF 相关」拆成多个 rule-providers，分别设置合理的 interval（例如数小时到一天），并在客户端里打开自动更新。

每次远程规则集更新后，做一次回归验证：浏览器打开 Google AI Studio 任意 Gemma 实验卡片；命令行用 huggingface-cli 或 git lfs 试拉一个小文件。若只有其中一条链路失败，优先查该链路对应策略组与日志主机名，而不是整体怀疑「机场挂了」。Geo 数据过期也会间接导致规则误判，可结合《Clash Meta 手动更新 GeoIP 与 Geosite》做例行检查。

团队共享订阅时，建议在文档中写明：HF 下载允许使用大带宽节点，而 AI Studio 试玩优先低 RTT节点；通过两个 select 组解耦，让成员按任务切换，而不是互相覆盖对方的全局选择。

7 TUN、CLI、huggingface-cli 与 git-lfs 一致性

仅开系统代理时，Chrome 可能正常访问 Google AI Studio，但终端里的 huggingface-cli download、git lfs pull 仍直连失败。对「试玩 + 拉权重」组合场景，更稳妥的是启用 TUN，让未显式配置代理的进程也进入 Clash 规则引擎；驱动与权限说明可参考《Clash Verge Rev TUN 模式完全指南》。

若暂时不能开 TUN，请在同一 Shell 会话中导出与 Clash 监听端口一致的 HTTP_PROXY / HTTPS_PROXY，并确认 NO_PROXY 未误排除 huggingface.co 或实际下载主机。容器内拉模型时，优先让容器继承宿主的 DNS 与代理策略，而不是在镜像里写死境外代理地址，以降低泄露与维护成本。

大文件下载对连接稳定性敏感：若节点频繁切换，会导致多段重传与校验失败。可把 PROXY_HF 绑定到支持长连接、丢包低的入口，并避免与其他高并发任务共用同一劣质线路。

8 DNS、日志与典型故障

「网页能打开、下载全红」时，先在日志里区分问题出在解析还是传输：FakeIP 与 DoH 策略不一致时，规则看似命中 PROXY_HF，实际 TLS SNI 与路由却可能不一致。建议在变更节点后清理本机 DNS 缓存，再用最小文件重复试传。

若 Google AI Studio在加载 Gemma 4卡片时偶发空白，检查是否仍有遗漏的 Google 子域被前置规则直连；同时观察是否存在 QUIC 相关干扰，必要时在浏览器侧关闭实验性 QUIC 做对比测试。

最小验证步骤 ① 浏览器完成 AI Studio 登录并打开任意 Gemma 试玩页；② 日志确认 Google 域命中 PROXY_GOOGLE；③ 用 CLI 或浏览器下载一个几十 MB 的公开权重片段，确认 LFS/CDN 主机命中 PROXY_HF。三步通过后再进行大批量拉取。

9 常见问题

HF 网页正常，git lfs 一直超时：多为终端未走代理；启用 TUN 或为 Git 配置与 Clash 一致的 HTTPS_PROXY。
下载进度卡住某一百分比：日志中可能出现新的 CDN 主机名；将该后缀加入 PROXY_HF 或对应 Rule Provider。
AI Studio 与 HF 只能通一个：检查两个策略组是否误指向同一拥堵节点，或规则顺序是否让其中一侧被 DIRECT 提前匹配。
与 Gemini API 深度混用：请交叉阅读 Gemini 专题，把 generativelanguage 等 API 域一并纳入 Google 组，避免脚本侧遗漏。

10 总结

Gemma 4把 Google AI Studio上的抢鲜试用与 Hugging Face上的开放权重、模型下载绑在同一条开发者时间线上；用 Clash 分流规则把它们拆成可观测、可更新的两个策略面，再配合 DOMAIN-SUFFIX 与远程 Rule Provider，比临时全局代理更能扛住 CDN 变化与长文件传输。与站内 Gemini 专题分工明确：Google 域族与 API 细节以那篇为准，本文补齐 HF 与下载侧常见坑位。

相比其他同类工具，Clash 系在规则透明度与 Mihomo 生态上的组合，特别适合需要同时照顾浏览器试玩、命令行拉权重与团队共享 Profile 的用户；把 PROXY_GOOGLE 与 PROXY_HF 写清楚并定期验证更新，往往比反复更换客户端更能减少间歇性失败。

需要安装或升级图形客户端时，请使用本站下载页获取各平台安装包；开源仓库可作为协议与贡献信息参考，与日常安装包获取路径区分开，更符合安全与版本管理习惯。

→ 立即免费下载 Clash，开启流畅上网新体验

Gemma 4 开放模型火了：
Clash 分流访问 AI Studio 与模型仓库