Clash 從入門到熟練使用手冊

先理解 Clash 的核心概念

開始操作前，先把用戶端、核心、設定檔、訂閱、節點、代理群組與規則分開理解。許多看似複雜的故障，本質上只是把其中兩個環節混在一起。例如，用戶端成功啟動不代表已有可用設定；訂閱匯入成功也不代表設定已經選取；選好設定後仍要確認代理群組使用哪個節點；開啟系統代理後，也只有遵循系統代理設定的程式會自動交由 Clash 處理。沿著這條鏈路逐層確認，比反覆重裝更容易找到問題。

用戶端、核心與設定各自負責什麼

用戶端是看得到的圖形介面，負責匯入訂閱、修改設定、顯示連線記錄，以及控制系統代理。核心是實際解析設定並處理連線的程式，Mihomo 是目前常見的相容核心之一。設定檔通常是 YAML 文字，包含連接埠、代理節點、代理群組、規則與 DNS 等內容。圖形用戶端啟動核心時，會把目前選取的設定交給核心讀取；只要設定語法有效，核心便會依照其中定義的順序處理流量。

這三層的故障表現不同。用戶端無法開啟，多半要檢查安裝、權限或系統相容性；用戶端能開啟但提示設定解析失敗，應查看 YAML 格式或訂閱內容；核心已執行但網頁無法連線，則繼續檢查系統代理、代理群組選擇、規則命中與節點可用性。排查時先判斷問題位於哪一層，避免把所有異常都歸因於「節點失效」。

訂閱、節點與代理群組的關係

訂閱連結是設定提供者提供的遠端網址。用戶端向該網址發出請求後取得設定內容，並將其儲存為本機設定。節點是設定中的單一代理出口，通常記錄伺服器位址、連接埠與協定參數。代理群組則將多個節點組織在一起，可以手動選擇，也可以依延遲測試或故障轉移策略選取。規則通常不會直接指向某個節點，而是先指向「節點選擇」「自動選擇」等代理群組，再由代理群組決定最終出口。

因此，看到節點清單不代表目前連線已經使用某個節點。需要先選取訂閱設定，再進入代理頁面查看主要代理群組，將其切換至合適的節點。若代理群組停在 DIRECT，相關連線會直接存取；若停在 REJECT，連線會被拒絕；若使用自動選擇，結果取決於該群組的測試網址、測試間隔與候選節點。節點來源不屬於用戶端本身，Clash 安裝後也不會自動產生可用線路。

系統代理與 TUN 的接管範圍

系統代理是作業系統提供的一組代理位址設定。瀏覽器與許多桌面應用程式會讀取這組設定，將 HTTP 或 SOCKS 連線傳送至 Clash 的本機監聽連接埠。它設定簡單、影響範圍清楚，適合作為首次使用時的首選。部分遊戲、命令列程式、商店應用程式與自行實作網路堆疊的軟體不會讀取系統代理，因此即使開關處於開啟狀態，也可能繼續直接連線。

TUN 模式透過虛擬網卡接收更多系統流量，涵蓋範圍通常比系統代理完整，但同時涉及管理員權限、路由表、DNS 接管與網路安全軟體相容性。正確順序是先用系統代理驗證訂閱與節點可用，再依實際需求開啟 TUN。若一開始同時修改訂閱、DNS、規則與 TUN，出現問題後很難判斷是哪個環節造成。

依系統與使用方式選擇用戶端

Clash 生態包含多個圖形用戶端與可獨立執行的核心。選擇時應先看作業系統，再看是否需要 TUN、規則編輯、訂閱管理與桌面系統匣等功能，不必只比較介面外觀。本網站下載頁依 Windows、macOS、Android、iOS、Linux 與 Mihomo 核心分組展示，用戶端清單與這裡的建議一致。首次使用時，優先選擇維護狀態清楚、操作入口完整的圖形用戶端；伺服器與路由器情境才考慮直接執行核心。

各平台的首選方向

Clash Plus 支援 Windows、macOS、Android 與 iOS，是本手冊在各平台的首推方案。它適合希望在不同裝置上使用相近操作邏輯的人，也提供常用的訂閱與代理設定入口。Windows 使用者還可以選擇 Clash Verge Rev、FlClash 或 Clash Nyanpasu；Clash for Windows 已停止維護，只適合處理既有環境或舊設定遷移，不建議作為新安裝的起點。

