Hugging Face のダウンロードが止まる？Hub・CDN・git-lfs を Clash（mihomo）で分流する実測（2026）

1. 対話型 AI 向け記事との違い（取得経路の形）

当サイトでは ChatGPT や DeepSeek のように、チャット UI と REST API が同一ブランドのサブドメイン配下にまとまりやすいケースを多く扱っています。一方、Hugging Faceはモデルカード閲覧（Web）、Hub API、Git と git-lfs による重いオブジェクト転送、さらに実ファイル配信に関わる CDN 側ホストへと通信が分岐しやすく、「ページは開くのに pull だけ遅い」が典型パターンになります。したがって、ルール設計はドメインの束ね方に加え、転送プロトコル（HTTPS の長セッション、LFS バッチ）とクライアントがプロキシを読むかどうかまでセットで見る必要があります。

本稿は製品レビューではなく、開発環境で再現性のある切り分けに寄せています。利用規約・ライセンス・地域に関する表示はサービス側のポリシーに従ってください。ここで述べる手順は一般情報であり、特定サービスの利用を推奨・保証するものではありません。

購読の取り込みやクライアント導入は サブスクリプション導入ガイドを参照しつつ、以下では Hugging Face 向けにホスト名の出発点とDNS の取り回しに焦点を当てます。

2. 症状を「Hub」「LFS・CDN」「クライアント」の三層で切り分ける

第一層はHub 本体と短縮ドメインです。認証やモデルカード、REST 風の API 呼び出しは huggingface.co 配下に集まりやすく、短縮リンクや一部フローでは hf.co が表に出ます。ここだけプロキシに載せ、別経路で名前解決されているホストが混ざると、画面は軽いのに取得だけ不安定に見えます。

第二層がLFS と CDNです。大容量の重みやデータは git-lfs のエンドポイントや、オブジェクトストレージ・CDN 側のホスト名へ直接伸びることがあり、ブラウザが触るホストと CLI が触るホストが一致しないことがあります。コミュニティのトラブルシュートでも、cdn-lfs 系のサブドメインや、リダイレクト先の別ホストをルールに足す話が繰り返し出ます。インフラは変わり得るため、ログと開発者ツールで実名を確認してから固定化するのが安全です。

第三層がクライアントです。ブラウザは OS のプロキシ設定や拡張に従いやすい一方、ターミナルの git や Python から叩く huggingface_hubは環境変数 HTTPS_PROXY を明示しないと直結のまま、という組み合わせがよく起きます。NO_PROXY に意図せず広い例外が入っているケースも、API 系の記事と同型です。

3. まず束ねたいホスト名：huggingface.co・hf.co・LFS 周辺

出発点として多いのは次の二行です。DOMAIN-SUFFIX,huggingface.co は huggingface.co 配下の API・認証・ウェブ UI を広く拾い、DOMAIN-SUFFIX,hf.co は短縮ドメイン側をまとめます。実運用では cdn-lfs.huggingface.co のような LFS 向けホストがログに単独で現れるため、suffix で既に覆われているかを確認しつつ、suffix が足りない別レジストラのホストが出たら DOMAIN 行で追加します。

Spaces や推論系の別サブドメイン、サードパーティの埋め込みが混ざると、HF 以外のホストが頻出します。ネットワークタブとコアログの両方で失敗しているホスト名をメモし、過度に広いワイルドカードは避けて足し込むのが無難です。ストアやゲームクライアントの CDN 分流と考え方は近く、Steam 向けの CDN・ダウンロード地域の記事と併読するとイメージが揃いやすいです。

ルールの評価順は ルールルーティング解説のとおり、具体的な DOMAIN 行を、広い GEOIP や MATCH より上に置きます。購読ルールセットの末尾に追記するだけでは効かないことがある点に注意してください。

4. mihomo ルール例：HF 専用の策略グループへまとめる

実務では Hugging Face 専用の策略グループを一つ切り、安定したノードを割り当てると切り分けがしやすいです。帯域の大きい転送では遅延よりも抜けと速度の安定が効くことが多く、同一グループ内で別ノードに切り替えて比較する運用が向きます。以下は構造の例です。プロキシ名は環境に合わせて置き換えてください。

# proxy-groups: dedicated group for Hugging Face Hub / LFS / short domain
proxy-groups:
  - name: HUGGINGFACE
    type: select
    proxies:
      - NODE-A
      - NODE-B
      - DIRECT

# rules: place before broad MATCH / GEOIP
rules:
  - DOMAIN-SUFFIX,huggingface.co,HUGGINGFACE
  - DOMAIN-SUFFIX,hf.co,HUGGINGFACE
  - MATCH,PROXY

ログに huggingface や hf.co を含まないホストが出る場合は、そのホストを DOMAIN, または DOMAIN-SUFFIX, で追加します。HTTPS で接続先が IP 評価に偏っている環境では Sniffer と SNI の記事も参照し、意図したドメインでルールが当たっているかを確認してください。

TUN モードとシステムプロキシでは挙動が変わります。モードごとの違いは TUN モードの解説も参照し、名前解決と実接続のログが矛盾していないかを確認してください。

