タイムアウトの見え方：HF「だけ」プロキシしていないか

Ollama で ollama pull や初回モデル選択時の自動取得が、途中で進まなくなる、ログに読みにくい タイムアウト が出続ける、転送開始までに異常な待ち時間がある——という相談は、2026 年現在も「Hugging Face とローカル 大モデル」という組み合わせで検索されやすいテーマです。原因が単純な帯域不足だけでないとき、ひとつの観点として押さえるべきなのが、huggingface.co と実際にバイトストリームを運ぶホストとの関係です。

モデルページをブラウザで開ける状態でも、実行時ダウンロードは複数ステップになります。モデル一覧／メタ情報、リポジトリのマニフェスト、重いウェイト一式（しばしば LFS やオブジェクトストア）、さらには地理的／負荷状況に応じて切り替わる CDN エンドポイント——といった具合にホストが分かれやすく、ひとつのサブスクの巨大ルールセットでは取りこぼしがあり得ます。その結果、huggingface の UI 側は問題なく見えているのに、Ollama だけ転送フェーズが固まって見える、というズレが起きます。

Clash / mihomo における分流は、この「開発者ツールでもネットワーク列に出てくるドメインの束」を意識した上でモデルダウンロード経路だけを別出口へまとめるのに向いています。たとえば サービス本体と CDN を分けていたら不安定になりやすい、というサイト別記事でも述べているのと同型で、コンテンツごとに「必ずセットで同一グループへ乗せるほうがよい」ドメイン群を決めることが重要になります。

検索インテントとのズレを避ける：Web の AI サイト分流とは別問題

当ブログでは、ChatGPT や Gemini などブラウザ向け生成 AI を専門グループへ分けるサイト分流記事もありますが、その多くは streaming やイベント送信のような HTTP レイヤーの最適化が主眼です。一方、モデルダウンロードは長時間の TCP、TLS、場合によっては QUIC、さらにはオブジェクト配信のようなアーティファクト取得に近く、評価の焦点はブラウザのタブ単位よりホスト単位とデーモン環境に寄ります。

したがって本稿では、生成 AI の Web サイト向けとは別線で、「どの名前解決とどの送信元プロセスが、どのルールへヒットしたか」をログで確認し、CDN の取りこぼしがないようにするという実務寄りの切り口に絞って説明します（2026 年時点の検索クエリとも整合させています）。ルールセットの基本概念は YAML とルール分流の解説と併読すると、どこにルールを挿すべきかの感覚が掴みやすくなります。

デーモンと環境変数：ブラウザのプロキシがそのまま効かないことがある

Ollama は多くの環境では常駐デーモンとして動き、システムブラウザのプロキシ設定や拡張の挙動と一致しないことがあります。典型として、シェルの HTTP_PROXY／HTTPS_PROXY がユーザーのログインセッションにだけ存在し、launchd／systemd サービス側には伝わっていない、といったギャップです。結果として、huggingface に関する名前解決はローカルの DNS と Clash が別経路だったり、アプリだけ直結だったりすることがあります。

運用上は次のような整理が安全です。TUN モードかつ適切な OS キャプチャがある構成なら、アプリ側にプロキシ環境変数を足さなくてもトラフィックがコアのルールに乗るケースがあります。逆に環境変数だけを濃くして、ブラウザ用のポートと競合していたり二重適用になると遅くなるので、検証フェーズでは「どちらを主経路とするか」を一本に絞ってから速度比較するのがよいです。DNS の細部や Fake-IP の注意点は Fake-IP／DNS の解説で設計全体を確認してください。

モデル pull で押さえるドメイン束（環境により追加）

バージョンやリージョン、利用するミラー構成によって増減しますが、huggingface に関する代表的なホストとしては huggingface.co、*.huggingface.co、短縮運用での hf.co、モデル一覧 API などのサブパスがあるホスト、重いオブジェクト配信に関わる cdn-lfs.huggingface.co や CloudFront 系のエンドポイント名、場合によっては cas-bridge.xethub.huggingface.co といった名前がログに現れることがあります。どれが実際にヒットしたかでルールへの追加項目が決まるため、事前の完全な列挙より自分の環境でのヒットセットを優先します。

ヒント

ログに別ドメインが出てきたら、その都度HF_MODEL（後述）と同じグループへ足すのが早道です。巨大なサードパーティ RULE-SET を信頼する場合でも、自前の例外を上書き側に置いてしまって意図と逆転しないよう、ルール順序を常に頭に入れておいてください。

コンテナや ghcr.io が絡むときはレジ分流の記事と併読

ローカルの検証環境によっては、モデル単体ではなく公式コンテナ経由でアーティファクトを取得する構成もあり、その場合レジストリ側の問題が優先することがあります。GitHub Container Registry の ghcr.io と Docker Hub が混在するときの考え方は、コンテナレジストリ分流の記事が近いので、ログ上で詰まっているホストが hf 側かレジ側かを先に分けると調査が楽になります。