macOS 除了 Clash Plus 外，也可以選擇 Clash Verge Rev 與 FlClash。ClashX Meta 已停止維護，現有使用者可先匯出或記錄訂閱資訊，再遷移至仍在維護的用戶端。Android 可使用 Clash Plus、Clash Meta for Android、FlClash 或 Surfboard。行動裝置系統對背景執行與電池最佳化限制較多，安裝後還要檢查 VPN 權限、背景活動與省電策略。iOS 請使用 Clash Plus 的 App Store 版本，相關入口可在iOS 下載區查看。

Linux 桌面環境可選擇 Clash Verge Rev 或 FlClash。沒有桌面環境的伺服器、軟路由與容器情境，可以使用 Mihomo 核心，但需要自行準備設定檔、服務管理與日誌查看方式。直接執行核心不會自動提供圖形介面，也不會替系統設定桌面代理，因此更適合已理解連接埠、路由與設定結構的使用者。

圖形用戶端與獨立核心如何取捨

圖形用戶端適合日常桌面與行動裝置。訂閱更新、代理群組切換、連線查看、系統代理與 TUN 開關都集中在介面中，發生問題時也更容易確認目前狀態。獨立核心適合希望使用 systemd、Docker 或腳本管理的環境，優點是部署方式彈性高，代價是需要自行維護設定路徑、啟動參數、日誌輪替與重啟策略。

如果只是想讓瀏覽器與常用應用程式依規則存取網路，不必為了「功能更多」就直接選擇核心。先用圖形用戶端熟悉規則模式、代理群組與連線記錄，之後再遷移到伺服器環境，理解成本會低很多。反過來，若目標裝置沒有桌面、需要長時間執行，且設定由自動化系統下發，圖形介面反而沒有必要。

遷移舊用戶端時應保留哪些資訊

從 Clash for Windows 或 ClashX Meta 遷移時，最重要的是保存原始訂閱網址以及自行撰寫的覆寫規則。不要只複製用戶端快取目錄，因為不同用戶端對設定目錄、資料庫與介面設定的組織方式不同。若訂閱仍可存取，在新用戶端重新透過 URL 匯入通常更穩妥；若設定中包含本機規則集或腳本，應另外備份相關檔案，並檢查新核心是否支援對應語法。

遷移完成後先關閉舊用戶端，避免兩個程式同時修改系統代理或占用相同連接埠。確認工作列、選單列或背景程序中只保留一個核心，再啟動新用戶端。接著依序匯入訂閱、選取設定、選擇代理群組並開啟系統代理。舊用戶端可以暫時保留作為對照，但不要同時執行。

完成安裝、授予權限與首次啟動

安裝階段的目標不是立刻修改所有進階設定，而是讓用戶端、核心與系統權限處於可驗證狀態。完成安裝後先啟動一次，確認主介面可以開啟、核心狀態正常，且沒有連接埠占用提示，再繼續匯入訂閱。若首次啟動就出現錯誤，應先處理安裝與權限問題，不要用反覆匯入設定來掩蓋底層故障。

Windows 安裝與連接埠檢查

Windows 使用者從下載頁選擇符合系統架構的安裝檔，依安裝精靈完成部署。若系統詢問是否允許應用程式通過防火牆，可依目前網路類型授權；區域網路共享代理不是首次使用的必要條件，不需要提前開啟區域網路連線。安裝後從開始功能表啟動用戶端，觀察核心是否成功執行。準備使用 TUN 時，後續可能還需要安裝服務，或以管理員權限完成虛擬網卡初始化。

連接埠被占用是 Windows 首次啟動時常見的問題。Clash 設定通常會使用本機 HTTP、SOCKS 或 mixed 監聽連接埠；如果舊代理工具仍在背景執行，新核心可能無法繫結相同連接埠。先退出其他代理用戶端，再重新啟動 Clash。需要進一步確認時，可以在 PowerShell 中查看某個連接埠的監聽程序：

Get-NetTCPConnection -State Listen |
  Where-Object LocalPort -In 7890,7891,7892 |
  Select-Object LocalAddress,LocalPort,OwningProcess

Get-Process -Id <OwningProcess>

