從零開始在 macOS 設定網路用戶端,關鍵不只是把應用程式拖進「應用程式」。安裝來源、處理器架構、系統延伸功能、VPN 設定、訂閱匯入、代理模式與 DNS 路徑,都可能影響最終結果。選單列顯示「已連線」只能表示用戶端完成了某個連線動作,不能直接證明瀏覽器、終端機及其他應用程式的流量都經過預期線路。

較穩妥的操作順序,是先確認安裝檔與裝置相容,再了解權限提示允許的內容,接著匯入訂閱、選擇合適的接管模式,最後分別核對出口 IP、DNS 與分流結果。發生異常時也應沿著同一條鏈路反向排查,而不是反覆重裝用戶端或頻繁切換線路。

安裝前確認用戶端、架構與來源

macOS 用戶端通常以磁碟映像檔、安裝程式套件或壓縮封存檔提供。磁碟映像檔通常要求將應用程式圖示拖入「應用程式」;安裝程式套件會經過系統安裝流程;壓縮封存檔則需要先解壓縮,再移動應用程式。無論採用哪種格式,都應從服務商控制台、專案官方發布頁或用戶端內建的更新管道取得檔案。

Mac 裝置可能使用 Apple 晶片,也可能使用 Intel 處理器。若發布頁分別提供不同架構,應下載與本機相符的版本;標示為 Universal 的版本通常同時包含相應架構。架構不相容時,應用程式可能無法開啟,也可能需要透過相容性轉譯層執行。可在「關於這台 Mac」中查看晶片或處理器資訊,再與下載頁標示核對。

檢查項目 應核對的內容 不相容時的表現
檔案來源 服務商控制台、用戶端官方發布頁或應用程式內更新入口 系統無法確認開發者,或應用程式行為與官方說明不一致
處理器架構 Apple 晶片、Intel 或 Universal 標示 應用程式無法啟動、意外結束或要求額外的相容環境
安裝格式 磁碟映像檔、安裝程式套件或壓縮封存檔所對應的安裝方式 應用程式仍在下載項目中執行,更新與權限狀態容易混亂
系統相容性 發布說明列出的最低系統需求與已知限制 網路延伸功能無法載入,設定入口與教學說明不同

如果 macOS 明確阻擋無法確認來源的應用程式,不建議透過關閉系統安全機制來繞過。請先核對下載網址、開發者資訊與發布說明;無法確認檔案來源時,重新從可信任的入口下載。系統的「開啟」確認適合處理已知開發者應用程式的首次啟動提示,不應視為所有警告的通用解決方式。

安裝階段結論:能開啟應用程式只代表程式本體可以執行。網路接管仍依賴後續的系統延伸功能、VPN 設定或代理設定,安裝完成後還不能直接判斷線路已經生效。

了解系統延伸功能與網路權限提示

用戶端首次啟用系統代理、TUN 或 VPN 接管時,macOS 可能要求管理者授權,也可能顯示「加入 VPN 設定」、「允許網路延伸功能」或與過濾器相關的提示。提示名稱會隨系統版本與用戶端實作而變化,但目的相近:允許應用程式建立由系統管理的網路路徑。

「加入 VPN 設定」不等於應用程式讀取了所有私人檔案。它允許用戶端建立系統認可的網路設定,並將符合條件的流量送入對應的網路延伸功能。管理者驗證用於核准這項系統層級變更。之後可以在「系統設定」的網路、VPN 與過濾器相關區域查看狀態,也可以從用戶端主動移除設定。

部分用戶端使用 Network Extension 框架實作 TUN,部分用戶端主要修改系統代理,另一些用戶端則允許在兩者之間切換。若系統提示延伸功能遭到阻擋,應先保持用戶端開啟,再進入「隱私權與安全性」查看待核准項目。核准後通常需要回到用戶端重新啟用連線;若應用程式明確提示重新啟動,再依提示操作。

系統代理與 TUN 的差異

