Docker Hub の docker pull が止まる？Hub と registry mirror を Clash（mihomo）で分流する実測（2026）

1. 最初にレイヤーを分ける：コンテナ出站と daemon の pull は別問題

開発者が最初に試しがちな export HTTP_PROXY=... は、コンテナ実行時に渡れば子プロセスにも伝播しますが、docker pull を発行している主体はコンテナではなくほぼ確実に Docker デーモンです。結果としてブラウザで Hub のページだけ開けても、daemon が見ているパスとは別レイヤになる、という状態がほぼ定番になります。この前提だけ押さえると、「なぜ自分の環境だけ固まったのか」というカオス状態が観測可能なリストに落ちやすくなります。ホスト側 Clash とコンテナ出站の記事はこの差分を細かく扱っているため、セットで読むと頭のなかでの住み分けが早いです。

ほかにも、Compose のビルドや CI のジョブでは BuildKit 経由のレジストリアクセスも独立したダイアルを持ちます。本稿では主に「端末での docker pull」にフォーカしますが、問題の型は共通なので読み替えれば応用できます。なおサービス側の SLA 変更や規約変更は自分で最新情報を確認し、クラウド事業者の公式ドキュメントと照らしてご利用ください。ここに書いたのは運用上の経路モデルであり利用の是非を規定するものではありません。

2. docker pull がぶつけるアーキテクチャ経路を描く

コンテナランタイムはイメージ名を検証するときhub.docker.com のような Web の表面とは別経路へ跳びます。標準構成ではdocker.io とその背後にある registry-1.docker.io へ向けられる通信が本命で、ログにタイムスタンプだけが伸び続けるときは、この系統で SYN が返ってこない、証明書交換までに RTT が飽和する、などの兆候になります。mihomo では「どのアウトバウンドに載ったか」がMATCH へ落ちる前に適切な節にあるかが性能を決めやすく、開発者グループだけ低レイテンシノードへ寄せておくような戦略も取りやすいです。ルールルーティングの解説ページと同様の頭でリスト化してください。

もうひとつの柱はdaemon.json の mirror リストです。ここへ登録するとレジストリクライアントは公開エンドポイントを自動で差し替えます。しかし名前解決結果が GEOIP と矛盾していたり、証明書の CN／SAN と期待がズレていたりすると、表面上は加速器を使っているのに実際には別リージョンを叩いている状態が起きえます。その場合 Clash が「開発者 egress をまとめる」側に立つなら、mirror が指す apex へのルールだけを明示的に 直连（DIRECT）や国内向けグループへ固定し、それ以外は越境グループへ、といったレイヤーを足すほうがログと相性が良いことが多くあります。ノードセットの質にも依存します。

3. 規則に載せやすい「Docker Hub」「認証」「インデックス」区分

環境により多少の差はありますが、開発者フォーラムで議論になりやすいのはregistry-1.docker.io と auth.docker.io と index.docker.io周辺と、CDN 側の名前です。リストは最小に留め実際には接続ログに出ているホスト名を足していく運用が堅実です。ログを見られる UI（例：Clash Verge Rev の接続ログ）があれば、まず問題のタイムウィンドウに合わせてフィルタし、規則の穴を埋めるのが再現コスト対効果として高めです。Hugging Faceの稿と思考回路は共通で、モデルレイヤとは別インフラだけれどログの増え方は似ている、と捉えると頭に入りやすいです。

# Example placeholders -- adapt to real subscription policy names
proxies: ...

proxy-groups:
  - name: DOCKER-HUB
    type: select
    proxies:
      - NEAR-LATENCY
      - DIRECT
      - REJECT

rules:
  - DOMAIN-SUFFIX,docker.io,DOCKER-HUB
  - DOMAIN,registry-1.docker.io,DOCKER-HUB
  - DOMAIN,auth.docker.io,DOCKER-HUB
  - # add mirror apex entries explicitly when daemon.json redirects

ひとつの落とし穴はRULE-SET と手書き DOMAIN の順が逆転しているときに MATCH へばかり寄る現象です。mihomo では YAML での並び順がそのまま優先順位になるため、開発者グループだけ上に持ち上げつつ広域ブロックセットは末尾にまとめる、という整理が読みやすいです。また DOCKER-HUB グループだけ TCP のみ許可されていても、まれに QUIC を前提にしないレジストリ通信が混ざっていれば追加観察がいります。Docker と QUIC の関係は将来変わり得ますが、問題が出ている時点での実ログを単一のソースオブトゥルースにしてください。