不同設定可能使用不同連接埠，介面顯示的實際監聽值才是判斷依據。不要因為習慣值是 7890 就直接修改系統代理；圖形用戶端通常會自動將正確位址寫入系統設定。

macOS 的安全性提示與網路權限

macOS 安裝完成後，將應用程式放入「應用程式」資料夾並從中啟動。系統可能要求確認應用程式來源、加入網路設定或輸入管理員密碼。系統代理只需修改網路代理設定，而 TUN 或增強接管通常還要安裝輔助服務。每次授權都應對應目前正在執行的操作；如果取消授權，用戶端介面可能仍能開啟，但相關開關將無法生效。

選單列用戶端容易與舊代理程式同時存在。檢查選單列圖示與「活動監視器」，確認舊核心已經退出。若開啟系統代理後立即自動關閉，先查看用戶端日誌是否提示權限不足，再檢查網路設定是否被其他網路管理工具覆寫。切換 Wi-Fi、網路線或個人熱點後，系統使用的網路服務可能改變，必要時重新切換一次系統代理開關。

Android 與 iOS 的 VPN 授權

行動裝置通常透過系統 VPN 介面接管流量。首次啟動連線時，系統會跳出 VPN 設定或連線要求，只有同意後用戶端才能運作。Android 狀態列出現 VPN 標誌，通常代表系統介面已建立，但仍需確認設定與代理群組正確。若應用程式切到背景後連線很快停止，請進入系統電池設定，允許背景活動，並將用戶端移出過於嚴格的省電限制。

同一時間通常只能有一個應用程式占用系統 VPN 介面。若裝置上已有企業 VPN、其他代理用戶端或隱私保護工具，啟動 Clash 時可能會主動中斷其中一個。先確認要保留哪個連線，不要同時開啟多個互相競爭的 VPN。iOS 加入 VPN 設定後，可以在系統設定中看到對應項目；刪除用戶端前若要徹底移除連線設定，也可一併檢查系統 VPN 清單。

Linux 桌面與核心執行方式

Linux 圖形用戶端依發行版選擇對應安裝檔。安裝後若應用程式可以啟動但無法設定系統代理，需要檢查桌面環境是否支援自動寫入代理設定。GNOME、KDE 與輕量桌面儲存代理設定的方式不同，必要時可以在桌面網路設定中手動核對位址與連接埠。使用 Wayland 或沙盒環境時，也要注意系統匣圖示與權限限制，但這些介面問題不一定會影響核心執行。

直接執行 Mihomo 核心時，應先準備獨立工作目錄，將設定儲存為可讀取的檔案，再以前景方式啟動以觀察日誌。以下是常見的啟動形式，路徑需要替換為本機實際目錄：

mkdir -p "$HOME/.config/mihomo"
mihomo -d "$HOME/.config/mihomo"

確認設定載入成功後，再考慮交由 systemd 等服務管理器處理。首次測試不建議直接放到背景執行，否則設定解析錯誤與連接埠衝突只會留在服務日誌中，不易察覺。伺服器還應限制控制介面與代理連接埠的監聽範圍，預設僅供本機使用時，繫結迴路位址即可。

匯入訂閱並建立可復原的設定流程

訂閱匯入是將遠端設定交由用戶端管理的過程。開始前準備完整的訂閱 URL，並確認複製時沒有多出空格、換行或說明文字。訂閱屬於設定來源，不應貼到節點名稱、代理連接埠或控制器位址輸入框。不同用戶端可能將入口稱為「設定」「訂閱」「Profiles」或「設定檔」，但核心操作都是透過 URL 下載設定、儲存到本機並設為目前設定。

URL 匯入的標準步驟

進入設定或訂閱頁面，選擇從 URL 建立新設定，將完整連結貼到網址欄。名稱可以填寫方便辨識的短文字，例如依用途或裝置區分，不建議將完整 URL 當作名稱顯示。提交後等待用戶端下載；成功時通常會出現新的設定項目，並顯示更新時間或更新按鈕。接著點擊該項目，讓它成為目前設定；有些用戶端匯入完成後不會自動選取，這是「看得到訂閱但沒有節點」的常見原因。

啟用設定後進入代理頁面，查看主要代理群組是否已出現，並選擇一個節點。然後開啟系統代理，用瀏覽器進行基礎存取測試。整個過程應分為「下載設定」「選取設定」「選擇節點」「開啟接管」四步，不要只因訂閱項目存在就以為設定已完成。完整圖文流程可參考Clash 訂閱連結匯入方法。

