この記事で分かること

Git、SSH、npm、pip、Homebrew、Dockerを日常的に使う開発環境では、ツールごとにプロキシを設定する方法が一見わかりやすく見えます。しかし実際には、Gitだけ設定したあとに npm の取得が失敗したり、Docker のビルドだけがタイムアウトしたり、IDEの統合ターミナルが別の環境変数を読んでいたりします。こうした設定漏れと通信経路の分裂を減らす方法として、Clash Verge Rev や Mihomo の TUNモードが役立ちます。

本稿では、開発者向けに Clash を導入する際の考え方を、単なる「プロキシをオンにする手順」ではなく、どの通信をTUNへ送るか、社内サービスや localhost をなぜ除外するか、Git・npm・Dockerをどう検証するかという順番で整理します。TUNは強力な機能ですが、社内VPNやセキュリティソフトと競合することもあるため、最初から全通信を無条件にプロキシへ流すのではなく、ログを見ながら段階的に有効化するのが安全です。

開発者の環境でTUNモードが有効な理由

通常のシステムプロキシは、OSの設定を参照するアプリには便利です。ブラウザや一部のGUIアプリは、Clash Verge Revで「システムプロキシ」を有効にすると、そのままHTTP通信をプロキシへ送ります。一方で、すべての開発ツールがOSのプロキシ設定を参照するとは限りません。Gitは環境変数や独自設定、Node.jsはライブラリ、Dockerはデーモン側の設定に依存する場合があり、同じ端末でもアプリごとに挙動が変わります。

TUNモードは、仮想ネットワークインターフェースを作り、アプリがプロキシを意識していない通信もMihomo側で処理しやすくする仕組みです。そのため、HTTPS_PROXYを設定し忘れたCLIや、プロキシ環境変数を無視するバイナリでも、ルールに従った経路へ載せられる可能性があります。特に、依存パッケージの取得、コンテナイメージのダウンロード、外部Gitホストへの接続が混在する開発環境では、ツール単位の設定を減らせる点が大きな利点です。

ただし、TUNは「すべての問題を自動で解決するVPN」ではありません。DNSの解決方法、IPv6、UDP、社内ネットワークの経路、管理者権限などが関係するため、導入前に現在の通信状態を把握してください。TUNを有効にしたあとに問題が出た場合、システムプロキシと環境変数を同時に変更してしまうと原因を追いにくくなります。

TIP：最初はシステムプロキシだけでブラウザと curl を確認し、その後にTUNを有効化してください。設定を一度に変えず、変更前後のログと実行結果を残すと、開発環境を元に戻すときも安心です。

Clash設定を始める前の準備

まず、Clash Verge RevまたはMihomo対応クライアントが正常に起動し、利用するプロファイルが読み込まれていることを確認します。プロファイルには通常、プロキシノード、プロキシグループ、DNS、ルールが含まれます。購読URLを使う場合は、取得元が信頼できるか、更新後にルールやDNS設定が意図せず置き換わらないかを確認してください。会社の端末や開発用サーバーでは、管理者や組織のネットワークポリシーに従う必要があります。

次に、Clashの混合ポートを確認します。一般的にはHTTPとSOCKSの両方を扱えるポートを使いますが、実際の番号はプロファイルやクライアントの初期設定によって異なります。ターミナルで環境変数を設定する場合、ポート番号を推測せず、Clashの設定画面に表示された値を使ってください。別のVPNや開発用プロキシが同じポートを使用していると、Clashが起動していても接続が失敗します。

また、次の情報を変更前に記録しておくと切り分けが容易です。

  • 現在のClashの混合ポートとコントロール状態
  • 使用中のプロファイル名とプロキシグループ
  • 社内Git、社内レジストリ、VPNのアドレス
  • 開発用サービスが待ち受ける localhost、127.0.0.1、Dockerネットワークの範囲
  • 変更前に成功していたGit、npm、pipのコマンド

