開発者向けClash設定：Git・SSH・Homebrewを快適に使う方法

ブラウザは動くのに Git・SSH・Homebrew だけ遅い理由

macOS や Linux のブラウザでウェブサイトを開けているのに、ターミナルから実行した Git、SSH、Homebrew だけが遅い、またはタイムアウトする現象は珍しくありません。主な理由は、ブラウザが OS のシステムプロキシを参照しやすい一方で、CLI ツールはシェルの環境変数、Git 独自の設定、SSH の設定、プロセスごとのネットワーク名前空間を使うからです。Clash の画面で「システムプロキシ」を有効にしても、ターミナルが自動的に同じ経路へ移るとは限りません。

たとえば GitHub のウェブ画面は問題なく表示できても、git clone が止まる場合があります。このときブラウザは HTTPS プロキシを利用しているのに、Git は直接接続している可能性があります。SSH の場合はさらに別の経路です。[email protected]:owner/repository.git の形式は通常 HTTPS ではなく SSH プロトコルを使うため、HTTP_PROXY や HTTPS_PROXY を設定しただけでは解決しません。Homebrew も、Formula の情報、GitHub 上のリポジトリ、バイナリボトルの CDN など複数のホストへ接続します。

したがって、最初から「Clash のノードが悪い」と決めつけるより、どのツールが、どのプロトコルで、どのホストへ接続し、どの設定を継承しているかを分けて確認するのが近道です。接続ログには同じ GitHub 関連通信でも、github.com、api.github.com、objects.githubusercontent.com、リリース用 CDN などが別々に現れることがあります。ひとつのドメインだけを許可しても、clone や更新全体が成功するとは限りません。

開発環境ではシステムプロキシと TUN をどう選ぶか

開発用 Mac で最初に試すべき構成は、Clash の mixed-port を確認し、システムプロキシを有効にしたうえで、ターミナルへ明示的に環境変数を渡す方法です。この構成は影響範囲が狭く、通常のブラウザや Git HTTPS のようなプロキシ対応アプリを確認しやすいという利点があります。Clash Verge、Clash Verge Rev、Mihomo 系クライアントでは表示名が多少異なりますが、確認する項目は「HTTP ポート」「SOCKS ポート」「mixed-port」「システムプロキシ」の四つです。

まずアプリの設定画面または接続設定で、Clash が待ち受けているポートを確認します。例として mixed-port が 7890 なら、現在のシェルだけで次のように指定できます。実際のポート番号は手元の画面に合わせてください。

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:7890
export NO_PROXY=localhost,127.0.0.1,::1

ただし、HTTP プロキシと SOCKS プロキシを同時に設定すると、ツールによって優先順位が異なることがあります。Git HTTPS を中心に確認する段階では HTTP_PROXY と HTTPS_PROXY だけを使い、SSH や特殊な CLI では別の方法を検証する方が結果を読みやすくなります。設定後は env | grep -i proxy で値を確認し、誤った古いポート番号が残っていないか確認してください。

TUN モードは、アプリがプロキシ環境変数を理解しない場合や、開発ツール、コンテナ、サブプロセスの通信をまとめて捕捉したい場合に便利です。一方で、仮想インターフェース、DNS、Docker、別 VPN、企業のセキュリティソフトが重なると、原因の境界が見えにくくなります。初回は TUN とシステムプロキシを同時に有効化せず、通常プロキシで確認してから TUN を試すと、経路の変化を追跡できます。

Git HTTPS：clone・fetch・push を同じ条件で確認する

GitHub を HTTPS URL で利用する場合、Git は環境変数だけでなく、独自の設定ファイルに保存されたプロキシ設定も参照します。まず現在の設定を確認します。

git config --global --get http.proxy
git config --global --get https.proxy
git config --show-origin --get-regexp 'http\..*proxy|https\..*proxy'

