2024–2026 年の文脈：HF Hub は「倉庫」であり API の玄関口

生成 AI ブーム以降、オープンウェイトの探索・比較・微調整の入り口として Hugging Face Hub（以下 HF Hub）は、研究・副業のプロトタイプから本番寄りのデプロイまで、検索回数の多い定番インフラに置き換わりつつあります。同じ 2024–2026 年のうちに、モデルカードの HTML は軽くても、実体は Git LFS や専用 CDN、場合によっては地域分散ストレージへ伸びる太いトラフィックであることが多く、回線揺れに加えて、プロキシの出口ノードが毎回変わると、大容量 モデルダウンロード では再開不能に見える timeout、Inference API では 502 や一瞬だけの失敗、といった症状を誘発しやすいです。

本稿の狙いは「Hugging Face 全体の高速化」ではなく、Clash の mode: rule で、Hub の閲覧・HF Hub 上の LFS 取得・Inference API 呼び出し（サーバレス推論）が一貫した出口に乗るようドメイン分流の型を示し、接続ログと DNS で検証できるようにすることです。ネットワーク利用は居住地域の法規制と Hugging Face の各種規約に従う前提であり、規制の回避を助長する意図はありません。ルール全般の考え方は ルール分流の総覧 と併読すると流れを掴みやすいです。

⚠️
法令・利用規約：プロキシの利用、モデルとデータの取り扱い、Hugging Face の Inference 機能は、居住地域の法規制および各サービス利用規約に従ってください。本記事は技術的な経路制御（Clash／Mihomo）に限った解説です。

「ブラウザは開けるが取得だけ失敗」と呼ばれやすい典型

コミュニティで語られやすいのは、（1）Web UI でモデルページは表示できるのに、git clone や huggingface-cli の download だけ遅延や中断が続く、（2）同じ推論を叩いていても、Inference エンドポイントだけ断続的に connection reset や TLS 失敗、（3）巨大ファイルの帯域は DIRECT に落ち、メタデータだけ PROXY となり再開ロジックが壊れている、（4）ノードを入れ替えた直後だけ成功率が変わる。原因は一つではありません。購読ルールの PROXY に含まれていても、上位の GEOIP や DOMAIN-KEYWORD より下で別経路に吸われている、fake-ip と実コネクションのずれ、システムプロキシ非対応の CLI が DIRECT のまま、企業回線の途中機器が長時間接続だけ切断する、などが重なります。

切り分けの第一歩は、Clash の接続ログで、実際に使われた FQDN と割り当て策略名を揃えて読むことです。Hugging Face 側のホスト名はプロダクト更新で増減しやすいため、公開リストを盲信せず、自分の手元で出たログを正にしてください。他記事との横断には ブログ一覧 も便利です。

ドメイン軸：押さえたい huggingface.co / hf.co 系の束

mode: rule のとき、最終的な MATCH や広い GEOIP より上に、何度も現れる Hub 関連ホストを専用の策略グループ（以下便宜上 AI-HF）へ流すのが基本形です。環境差は大きいものの、出現しやすいのは DOMAIN-SUFFIX,huggingface.co（本体・LFS 含む大枠）、短縮ドメインの hf.co 系、ブラウザからの モデルダウンロード やチャンク配信に絡む cdn- や cas- 接頭のサブドメイン、Inference API まわりの api-inference 等のサブドメインです（名称は移行期に揺れうるため、ログの実名で上書きしてください）。

ポイントは、DOMAIN-SUFFIX,huggingface.co 一括で HF Hub 全体を同じ出口に寄せるのが扱いやすい一方、不要な大域と混ぜないことです。例えば、社内向けの別 Git ホスティングとドメインが似通うような特殊環境でなければ、キーワードより suffix ベースの方が衝突しにくい傾向にあります。中国本土向けの GEOIP,CN,DIRECT より上に、Hub 専用の DOMAIN / DOMAIN-SUFFIX 行を置く位置取りを意識してください。ChatGPT や Google Gemini 向けに個別記事化している OpenAI 系 や Gemini 系 と主題のキーワードを被らせず、本稿は Hugging Face ドメイン束に特化した補完として読むのが明確です。

LFS 大容量転送と Inference API：形状の違い

モデルダウンロード（数十〜数百 GB 級に及ぶ例もある）のセッションは、短い REST 呼び出しの連打とは違い、TCP 長回線と再開（レジューム）の振る舞いに敏感です。出口が切り替わると、クライアントは「最初から」相当に見えたり、LFS オブジェクトの指し示す URL が一時的に別経路に落ち、帯域制御装置の閾値にだけ引っかかる、といった具合に見えがちです。

一方、Inference API（旧称に近い呼び方で語られる推論 API）や Text Generation Inference 等の周辺は、短い往復が多く、HTTP/2 や gRPC 前提の接続のまま、DNS だけが別リゾルバを向いていて SNI が噛み合わない、というパターンもゼロではありません。ドメイン分流を「巨大ファイル用」と「推論用」に物理的に分けたい場合は、まずはログ上で FQDN を分類し、行を二段にするのが先です。

TLS／SNI と CLI プロキシ

