macOS 系統代理無效？瀏覽器與終端機分別排查

先釐清：用戶端、系統代理與應用程式

v2rayN 顯示已選取節點，不代表每個程式都會使用該節點。應用程式必須將請求交給本機代理連接埠，v2rayN 才能處理後續連線。macOS 系統代理主要提供給遵循系統網路設定的應用程式；終端機工具可能改讀環境變數，也可能需要明確指定代理。

開始排查前，請在 v2rayN 查看本機 HTTP 與 SOCKS 監聽位址，並確認核心正在執行。下方數值僅供示範，不代表你的安裝一定使用這些連接埠；後續命令與系統設定都應改用用戶端目前顯示的實際值。

檢查 macOS 目前網路服務的代理設定

先在 v2rayN 的系統代理選單確認已選取「自動設定系統代理」，再到 macOS 確認設定套用在目前使用的網路服務。系統介面位置會因 macOS 版本及 Wi-Fi、乙太網路等連線方式而異；較新的介面通常可從「系統設定」→「網路」→目前的網路服務→「詳細資訊」→「代理伺服器」進入。

1. 確認核心正在執行

   查看 v2rayN 主畫面的狀態與記錄。若核心尚未啟動，即使系統已填入代理位址，也無法連上本機連接埠。

2. 查看監聽連接埠

   在 v2rayN 的「設定」→「參數設定」中確認本機代理連接埠，並以目前介面及記錄顯示的監聽結果為準。請分清 HTTP 與 SOCKS 連接埠，不要填錯。

3. 選取系統代理

   在 v2rayN 的系統代理選單選取「自動設定系統代理」，接著開啟 macOS「系統設定」→「網路」→目前的網路服務→「詳細資訊」→「代理伺服器」，確認位址與連接埠。

4. 確認網路服務

   若目前使用乙太網路，不要只檢查 Wi-Fi 的代理選項。切換網路連線後，請重新查看目前使用的服務；也要留意是否啟用了舊的自動代理設定或其他手動代理。

手動設定時，HTTP 代理與安全網頁代理應使用實際的 HTTP 監聽連接埠；SOCKS 代理則應使用實際的 SOCKS 監聽連接埠。範例位址 127.0.0.1 僅代表這台 Mac 本身，不可將遠端節點位址填入系統代理欄位。若用戶端產生的是自動代理設定，請確認其狀態，不要把設定位址誤當成一般 HTTP 代理伺服器。

也可以在終端機執行以下唯讀命令，查看系統目前提供的代理設定。若輸出中出現舊位址或舊連接埠，請先回到目前網路服務的設定頁修正，再重新啟動要測試的應用程式。

scutil --proxy
networksetup -listallnetworkservices
networksetup -getwebproxy "Wi-Fi"
networksetup -getsocksfirewallproxy "Wi-Fi"

瀏覽器無法連線：排除獨立代理與擴充功能衝突

瀏覽器能開啟網頁，只能表示目前的連線路徑可用，不能因此判定它正在使用 v2rayN。反過來說，瀏覽器無法開啟網頁、其他應用程式卻正常，也不一定是節點故障。請先使用同一個明確網址重複測試，並記下是所有網站都無法連線，還是只有特定網站有問題。

• 檢查瀏覽器的代理設定：若瀏覽器有代理設定選項，請確認它使用 macOS 系統代理，而不是先前留下的手動伺服器位址。
• 暫時停用會變更代理的擴充功能：特別留意代理切換、請求轉送類擴充功能。停用後開啟新視窗測試，避免同時把擴充功能規則和系統設定當成變因。
• 確認目前網路與登入狀態：切換網路後，請重新檢查對應服務的代理設定。需要透過入口網站登入的公共網路，應先完成該網路本身的連線程序。
• 比較一般視窗與新工作階段：若只有原本的視窗異常，請再檢查網站快取、瀏覽器設定或擴充功能；不要直接修改 v2rayN 節點參數。

若瀏覽器顯示代理伺服器拒絕連線，請優先確認系統代理中的本機位址、連接埠與核心監聽狀態。若頁面已建立連線，卻只有特定網站出現憑證錯誤或無法存取，應將問題視為該網站或瀏覽器的個別狀況排查，不要關閉憑證驗證來掩蓋錯誤。