4. registry mirror 設定とクラッシュしない分流の両立

国内向けサービス提供者が公開する加速器は、その URL を /etc/docker/daemon.json に書いた瞬間からデーモンが優先的に読み込みます。ここでの典型トラブルは「Clash が mirror の apex を越境グループへ飛ばし続けていた」ため、ユーザーは加速器をオンにしているのに実質は海外迂回が二重になり RTT が爆発していた、というパターンです。分流を整えるときは「mirror が指す名前は DIRECT／国内近傍へ」「それ以外は開発者グループ」と二段に割ると判断が単純化します。とはいえ、利用規約により商用利用可否が異なるため、自分の環境だけで評価し、許諾されていないサービスへの依存は避けてください。

ほかにも 加速器が返すコンテンツのキャッシュレイヤが古く、レイヤの digest だけが一致しないときに予期しない 404 が出て再ダウンロードが頭打ちになる例もまれにあります。これは単純な Clash の話だけでは済まなく、ログに出る HTTP コードとヘッダの WWW-Authenticate に注目してください。開発者ワークフローでは 問題のレイヤだけを削除して強制フェッチするテクニックと合わせ、レジストリとの往復ログをセットで読むほうが再現時間を短縮できます。

5. mihomo の DOMAIN系ルール例と策略グループの切り口

実運用には「安定さ優先」の海外出口を一本に固定することと、問題が出ているときのみ 自動 url-test で浮かせるグループへ切り替えることの両方が必要になります。mihomo では名前付きグループへの束ねだけで済むケースも多いですが、CI 環境ほど並列フェッチへ耐えるにはdialer-proxy や複数ポートのキュー調整など上級機能を見るほうがフェアです。とはいえ多くのローカル環境では、まず単純に DOCKER-HUB と MIRROR-CN の二グループに分離し、RULE だけで済ませるのが最初の収束点になります。自動測速と failoverの稿と組み合わせれば、開発者ワークステーションだけで済むモデルにも拡張しやすいです。

ログ観察では 「SYN が張れるが TLS が詰まる」タイプと、「そもそも SYN が張れない」タイプが混ざっていることに留意してください。この二つは上流の QoS と下流の DPI／MITM とで原因が異なり、ルールの切り替え順も変える必要があります。mihomo の Sniffer と fake-ip が噛み合わないときはDNS の比較稿を参照すると再現フェーズでの意思決定が早くなります。

6. DNS（fake-ip / redir-host）と証明書・SNI でのタイムアウト

fake-ip モードではアプリケーションが名前解決と実接続対象との対応関係が Clash に隔離されます。開発者側が dig を叩いた結果と、実際のアプリログに出ている宛先情報が異なるときは、このモードとの整合を疑ってください。また企業環境ほど中間者証明書を自動配布していて Docker 側の証明書ストアにだけ不足しているケースがあります。コンテナとは別レイヤとはいえ、CI のビルダーイメージ内でだけ失敗するとき、この筋は早めにチェックリストへ入れたほうがよいです。TLS メッセージで 証明書の SAN とリクエスト先ホストが一致しないときは、mirror と公式レジストリの両方についてホスト明示をログで追跡しましょう。

HTTP/3 や QUIC がレジストリ経路へ入り込んだ場合でも、多くのクライアントはまず TCP 側で粘るため、体感は「ログに QUIC は出ていないのに体感が変だ」となることがあります。まずクラシックなログを眺め、そのうえで Google サービス側の QUIC 関連稿と同調してブロックリストを評価するのが順当です。また TUN モードを有効にするかどうかは「デーモンが自分でバインドするソケットをどう取るか」という OS 側の質問とも絡むため、開発者 PC だけで済むときは規則中心のほうが切り分けコストが下がりがちです。

7. systemd 側で Docker がプロキシを読むときの論点

Linux での恒久対処としてdocker.service ドロップインへ Environment=HTTPS_PROXY=http://... を載せる構成もありえます。その場合においても、Clash が提供するポートはほぼ mixed-port と理解しておいたほうがトラブルシュートが単純です。systemd のユニットと GUI プロキシの二重適用になると競合することがあるため環境変数の供給元を一本化したうえで再現するのが鉄則です。mihomo ログでレジストリ宛の CONNECT が張れずに落ちる場合でも、問題は Daemon 側のダイアル制限であったり単純にノード側の転送キューであったりすることがあるため、複数ソースを並行観察してください。