TUNモードとルール分流の設計

ClashのTUNをオンにする前に、最も重要なルールの優先順位を確認します。開発端末では、外部のコードホストやパッケージレジストリをPROXYへ送り、社内サービス、プライベートネットワーク、ローカル開発環境はDIRECTにする構成が基本です。ルールは上から評価されるため、広い範囲を対象にするルールを先に置くと、後から追加した除外設定が効かないことがあります。

たとえば、社内Gitが git.corp.example、社内npmレジストリが npm.corp.example にある場合、これらを先にDIRECTへ指定します。その後で外部GitHub、npm公開レジストリ、Pythonパッケージ配布サイトなどを必要に応じてPROXYへ送ります。実際のドメインは組織や利用サービスによって違うため、サンプルのホスト名をそのまま登録するのではなく、Clashの接続ログに表示された名前を基準にしてください。

ローカルアドレスの除外も重要です。localhost、127.0.0.1、192.168.0.0/16、10.0.0.0/8、172.16.0.0/12 などは、家庭内LANや開発用コンテナで使われることがあります。これらを外部プロキシへ流すと、ローカルAPIに接続できなくなったり、社内サービスの名前解決だけ失敗したりします。社内VPNが提供する専用ドメインやサブネットも、ネットワーク管理者の指示に従ってDIRECTまたはVPN側へ残してください。

DNS設定では、外部ドメインと社内ドメインを同じ方法で解決しないことがポイントです。社内DNSが必要な名前をパブリックDNSへ送ると、名前が見つからない、誤ったアドレスが返る、または社内情報が外部へ問い合わせられる可能性があります。Fake-IPを使う構成では、社内ドメインやローカル機器を除外リストへ追加し、アクセス先のアドレスが期待どおりか確認してください。

Git・SSH・npm・pip・Homebrew・Dockerの確認方法

GitとSSH

GitのHTTPS接続は、システムプロキシまたは環境変数で動作することが多い一方、SSHは別の経路を使います。TUNを使えばSSHのTCP接続もルールで扱える場合がありますが、社内GitのSSHアドレスまで外部PROXYへ送ると認証や経路が壊れることがあります。まずはリモートURLを確認し、外部ホストと社内ホストを分けてください。接続確認では、実際のリポジトリを変更せず、読み取り専用の取得や接続テストを使うと安全です。

Gitの動作だけでなく、サブモジュールも確認しましょう。メインリポジトリが取得できても、サブモジュールのURLが別ホストを向いていると、そこで初めてタイムアウトすることがあります。Git LFSを使うプロジェクトでは、大きなファイルの保存先が通常のGitホストと異なる場合もあるため、Clashのログに出る接続先を一つずつ確認します。

npm、pip、Homebrew

npmやpipは、パッケージ本体だけでなく、メタデータ、認証、リダイレクト先、依存関係の取得先へ複数の接続を行います。npmの設定に古いプロキシが残っていると、TUNと二重にプロキシを通り、接続が遅くなったり証明書エラーになったりします。pipでもユーザー設定、仮想環境、CI用の環境変数が別々に存在することがあるため、現在どの設定が優先されているかを確認してください。

Homebrewは、リポジトリ、ボトル、GitHubのリリース、CDNなど複数のホストへ接続します。Formulaの更新だけ成功しても、バイナリのダウンロードで失敗するケースがあるため、コマンドを一回実行しただけで設定完了と判断しないことが大切です。パッケージ管理ツールで問題が起きたら、まずClashのログに表示されるドメイン、接続方式、マッチしたルール、使用ノードを確認します。

Dockerとコンテナ

Dockerでは、ターミナルで実行するDocker CLIと、バックグラウンドで動くDocker Engineを分けて考える必要があります。CLIがTUNを通っていても、デーモンが別のVMやLinux環境で動いていれば、その環境から外部レジストリへ接続します。Docker Desktopを使う場合は、ホスト側のTUNだけでなく、Docker Desktopのプロキシ設定や証明書設定も確認してください。

