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

ブラウザではGitHubや各種開発サービスを開けるのに、ターミナルでgit cloneを実行するとタイムアウトする、SSH接続だけが失敗する、Homebrewのダウンロードが途中で止まる。この現象は、Clashが動作していないのではなく、アプリごとにプロキシの扱いが異なることが原因である場合が多いです。ブラウザはシステムプロキシを自動利用できますが、Git、SSH、Homebrewはそれぞれ独立した設定や環境変数を参照します。

この記事では、開発者向けにClashとGit・SSH・Homebrewを連携させる方法を整理します。HTTPS経由のGit操作、SSH経由のGit操作、Homebrewのリポジトリ取得とバイナリダウンロードを分けて考え、必要な通信だけをプロキシへ送る構成を作ります。Clash Verge、Clash Verge Rev、Mihomoなど、ローカルのHTTPポートとSOCKSポートを提供するクライアントであれば基本的な考え方は共通です。

開発者向け通信がブラウザと異なる理由

ブラウザでページを表示できるからといって、ターミナル上のすべての通信が同じ経路を使うとは限りません。ブラウザはOSのプロキシ設定、PACファイル、拡張機能、あるいはClashのシステムプロキシ連携を利用します。一方、Gitはhttp.proxyやhttps.proxy、環境変数を参照し、SSHは通常それらを無視して宛先の22番ポートへ直接接続します。

さらに、Homebrewは単一の通信だけで構成されていません。FormulaやCaskの情報を取得するGit通信、ソースコードやリリースファイルを取得するHTTPS通信、ボトルをダウンロードするCDN通信などが組み合わさります。そのため、Gitだけを設定してもHomebrewのインストールが成功するとは限りません。

• Git over HTTPS：HTTPまたはHTTPSプロキシ設定を利用できるため、比較的簡単にClashへ接続できます。
• Git over SSH：標準SSHはHTTPプロキシを理解しないため、SOCKS5またはCONNECT方式の中継設定が必要です。
• Homebrew：Gitの設定、シェル環境変数、Homebrew固有のダウンロード設定を確認する必要があります。
• コンテナやIDE：ホスト側でClashを設定しても、Dockerコンテナやリモート開発環境へ自動的には引き継がれません。

Clashのポートと動作モードを確認する

まずClash側のポートを確認します。Clash VergeやMihomoでは、HTTPプロキシ、SOCKS5プロキシ、混合ポート、外部コントローラーがそれぞれ別の項目です。開発ツールとの互換性を重視するなら、HTTPとSOCKS5の両方を利用できる構成が扱いやすいでしょう。

# 代表的なローカルポート例。実際の値はクライアントに合わせて変更
HTTP proxy: 127.0.0.1:7890
SOCKS5 proxy: 127.0.0.1:7891
Mixed port: 127.0.0.1:7893

# HTTPプロキシの疎通確認
curl -I -x http://127.0.0.1:7890 https://github.com

# SOCKS5プロキシの疎通確認
curl -I --proxy socks5h://127.0.0.1:7891 https://github.com

SOCKS5の確認では、socks5h://を使うことが重要です。末尾のhは、DNS解決もSOCKSプロキシ側で行うことを意味します。socks5://だけを指定すると、DNSだけがローカル環境から直接送信され、名前解決に失敗したり、意図しないDNSリークが発生したりすることがあります。

Clashの動作モードは、開発用途では通常「ルール」モードが扱いやすいです。GitHub、GitLab、Homebrewの配布元などをプロキシへ送るルールを明示し、社内Gitサーバーやローカルネットワークは直接接続にできます。すべての通信をプロキシする「グローバル」モードは切り分けには便利ですが、社内システムやパッケージミラーまで遠回りする可能性があります。

rules:
  # 会社や自宅LANの内部ドメインは先に直接接続
  - DOMAIN-SUFFIX,internal.example,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve

  # 開発サービスはプロキシグループへ
  - DOMAIN-SUFFIX,github.com,PROXY
  - DOMAIN-SUFFIX,githubusercontent.com,PROXY
  - DOMAIN-SUFFIX,gitlab.com,PROXY
  - DOMAIN-SUFFIX,brew.sh,PROXY

Git over HTTPSを設定する

GitHubのリポジトリをHTTPS URLで操作する場合、GitはHTTPプロキシを利用できます。まず一時的に環境変数を設定して動作を確認し、問題がなければGitのグローバル設定へ移す方法がおすすめです。環境変数は現在のターミナルやスクリプトだけに影響するため、設定ミスの範囲を限定できます。