系統代理會寫入 macOS 的 HTTP、HTTPS 或 SOCKS 代理設定。遵循系統代理的瀏覽器與應用程式會將請求交給用戶端,但自行實作網路堆疊、忽略系統代理或使用特殊傳輸方式的應用程式可能繞過它。此模式變更較少,適合先驗證網頁存取與基本分流。

TUN 模式會建立虛擬網路介面,由用戶端接收更廣泛的 IP 流量,再依據規則決定代理、直連或攔截。它通常更適合需要涵蓋終端工具、開發環境與不讀取系統代理的應用程式,但也更容易與其他 VPN、過濾器、安全軟體或企業網路延伸功能發生衝突。

接管方式 主要涵蓋範圍 常見限制 適用的排查情境
系統代理 讀取 macOS 代理設定的應用程式 部分終端機程式與獨立網路堆疊可能不會跟隨 先確認瀏覽器與基本規則是否正常
TUN 進入虛擬介面並由規則接管的流量 可能與其他網路延伸功能、過濾器衝突 瀏覽器正常但其他應用程式未生效
手動代理 個別填寫代理位址的指定應用程式 設定分散,不同應用程式的狀態不一致 隔離驗證某個應用程式的代理能力

匯入訂閱並辨識協議與線路欄位

完成權限設定後,可從服務商控制台複製訂閱連結,在用戶端的「訂閱」、「設定」、「遠端設定」或「Profiles」入口匯入。不同用戶端的按鈕名稱不同,但基本動作都是儲存遠端網址、下載設定並解析節點。若用戶端支援從剪貼簿匯入,請先確認剪貼簿中只有完整連結,沒有前後空格、換行或通訊軟體附加的標點符號。

匯入成功後,應先執行一次更新,查看是否出現節點、策略群組與規則。只有訂閱名稱而沒有任何可選線路,通常表示下載失敗、格式不相容或遠端內容未正確解析。此時應查看用戶端日誌中的 HTTP 狀態、解析錯誤與設定欄位提示,而不是重複貼上同一個連結。

  1. 從帳戶控制台複製目前有效的訂閱網址,不要在公開頁面開啟或轉發。
  2. 進入用戶端的訂閱或遠端設定入口,貼上網址並儲存。
  3. 手動更新設定,等待節點、策略群組與分流規則完成載入。
  4. 選擇符合目前任務的策略群組,再選定具體的出口線路。
  5. 啟用系統代理或 TUN,確認選單列狀態與系統設定中的網路設定一致。
  6. 完成出口 IP、DNS 與分應用程式驗證後,再啟用自動更新或開機啟動。

Shadowsocks、VMess、Trojan、VLESS、Hysteria2 與 TUIC

這些名稱代表不同的代理協議或傳輸方案,不是線路品質等級。Shadowsocks 以加密代理方式轉送流量,設定通常包含伺服器、連接埠、加密方法與憑證。VMess 與 VLESS 通常由相容核心處理,並可組合不同傳輸方式與 TLS 設定。Trojan 通常透過 TLS 外觀承載代理連線。Hysteria2 與 TUIC 採用以 QUIC 為方向的傳輸設計,對用戶端核心與網路環境各有要求。

使用者不應只憑協議名稱,手動改寫訂閱中的連接埠、傳輸層、安全參數或伺服器名稱。協議能否使用,取決於用戶端核心是否完整支援相關欄位,也取決於伺服器端設定是否相符。用戶端支援訂閱格式,不代表支援訂閱內的所有協議;匯入後出現「未知類型」或欄位解析失敗時,應改用支援相應協議的用戶端版本,或使用服務商提供的相容訂閱格式。

直連、中轉與 IEPL 專線

直連表示用戶端直接連接目標節點入口,路徑簡單,但品質更依賴本地電信商到入口的跨網表現。中轉線路會先接入中轉節點,再轉向出口,服務商可藉此調整部分路徑。IEPL 專線屬於面向國際連線的專線接入形式,其調度與出口仍由伺服器端完成。