Windows と macOS での Docker Desktop では、名前空間構成が異なり、WSL 越しでの観察が増えるときはWSL2 とホスト側 Clash の稿と混ぜて読むほうが往復ログの位置づけが早くなります。いずれの OS でも、デーモンが参照する名前解決器とホスト側 Clash が参照する名前解決器が一致しないと、ログの粒度が異なるだけで問題が不透明になりますので、開発者ワークフローではその差分を明示的にメモしましょう。

8. 開発者ワークフローの切り分け順（チェックリスト）

1. まずコンテナ側の環境変数と独立した daemon 側の状態を切り離しつつ問題の症状を短文で書く（例：`registry-1` へのレイヤ取得がレイヤ単位で失敗、`TLS handshake timeout`、`EOF`など）。ログの原文を残すだけでも後で差分検索が効きやすくなります。
2. mihomo の接続ログで実際のアウトバウンドやルールヒット順を確認します。自動生成ルールセットの末尾に埋没していないか、地域ブロックセットと衝突していないかも同時に見ます。
3. DNS ログで fake-ip 以外のクエリログが混ざっているか確認し、コンテナとは別名前解決器を叩いているミドルウェアがいないか洗います。必要なら一時的に redir-host へ切って比較し、復旧したかどうかをメモしてください。
4. mirror が有効なら apex だけルール単位で直結グループへ、公式レジストリへ戻すべきときはその逆の束ね変更を適用します。設定変更後は sudo systemctl restart docker まで含め再現手順が完結しているかチェックリスト化します。
5. 問題が再現しないケースだけをリスト化しておき、「成功したとき」と「失敗したとき」の差が RTT と証明書とルール順のどれかに収束しているか評価します。ここまで来ると、追加観察は openssl のハンドシェイクだけで済むようなケースも出てきます。

ワークフロー全体はMCP と npm と GitHubの稿にある「開発ツールチェーンでの越境」を補強する側面もあります。Docker はその中心に座るため、イベントが相関したときほど単一ログビューを用意しておいたほうがよいです。CI とローカルを混ぜると観察が複雑化するので、開発者ワークステーションのみに絞って最初の再現を取る運用も有効です。

9. FAQ

検索クエリにも近い質問だけに絞ります。構成はすべて一般論であり環境ごとの差異を吸収しない点にご注意ください。

ブラウザは速いのに docker pull だけできません。なにが違いますか。

ブラウザとデーモンが参照する名前空間やプロセス境界が異なり、デーモンはシェル環境変数を読みません。またレジストリは UI サイトとは異なる複数ホストへ展開されます。

国内 mirror を Clash とどう両立させますか。

mirror の apex が越境グループへ飛ばされ続けると体感が安定しません。明示的ルールだけ国内／直結へ寄せ、その他だけ越境グループへ、と二分割してください。

ログに TLS handshake timeout とだけ出ています。

RTT とルール順だけでなく、証明書と DNS の両方へ当たってください。企業環境ではデーモンだけ CA が不足していることがあります。

10. まとめ

docker pull が止まる問題は単一トリガではなくデーモン〜レジストリ〜加速器〜DNS〜TLS が積み上がっているため、コンテナ出站の環境変数だけをいじっても復旧しないことがほとんどです。mihomo ではDOCKER-HUB と mirror 先を別グループに分けログで観察することで開発者ワークフローがかなり素直になります。ルールセットの並び順を誤って MATCH に落とし続けるのも有名なので、まず自分のワークステーションだけでチェックリストの五段へ落とせるようにすると再現フェーズでの安心感が上がります。

開発者レイヤでのトラブルシュートに置いて、すべての経路が単一のアプリウィンドウに閉じる総合 VPN タイプよりも、ログと名前付き策略で追い込めるほうが工数効率が高いことが多く、ルールセットの増減と購読の更新がセットで評価しやすい点は、mihomo 系クライアントの運用上の強みになります。また GUI が古い構成や更新サイクルの遅いクライアントでは、開発者ワークフローが変わるたび設定がずれ続けログが読みづらい、という悪癖がちです。自分のワークフローに合わせてダッシュボードとログ読み込みだけは最新に保つのが安定の近道になります。→ 無料で Clash をダウンロードし、自分に合った GUI でログと規則を整えるところから着手できます。