コンテナ内のアプリが外部APIへ接続する場合も同様です。ホストの localhost とコンテナ内の localhost は同じ意味ではありません。プロキシのアドレスをコンテナへ渡す場合、ホスト専用のループバックアドレスをそのまま使うと到達できないことがあります。まずホスト上のGitやcurlで成功を確認し、その後にDockerネットワーク、DNS、環境変数を個別に検証してください。

ログとコマンドで通信を検証する

TUNを有効にしたあと、いきなり大きな依存関係をインストールするのではなく、短いテストを順番に実行します。最初は外部のHTTPSサイト、次にGitホスト、続いてパッケージレジストリ、最後にDockerイメージという順序が扱いやすいです。各テストのたびにClashの接続画面を開き、ホスト名、ルール、プロキシグループ、接続状態を確認します。

curl -I https://example.com
git ls-remote https://github.com/example/project.git
npm view npm version
python -m pip index versions pip
docker pull hello-world

外部サイトだけ成功し、Gitやnpmが失敗するなら、特定ドメインのルール不足、認証、TLS、またはレジストリ側の設定を疑います。すべての外部通信が失敗する場合は、TUNの権限、混合ポート、DNS、ノード状態を確認してください。社内サービスだけ失敗する場合は、DIRECTルール、社内DNS、VPN経路がTUNによって上書きされていないかを見ます。

環境変数を使う場合は、設定するだけでなく、現在のシェルが実際に読み込んでいるかを確認します。IDEの統合ターミナルは、ログインシェルと異なる起動設定を持つことがあります。設定変更後にターミナルやIDEを再起動し、シェル、ビルドツール、CIランナーがそれぞれ同じ環境を参照しているかを確認してください。HTTPSの証明書エラーが出た場合は、プロキシを無理に信頼済みにする前に、システム時刻、企業内TLS検査、CA証明書、接続先ホストを切り分けます。

注意：TUN、社内VPN、別の常駐VPNを同時に有効化すると、ルートやDNSの奪い合いが起きることがあります。接続不能になった場合は、Clashだけを残して他のネットワーク拡張を一時停止し、問題が再現する最小構成から確認してください。

開発環境で長く使うための運用ポイント

TUNを常時オンにするなら、設定を「動けばよい状態」で放置しないことが重要です。プロファイルを更新した後は、社内Git、外部Git、npm、pip、Dockerの代表的な通信を再確認します。ノード変更で結果が変わった場合は、ノードの品質だけでなく、ルールグループが意図した選択をしているかも確認してください。開発作業では短時間の成功より、同じ条件で再現できることのほうが価値があります。

CIやチーム開発では、個人PCのClash設定をそのまま共有しないようにします。認証情報、購読URL、社内ドメイン、プロキシのパスワードをリポジトリへ保存するのは危険です。チーム用の環境では、必要な通信、許可された経路、障害時の切り戻し方法を文書化し、個人のノード選択とは分離してください。特にDockerイメージやパッケージを取得するビルド環境では、外部通信を許可する範囲を最小限にすると、再現性と安全性を両立しやすくなります。

同類のGUIプロキシは導入が簡単でも、CLIごとの設定が分散したり、DockerやSSHの扱いが製品ごとに異なったりすることがあります。一方、Clashはルール、DNS、TUN、接続ログを一つの設定思想で確認でき、Git・npm・pip・Homebrew・Dockerの経路を段階的に揃えられる点が開発環境で実感しやすい強みです。もしツールごとのプロキシ設定に悩み、社内サービスは直結したまま外部開発通信だけを安定させたいなら、まず対応プラットフォーム向けのClashを入手し、今回紹介した小さなテストから始めるのが自然です。

Clash を無料でダウンロードして、快適なネット体験を →