判斷用戶端是否接受連結格式

常見訂閱內容包括 Clash YAML 設定、節點清單，以及需要轉換後才能讓 Clash 識別的格式。用戶端透過 URL 取得內容後，會交由設定解析器處理。如果回傳的是登入頁面、錯誤頁面、空白文字或不相容格式，介面可能提示解析失敗，而不是單純顯示網路錯誤。此時先在訂閱提供者頁面重新複製專用於 Clash 或 Mihomo 的連結，不要隨意把網頁網址當成訂閱網址。

基本 YAML 設定通常包含連接埠、代理、代理群組與規則等欄位。以下範例展示結構關係，不包含實際節點資訊：

mixed-port: 7890
mode: rule
log-level: info

proxies: []

proxy-groups:
  - name: 節點選擇
    type: select
    proxies:
      - DIRECT

rules:
  - GEOIP,LAN,DIRECT
  - MATCH,節點選擇

YAML 對縮排敏感，通常使用空格，不要混入定位字元。訂閱由遠端服務產生時，不必手動修改原始檔案；需要加入自訂規則時，優先使用用戶端提供的覆寫或合併功能，避免每次更新訂閱後本機修改被覆蓋。

更新失敗時依回應類型處理

訂閱更新逾時，表示用戶端在限定時間內沒有完成請求，可能是目前網路無法存取訂閱網址、DNS 解析異常，或更新請求需要經過既有代理。可以先用原本的網路直接開啟訂閱提供者的管理頁面，確認服務可連線；如果用戶端有「透過代理更新」選項，可在已有可用設定時嘗試開啟。首次匯入尚無可用設定時，則應先確保訂閱網址能透過目前的直接連線網路存取。

回傳 404 或類似的資源不存在提示，通常表示連結路徑失效、權杖已更換或複製不完整。此時重試不會修復網址，需要回到訂閱來源重新產生連結。若回傳未授權或拒絕存取，應檢查帳戶狀態、連結權限與服務端限制。更多依錯誤類型拆分的處理方式，請見訂閱更新失敗排查。

自動更新間隔與本機備份

自動更新不必設定得過於頻繁。節點與規則只有在伺服器端內容變更時才會改變，短時間連續請求會增加失敗機率，也不利於判斷目前使用的是哪一次更新結果。日常裝置可以依用戶端提供的小時級間隔設定；需要立即同步時再手動更新。更新後若節點清單明顯異常，先查看設定更新時間，並嘗試切回上一個仍可用的本機設定。

訂閱 URL 應作為敏感設定資訊妥善保管，因為它可能允許取得對應帳戶的設定內容。分享截圖時遮住完整網址，排查問題時優先提供錯誤類型與日誌片段，而不是公開連結。備份時可以儲存訂閱網址、自訂覆寫與用戶端設定說明；遠端訂閱產生的節點清單通常可以重新下載，不必在多台裝置間複製整個快取目錄。

理解規則、全域與直連三種代理模式

代理模式決定連線進入 Clash 後如何選擇出口。它不決定流量能否進入用戶端；系統代理或 TUN 才負責接管。模式選擇也不會改變節點本身是否可用。理解這兩個界線後，排查會清楚許多：連線記錄完全沒有請求，應檢查接管；有請求但出口不符合預期，應檢查模式、規則與代理群組；請求選擇代理卻連線失敗，再檢查節點與目標網路。

規則模式適合日常使用

規則模式會由上而下檢查設定中的規則，第一條符合的規則決定連線交給哪個策略群組、直接連線或拒絕。常見規則依據包括網域、網域後綴、IP 位址、地理資料庫、程序名稱與規則集。它可以讓區域網路、本機服務與常用直連網站維持直連，同時將需要代理的連線交給指定代理群組，兼顧存取路徑與本機服務相容性。

規則模式不等於「自動判斷一切」。判斷依據來自設定檔，規則的涵蓋範圍與順序都可能影響結果。某個新網域尚未加入規則集時，最終會落到末尾的 MATCH 規則。遇到單一網站出口不正確時，應先在連線記錄中找到目標網域，查看它命中了哪條規則與最終策略，再決定是否加入自訂規則，而不是立刻切換至全域模式長期使用。

