症状の整理：レイヤの取得だけ異常に遅い

docker pull や Kubernetes のイメージ取得で、レイヤのダウンロードが途中で止まる、TLS ハンドシェイクまで進まない、レート制限らしきエラーが続く——といった症状は、2026 年現在も開発者向けフォーラムや CI のログに頻出します。ブラウザでは別のサイトが普通に開けるのに、コンテナだけ失敗する場合、原因は「プロキシをオンにしている／いない」より前に、どのホスト名の通信がどの経路に乗っているかの整理が必要になります。

イメージ取得は単一の docker.io という文字列で完結しません。マニフェストと実体の配信、認証、リダイレクト先の CDN など、複数のサブドメインや別ドメインにまたがるのが普通です。Clash / mihomo における分流ルールは、こうしたホスト単位で出口を分け、開発者プロキシとして「公開レジストリだけ別ノード」「社内レジストリは常に直結」といった方針を実装するための仕組みです。

グローバル代理だけに頼ると起きやすいこと

すべてのトラフィックをひとつのプロキシグループへ寄せると、設定は単純に見えますが、次のような副作用が出やすくなります。第一に、社内や VPC 内のプライベートレジストリまで遠回りし、逆に遅くなるか、経路要件を満たさず失敗するケースです。第二に、利用しているミラー（大学・クラウド事業者・社内キャッシュ）が「国内や同一リージョンで直結したほうが速い」にもかかわらず、海外出口に乗って遅延が増えることです。第三に、CI ランナーやビルドサーバではデーモンのプロキシ環境変数と、ワークステーションのブラウザ設定が別物になり、同じ YAML でも挙動がズレることです。

したがって実務では、公開の Docker Hub・GitHub Container Registry（GHCR）・Google の gcr.io／k8s.gcr.io 系・Quay などをレジストリ用グループへまとめ、社内サフィックスや RFC1918 向けは広い DIRECT より上に明示的に置く、という二段構えが効きやすいです。

まず押さえるドメインの束（例）

環境やイメージによって増減しますが、代表的には次のようなホストがイメージ取得に関わります。docker.io、registry-1.docker.io、*.docker.io、認証やレート制限まわりで auth.docker.io、GitHub なら ghcr.io、Google コンテナレジストリなら gcr.io、*.gcr.io、Red Hat 系なら quay.io などです。ルールは DOMAIN-SUFFIX でまとめるか、信頼できる RULE-SET を購読し、自前の例外を上書きされる位置に置かないようにします。

記法の基礎と優先順位の感覚は、YAML・ルール分流の解説記事と併読すると、どのブロックを触ればよいかが掴みやすくなります。DNS の挙動全般は、ドキュメントの Fake-IP／DNS 解説で補完できます。

レジストリ専用の proxy-groups を切る

日常のブラウジング用とは別に、REGISTRY のような名前の select 型グループを用意し、レイテンシと帯域が安定しているノードだけを候補に入れると運用が楽です。url-test で自動選択する場合も、計測 URL は実在する HTTPS エンドポイントを選び、イメージ取得の長時間転送と矛盾しないよう tolerance に余裕を持たせます。

# Concept only — replace RULE-SET names/URLs with ones you trust and maintain.
proxy-groups:
  - name: REGISTRY
    type: select
    proxies:
      - node-stable
      - node-backup
      - DIRECT

rules:
  - DOMAIN-SUFFIX,docker.io,REGISTRY
  - DOMAIN-SUFFIX,docker.com,REGISTRY
  - DOMAIN-SUFFIX,ghcr.io,REGISTRY
  - DOMAIN-SUFFIX,gcr.io,REGISTRY
  - DOMAIN-SUFFIX,quay.io,REGISTRY
  # Put private registry / RFC1918 / GEOIP-cn BEFORE broad MATCH ...
  - MATCH,PROXY
ヒント

