Hugging Face の取得が止まる？Clash で hf.co・Git LFS・CDN を分流する実測手順（2026）

Hugging Face Hub と Clash：「一覧は速いのにダウンロードだけ詰まる」構図

2026 年も、オープンウェイトのモデルや大規模データセットの入口として Hugging Face Hub（ブランド上は Hugging Face、実際のホストは huggingface.co や短縮の hf.co、および配下の CDN／LFS 用サブドメインに分散しやすい）を日常利用する開発者・研究者は増え続けています。ブラウザでモデルカードやファイル一覧を開くのは軽い一方、Git LFS や 大容量バイナリの取得だけが進捗バーで長く止まったり、途中で切断されたりする——そんなとき、原因は「サイト全体がブロックされている」より、オブジェクト配信経路と利用中の出口ノードの相性、そして DNS が返している宛先の組み合わせにあることが少なくありません。

本稿は、OpenRouter など集約 APIや IDE 連携記事とはドメインと用途が異なる前提で、モデル／データセットの取得（git lfs、huggingface-cli、ライブラリ経由の download）に載るトラフィックを対象にします。ルールの型はルール分岐の詳解と共通ですが、ここでは LFS／CDN 層のホスト名を明示的に切り出す設計に焦点を当てます。

なぜ「ページは開くのに LFS だけ遅い」のか

Hub の UI やメタデータは比較的小さな HTTPS レスポンスで済む一方、実体の重いファイルはしばしば 別ホストのストレージや CDN エッジへ誘導されます。Git LFS のバッチ転送は長い TCP セッションと複数レンジリクエストに依存するため、遅延テストの数値だけ良くても途中でリセットされやすい出口では、クライアント側では単なる「固まった」「再試行が多い」に見えます。また、短縮ドメイン hf.co 経由のリダイレクトや、環境によって現れる cdn-lfs 系の名前は、一般ブラウジングと同じプロキシグループに載せたときだけ律速になる、というパターンも典型です。

さらに、huggingface_hub や git、コンテナ内の取得処理は、OS のシステムプロキシや TUN の取り込み方がブラウザと一致していないと、片方だけ直結・片方だけプロキシ、という状態になりがちです。OS 全体へ透過させる手順はTUN モード完全ガイドが参考になります。

コピー用：Hub・LFS・短縮ドメイン周辺のホスト例

実務の出発点として、次のような DOMAIN-SUFFIX を挙げます。リポジトリやツールの版によって追加ホストが出るため、取得失敗時は接続ログで足し引きしてください。

• Hub 本体：huggingface.co（モデルカード、API エンドポイント、認証まわりがここに載りやすい）
• 短縮／リダイレクト：hf.co（共有リンクや一部取得フローで先行し、最終的にストレージ側へ跳ぶことがある）
• LFS／オブジェクト配信：ログに cdn-lfs.huggingface.co や類似の cdn-lfs 系ホストが出る場合は、上位の huggingface.co で覆えることが多いが、実測で別名があれば DOMAIN 行で補強する
• Git 操作：git clone／git lfs pull が参照するホストが上記と一致しない場合、エラーメッセージに出た実ホスト名を最優先でルールに追加する

DOMAIN-KEYWORD,huggingface のような広い書き方は、意図しないサブサービスまで同じ出口に載せる恐れがあるため、まず DOMAIN-SUFFIX,huggingface.co と DOMAIN-SUFFIX,hf.co の二行から始め、ログで漏れを足すのが安全です。

「HF ダウンロード」専用プロキシグループを切る理由

購読ルールが「海外サイトをまとめて一つの select」のままだと、軽い HTTPS と数ギガバイト級の LFS 転送が同じ出口に載り、後者だけが不安定に見えます。HF_DOWNLOAD のような名前の独立プロキシグループを用意し、huggingface.co／hf.co 向けだけそこへ流すと、(1) 長時間転送に強いノードへ固定しやすい、(2) ログで「どのホストがどの出口か」追いやすい、(3) ブラウザ用の出口と切り離して帯域を圧迫しにくい、という利点があります。

評価順：HF 行をどこに置くか

Clash 系の rules: は上から順に評価され、最初の一致で打ち切られます。Hub 向けの行を末尾に追記したつもりが、上段の GEOIP や巨大な RULE-SET に先に飲み込まれている——というのは典型的なパターンです。より具体的な DOMAIN-SUFFIX を、大雑把な締め行より上に置き、保存後は順序を目視してください。

YAML の骨格例（概念サンプル）

キー名やインデントは利用中のコア・GUI に合わせてください。ここでは HF_DOWNLOAD を用意し、rules から参照するイメージだけ示します。

proxy-groups:
  - name: HF_DOWNLOAD
    type: select
    proxies:
      - 🇺🇸 大容量・長接続向け
      - 🇯🇵 安定
      - 🌐 自動選択

