一、為什麼瀏覽器能上網，終端機卻像「沒開代理」

macOS 的「網路」設定或部分客戶端寫入的系統代理，主要影響遵循系統組態的圖形介面程式與部分內建服務；而你在終端機執行的 curl、git、npm、pip 等多數 CLI，屬於獨立行程，預設不會因為你在「系統設定」勾了代理就自動把流量送進 Clash。除非該程式明確讀取系統代理（少數工具會），否則行為就是依預設路由直連。

另一個容易混淆的點是：Clash 客戶端常同時提供「開啟系統代理」與「本機監聽埠」。前者讓部分 App 走 PAC 或 HTTP 代理設定；後者則在 127.0.0.1（或你設定的位址）上提供 HTTP／SOCKS 入口，也就是常見的混合埠。終端機內的工具要利用這個入口，最通用、也最可攜的做法，就是設定標準的Shell 環境變數，讓程式自己帶著代理 URL 去連線。

因此，排查順序建議固定為：先確認 Clash 本機埠真的在聽、規則與 DNS 正常（可對照《Clash 常見報錯與排除》），再在 shell 內設定變數並用 curl -v 看連線是否經由代理；不要一開始就改一大堆規則檔，否則很難分辨是「代理沒套上」還是「規則誤判」。

二、先對齊本機 Clash 混合埠與監聽位址

開啟你使用的桌面客戶端，在設定或狀態頁找到 mixed-port（混合埠）或同等的「本機 HTTP／SOCKS 埠」。社群設定檔常見預設為 7890，但你可能改成 7897、1080 等，以下範例請全部替換成你畫面上實際顯示的數字。

若混合埠只綁在 127.0.0.1，對「本機終端機」通常沒問題；但若你之後要從區網其他裝置或虛擬機連進來，需要一併開啟允許區域網路（allow-lan）並理解監聽介面，細節可參考《Clash 開啟區域網路代理》。本篇聚焦同一台 Mac 的終端機，代理 URL 一般寫成：

http://127.0.0.1:7890

若你的客戶端把 HTTP 與 SOCKS 分開不同埠，請以客戶端說明為準；多數情況下混合埠單一 URL 即可同時服務遵循 http_proxy 與 all_proxy 的工具。

三、在 shell 內設定 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY

在 zsh（macOS 預設）或 bash 中，可先以當次工作階段測試。建議大寫與小寫並列，因為有些程式只讀其中一種：

export http_proxy="http://127.0.0.1:7890"
export https_proxy="http://127.0.0.1:7890"
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 ALL_PROXY="http://127.0.0.1:7890"

NO_PROXY（與小寫 no_proxy）用來排除不必繞代理的主機，避免本機服務或內網位址被錯誤轉送。可依需求增刪：

export no_proxy="localhost,127.0.0.1,::1"
export NO_PROXY="localhost,127.0.0.1,::1"

說明：ALL_PROXY 常被需要 SOCKS 語意或「所有協定共用一個代理」的工具讀取；僅設 HTTPS_PROXY 有時不足以涵蓋 git:// 或部分舊式連線（實務上 GitHub 以 HTTPS 為主，但仍建議一併設定，行為較一致）。若某工具明確要求 socks5://127.0.0.1:7890，請改為對應前綴，並確認 Clash 該埠確實提供 SOCKS。

四、用 curl 驗證：真的走代理了嗎

設定完變數後，用詳細模式觀察連線過程：

curl -vI https://www.google.com

在輸出中尋找是否出現透過 proxy 連線、或目標位址經由 127.0.0.1:7890 之類字樣（不同 curl 版本用語略有差異）。若仍直連或連線被拒，請回頭檢查埠號是否打錯、Clash 是否未啟動、或該網域是否被規則送到 DIRECT 導致你看起來像「沒走節點」。

也可刻意指定代理做對照實驗（不依賴環境變數）：

curl -vI --proxy "http://127.0.0.1:7890" https://www.google.com

若帶 --proxy 可以、只靠環境變數不行，通常是變數名稱拼錯、當前 shell 沒載入到、或該次指令在子 shell／IDE 內建終端機繼承了另一套環境。此時可執行 env | grep -i proxy 確認實際值。

五、Git：環境變數之外，必要時加上 http.proxy

多數情況下，設好 HTTPS_PROXY 後，git clone 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
git config --global --unset https.proxy

使用 SSH（[email protected]:...）時，流量不會自動套用上述 HTTP 代理；需改走 HTTPS 遠端，或另行為 SSH 設定 ProxyCommand（例如透過 nc 與 SOCKS），該主題與本篇「HTTP(S) 環境變數」路線不同，請勿混用預期。

六、npm：registry、環境變數與 npm config

npm 會尊重 HTTP_PROXY／HTTPS_PROXY 的情況相當常見，但若你仍遇到僅 npm 失敗，可明確寫入：

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

清除時：

npm config delete proxy
npm config delete https-proxy

請注意：npm 的問題有時與 registry 有關（例如企業鏡像、私有倉庫證書）。若代理已通但安裝仍失敗，請用 npm config get registry 確認來源，並閱讀錯誤訊息區分是 TLS、DNS 還是 404。與在容器內跑 npm 相比，宿主機始終使用 127.0.0.1 指向自己即可；容器情境請改參考前述 Docker 專文。

七、寫入 ~/.zshrc：開新終端機自動生效

測試無誤後，把同一組 export 寫入 ~/.zshrc（若使用 bash 則為 ~/.bash_profile 或 ~/.bashrc），存檔後執行 source ~/.zshrc 或重開終端機。建議在檔案中加註解區塊，方便日後一鍵註解切換回直連。

若你同時使用 VS Code、JetBrains 等 IDE 內建終端機，請確認它們啟動時會載入登入 shell 設定檔；少數情況下需在 IDE 的環境變數設定頁手動同步，否則「系統終端機可以、IDE 裡不行」的現象會反覆出現。

八、除錯清單：仍連不上時依序核對

  • 埠號與協定：混合埠是否為 7890？HTTP URL 是否誤寫成 SOCKS 埠或反過來？
  • Clash 是否運作中：本機連線是否顯示規則命中；日誌有無 REJECT 或異常 DNS。
  • 變數是否在目前 shell 生效：env | grep -i proxy 對照預期字串。
  • NO_PROXY 是否過寬：誤把目標網域排除會導致直連失敗卻以為「代理沒開」。
  • VPN 與防火牆：全隧道 VPN 可能改寫路由，與本機迴環代理互動異常，可短暫關閉對照。
  • Git SSH 與 HTTPS：確認遠端 URL 形態，避免用 HTTP 代理期待去救 SSH 流量。

九、小結

在 macOS 上，「系統能翻牆」與「終端機能翻牆」是兩件事；對 curl、Git、npm 這類 CLI 而言，最穩定的做法仍是對齊 Clash 混合埠，並在 shell 中明確設定 HTTPS_PROXY、ALL_PROXY 與 NO_PROXY，必要時再補上 git 代理 與 npm 代理 的專用設定。把驗證拆成「curl 先通 → 再試 git → 再試 npm」，大多數問題都能快速定位。

相較於到處找一次性腳本，在開源核心上自行維護分流與日誌，長期可控性通常更好；圖形客戶端也能降低改設定檔的頻率。若你尚未完成訂閱匯入與基礎啟動，可先依《Clash Verge Rev 設定教學》把本機環境跑通，再回頭套用本文的環境變數。→ 立即免費下載 Clash，開啟流暢上網新體驗