對 macOS 用戶端而言,這些差異通常已寫入節點設定。用戶端負責連接指定入口,不會因為開啟 TUN 就把一般直連線路變成專線。選線時應以訂閱中的線路標示、目標地區與實際任務為準,不要根據協議名稱推斷它是直連、中轉還是 IEPL。

選擇全域、規則與直連模式

常見用戶端會提供全域、規則與直連模式。全域模式會將已由用戶端接管的流量統一交給代理策略,適合短時間排除規則比對問題;規則模式依網域、IP、程序或規則集決定代理與直連,是日常使用較常見的方式;直連模式則讓已被接管的流量直接存取,常用於恢復本地網路或判斷異常是否由代理鏈路造成。

「全域」只描述用戶端對已接管流量的處理方式,不一定表示裝置上的所有連線都進入用戶端。如果目前只啟用了系統代理,不讀取系統代理的應用程式仍可能繞過。相反地,TUN 已接管流量後,規則模式仍可讓本地網站、區域網路資源或指定應用程式直連。

分流規則需要留意比對順序。具體網域規則應在廣泛規則之前生效,最後的兜底規則負責處理未符合前面條件的請求。若同一個網域同時出現在多個規則集中,用戶端通常會依設定順序採用第一個符合的結果。修改規則後應重新載入設定,並清除應用程式內既有的連線,避免舊連線繼續沿用先前的路徑。

驗證出口 IP、DNS 與分應用程式結果

連線驗證應從網路層逐步進到應用程式層。先查看出口 IP 是否切換至所選地區,再檢查 DNS 請求由誰解析,最後分別開啟瀏覽器、終端機與實際要使用的應用程式。如此可區分「通道未建立」、「只有部分應用程式被接管」、「DNS 路徑不一致」及「目標服務本身有限制」等不同問題。

核對出口 IP

連線前後分別使用可信任的 IP 檢測頁面查看公開出口。結果應與所選節點地區相符,同時應排除瀏覽器快取、舊分頁與既有長連線的影響。可以關閉原頁面後重新開啟,或使用新的私密瀏覽視窗發出請求。若用戶端日誌顯示連線成功但出口沒有變化,應先確認系統代理或 TUN 是否確實開啟,再確認瀏覽器是否設定了獨立代理或安全 DNS 功能。

檢查 DNS 洩漏與解析路徑

DNS 洩漏通常是指業務流量經過代理,但網域查詢仍傳送至不符合預期的本地解析器,使解析路徑與出口路徑分離。在系統代理模式下,應用程式可能繼續使用系統 DNS;在 TUN 模式下,用戶端可以接管更多 DNS 流量,但是否接管仍取決於設定、規則與應用程式自身的加密 DNS 設定。

檢查時不要只看某個解析器名稱,還要確認請求是否命中用戶端 DNS 規則、解析結果是否遭到污染,以及代理網域是否在建立通道前正確解析。瀏覽器內建的安全 DNS、企業網路設定與其他網路過濾器都可能改變結果。發現不一致時,應先關閉重複的 DNS 接管來源,再依用戶端文件選擇系統解析、遠端解析或規則化解析方案。

scutil --proxy
scutil --dns
scutil --nwi
networksetup -getwebproxy "Wi-Fi"
networksetup -getsecurewebproxy "Wi-Fi"

scutil --proxy 可查看目前的系統代理狀態,scutil --dns 用於觀察系統解析器設定,scutil --nwi 可協助查看網路介面資訊。命令結果只能說明系統目前的設定,不能單獨證明某個應用程式嚴格遵循這些設定,因此仍需結合用戶端日誌與實際請求進行驗證。

按應用程式驗證

瀏覽器成功不代表終端機、開發工具與桌面應用程式都會成功。瀏覽器通常遵循系統代理,也可能使用獨立的代理擴充功能;終端機中的命令列程式有些會讀取環境變數,有些則直接連線;使用 QUIC、自帶 DNS 或長連線的應用程式也可能有不同表現。應在目標應用程式內重新建立連線,並觀察用戶端連線日誌是否出現對應網域、目標 IP 與策略。

