ローカル LLM と Ollama：pulling manifest が目に留まりやすい理由

2026 年も、端末や社内サーバで ローカル LLM を動かす選択肢として Ollama を採用する開発者・研究者は増え続けています。ollama pull を実行すると、ターミナルには pulling manifest という段階表示が先に現れ、ここでしばしば「ずっと同じ行のまま」に見える、という相談が出ます。体感としては「モデルの本体ダウンロード」より前の段階なので不安が大きい一方、実際にはレジストリと HTTPS、続くレイヤやオブジェクトの取得が別ホストに分かれやすく、片方だけ出口や DNS がずれているとタイムアウトに見えることが少なくありません。

本稿は、ブラウザでページを開く用途とは異なり、CLI デーモンが叩く registry と CDN／ストレージを対象にします。Hugging Face の LFS 取得やnpm のメタデータと tarball CDNの記事と同じく、「メタは通るのに別経路だけ詰まる」構図の切り分けですが、ここでは Ollama の既定レジストリ registry.ollama.ai と、その後にログへ出るホストを明示的に分流する設計に焦点を当てます。ルールの型そのものはルール分岐の詳解と共通です。

なぜ「pulling manifest」で止まって見えるのか

マニフェスト取得は、モデル名とタグに対応するディレクトリ構造やレイヤの参照一覧を返す小さめのレスポンスです。ただしその最初の TLS 接続が不安定だと、以降のレイヤ転送に進む前に時間がかかったり、CLI では同じ行のまま長く見えたりします。典型的な要因は次のとおりです。

出口の相性：レジストリへの HTTPS は「数値の遅延テスト」ではそこそこ良くても、企業 FW や中間機器で長セッションが切られると EOF や i/o timeout に見える
DNS の食い違い：Fake-IP と直叩きのシステム解決が混在し、ルールで期待した出口と実接続がずれる（同名に見えて実 IP が別エッジ）
ルール順：具体的な DOMAIN-SUFFIX より先に GEOIP や巨大な RULE-SET が当たり、意図しないノードへ落ちる
ミラー設定：コミュニティや社内で用意された ミラーへ向き先を変えた場合、ホスト名が公式と完全に一致せず、用意した行が効いていない

コンテナから Ollama を動かす場合は、ホスト側のプロキシ環境変数と、ブリッジ越しの名前解決の差も出やすいです。Docker Desktop と Clash の併用を参照し、デーモンやコンテナの参照先を揃えてください。

注意：レジストリのエンドポイントや下流のストレージ構成は変更され得ます。本稿のドメイン例は出発点であり、詰まっている環境では必ず 接続ログの実ホスト名を確認し、利用規約・法令・社内ポリシーに従ってください。ミラー利用は信頼できるソースのみを選び、改ざんリスクを理解したうえで運用してください。

切り出し用：Ollama が叩きやすいホストの出発点

実務では次の DOMAIN-SUFFIX を最初のブロックとして足し、不足はログで補います。

公式レジストリ：registry.ollama.ai（ollama pull のマニフェスト取得など、API ドキュメントでも既定のレジストリとして扱われる名前）
ブランド・Web：ollama.com（ドキュメントや配布ページを開くとき。CLI の律速とは別経路になり得るが、混線を避けるなら同じグループに載せる選択肢もある）
レイヤ・オブジェクト：マニフェスト返却後にログへ現れる別 FQDN が律速になることが多い。親の DOMAIN-SUFFIX で覆える場合もあれば、ストレージ専用名が出るなら DOMAIN 行で補強する

DOMAIN-KEYWORD,ollama のように広げすぎると、意図しないサブサービスまで同じ出口へ寄る恐れがあるため、まずは registry.ollama.ai とログで確認できた実名から始めるのが安全です。Docker Hub（docker.io）や別のコンテナ registry を同時に使うワークフローでは、ホストが混線しないよう行を分けます。

ミラー・別レジストリを使うときの分流

地域や回線事情で ミラーや自前の registry に向き先を変える運用では、実際に解決される FQDN が公式と異なります。環境変数や設定ファイルでエンドポイントを差し替えたら、そのホストに対応する DOMAIN-SUFFIX か DOMAIN を OLLAMA 用グループへ必ず追加してください。ミラー側が Cloudflare 等の前段を挟むと、一過性の障害で manifest だけ失敗する報告もあります——この場合も「ルールが無い」より接続の実体を確認するのが早いです。

`OLLAMA_PULL` のような専用プロキシグループを分ける理由

購読ルールが「海外サイトをまとめて一つの select」だと、軽い HTTPS と大容量レイヤ転送が同じ出口に載り、前者のレイテンシだけ良いノードを選んでしまい、後者だけ不安定に見える、というズレが起きます。OLLAMA_PULL など名前のついた独立プロキシグループを用意し、registry.ollama.ai およびログで判明したストレージ系ホストだけをそこへ流すと、(1) 長時間転送に強いノードへ寄せやすい、(2) 失敗時に「どのホストがどの出口か」追いやすい、(3) ブラウザ用ノードと帯域競合しにくい、という利点があります。

評価順：Ollama 行をどこに置くか

Clash 系の rules: は上から順に評価され、最初の一致で打ち切られます。Hub 向けの行をファイル末尾に追記したつもりが、上段の GEOIP に先に飲み込まれている——というのは定番です。registry.ollama.ai を含む明示的な DOMAIN-SUFFIX は、大雑把な締めより上へ。外部 RULE-SET を大量に読み込んでいる場合は、追記位置を目視で確認してください。共通の考え方はルール分岐の詳解と同じです。

