📖 チュートリアル 2026年4月20日 ⏱ 約18分で読めます

Docker Desktop でイメージが引けない？Windows 11 の Clash とプロキシ・DNS を揃える（2026）

Windows 11 でブラウザや Clash（Clash Verge Rev／Mihomo 系）は問題なく動いているのに、Docker Desktop だけ docker pull がタイムアウトしたり、docker compose のビルド中に apt が直結のまま失敗したりする——原因はしばしば購読やノード品質ではなく、Docker がホストとは別のネットワークスタックを使い、さらに コンテナ内のプロキシ環境変数が空のまま動くことにあります。本稿は、HTTP/HTTPS プロキシ と daemon.json、DNS とレジストリ解決を、ホスト側の Clash と同じ前提に揃える手順を段階的に整理します。WSL2 で Git／npm をホスト Clash に合わせる記事と棲み分けし、Docker Desktop 固有の設定に焦点を当てます。利用は法令と利用規約の範囲内で行ってください。

この記事で最後までできるようになること

Windows 11 上で Clash の listen ポート（多くの場合 mixed-port や HTTP プロキシ）を確認し、Docker Desktop から ホストへ到達できるアドレス（host.docker.internal 等）を選べます。daemon.json または GUI のプロキシ欄に HTTP/HTTPS プロキシ を書き、docker pull・docker compose pull でイメージ取得が通るかを検証できます。あわせて DNS と fake-ip、コンテナビルド 時の HTTP_PROXY、apt／apk がプロキシを読まない典型パターンを切り分け、再インストールのループを避けるチェックリストも持ち帰れます。

なぜ「ホストでは Clash が効いているのに Docker だけ別物」に見えるのか

第一に、Docker Desktop（WSL2 バックエンドを含む）は、Linux コンテナ用の仮想ネットワーク上で動きます。Windows の「システムプロキシ」やブラウザの設定が、そのまま dockerd と コンテナのプロセスに伝播するとは限りません。第二に、イメージ取得 は registry-1.docker.io などレジストリの名前解決と TLS に依存し、DNS がホストの Clash と食い違うと「接続は張れるのに証明書や名前で落ちる」ように見えることがあります。第三に、Dockerfile 内の RUN apt-get は、ビルドステージのシェルで プロキシ環境変数が無いと直結のままです。ホストでプロキシをオンにしたつもりでも、ビルド引数や BuildKit の secrets を敷かないと再現しません。

前提：Windows 側の Clash でポートと到達範囲を確定する

まず mixed-port（例：7890）や HTTP プロキシの番号をメモします。Clash が 127.0.0.1 のみに bind していると、仮想ネットワークからは届きません。allow-lan 相当の設定と、ファイアウォールの受信規則が、Docker のブリッジからホストのポートへ届く前提を満たしているか確認してください。具体例は Windows 11 の LAN 許可とファイアウォールが近いです。初回セットアップが未完了なら、先にシステムプロキシと TUN の選び方を済ませると手戻りが減ります。

ステップ1：Docker Desktop からホストのプロキシへ届くアドレスを選ぶ

Linux コンテナから Windows ホストへは、多くの環境で host.docker.internal が解決されます（Docker Desktop のドキュメントに準拠）。この名前が使えない構成では、ホストの LAN IP を直接書く手もありますが、DHCP で変わる点に注意してください。検証には、コンテナ内から wget や curl で http://host.docker.internal:PORT（PORT は実際の mixed ポート）へ届くかを見ると早いです。届かない場合は、まずホスト側の listen とファイアウォールを直し、Docker の設定に進みます。

ステップ2：daemon.json で HTTP/HTTPS プロキシを明示する

Docker のエンジン設定（ユーザー向け UI の「Docker Engine」JSON、または daemon.json の場所は環境により異なります）に、proxies を追加する方法が一般的です。実際のキー名は Docker のバージョン表記に従ってください。概念的な例は次です（ポートとホスト名は環境に合わせて置き換え）。

{
  "proxies": {
    "http-proxy": "http://host.docker.internal:7890",
    "https-proxy": "http://host.docker.internal:7890",
    "no-proxy": "localhost,127.0.0.1,::1"
  }
}

近年の Docker Desktop ではキー名が http-proxy 形式のものと、ネストした proxies オブジェクトのものがドキュメント上に併存することがあるため、自分のバージョンの公式ドキュメントを正としてください。設定後は Docker を再起動し、docker info やログでプロキシが読み込まれているか確認します。no-proxy には社内レジストリや国内ミラーなど、直結したいホストを足します。ミラーだけプロキシを外す運用では、取りこぼしがないかをログで確認してください。

ステップ3：GUI の「Manual proxy」欄との関係

Docker Desktop の設定画面に Manual proxy configuration がある場合、GUI と daemon.json のどちらが有効か／上書きされるかは版により異なります。迷ったら、一度 GUI をクリアし、JSON 側だけで再現できる状態にすると切り分けが楽です。企業プロキシと Clash のローカルポートを混同しないよう、最終的にコンテナが向かう URL を一つに決めてから書き写します。

