📖 チュートリアル ⏱ 約18分で読めます

2026：Hugging Face（Hub／Spaces／Inference API）を Clash で安定利用する分流ルールと DNS（実測）

2025–2026 年もオープンウェイトモデルとGradio／Spacesのデモ需要は高く、Hugging Faceは研究者・開発者にとって欠かせないホスティングです。一方でモデルカードは開くのに LFS 取得だけ失敗する、Spaces の iframe だけ真っ白、Inference API だけタイムアウトといった症状は、単一ドメイン一行の PROXY では足りないホスト集合と、DNS（fake-ip・DoH）の取り違えとして現れやすいです。本稿はClash（多くの場合 Clash Meta／Mihomo コア）でHub・Spaces・Inference APIに現れる分流ルールの出発点と、Rule モードのログで再現する手順を日本語で整理します。ChatGPT／OpenAI 向け記事やDeepSeek 向け記事が扱う別ベンダーのホスト集合と混ぜず、HF エコシステム固有のドメイン分岐に焦点を当てます。CDN やエッジは更新で変わり得るため、以下の YAML は出発点の例とし、自分の環境の接続ログを正としてください。

なぜ「生成 AI 向けの汎用ルール」をそのまま流用しにくいか

Hugging Faceは、モデル Hub（huggingface.co 本体と短縮の hf.co）、Spaces（多くの場合 *.hf.space のような別ゾーンの FQDN）、Inference API（ドキュメントに記載の api-inference.huggingface.co など推論専用ホスト）、大容量ファイル用の Git LFS やCDN系サブドメインが同時に絡みます。ブラウザの UIは通るのにコマンドラインの huggingface-cliやPython SDKだけ別経路になる、Spaces の静的アセットだけ意図せず DIRECT に落ちる、といった切り分けが典型です。Clash の観点では「どのホストがどのポリシーにマッチしたか」「広い RULE-SET に先に飲まれていないか」「CLI がシステムプロキシを読まずに別出口へ出ていないか」が分岐点になります。チュートリアルでモードの前提を押さえたうえで、カスタムルールの書き方と併読すると、HF 向けの例外を上に積む判断がしやすくなります。

すでに公開している Claude 向け記事やNotion AI 向け記事は、SaaS 型の別ドメイン集合を扱っています。本稿はオープン模型ホスティングに絞り、Hub／Spaces／Inference APIの安定アクセスと、DNSまわりの切り分けを重ねます。

Hugging Face が扱うホストのイメージ（Hub・Spaces・推論・LFS）

モデルやデータセットの閲覧・検索では huggingface.co が中心になりやすく、短縮リンクやリダイレクトで hf.co が現れることもあります。Spaces（Gradio 等）は、公開 URL が huggingface.co/spaces/... に見えても、実際の読み込みで別サブドメインやCDN、埋め込み用の追加ホストが混ざることがあります。Inference APIはドキュメント記載のエンドポイント（例：api-inference.huggingface.co）がWeb UI とは別 FQDNになるのがポイントで、スクリプトから叩くとブラウザだけ通る状況が起きやすいです。さらに Git LFS や大容量配信向けのホストはインフラ側の変更で増減し得るため、検索で見つかるドメイン一覧は参考にとどめ、自分のログに出たホスト名を正としてルールを育てるのが長く使うコツです。

HTTPS の SNI と実ホストの取り違えで挙動がおかしいときは、Clash Meta の sniffing と DNS の切り分けも併せて確認すると原因が絞りやすいです。

分流の土台：proxy-groups に「Hugging Face 用」を置く

購読テンプレの汎用 PROXY を直接指すより、HFProxy のような用途名のグループを select または url-test で用意し、rules からは常にその名前を参照するのが運用しやすいです。Hub の閲覧と Inference API を同じ出口に揃えるか、レイテンシや課金ゾーンの都合でAPI だけ別グループにするかも、グループ名を分けておけば後から差し替えが容易です。ネストや型の詳細は proxy-groups のガイド を参照してください。

