Clashの3つのモードの違い
GitHubのcloneが遅い、npmやpipのインストールが止まる、Dockerイメージを取得できない。そんな開発中の通信トラブルに、ClashのTUNモードで対処する手順を紹介します。Git・npm・pip・Dockerでの疎通確認から、macOSやWindowsで起きやすい権限・ルーティングの見直し方まで、…
開発用CLIをまとめて扱うなら、まずTUNの役割を理解する
Git、npm、Dockerの通信を個別の環境変数に頼らずプロキシへ流したい場合、TUNモードは有力な選択肢です。通常のシステムプロキシ設定は、HTTPプロキシを参照するアプリには便利ですが、すべてのCLIやバックグラウンドサービスがその設定を使うとは限りません。TUNは仮想ネットワークインターフェースを作り、OSの経路設定などを通じて端末のIP通信を取り込みます。対応する通信がClashまたはmihomoに届けば、Gitやnpmのためにそれぞれのプロキシ環境変数を設定しなくても、通常のルールで振り分けられます。
ただし、TUNを有効にすれば、端末上のすべてのアプリが必ず同じ経路になるわけではありません。OS、クライアント、カーネルのバージョン、権限、経路設定、DNSの構成によって挙動は異なります。さらにDocker DesktopのデーモンやWSL上のプロセスのように、通信元がホストOSの通常のアプリと異なる場合もあります。まずは「通信をTUNで取り込む設定」と「取り込んだ通信の出口を決めるルール」を分けて確認しましょう。
| 対象 | 確認する通信 | 注意点 |
|---|---|---|
| Git | HTTPSのclone、fetch、push。SSH接続の場合は通常TCP 22番など。 | SSHのポートがネットワーク側で遮断されている場合、TUNだけでは解決しません。 |
| npm | レジストリや依存パッケージ配布先へのHTTPS接続。 | レジストリのドメインがルールで意図したポリシーに振り分けられるか確認します。 |
| Docker | Docker EngineやDocker Desktopのデーモンによるイメージ取得。 | デーモンがホストとは異なる仮想環境で動作する場合、ホストの経路設定だけでは捕捉されないことがあります。 |
TUNを有効にする前にバックアップと最小構成を準備する
設定を変更する前に、クライアント名とバージョン、使用中のコアがmihomoかどうか、OSのバージョンを控えます。サブスクリプションを使っている場合は、元の設定をバックアップしてください。クライアントによってはサブスクリプションから生成した設定を直接編集しても、次回更新時に変更が消えます。TUNの項目をアプリの設定画面で管理するのか、オーバーライドやマージ設定に記述するのかを先に確認しましょう。
mihomoの設定ファイルで管理する場合、次は機能を確認するための最小例です。利用中のクライアントが設定画面からTUNを管理している場合は、同じ項目を別途設定ファイルにも重複して追加しないでください。クライアントが利用するコアのバージョンや配布元によって、対応する項目が異なることがあります。
tun:
enable: true
stack: mixed
auto-route: true
auto-detect-interface: trueenableはTUNを有効にし、auto-routeは経路設定を自動化するための指定です。auto-detect-interfaceは利用するネットワークインターフェースを検出するために使われます。stack: mixedは利用可能なスタック方式の一例ですが、すべてのOSやビルドで最適とは限りません。まずは現在のクライアントの推奨値を使い、複数の項目を一度に変更しないようにします。DNSのハイジャックやルート制御を追加する場合も、DNS設定全体を確認してから行ってください。
OSごとに権限と経路設定を確認する
- Windows：クライアントのTUNサービスまたは管理者権限の確認を求められたら、画面の案内に従います。仮想アダプターが作成されたか、クライアントのログにルート追加や権限エラーがないかを確認してください。会社の端末では、セキュリティソフトや組織のポリシーが仮想アダプターの作成を制限していることがあります。
- macOS：クライアントによってはネットワーク拡張機能やVPN構成の追加を許可する必要があります。macOSのプライバシーとセキュリティ関連の設定で許可を求められていないか確認し、許可後にクライアントを再起動します。許可画面の名称や場所はmacOSとクライアントのバージョンで異なります。
- Linux：仮想インターフェースの作成や経路変更に必要な権限があるか確認します。コンテナ内やWSL上でコアを動かす場合は、ホストとのネットワーク境界、必要な権限、ルートの競合も確認してください。権限を広く与える前に、ログに記録された具体的な拒否内容を調べます。
Git・npm・Dockerを別々にテストして通信経路を特定する
TUNを有効にしたら、最初にクライアントのログでTUNの起動結果を確認します。次に、接続画面や通信ログでテスト中の宛先が表示されるかを見ます。宛先が現れない場合は、ルールを変更する前に、そのプロセスの通信がTUNへ届いているかを調べてください。宛先が表示されているのに失敗する場合は、マッチしたルール、選択されたポリシー、DNS結果、接続先の状態を順に確認します。
Git：HTTPSとSSHを分けて確認
HTTPSのリポジトリであれば、次のコマンドでリモート参照を確認できます。実際にcloneする前に試せるため、認証や大容量データ取得の問題を分けやすくなります。
git ls-remote https://example.org/team/project.gitコマンドがタイムアウトする場合は、Clashの通信ログに接続先ドメインが記録されるかを見ます。ログに出ていれば、適用ルールと最終ポリシーを確認します。ログに出ていなければ、TUNの取り込み、別のネットワーク名前空間、Gitが実行されている環境を調べます。SSHのリポジトリでは、HTTPSとは別の接続先・ポートを使います。ネットワークがSSHを許可していない場合は、利用可能なHTTPS URLに切り替えられるか、管理者やリポジトリ提供元に確認してください。診断のためにホストキー検証を無効にするのは避けましょう。
環境変数やGitの設定に既存のプロキシが残っていると、TUNと明示プロキシが重なって別の経路になる場合があります。現在の設定を確認するには、次のコマンドを使えます。
git config --show-origin --get-regexp 'http\..*proxy|https\..*proxy'
env | grep -i proxyWindowsのPowerShellでは、環境変数の確認にGet-ChildItem Env:*proxy*を使えます。表示された値に認証情報が含まれる場合は、そのままログや問い合わせに貼り付けないでください。原因を確認せずに設定を一括削除せず、値の出どころと、設定が必要な別の環境でないかを確かめてから変更します。
npm：レジストリと依存先の両方を見る
まずnpmが使用するレジストリとプロキシ設定を確認します。次に、レジストリへの応答を調べます。
npm config get registry
npm config get proxy
npm config get https-proxy
npm pingnpm pingが成功しても、すべての依存パッケージが取得できるとは限りません。パッケージやロックファイルに記録された配布先が、レジストリとは異なるドメインを使う場合があります。インストールに失敗したときは、エラーメッセージのホスト名とClashの通信ログを照合してください。401や403は認証・アクセス権の問題、名前解決エラーはDNS、接続タイムアウトは経路や到達性など、エラーの種類によって見る場所が変わります。TLS検証を無効にして回避しないでください。
Docker：クライアントではなくデーモンの経路を確認
docker pullは、通常、Docker Engineのデーモンがイメージを取得します。Docker CLIを実行するシェルの環境変数が、デーモンにそのまま引き継がれるとは限りません。Docker Desktopではデーモンが仮想環境内で動作する構成があり、LinuxのDocker Engineでもsystemdサービスの環境設定はログインシェルと別です。そのため、GitやnpmがTUN経由で成功しても、Dockerのpullだけ失敗することがあります。
docker info
docker pull alpine:latestdocker infoで接続先のEngineやプロキシ関連の情報を確認し、pullの失敗時刻にクライアントのログへレジストリの接続が記録されるか調べます。デーモンの接続がログに出ない場合は、Docker Desktopのネットワーク設定、デーモンのプロキシ設定、WSLや仮想環境の経路を確認します。通信が記録される場合は、レジストリへのルール、DNS応答、認証情報を確認します。Docker向けのプロキシ設定が必要な環境では、組織の管理方針に従い、デーモン側に設定してください。TUNを有効にしただけでデーモンの設定が不要になるとは限りません。
失敗したときはDNS・ルート・既存プロキシを一つずつ確認する
複数の開発ツールが同時に失敗するなら、個々のツール設定よりもTUNの起動、権限、経路、DNSを先に調べます。1つのツールだけが失敗するなら、そのツール固有のプロキシ設定、実行環境、認証を疑います。たとえばnpmだけが失敗し、同じドメインへのHTTPS通信が他のツールでは成功する場合、npmの設定や依存先固有のホスト名を確認します。Dockerだけが失敗する場合は、Engineの実行場所とデーモンの経路が重要な手がかりです。
| 症状 | 最初に確認するもの | 避けたい対応 |
|---|---|---|
| TUNを有効にすると全体の通信が止まる | 起動ログ、権限、仮想アダプター、ルート競合。まずTUNを無効にして復旧するか確認。 | 原因を確認せずに複数のDNS・ルート設定を追加する。 |
| Git、npm、Dockerすべてで名前解決に失敗する | クライアントのDNS設定、OSのDNS、ログに表示される問い合わせ先。 | ファイアウォールや証明書検証を一括で無効にする。 |
| ブラウザーは使えるがGitまたはnpmが失敗する | プロセスのTUN捕捉、環境変数、ツール固有のproxy設定、対象ドメイン。 | ブラウザーの成功だけでCLIの経路も正常だと判断する。 |
| Gitとnpmは成功するがDocker pullだけ失敗する | Docker Engineの稼働場所、デーモンのプロキシ、DesktopやWSLのネットワーク境界。 | Docker CLIのシェル環境変数だけを変更して解決と決めつける。 |
| 一部のホストだけタイムアウトする | 通信ログのルールと出口、DNS応答、ホスト側の制限、ポート。 | 全宛先を同じポリシーに変更して切り分けを難しくする。 |
DNSの問題を調べるときは、Clash側のDNSログとOS側の名前解決結果を比較します。キャッシュや既存の接続が残っていると、設定変更前の結果が見える場合があります。確認時は対象コマンドを再実行し、必要であればアプリ側の接続を終了してから試してください。DNSを変更する場合は、TUNのDNS処理とOSのDNS設定が矛盾していないかを確認し、無関係な値を同時に追加しないようにします。
企業ネットワークやセキュリティ製品を利用している端末では、仮想インターフェース、独自ルート、TLS検査、UDPの制限が通信に影響することがあります。警告を回避するために証明書検証を無効化したり、管理者が設定した保護機能を停止したりしないでください。ログにはサブスクリプションURL、認証トークン、プライベートリポジトリ名などが含まれることがあります。共有前に機密情報を伏せ、エラー時刻、クライアントとコアのバージョン、対象ツール、エラーコードを残すと調査しやすくなります。
よくある質問
TUNを使えばGitやnpmのプロキシ環境変数は必ず不要ですか？
不要になる場合はありますが、必ずではありません。ツールの通信がOSのTUN経路を通り、Clashのルールに一致していることが前提です。既存の環境変数やツール独自のプロキシ設定があれば、それらが優先されたり、TUN経由の通信と競合したりすることがあります。まず設定の有無を確認し、TUNだけで通信できることを個別に検証してください。
Dockerのpullだけ失敗するのはなぜですか？
イメージを取得する主体がDocker Engineのデーモンであり、CLIを実行する端末とは別の環境で動くことがあるためです。Docker Desktop、WSL、Linuxのsystemdサービスでは、デーモンのネットワークやプロキシ設定がホストのシェルと異なる場合があります。Engineの稼働場所、デーモンの設定、Clashのログを照合してください。
GitのSSH接続がタイムアウトします。TUNの設定ミスですか？
可能性の一つですが、SSHで使うポートがネットワークや組織のファイアウォールにより遮断されている場合もあります。通信がClashのログに現れるか、別の許可されたネットワークで接続できるかを確認します。TUNは通信を取り込む仕組みであり、利用ネットワーク側のポート制限を解除するものではありません。
TUNを有効にするとGlobalモードにする必要がありますか？
ありません。TUNは通信を取り込む方式、Rule・Global・Directは取り込まれた通信の扱い方です。日常的な開発ではRuleモードを使い、対象ドメインに適用されたルールとポリシーを確認します。テストでGlobalを使った場合は、検証後に普段のモードへ戻してください。