はじめに
ブラウザーでは問題なく接続できるのに、ターミナルから git clone を実行すると失敗する。Homebrew の更新が止まったり、パッケージのダウンロードだけタイムアウトしたりする。こうしたトラブルは、Clash が動作していても、ターミナルの通信がプロキシを経由していない場合に起こります。
多くの GUI アプリはシステムプロキシの設定を参照しますが、コマンドラインツールは環境変数や個別の設定を参照することがあります。つまり、ブラウザーで接続できることだけでは、Git や Homebrew にプロキシが適用されているとは限りません。本記事では、通常のプロキシ設定と TUN モードの違いを確認し、ターミナルの通信経路を切り分ける手順を紹介します。
この記事で確認すること
Clash の TUN 設定、OS の権限、ターミナルの環境変数、Git と Homebrew の接続テストを順番に確認します。
1通信方式を選ぶ：システムプロキシと TUN
まず理解しておきたいのは、Clash の「システムプロキシ」と「TUN モード」は通信を取り込む方法が異なることです。システムプロキシは、OS のプロキシ設定を参照するアプリに向いています。一方、TUN モードは仮想ネットワークインターフェースを作り、通常のプロキシ設定を参照しないアプリの通信も取り込める場合があります。
| 方式 | 向いている状況 | 確認したい点 |
|---|---|---|
| システムプロキシ | ブラウザーなど、OS のプロキシ設定に対応したアプリを使う | ターミナルの環境変数やツール個別の設定が必要な場合がある |
| TUN モード | プロキシ設定を参照しないアプリや、複数の通信をまとめて制御したい | 管理者権限、ルート設定、DNS 設定、ルールの動作 |
| 環境変数 | Git や curl など、プロキシ環境変数を参照するコマンドを使う | プロキシのポート、変数の適用範囲、シェルの起動方法 |
TUN を有効にすれば、すべてのコマンドが必ずプロキシ経由になるとは限りません。OS、Clash クライアント、Mihomo コアの設定や、ルールの内容によって処理は異なります。変更前にプロファイルをバックアップし、最初は通信ログで対象プロセスの接続先とルールの判定を確認しましょう。
切り分けの基本
システムプロキシで動くアプリとターミナルで動くコマンドを分けて考えます。ターミナルだけ失敗する場合は、環境変数、Git の個別設定、TUN の順に確認すると原因を絞りやすくなります。
2Clash の TUN モードを設定する
Clash Verge Rev などのクライアントでは、設定画面から TUN モードを有効にできる場合があります。表示名や項目の配置はバージョンによって異なるため、まず設定画面で TUN を有効化し、必要に応じて管理者権限やシステム拡張の許可を求める案内に従います。アプリを管理者として起動する場合は、信頼できる配布元のソフトウェアであることを確認してください。
- Clash のプロファイルを選択し、コアが TUN に対応していることを確認します。
- 設定画面で TUN モードを有効にします。自動ルート設定や DNS 取得の項目がある場合は、現在のネットワーク環境とクライアントの説明を確認してから選びます。
- OS が許可を求めた場合は、管理者パスワードやネットワーク拡張の許可を行います。許可後に再起動が必要な環境もあります。
- 接続を開始し、Clash のログに TUN インターフェースの初期化エラーがないことを確認します。
- まずブラウザー、次にターミナルでテストを行い、Clash の接続ログに通信が記録されるか確認します。
Mihomo の設定を直接編集する場合は、既存プロファイルを壊さないよう、クライアントが提供するオーバーライド機能を優先してください。次の例は設定項目の形を示すものであり、すべての環境にそのまま適用できる完成設定ではありません。利用中のコアが各項目をサポートしているか、クライアントの説明と照らし合わせてください。
auto-route は対象環境に応じてルートを設定する項目です。VPN クライアント、仮想マシン、コンテナ、複数のネットワークインターフェースを併用していると、意図しない経路の競合が起こることがあります。TUN を有効にした後に社内ネットワークやローカル機器へ接続できなくなった場合は、設定をいったん戻し、ルートや除外対象を一つずつ確認してください。
権限と接続への影響
TUN はネットワーク経路を変更する機能です。設定変更後に通信が途切れた場合は、Clash を停止して元の経路に戻せるよう、プロファイルと現在の設定を保存してから作業してください。
3ターミナルと Git のプロキシを確認する
TUN を使わず、または TUN と併用してコマンド側にプロキシを指定する場合は、Clash が待ち受けているポートを確認します。よく使われる例は 7890 ですが、実際のポートはプロファイルやクライアントの設定によって異なります。ポート番号を推測せず、Clash の設定画面またはプロファイルで確認してください。
HTTP プロキシとして利用できるポートを確認したら、現在のターミナルのセッションだけで環境変数を設定してテストできます。以下の例のポートは、実際の設定に置き換えてください。
HTTP 用のポートと SOCKS 用のポートが別々に指定されている環境では、各変数に対応する形式とポートを使います。SOCKS の URL では、利用するツールが対応している場合、socks5h を使うとホスト名の名前解決もプロキシ側に任せられます。プロキシ認証を求める環境では、認証情報の保存方法にも注意してください。
Git が環境変数を参照しない、または Git だけ動作しない場合は、Git の設定を確認します。次の例では Git 用の HTTP プロキシを明示しています。不要になったら、同じスコープで設定を削除してください。
--global の設定はユーザー全体に適用されるため、社内 Git サーバーやローカルネットワークのリポジトリにも影響する可能性があります。特定のリポジトリだけで使う場合は、対象リポジトリのディレクトリで --local を指定する方法を検討してください。プロキシが不要な環境へ移動したときに接続できなくなる場合は、Git の設定に残った古い値を確認します。
4Homebrew をテストして原因を切り分ける
Homebrew はダウンロード処理などで内部的にコマンドやライブラリーを利用します。そのため、ターミナルに環境変数を設定しても、すべての依存処理に同じ方法で適用されるとは限りません。まずは短い接続テストを行い、Clash、DNS、Git、Homebrew のどの段階で止まるかを分けて確認します。
curl の結果が成功しても、Git や Homebrew が同じプロキシ設定を利用しているとは限りません。続けて、ターミナルを開いた状態で git ls-remote などの読み取り操作や、Homebrew の情報確認を行います。最初から更新やインストールを実行するのではなく、接続確認から始めると、不要な変更や大きなダウンロードを避けられます。
- 名前解決エラー： Clash の DNS 設定、TUN の DNS 取得、OS 側の DNS 設定を確認します。
- 接続拒否： ループバックアドレスとポート番号が正しいか、Clash が起動して待ち受けているかを確認します。
- タイムアウト： Clash の接続ログでルールの判定と選択中のプロキシを確認し、ノード側の状態も切り分けます。
- ブラウザーだけ成功： ターミナルの環境変数、Git のプロキシ設定、シェルの起動設定を確認します。
- TUN 有効時だけ失敗： ルートの競合、DNS の経路、ネットワークインターフェースの選択を見直します。
設定を安全に戻せるようにする
環境変数を ~/.zshrc や ~/.bashrc に追加すると、新しいターミナルにも設定が引き継がれます。恒久設定にする前に、一時設定で接続が改善することを確認してください。元に戻すときは、シェル設定ファイルから追加した行を削除し、新しいターミナルを開きます。現在のセッションだけ解除する場合は、macOS / Linux では unset HTTP_PROXY HTTPS_PROXY ALL_PROXY、PowerShell では該当する変数に空の値を設定します。
TUN と環境変数を同時に使う場合、同じ通信が二重にプロキシ処理されたり、片方の設定だけが優先されたりすることがあります。原因調査中は、まず片方の方式に絞ってテストし、安定したことを確認してから併用してください。組織が管理するネットワークでは、開発用リポジトリや認証情報の取り扱いについて、社内ポリシーも確認しましょう。
確認の順番
Clash の待受ポート、curl の接続、Git の設定、Homebrew の順にテストし、各段階で Clash のログを確認します。成功した項目と失敗した項目を記録すると、設定をやみくもに変更せずに原因を特定できます。
ターミナルの通信が安定しないときは、すべての設定を一度に変えるのではなく、通信を取り込む方式とコマンドごとの設定を一つずつ確かめることが重要です。Clash のログ、OS の権限、環境変数、Git の保存設定を順に確認すれば、問題のある箇所を安全に切り分けられます。