💡 ヒント テンプレのグループ名と rules 内の綴りが一致しているかを最初に確認してください。ここがずれると「ルールを足したのに効かない」状態になりがちです。

ドメインルールの出発点（YAML 例）

方針として、(A) Hub・短縮ドメイン・Spaces 用サフィックス・Inference API を同じ HFProxy に寄せるのがシンプル、(B) 社内ポリシーで特定ゾーンだけ直結にしたい場合は、GEOIP や広い RULE-SET との衝突をログで確認しながら例外を上に積む、が現実的です。(C) DOMAIN-SUFFIX,com のような広すぎる一括は他サービスへ波及しやすいので避け、huggingface.co・hf.co・hf.space などログで確認したサフィックスに絞るのが無難です。推論 API のホスト名は公式ドキュメントの最新表記を優先し、本稿の例は出発点として扱ってください。ルールの上から先にマッチした行が優先されることは カスタムルール記事 のとおりです。コミュニティの RULE-SET と併用する場合も、HF 向けの例外を上に積むと意図した出口に寄せやすくなります。

rules:
  # Examples only — tune group name (HFProxy) and domains to your logs/docs
  - DOMAIN-SUFFIX,huggingface.co,HFProxy
  - DOMAIN-SUFFIX,hf.co,HFProxy
  - DOMAIN-SUFFIX,hf.space,HFProxy
  - DOMAIN,api-inference.huggingface.co,HFProxy

ブラウザ、huggingface-cli、transformers／huggingface_hub からの取得、CI ランナーは、参照するホスト名が UI と一致しないことが多く、本稿のリストとは必ずしも一致しません。LFS やデータ転送で別ドメインが出た場合は、接続ログに出た FQDN をそのまま DOMAIN や DOMAIN-SUFFIX で追加してください。画像や WASM、埋め込みリソースの読み込みに別ドメインが混ざる場合も、ログに出た名前を足すたびに、安定アクセスの再現性が高まります。

DNS と fake-ip：ルールより前に潰れる「名前解決」

分流ルールが正しくても、DNS が期待と違う応答を返すと、タイムアウトや証明書エラー、大ファイル取得の中断に見えます。Clash／Mihomo 系では dns ブロックの fake-ip、redir-host、DoH の有無が挙動に直結します。テンプレの推奨設定から大きく外すと切り分けが難しくなることもあるため、まずは購読既定で再現する→ 問題が続くときに、(1) DoH エンドポイントの信頼性とレイテンシ、(2) nameserver-policy で huggingface.co や推論用ホストだけ別 DNS に寄せる、(3) IPv6 の有無と OS の解決順、を一度に一項目ずつ変えるのが安全です。

ブラウザ独自の Secure DNS（DoH）と Clash 側の DNS が二重に効いていると挙動が読みにくいので、比較時にはブラウザ側を一時オフにする方法もあります。ターミナルやコンテナから API を叩く場合、システムプロキシを読まない経路があるとルールが効きません。そのときは TUN モード でトラフィックをコア側に寄せる案や、HTTPS_PROXY 環境変数の明示を検討してください。ルールの優先順位は、より具体的な DOMAIN を汎用の MATCH や広い RULE-SET より上に置く、という原則が API や長時間接続の取りこぼし防止に効きます。

動作モード：Rule・Global・Direct の使い分け

Rule が日常運用の基本です。Global は「すべてをプロキシへ」として、一時的にルール不足かノード品質かを切り分けるのに便利ですが、国内サイトまで遠回りになるため常時利用はおすすめしません。Direct はベースライン計測用に、Clash を事実上オフに近い状態で挙動を見るときに使います。Hub は開くが Spaces だけ不調なときは Rule に戻し、該当ホストが意図したポリシーにマッチしているかをログで確認するのが定石です。トンネル型 VPN との違いは Clash と VPN の比較 も参照してください。

