はじめに
開発者にとって、ネットワークの不調は単なる閲覧速度の問題ではありません。GitHub からリポジトリを取得できない、SSH で push すると接続がタイムアウトする、Homebrew の更新やパッケージのインストールが途中で止まるといった障害は、作業時間とチームの生産性に直接影響します。特に企業ネットワーク、学内ネットワーク、海外サービスへの経路が不安定な環境では、ブラウザーだけが動作していても開発ツールの通信だけが失敗することがあります。
Clash を開発環境に導入すると、アプリケーションごと、またはドメインごとに通信経路を分けられます。通常の国内サービスは DIRECT のまま維持し、GitHub やパッケージレジストリなど必要な通信だけをプロキシへ送る構成にすれば、余計な遅延を避けながら接続の安定性を高められます。本記事では、Clash Verge Rev や Mihomo を中心に、モードの選び方、ターミナルへの反映、Git・SSH・Homebrew の確認方法を順番に解説します。
この記事のゴール
開発用通信だけを適切な経路へ振り分け、どこで失敗しているのかをコマンドで切り分けられる状態を作ります。
1Git・SSH・Homebrewの通信を理解する
最初に確認したいのは、すべての開発ツールが同じ方法で通信しているわけではないという点です。Git の HTTPS 接続は通常、OS のプロキシ設定や環境変数を利用できます。一方、Git の SSH 接続は独立した TCP 通信であり、ブラウザーのプロキシ設定を有効にしただけでは経路が変わらない場合があります。Homebrew も、Formula の取得、GitHub 上のリポジトリへのアクセス、バイナリやソースアーカイブのダウンロードなど、複数の接続を行います。
- Git over HTTPS：
https://github.com/...を使う方式です。HTTP プロキシとの相性がよく、まず試しやすい接続方法です。 - Git over SSH：
[email protected]:owner/repository.gitの形式です。一般的には TCP ポート22を使うため、プロキシの扱いを別途設定します。 - Homebrew： GitHub、各プロジェクトの配布サーバー、API エンドポイントなどへ接続します。単一のドメインだけ許可しても、処理全体が完了するとは限りません。
- コンテナやSDK： Docker、npm、PyPI、RubyGems、Cargo なども、それぞれ独自のプロキシ変数や証明書設定を持つことがあります。
したがって、「Clashをオンにしたのに Git が動かない」という場合は、ノードの品質だけでなく、使用しているプロトコル、ポート、環境変数、ルールの順序を確認する必要があります。Clash のログ画面で実際の宛先と採用されたルールを見ると、問題の場所をかなり早く特定できます。
2Clashのモードとルールを整える
開発用途では、まず Rule モードを選ぶのが基本です。Global モードはすべての通信を同じプロキシグループへ送るため、テスト時には便利ですが、社内サイト、ローカル開発サーバー、プライベートレジストリまで経由してしまう可能性があります。Rule モードなら、必要な宛先だけを指定でき、通常の通信への影響を抑えられます。
プロファイルのプロキシグループ名に合わせて、以下のようなルールを追加します。ここではグループ名を Developer としています。実際の設定では、利用中のプロファイルに存在する名前へ置き換えてください。
ルールは上から順に評価されます。社内ドメインやローカルネットワークを先に DIRECT とし、その後に海外の開発サービスを Developer へ送る構成が扱いやすいでしょう。ただし、サブスクリプションが最後に追加するルールによって上書きする場合があるため、Clash Verge Rev の設定画面で生成後の最終ルールを確認してください。
モード選択のポイント
通常運用は Rule、原因調査は一時的に Global、ローカルサービスを保護したい場合は Rule と明示的な DIRECT ルールを使い分けます。Global を常用すると、社内Gitやデータベースへの接続に影響することがあります。
3ターミナルへプロキシを反映する
System Proxy を有効にしても、ターミナル上のすべてのコマンドが自動的にその設定を利用するとは限りません。macOS や Linux のシェル、Windows の PowerShell では、環境変数を明示する方法が最も分かりやすく、ツールごとの差も確認しやすくなります。Clash の混合ポートが 7890 である場合の例を示します。
- Clash Verge Rev の「Settings」または「General」で、HTTP と SOCKS の混合ポートを確認します。
- 使用中のシェル設定ファイル、たとえば
~/.zshrcまたは~/.bashrcを開きます。 - 以下を追加し、ポート番号を実際の値に合わせます。
設定を保存したら source ~/.zshrc を実行します。社内ネットワークやローカル開発環境を直接接続したい場合は、NO_PROXY に社内ドメインやプライベートIP範囲を追加してください。
PowerShell では、現在のセッションだけに設定する場合、次のコマンドを実行します。
Git の設定を別途確認するには、git config --global --get http.proxy を実行します。古いプロキシが残っている場合は、git config --global --unset http.proxy と git config --global --unset https.proxy で削除してから、環境変数方式に統一すると混乱を避けられます。
4GitとSSHを接続確認する
HTTPS で GitHub を利用する場合は、まず接続先を確認します。次のコマンドで名前解決、TLS 接続、Git の認証を段階的に切り分けられます。
curl が成功しても git ls-remote が失敗する場合は、Git 独自の設定、認証情報、または証明書の問題が疑われます。反対に、両方ともタイムアウトする場合は、Clash のログで github.com がどのグループへ送られているかを確認してください。
SSHポートを設定する
SSH は通常ポート 22 を使用します。ネットワーク側でこのポートが遮断されている場合、GitHub が提供する SSH over HTTPS の入口を試す方法があります。~/.ssh/config に次の設定を追加します。
設定後は ssh -T [email protected] を実行します。初回はホスト鍵の確認が表示されるため、接続先が正しいことを確認してから承認してください。成功すれば、GitHub のユーザー名に関する認証メッセージが表示されます。認証に失敗する場合は、ssh-add -l で鍵が読み込まれているか、GitHub アカウントに公開鍵を登録しているかを確認します。
SSH設定時の注意
SSH の通信を無理にHTTPプロキシへ通す設定は、クライアントやOSによって挙動が異なります。まずはポート443の方式、またはClashのTUNモードでTCP通信を処理する方法を優先し、複雑な外部ラッパーは最後に検討してください。
5Homebrewと依存パッケージを検証する
Homebrew の問題は、「brew コマンドが見つからない」「更新だけが遅い」「特定のアーカイブ取得で止まる」など、症状によって対処が異なります。まずは診断結果とバージョンを記録しましょう。
macOS や Linux で環境変数を設定している場合、env | grep -i proxy で意図した値が入っているか確認します。Homebrew の処理がプロキシ経由で進まない場合は、Clash のログに GitHub 以外の配布ドメインが表示されていないかを見ます。Formula の更新は GitHub だけで完結せず、プロジェクトのリリースサーバーや CDN へ移動することがあるためです。
- 更新が開始されない： DNS 解決、Clash の接続状態、プロキシポートの誤りを確認します。
- 途中で切断される： ノードを変更し、ログのエラーがタイムアウトかTLSエラーかを確認します。
- 証明書エラーが出る： システム時刻、CA証明書、HTTPS通信を検査するセキュリティソフトの有無を確認します。
- 特定パッケージだけ失敗する： 取得先のドメインをログから特定し、必要に応じてルールへ追加します。
npm、pip、RubyGems、Cargo などを使う場合も、同じ考え方で検証できます。たとえば npm は npm config get proxy、pip は pip config list、Cargo は ~/.cargo/config.toml を確認します。複数の設定箇所に異なるプロキシが残っていると、Clashを切り替えた後も古いポートへ接続し続けることがあります。
安全に運用するために
認証付きプロキシのパスワードをシェル履歴、Gitの設定、設定ファイルへ平文で保存しないでください。共有端末では環境変数や資格情報ヘルパーの扱いにも注意し、不要になった接続設定は削除しましょう。
失敗時の確認チェックリスト
設定を変更した後は、一度にすべてを試すのではなく、下記の順番で確認すると原因を追いやすくなります。最初に Clash が起動し、選択したプロファイルが有効で、プロキシグループに利用可能なノードがあることを確認します。次に、curl -I https://github.com で基本的なHTTPS接続を調べます。
- Clash のログで対象ドメイン、接続方式、採用ルール、使用ノードを確認する。
- ターミナルの
HTTP_PROXY、HTTPS_PROXY、ALL_PROXYが想定したポートを指しているか確認する。 - Git に古い
http.proxyやhttps.proxyが残っていないか確認する。 - HTTPS と SSH を分けて試し、認証の問題と経路の問題を切り分ける。
- Homebrew やパッケージマネージャーの取得先をログから確認し、必要なルールだけを追加する。
- ノードを変更して同じコマンドを再実行し、特定ノードだけの障害かを判定する。
開発環境では、常に最も強いモードを選ぶことよりも、通信を観測できることが重要です。Clash のログ、Git の詳細出力、Homebrew の診断結果を組み合わせれば、「接続できない」という曖昧な症状を、DNS、TCP、TLS、認証、ルールのどの段階で止まったのかへ分解できます。設定を変更した際は、動作したコマンドと使用したノードを簡単に記録しておくと、チーム内での再現や復旧も容易になります。
Clash は開発者の通信を自動的に改善する魔法のツールではありません。しかし、Rule モード、適切なターミナル設定、SSHのポート設計、そしてログを使った検証を組み合わせれば、Git、Homebrew、各種パッケージ管理ツールを安定して運用するための強力な基盤になります。