proxy-groups と YAML 概念例（コピペ前に自分のセットに差し替え）

日常のブラウジンググループとは別に、レイテンシと切断が少ない出口だけを並べた HF_MODEL のような select を切る運用だと試行錯誤が速いです。自動選択する url-test を使うなら、短い計測用 URL を選ぶのではなく実際の転送とも矛盾しにくいエンドポイントを検討してください。

# Concept only — replace RULE-SET names/suffixes based on YOUR real log hits.
proxy-groups:
  - name: HF_MODEL
    type: select
    proxies:
      - node-stable
      - node-backup
      - DIRECT

rules:
  - DOMAIN-SUFFIX,huggingface.co,HF_MODEL
  - DOMAIN-SUFFIX,hf.co,HF_MODEL
  - DOMAIN-KEYWORD,cloudfront.net,HF_MODEL   # Appears in some CDN paths — verify logs
  # Add other CDN/LFS hosts you actually see in connection logs BEFORE broad MATCH...
  - MATCH,PROXY
注意

DOMAIN-KEYWORD は広すぎると関係ないサービスまで同じグループへ流れるため、本番プロファイルでの濫用は避け、ログで実名が確認できてから_suffix や細かい列挙に寄せてください。また利用規約・輸出管理・会社の情報セキュリティ方針は環境により異なり、本稿はネットワーク設計の一般論であり特定のモデル／ノード／プロバイダの利用を勧めるものではありません。

広い社内向けサフィックスやプライベートレジストリを常に優先させたいときは、このブロックより上に DOMAIN-SUFFIX,corp.example,DIRECT のような明示規則を置くほうが事故が少ないです。コンテナ開発で Git／npm と混線しやすい Windows ワークステーション構成は Git と npm の mixed-port 設定なども参照し、開発トラフィック全体の経路設計と矛盾がないかを確認してください。

検証チェックリスト

  1. 名前解決：huggingface.co と重い転送側の両方で Fake-IP やCDN向け名前解決の食い違いが無いか、dig／クライアントの名前解決ログで確認します。
  2. ヒットグループ：転送フェーズで使われている各ホストが、意図した 分流グループへ落ちているか、接続ログで追います。
  3. 二重経路：環境変数と TUN の二重適用で遅くなっていないか、アプリ側のプロキシをいったん外して単独で比較します。
  4. 並行トラフィック：家庭内の別端末による帯域占有や QoS と混同しないよう、単一機・単一モデルでの再試行も取ります。
  5. レジ側：詰まっているのがコンテナレイヤーだけなら、ghcr.io などへの別グループが必要になり得ます。レジストリ分流に切り替えます。

よくある質問

ブラウザでは開けるのに Ollama だけ失敗する

ブラウザのプロキシ／拡張とデーモンのモデルダウンロード経路が一致していない、メタ情報と実体のCDN の出口が食い違っている、暗黙のリージョン制限がオブジェクト配信側にだけかかっている、などが典型です。まずはログで実ホスト名を洗い出し、同じプロキシグループへ揃えるのが再現性の高い第一歩です。

ghcr.io の話題が出てきたら

コンテナを介して取得するフローでは ghcr.io が支配的になることがあり、その場合は Hugging Face 固有の話より先にレジストリ向けのルールを足すほうが早いです。レジストリと hf を混ぜて一つの巨大キーワードルールに押し込むより、用途別にグループを分けたほうが後からのメンテナンスが楽になります。

まとめ

Ollama から Hugging Face へアクセスしてローカル大モデルを取り込むワークフローでは、メタ情報とCDN／LFS 周辺が別ホストになりやすく、ブラウザと実行時でタイムアウトの出方が違うことがあります。Clash では分流により huggingface 系をまとめて安定出口へ流し、ログで取りこぼしを潰すアプローチが実務的です。

一方で、ブラウザ向けの生成 AI サイト設定だけを流用し、デーモン経路やコンテナ経路を見落とすと改善が頭打ちになりがちです。GUI ベースのクライアントに寄せる場合も、最終的にどの行のルールを動かしたか説明できる状態にしておくと、サブスク更新後の不具合に強くなります。グローバルにすべてを同じノードへ寄せるツールは手早い反面、社内ドメインやミラー、レジストリまで巻き込んで遅くしたり壊したりしやすく、用途別のプロキシグループと順序づけが効きます。手元の検証をすぐ始めたい場合は、Clash のダウンロードページから OS に合うクライアントを選び、上記チェックリストに沿ってログを追ってみてください。オープンソースのリポジトリは動作理解に有用ですが、配布は公式チャネルを優先するとコアと UI の対応が追いやすいです。→ 無料で Clash をダウンロードし、Ollama×Hugging Face の経路を整理する