生效判斷:出口地區與預期一致,DNS 路徑可以合理解釋,目標應用程式的請求命中正確規則,本地資源仍依預期直連。符合這些條件後,才可將目前設定視為完整生效。

常見權限錯誤與排查順序

權限錯誤往往來自殘留延伸功能、重複用戶端或系統狀態未同步。最有效的方法是一次只處理一個變因。先退出其他網路用戶端與過濾工具,再確認目前應用程式位於「應用程式」資料夾,並檢查系統設定中是否存在舊的 VPN 設定或網路延伸功能。不要在多個用戶端同時執行時反覆點選允許,否則很難判斷目前提示屬於哪個應用程式。

核准後仍反覆要求授權

這種情況常見於應用程式副本位置變更、舊版本延伸功能殘留,或用戶端未取得完成安裝所需的管理者驗證。先完全退出應用程式,刪除從磁碟映像檔執行的副本,只保留「應用程式」內的正式副本。接著查看系統設定中的 VPN 與過濾器狀態,移除明確屬於舊用戶端且已停用的設定,再重新開啟目前的用戶端。

如果系統設定顯示延伸功能已允許,但用戶端仍回報未載入,可以先停用再啟用對應功能,讓應用程式重新觸發狀態檢查。只有在用戶端發布說明明確要求時才重新啟動系統。直接刪除應用程式不一定會移除網路延伸功能與 VPN 設定,應使用用戶端提供的解除安裝或移除設定功能完成清理。

連線成功但網頁無法開啟

先切換至直連模式,確認本地網路本身可用。直連也失敗時,應檢查目前 Wi-Fi、企業網路驗證與系統 DNS,而不是繼續更換節點。直連正常但代理失敗時,再查看節點交握、訂閱有效性、協議相容性與 DNS 日誌。若只有個別網域失敗,應檢查分流規則與解析結果,不要直接認定整條線路無法使用。

瀏覽器可用但終端機未生效

這通常表示瀏覽器讀取了系統代理,但終端機程式沒有讀取。可以啟用用戶端支援的 TUN 模式進行比對,或依命令列工具文件設定其代理環境。若開啟 TUN 後終端機恢復正常,表示問題在接管範圍,而非遠端線路。若仍未生效,應查看該工具是否固定使用獨立 DNS、UDP 或特殊網路介面。

睡眠喚醒後失去連線

Mac 喚醒後可能更換網路介面、重新取得位址或恢復舊連線。先讓用戶端中斷並重新連線,使路由、DNS 與虛擬介面重新載入。若問題持續,檢查用戶端是否有自動恢復連線選項,並確認沒有其他工具在喚醒後覆寫系統代理。若頻繁發生,可儲存喚醒前後的日誌,比對介面與 DNS 狀態的變化。

穩定使用前的收尾檢查

確認設定正常後,再決定是否啟用開機啟動、自動更新訂閱與網路變更後自動重新連線。自動化功能應建立在已驗證的設定上,否則系統啟動時會重複載入錯誤規則或無效延伸功能。訂閱更新也可能變更節點名稱與策略內容,更新後應確認原有策略群組仍指向預期線路。

保留必要的故障紀錄,有助於後續定位問題,包括用戶端版本、macOS 版本、接管模式、所選策略、錯誤時間與經過去識別化的日誌片段。日誌中的訂閱網址、驗證欄位、伺服器憑證與個人路徑,應在提交前移除。描述問題時,寫清楚「哪個應用程式、哪種模式、哪一步失敗」,比只寫「無法連線」更容易得到準確判斷。

如果裝置由學校或企業管理,設定描述檔可能限制 VPN、代理或網路延伸功能。這類限制通常無法透過一般管理者授權覆蓋,應遵循裝置管理方的網路政策。個人裝置則應定期清理已停用用戶端留下的代理設定與網路延伸功能,避免多個網路元件爭用同一路由。