⚠️ 注意 Inference API のトークンや、プライベートモデルへのアクセス権はクライアント設定に平文で残りやすいです。リポジトリにコミットしない・共有端末では権限を絞る、などセキュリティ面はプロキシ設定とは独立して必ず確認してください。

段階実測：ログで「宛先」と「採用ルール」を確認する

  1. 1

    Baseline（Direct または Clash 停止）

    まず Direct でブラウザから Hub を開き、同じ端末から curl 等で推論エンドポイントへの疎通を試し、症状が再現するかを記録します。これで「ローカル回線やプロバイダ側」の要因も見えます。

  2. 2

    Rule に戻し、Hub・Spaces・API それぞれでログを読む

    モデルカード閲覧、Spaces の実行、Inference API の呼び出し、huggingface-cli download などについて、接続一覧／コアログで向いているドメインとマッチしたルール行（またはポリシー名）をメモします。リストにないホストが出たら、それが次に追加すべき行です。

  3. 3

    一行ずつルールを足して再計測

    DOMAIN-SUFFIX を追加し、同じ操作を繰り返します。一度に大量変更すると効いた変更が特定できません。意図と違う行にマッチしているときは、より具体的なルールを上へ移動します。

  4. 4

    DNS ログがあれば併記する

    名前解決結果がおかしい場合はルールより先に DNS を直します。クライアントが DNS ログを出せない場合は、ログレベルを上げる、別ツールで確認するなど環境に合わせてください。

この繰り返しが本稿でいう「実測」です。検索で見つかるドメイン一覧は参考にとどめ、自分のログを正としてメンテすると、CDN やエンドポイント変更にも追従しやすくなります。企業ネットや地域によっては特定ドメインへの到達性が制約される場合でも、出口の品質・DNS・ルールの三つを同時に疑うと早く収束しやすいです。

よくある質問

ブラウザは快適なのに CLI のダウンロードだけ失敗する

ブラウザはシステムプロキシ経由でルールが効いているが、ターミナルがプロキシ設定を読んでいないパターンです。環境変数、TUN、または実行ユーザの違いを確認してください。

Spaces だけ読み込みが遅い・タイムアウトする

埋め込みや静的アセット用のホストが別ドメインに分かれ、意図せず DIRECT や遅いノードに落ちている可能性があります。ログに出たホストを追加し、該当行を上に移動して再確認してください。ノード側のタイムアウトも疑ってください。

職場・学校のネットワークでは？

組織ポリシーでプロキシ迂回が禁止されている場合があります。技術的に可能でも、規程と管理者の指示を優先してください。

まとめ

Hugging FaceのHub・Spaces・Inference APIをClashで安定アクセスしたい場合は、openai.com や anthropic.com 向けに整理した分流ルールだけでは取りこぼしが出やすく、huggingface.co 系・hf.space・推論用ホスト・LFS／CDNに現れるホストを、ログで拾い上げてドメイン分流に落とし込むのが実務的です。本稿の例は出発点であり、ログに基づきルールを育てることが長く使うコツです。チャット中心の整理は ChatGPT の記事、オープン模型の Web／API 分岐の別例は DeepSeek の記事で扱っているため、混同せず参照してください。

クライアントの入手は 本サイトのダウンロードページ を第一にすると、記事との対応も追いやすくなります。オープンソースの参照や Issue の確認は GitHub 等でも可能ですが、インストーラの主導線は本サイトのダウンロードページに寄せるのが、他の AI 向け記事とも揃った使い方です。ルールの基礎を固めたい場合は カスタムルール完全ガイド も併せてどうぞ。用途ごとに出口を切り替えられる点では、端末全体を常時トンネルする汎用 VPN に比べ、Clash の運用体験が一段整理されやすい場面が多いです。

→ Clash を無料ダウンロードし、Hugging Face 向けの分流と DNS を試す