GitHub・npm がターミナルでタイムアウトする：Clash と HTTP_PROXY・Git 代理で三 OS を揃える
Clash を起動し、ブラウザでは GitHub が開けるのに、git clone や npm install、curl だけが固まる——よくある切り分けの出発点は「ターミナルがシステムプロキシを自動では読まない」ことです。本稿では HTTP_PROXY／HTTPS_PROXY／ALL_PROXY と Git の http.proxy を、Windows・macOS・Linux それぞれで実務的にそろえる手順を整理します。WSL2 から Windows 上の Clash へ届かない場合は、別稿のミラー／ポート転送と組み合わせてください。
こんな症状なら本文の対象です
ブラウザや GUI クライアントは問題ないのに、シェルだけが Connection timed out、TLS handshake timeout、あるいは極端に遅いまま失敗する。企業ネットではプロキシ必須なのに、自宅では直結が通るはずの registry.npmjs.org や github.com が CLI からだけ届かない——このギャップは、多くの場合 環境変数の欠如か Git 単体の設定不足で説明できます。まず「Clash のローカル HTTP 出口がどのポートで待っているか」を確認し、同じ値をシェルと Git に渡すのが最短です。
- git：HTTPS リモートは libcurl 経由のため、環境変数と
http.proxyの両方を意識すると安全。 - npm / yarn / pnpm：多くは Node の HTTP スタックが
HTTP_PROXY系を参照。社内ミラーがある場合は.npmrcも別途。 - curl / wget：典型的に大文字の
HTTP_PROXYを読む。小文字のみの環境では効かない実装もある。
なぜ「システム代理オン」だけでは足りないのか
macOS や Windows の「システムのプロキシ設定」は、主要ブラウザや一部ネイティブ API には効きますが、ターミナル内のすべてのプロセスが追従するとは限りません。特に OpenSSH や 古いビルドの Git、独自 TLS を持つツールは、明示的な http_proxy 系かツール固有の設定がないと直結を試み続けます。Clash 側は mixed-port で HTTP と SOCKS を同居させる構成が一般的で、HTTP CONNECT をそのポートに向ければ多くの CLI が一度で収まります。
整理のコツ
「ブラウザ用のシステム代理」と「シェル用の環境変数」は別レイヤーと考える。Clash が 127.0.0.1:7890 で HTTP を待っているなら、シェルにも同じ URL を書く。ポートが違うクライアントでは必ず設定画面の値に合わせる。
Clash 側で先に確認すること
設定 YAML または GUI のポート欄で mixed-port（または HTTP 専用ポート）を確認します。多くのテンプレートは 7890 ですが、衝突回避で変えている場合があります。以下の説明では例として http://127.0.0.1:7890 を使いますが、実機の値に置き換えてください。SOCKS のみ別ポート（例：7891）の場合、ALL_PROXY=socks5://127.0.0.1:7891 のように分ける選択肢もあります。HTTP と SOCKS のどちらを CLI に渡すかは、ツールの実装差があるため、まずは mixed の HTTP 側で試すとトラブルが少ないです。
セキュリティ
社外にプロキシ URL を共有したり、認証付き出口を平文で書き残さない。端末を他人と共有する場合、シェル履歴と git config --global の内容に注意する。
HTTP_PROXY／HTTPS_PROXY／ALL_PROXY／NO_PROXY
POSIX 系では次の形が通例です（例示ポートは実環境に合わせる）。
# Example — replace port with your Clash mixed-port
export HTTP_PROXY="http://127.0.0.1:7890"
export HTTPS_PROXY="http://127.0.0.1:7890"
export ALL_PROXY="http://127.0.0.1:7890"
export NO_PROXY="localhost,127.0.0.1,::1"
NO_PROXY（または no_proxy）に社内イントラのドメインを足すと、npm の tarball 取得だけ社内ミラーへ、GitHub だけ出口へ、といった分岐がしやすくなります。カンマ区切りの慣習は環境で揺れるため、効かないときは公式ドキュメントの区切り文字を確認してください。
| 変数 | 役割 |
|---|---|
HTTP_PROXY |
平文 HTTP と、多くの HTTPS クライアントのトンネル起点 |
HTTPS_PROXY |
HTTPS を明示的に分けたい実装向け（未設定なら HTTP_PROXY にフォールバックすることが多い） |
ALL_PROXY |
スキーム横断で使うツール向け。SOCKS を載せるときに効くことがある |
NO_PROXY |
ローカルホストやイントラを直結させ、ループや遅延を防ぐ |
Windows（PowerShell・CMD・Git Bash）
現在のセッションだけなら PowerShell で次のように設定できます。
# Current session only (PowerShell)
$env:HTTP_PROXY="http://127.0.0.1:7890"
$env:HTTPS_PROXY="http://127.0.0.1:7890"
$env:ALL_PROXY="http://127.0.0.1:7890"
恒久的にユーザ環境へ入れるなら setx を使う方法もありますが、既存のターミナルには反映されない点に注意してください。GUI ターミナル（Windows Terminal）を開き直すか、新しいログオンが必要です。複数バージョンの Git for Windows が混在している環境では、どの git.exe が PATH に乗っているかも併せて確認すると、設定が食い違うのを防げます。
macOS・Linux（bash／zsh／fish）
対話シェルの起動ファイル（~/.zshrc、~/.bashrc など）に上記の export を追記する方法が一般的です。CI やエディタ統合ターミナルはログインシェルではないことがあるため、追記後に source ~/.zshrc で読み直すか、タブを閉じて開き直してください。Linux の headless サーバで Clash を同機に載せている場合は、systemd 常駐の稿と合わせ、ローカルループバックへ向けるだけで十分なことが多いです。
動作確認の順序
curl -I https://github.comで TLS が完了するか見る。- 続けて
git ls-remote https://github.com/...を試す。 - 最後に
npm pingや実プロジェクトのnpm install。
Git 専用：http.proxy と https.proxy
環境変数だけでも多くのケースは通りますが、HTTPS クローンが不安定なときは Git の設定を明示します。
git config --global http.proxy http://127.0.0.1:7890
git config --global https.proxy http://127.0.0.1:7890
解除するときは git config --global --unset http.proxy などで戻します。SSH リモート（[email protected]:）は別経路のため、HTTPS の遅延対策とは別問題です。SSH を使うなら ~/.ssh/config の ProxyCommand や nc 経由のトンネルが必要になる場合がありますが、本稿の主眼は HTTPS と npm です。
npm・yarn・pnpm
多くの環境では前述の環境変数で npm が追従します。うまくいかない場合は npm config set proxy／https-proxy を検討してください。社内レジストリへ切り替えているなら registry= 行と矛盾がないかも確認します。モノレポで pnpm のストアがローカルループバックに乗るケースでは、NO_PROXY に開発用ホスト名を足すとビルドが安定することがあります。
WSL2 と本稿の棲み分け
WSL2 のゲストから見た 127.0.0.1 は Linux 自身であり、Windows 側の Clash とは別物です。ミラードネットワークやホスト IP 経由でポートを指す必要があるため、詳細は WSL2 と Clash の稿へ。本稿の「環境変数の形」はそのまま使えますが、プロキシ URL のホスト部分だけを Windows の実アドレスに差し替えてください。
まだ遅い／失敗するとき
変数を入れても TLS が遅い場合は、ノードの地理的距離や輻輳より先に、DNS と fake-ip の整合を疑います。DNS・fake-ip の稿の手順で、解決結果と実接続先が食い違っていないかを見てください。また ルールモード で GitHub 向けポリシーが意図したグループに落ちているか、Clash のログで確認すると、出口の取り違えを早く潰せます。開発者向けの広いドメイン分流は Claude Code／MCP の稿とも補完関係にあります。
- プロキシを外して比較試験し、症状が環境変数依存かを切り分ける。
- 企業プロキシの PAC と Clash の二重化でループしていないか。
- IPv6 だけ別経路になっていないか（一時的に IPv4 優先で試す等）。
よくある質問
環境変数は効いているのに Git だけ失敗する
git config --global http.proxy を追加するか、別の git.exe が動いていないか確認してください。
SOCKS しか開いていない
ALL_PROXY=socks5://127.0.0.1:7891 のようにし、HTTP 用ポートと混同しないでください。ツールによっては SOCKS5h（リモート DNS）が必要です。
作業が終わったら必ず外す？
常時開発なら残しても構いませんが、イントラへのアクセスが遅くなるなら NO_PROXY を厚くするか、プロジェクト単位でシェルプロファイルを切り替えると安全です。
チェックリスト
- Clash の mixed-port（または HTTP ポート）を確認する。
- シェルに
HTTP_PROXY／HTTPS_PROXY／必要ならALL_PROXYを設定する。 NO_PROXYにローカルと社内ドメインを入れる。- Git に
http.proxy／https.proxyを追加し、HTTPS クローンを再試行する。 curlとnpmで順に検証し、ルールログで出口を確認する。
まとめ
Clash を「ブラウザ専用」にせず CLI まで広げる鍵は、ローカル HTTP 出口への明示的な橋渡しです。OS ごとの書き方は違っても、渡す URL の形は同じです。まず小さく curl で成功を確認し、Git とパッケージマネージャへ広げていくと、タイムアウトの原因がネットワークか設定かを素早く切り分けられます。