全域模式用於對照測試

全域模式通常會將已接管的連線統一交給全域代理群組。它適合短時間判斷「問題是否由規則造成」：若規則模式下存取失敗，切換全域後恢復，表示節點與接管鏈路大致正常，接下來應檢查規則命中或 DNS 結果。如果全域模式仍然失敗，則優先檢查節點、連接埠、權限與網路環境。

全域模式不代表作業系統的所有流量一定都被接管。僅開啟系統代理時，不讀取系統代理的應用程式仍可能直接連線；要擴大範圍需要 TUN。全域模式也可能讓區域網路裝置、印表機、開發服務或僅允許本機網路存取的資源經過代理，因此更適合作為測試工具，或在有明確需求時暫時使用，而不是解決所有故障的固定開關。

直連模式用於復原與基準檢查

直連模式會讓進入 Clash 的連線繞過代理出口。它可用於確認系統原始網路是否正常，也適合在保留用戶端執行的同時暫時停止代理。若切換至直連後一般網站仍無法存取，問題可能位於本機 DNS、系統網路、殘留代理設定或 TUN 路由，而不是遠端節點。

退出用戶端前，建議先關閉系統代理與 TUN，再結束程式。若程式被強制終止，系統代理位址可能仍指向已不存在的本機連接埠，導致所有遵循系統代理的應用程式突然無法連網。此時重新啟動用戶端並正常關閉開關，或進入系統網路設定清除代理位址。直連模式與停止接管並不完全相同：前者仍讓連線經過核心後直接連線，後者則不再將相應流量送入核心。

代理群組的手動、自動與故障轉移

select 類型代理群組由使用者手動選擇節點或其他子群組，結果穩定且容易理解，適合作為主要出口；url-test 類型會定期請求測試網址，從候選節點中選擇回應表現較合適的一個；測試結果只反映該測試目標，不等於所有網站的實際體驗。fallback 類型會依序檢查可用性，目前項目失效後切換至後續候選，適合重視連續性的情境。

自動群組頻繁切換時，現有連線不一定能平順遷移，登入工作階段與下載任務也可能受到影響。測試間隔不宜過短，候選節點也不必無限制增加。對需要固定出口的帳戶或服務而言，選擇穩定的手動群組更容易維持一致性。代理群組中也可能巢狀包含其他代理群組，排查時要逐層查看，避免只看到外層名稱便誤判最終節點。

掌握規則順序、分流寫法與 DNS 搭配

規則分流是 Clash 的核心能力，也是設定出現「部分網站正常、部分網站異常」時最值得檢查的部分。規則會依設定中的排列順序逐條比對，命中後停止繼續檢查。因此，範圍較大的規則若放得太前面，可能遮蔽後面的精確規則。設計規則時通常先處理區域網路與明確例外，再放入具體網域或規則集，接著處理 IP 類規則，最後使用 MATCH 接住剩餘連線。

常見規則類型如何使用

DOMAIN 用於完整網域，適合處理單一主機；DOMAIN-SUFFIX 比對某個網域及其子網域；DOMAIN-KEYWORD 範圍更廣，容易誤判，只有在網域結構不穩定且關鍵字足夠明確時才使用。IP-CIDR 依 IPv4 網段比對，IP-CIDR6 對應 IPv6。GEOIP 依 IP 地理資料庫處理，RULE-SET 則引用外部或內建規則集合。

rules:
  - DOMAIN,printer.lan,DIRECT
  - DOMAIN-SUFFIX,example.internal,DIRECT
  - DOMAIN-SUFFIX,example.com,節點選擇
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - GEOIP,LAN,DIRECT
  - MATCH,節點選擇

範例中的 no-resolve 表示比對該 IP 規則時，不為網域額外觸發解析，適合明確的本機網段。實際設定應保留訂閱原有的規則架構，只將確有需求的例外放在適當位置。若用戶端支援覆寫規則，可以在訂閱更新後自動合併；直接修改下載取得的設定，下一次更新很可能會覆蓋變更。

從連線記錄反推規則問題

排查某個網站時，先清除或暫停無關應用程式，重新存取目標頁面，再在連線記錄中依網域篩選。記錄通常會顯示目標主機、使用的規則、策略群組與鏈路。若命中意外的直連規則，檢查是否存在範圍過大的網域後綴或地理規則；若落到 MATCH，表示前面的規則沒有涵蓋它；若已命中預期代理群組但最後選到 DIRECT，則繼續查看該代理群組目前的選擇。