# macOS / Linux / zsh / bash
export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export NO_PROXY=localhost,127.0.0.1,.local,internal.example

# GitHubへの接続を確認
git ls-remote https://github.com/example/project.git

# Windows PowerShell
$env:HTTP_PROXY="http://127.0.0.1:7890"
$env:HTTPS_PROXY="http://127.0.0.1:7890"
git ls-remote https://github.com/example/project.git

常にGitへプロキシを適用したい場合は、Gitの設定を使います。URLのスキームごとに設定できるため、HTTPSのGitHubだけを対象にし、社内Gitサーバーは除外することも可能です。

# すべてのHTTP/HTTPS Git通信に適用
git config --global http.proxy http://127.0.0.1:7890
git config --global https.proxy http://127.0.0.1:7890

# GitHubだけに限定する設定
git config --global http.https://github.com.proxy http://127.0.0.1:7890

# 社内Gitをプロキシから除外
git config --global http.https://git.internal.example.proxy ""

# 現在の設定を確認
git config --global --get-regexp 'http.*proxy'

認証エラーとプロキシエラーは見た目が似ているため、切り分けではgit ls-remoteを使うと便利です。接続自体が失敗する場合はプロキシポート、Clashのルール、DNSを確認します。接続後に401や403が返る場合は、トークン、Credential Manager、SSH鍵ではなくHTTPS認証情報の問題である可能性が高いです。

Git over SSHをClash経由にする

[email protected]:owner/repository.gitのようなSSH形式のURLは、通常のHTTPプロキシ設定では中継されません。SSHクライアントは直接TCP接続を試みるため、ネットワーク側で22番ポートが制限されていると、ブラウザやGit HTTPSが使えてもcloneだけが失敗します。

最も扱いやすい方法は、SSHのProxyCommandでローカルのSOCKS5ポートへ接続する構成です。OpenSSHに同梱されるncがSOCKS5をサポートしていない環境では、macOSのHomebrewなどでconnect系のツールを導入する方法もあります。ここではまず、OpenBSD netcatの-X 5オプションが使える環境の例を示します。

# GitHubだけClashのSOCKS5へ接続
Host github.com
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_ed25519
    ProxyCommand nc -x 127.0.0.1:7891 -X 5 %h %p
    ServerAliveInterval 30
    ServerAliveCountMax 3

# GitLabも同じ経路にする場合
Host gitlab.com
    HostName gitlab.com
    User git
    IdentityFile ~/.ssh/id_ed25519
    ProxyCommand nc -x 127.0.0.1:7891 -X 5 %h %p

SSHの接続テストは、Gitコマンドより先に単独で実行します。詳細ログを見ることで、鍵の問題なのか、ProxyCommandの実行失敗なのか、Clash側で接続が拒否されているのかを判別できます。

# 通常のSSH認証テスト
ssh -T [email protected]

# 詳細ログを表示
ssh -vT [email protected]

# 実際のGit操作を確認
git clone [email protected]:owner/repository.git

GitHubのSSHは認証に成功すると、シェルアクセスは提供していないという趣旨のメッセージを返します。これは接続成功を示す正常な応答です。反対に、Connection timed outやkex_exchange_identificationが出る場合は、22番ポートやプロキシ経路を確認します。ネットワークによってはGitHubが提供するSSH over 443を使う方法もあります。

# 22番ポートが利用できない場合のGitHub向け設定
Host github.com
    HostName ssh.github.com
    Port 443
    User git
    IdentityFile ~/.ssh/id_ed25519
    ProxyCommand nc -x 127.0.0.1:7891 -X 5 %h %p

Homebrewの取得とダウンロードを安定させる

Homebrewでは、Git経由の操作とファイルダウンロードを別々に確認します。Formulaの更新やtapの取得に失敗する場合はGitのHTTPS設定が関係し、ボトルの取得に失敗する場合はHOMEBREW_BOTTLE_DOMAIN、HTTP_PROXY、HTTPS_PROXY、またはClashのルールが関係します。

# ~/.zshrc または ~/.bashrc
export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export ALL_PROXY=socks5h://127.0.0.1:7891
export NO_PROXY=localhost,127.0.0.1,.local,internal.example

# 設定反映
source ~/.zshrc

# Homebrewの診断
brew config
brew doctor
brew update

ALL_PROXYは多くのCLIツールで利用されますが、すべてのプログラムが対応しているわけではありません。まずはHTTP_PROXYとHTTPS_PROXYを設定し、必要に応じてALL_PROXYを追加するのが安全です。大文字と小文字の環境変数を別の値にすると、ツールによって挙動が変わるため、混乱する場合は同じ値にそろえます。

