Hugging Face のモデル取得が遅い／403？2026 年、Clash の分流で学習・推論アクセスを安定させる

遅さ・切断・403 が出るときの整理

症状を混ぜると手戻りが増えます。まずは次のように分けて観測してください。

• スループット型：数 GB のシャード取得で速度が伸びない、残り時間が暴れる。多くは CDN 経路や混雑した出口の問題。
• ハンドシェイク型：TLS が遅い、最初の数 MB だけ進んで止まる。DNS・fake-ip・IPv6 の取り違え、または不安定な中継が疑わしい。
• 403／401 型：ブラウザでは開けるのに huggingface-cli や git lfs だけ失敗する。トークン未設定、古い HF_TOKEN、Organization の権限、あるいはエッジ側のボット判定が絡むことがあります。

Clash は経路の一貫性を上げる道具です。認可そのもの（誰がどのモデルを読めるか）は Hub 側のポリシーに従います。利用規約とライセンス、組織のデータ持ち出しルールは各自で確認してください。

ルールに載せたいドメインの束

実装はクライアントごとにマージ順が違いますが、考え方は共通です。Web UI・REST・LFS・Spacesが別ホストに散らばっても、まずは公式が案内する接続先をひとつのポリシーグループ（例：PROXY-HF）にまとめ、細かい調整はログを見ながら足します。

以下は出発点の例です。購読ルールと衝突しないよう、マージ後の先頭付近に自前の HF ブロックを置くか、ローカルファイルで上書きしてください。

# Illustrative — replace PROXY-HF with your policy group name
rules:
  - DOMAIN-SUFFIX,huggingface.co,PROXY-HF
  - DOMAIN-SUFFIX,hf.co,PROXY-HF
  - DOMAIN-SUFFIX,amazonaws.com,PROXY-HF
  - DOMAIN-SUFFIX,cloudfront.net,PROXY-HF
  - DOMAIN-SUFFIX,github.com,DIRECT
  - DOMAIN-SUFFIX,githubusercontent.com,DIRECT

最後の GitHub 行は「自前コードは直結、HF だけ出口」のように役割分離したいときの例です。実際には LFS ミラーが GitHub 上にある場合もあるため、失敗したホスト名をログで拾って DIRECT か PROXY-HF に振り直してください。amazonaws.com や cloudfront.net は広いので、リモートルールと重なると別サービスまで巻き込みます。専用の狭いルールセットに分けるか、PROVIDER で段階的に有効化するのが無難です。

DIRECT とプロキシのハイブリッド

開発マシンでは次の二層がよく使われます。

1. 社内・国内の依存：社用 Git、社内 PyPI ミラー、VPN 内のレジストリは DIRECT か社内専用グループ。
2. 公開 Hub と大容量：huggingface.co と実際にレスポンスを返している CDN 群を PROXY-HF。帯域と接続維持に強いノードを選ぶ。

Rule モードで全体を細かく保ちつつ、一時的に Global で試すのは切り分けには有効ですが、普段は広い MATCH に頼らず、HF 用の明示ブロックを残してください。そうしないと、後から入れた広域ルールが意図せず DIRECT に落とし、Hub だけ再び不安定になる、という事故が起きやすいです。

DNS と fake-ip のすり合わせ

huggingface-cli や Python の HTTP クライアントは、システム DNS と Clash の redir-host / fake-ip の組み合わせで「名前は解けるが実体の経路が食い違う」状態になり得ます。ブラウザだけ成功する場合は、まず DNS セクションを疑ってください。

手順の骨格は次のとおりです。

• Clash の DNS を有効にし、フォールバックとキャッシュが過剰に遠いリゾルバばかり指していないか確認する。
• fake-ip を使うなら、対象ドメインの nameserver-policy や除外リストが Hub 関連と整合しているか見る。
• IPv6 が有効な回線では、IPv4 だけの出口に乗せたいポリシーと、OS が IPv6 を優先していないかを併せて確認する。

詳細な切り分けは 「接続中なのに繋がらない？DNS と fake-ip」 を参照し、変数は一度に一つだけ動かしてください。

huggingface-cli・Git LFS・ライブラリ側

重みの一括取得では huggingface-cli download や git lfs clone が主流です。どちらも HTTPS を連発するため、同じポリシーグループに載るようにします。ターミナルだけ失敗するときは、GUI ブラウザがシステムプロキシを読んでいるか、ターミナルが読んでいないか、という古典的な差も忘れずに。

HF_ENDPOINT をミラーに向ける運用は環境差が大きいです。ミラーのドメインを別ルールで DIRECT に固定するか、信頼できる出口に載せるかは、そのミラーの所在地と契約次第です。本記事では特定ミラー名は固定しません。

シナリオ別：重み・デモ・Inference API

大容量のチェックポイント：単一 TCP が長時間張り付くため、レイテンシより安定性と帯域を優先した url-test／手動選択のグループに載せる。ダウンロード中に別タスクが同じノードを占有していると速度が割れるので、必要なら時間帯を分ける。

Spaces の対話デモ：WebSocket や SSE が混ざることがあり、短いタイムアウトのノードでは途中切断が出やすいです。HF 用グループのアイドルタイムアウトを確認し、ブラウザの開発者ツールで失敗 URL を拾ってルールに足してください。

Inference API とバッチ推論：エンドポイントはドメインが分岐する場合があります。429／503 が出たときにいきなりルールを疑わず、まずレスポンス本文と Retry-After を見る。経路が安定していてもサーバ側混雑のことはあります。

用途	ルール設計の要点
重み・LFS	CDN 実名をログで確認し、広すぎるサフィックスは段階的に狭める
Spaces	長めの接続向きノード、WebSocket 失敗時はホスト単位で追加
API	レート制限と認証を先に切り分け、経路は一貫させる

サーバ／CI でも同じ考え方

ローカルだけでなく、VPS やランナーから Hub を引く場合も、出口の一貫性が重要です。Linux 常駐構成は 「Clash Meta と systemd」 をベースに、環境変数 HTTP_PROXY／HTTPS_PROXY をコンテナやサービスに渡すか、TUN で全体を捕捉するかを選びます。CI ではキャッシュ層（自前レジストリ、artifact ミラー）と組み合わせると、Hub への再試行回数を減らせます。

よくある質問

403 なのに経路は合っているように見える

プロキシを外して DIRECT だけで再現するか比較してください。再現するならトークン・権限・レート制限寄りです。外すと直るなら、出口 IP が共有レンジで制限されている可能性を疑い、別ノードや専用回線を検討します。

一部ファイルだけ極端に遅い

シャードごとにホストが分かれていることがあります。ログの SNI またはドメイン列を確認し、そのサフィックスだけルールに追加します。

Cursor からのモデル取得も同じ？

エディタ拡張やバックグラウンドツールは別ホストに向くことがあります。Cursor 向け記事と併せ、接続ログで実ホストを突き合わせてください。

チェックリスト

まとめ

2026 年も Hugging Face はモデル配布と試行のハブのままです。Clash でやることは、魔法の高速化ではなく、期待する出口にトラフィックを揃え、DNS と認証のノイズを減らすことです。ルールとログが読めれば、同じ型は他のレジストリにも転用できます。

Clash を無料ダウンロードして、快適な接続を体験する