現代網頁會同時存取多個網域，主頁網域正常不代表靜態資源、登入介面與圖片網域都使用相同策略。只加入一條主網域規則後頁面仍不完整，應從失敗請求中找出相關網域，而不是盲目加入寬泛關鍵字。瀏覽器開發人員工具與 Clash 連線記錄可以互相對照：前者確認哪個請求失敗，後者確認該請求使用了哪個出口。

DNS 為什麼會影響規則結果

DNS 負責將網域轉換為 IP 位址。若應用程式在流量進入 Clash 前已自行解析，只傳送 IP，基於網域的規則可能無法直接取得原始主機資訊；如果解析結果受到網路環境影響，即使節點可用，也可能連線至錯誤位址。Clash 的 DNS 模組可以依設定處理查詢，並搭配 fake-ip 或 redir-host 等模式保留網域對應關係。

fake-ip 模式會向應用程式回傳保留位址範圍內的暫時位址，核心再依對應關係找到真實網域並執行規則。它通常具備較好的網域規則識別能力，但少數區域網路裝置、舊版應用程式或依賴真實 IP 的程式需要加入過濾清單。redir-host 更接近回傳真實解析結果，相容性思路較直觀，但網域對應與連線識別方式有所不同。不要只因名稱看起來陌生就切換模式；若目前訂閱的 DNS 設定穩定，應先維持原設定。

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 1.1.1.1
    - 8.8.8.8
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"

這段範例展示欄位關係，並不表示所有網路環境都應使用相同的上游位址。訂閱設定可能採用 DoH、DoT、系統 DNS，或依網域分流的 nameserver-policy。修改前先記錄原始值；若變更後所有網域都無法解析，先還原訂閱預設設定，再檢查 1053 等監聽連接埠是否衝突、系統防火牆是否攔截，以及 TUN 的 DNS 劫持是否指向正確連接埠。

IPv6、區域網路與自訂規則邊界

裝置具備 IPv6 連線時，應用程式可能優先請求 AAAA 記錄。如果設定只處理 IPv4，而系統又透過 IPv6 直接連線，可能出現出口不一致。是否關閉 IPv6 取決於節點、核心與本機網路是否完整支援，不應把關閉 IPv6 當作固定答案。較穩妥的做法是先在連線記錄中確認異常請求是否使用 IPv6，再決定補充規則、調整 DNS 回應或暫時停用相關路徑。

存取路由器、NAS、印表機與開發伺服器時，應確保私有位址範圍與本地域名直連。TUN 環境下還要保留區域網路路由，避免將本機連線送往遠端代理。允許區域網路裝置連線至 Clash 本機代理是另一項功能，會改變監聽範圍；只有確有共享需求時才開啟，並搭配防火牆限制可信任網路，不要把「存取區域網路」和「向區域網路開放代理」混為一談。

依需求啟用 TUN 接管全域流量

TUN 模式會建立虛擬網路介面，並透過路由將更多連線交給 Clash。它適合不讀取系統代理的遊戲、命令列工具、商店應用程式，以及需要統一處理 TCP、UDP 流量的情境。TUN 能擴大接管範圍，但不會修復失效節點、錯誤訂閱或不合理規則。因此啟用前必須先在系統代理模式下驗證設定可用，並記住原本的 DNS 與代理設定，方便發生異常時快速還原。

啟用前的四項檢查

第一，確認目前設定在規則模式下可透過系統代理正常存取。第二，關閉其他 VPN、虛擬網卡代理，以及可能修改路由的網路工具，避免多個接管層互相覆蓋。第三，確認用戶端具備管理員權限，或已安裝所需服務。第四，儲存正在使用的設定，並了解關閉 TUN、關閉系統代理與退出用戶端的確切位置。完成準備後，再啟用 TUN 並等待虛擬網卡初始化。

Windows 用戶端通常透過服務模式取得修改路由所需的權限。如果點擊開關後立即復位，查看是否提示安裝服務、權限不足或驅動程式初始化失敗。macOS 可能要求安裝網路擴充功能或輔助服務。Android 與 iOS 本身已使用系統 VPN 介面，介面中的接管實作與桌面端不同，通常不需要尋找完全相同名稱的 TUN 開關。

