1 背景：Gemma 4 と「二正面」のトラフィック
Gemma 4 は、Google が 2026 年 4 月初旬に打ち出したオープンウェイトのモデルファミリーで、推論品質やエージェント的なワークフローへの適合をアピールする位置づけです。クラウド上のクローズドモデルではなく、重みを手元や自前 GPU に落とし込んで試す開発者が増える一方で、最初の体験は依然として Google AI Studio のブラウザ UI から入る人が多いでしょう。そこから本番寄りの検証へ進むと、モデルカードや Git LFS を通じて Hugging Face 上のリポジトリへアクセスし、数ギガバイトから数十ギガバイト規模のファイル転送が始まります。
このときネットワーク上で起きやすいのは、「AI Studio のチャットは快適なのに、git clone だけ異常に遅い」「Hugging Face のページは開けるのに、LFS のダウンロード URL だけ別ドメインで失敗する」といった経路の分裂です。原因はマルウェアではなく、多くの場合 rules の優先順位と MATCH の落ち先、あるいはブラウザと CLI が参照するプロキシ設定の差です。Clash 互換クライアント（Mihomo コア）では、DOMAIN-SUFFIX で束ね、不足分を接続ログから補うのが現実的な運用になります。
本稿は Gemma に限定した公式ホスト一覧を断定するものではありません。Google と Hugging Face は CDN やエッジの構成を随時更新するため、実測ログを正にしつつ、ルールのテンプレートと Rule Provider の更新リズムを揃えることに焦点を当てます。利用規約・輸出規制・社内情報システムの方針は必ず優先してください。
2 Google と Hugging Face の両輪で考える
Gemma 4 を題材にしたとき、開発者マシンから出る HTTPS は大きく二系統に分かれます。第一に、Google AI Studio と Google アカウント、静的アセット、Generative Language API などに代表される *.google.com／*.googleapis.com／*.gstatic.com 系。第二に、モデルカード閲覧・トークン発行・コミュニティ機能を含む huggingface.co、短縮ドメインの hf.co、大容量配信用に観測されやすい cdn-lfs.huggingface.co などの Hugging Face エコシステムです。どちらか片方だけルールでカバーすると、もう片方が DIRECT に落ちて帯域制限や不安定なピアリングに晒され、体感では「半分だけ速い」状態になります。
さらに huggingface-cli や Python の huggingface_hub は、OS の環境変数 HTTPS_PROXY を見る一方でブラウザはシステムプロキシや独自のプロキシ設定を見る、という二重の入口があります。Clash の TUN モードで仮想 NIC に揃えるか、シェルと IDE に同じプロキシを明示するか、どちらかで「ブラウザと CLI の出口」を一致させない限り、再現性のあるベンチマークは取りにくいです。
3 Gemini 2.5 記事との棲み分け
本サイトの日本語ブログには、すでに Gemini 2.5 と Google AI Studio を Clash で安定させる記事があります。あちらは Google クラウド側のドメイン設計と Generative Language API を主役にしており、Gemini ブランドのストリーミング応答に強い構成が中心です。本稿はあえて同じ AI Studio 入口でも、オープンウェイトの取得経路（Hugging Face・LFS・大容量 CDN）に軸足を移します。
つまり読み分けとしては、Gemini 2.5 記事で Google 系の「土台」を押さえ、本稿で Hugging Face 系のサフィックスと長時間転送の注意点を足す、という積み上げが自然です。Google ルールの詳細な並べ方や DNS の深掘りは前者とDNS 実務記事に譲り、ここでは HF 側の落とし穴と Rule Provider の運用に紙幅を割きます。
4 Google AI Studio 側で押さえるホスト
AI Studio を開いてモデルを選び、チャットやコード生成を試すまでの間、ブラウザは短時間に多数のホストへ並列接続します。アカウント連携では accounts.google.com、API 呼び出しでは generativelanguage.googleapis.com をはじめとする *.googleapis.com、静的資産では gstatic.com や googleusercontent.com が絡むことがあります。Gemma 4 の試用 UI もこの枠組みに収まるため、Google 向けサフィックスをひとまとまりのセレクタに載せる設計が再現性を高めます。
すでに購読ルールに「Google」カテゴリが含まれている場合でも、国内直行ルールとの評価順を誤ると意図せず DIRECT に滑ります。Clash の接続ログで、失敗リクエストの SNI がどのルール行にマッチしたかを確認し、必要なら Google 用ブロックを上へ寄せてください。企業プロキシと二重化している場合は、TLS インスペクションで証明書エラーが出ていないかもあわせて見ます。
5 Hugging Face：モデルカード、LFS、CDN
Hugging Face は表向きの UI が huggingface.co にありますが、実際のモデルダウンロードは LFS や CDN の別ホストへリダイレクトされることが珍しくありません。観測例として cdn-lfs.huggingface.co が挙がることが多く、環境によっては短縮 URL の hf.co が挟まります。リリース直後の Gemma 4 のようにアクセスが集中すると、エッジの選択やレート制限の挙動が日々変わり得るため、ホスト名を固定リストだけで完結させようとすると保守が破綻しがちです。
運用上のコツは、(1) DOMAIN-SUFFIX,huggingface.co と DOMAIN-SUFFIX,hf.co を同じアウトバウンドに載せる、(2) ログに出た LFS／CDN 用サブドメインを追記する、(3) それでも漏れる場合は一時的に DOMAIN-KEYWORD,huggingface のような広めの行を検討し、落ち着いたらサフィックスへ戻す、の三段です。キーワードルールは誤爆しやすいので、長期運用では必ず絞り込みます。
6 DOMAIN-SUFFIX と YAML の骨格（例）
以下は Mihomo／Clash Meta 互換の rules に追記するイメージです。AI_DEV_PROXY は手元のセレクタ名に置き換え、GEOIP や社内向け DIRECT ルールとの順序を必ず確認してください。コメントは仕様に従い英語のみとします。
# Place ABOVE MATCH / generic catch-all rules. Replace AI_DEV_PROXY.
rules:
- DOMAIN-SUFFIX,google.com,AI_DEV_PROXY
- DOMAIN-SUFFIX,google.dev,AI_DEV_PROXY
- DOMAIN-SUFFIX,googleapis.com,AI_DEV_PROXY
- DOMAIN-SUFFIX,gstatic.com,AI_DEV_PROXY
- DOMAIN-SUFFIX,googleusercontent.com,AI_DEV_PROXY
- DOMAIN-SUFFIX,huggingface.co,AI_DEV_PROXY
- DOMAIN-SUFFIX,hf.co,AI_DEV_PROXY
# Uncomment if your logs show LFS/CDN hosts outside the suffixes above:
# - DOMAIN-SUFFIX,cdn-lfs.huggingface.co,AI_DEV_PROXYGoogle のサフィックスを広く取ると Gmail や Drive まで同じ出口に乗ります。職場ポリシーで分離したい場合は、セレクタを二つに分け、HF 用に遅延よりもスループットを優先したノードを割り当てる、といった運用もあります。逆に、ダウンロード専用のセレクタを切ると、チャット用の低遅延ノードと帯域重視ノードを切り替えやすくなります。
7 Rule Provider と更新戦略
コミュニティの Rule Provider は、グローバル SaaS やメディア向けのリストをまとめて配布してくれる一方、新しい CDN 名や Hugging Face のエッジ変更がリストに反映されるまでタイムラグがあります。Gemma 4 のような話題リリースの直後は、ローカル rules に数行の「上書き」を置いておき、落ち着いたら Provider 側の更新に任せる二段構えが現実的です。
rule-providers の interval を短くしすぎると購読元に負荷がかかるため、公式が推奨する間隔とチームの変更頻度のバランスを取ります。Git で設定を管理するなら、Pull Request に「追加したドメインと、接続ログでの根拠」を残すと、数か月後の自分が助かります。Provider を複数マージしている場合は、同一ドメインが別アウトバウンドに二重定義されていないかプレビューで確認してください。
8 huggingface-cli・Git とプロキシ
ブラウザから「Download」を押す経路と、ターミナルから huggingface-cli download する経路は、見かけ上同じファイルでもHTTP クライアントスタックが異なるため、プロキシの見え方がずれます。Python 仮想環境ごとに HTTP_PROXY／HTTPS_PROXY を揃える、Git には http.proxy を設定する、あるいは TUN でプロセス差を吸収する、のいずれかが必要です。
Git LFS は大容量転送の途中でタイムアウトすると再開コストが高いので、セレクタで「長めの TCP セッションに強い」ノードを選び、可能ならダウンロードジョブの単位で出口を固定します。複数ジョブを並列に走らせると、同一ノードの帯域が頭打ちになる点にも注意してください。CI から取得する場合は、ランナー側の環境変数と Clash 側のルールをペアで見直すと早いです。
9 DNS・TUN・長時間転送
cdn-lfs.huggingface.co のような名前が、DNS の応答によっては期待と異なるエッジへ解決されることがあります。Clash 内の DoH、FakeIP、fallback-filter の組み合わせは DNS 実務記事に詳しいので、ここでは「ブラウザの Secure DNS」と「Clash の DNS」を二重に有効にして挙動が読めなくならないことだけ強調します。名前解決とルールの結果が食い違うと、ログ上はマッチしているのに実パケットが別経路へ出る、という混乱の元になります。
TUN を有効にすると、環境変数を設定し忘れた CLI も同じルーティングに乗りやすくなります。一方で企業 VPN やローカル開発用の例外ルートと衝突する場合があるため、企業 VPN と Clash を併用する記事の考え方とあわせて、デフォルトゲートウェイの優先順位を確認してください。長時間ダウンロードではノード切り替えによる接続リセットも起こり得るため、ジョブ中はセレクタを固定する運用が無難です。
10 トラブルシューティング
- AI Studio は動くが HF の LFS だけ失敗： ログで LFS 用ホスト名を特定し、
DOMAIN-SUFFIXを追記。CLI にHTTPS_PROXYが無い場合は TUN か環境変数を補います。 - ブラウザは成功して git のみタイムアウト： Git のプロキシ設定と Clash のルールの両方を確認。証明書エラーなら企業 TLS インスペクションを疑います。
- 転送が途中で切れる： ノードのパケットロスや帯域上限、HTTP/2 の長连接切断を疑い、セレクタで別アウトバウンドへ切り替えて比較します。
- 急に遅くなった： CDN 側の負荷か、DNS 応答が変わって遠いエッジに刺さったかを切り分けます。DoH を一本化して再試行します。
- ルールを足したら国内サイトが遅い：
DOMAIN-KEYWORDの広げすぎや、GEOIP,JP,DIRECTより上に誤った行が来ていないか順序を見直します。
11 まとめ
Gemma 4 のようなオープンウェイトの波は、Google AI Studio での試用と、Hugging Face を介したモデルダウンロードという二つの HTTPS 束を同時に要求します。Clash では DOMAIN-SUFFIX で Google 系と HF 系をまとめ、ログで漏れた CDN 名を足し、Rule Provider の更新とローカル上書きの役割分担を決めると、リリース直後の慌ただしい検証でも経路がブレにくくなります。
Gemini 2.5 向けの Google 分流記事と本稿を組み合わせれば、クラウド推論とオープンウェイト取得の両方を同じクライアント設計で支えられます。DNS と TUN の細部は専門記事に譲りつつ、出口の一貫性を最優先すると、エージェント実験やファインチューニングの前段階でつまずきにくくなります。
単純な HTTP プロキシだけを切り替えるより、ルールと DNS を一体で扱える Clash 互換スタックの方が、分散ドメインと長時間転送に強い場面が多いです。試行錯誤のサイクルを短くしたい開発者ほど、一度ルールセットを整備する投資効果が大きくなります。
→ 無料で Clash をダウンロードし、Gemma 4 の試用と Hugging Face の取得を同じ分流で安定させる
