ネットワーク実践 開発者向け タグ： ターミナル http_proxy Git npm

npm と Git がまだ直結？macOS と Linux ターミナルで Clash プロキシと環境変数を揃える

Clash のシステムプロキシや TUN を有効にしても、ターミナルからの npm install や git clone、curl だけがタイムアウトする——このパターンは開発現場で非常に多いです。本稿では、環境変数（http_proxy・HTTPS_PROXY・ALL_PROXY）と Git／npm 系の個別設定を、本機の Clash 待受ポートに合わせて順に整える手順を、macOS と Linux の両方を想定して整理します。

読了時間：約16分
Clash 編集部
目次

1. GUI は通るのに CLI が直結する理由

macOS の「ネットワーク」や各種 Clash クライアントが書き込むシステムプロキシは、多くの場合、Safari や Chrome のようなネイティブ GUI アプリには効きます。一方、ターミナルから起動する git や npm、curl、python -m pip などは、OS が自動でプロキシを注入してくれるとは限りません。ライブラリや実装によっては HTTP_PROXY を読むもの、読まないもの、独自の設定ファイルだけを見るものが混在します。

TUN モードを有効にしていれば理論上はカーネルレベルでトラフィックを捕捉できるため、CLI も迂回先に乗るケースは増えます。ただし、ルールで DIRECT になっているドメイン、Fake-IP と実 DNS の食い違い、あるいは特定プロセスだけが別インターフェースを使う状況では、依然として「ブラウザは速いのに git pull だけ遅い」という現象が残ります。そのとき最後の保険になるのが、明示的な環境変数とツール固有のプロキシ設定です。

ヒント：全体像は Clash のドキュメントで押さえつつ、本記事は「ターミナルがローカル Clash の HTTP／SOCKS ポートを確実に指す」ことに絞ります。

2. まず Clash 側のポートを確定する

以降の例では、よくあるデフォルトである 127.0.0.1:7890 をミックスドポート（HTTP と SOCKS が同居する待受）として使う想定で書きます。実際の値は GUI の設定画面か config.yaml の mixed-port／port／socks-port を確認し、自分の環境の数字に置き換えてください。

待受が 127.0.0.1 にだけバインドされているか、0.0.0.0 で LAN に開いているかも重要です。単一マシン上のターミナルなら 127.0.0.1 で十分ですが、コンテナや WSL2 のような別ネットワーク名前空間から接続する場合は、ホスト側 IP が必要になります（Windows ホスト上の Clash と WSL2 の組み合わせは WSL2 向けの記事を参照）。

動作確認として、プロキシをまだ設定していない状態と設定後の状態で次を比較すると切り分けが速いです。

curl -I https://www.google.com --max-time 15

タイムアウトするなら、DNS かルールか、単純にプロキシ未設定の可能性が高いです。

3. シェル環境変数（http_proxy 系）

多くの CLI ツールは、少なくとも次のいずれかを参照します。

  • http_proxy／HTTP_PROXY：HTTP および一部の HTTPS クライアント向け
  • https_proxy／HTTPS_PROXY：HTTPS 向け（実装によっては http の URL を指してもよい）
  • all_proxy／ALL_PROXY：SOCKS など「すべてのスキーム」向け（ライブラリ依存）
  • no_proxy／NO_PROXY：プロキシを使わないホスト一覧（カンマ区切りが一般的）

大文字・小文字の揺れに弱いプログラムがあるため、両方セットしておくとトラブルが減ります。no_proxy には localhost,127.0.0.1,::1 に加え、社内 Git サーバのドメインや .local を入れておくと、不要なループや遅延を避けられます。

HTTP ミックスドポートを指す典型例

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"

SOCKS5 を ALL_PROXY に載せる例

一部ツールは SOCKS のほうが安定します。socks5h:// は名前解決もプロキシ側で行う指定です（ローカル DNS が詰まっているときに有効なことがあります）。

export all_proxy="socks5h://127.0.0.1:7891"
export ALL_PROXY="$all_proxy"

ポート番号は自分の Clash 設定に合わせて変更してください。

4. zsh／bash に永続化する

一時的な試行なら上記の export だけで足ります。毎回ターミナルを開くたびに効かせるには、ログインシェルの起動ファイルに追記します。

  • zsh（macOS のデフォルト）：~/.zshrc
  • bash：対話シェルなら ~/.bashrc、ログインシェル中心なら ~/.bash_profile（環境に応じて source を整理）

追記後は source ~/.zshrc などで読み直すか、ターミナルを開き直します。IDE 内蔵ターミナルは親プロセスの環境を引き継ぐため、IDE ごと再起動しないと反映されないこともあります。

注意：プロキシ URL をシェル履歴や共有マシンの設定ファイルに残すと、社内ポリシー上まずい場合があります。必要なら一時的なエイリアスや、direnv のようにプロジェクト単位で読み込む方法を検討してください。

5. Git 専用の http／https プロキシ

git は環境変数を尊重しますが、リポジトリ単位またはグローバルに http.proxy が別途設定されていると、そちらが優先されたり、意図せず古いプロキシが残っていたりします。まず現状を確認します。

git config --global --get http.proxy
git config --global --get https.proxy
git config --list --show-origin | grep -i proxy