終端機無法連線：分別測試明確代理與環境變數

終端機並非單一的網路用戶端：curl、套件管理工具和其他命令各有讀取代理設定的方式。先略過系統設定，直接讓 curl 連線至 v2rayN 的 HTTP 連接埠範例。若你的 HTTP 連接埠不是 10809，務必先替換命令中的數字。

curl -v -x http://127.0.0.1:10809 -I https://example.com

留意輸出中的代理位址、HTTP CONNECT 階段，以及最後的回應或錯誤。若連線遭拒，通常表示該連接埠沒有程式監聽，或連接埠填錯；若請求已到達代理卻遲遲沒有回應，請繼續檢查 v2rayN 記錄、節點設定與目標網站。-I 只會要求回應標頭，部分網站對這類請求的處理方式不同，可改用不含 -I 的命令重新測試。

1. 明確指定代理

   先執行上方的 curl -x 命令。這可確認本機 HTTP 連接埠能否處理請求，不受 shell 是否設定代理變數影響。

2. 檢查環境變數

   執行 env | grep -i proxy，檢查是否留有舊位址、錯誤連接埠，或讓目標網域略過代理的 NO_PROXY 設定。

3. 設定目前工作階段

   明確指定代理的請求成功後，再依照下方範例為目前的終端機工作階段設定變數，並執行不含 -x 的 curl 比較結果。

4. 逐一測試工具

   其他命令仍無法使用時，請檢查該工具自己的代理選項或設定檔。不要直接把 curl 的行為套用到所有命令列程式。

env | grep -i proxy
export http_proxy=http://127.0.0.1:10809
export https_proxy=http://127.0.0.1:10809
curl -v -I https://example.com

https_proxy 的值使用 http://，不代表目標網站改用未加密的 HTTP；這裡表示的是連線至本機 HTTP 代理的方式，HTTPS 目標通常會透過 CONNECT 建立通道。若只提供 SOCKS 連接埠，可對支援 SOCKS 的工具使用相應選項，例如 curl --socks5-hostname 127.0.0.1:10808 -I https://example.com；其中 --socks5-hostname 會讓網域名稱交由 SOCKS 代理解析。

依錯誤訊息定位：連接埠、位址與憑證

錯誤原文有助於判斷請求停在哪一層。以下範例中的位址和連接埠仍使用前文的示範值；不同系統或工具的錯誤文字可能略有差異，請搭配實際命令輸出與 v2rayN 記錄判斷。

若 curl -x 成功，但不含 -x 的相同命令失敗，請優先檢查環境變數、NO_PROXY 與命令本身的代理設定。若兩種呼叫方式都失敗，先查看 v2rayN 記錄是否有這次請求；若沒有記錄，請優先重新檢查監聽位址與連接埠。

切換網路或修改系統代理後，請重新送出請求並查看記錄。不要把先前的連線記錄當成本次測試結果；也避免一次修改節點、瀏覽器擴充功能和 shell 設定，否則即使恢復連線，也難以判斷是哪個步驟發揮作用。

還原設定並分層重新測試

排查完成後，請保留一套清楚的設定方式：瀏覽器視需要使用 macOS 系統代理，終端機工具則視需要使用自己的代理參數或環境變數。若只是暫時測試，不必將示範連接埠永久寫入所有終端機工作階段。

• 先測用戶端：確認 v2rayN 核心正在執行，記下目前 HTTP、SOCKS 監聽連接埠，並查看新請求是否出現在記錄中。
• 再測系統與瀏覽器：確認目前網路服務的代理設定，停用有衝突的擴充功能後，開啟新視窗瀏覽相同的測試網址。
• 最後測終端機：先執行明確指定連接埠的 curl -x，成功後再測試環境變數及實際要使用的命令。
• 清除暫存變數：不再需要本次 shell 測試值時，執行 unset http_proxy https_proxy；若也設定過其他代理變數，請依實際名稱逐一清除。

依照這個順序，就能分別確認「本機連接埠是否可用」、「應用程式是否讀取系統設定」及「命令是否自行設定代理」。若連接埠與明確代理請求都正常，就不必從頭重新設定節點；若明確代理請求仍失敗，再回頭檢查用戶端記錄與節點設定。