システムプロキシとターミナルは別レイヤー
macOS で Clash 系クライアントの「システムプロキシを有効化」をオンにすると、システムのネットワーク設定に HTTP／HTTPS プロキシのホストとポートが書き込まれ、対応する GUI アプリや Safari などはその設定を参照します。一方、ターミナルで動く curl や git、多くの場合の brew は、自動的にはその値を読みにいきません。環境変数（http_proxy／HTTPS_PROXY など）やツール独自の設定が無い限り、外向き通信はプロキシを迂回して「直結」したように見えます。
したがって「ブラウザでは海外サイトが開けるのに、brew update だけ遅い／失敗する」といった症状は、Clash 自体の不調というより、CLI がプロキシ情報をどこから取るかの問題であることが多いです。以降の手順は、その前提を踏まえて上から順に試すと無駄が少なくなります。
切り分けの全体像（この順で確認）
再現性を高めるため、次の順序をおすすめします。（1）実際に動いているシェルと、起動時に読まれるファイル（.zshrc／.zshenv など）。（2）現在のセッションに http_proxy／HTTPS_PROXY／ALL_PROXY が存在するか、値は Clash の待受と一致するか。（3）NO_PROXY／no_proxy に目的ホストや localhost、社内ドメインが誤って入っていないか。（4）Clash の設定で HTTP ポートと mixed ポートのどちらを指すべきか。（5）sudo や SSH セッションなど、別ユーザー／別環境で変数が消えていないか。
アプリ全体のトラフィックをルール下に載せたい場合は、環境変数だけに頼らず TUN モードの検討余地があります。当サイトのTUN モード解説とあわせて読むと、「システムプロキシを無視するプロセス」をどう捕まえるかの地図がつながります。
ステップ1：シェルと読み込まれる設定ファイル
ターミナル.app や iTerm2 を開いたとき、ログインシェルかどうかで読まれるファイルが変わります。まず echo $SHELL で /bin/zsh などを確認し、続けて dscl . -read ~/ UserShell や「ターミナル」環境設定のシェル指定も見ておくと、想定外の bash 固定などに気づきやすくなります。
zsh の場合、非ログインの対話シェルでは通常 ~/.zshrc が読まれ、~/.zshenv はより広いタイミングで毎回評価されます。GUI から起動したターミナルが「ログインシェルとして起動」にチェックされているかどうかで ~/.zprofile が絡むかも変わります。プロキシ用の export をどこに書いたかと実際にそのファイルが評価されたかがずれると、「設定したはずなのに空」の典型原因になります。
確認用に、新しいタブを開いてすぐ次を実行し、空でないかを見ます。
echo "http_proxy=$http_proxy"
echo "HTTPS_PROXY=$HTTPS_PROXY"
echo "ALL_PROXY=$ALL_PROXY"ここですべて空なら、そのシェルセッションはまだプロキシ変数を持っていません。Clash の「システムプロキシ」だけでは足りず、.zshrc 等での export、または手元のプロキシ管理スクリプトが必要です。
ステップ2：環境変数の名前・大文字小文字・スキーム
多くの CLI は http_proxy と https_proxy（小文字）を参照しますが、ツールによっては HTTP_PROXY だけを見る場合もあります。確実を期するなら、次のように大文字・小文字の両方を同じ値にそろえる運用が無難です。
# Example: Clash local HTTP proxy on 7890 — replace port if yours differs
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=socks5://127.0.0.1:xxxx が有効なこともありますが、brew や一部 HTTP ライブラリは HTTP プロキシの方が扱いやすいことが多いです。クライアントの「ポート」表示が mixed と HTTP で分かれている場合は、環境変数には通常 http://127.0.0.1:<HTTP または mixed> を指定し、実際の listen アドレスが 127.0.0.1 か 0.0.0.0 かもあわせて確認してください。
ステップ3：NO_PROXY／no_proxy と「直結」に見える例外
NO_PROXY（または no_proxy）には、プロキシをわざと通さないホストやサフィックスを列挙します。localhost、127.0.0.1、*.local、社内ドメイン、10.0.0.0/8 などが入っていると、その範囲への通信はプロキシを迂回します。意図せず広いパターン（例：トップレベルが短すぎるドメイン）を書いてしまうと、「一部のホストだけ直結」のように見え、切り分けが難しくなります。
次のように現在値を表示し、目的のホストがマッチしていないか読み解きます。
echo "$NO_PROXY"
echo "$no_proxy"また、git config --global --get http.proxy や https.proxy が別値に固定されていると、環境変数より優先されることがあります。複数の設定源（シェル、Git 設定、ツールの設定ファイル）を同時に疑うと早く終わります。
ステップ4：Clash 側のポートと「どこを指すか」
環境変数の URL は、実行中の Clash／Mihomo が実際に待ち受けているポートと一致している必要があります。設定ファイルや GUI の「ポート」画面で mixed-port と port（HTTP）が別々に表示されている場合、片方だけ有効な構成もあり得ます。誤ったポートを指すと接続拒否やタイムアウトとなり、結果として「プロキシが効いていない」ように見えます。
動作確認には、変数を付与したうえで curl -I を少数回試す方法が手軽です。出口の見え方まで知りたい場合は、信頼できるチェック用エンドポイントへのアクセス結果をログと照合します。クライアントの導入や更新については、当サイトのダウンロードページから入手し、バージョンとポート表示を手元で揃えておくと、変数の打ち間違いを減らせます。
Homebrew・Git・curl のよくあるパターン
Homebrew は、公式スクリプトや brew 本体が環境変数を参照するため、シェルに https_proxy が無いと GitHub や Bottle 取得が直結側に回ることがあります。CI 用ドキュメントでは ALL_PROXY の例も出ますが、手元のネットワークでは HTTP プロキシの方が安定することが多いです。
Git は環境変数 http_proxy／https_proxy を解釈しますが、リポジトリ単位で http.proxy が設定されているとそちらが優先されます。git config --list --show-origin | grep -i proxy で出自を追うと早いです。
curl は https_proxy を尊重しますが、--noproxy オプションや ~/.curlrc が上書きしていないかも確認ポイントです。他者からコピーした .curlrc に proxy = "" のような行が残っていると、環境変数があっても無効化されることがあります。
落とし穴：sudo、SSH、別ツールが起動したシェル
sudo brew のように権限昇格すると、デフォルトでは secure_path や環境のサニタイズによりプロキシ変数が引き継がれないことがあります。その場合は sudo -E を検討する一方で、セキュリティポリシーと相性が悪い環境もあるため、運用ルールに従ってください。
リモートサーバへ SSH した先のシェルは、手元 Mac の Clash とは別マシンです。サーバ側にプロキシを立てていない限り、サーバ上の curl が「直結」するのは正常な挙動です。混乱しやすいので、どのホスト上のシェルかを常に意識するとよいです。
また、VS Code や JetBrains 系の統合ターミナルは、親プロセスの環境を引き継ぎます。IDE をプロキシ ON の前に起動していた場合、ターミナルを再起動しないと古い空環境のままということもあります。
オープンソースとドキュメント
コアの挙動や設定キーの詳細は、利用中の実装（Mihomo など）の公式ドキュメントやGitHub リポジトリで確認できます。インストールパッケージの取得は当サイトのダウンロード導線を優先し、GitHub は仕様確認・Issue 追跡の参照先として使い分けると、初見の読者が手順を取り違えにくくなります。画面操作の流れはドキュメント／チュートリアルもあわせて参照してください。
まとめ
macOS で「Clash は動いているのにターミナルだけ直結」に見えるとき、まず疑うべきはCLI が参照するプロキシ情報の出どころです。システムプロキシと環境変数は別物であり、.zshrc と .zshenv のどちらが読まれたか、HTTPS_PROXY とポート番号、NO_PROXY の例外、Git 独自設定の上書きを、この記事の順で確認すると原因に辿り着きやすくなります。
環境変数での運用が煩雑な場合や、アプリがシステムプロキシを無視する場合は、TUN など別レイヤーの検討も選択肢です。いずれにせよ、一つずつ変数を表示して事実を積み上げることが、感覚的なトラブルシュートより早く確実です。
同種のツールのなかでも、Clash / Mihomo 系はローカル HTTP／SOCKS の待受とルール分流がわかりやすく、ターミナルと GUI の挙動差をログで突き合わせやすいのが長所です。手元のポート表示と変数をそろえ、必要ならクライアントを最新に保つことで、CLI からの更新作業も安定しやすくなります。