古いプロキシや存在しないローカルポートが残っていると、Clash を起動しているのに Git だけ接続できない状態になります。不要な設定が見つかった場合は、削除して環境変数へ統一するか、現在の mixed-port に合わせて更新します。会社の Git サーバーや LAN 内のリポジトリまで外部プロキシへ送る必要はないため、社内ドメインやローカルアドレスには NO_PROXY、または Git の noProxy 設定を検討します。

接続確認には、実際に大量の履歴を取得する clone より、まずリモート参照だけを取得する git ls-remote が適しています。認証情報を入力する前に、名前解決と TLS 接続が成功するかを短時間で確認できます。

git ls-remote https://github.com/example/project.git
git -c http.version=HTTP/1.1 ls-remote https://github.com/example/project.git

二つ目だけ成功する場合は、Clash のノードや GitHub 側だけでなく、HTTP/2、TLS 中継、ネットワーク経路の相性を疑います。ただし常に HTTP/1.1 を固定するのが正解とは限りません。まず一時的な比較に使い、接続ログで再現性を確認してください。git clone は成功するのに push だけ失敗する場合は、認証トークン、リモート URL、リポジトリ権限をネットワーク問題と分けて確認します。

SSH 接続：ProxyCommand と TUN を混同しない

SSH 形式の Git リモートは、HTTPS 用のプロキシ変数を設定しても自動的にはプロキシを通りません。ssh -T [email protected] が失敗する場合、まず SSH 自体がどのポートへ接続しているかを確認します。標準の SSH は通常 TCP 22 番ポートを使用しますが、ネットワークによっては 22 番が制限されているため、GitHub が提供する SSH over 443 を検討できる場合があります。利用できる接続方法や組織のポリシーは、必ず GitHub と管理者の公式情報に合わせてください。

macOS の OpenSSH では、~/.ssh/config にホスト単位の設定を記述できます。Clash の mixed-port が HTTP プロキシとして待ち受けている場合、SSH がそのまま HTTP プロキシを理解するわけではないため、単純に ProxyCommand へ HTTP URL を書いても動作しません。HTTP CONNECT に対応した補助コマンドを使う構成、SOCKS5 に対応した既存のツールを使う構成、または Clash の TUN で SSH を捕捉する構成を分けて考える必要があります。

Host github.com
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

まずは上のような最小設定で直接の SSH 認証が成立するかを確認し、その後に経路を追加します。詳細ログは次のコマンドで取得できます。

ssh -Tv [email protected]
ssh -T [email protected]

ログに秘密鍵の内容が表示されるわけではありませんが、ユーザー名、接続先、認証方式、失敗理由が含まれることがあります。第三者へ共有する場合は、ホスト名やユーザー名、ローカルパス、組織名を必要に応じて伏せてください。Permission denied はネットワーク障害ではなく、公開鍵未登録、agent 未起動、使用鍵の不一致である可能性があります。一方、接続先へ到達する前に timeout になる場合は、Clash のライブ接続、TUN の捕捉状態、22 番または 443 番への経路を確認します。

Homebrew：registry、GitHub、ボトル CDN を分けて考える

Homebrew の更新が止まるとき、単一の「Homebrew サーバー」を直せばよいとは限りません。brew update は Homebrew の Git リポジトリや API、Formula 情報を取得し、brew install はさらに GitHub Releases やバイナリボトルの CDN へ接続することがあります。Apple Silicon と Intel Mac では既定のインストール場所や一部の配布物が異なるため、アーキテクチャも合わせて確認します。

最初に次の情報を保存すると、環境差を説明しやすくなります。

brew config
brew doctor
brew --prefix
uname -m

brew config には macOS、CPU アーキテクチャ、Git、HTTP プロキシに関する情報が表示されます。出力を公開する前に、ユーザー名や社内パスが含まれていないか確認してください。brew doctor の警告はすべてネットワーク障害を意味するわけではありませんが、壊れたリンク、古い Command Line Tools、権限問題を先に除外できます。