5. DNS・fake-ip と Sniffer（HTTPS の SNI）の整合

mihomo 系で fake-ip を使う構成では、アプリが受け取る IP と実際の出口決定のステップが分かれるため、ルールを増やしても体感が変わらないように見えることがあります。Hugging Face のような HTTPS で SNI にホスト名が載る通信では、Sniffer 有効時の挙動と DNS の問い合わせ経路をセットで確認する価値があります。考え方の骨格は Claude 向け DNS 稿と重なりますが、本稿では大容量転送と LFSのほうがボトルネックになりやすい点が異なります。

切り分けの手順としては、（1）コアの DNS ログで HF 関連クエリがコアに届いているか、（2）接続ログで HUGGINGFACE グループ（または意図した策略）にマッチしているかを、同じ取得操作の前後で見比べます。ブラウザだけ成功して CLI だけ失敗するときは、fake-ip 以前に OS や Git 自体の DNS 設定が別経路になっていないかも疑ってください。

企業ネットワークでは分割 DNS や SSL インスペクションが入り、自宅で動いた設定が再現しないことがあります。その場合は社内ポリシーを優先し、本稿は個人環境向けの参考として扱ってください。

6. Git・huggingface-cli・環境変数：ブラウザとズレる理由

git と git-lfs は、リモート URL が https://huggingface.co/... であっても、LFS オブジェクトの実取得先は別ホストへリダイレクトされることがあります。Clash 側のルールが整っていても、ターミナルがプロキシを読んでいないと出口が揃いません。mixed-port や HTTP ポートに向けるなら、シェルで export HTTPS_PROXY=http://127.0.0.1:7890 のように明示し、NO_PROXY に誤って広いサフィックスが入っていないかも確認してください。

Python から huggingface_hub を使う場合も同様で、ランタイムを起動した IDE が別のプロキシプロファイルを持っていると、ターミナルと結果が分かれます。Cursor 向けの開発者ドメイン分流稿と組み合わせると、エディタ内の取得とシステム全体のルールの両方を点検しやすくなります。

コンテナや WSL からホストの Clash を参照する構成では、Docker がホストのプロキシを使う記事や、ミラー型ネットワークまわりの記事とゲートウェイ・DNS の整合が重要です。どの名前空間がどのリゾルバを見るかがずれると、ルールだけ直しても再現しません。

7. 実測の進め方：ログで CDN ホストを拾い足す

おすすめの順序は次のとおりです。（1）問題の取得操作をしながらコアログで HF 関連ホストがどの策略にマッチしたかを確認する。（2）意図したグループに揃っているのに失敗するなら、DNS ログと fake-ip 設定を確認する。（3）ブラウザは通って CLI だけ失敗するなら HTTPS_PROXY と NO_PROXY、IDE 設定を確認する。（4）HTTPS が IP 評価に偏っているなら Sniffer と SNI を確認する。（5）それでも断続するなら別ノードへ切り替え、同じファイル取得を再試行する。

開発者ツールのネットワークタブと GIT_TRACE や GIT_CURL_VERBOSE など、Git 側が実際に触っている URLを一時的に詳細表示する手段を併用すると、ルールに書くべきホスト名が明確になります。再現手順が長いほど、ログのタイムスタンプと操作の対応を取る習慣が効いてきます。

ミラーサイトや公式の代替エンドポイントを使う運用は環境依存が大きいため、本稿では扱いません。Clash でドメイン単位に出口を揃え、ログで足りないホストを追記する方針が、長期的には追いやすいです。

8. つまずきやすいポイント

第一に、ルールの順序ミスです。広い MATCH や GEOIP が先に勝つと、HF 用の行が評価されません。ルールの並びを購読ファイル全体で見直してください。

第二に、CLI の直結です。ブラウザは通っても git が直結のままだと、出口が変わらずタイムアウトが続きます。環境変数とアプリ個別設定を疑ってください。

第三に、レート制限や認証エラーです。プロキシを正しくしても 401 や 403、429 が返る場合は、トークン・組織権限・利用枠などアカウント側の要因を切り分けてください。本稿はネットワーク経路に焦点を当て、課金やアカウント状態の詳細には踏み込みません。

9. まとめ

Hugging Faceの取得トラブルは、Hub・短縮ドメイン・LFS・CDNへ通信が分散するタイプの問題として捉えると切り分けが速くなります。まず mihomo で huggingface.co と hf.co を専用策略に揃え、ログに出る別ホストを足し込みます。ブラウザと CLI で挙動が分かれるときは DNS（fake-ip）と環境変数を疑い、HTTPS のみルールがずれるときは Sniffer と SNIを確認してください。同じ Clash 系スタックでも GUI の表記とコア世代は移り変わります。購読とルールを整理し、ログでホスト名を追う姿勢を保つのがいちばん確実です。

大容量転送でも観測しやすいログとルールの組み合わせは、エンタメ系ストリーミングや対話型 AI とは別の快適さにつながります。クライアントの入手から始めるなら、 → 無料で Clash をダウンロードし、快適な接続体験を試す ところから環境を揃えるのがおすすめです。