グローバルで Clash のローカルポートへ揃える例です。

git config --global http.proxy  http://127.0.0.1:7890
git config --global https.proxy http://127.0.0.1:7890

SSH で [email protected]:... を使う場合、上記の HTTP プロキシは効きません。その場合は SSH の ProxyCommand や ~/.ssh/config で別途トンネルを張る必要があります。HTTPS クローン（https://github.com/...）であれば本節の設定がそのまま活きます。

プロキシを外したいときは git config --global --unset http.proxy などで削除できます。

6. npm・yarn・pnpm

npm は環境変数 HTTP_PROXY／HTTPS_PROXY を読むため、第 3 節まで整えていれば多くの場面で動きます。それでもレジストリや企業プロキシの組み合わせで失敗する場合は、npm config set proxy と https-proxy を明示します。

npm config set proxy http://127.0.0.1:7890
npm config set https-proxy http://127.0.0.1:7890

設定はユーザーホームの .npmrc に保存されます。npm config delete proxy で元に戻せます。

yarn（v1 系）は ~/.yarnrc の proxy、yarn berry 系はプロジェクト設定や環境変数の扱いが異なるため、公式ドキュメントと併せて確認してください。pnpm も環境変数を尊重しつつ、必要なら .npmrc 互換の指定で揃えるのが現場では扱いやすいです。

GitHub Packages や私有レジストリを併用している場合、registry ごとにホストが分かれるため、no_proxy に社内レジストリだけを入れておく、といった調整が必要になることがあります。

7. macOS での注意点

macOS では、Clash Verge などが システムプロキシ と Network Extension を組み合わせる構成が多く、権限ダイアログやプロファイルの有効化を誤ると「メニューバーは緑なのにターミナルだけ不安定」という状態になり得ます。GUI 側の挙動は macOS の Clash Verge に関する記事で詳しく扱っています。

Terminal.app と iTerm2、VS Code／Cursor の統合ターミナルでは、それぞれログインシェルとして何を起動するかが微妙に異なります。echo $SHELL と echo $0、読み込まれているファイル（~/.zprofile と ~/.zshrc の違いなど）を意識すると、設定が一部のウィンドウにしか効いていない問題を避けられます。

8. Linux での注意点

デスクトップ Linux では、GNOME の「ネットワークプロキシ」設定とターミナル環境が自動同期されないことがあります。サーバー用途ではそもそも GUI プロキシが存在しないため、環境変数か systemd の Drop-in でサービスにプロキシを渡すパターンが一般的です。

Clash 本体を systemd で常駐させる構成は Ubuntu 22.04 での systemd 手順とあわせて読むと、待受ポートとユーザ権限のイメージがつながります。CLI からのトラフィックをローカル 127.0.0.1:7890 に流すだけなら、ファイアウォールで外向きを塞いでいない限り、追加のルーティング変更は不要なことが多いです。

9. TUN と環境変数の関係

TUN が有効で、かつルール上そのトラフィックがプロキシチェーンに乗る設定であれば、環境変数なしでも CLI が通ることがあります。しかし Fake-IP モードとローカルスタブリゾルバ、split DNS、あるいは「プロセス種別で TUN を迂回する」ような例外設定が絡むと、再現性のある明示プロキシのほうが調査しやすいです。

実務では、TUN で全体を安定ルーティングしつつ、問題のあるツールだけ HTTPS_PROXY を足す、というハイブリッド運用もよく見られます。どちらか一方に寄せ切る必要はありません。

10. 切り分け表

症状 よくある原因 確認すること
curl は通るが git だけ失敗 Git 固有の http.proxy が空または別ホスト git config --list、リポジトリローカル設定
環境変数を入れたが npm だけ無視 .npmrc の proxy が古い npm config list、~/.npmrc
HTTPS は失敗、HTTP は成功 MITM 証明書や https_proxy のスキーム不一致 企業プロキシ、git -c http.sslVerify=false は最終手段のみ
一部ターミナルだけ効かない 起動ファイルが読まれていない シェル種別、IDE のシェル統合、login シェルかどうか

これでも原因が特定しにくいときは、Clash のログで該当接続が DIRECT になっていないか、期待するノードに乗っているかを確認すると、ルール側の修正に進みやすくなります。

11. まとめ

ブラウザが快適でも ターミナルだけが直結して失敗するのは、プロキシ情報が OS から CLI に自動伝播しないことが根本原因です。環境変数で http_proxy・HTTPS_PROXY・ALL_PROXY を揃え、Git と npm には必要に応じてツール固有の設定を重ね、待受は常に本機 Clash の実ポートに合わせる——この三段ができれば、多くの「GUI は行けるのに npm i が終わらない」系の悩みは解消に近づきます。

クライアントによっては、ルール編集のしやすさや更新の手間で差が出ます。安定した YAML 管理とログの見やすさのバランスでは、オープンソース系の Clash エコシステムのほうが長時間の開発セッション向きだと感じる人も多いでしょう。インストールや更新の入口は、リリースノートと合わせて 本サイトのダウンロードページから辿ると、OS ごとのクライアント選びも迷いにくくなります。

→ Clash を無料ダウンロードして、ターミナルとブラウザの両方で快適に使う