常見 TUN 參數的意義

auto-route 用於自動加入必要路由，適合大多數桌面用戶端；關閉後需要自行管理流量如何進入虛擬網卡。auto-detect-interface 會嘗試識別目前實際連線的介面，裝置在 Wi-Fi、網路線與個人熱點之間切換時特別有用。dns-hijack 將指定的 DNS 請求交給核心 DNS 模組處理，用於減少系統 DNS 繞過。strict-route 會更嚴格地限制路由行為，可能改善洩漏問題，也可能影響多網卡、虛擬機器與區域網路存取。

stack 參數決定 TUN 網路堆疊的實作。不同系統與用戶端提供的選項可能包括 system、gVisor 或 mixed。system 通常更接近系統網路堆疊，效能與相容性取決於平台；gVisor 使用使用者空間網路堆疊，在部分環境中的隔離與相容性表現不同；mixed 會依協定組合處理。沒有明確故障時，優先使用用戶端推薦值，不必為了追求理論上的差異而頻繁切換。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

此範例只展示通用結構。設定檔中的具體欄位支援情況由目前核心與用戶端決定，圖形介面產生的設定可能還包含裝置名稱、MTU、路由包含項目與排除項目。使用訂閱覆寫時，應確認合併結果沒有重複定義 tun 區塊，否則後出現的欄位可能覆蓋前面的設定。

啟用後的驗證順序

啟用 TUN 後先保持系統代理關閉，以便確認目前流量由哪條路徑接管。存取一個一般網頁，觀察連線記錄是否出現網域請求；再測試先前不遵循系統代理的應用程式。接著檢查區域網路裝置、DNS 解析與常用登入服務。如果網頁可用但區域網路失效，重點檢查私有網段路由與 strict-route；如果所有網域都無法解析但直接存取 IP 有回應，重點檢查 DNS 劫持、監聽連接埠與上游解析。

命令列可以協助檢查系統路由，但不了解作用時不要手動刪除整套路由。Windows 可使用 route print 或 PowerShell 查看介面，macOS 與 Linux 可使用 netstat -rn、route -n get 或 ip route。比較啟用前後的預設路由與虛擬介面，確認流量確實進入 TUN。更完整的原理與操作路徑請見Clash TUN 模式啟用方法。

異常時如何安全退出

若啟用後網路完全中斷，先關閉 TUN，等待路由恢復，再關閉系統代理並退出用戶端。仍無法恢復時，重新連線 Wi-Fi 或網路線，讓系統重新取得位址與 DNS；接著檢查系統代理是否殘留、虛擬網卡是否仍啟用。不要在網路中斷時連續重裝多個用戶端，因為舊服務、舊網卡與新設定疊加後會增加判斷難度。

休眠喚醒、切換網路，或從公司網路回到家用網路後，自動識別介面可能暫時保留舊路由。先切換一次 TUN 開關，讓用戶端重建介面。如果問題固定發生在某類網路，記錄當時的實體介面、DNS、路由與日誌，再決定是否使用介面排除、路由排除或不同 stack。企業 VPN 與 TUN 同時使用時尤其容易發生路由優先順序衝突，通常應明確哪個工具負責哪些目標網段。

建立日常維護、排錯與進階路線

完成設定後，穩定使用仰賴的是可重複的維護習慣，而不是持續調整參數。建議保留一套已驗證可用的基礎狀態：一個正常的訂閱、一組明確的代理群組選擇、規則模式、可運作的系統代理，以及依需求啟用的 TUN。每次更新用戶端、訂閱或自訂規則後，只需檢查這條基礎鏈路是否仍然成立。若多個環節同時變更，發生異常時很難回到確定狀態。

日常更新分為三個層次

用戶端更新、核心更新與訂閱更新是三件不同的事。用戶端更新會改變介面、系統整合與核心管理方式；核心更新可能帶來設定語法、協定與網路處理上的變化；訂閱更新只會重新整理遠端設定、節點與規則。遇到問題時應記錄最近變更的是哪一層。例如，只有更新訂閱後代理群組消失，應先查看新設定內容；更新用戶端後 TUN 服務無法啟動，則應檢查權限與服務狀態。

