はじめに：Dockerだけ通信できない理由
Docker開発環境では、ホストOS上のブラウザーやターミナルは正常にインターネットへ接続できるにもかかわらず、コンテナ内の GitHub、Docker Hub、npm、PyPI、Go Modules だけがタイムアウトすることがあります。この症状は、単純にClashのプロキシを有効にするだけでは解決しません。コンテナはホストとは異なるネットワーク名前空間とDNS設定を使用するため、ホスト側のシステムプロキシ設定がそのままコンテナへ継承されないからです。
本ガイドでは、Clash と Mihomo を中心に、Dockerの通信を適切な経路へ分流するための設計を解説します。TUNモードを使って透過的に処理する方法、Linuxホストでiptablesを組み合わせる方法、Dockerデーモンだけにプロキシを設定する方法を比較し、DNS、IPv6、開発ツールごとのルール、設定ファイルの管理、障害発生時のログ確認まで実運用を意識して整理します。
この記事の目標
ホストとコンテナの通信経路を分離して可視化し、必要な開発通信だけをClashへ通しながら、国内サービスや社内ネットワークは安全にDIRECTで接続できる構成を作ります。
1まず理解したい通信経路と方式の違い
Dockerの通信をClashへ流す場合、最初に「どの通信を捕捉するか」を決める必要があります。ブラウザーのようにHTTPプロキシへ対応したアプリケーションだけを対象にするのか、コンテナ内のあらゆるTCP通信を対象にするのかによって、適切な方式は変わります。
- 環境変数によるプロキシ：
HTTP_PROXY、HTTPS_PROXY、ALL_PROXYを設定する方式です。curl、Git、npm、aptなど多くのツールで利用できますが、プロキシに対応していない通信やUDPは対象外です。 - TUNモード： 仮想ネットワークインターフェースでシステム通信を捕捉し、宛先ルールに従って処理します。コンテナの通信を含む幅広いトラフィックを扱いやすい一方、管理者権限、ルーティング、DNSの設計が必要です。
- iptablesによる透過プロキシ： Linuxホスト上でDockerブリッジから出るパケットをREDIRECTまたはTProxyへ送ります。細かい制御が可能ですが、除外先、戻りパケット、Dockerの仮想インターフェースを誤ると通信ループが発生します。
- Dockerデーモンのプロキシ： Docker Hubからイメージをpullする処理だけを対象にします。イメージ取得には便利ですが、実行中コンテナのGitやパッケージマネージャーの通信までは自動的に処理しません。
方式選択の目安
まずは環境変数方式で動作を確認し、複数のコンテナやプロキシ非対応アプリまで一括して扱いたい場合にTUNまたはiptablesへ進むと、原因を切り分けやすくなります。
TUNとiptablesはどちらを選ぶべきか
WindowsやmacOSでClash Verge Revを使う場合は、ホスト側のTUNモードを有効にする構成が比較的管理しやすい方法です。Clashが仮想インターフェースを作成し、OSの経路を通じてDocker Desktopの通信を捕捉できる場合があります。ただし、Docker Desktopの内部VMやバージョンによって挙動が異なるため、必ずコンテナからの名前解決とHTTPS接続を実測してください。
LinuxでDocker Engineを直接動かしている場合は、Dockerブリッジのサブネットを明示し、iptablesまたはMihomoの自動ルート機能を設計する方法が適しています。最初から全ポートを強制的に転送するのではなく、DockerネットワークのCIDR、Clash自身の混合ポート、DNSポート、社内アドレスを除外することが重要です。
2実際に設定する：TUNとコンテナ用プロキシ
ここでは、Mihomoを搭載したClashクライアントをホストで起動し、コンテナから開発ツールの通信を送る基本構成を作ります。以下の値は例です。Clashが待ち受けるアドレス、Dockerブリッジのゲートウェイ、利用するプロキシグループ名は、環境に合わせて変更してください。
allow-lan: true はLAN上のクライアントからClashへ接続するために必要です。ただし、無制限に公開すると同一ネットワーク内の他端末からプロキシとして利用される可能性があるため、ファイアウォールで許可範囲を絞ってください。Dockerの内部ネットワークからアクセスする場合も、7890番ポートをホスト側で適切に公開する必要があります。
コンテナがホストのプロキシへ接続するには、LinuxではDockerブリッジのゲートウェイ、Docker Desktopでは host.docker.internal を使用する構成が一般的です。Composeの場合は、開発用ファイルにだけ以下の環境変数を追加します。
Gitではリポジトリ単位またはコンテナ内だけにプロキシを設定できます。たとえばHTTPS経由の取得には次のように指定します。
認証情報を環境変数へ直書きしない
プロキシにユーザー名やパスワードが必要な場合、ComposeファイルをGitへコミットすると漏えいにつながります。開発用の.env、Docker secrets、CIの保護された変数を利用し、ログにも認証情報が出力されないようにしてください。
3DNSと開発ツールごとの分流ルール
コンテナ環境で最も見落とされやすいのがDNSです。ホストのDNSが正常でも、コンテナの /etc/resolv.conf がDocker内部のリゾルバーを指し、Clashのルール処理を経由していない場合があります。fake-ipを使う場合は、コンテナが返された仮想アドレスへ接続できる経路になっているかを確認し、社内ドメインやサービスディスカバリー名はfake-ipの対象外にします。
分流ルールは「すべてプロキシ」から始めるより、用途別にグループを分けるほうが安全です。GitHubのコード取得、Docker Hubのレジストリ通信、言語パッケージ、一般的なWebアクセスでは、必要なノードや障害時の扱いが異なるためです。
Git、Docker、npmで異なる注意点
GitHubはコード本体だけでなく、認証、リダイレクト、Releaseファイル、Git LFSなど複数のホストへ接続することがあります。github.com だけを指定しても、アセット取得が失敗する場合は githubusercontent.com やLFS用のエンドポイントをログから確認してください。
Docker Hubの docker pull はDockerデーモンが実行するため、コンテナの環境変数だけでは解決しません。LinuxではsystemdのDockerサービスにプロキシ設定を追加し、設定後にデーモンを再起動します。一方、コンテナ内で実行するcurlやGitは、別途コンテナ側のプロキシ環境変数が必要です。この二つを混同しないことが重要です。
DIRECTにすべき通信
Dockerのブリッジネットワーク、localhost、社内VPNのCIDR、データベースやRedisなどの開発用サービスは、原則としてプロキシへ送らないでください。誤って外部ノードを経由すると、接続遅延だけでなくアクセス制御や監査上の問題が発生します。
4障害時の確認手順と運用のコツ
設定後に通信できない場合は、いきなりルールを増やすのではなく、名前解決、ホスト到達性、プロキシ接続、目的地へのHTTPS接続の順に確認します。コンテナ内で次のコマンドを実行すると、どの段階で失敗しているかを判断できます。
- DNSだけ失敗する： DockerのDNS設定、ClashのDNS listenポート、fake-ip-filter、UDP 53の扱いを確認します。
- プロキシ指定時だけ成功する： TUNやiptablesがコンテナ通信を捕捉できていません。経路、権限、Dockerブリッジの除外設定を調べます。
- GitHubは成功するがpullだけ失敗する： Dockerデーモンのプロキシ設定、レジストリの認証、Docker Hubのリダイレクト先を確認します。
- 一部の社内サービスだけ失敗する：
NO_PROXYとClashのDIRECTルールに、ホスト名とCIDRの両方が含まれているか確認します。 - 接続が不安定になる： IPv6がプロキシを迂回していないか、MTU、UDP対応、ノードのレイテンシを確認します。
Clashのログでは、対象ドメインがどのルールに一致し、どのプロキシグループへ送られたかを確認できます。デバッグ時だけ log-level: debug に変更し、原因が分かったら info または warn に戻してください。常時デバッグログを出すと、認証用URLや内部ホスト名がログに残り、ディスク容量も消費します。
設定ファイルは一枚に詰め込まず、サブスクリプション本体、開発環境用のMerge設定、個人用の秘密情報を分離して管理すると更新に強くなります。ルールを変更したら、ホストのブラウザーだけでなく、実際のコンテナから git ls-remote、docker pull、パッケージインストールをテストし、DIRECTへ戻した場合の動作も確認してください。
最終チェック
Dockerデーモンと実行中コンテナのプロキシ設定を分け、DNSリークとIPv6の迂回を確認し、社内CIDRをDIRECTへ固定できれば、開発環境でも再現性の高い分流構成になります。
運用中は、Clashのコア更新やDocker Desktopのネットワーク仕様変更によって挙動が変わることがあります。設定を更新する前に現在のYAMLとComposeファイルを保存し、変更後は小さなテスト用コンテナで検証してから本番の開発環境へ反映してください。