なぜ Hugging Face だけ「途中で切れる」のか
Hub 上のモデル取得は、ざっくり言うと 小さな JSON／HTML とメタデータ の往復と、数ギガバイト級の単一オブジェクト のダウンロードがセットになったワークロードです。前者は huggingface.co や短縮ドメイン hf.co 側の API・認可フロー に寄りがちで、後者は Git LFS のバッチ転送 や CDN エッジ に振り分けられることが多く、接続先のホスト名がログ上で明確に分かれます。このときすべてを同じ ポリシーグループ に載せると、「API だけ別ノードにしたい」「LFS だけレイテンシよりスループット優先の出口にしたい」といった微調整がしづらく、結果として 再開（resume）やチャンク取得 のたびに別経路に振られて不安定に見える、という現象が起きやすいです。
加えて、企業ネットワークやクラウド VPC では、長時間の TLS セッションや大きな TCP ウィンドウを途中のセキュリティ機器が嫌う構成も珍しくありません。これは Clash の設定以前のレイヤの話ですが、出口を変えると症状が変わる ため、実務では「まずログのホスト名を確定し、次にルールで束ねる」順序が安全です。分流の一般論は YAML ルール分流ガイド に譲り、本稿では HF 特有の切り口に集中します。
トラフィックの三層：Hub API・Git LFS・静的 CDN
実装の前に、取得処理を三つのバケツに分けて考えると設計がブレません。第一に Hub API と Web UI です。モデルカードの表示、トークン認可、リビジョン情報の取得などがここに含まれます。第二に Git／Git LFS の制御面 です。git clone や git lfs pull が参照する .lfsconfig やバッチ API は、一般のブラウズよりも 細かいホストの切り替え を伴います。第三に 実体ファイルのバイナリ配信 です。ここはプロバイダやリージョンによって cdn-lfs.huggingface.co のような LFS 専用 CDN、あるいは別サフィックスのストレージホストに出ることがあり、時期とアカウント種別で変化します。
huggingface-cli やライブラリ経由のダウンロードも、内部では上記の層を順に叩きます。したがって「CLI だけ失敗する」場合でも、ブラウザと同じ出口に固定せず、失敗した URL のホスト名 を起点にルールを足すのが近道です。
ポリシーグループ設計：HF-API と HF-BULK を分ける
命名はチームの規約に合わせて構いませんが、運用で迷子になりにくいのは次の二段です。HF-API は Hub のメタデータと認可、軽量 JSON 向け。HF-BULK は LFS 実体と大容量 CDN 向け。さらに細かくしたければ HF-WEB を切ってブラウザ閲覧だけ別ノードにする三段もありえますが、YAML の複雑さとのトレードオフなので、まず二段でログを見ながら増やす のが現実的です。
HF-BULK は url-test で自動選択より、select で手動固定したほうが再現性が高い場面があります。理由は、自動選択がレイテンシ基準で振ると、ギガバイト級転送ではレイテンシより損失率とスループット が支配的だからです。夜間バッチで落とすなら安定重視ノード、日中の試行錯誤なら低遅延ノード、のように人間が明示切替できるとトラブルシュートが早くなります。
proxy-groups: - name: "HF-API" type: select proxies: - "node-stable" - "DIRECT" - name: "HF-BULK" type: select proxies: - "node-high-throughput" - "node-stable" - "DIRECT"
コア側の挙動差で詰まる場合は、Clash Meta（mihomo）コアのアップグレード も併せて検討してください。HTTP/2 や長尺ダウンロードまわりはクライアントとコアの組み合わせで差が出ます。
ルール例：ドメインを HF-API／HF-BULK に振り分ける（たたき台）
以下は 出発点 です。購読プロファイルでは、これらの行を広い GEOIP や MATCH より 上 に置き、ポリシー名を自環境に合わせて置換してください。実ホスト名はログで検証し、足りない行を DOMAIN で追加するのが安全です。
rules: - DOMAIN-SUFFIX,huggingface.co,HF-API - DOMAIN-SUFFIX,hf.co,HF-API - DOMAIN-SUFFIX,cdn-lfs.huggingface.co,HF-BULK # DOMAIN,other-storage-host.example,HF-BULK # Then generic rules (GEOIP, MATCH, ...)
RULE-SET が先にマッチして意図と違う出口に出ている場合は、HF 向けの行をその より上 に移すか、購読側の順序設計を見直します。競合の典型は、「海外向けセットに huggingface.co が含まれているが、別ポリシー名に固定されている」ケースです。ログで どのルール名に当たったか を確認し、重複を解消してください。
Git と Git LFS のプロキシ環境変数
ターミナルから git clone する場合、OS の HTTPS_PROXY と Git 自身の http.proxy、さらに Clash の TUN／システムプロキシ が重なると、Clash 上では正しく分流していてもプロセスだけ別経路、ということが起きます。どの設定が実際に効いているか を git config --list と環境変数の両面から確認してください。Git LFS は Git の上に載るため、まず Git のプロキシ経路を揃えるのが先です。
タイムアウトと再試行：ログとルールの突き合わせ方
大容量転送の失敗は、大きく DNS、TCP 接続、TLS、中間の HTTP ステータス に分類できます。Clash ログでは、接続試行時に マッチしたルール行 と 選択されたポリシー がセットで出ることが多いので、「HF-BULK に載せたつもりが PROXY の別ノードに出ている」「DIRECT に落ちている」といった 意図と実際の乖離 をまず潰します。
再試行ループに入ったときは、クライアント側の 並列数 も確認してください。あまりに多い同時接続は、住宅系回線や安価な VPS 出口でパケット落ちを誘発し、結果として LFS の再開が不安定になります。Clash の設定というより運用パラメータですが、出口を変えたら同時数も見直す と改善することがあります。
- 途中で速度が落ちて止まる：別ホストへのリダイレクトやレンジ GET の再開点が変わっていないか、ログのホスト名が切り替わっていないかを確認します。
- 最初の数パーセントだけ進む：認可トークンや署名付き URL の期限切れ、あるいは API 側のレート制限が疑わしいです。API とバルクで出口が分かれすぎていると、片側だけブロックされる、という見え方になります。
- ブラウザは成功・CLI は失敗：プロキシの二重適用や
NO_PROXYの取り違えを疑います。
DNS の見え方が原因のときは、Fake-IP と redir-host の切り分け を参照し、名前解決とルールマッチの順序を整理してください。特に fake-ip 利用時は、一見同じドメインでも内部表現が変わり、ルールの想定とズレることがあります。
CDN と LFS を分けるときの判断軸
厳密にはすべてが LFS というわけではなく、小さなシャードやインデックス、サムネイル類は 一般 CDN に乗ることがあります。運用上は「ファイルサイズ」より ログに出たホストの系統 で分けるほうがブレません。例えば *.cloudfront.net のような汎用 CDN 名だけを拾うと他サービスまで巻き込むため、まず DOMAIN で HF 取得中に観測されたフルホスト をホワイトリスト的に足し、安定したら DOMAIN-SUFFIX へ昇格させる段階的アプローチが安全です。
研究室やチームで共有マシンを使う場合、個人の Clash 設定に加えて 共有キャッシュ（ローカルミラー、社内 Artifactory 等）を併用する構成もあります。その場合でも、Clash 側では ミラーへ向くホスト名 を DIRECT または社内出口のポリシーに固定する、という整理がしやすいです。
まとめ
2026 年もオープンウェイトの需要は高く、Hugging Face は事実上のハブです。Clash で体験を安定させるコツは、取得処理を Hub API・Git LFS・CDN に分解し、ログに出る 実ホスト名 をもとに ポリシーグループ を分けること、そして ルールの順序 と DNS モード をセットで確認することです。レジストリや IDE 更新に寄せた Cursor／npm 向け分流 と題材は異なりますが、「ログでホストを確定してからルールを足す」 という作業姿勢は共通です。合わせて読むと、開発者ワークステーション全体の出口設計がしやすくなります。
クライアントの選定や入手は ダウンロードページ から一括で確認でき、長時間転送ほど「コアの更新」と「ルールのメンテ」が効いてきます。同等の GUI でも、ログの見え方や TUN の取り込み範囲は製品ごとに差があるため、自分の環境に合うクライアントから試すのがおすすめです。