進階設定 閱讀時間約 12 分鐘

macOS TUN 增強模式設定教學：接管終端機與全域流量

了解系統代理與 TUN 虛擬網卡的差異，掌握終端機與遊戲未走系統代理的原因，以及在 Mac 用戶端授權、啟用和驗證 TUN 的完整步驟。

系統代理與 TUN：流量接管的位置不同

在 Mac 上啟用系統代理後，瀏覽器可以正常連線，終端機指令卻仍然逾時，通常不是同一個開關失效，而是兩種程式使用了不同的網路路徑。系統代理提供 HTTP、HTTPS 或 SOCKS 代理位址，應用程式必須主動讀取並使用這些設定。TUN 則透過虛擬網路介面和路由，將符合條件的 IP 流量送進代理核心。

比較項目系統代理TUN 增強模式
接管條件應用程式讀取系統代理，或個別設定代理連線符合虛擬網卡相關路由
常見用途瀏覽器及遵循系統設定的應用程式終端機工具、部分遊戲及其他直連程式
權限需求可能需要授權修改網路代理設定通常需要特權輔助服務來建立介面與路由
UDP 流量一般 HTTP 系統代理無法通用接管還需要核心、出站協定與節點共同支援
出站選擇由核心執行模式與規則決定同樣由核心執行模式與規則決定

「全域流量」也不代表一定涵蓋所有連線。排除區域網路、程式明確綁定介面、其他 VPN 路由，以及系統本身的流量，都可能影響實際涵蓋範圍。驗證時應檢查目標應用程式的實際連線，不要只看選單列上的開關。

啟用前：確認核心、節點與目前網路狀態

確認用戶端實際執行的核心

Clash 是設定與用戶端生態系常見的名稱，不代表所有應用程式都使用相同核心。Clash Meta 後續以 mihomo 為名持續開發；特定 TUN 欄位是否受支援，應以目前執行的核心版本及其文件為準。先在用戶端的「關於」、核心管理頁面或啟動記錄中記下用戶端版本、核心名稱與版本號。圖形介面版本和核心版本是兩項不同資訊，不能互相取代。

先建立可用的基準狀態

  1. 更新訂閱並選擇可用節點。在只啟用系統代理的狀態下，確認瀏覽器可以連上要測試的網站。
  2. 確認目前使用「規則」模式，並查看目標網域會符合哪個策略群組。節點延遲測試通過，不代表 HTTPS 和 UDP 都能正常使用。
  3. 暫時中斷其他個人 VPN、網路加速器及另一個代理用戶端。若是公司或機構管理的 VPN，請勿自行移除，應先確認組織的網路規範。
  4. 記下目前的系統代理狀態與本機監聽連接埠，並保留現有設定備份，以便發生問題時還原。

連接埠數值請以用戶端設定為準。例如，只有本機混合連接埠確實是 7890 時，127.0.0.1:7890 才是有效的代理入口；這不是所有用戶端通用的固定值。TUN 也不是把系統代理連接埠改成另一個數字。

授權並啟用：先安裝服務，再接管流量

不同用戶端的選單名稱不盡相同。以 Clash Verge Rev 常見介面為例，先開啟「設定」→「Clash 設定」，確認「服務模式」已安裝並正在執行，再啟用「TUN 模式」。若目前版本調整了入口，請依介面中的「服務模式」和「TUN 模式」設定項目尋找，不要直接套用其他用戶端的選單路徑。

  1. 安裝特權輔助服務。按一下服務模式旁的安裝按鈕；macOS 要求授權時，先確認提出要求的是剛開啟的用戶端，再依系統提示完成管理員驗證。不要在終端機中以管理員身分執行整個圖形介面應用程式。
  2. 確認服務正在執行。安裝成功後，介面應顯示服務已就緒。若仍顯示尚未安裝或無法連線，請先排除服務錯誤，不要反覆切換 TUN。
  3. 啟用 TUN 模式。等待核心重新載入設定，並檢查記錄中是否出現建立虛擬介面或新增路由失敗等訊息。不同版本的成功提示可能有所不同。
  4. 首次測試時維持規則模式。先驗證現有規則，不要同時更換節點、切換全域模式和修改 DNS，否則難以判斷是哪項變更影響結果。
  5. 單獨驗證 TUN。服務穩定後，可以暫時關閉系統代理再測試。這樣更容易確認連線不是繼續透過瀏覽器讀取的 HTTP 代理進入核心。