社内ドメインやステージング用レジストリは、サブスクリプションの巨大ルールセットより必ず上に DOMAIN-SUFFIX,registry.corp.example,DIRECT のように置いておくと、意図せず REGISTRY グループへ流れる事故を防げます。

Docker デーモンのプロキシと TUN の違い

Linux では dockerd が HTTP_PROXY／HTTPS_PROXY を参照する一方、クライアント側のシェルだけプロキシを設定してもデーモンに届かない、という切り分けがよくあります。systemd でユニット環境変数を渡す、/etc/systemd/system/docker.service.d/ にドロップインを置く、など OS ごとの手順は公式ドキュメントに従ってください。

Clash をTUN モードで動かし、OS のデフォルトゲートウェイ側のトラフィックをコアが捕捉する構成では、デーモンがプロキシ環境変数なしでもレジストリ向け TCP がコアのルールに乗ることがあります。逆に、プロキシ環境変数だけ設定して Clash のルールと二重に経路がかかると、遅延や認証エラーの原因になるため、どちらを主に使うかを一本化するのが安全です。Linux デスクトップでの常駐構成は、systemd 同梱の導入記事も参照してください。

containerd・Kubernetes 利用時の注意

コンテナランタイムが containerd の場合も、名前解決と実接続の経路はイメージ取得全体に影響します。ノード上の kubelet／CRI が参照する設定は Docker Desktop の GUI とは別物なので、「手元の Mac では pull できるのにクラスタだけ失敗する」といった差は、レジストリ認証（imagePullSecrets）とあわせ、ノード側の出口ポリシーを疑うと早いです。

AI サイト分流記事との違い

当ブログでは、生成 AI の Web を専用グループへ分ける記事を別途公開しています。骨格は同じく「特定カテゴリのドメインを専用 proxy-groups へ」ですが、コンテナレジストリではレイヤ転送の帯域・長時間接続・認証ホストの取りこぼしがボトルネックになりやすく、検証の焦点はブラウザの SSE よりもデーモンとランタイムの経路に寄ります。併せて読む場合は、AI サイト分流の記事を参照してください。

切り分けチェックリスト

  1. ルールヒット：ログで registry-1.docker.io 等が意図したグループに落ちているか確認する。
  2. 社内レジの位置：広い MATCH や海外向けプロキシより上に、社内サフィックスの DIRECT があるか。
  3. DNS：Fake-IP と nameserver-policy の組み合わせで、名前解決と実 TLS 接続のリージョンが食い違っていないか。Fake-IP 解説と整合させる。
  4. デーモン環境変数：systemd 経由のプロキシと TUN の二重適用になっていないか。
  5. ミラー設定：registry-mirrors を使う場合、ミラーのドメインもルールで直結または意図した出口へ揃えているか。
注意

利用規約・レート制限・輸出規制・社内セキュリティポリシーは環境ごとに異なります。本稿はネットワーク設定の一般的な説明であり、特定レジストリの利用を推奨・保証するものではありません。

まとめ

Docker や containerd を使う開発フローでは、Docker やレジストリというキーワードでトラブル検索に来る利用者が多く、分流ルールで「公開レジだけ安定ノード」「社内は直結」と分けるパターンは再現性が高いです。Clash ではホスト名を上のルールで捕捉し、REGISTRY 用プロキシグループに流す設計が効きやすく、その裏側ではデーモンのプロキシ設定と TUN の関係、DNS の一貫性まで含めて揃える必要があります。

GUI クライアントで試行錯誤する場合も、最終的に YAML のどの行を動かしたかを説明できる状態にしておくと、サブスク更新後の不具合に強くなります。安定したビルドから検証を始めたい場合は、クライアントのダウンロードページで OS に合った配布物を選ぶと手順が短くなります。オープンソースのリポジトリは挙動の理解に役立ちますが、実行ファイルの入手は配布ページを主な入口にすると、コアと UI の対応関係が追いやすいです。→ 無料で Clash をダウンロードし、レジストリ向け分流の検証を始める