開発者向けClash設定でできること
Git clone は進むのに npm install が止まる、pip のダウンロードがタイムアウトする、Docker のイメージ取得だけ失敗する——開発中の通信トラブルは、ブラウザーが使えるからといってターミナルやコンテナーも同じ経路を通っているとは限りません。ブラウザーは OS のシステムプロキシを参照していても、Git やパッケージ管理ツール、Docker Engine はそれぞれ独自のプロキシ設定を使うことがあります。
この記事では、Clash Verge Rev など Mihomo を利用するクライアントを例に、開発端末の通信を切り分ける方法を紹介します。まずはルールモードと環境変数を使い、必要な通信だけをプロキシへ送ります。それでもプロキシ設定を読まないアプリがある場合は、Clash の TUN モードを検討します。TUN は便利な一方で、社内 VPN やローカルネットワークとの経路が競合することもあるため、目的を決めてから有効にするのがポイントです。
Git、npm、pip、Docker の設定は似ているようで、適用されるプロセスが異なります。設定を変更する前に「どのコマンドが、どのホストへ、どの経路で接続しているか」を確認し、一度に複数の層を変えないようにしましょう。Clash の接続ログとツール側のエラーを照らし合わせれば、DNS、認証、プロキシ、レジストリのどこで止まったかを判断しやすくなります。
最初に選ぶのはシステムプロキシかTUNか
通常のシステムプロキシは、OS のプロキシ設定を参照するアプリの通信を中継します。ブラウザーや一部の GUI アプリには手軽ですが、すべての CLI やバックグラウンドサービスに自動で適用されるわけではありません。ターミナルから起動した Git、Node.js のパッケージマネージャー、Docker デーモンが別の環境で動作している場合、デスクトップの設定だけでは経路がそろわないことがあります。
TUN モードは仮想ネットワークインターフェースを使い、アプリが明示的なプロキシ設定を持たない通信も Clash 側へ取り込む方式です。環境変数を認識しない実行ファイルや、子プロセスが独自に通信するツールの確認に役立ちます。ただし、TUN を有効にしただけで必ずすべての通信が意図したノードへ流れるとは限りません。ルール、DNS、IPv6、OS のルート設定も影響します。
- システムプロキシから開始：ブラウザーと CLI を別々に試し、CLI だけ失敗するかを確認します。
- 環境変数を設定：HTTP(S) プロキシに対応するツールへ、Clash のローカルポートを明示します。
- TUN は必要な場合に限定：明示設定を受け付けないアプリや、設定を持たないプロセスで経路を補います。
- 結果をログで確認：成功したかだけでなく、接続先ホストと選ばれたルール、プロキシグループを照合します。
ポート番号はクライアントやプロファイルによって異なります。例としてよく見かける値をそのままコピーするのではなく、Clash の設定画面または実際に読み込まれている設定で HTTP と SOCKS のポートを確認してください。設定変更後は既存のシェルを使い回さず、新しいターミナルを開いてテストすると、古い環境変数が残る問題を避けられます。
ターミナルにプロキシ環境変数を渡す
多くの CLI は HTTP_PROXY、HTTPS_PROXY、場合によっては小文字の http_proxy、https_proxy を参照します。値には Clash のローカル HTTP プロキシを指定します。次は形式を示す例です。ポート番号は自分の Clash 設定に置き換えてください。
export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export http_proxy="$HTTP_PROXY"
export https_proxy="$HTTPS_PROXY"
export NO_PROXY=localhost,127.0.0.1,::1,.local
この設定は現在のシェルと、そのシェルから起動したプロセスに適用されます。設定ファイルに追加する場合は、macOS や Linux なら使用中のシェルに合わせて ~/.zshrc、~/.bashrc などを選び、読み込み直すか新しいターミナルを開きます。Windows PowerShell では環境変数の設定方法が異なり、ターミナルのセッションだけに一時設定する方法と、ユーザー環境変数として保存する方法があります。会社の端末では、永続的な変更を加える前に管理ポリシーを確認してください。
NO_PROXY は、プロキシを経由させたくない接続先を列挙します。開発サーバー、localhost、コンテナー内のサービス、社内 Git サーバーなどを対象にすることがあります。ただし、すべてのソフトが同じ書式を解釈するとは限りません。ホスト名、ドメイン接尾辞、IP アドレス、ポート指定の対応は実装によって異なるため、除外が効かない場合はツールのドキュメントとログを確認します。
環境変数を設定したら、まず値がシェルに反映されているかを確認します。プロキシの URL に認証情報を含める場合は、シェル履歴やログに秘密情報が残る可能性があります。共有端末では特に避け、必要なら OS の資格情報管理や組織の推奨方法を利用してください。Clash のローカルポートは通常、端末内からだけ利用する設定にし、LAN 全体へ不用意に公開しないことも大切です。
Git・npm・pip・Dockerを個別にテストする
プロキシが有効かどうかは、ひとつのコマンドだけで判定せず、実際に問題が起きているツールで確認します。たとえば curl の疎通が成功しても、Git の設定や Docker デーモンに同じプロキシが適用されているとは限りません。Clash の接続ログを開き、テストを実行した時刻に接続先が現れるかを見ます。ログに記録がなければ、通信が Clash に届いていない可能性があります。
Git cloneの確認
Git は環境変数を利用する構成に加え、独自の http.proxy 設定を持てます。どちらを使うか決めてから設定し、環境変数と Git 設定の両方に異なる値を残さないようにします。特定の公開リポジトリだけ失敗する場合は、プロキシ経路の問題だけでなく、リポジトリ URL、認証、サーバー側のレート制限も確認してください。社内 Git のように直接接続したいホストは、ルールまたは除外設定で意図どおりの経路になっているかをテストします。
npmとpipの確認
npm は実行する Node.js 環境や npm の設定によって、環境変数の読み方が変わる場合があります。ターミナルで設定した値が IDE の統合ターミナルにも渡っているか、また別の Node.js バージョン管理ツールが異なる環境を選んでいないかを確認しましょう。接続だけでなく、使用中のレジストリが社内ミラーや独自 URL に切り替わっていないかも見ます。エラーが認証や証明書を指しているなら、プロキシ経路だけを変更しても解決しないことがあります。
pip も環境変数や設定ファイル、パッケージインデックスの指定によって接続先が異なります。タイムアウトが出たときは、まず表示されたホスト名を記録し、Clash のログに同じ接続が出ているかを確認します。社内ミラーを使う環境では、そのミラーを不必要にプロキシへ送らないようにします。証明書エラーが出た場合は、認証局や社内 TLS 検査の設定が関係する可能性があるため、証明書検証を無効にするのではなく、管理者の案内に従って原因を調べてください。
Dockerイメージ取得の確認
Docker の通信は、コマンドを入力したシェルではなく Docker デーモン側で処理される場合があります。そのため、シェルに HTTPS_PROXY を設定しても、docker pull に反映されないことがあります。Docker Desktop を使っている場合は、アプリ側のプロキシ設定と、コンテナーへ渡す環境変数を混同しないようにします。Linux の Docker Engine では、デーモンのサービス設定にプロキシを指定する構成もあります。設定後にデーモンの再起動が必要なことがあるため、稼働中のコンテナーや共有環境への影響を確認してから変更してください。
Docker Hub からの取得が失敗する場合は、イメージ名やタグの誤り、認証制限、レート制限、レジストリへのネットワーク経路を分けて確認します。ダウンロードが始まってから切れるなら、単純な DNS 失敗ではなく、接続の安定性や大きなレイヤーの転送が関係しているかもしれません。ログに出るホストは設定やレジストリによって異なるため、固定のドメイン一覧をそのまま適用するより、実際に発生した接続先をもとにルールを調整する方が安全です。
TUNで取り込み、社内LANとローカル通信を除外する
環境変数を設定しても通信がプロキシを通らない場合は、Clash の TUN モードを一時的に有効にして比較できます。クライアントで TUN をオンにする前に、管理者権限が必要か、ネットワーク拡張や仮想アダプターの許可が求められるかを確認します。OS ごとに設定画面や許可の表示は異なります。Windows では仮想アダプターや管理者権限、macOS ではネットワーク関連の許可、Linux では TUN デバイスと権限が確認点になります。表示される名称はバージョンによって変わるため、画面上の案内を優先してください。
TUN を使うと、アプリ側にプロキシを設定できない通信もルールで扱いやすくなります。一方、社内 VPN、EDR、ゼロトラストクライアント、別の VPN アプリと同時に動かすと、デフォルトルートや DNS の取り合いが起きることがあります。接続が不安定になったら、TUN をいったん停止し、他の VPN を含めて一つずつ状態を確認します。管理対象端末では、ネットワーク設定の変更自体が禁止されている場合があるため、組織のルールを優先してください。
社内 LAN やローカル通信は、必要に応じて Clash のルールや TUN のルート除外でプロキシ対象から外します。対象になりやすいのは、ループバックアドレス、プライベートネットワーク、社内 DNS 名、開発用のローカルサーバー、コンテナー間通信です。ただし、プライベート IP をすべて無条件に直接接続にすると、意図しないネットワークまで除外する可能性があります。組織で利用しているサブネットや社内ドメインを確認し、最小限の範囲に設定してください。
設定後は、社内 Git、ローカル開発サーバー、Docker の公開ポートなど、直接接続が必要な通信をひとつずつ試します。Clash のログに表示されるルールと経路が意図どおりかを確認し、ローカル宛て通信までプロキシへ送られていないことを確かめます。ブラウザーで社内サイトが開くことだけを根拠にせず、実際に使う CLI や IDE から確認するのが重要です。
症状から原因を絞り込む
「ブラウザーは動くが clone できない」場合は、Git が環境変数または Git 独自設定を読み込んでいるかを確認します。「npm と pip は成功するが Docker だけ失敗する」場合は、Docker デーモンや Docker Desktop 側の設定を調べます。「TUN を有効にすると社内システムに接続できない」場合は、ルートや DNS の競合、除外ルールの範囲を見直します。このように、失敗しているツールと成功しているツールの違いを手掛かりにすると、むやみにプロファイル全体を書き換えずに済みます。
タイムアウトと認証エラーも区別しましょう。タイムアウトは DNS、経路、プロキシノード、接続維持の問題などで発生しますが、401 や 403 は認証情報、権限、レジストリポリシーが原因のことがあります。証明書エラーの場合も、検証を無効化して回避するのではなく、Clash のログ、CLI のエラー出力、社内ネットワークの証明書設定を確認します。ログを共有する際は、トークン、ユーザー名、社内ホスト名、接続先 IP などの機密情報を伏せてください。
最終的には「この端末のどのプロセスが、どの接続先に、どのルールで接続したか」を説明できる状態を目指します。開発者ごとに環境が異なるチームでは、Clash のプロファイルだけでなく、必要な環境変数、NO_PROXY の対象、Docker の設定場所、確認コマンドを短い手順書にまとめておくと再現性が上がります。設定を変えた日時と変更点も残しておけば、OS 更新や VPN クライアント更新のあとに問題が再発したとき、比較の基準になります。
よくある質問
システムプロキシを有効にすれば、Gitやnpmも必ず通りますか？
必ず通るわけではありません。各ツールの実装、起動元の環境、バックグラウンドサービスの動作によって、システムプロキシを参照しないことがあります。まずターミナルから実行するツールの環境変数を確認し、必要なら個別設定を使います。
最初からTUNを常時有効にしても問題ありませんか？
環境によっては動作しますが、社内 VPN や別のネットワーク拡張との競合、ローカル通信への影響を確認する必要があります。まず通常のプロキシ設定で解決できるかを調べ、TUN が必要なケースに絞って試すのがおすすめです。管理端末では組織のポリシーも確認してください。
NO_PROXYに社内ネットワークを登録したのに、直接接続されません。
NO_PROXY の書式や対応範囲はツールによって異なります。ドメインの接尾辞、IP アドレス、CIDR、ポート番号の扱いが共通とは限らないため、対象ツールの仕様を確認します。TUN モードの場合は、環境変数だけでなく Clash 側のルールやルート除外が必要なこともあります。
Dockerのpullだけ失敗するとき、最初に何を確認しますか？
Docker コマンドを実行するシェルだけでなく、Docker デーモンまたは Docker Desktop が使うプロキシ設定を確認します。続いて、イメージ名、タグ、認証状態、レジストリの制限と、Clash ログに実際の接続先が現れるかを順番に調べてください。
開発用プロキシツールの中には、環境変数を手作業で設定するだけのものや、端末ごとの通信経路を確認しにくいものもあります。Clash はルール分流、接続ログ、必要に応じた TUN を組み合わせられるため、Git・パッケージ管理ツール・Docker の経路を段階的に調整し、社内 LAN やローカル通信を分けて管理しやすいのが利点です。開発環境に合わせて設定を確かめたい場合は、対応クライアントをダウンロードして、まずは通常のプロキシ接続から試してみてください。