この記事で分かること
Git の clone や fetch は途中で止まるのに、ブラウザでは問題なくページを開ける。npm install でパッケージの取得がタイムアウトする。Docker の pull だけが失敗する——開発用ターミナルで起きるこうした症状は、ネットワーク全体の障害ではなく、コマンドを実行するプロセスが Clash のプロキシ設定を参照していないことが原因の一つです。
本稿では Clash Verge Rev と Mihomoを例に、TUN モードでターミナル通信を扱う考え方を解説します。TUN は、アプリごとに HTTP_PROXY を設定しなくても、OS のネットワーク経路を通る通信を Mihomo 側で受け取れる方式です。Git、npm、Docker が必ず同じように動くわけではありませんが、どの通信が TUN の対象になっているかを確認し、必要なら環境変数や Docker 側の設定を併用すれば、原因を段階的に切り分けられます。
ポイントは、TUN を有効にすれば何でも自動で直ると考えないことです。DNS の解決、ルールのマッチ先、アプリ独自のプロキシ設定、コンテナとホストのネットワーク境界は別々に確認します。最初は Git など一つのコマンドで経路を検証し、問題がなければ npm、Docker の順に対象を広げると、変更の影響を追いやすくなります。
TUN はターミナル通信をどう扱うのか
通常のシステムプロキシは、OS のプロキシ設定を参照するアプリには有効ですが、すべての CLI や開発ツールがその設定を自動利用するわけではありません。シェルから起動したプログラムが環境変数を見ていなければ、ブラウザはプロキシ経由でも、Git や Node.js の通信は直接接続になることがあります。
TUN モードでは、仮想ネットワークインターフェースを使って端末の IP 通信を Mihomo に渡し、設定したルールに沿って処理します。そのため、アプリ側にプロキシ対応がなくても、OS の通常の通信経路に乗る接続であれば扱える可能性があります。一方、権限の制約、他の VPN やセキュリティソフトとの競合、端末や OS ごとの実装差があるため、対象範囲は環境によって異なります。
また、TUN は「すべての通信を必ずプロキシへ送る」機能ではありません。Mihomo のルールが DIRECT を選べば、その接続は直接通信になります。DNS の処理方法や接続先 IP によってルールの見え方が変わることもあるため、TUN を開始したあとに Clash の接続ログを確認し、実際のホスト名と最終的なポリシーを照合してください。
- システムプロキシ：OS の設定を参照するアプリに向く方式。CLI は環境変数などの個別対応が必要な場合があります。
- 環境変数：対応するプロセスを明示的にプロキシへ向ける方式。対象が分かりやすく、特定のシェルやコマンドだけに適用できます。
- TUN：プロキシ設定を持たないアプリも含め、OS の通信経路を介して処理する方式。権限や競合、ルール確認が重要です。
有効化の前に確認する設定
まず Clash のプロファイルが読み込まれ、利用するプロキシグループに接続先があることを確認します。TUN はネットワーク経路を切り替える機能であり、接続先ノードやルールを自動で用意するものではありません。ブラウザなど、すでに動作しているアプリで基本の接続を確認してから、TUN の検証に進みます。
Clash Verge Rev では、設定画面から TUN の有効化や関連オプションを操作します。画面の項目名や必要な権限は、アプリと Mihomo のバージョン、OS によって異なるため、表示されている案内を確認してください。管理者権限やネットワーク拡張の許可を求められた場合は、内容を理解したうえで承認します。組織管理端末では、利用規約や管理者の指示を優先してください。
次に、プロファイルのルールを確認します。開発端末では Git ホスティング、npm レジストリ、Docker Registry など、実際に使う接続先がどのルールに一致するかが大切です。特定サービスをプロキシ経由にする場合も、ホスト名を決め打ちで大量に追加するより、接続ログに記録された名前を確認してからルールを調整します。サービス側の CDN や認証先が別ホストになることもあるため、ひとつのドメインだけを登録しても通信全体をカバーできない場合があります。
- Clash のプロファイルが有効で、選択中のグループに利用可能な接続先がある。
- TUN に必要な権限が許可され、アプリ画面に起動状態が表示されている。
- 別の VPN、仮想ネットワーク、セキュリティ製品が同じ経路を変更していない。
- 社内 Git やローカル開発サーバーなど、直接接続を維持したい宛先を把握している。
実践：TUN を有効にして Git と npm を確認する
ここでは、設定を一度に広げず、ホスト端末上の Git と npm から確認します。操作名はバージョンで異なる場合がありますが、検証の順序は共通です。まず Clash Verge Rev で TUN を有効にし、状態表示が起動中になったことを確認します。その後、接続ログを開いたまま、短いテストコマンドを実行してください。
- TUN を開始する：設定画面で TUN を有効にし、権限やネットワーク拡張の確認が出た場合は、表示内容を確認して処理します。開始できない場合は、他の VPN やネットワーク制御アプリを一時停止して再確認します。
- プロキシ環境変数を確認する：シェルで
env | grep -i proxyを実行します。環境変数が設定されていなくても、TUN の経路で通信できる場合はあります。逆に、古いHTTP_PROXYが残っていると、TUN と異なるプロキシへ接続しようとする可能性があります。 - Git の接続を試す：既知のリポジトリに対して
git ls-remoteを実行します。認証が必要なリポジトリでは、まず公開リポジトリなど認証の影響を受けにくい対象を使います。Clash のログに対象ホストが現れ、意図したポリシーに一致しているか確認します。 - npm の取得を試す：普段使っているレジストリ設定を確認したうえで、パッケージ情報の取得や通常のインストールを試します。失敗した場合は、npm のエラーに出るホスト名と Clash のログを突き合わせます。レジストリを変更する前に、現在の設定を記録してください。
- 結果を一つずつ比較する：TUN をオフに戻した状態でも同じコマンドを試すと、TUN が経路へ影響しているか比較できます。システムプロキシや環境変数も同時に変更すると、成功した理由が分かりにくくなるため、条件は一度に一つだけ変えます。
CLI に明示的なプロキシ設定が必要な環境では、Clash のローカル HTTP または SOCKS ポートを確認し、シェルの環境変数を利用できます。ポート番号はプロファイルやアプリ設定によって異なるため、例の番号をそのまま使わず、実際の待受ポートに置き換えてください。
export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export ALL_PROXY=socks5://127.0.0.1:7891
export NO_PROXY=localhost,127.0.0.1,::1
この設定は、環境変数を読むプロセスにだけ作用します。シェル設定ファイルに保存する場合は、不要になったときに解除できるよう、追加した行を分かる形で管理してください。ローカル開発用のホストや社内サービスを NO_PROXY に含めるかは、組織のネットワーク設計に合わせます。むやみに広いドメインを除外すると、意図せず直接接続になることがあります。
Docker はホストの TUN と別に確認する
Docker のイメージ取得では、まず docker pull を実行しているのがホスト上の Docker CLI なのか、別の仮想マシンやリモート Docker Engine なのかを確認します。CLI がローカルにあっても、レジストリへ実際に通信するのは Docker デーモンです。Docker Desktop は内部の VM やネットワーク層を経由するため、ホスト端末の TUN が有効だからといって、デーモンの通信も同じ経路になるとは限りません。
まず Clash のログを見ながらイメージ取得を試し、Registry や認証先への接続が記録されるか確認します。ログに通信が出ない場合は、Docker Engine が別環境で稼働していないか、デーモン側のプロキシ設定が必要ではないかを調べます。Docker Desktop ではアプリの設定画面、Linux の Docker Engine ではサービス管理方法など、環境に合った公式手順に従ってください。ホストのシェルで設定した HTTPS_PROXY が、すでに起動中のデーモンへ自動反映されるとは限りません。
コンテナ内のアプリ通信も、イメージ取得とは別の問題です。コンテナは独自のネットワーク名前空間や DNS 設定を持つため、ホストの TUN、Docker ブリッジ、コンテナ内の環境変数のどこで処理するかを切り分けます。コンテナからホストの 127.0.0.1 を指定しても、そのアドレスはコンテナ自身を指す点にも注意してください。必要な場合は Docker のネットワーク構成とホスト側プロキシの到達可能なアドレスを確認し、公開ネットワークへ不用意にプロキシポートを開放しないようにします。
DNS・タイムアウト・接続先の切り分け
Git、npm、Docker のどれかが失敗したら、最初にエラーメッセージを分類します。名前解決エラー、接続拒否、TLS エラー、認証エラー、タイムアウトは、同じ「接続できない」でも原因が異なります。失敗時刻、実行したコマンド、対象ホスト、Clash のログをセットで記録すると、再現性のある調査ができます。
- ログに対象ホストがない：アプリが別のネットワーク環境や Docker デーモンから通信している、あるいは TUN の対象外になっている可能性があります。実行場所とデーモンの位置を確認します。
- ログに DIRECT と表示される：ルール順序やルールの対象を確認します。最後の汎用ルールに到達していないか、ドメインではなく IP ベースの接続になっていないかも調べます。
- 接続先が PROXY なのにタイムアウトする：選択中のノード、上流の混雑、接続先の応答、長い転送に対するタイムアウトを分けて確認します。別の接続先で同じテストを行う場合も、一度に条件を増やさないようにします。
- DNS エラーや誤った IP が見える：端末、Clash、Docker のどの層が名前を解決しているかを確認します。DNS キャッシュや異なる DNS 設定が残っていると、ログ上の接続先と期待するホストが一致しないことがあります。
- TLS や証明書で止まる：プロキシ経路だけでなく、企業ネットワークの TLS 検査、システム時刻、証明書ストア、アプリ独自の証明書設定も調べます。証明書検証を無効にして回避する方法は、原因調査にも安全性にも適しません。
タイムアウト値をすぐ大きくするのは避けてください。DNS 解決が止まっているのか、TCP 接続が確立しないのか、TLS の後で応答が途切れるのかで対処は変わります。接続ログとコマンドの詳細出力を時刻で照合し、失敗した段階を絞ってから、ルールやポート、ノードを修正します。設定を変更したら、同じ宛先・同じコマンドで再試験すると効果を判断しやすくなります。
よくある質問
環境変数を設定しなくても TUN だけで Git は使えますか？
Git の通信が TUN の対象になるネットワーク経路を通り、Clash のルールと接続先が適切であれば、環境変数なしで動作する場合があります。ただし、Git の通信方式や実行環境、OS、他の VPN との組み合わせによって結果は異なります。接続ログに Git の接続先が出るかを確認し、出ない場合は環境変数を使う方法と比較してください。
TUN を有効にしたのに npm install が失敗するのはなぜですか？
npm のレジストリ設定、環境変数、DNS、認証、依存パッケージの取得先など、原因は複数あります。エラーに表示されたホスト名を確認し、その接続が Clash のログに記録されるか、どのルールへ一致したかを調べます。レジストリの変更やタイムアウト値の延長は、原因を特定してから行うのが安全です。
Docker Desktop の pull もホストの TUN で処理されますか？
常にそうなるとは限りません。Docker Desktop はホスト上の CLI と別の内部ネットワーク層を使うため、Docker デーモン側のプロキシ設定が必要な場合があります。ホストで Git が成功しても、Docker の接続が Clash のログに現れるかを個別に確認してください。
TUN と環境変数を同時に使っても問題ありませんか？
併用できる環境はありますが、接続が二重にプロキシされる、古いポートへ接続する、ローカル通信までプロキシへ送るといった問題が起きることがあります。まず片方だけでテストし、必要な場合に限って併用します。解除方法も合わせて記録しておくと、トラブル時に元へ戻せます。
開発環境によっては、CLI ごとにプロキシ設定を手入力する方法が確実な一方、Git、npm、Docker で設定場所が分かれ、端末を替えるたびに見直しが必要になります。Clash の TUN は、OS の経路を通る複数の通信をまとめて扱い、ログとルールで接続先を確認できるのが利点です。ただし Docker デーモンやコンテナの境界は個別確認が欠かせません。まず一つのコマンドで経路を確かめ、自分の開発環境に合う運用を組み立てたい方は、対応クライアントを確認してください。