日常可以依較長的固定間隔更新訂閱，並在更新後確認目前設定仍被選取。升級用戶端前記下訂閱網址、自訂覆寫與關鍵設定。升級後不要立刻刪除舊設定，先完成一次瀏覽器存取、連線記錄、區域網路與 TUN 測試。對長期執行的裝置而言，可在維護時段主動重新啟動一次用戶端，及早發現服務自動啟動、權限或設定載入問題。

用日誌與連線記錄縮小範圍

連線記錄回答「某次請求經過了哪裡」，日誌則回答「核心在處理過程中發生了什麼」。網站出口不正確時優先查看連線記錄；訂閱解析、連接埠繫結、DNS 查詢、TUN 初始化與網路錯誤則更適合查看日誌。排查時先將日誌層級維持在 info，通常已包含足夠資訊；debug 會產生大量記錄，只在需要重現短暫問題時暫時開啟，完成後恢復原設定。

擷取日誌時保留錯誤前後少量上下文，並移除訂閱網址、驗證欄位、裝置識別資訊與不必要的存取記錄。常見關鍵字包括 timeout、connection refused、network unreachable、address already in use、parse error 與 permission denied。它們分別指向逾時、目標拒絕、沒有路由、連接埠占用、設定解析與權限問題。先依錯誤類別處理，再考慮更換用戶端。

一套穩定的故障定位樹

1. 確認原始網路。關閉系統代理與 TUN，檢查一般網路是否可以存取本機與常用網站。原始網路異常時，先處理 Wi-Fi、網路線、驗證頁面或系統 DNS。
2. 確認核心狀態。啟動用戶端，檢查是否有設定解析、連接埠占用或權限錯誤。核心未執行時，後續模式與節點設定都不會生效。
3. 確認設定鏈路。查看訂閱更新時間、目前選取的設定、主要代理群組與最終節點。必要時手動更新訂閱，但不要連續重複請求。
4. 確認流量接管。開啟系統代理並發出新請求，觀察連線記錄。沒有記錄表示應用程式未使用系統代理，或本機連接埠設定異常。
5. 確認規則與出口。比較規則模式與全域模式的結果，查看目標網域命中的規則。全域可用而規則失敗時，集中處理分流問題。
6. 最後檢查 TUN。基礎鏈路正常後再啟用 TUN，分別測試 DNS、區域網路、UDP 與休眠恢復，不要一次加入多個變數。

如果需要依具體症狀繼續排查，可進入疑難解答尋找系統代理、訂閱、TUN 與連線問題。描述故障時最好包含平台、用戶端名稱、接管方式、代理模式、是否能在連線記錄看到請求，以及錯誤類型；這些資訊比一句「無法上網」更容易得到準確結論。

哪些內容備份後才真正有用

值得備份的內容包括訂閱網址清單、自訂規則覆寫、自訂 DNS 片段、核心服務設定，以及關鍵設定的簡短說明。若用戶端支援匯出設定，可以作為輔助，但不要把單一匯出檔當成唯一的復原方式。不同用戶端之間遷移時，最通用的仍是訂閱 URL 與標準 YAML 片段。

自訂設定應附上修改原因。例如，某條網域規則用於解決哪個服務、某個區域網路網段為何需要排除、某項 TUN 參數是針對什麼網路環境。數月後重新查看時，這些說明能協助判斷規則是否仍有必要。沒有原因記錄的設定容易越積越多，最後出現重複、衝突與順序難以理解的問題。

從日常使用走向進階設定

進階學習可以沿著連線處理順序展開：先熟悉代理群組的 select、url-test 與 fallback，再學習規則集與規則提供器，接著理解 DNS 的 fake-ip、分流解析與 IPv6，最後研究 TUN 路由、程序規則與獨立核心部署。每個階段都應有明確情境，不必一次啟用所有功能。能夠透過連線記錄解釋一個請求為何選擇某個出口，比記住大量參數更重要。

需要在多台裝置上使用時，可以將穩定的自訂規則維護為獨立覆寫檔，減少直接修改遠端訂閱主體。伺服器環境則應進一步學習最小監聽範圍、服務使用者權限、設定目錄權限、日誌管理與啟動失敗復原。圖形用戶端使用者也可以了解 YAML 基礎，以便看懂合併結果與解析錯誤，但日常修改仍優先使用用戶端提供的結構化入口。