HTTPS では SNI がホスト名と揃う必要があり、ルール上は AI-HF なのに TLS 失敗だけ残る場合は、企業向け透明プロキシ、ウイルススキャン、誤った MITM 証明書を疑います。curl で同一 URL を、ブラウザと huggingface-cli の両方から試し、環境変数 HTTP(S)_PROXY が Clash のリスンポートを向いているか、別プロキシに固定されていないかを確認します。Hugging Face の Python ツール群は、多くの場合これらの環境変数を解釈するため、OS の「システムプロキシ」だけ有効にしても CLI には届かないことがあります。

rule-providers と手書きルールの併用

コミュニティの rule-providers に「AI サービス」系の大括りがあれば、初期投入は速い一方、Hugging Face 以外のホストを同じ出口に巻き込みすぎると、想定外の遠回りになります。実務では、（1）購読で大枠、（2）接続ログに出た不足 FQDN だけ rules: 冒頭に DOMAIN で足す、の二段が扱いやすいです。更新反映後、Clash 側でプロバイダの再読み込みが効いているか先に切り分けてください。

策略グループ：url-test、fallback、手動 select

安定性を優先するなら、単一の select だけに頼らず、url-test でレイテンシの良い出口を拾う、fallback で最初に通った集合へ、といった二段にすると大容量モデルダウンロードの体感が整いやすいです。課金やコンプラで国・リージョンを揃えたい場合は、上に select を置き、中身のノード候補を地理的に絞る、という形も有効です。策略名の綴りは設定ミスが付き物なので、GUI で改名したら rules: 側も同時に更新します。

ℹ️
ポイント：ルールは上から最初の一行だけが有効です。HF Hub 向けの DOMAIN / DOMAIN-SUFFIX 行は、大きな GEOIP や広い MATCH より必ず上に置いてください。

YAML 記述例（FQDN はログに合わせて置換）

以下は説明用の断片です。実際のサブドメインは、利用する機能とクライアントの挙動に合わせてください。コピペのままでは不足や過剰がありうる点に注意してください。

proxy-groups:
  - name: AI-HF
    type: url-test
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    proxies:
      - 低遅延ノード A
      - 低遅延ノード B
      - 予備ノード

rules:
  - DOMAIN-SUFFIX,huggingface.co,AI-HF
  - DOMAIN-SUFFIX,hf.co,AI-HF
  - DOMAIN-SUFFIX,amazonaws.com,AI-HF
  - GEOIP,CN,DIRECT
  - MATCH,既定の策略グループ

上段の amazonaws.com 行は、一部の LFS や Inference のバックエンドが一時的に S3 互換のホスト名を指す状況でログに出た場合の補足用に過ぎません。AWS 全般を吸い込むと別ワークロードまで巻き込みます。ログ上で本当に必要なときだけ、より限定した DOMAIN に絞るか、手書きの上書き行で対処してください。計測 URL や interval は自環境向けに調整します。

DNS・fake-ip：ルール通りなのに期待と違う経路

enhanced-mode: fake-ip 利用時、ドメインルールに合致したつもりでも、実接続のタイミングで想定外の IP へ向くことがあります。HF Hub のような、長いセッションと再試行が重なる利用では、fake-ip-filter や nameserver の階層、DoH/DoT の併用を、Fake-IP／DNS 解説 の型に倣い見直す価値があります。IPv6 有効回線では、IPv4 ベースの判定だけ取りこぼす例も出ます。

システムプロキシ、TUN、非対称アプリ

ブラウザは多くの場合システムプロキシに従いますが、Git や Python 仮想環境上の pip／huggingface-hub、コンテナ内の wget は、別経路のままです。OS 全体の TCP/UDP を Clash 側へ取り込みたい場合は TUN モードの検討枠に入ります。権限とスタックの違いは TUN 解説 を参照してください。

効果の確認手順（実測ベース）

  • 接続ログを表示した状態で、Hub 上の小さなファイル取得か推論 1 回分を実行し、想定 FQDN が AI-HF に乗ったか照合する。
  • huggingface-cli か git lfs で同一リポジトリの取得を再試行し、策略と実出口が揃うか確認する。
  • AI-HF を一時的に単一地域のノードへ固定し、タイムアウト率と平均時間の変化を比較する。
  • DNS クエリと接続先 IP の対応、fake-ip 利用時のフィルタ条件を併せて点検する。

よくあるつまずき

行を足しても挙動が変わらない

上の行に吸われている、策略名の表記揺れ、CLI だけ HTTP_PROXY が空、コンテナ内は別スタック、拡張機能がローカルバイパス、などを疑い、ログ上の「一致行」と「出口」を揃えて読んでください。

S3 行を広げたら別のクラウド作業が遅くなった

前段の YAML 断片の amazonaws.com は、必要最小限に絞るのが原則です。不要な範囲を広い DOMAIN-SUFFIX にしないでください。ログ上で実名が判明してから、補足行として足す方が安全です。

まとめ

2024–2026 年、オープンウェイトと HF Hub への集中は衰えにくい一方、大容量 LFS 取得と Inference API は、出口が揃っていないと失敗の見え方が大きく変わります。Clash では、Hugging Face 向け ドメイン分流をログ起点で前置きし、DNS／fake-ip、必要なら TLS／SNI と CLI プロキシを切り分けるのが実務的です。他ベンダーの生成系記事と組み合わせ、設定ファイル内の「サービス別チャネル」を整理すると運用しやすくなります。

クライアントの導入や更新は、まとまった ダウンロードページ から行うと、本稿の設定を追いながら検証しやすいです。

→ Clash を無料で入手し、Hugging Face 向けの出口を自環境に合わせて整える