Apple 晶片 Mac 建議優先選用適用於 Apple 晶片的用戶端，Intel Mac 則選擇相對應的架構版本。架構主要影響應用程式與輔助程式能否正常執行；兩種架構下，TUN、路由和規則分流的基本原理相同。

設定欄位：路由、協定堆疊與 DNS 接管

如果圖形介面用戶端已提供 TUN 開關，建議優先透過介面管理。部分用戶端會將介面選項合併至執行設定，直接修改訂閱原始檔可能會在更新時被覆蓋。若需要自訂，請使用用戶端提供的覆寫或設定合併功能，並確認最終執行設定確實生效。

以下是 mihomo 的局部設定範例，只列出 TUN 相關欄位，並非可獨立執行的完整訂閱。範例假設已有可用的代理、規則及已啟用的內建 DNS 設定：

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
  • enable：啟用 TUN 功能。關閉圖形介面開關時，用戶端可能會重新產生此值。
  • stack: mixed：選用混合協定堆疊。其他可用值及其行為，請以目前核心支援的項目為準；不要只因網路速度慢就反覆隨機切換。
  • auto-route：由核心自動設定相關路由。自訂路由、其他 VPN 或管理政策仍可能影響最終連線路徑。
  • auto-detect-interface：嘗試辨識出站介面。若從 Wi-Fi 切換至乙太網路後連線異常，可重新啟動核心並檢查辨識結果。
  • dns-hijack：將符合條件的傳統 DNS 要求交由內建 DNS 處理。範例中的 any:53 並不代表「接管所有加密 DNS」。

網域規則為什麼與 DNS 有關

許多分流規則仰賴網域資訊，而 TUN 收到的基本資料是 IP 封包。核心需要透過 DNS 對應、連線中繼資料或設定的流量嗅探能力來辨識網域。使用 fake-ip 時，內建 DNS 會回傳映射位址，再由核心關聯實際目標；使用其他 DNS 模式時，網域關聯方式可能不同。

瀏覽器的安全 DNS 通常使用 HTTPS，流量會經過 443 連接埠，不會因為劫持 53 連接埠就自動變成核心看得到的明文 DNS。若規則比對異常，請一併檢查瀏覽器 DNS 設定、核心 DNS 記錄及實際命中的規則。不要只修改一個欄位，就認定網域辨識已完整。

驗證 TUN：交叉檢查介面、終端機連線與規則

第一步：觀察網路狀態，不要只憑介面名稱下結論

開啟「終端機」並執行以下唯讀指令。第一個指令顯示系統代理設定，第二個列出網路介面，第三個查詢通往指定位址的路由：

scutil --proxy
ifconfig
route -n get 1.1.1.1

macOS 常見的虛擬介面名稱是 utun 加上數字，但系統服務和其他 VPN 也會建立這類介面。因此，看到 utun3 並不能證明它屬於目前的用戶端。應綜合比較啟用前後的變化、用戶端記錄與路由結果來判斷。單一目標的路由查詢也不代表所有目的位址的路徑。

第二步：明確讓終端機不使用應用程式層代理

使用 macOS 內建的 curl 進行測試，並透過 --noproxy '*' 略過 curl 的應用程式層代理。這個參數不會略過 TUN，因此適合用來區分兩種接管路徑：

/usr/bin/curl --noproxy '*' --connect-timeout 10 --max-time 20 -I https://example.com