# 公式配布元を使う例。ミラーを使う場合は信頼できるURLだけを指定
export HOMEBREW_BOTTLE_DOMAIN=https://ghcr.io/v2/homebrew/core

# 現在の環境を確認
env | grep -E '^(HTTP|HTTPS|ALL|NO)_PROXY|^HOMEBREW_'

# 特定パッケージの取得テスト
brew fetch --verbose wget

Homebrewのミラー設定は便利ですが、ミラーの内容、証明書、更新頻度、運営者を確認してから使用してください。社内ミラーを使う場合は、ClashのルールでそのホストをDIRECTにする必要があることもあります。逆に、ミラーへ到達できない環境で固定すると、公式配布元へ戻しても設定が残っているため、原因が分かりにくくなります。

用途別にプロキシを分ける設計

開発環境では「すべてをプロキシする」よりも、通信先と用途に応じて経路を分ける方が安定します。たとえば、GitHubと外部パッケージレジストリはClashのプロキシグループへ送り、会社のGitLab、VPN内のデータベース、ローカルのコンテナは直接接続します。

• 外部ソースコード：GitHub、GitLab.com、Bitbucketなどはプロキシグループへ送る。
• 外部配布ファイル：GitHub Releases、npm、PyPI、RubyGemsなど、必要なドメインをルールへ追加する。
• 社内サービス：.corp、.internal、VPNのCIDRはDIRECTにする。
• ローカル開発：localhost、127.0.0.1、Dockerのサービス名はプロキシ対象から除外する。
• DNS：内部ドメインを外部DNSへ送らないよう、fake-ip-filterやnameserver-policyを検討する。

IDEの統合ターミナルでだけ動作しない場合は、IDEがシェルの起動ファイルを読み込んでいるかを確認します。GUIから起動したIDEは、ターミナルで設定した環境変数を継承しないことがあります。その場合はIDEのHTTPプロキシ設定、起動時環境、またはシステムプロキシ設定を確認します。

Dockerを使う場合、コンテナ内の127.0.0.1はホストOSではなくコンテナ自身を指します。ホストのClashへ接続するには、Docker Desktopのホスト名、Linuxのブリッジゲートウェイ、あるいはホスト側LANアドレスを利用し、ClashがLAN接続を受け付ける設定になっているかを確認します。外部公開範囲を広げる場合は、強い認証とファイアウォールを必ず併用してください。

接続できないときの診断手順

複数の設定を一度に変更すると原因が分からなくなります。次の順番で、Clash、DNS、プロキシ種別、アプリ設定を一つずつ確認すると効率的です。

1. Clashのプロファイルが有効で、プロキシノードが利用可能か確認します。
2. curl -I -x http://127.0.0.1:7890 https://github.comでHTTPプロキシを確認します。
3. curl -I --proxy socks5h://127.0.0.1:7891 https://github.comでSOCKS5と代理DNSを確認します。
4. Gitの設定と環境変数が別のプロキシを指定していないか確認します。
5. SSHではssh -vT [email protected]を実行し、ProxyCommandが起動しているか確認します。
6. Clashの接続画面で、対象ドメインが表示され、想定したルールとプロキシグループに一致しているか確認します。
7. Homebrewではbrew config、brew doctor、brew fetch --verboseを個別に実行します。

よくある失敗は、GitにHTTPプロキシを指定したままSSH URLを使っているケースです。この設定ではgit clone https://...は動いても、git clone [email protected]:...は直接接続になります。また、SOCKS5設定でsocks5://を使い、DNSだけがローカル経路へ出ているケースもあります。SSHについては~/.ssh/config、Git HTTPSについてはgit config --show-origin --get-regexp 'http.*proxy'を確認すると設定元を特定できます。

# Gitのプロキシ設定を一時的に削除
git config --global --unset http.proxy
git config --global --unset https.proxy

# シェル環境変数を一時解除
unset HTTP_PROXY HTTPS_PROXY ALL_PROXY http_proxy https_proxy all_proxy

# 解除後に設定元を確認
git config --show-origin --get-regexp 'http.*proxy'
env | grep -i proxy

最終的には、普段使う方法を一つに決めると運用が安定します。GitHubのHTTPSを使うならGitのHTTPSプロキシを中心にし、SSHを使うならSSHのProxyCommandを明示します。Homebrewはシェル環境変数と配布元を確認し、社内サービスはNO_PROXYとClashルールの両方で除外します。こうした分離を行えば、ブラウザだけでなく、clone、push、SSHログイン、パッケージ導入まで同じネットワーク方針で管理できます。