Homebrew 用のプロキシを環境変数で与える場合は、同じシェルで brew update を実行し、Clash の接続ログに実際のホストが現れるか見ます。GitHub の画面を開いただけでは、Homebrew が正常に通った証拠にはなりません。更新メタデータは成功するのにボトル取得だけ遅い場合、GitHub のオブジェクト配信や CDN が別の出口へ割り当てられている可能性があります。

ルールを作るときは、観測したホストをすべて無差別に一つの大きなルールへ追加するのではなく、開発ツール用のポリシーグループへ段階的にまとめます。たとえば GitHub のウェブ閲覧、Git のリポジトリ転送、Homebrew の配布 CDN は同じポリシーを共有できる場合がありますが、速度と安定性を比較したうえで決めるべきです。広すぎる DOMAIN-SUFFIX,github.com だけに頼ると、実際の配布先や関連 CDN が MATCH へ流れ、問題の再現条件が見えなくなることがあります。

失敗時の確認順序と長期運用のコツ

実務では、次の順序で確認すると設定を必要以上に複雑化せずに済みます。第一に Clash が起動しており、mixed-port または SOCKS ポートが LISTEN していることを確認します。第二に、対象シェルの HTTP_PROXY、HTTPS_PROXY、ALL_PROXY、NO_PROXY を確認します。第三に、Git のグローバル設定と SSH のホスト設定を確認します。第四に curl、git ls-remote、ssh -T、brew update を個別に実行し、接続ログのホスト名とルール名を記録します。

1. ブラウザではなく端末を基準にする：問題が起きている同じユーザー、同じシェル、同じネットワークでテストします。
2. 一度に一つだけ変更する：TUN、環境変数、Git proxy、SSH 設定を同時に変えると、成功しても原因が分かりません。
3. ルールの順番を確認する：広い GEOIP、広告ブロック、直結ルール、最後の MATCH が開発者向けホストより上にないか確認します。
4. 成功条件を記録する：利用したモード、ポート、ノード、コマンド、時刻をメモし、ノード変更後にも比較できるようにします。
5. 秘密情報を分離する：トークン、秘密鍵、購読 URL、環境変数の値はログやリポジトリへ保存しません。

シェル起動時にプロキシを常時 export する場合は、ローカル開発、社内サーバー、CI、コンテナへの影響を考慮してください。すべての通信を固定的にプロキシへ送るより、必要なシェルだけで有効化する関数や短いスクリプトを用意し、作業終了時に解除できる方が安全です。Docker や Dev Container を利用する場合も、ホストの環境変数がコンテナへ自動継承されるとは限りません。コンテナ内部から見た 127.0.0.1 はホストと異なるため、ポートを公開する構成ではアドレスの意味まで確認してください。

小さな接続テストを定期的に実行するのも有効です。たとえば、リポジトリのメタデータ取得、SSH の認証確認、Homebrew の更新確認を別々に記録すれば、「GitHub 全体が落ちた」のか「ボトル CDN だけ遅い」のかを判断できます。Clash の設定は購読更新で上書きされることがあるため、自分用のルールやプロキシグループは管理可能なオーバーライド領域へ分離し、変更前後の YAML を比較できる状態にしておくと、翌日の再発にも対応しやすくなります。

開発者向けの運用では、単純なシステムプロキシだけで済む環境もあれば、SSH、コンテナ、IDE のサブプロセスまで扱うため TUN が必要な環境もあります。ClashX 系の軽量クライアントは常駐と切り替えが手軽な一方、詳細なルール編集や Mihomo の高度な機能を画面で管理しにくいことがあります。逆に個別の環境変数だけに頼る方法は透明性が高い反面、設定漏れが起きやすく、SSH や Homebrew の複数 CDN まで一貫して扱うには手作業が増えます。開発用途で必要なシステムプロキシ、TUN、ルールログ、プロファイル管理を一つの作業面で確認できる Clash V.CORE なら、今回の切り分け手順を再利用しやすくなります。自分の OS と利用規約に合う構成を確認したうえで、必要ならClash V.CORE をダウンロードして、まずは Git HTTPS の短いテストから始めてください。