範例分別設定 10 秒連線逾時和 20 秒總逾時。收到 HTTP 回應只能證明目標可以連線，無法單獨證明流量使用了代理節點；在部分網路環境中，這個網站本來就能直連。執行指令時，請同時開啟用戶端的連線清單，找出 example.com 對應的連線，確認符合的規則、策略群組及最終出站。

第三步：比較關閉 TUN 後的狀況

  1. 維持節點、規則與測試網址不變，記錄啟用 TUN 時的連線記錄。
  2. 關閉 TUN，並維持系統代理關閉，再執行同一個指令。
  3. 比較用戶端是否仍看得到該連線、命中的規則是否一致，以及要求結果有何變化。
  4. 還原所需的開關狀態。若結果沒有變化，請確認目標是否原本就會直連、是否仍有其他 VPN，或測試程式是否重用了舊連線。

測試遊戲時，還需要觀察遊戲實際建立的 UDP 工作階段。網頁能開啟、TCP 測試成功，都不代表節點支援遊戲所需的 UDP。遊戲登入、資源下載和對戰也可能使用不同網域與連接埠，應分別檢查，不要只測試啟動器。

常見問題：依序檢查權限、路由、DNS 與出站

TUN 開關立刻關閉，或顯示建立介面失敗

先確認輔助服務是否正在執行、核心是否成功啟動，再檢查執行設定是否有 YAML 縮排錯誤或包含目前核心不支援的欄位。安裝檔更新後，用戶端與舊版輔助服務可能需要重新配套；請透過用戶端提供的服務管理入口修復，避免手動刪除不明系統檔案。

啟用後所有網站都無法連線

先關閉 TUN，確認基本網路是否恢復。接著檢查節點連線、DNS 上游是否可達，以及記錄中的出站介面。若同時執行 VPN，請在獲得許可的情況下暫停其中一個，再重新測試。路由彼此覆蓋可能導致連線進入錯誤的隧道，也可能讓 DNS 要求無法抵達上游。

可以連線至 IP，網域卻解析失敗

優先檢查內建 DNS 是否啟用、上游解析器是否可達，以及 DNS 要求是否正確交由其處理。不要直接用「連線到 HTTPS 的 IP 位址」取代網域測試，因為憑證與虛擬主機通常仰賴網域名稱。macOS 的 scutil --dns 可用來查看解析器狀態，但仍應搭配實際應用程式的解析路徑判斷。

終端機流量已接管，某個應用程式仍然直連

先區分「進入核心後命中 DIRECT」和「根本沒有進入核心」。前者應檢查規則順序、策略群組選擇和區域網路排除；後者則檢查應用程式是否綁定特定介面、其他網路擴充功能是否接管，以及連線是否在啟用 TUN 前就已建立。結束並重新開啟目標應用程式，比只重新整理視窗更適合驗證新連線。

睡眠喚醒或切換 Wi-Fi 後失效

先中斷正在重試的應用程式連線，再重新啟動核心，讓介面辨識與路由重新建立。若問題經常重現，請記錄切換前後的網路類型、核心版本及相關記錄，再回報問題。分享記錄前，請移除訂閱網址、節點憑證和其他個人網路資訊。

關閉與還原：維持可重複的操作順序

不再需要 TUN 時，先在用戶端關閉 TUN，確認一般網路恢復後再結束應用程式。若先前啟用了系統代理，也請依實際需求關閉；系統代理若仍指向已結束的本機程序，遵循該設定的應用程式可能無法連網。

  • 檢查 Wi-Fi 代理的路徑：「系統設定」→「網路」→「Wi-Fi」→「詳細資訊」→「代理伺服器」。使用有線連線時，請選取對應的網路服務。
  • 檢查 VPN 的路徑：「系統設定」→「VPN」。用戶端建立的底層 TUN 不一定會在此處顯示為獨立 VPN 項目，因此沒有項目不代表不存在虛擬介面。
  • 若異常結束後網路未恢復，建議先重新開啟原用戶端，再正常關閉 TUN 和系統代理；必要時重新啟動 Mac，不要直接清空整套路由表。
Clash Mac版安裝檔