開発作業でブラウザだけ通信できる理由
ブラウザでは GitHub を開けるのに、ターミナルの git clone や brew install がタイムアウトすることがあります。これは必ずしも Clash のノードが停止しているからではありません。ブラウザは OS のシステムプロキシ設定を参照する一方、Git、SSH、Homebrew はそれぞれ異なる方法で通信経路を決めるためです。つまり、ブラウザでの成功だけでは、開発ツールの通信もプロキシを通っているとは判断できません。
まず、失敗するコマンドと実行環境を切り分けます。macOS のローカルターミナル、VS Code の統合ターミナル、Dev Container、リモート SSH 先では、引き継がれる環境変数やネットワーク経路が異なります。ローカルの Clash が有効でも、リモートサーバー上で実行した git の通信は、そのサーバー側のネットワークから出ていくのが基本です。どの端末で、どのホスト名への接続が失敗しているのかを先に記録すると、設定をむやみに増やさずに済みます。
対策は大きく二つあります。一つは Clash の TUN モードで端末の通信を捕捉する方法、もう一つは各ツールへ HTTP プロキシや SOCKS プロキシを明示する方法です。TUN はアプリごとの環境変数に頼らず通信をまとめて扱える反面、権限や VPN との競合、DNS の経路確認が必要です。ツールごとの設定は対象を限定しやすいものの、Git の HTTPS と SSH を別々に設定する必要があります。どちらか一方から始め、経路を確認してから次の設定に進むのが安全です。
github.com、GitHub の SSH 接続先、Homebrew が利用した配布ホストが記録されるかを見ます。ログに通信が出ない場合は、プロキシ設定の不足だけでなく、対象プロセスが別のネットワーク名前空間やリモート環境で動いていないかも確認してください。
TUN・システムプロキシ・環境変数を使い分ける
Clash Verge、Clash Verge Rev、Mihomo などで TUN モードを使う場合は、まずクライアントとコアが TUN をサポートしていること、必要な権限が許可されていることを確認します。メニュー名や権限の表示はアプリや OS により異なります。TUN を有効にしたら、端末から HTTPS 接続を一つ試し、Clash の接続ログに対象ホストが現れるかを見てください。システムプロキシだけを有効にした状態では、ターミナルの全通信が捕捉されるとは限りません。
TUN で通信が確認できれば、Git や Homebrew に個別のプロキシ設定を加えずに済む場合があります。ただし、アプリが独自のプロキシを指定していると、接続が二重になったり、設定したプロキシ自体へ到達できなくなったりすることがあります。TUN と環境変数を同時に使う場合は、まず片方だけを有効にして動作を確認し、必要性が明確なときにもう一方を加えてください。特に 127.0.0.1 宛てのプロキシ接続が TUN で再捕捉される構成では、ループバック通信や除外設定の扱いが重要です。
ツール別に設定するなら、Clash のポート設定で実際の HTTP mixed-port または SOCKS port を確認します。よくある既定値として HTTP が 7890、SOCKS が 7891 の構成がありますが、購読やクライアントの設定によって異なります。表示された値を確認せず、例のポート番号をそのまま貼り付けないでください。プロキシがローカル以外のインターフェースにも公開されている場合は、不要な外部接続を許さないよう待ち受け範囲と認証の設定にも注意します。
シェルで一時的に試すときは、Clash の実際の HTTP ポートに合わせて環境変数を設定します。たとえば HTTP ポートが 7890 の場合、次のようにして同じターミナルから接続を確認できます。大文字と小文字の環境変数を併記すると、ツールや子プロセスによる参照名の違いを吸収しやすくなります。
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
シェルを閉じれば消える一時設定で疎通を試し、うまくいった場合だけシェルの設定ファイルへ移します。企業内のホストやローカルサービスまでプロキシへ送らないよう、必要に応じて NO_PROXY に社内ドメインや開発用ホストを追加してください。シェルの起動方法によって設定ファイルが読み込まれないこともあります。ログインシェル、非ログインシェル、IDE の統合ターミナルで値が一致するか、env などで確認するのが実務的です。
GitHub の HTTPS と SSH を別々に設定する
HTTPS の Git リモートは、Git の設定またはシェルのプロキシ環境変数を利用できます。まず git remote -v でリモート URL が https:// か git@ 形式かを確認してください。HTTPS の場合、先ほどの環境変数を設定したターミナルから git ls-remote や小さなリポジトリの取得を試します。これで成功し、環境変数を外すと失敗するなら、Git の通信がプロキシ設定に依存していることを絞り込めます。
常用する場合でも、いきなり全ホストへ効くグローバル設定を追加するのは避けるのが無難です。会社の Git サーバーやローカルの開発サービスまで同じ出口へ送ると、認証や接続先制限に影響する可能性があります。Git の設定を恒久化するなら、対象 URL に限定する方法や、利用するリポジトリだけで設定する方法を検討し、既存の http.proxy がないか git config --show-origin --get-regexp 'http.*proxy' で確認します。試験後に設定を消す場合も、どの設定ファイルから読み込まれた値かを確認してから変更してください。
SSH 形式のリモートは別の扱いです。Git の HTTPS プロキシ設定や https_proxy は、通常の SSH 接続を自動的にプロキシへ流しません。まず Clash のルールで対象の SSH 通信が意図したポリシーに割り当てられているかを確認し、TUN を使っていない場合は SSH 用の中継方法を設定します。macOS の nc で SOCKS5 の ProxyCommand を利用できる環境なら、~/.ssh/config に対象ホスト向けの設定を追加する方法があります。
Host github.com
HostName github.com
User git
ProxyCommand nc -X 5 -x 127.0.0.1:7891 %h %p
この例は SOCKS ポートが 7891 で、使用中の nc が -X 5 と -x に対応している場合に限ります。実装によってオプションが異なるため、まず nc -h で対応状況を調べ、利用できない場合は対応するプロキシ中継ツールや TUN を検討します。設定後は ssh -T [email protected] で認証と接続を試し、必要なら ssh -vT [email protected] の出力から ProxyCommand の起動と接続先を確認します。秘密鍵の内容や認証情報をログとして公開しないようにしてください。
SSH が接続できても、Git の処理が完了するとは限りません。複数のサブモジュール、LFS、追加の配布サービスを使うリポジトリでは、別のホストへの通信が必要になる場合があります。失敗した操作を短い時間で再現し、Clash のライブ接続と SSH の詳細ログを見比べて、実際に現れた接続先だけをルールへ加えます。未知のドメインを推測で大量に追加するより、接続ログに基づいて一つずつ確認する方が、意図しない通信を増やさずに済みます。
Homebrew のダウンロードと依存取得を確認する
Homebrew はフォーミュラの情報取得、ソースやバイナリのダウンロード、依存関係の取得など、複数の段階で通信します。そのため brew update が成功しても、特定のパッケージを入れる段階で止まることがあります。まず、Clash を有効にした状態で brew update を実行し、続いて対象パッケージのインストールを試します。失敗したら、Homebrew のエラー表示にある URL と Clash の接続ログのホスト名を照らし合わせます。実際の配布先はパッケージや時期によって変わるため、固定のホスト一覧だけを頼りにしないことが大切です。
Homebrew が環境変数を参照する構成では、先ほどの http_proxy と https_proxy を設定した同じシェルから実行して比較します。プロキシ URL の形式は Clash のポート種別に合わせてください。HTTP ポートを SOCKS ポートとして指定したり、SOCKS 用の URL を HTTP 接続先へ使ったりすると、名前解決や TLS 接続が失敗することがあります。DNS をどこで解決するかが問題になっている場合は、TUN の DNS 設定とプロキシ方式を分けて検証し、接続先の名前解決が成功しているかも確認します。
Homebrew の実行時だけ値を渡す方法なら、シェル全体の設定を変えずに比較できます。たとえば次のように一時的な環境変数を指定し、成功するかを確認します。これは HTTP ポートが 7890 の例です。別のポートを使っている場合は、Clash の設定に合わせて置き換えてください。
http_proxy=http://127.0.0.1:7890 \
https_proxy=http://127.0.0.1:7890 \
brew update
取得処理が Git によるクローンへ進む場合は、Homebrew の環境変数だけでは足りず、Git 側の設定も影響することがあります。また、すでに環境変数や Git 設定に別のプロキシが残っていると、意図しない経路へ接続することがあります。env | grep -i proxy と Git の設定を確認し、設定元が複数ないか調べてください。Homebrew のキャッシュやダウンロード先に関するエラーを、最初からノード障害と決めつけず、ログに示されたホストへの接続段階を特定することが重要です。
Apple Silicon と Intel の違いだけでなく、macOS のバージョン、社内証明書、セキュリティソフトも結果に影響します。証明書エラーが出た場合、証明書検証を無効にして回避するのではなく、システムの証明書ストアや企業の TLS 検査ポリシーを管理者に確認してください。ダウンロードが途中で切れる場合は、同じコマンドを短時間に繰り返す前に、Clash の接続ログでリトライ先と選択ポリシーを見て、出口の品質やルールの適用順を切り分けます。
疎通テストとトラブル時の見直し順
設定後は、いきなり大きなリポジトリや多数のパッケージを取得するのではなく、小さなテストを順に行います。最初にシェルから HTTPS の接続先を確認し、次に GitHub の HTTPS リモートで参照一覧を取得し、その後 SSH の認証テスト、最後に Homebrew の更新と対象パッケージの取得を試します。各段階で成功・失敗の時刻とエラーを記録し、同時に Clash の接続ログでホスト名、ルール、ポリシー、選ばれたノードを確認してください。これにより、ネットワーク経路の問題と Git の認証問題を混同しにくくなります。
接続ログに対象ホストが出ているのに失敗する場合は、ルール順と選択されたポリシーを確認します。Clash のルールは上から評価されるため、広いルールや既定の MATCH より前に想定外のルールが一致していると、開発者向けのルールへ到達しません。逆にログに通信が出ない場合は、TUN が無効、システムプロキシを参照しないツールで環境変数も未設定、またはコマンドがリモート環境で実行されている可能性があります。まずコマンドを実行しているホストとシェルを確認しましょう。
「接続拒否」はポート番号や Clash の待ち受け状態、「名前解決エラー」は DNS の経路、「タイムアウト」はノード、ルール、ファイアウォール、リモート側の応答遅延をそれぞれ疑います。SSH の認証失敗は、プロキシを通過した後の鍵や GitHub アカウントの問題である場合もあります。エラー文に Permission denied (publickey) と出るなら、接続経路だけを変更し続けず、SSH エージェント、鍵の登録、対象ホスト名を確認してください。TLS エラーでは、時計のずれや証明書チェーン、企業の検査機器が関係することもあります。
設定の変更は一度に一つだけ行い、成功した状態を記録してから次へ進みます。TUN、環境変数、Git の恒久設定を同時に追加すると、どの変更が効いたのか分かりにくくなり、元に戻す作業も複雑になります。不要になった一時設定はシェルを閉じるか unset で解除し、Git の設定を使った場合は設定元を確認してから削除します。会社や学校の端末では、ネットワークポリシーや管理者の指示を優先し、許可されていない経路変更を行わないでください。
開発用プロキシの設定方法は、アプリごとに指定場所が異なる単機能の VPN クライアントでは、Git の HTTPS、SSH、Homebrew の違いまで一つのログで追いにくいことがあります。一方、Clash V.CORE ならルールと接続ログを見ながら、TUN とツール別プロキシを段階的に検証し、どの通信がどのポリシーを通ったかを整理できます。設定を自分の開発環境に合わせて試したい方は、Clash V.CORE をダウンロードして、まず小さな接続テストから始めてみてください。