ステップ4：DNS とレジストリ——イメージ取得が「引けない」本丸

docker pull が失敗するとき、プロキシ以前に 名前解決 が崩れているケースが多いです。Clash の fake-ip を使う構成では、ホストのリゾルバと Docker 内の解決結果がズレると、レジストリの実 IP や SNI の期待と一致しません。対策の方向性は、(1) Docker Desktop の DNS 設定（例：ホストの DNS または信頼できる DoH／ローカル DNS を指定）を揃える、(2) Clash 側の DNS とルールで docker.io 系が意図した出口に付くかログで確認する、の二段です。詳細な sniffing／DNS の話は Clash Meta の sniffing と DNS も参照してください。

社内フィルタや地域制限でレジストリ自体がブロックされている場合は、ミラーへの切り替えや組織の許可が先です。技術的に可能でも、規程に反する迂回は扱いません。

ステップ5：docker compose とビルド時のプロキシ

docker compose で build: がある場合、イメージ取得（pull）と ビルド中の RUN は別レイヤです。pull はステップ2–4 で整えたエンジン設定に従いやすい一方、Dockerfile 内の apt-get update は、--build-arg HTTP_PROXY=... を渡すか、docker-compose.yml の args: で渡す必要があることがあります。BuildKit を使う場合は、ドキュメントに沿って ビルド時シークレットや キャッシュの扱いを選ぶと、資格情報をイメージに残しにくくなります。

環境変数の例（値は自分のホストとポートに置き換え）：

HTTP_PROXY=http://host.docker.internal:7890
HTTPS_PROXY=http://host.docker.internal:7890
NO_PROXY=localhost,127.0.0.1

docker compose の environment: は実行時コンテナ向けで、ビルド引数とは別口です。症状が「pull は通るが build だけ落ちる」のときは、ここを疑ってください。

ステップ6：コンテナ内の apt / apk がプロキシを使わないとき

起動済みコンテナに docker exec して apt-get する場合、シェルに http_proxy が無ければ直結のままです。/etc/apt/apt.conf.d/ に Acquire::http::Proxy を書く方法もありますが、イメージに焼き付けると運用が硬直するので、開発時は compose の environment やエントリポイントで注入する方が安全なことが多いです。Alpine の apk も同様に、ツールが参照する変数や設定ファイルが異なるため、エラーメッセージを見て層を切り分けます。

ステップ7：WSL2 統合利用者へのメモ

Docker Desktop の WSL2 バックエンドを使う場合、WSL2 のシェルから docker コマンドを叩く構成と、Windows 側の GUI から叩く構成で、見えている DNS やプロキシがズレることがあります。WSL2 と Windows で Clash を共有する記事でホスト IP を揃えたうえで、本稿の daemon.json を適用すると、docker pull の挙動が期待に近づきやすくなります。それでも不一致が残るときは、どのコンテキストで docker デーモンが動いているか（WSL 統合のオンオフ）を確認してください。

チェックリスト（上から順に）

（1）ブラウザ経由で Clash のルールにレジストリ関連ホストがヒットするか。（2）ホストで mixed ポートが listen し、必要なら LAN／ファイアウォールが許可しているか。（3）host.docker.internal:PORT がコンテナから TCP で届くか。（4）daemon.json または GUI のプロキシが意図どおり読み込まれているか。（5）DNS と fake-ip で名前解決が崩れていないか。（6）docker compose build にビルド用 HTTP_PROXY が渡っているか。（7）社内ミラー・国内レジストリを no-proxy に入れるべきか。これを一気に全部いじらず、ログで一段ずつ進めるのがコツです。

セキュリティとコンプライアンス

プロキシ URL に認証情報を埋め込むと、設定ファイルの共有やログに残るリスクが上がります。allow-lan を広げたときは、同一 LAN 上の他端末からホストのポートが見えないかも意識してください。本稿は自宅や許可された開発端末でのトラブルシュートを想定し、違法な迂回や利用規約違反の手口は扱いません。

まとめ

Docker Desktop を Windows 11 の Clash と揃える要点は、エンジン全体の HTTP/HTTPS プロキシ（daemon.json 等）でイメージ取得の経路を明示し、DNS と fake-ip のレイヤでレジストリ解決をホストと矛盾させないこと、そして docker compose の ビルド と コンテナ内 apt には別途 プロキシ環境変数 が要る場合があることです。チュートリアルでモードとログの読み方を押さえたうえで本稿を適用すると、切り分けが速くなります。

クライアントの入手は本サイトのダウンロードページを第一にすると、記事間の対応も追いやすく、ルール型プロキシの可観測性を活かした運用にもつながります。コンテナとホストで出口がバラつくときほど、明示的に揃えられるクライアントの価値がはっきりします。

→ Clash を無料ダウンロードし、Docker とホストのプロキシを揃えて試す