YAML の骨格例（概念サンプル）

キー名やインデントは利用中のコア・GUI に合わせてください。ここでは OLLAMA_PULL を用意し、レジストリ本体を先に載せるイメージだけ示します。

proxy-groups:
  - name: OLLAMA_PULL
    type: select
    proxies:
      - 🇺🇸 長接続・高帯域向け
      - 🇯🇵 安定
      - 🌐 自動選択

rules:
  - DOMAIN-SUFFIX,registry.ollama.ai,OLLAMA_PULL
  - DOMAIN-SUFFIX,ollama.com,OLLAMA_PULL

このあとに社内ドメインや国内 GEOIP、最後に MATCH などを続けます。ollama pull 実行中にログへ出た別ホストがあれば、このブロック付近へ追記してください。

実測の短い手順（そのまま試せる順序）

ollama pull モデル名 を再現し、Clash の接続一覧で registry.ollama.ai とその直後に増える接続先をメモする。CLI なので TUN やシステムプロキシの届き方をTUN ガイドに照らす。
メモした各 FQDN が OLLAMA_PULL（または同等）にマッチしているか確認する。一つでも漏れると manifest の前後で別出口になり、滞留に見えやすい。
同一プロファイルのまま出口ノードやプロトコルを変え、同じモデルで再試行しタイムアウトの再現性を比較する。
改善しない場合は名前解決を疑い、OS の Secure DNS・別 VPN・企業 PAC と Clash の DNS 設定の食い違いを整理する。

クライアントと環境変数の観測ポイント

Ollama はバックグラウンドのデーモンとして動き、ollama CLI はローカルの API に依頼します。プロキシを「ブラウザだけ」にしていると、デーモンの外向きが取りこぼされることがあります。HTTP_PROXY／HTTPS_PROXY をデーモンに渡す構成と、TUN でプロセス全体を透過する構成では挙動が変わるため、どちらか一方に寄せたうえで再現テストしてください。複数のネットワークプロファイル（職場／自宅）を切り替える運用では、DNS キャッシュを含めて一回リセットしてから ollama pull をやり直すと切り分けが早いです。

DNS・TLS：遅延に見える別要因

ルールはドメイン行と IP 行が混在します。DNS が Clash の想定とずれていると、YAML は正しそうでも実接続は別経路です。DNS 周りの別記事と合わせ、Fake-IP と実 IP の対応、ブラウザだけ別 DNS を使っているパターンを確認してください。長い TLS ハンドシェイクの再試行は、CLI 上では単なる「manifest の滞留」に見えることがあります。

よくある質問

pulling manifest だけが異常に長い

レジストリへの接続が律速なのか、実はその直後のレイヤ要求まで含めて別ホストで失敗しているのかを、接続ログの時系列で見分けます。マニフェスト JSON 自体は小さくても、その取得 TLS が不通なら先に進みません。

ミラーにしたのに改善しない

向き先を変えたことで FQDN が変わっているのに、古い registry.ollama.ai 行だけを信じていないか確認してください。またミラー自体の可用性や証明書エラーで失敗している場合は、プロキシ以前の問題です。

Docker イメージと混同した

docker pull は docker.io 等を主に叩きます。Ollama のモデル取得とはホストが別です。同じターミナルから両方を使う場合は、docker.io 向けの行と registry.ollama.ai 向けの行を分け、ログで取り違えないようにしてください。

検証チェックリスト（追記）

ollama pull 実行中に、Clash の接続ログでホスト名とプロキシ名をメモする
該当ホストが OLLAMA_PULL に載っているか、より上のルールに飲まれていないか確認する
ノードを変えて再試行し、切断・タイムアウトの再現性が変わるか比較する
CLI のみ失敗するときは、TUN・環境変数・コンテナのネットワークモードを揃えて再試行する

Tip：企業環境で プロキシ認証が必須の場合、Clash 出口と直接 CONNECT の混在に注意してください。認証が通らない経路だと TLS の途中で止まり、manifest 取得に見えることがあります。

まとめ

2026 年の開発フローでは、Ollama によるローカル LLM が定番化し、ollama pull のpulling manifest で立ち往生したように見える相談も増えています。原因を単一ノードの ping に求めず、registry.ollama.ai を含むレジストリ経路と、その後に現れるストレージ／CDNを分流し、評価順とDNS・TUNをセットで整えると、改善が体感しやすくなります。大容量のモデル取得全般では Hugging Face の LFS 記事とも俯瞰が重なります。

一方で、汎用 VPN や単一トンネルだけに頼ると、CLI デーモンがプロキシを拾わない・ルール順で想定外の出口へ落ちる、といった抜けが残り、同じ手順を繰り返しても再現性が出にくいことがあります。Clash 公式サイト は Clash／Mihomo 系の設定を、用途ごとにドメイン単位で制御しやすい形にまとめており、本稿のような registry と実体取得の切り分けとも相性が良いです。細かいホストをログで足し引きしながら進められるため、試行錯誤の手戻りも抑えやすいでしょう。ローカル推論環境を整えたい場合は、Clash 公式サイトを無料ダウンロードして、いまのプロファイルに Ollama 向け行を足してみてください。数分で export や購読の更新と合わせて検証を回せます。