rules:
  - DOMAIN-SUFFIX,huggingface.co,HF_DOWNLOAD
  - DOMAIN-SUFFIX,hf.co,HF_DOWNLOAD

このあとに社内ドメインや国内 GEOIP、最後に MATCH などを続けます。ログに別ホストが出たら、その行をこのブロック付近に追加してください。

クライアント別の観測ポイント（git・CLI・Python）

Git LFS は git 本体と別プロセス・別設定を参照することがあります。GIT_LFS_SKIP_SMUDGE や資格情報ヘルパー、企業プロキシ環境では環境変数 HTTP_PROXY／HTTPS_PROXY の有無も確認してください。huggingface-cli や huggingface_hub 経由のダウンロードは、ライブラリが内部的にどの URL を叩いているかが UI より追いにくいため、詰まったタイミングで Clash の接続一覧と突き合わせるのが早いです。並列ダウンロードを増やすオプションやコミュニティ製トランスポート拡張を使う場合でも、最終的なホスト名が本稿のサフィックスで覆えているかは変わりません。

ノード選定：大容量取得を安定させる観点

遅延テストの数値だけが良くても、途中切断が多いノードでは LFS が再開ループに入り、体感は「ずっと止まっている」に近づきます。実務では次を意識すると切り分けが速いです。

• 帯域と切断のバランス：同一プロバイダー内で地域やプロトコルを変え、単一ファイルの取得が最後まで完了するか比較する
• CLI とブラウザを分けて観測：片方だけ失敗するときは、TUN 未捕捉プロセスや環境変数の抜けが原因のことが多い
• IP ルールとの競合：解決済み IP が IP-CIDR や GEOIP に先にマッチし、ドメイン行より IP 側が優先されていないか確認する

DNS・TLS：遅延に見える別要因

ルールはドメイン行と IP 行が混在します。DNS が Clash の想定とずれていると、YAML は正しそうでも実接続は別経路に落ちます。典型例は次のとおりです。

• ブラウザや OS の Secure DNS が Clash 外で先に解決し、想定外の CDN エッジが選ばれる
• Fake-IP と、一部プロセスだけ直叩きするシステム DNS が混在し、マッチと実接続の関係が追いにくくなる
• 中間機器が長い TLS セッションを切り、クライアントではタイムアウトに見える

対策の方向性は「名前解決の経路をできるだけ一本化し、TUN や DNS ハイジャックを併用するならその前提でルールを読む」ことです。設定変更後は DNS キャッシュのクリアと、同一ファイルの再取得をセットで確認してください。

検証チェックリスト（そのまま試せる順序）

1. 失敗しているコマンド（git lfs pull、huggingface-cli download 等）実行中に、Clash の接続ログでホスト名をメモする
2. 該当ホストが HF_DOWNLOAD（または同等のグループ）に乗っているか確認する
3. 同じプロファイルのままノード地域やプロトコルだけを切り替え、再現性が変わるか比較する
4. ブラウザでは通るが CLI だけ失敗するときは、プロキシ環境（環境変数・TUN・システムプロキシ）を揃えて再試行する

よくある誤解と切り分け

DOMAIN-KEYWORD で雑にまとめる

手早い反面、無関係なホストまで同じ出口に載り、期待しない挙動の原因になり得ます。まず huggingface.co と hf.co の DOMAIN-SUFFIX から始め、ログで漏れを足してください。

ルールを足したのに効かない

多くは順序かグループ名の綴りです。外部 RULE-SET を大量に載せている場合、明示ルールが下に埋もれていないかを確認してください。

CDN ホストだけ別出口に落ちている

LFS 用のホストが想定と異なるサブドメインになっている場合、親サフィックスで足りないことがあります。接続ログの実名をルールに追記してください。

まとめ

2026 年の機械学習ワークフローでは、Hugging Face Hub からのモデルダウンロードとデータセット取得が日常業務の中心にあります。「サイトが開かない」より、Git LFS や cdn-lfs 系経路だけが律速する相談は、単一ノードの ping 値だけでは説明できず、huggingface.co／hf.co 向けトラフィックを独立プロキシグループへ寄せ、評価順序とDNS をセットで設計すると成功率が体感しやすく上がります。コンテナや CI からの取得を扱う場合は、Docker Desktop と Clashの記事と合わせ、デーモン側のプロキシ参照も揃えると再現性が高まります。

用語や汎用手順は当サイトのチュートリアル・ドキュメントも参照できます。クライアントの入手と更新はダウンロードページから環境に合わせて選べます。ルールの基礎はルール分岐の詳解、OS 全体へ透過的に効かせたい場合はTUN ガイドと併読すると、本稿の設定がすぐ実装に落ちます。用途別にトラフィックを制御できる点が、研究・開発の両方で実用的です。→ Clash クライアントを無料でダウンロードし、Hugging Face 向け分流を試す