Clash 從零開始到熟練的使用手冊

第一章

核心概念：先看清一條連線經過什麼

客戶端、核心與設定檔的分工

Clash 生態通常由三個部分組成：圖形客戶端負責按鈕、設定管理與系統權限；Mihomo 等核心負責監聽連接埠、解析規則、建立代理連線與轉送流量；設定檔則負責描述節點、策略組、規則、DNS 與 TUN 參數。使用者在介面中點選「系統代理」或「TUN 模式」時，實際上是由客戶端修改系統網路設定，再將對應參數交給核心執行。理解這層關係後，排障時就不會只盯著介面上的連線開關。介面顯示正在執行，只能表示核心程序已啟動，並不代表訂閱有效、策略選擇正確、DNS 正常，或目標應用程式已進入代理路徑。

圖形客戶端與核心也不是同一個版本概念。客戶端更新通常帶來介面、平台適配與設定管理能力，核心更新則更著重於協定、規則行為、DNS 與網路堆疊。部分客戶端內建核心更新入口，部分客戶端則將核心隨安裝套件一併發布。日常使用不必追逐每次更新，但遇到設定欄位無法識別、協定握手失敗或新系統相容性問題時，應分別確認客戶端與核心狀態，不要把兩者混稱為一個「Clash 版本」。

流量入口、策略判斷與出口

一條典型連線可以拆成四個步驟。第一步，瀏覽器或應用程式將請求交給系統代理連接埠，或由 TUN 虛擬網卡攔截；第二步，核心解析目標網域、IP、程序或網路類型；第三步，規則由上至下匹配，並將請求送入某個策略組；第四步，策略組選擇具體代理節點、直連或拒絕動作。任何一步中斷，表面上都可能呈現為網頁無法開啟。系統代理未啟用屬於入口問題，規則順序錯誤屬於判斷問題，節點無法使用屬於出口問題，而 DNS 回應異常則可能發生在判斷之前。

常見監聽連接埠包括 HTTP、SOCKS5 與 mixed-port。HTTP 連接埠適合明確支援 HTTP 代理的程式，SOCKS5 連接埠適合支援 SOCKS 的工具，mixed-port 則可在同一個連接埠同時接受兩類請求。多數圖形客戶端已經管理這些連接埠，一般使用者不需要自行修改。只有在連接埠被其他程式佔用、區域網路裝置需要接入，或命令列工具需要手動指定代理時，才需要查看目前的監聽位址與連接埠。監聽於 127.0.0.1 時僅本機可存取；開放區域網路存取會擴大可連線範圍，應同時確認防火牆與存取控制。

設定、訂閱與執行狀態不是一回事

訂閱是由遠端維護的設定來源，設定檔是客戶端下載後保存在本機的具體內容，而執行狀態則是核心載入某份設定後的結果。訂閱網址可以正常存取，但回傳內容未必符合目前核心的語法；設定可以成功解析，但其中的節點可能已失效；節點可以建立連線，但規則仍可能將目標請求送往直連。檢查時應依序確認「訂閱是否更新成功—設定是否載入成功—策略組是否有可選項目—請求是否命中預期規則—出口是否可用」。按層次檢查，比反覆切換總開關更快。

完成本章後，先記住一個判斷原則：連線問題不是單一開關問題。後續每項設定都應放回「入口、判斷、出口」這條路徑中理解。如此一來，無論使用 Windows、macOS、Android、iOS 或 Linux，即使介面名稱不同，排查順序仍可保持一致。

第二章

選擇客戶端：依平台、權限與維護方式決定

優先選用圖形客戶端，而不是直接執行核心

一般桌面與行動裝置應優先使用圖形客戶端。它會處理設定儲存、系統代理、開機啟動、日誌檢視、核心啟停與權限申請，發生錯誤時也更容易確認目前狀態。本網站各平台首推 Clash Plus，適合希望透過統一介面完成訂閱匯入、策略切換與基礎網路接管的使用者。Windows 與 macOS 也可選擇 Clash Verge Rev、FlClash；Windows 可選 Clash Nyanpasu，並保留已停止維護的 Clash for Windows 作為封存選項；macOS 另有已停止維護的 ClashX Meta。完整客戶端列表、平台入口與目前安裝套件，請前往下載頁查看。

Android 可在 Clash Plus、Clash Meta for Android、FlClash 與 Surfboard 之間選擇。行動端需要留意系統 VPN 權限、背景執行限制與省電策略，不能只比較介面。iOS 使用 Clash Plus 的 App Store 版本，系統會透過 VPN 設定接管流量。Linux 桌面環境可使用 Clash Verge Rev 或 FlClash；伺服器、路由器、容器與沒有桌面環境的裝置，則更適合直接部署 Mihomo 核心並使用設定檔管理。

選擇時留意三個實際條件

第一是系統架構。Windows 常見為 x64，少數裝置為 ARM64；採用 Apple 晶片的 Mac 應選擇 Apple Silicon 或 ARM 架構套件，較早的 Intel Mac 則選擇 x64 套件。Linux 除了發行版格式外，還要確認 CPU 架構，不能混用 AMD64、ARM64、ARMv7 或 MIPS 套件。系統架構不確定時，應先在系統資訊中確認，不要靠檔名猜測。安裝套件可以下載但無法啟動時，架構不相容是優先檢查項目之一。

第二是需要接管的應用程式範圍。只代理瀏覽器及遵循系統代理的程式時，一般系統代理已經足夠；遊戲、命令列工具、商店應用程式、虛擬機器或不讀取系統代理設定的軟體，可能需要 TUN。第三是維護方式。桌面使用者通常需要圖形化的訂閱更新與策略選擇，伺服器使用者則更重視設定檔、服務程序、遠端日誌與自動重啟。功能最多的客戶端不一定最穩定；能滿足目前需求、更新路徑清楚且日誌易讀，通常更重要。

避免多個客戶端同時接管系統

同一台裝置可以安裝多個客戶端進行比較，但不應同時啟用系統代理或 TUN。兩個核心可能爭用監聽連接埠，兩個客戶端也可能輪流改寫系統代理，造成介面看似已啟用，實際連接埠卻指向另一個程序。切換客戶端前，先關閉舊客戶端的系統代理與 TUN，確認程序已退出，再啟動新客戶端。若新客戶端提示連接埠佔用，應查明佔用程序，而不是連續改成隨機連接埠，因為瀏覽器、環境變數或其他工具可能仍指向舊連接埠。

封存客戶端適合相容舊設定或臨時遷移，不適合作為新安裝的預設起點。停止維護不代表現有安裝會立即失效，但作業系統升級、協定變更與核心欄位更新，都可能逐漸產生相容性問題。遷移時先匯出本機覆寫規則、記錄策略選擇與連接埠設定，再在新客戶端中匯入訂閱；不要直接複製整個程式目錄，以免連同舊核心、快取與系統整合狀態一併帶入。

第三章

安裝與初始化：先建立可回復的基礎狀態

安裝前清理衝突狀態

安裝前先退出正在執行的其他代理客戶端，並關閉其系統代理、TUN 或 VPN 設定。Windows 可在系統網路設定中檢查手動代理是否仍指向舊連接埠；macOS 可查看目前網路服務的代理選項；行動裝置則檢查狀態列中的 VPN 是否仍由其他應用程式維持。保留舊客戶端沒有問題，但首次初始化最好只讓一個程式控制網路。如此一來，安裝後若無法存取網路，就能明確判斷問題來自新客戶端，而不是兩個程式疊加造成。

下載時依照作業系統與架構選擇檔案。Windows 安裝套件通常會透過安裝精靈寫入使用者目錄或程式目錄；macOS 應將應用程式放入「應用程式」，首次開啟可能需要在系統隱私權與安全性設定中確認；Linux 的 deb 或 rpm 套件應對應發行版，便攜版套件與核心壓縮檔則需要自行安排路徑與執行權限。Android 安裝後會要求 VPN 權限，iOS 從 App Store 安裝後也會在首次連線時建立 VPN 設定。這些權限用於建立本機流量入口，拒絕後客戶端仍可開啟，但無法真正接管網路。

首次啟動只進行最少設定

第一次啟動不建議立刻修改連接埠、DNS、TUN 堆疊與大量覆寫項目。先保留預設監聽位址與連接埠，確認客戶端能夠啟動核心，並找到日誌、設定清單、代理策略與連線記錄的入口。接著匯入一份有效訂閱，選擇其中一個可用策略，再啟用系統代理。此時用瀏覽器開啟一般網頁，觀察連線記錄是否出現新請求。如果連線清單完全沒有變化，表示流量尚未進入客戶端，應先檢查系統代理，而不是更換節點。

Windows 上若客戶端需要安裝服務模式或網路元件，應依照介面提示完成授權。服務模式通常用於以較高權限管理 TUN、路由或系統設定，安裝後可能需要重新啟動客戶端。macOS 的網路延伸功能或輔助服務同樣需要系統確認。Linux 桌面環境中，系統匣、系統代理寫入與 TUN 權限依賴桌面工作階段與系統服務；只從終端機啟動圖形客戶端時，應留意關閉終端機後程序是否也隨之退出。

用可觀察訊號驗證安裝結果

安裝成功不能只看視窗是否出現。至少確認四個訊號：核心日誌沒有持續重複的啟動錯誤；本機監聽連接埠已建立；訂閱設定可以載入；啟用系統代理後，連線記錄能看到瀏覽器請求。若日誌提示位址已被佔用，可在 Windows 使用 netstat，在 macOS 或 Linux 使用 lsof 查看連接埠歸屬。以下指令只負責定位本機監聽狀態，不會修改網路設定：

Windows:
netstat -ano | findstr LISTENING

macOS / Linux:
lsof -nP -iTCP -sTCP:LISTEN

如果連接埠由舊客戶端佔用，先退出對應程序，並還原舊客戶端改寫過的系統代理。若連接埠沒有監聽但客戶端顯示正在執行，應開啟核心日誌，尋找設定解析失敗、權限不足或核心檔案遺失。不要一開始就關閉防火牆或安全性設定；先依據明確日誌定位，因為本機迴路連接埠無法建立與遠端連線遭阻擋是兩類問題，處理方式不同。

行動裝置驗證還要考慮系統背景限制。Android 在螢幕關閉後斷線，常見原因是電池最佳化、背景活動限制或系統清理程序；可以允許客戶端在背景執行，並確認 VPN 常駐狀態。iOS 在 Wi-Fi 與行動網路切換時可能觸發網路重建，短暫重新連線屬於系統行為；若長時間沒有恢復，應回到客戶端查看目前設定與策略，而不是反覆刪除 VPN 設定。

保留這個最小可用狀態非常重要。後續啟用規則覆寫、TUN 或 DNS 後，如果網路異常，可以逐項退回「預設設定加系統代理」的狀態。一次修改多個模組雖然省步驟，但出現問題時無法確認是哪一項造成，最後往往只能重裝；而重裝也不會自動清除系統代理、服務與本機設定。

第四章

訂閱與設定：更新來源、載入結果與本機修改

匯入訂閱後的第一輪檢查

訂閱匯入通常透過 URL、剪貼簿或本機檔案完成。新增後先手動更新一次，確認客戶端顯示更新時間，並檢查代理策略頁是否出現節點與策略組。只看到訂閱名稱不代表內容已成功下載；訂閱網址過期、網路無法存取、回應格式錯誤或轉換結果不相容，都可能留下空的設定項目。更新失敗時，先查看客戶端日誌中的 HTTP 狀態、解析提示與儲存路徑，不要連續重複點選更新。

訂閱 URL 往往包含存取憑據，應像帳戶密碼一樣保存，不要放入公開截圖、問題討論或日誌附件中。更換裝置時可以透過可信管道重新取得網址，而不是長期從瀏覽器歷史記錄或聊天記錄複製。匯出設定也要區分來源：完整匯出可能包含訂閱網址與節點參數；只匯出本機規則或覆寫內容，更適合遷移個人設定。

遠端設定與本機覆寫的界線

直接編輯訂閱下載後的 YAML，通常不是長期方案。下一次更新會以遠端內容覆蓋本機檔案，手動新增的規則、DNS 或策略組可能隨之消失。支援覆寫、合併或擴充腳本的客戶端，應將個人規則放在獨立覆寫層；不支援覆寫時，可以將訂閱設定複製為本機設定，但必須接受它不會繼續自動同步遠端變更。維護前先弄清楚客戶端採用的是「覆蓋更新」、「合併更新」還是「產生執行設定」，否則很容易出現介面中修改過、重新啟動後卻恢復原狀的情況。

標準 YAML 使用縮排表達層級，不能混用定位字元。清單項目以連字號開頭，字串中含有冒號、井號或特殊字元時，最好加上引號。設定載入失敗時，錯誤常指向後續行，真正原因可能是上一行縮排錯誤或引號未閉合。修改後先做小範圍測試，每次只改一個模組，並保留上一份可載入檔案。以下是一段用於理解結構的最小範例，伺服器位址採用文件保留位址，不能用於實際連線：

mixed-port: 7890
mode: rule
log-level: info
allow-lan: false

proxies:
  - name: "範例節點"
    type: socks5
    server: 192.0.2.10
    port: 1080
    username: "demo-user"
    password: "your-password"

proxy-groups:
  - name: "手動選擇"
    type: select
    proxies:
      - "範例節點"
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,手動選擇
  - MATCH,DIRECT

設定中的名稱必須一致。規則指向「手動選擇」時，策略組必須存在同名項目；策略組引用「範例節點」時，節點名稱也必須完全相符，包括空格與大小寫。常見載入錯誤不是協定參數本身，而是重新命名節點後忘記同步策略組，或複製規則時保留了設定中不存在的組名。中文名稱可以正常使用，但跨工具轉換時，簡短且穩定的名稱更容易維護。

訂閱更新失敗的分層處理

先確認裝置在不依賴該訂閱設定的情況下，能否存取訂閱網址。部分情況下，舊設定失效後訂閱更新也會跟著失敗，可以暫時關閉代理並以直連方式更新，或切換到另一份可用設定再更新。若回傳的是網頁、登入頁或錯誤提示，而不是設定內容，應回到訂閱來源處理授權，不要嘗試將網頁儲存成 YAML。若下載成功但解析失敗，檢查訂閱是否面向其他客戶端格式，或是否包含目前核心不支援的欄位。

訂閱轉換應視為設定產生流程，而不是節點修復工具。轉換可以重組策略組、規則與欄位，但不能讓失效節點恢復，也不能改變訂閱本身的權限。使用轉換時記錄範本來源、目標格式與更新方式，避免數個月後無法說明某條規則的來源。涉及存取憑據時，更應確認處理鏈路與儲存位置，盡量在自己可控制的環境中完成。

設定管理的目標不是儲存越多檔案越好，而是能說明目前執行的是哪一份、從何處更新，以及哪些內容由本機追加。建議為本機設定清楚寫明用途，例如「桌面日常」、「僅系統代理測試」、「TUN 排障」，並刪除長期不用的重複副本。設定過多時，誤選舊檔案往往比規則本身更難察覺。

第五章

代理模式：如何選擇規則、全域與直連

規則模式是日常預設選擇

規則模式會依照設定中的規則逐條判斷請求，決定使用某個策略組、直接連線或拒絕。它適合長期使用，因為不同網站與應用程式可以採用不同出口，本機服務、區域網路位址與不需要代理的流量也能維持直連。規則模式是否符合預期，取決於規則集內容、順序、DNS 結果與策略組選擇。它不是會自動判斷所有網路環境的黑盒；當某個位址走錯出口時，應查看連線詳情中的命中規則，而不是直接將整個客戶端長期改為全域模式。

連線記錄通常會顯示目標網域或 IP、匹配規則、策略鏈與最終節點。排查單一網站時，先清除或篩選連線清單，再重新發起請求，觀察新連線。瀏覽器可能同時請求主網域、靜態資源、登入介面與第三方服務，頁面異常不一定由主網域造成。只有找到失敗連線及其命中規則，才能判斷是規則缺失、策略組選擇錯誤，還是節點本身無法使用。

全域模式用於隔離規則問題

全域模式通常會將絕大多數可接管流量送往指定策略或節點，適合短時間驗證出口。如果規則模式下某個網站無法存取，而全域模式下恢復，表示節點具備連線能力，問題更可能位於規則匹配、DNS 或策略組路徑。若全域模式同樣失敗，則優先檢查節點、協定、系統時間與網路環境。全域模式是一種診斷工具，也可用於需要統一出口的臨時情境，但它會繞過原有分流設計，區域網路、本機服務與不需要代理的流量可能受到影響。

切換全域模式後要確認全域策略組選中了什麼。部分設定會將「GLOBAL」組設為可選清單，仍需手動指定節點；只切換模式但沒有選擇有效出口，結果可能與規則模式相同。測試結束後切回規則模式，並重新開啟目標應用程式。某些程式會沿用已建立的長連線，模式切換不會讓舊連線立即改變路徑，瀏覽器可以關閉相關分頁或等待連線重建。

直連模式用於確認本地網路

直連模式會讓被接管的請求不經代理節點直接存取。它適合判斷基礎網路、DNS 與目標服務在目前網路中是否可達，也適合暫停代理時保持客戶端執行以觀察連線。直連模式不等於關閉系統代理：流量仍可能進入核心，只是最終動作為 DIRECT。因此若要徹底退出客戶端，應關閉系統代理或 TUN，並確認系統網路設定已恢復。

若直連模式也無法存取一般網站，問題可能出在本地網路、DNS、系統路由、防火牆，或仍殘留的其他 VPN。此時繼續更換代理節點沒有意義。反過來，直連正常、全域失敗，通常指向節點或代理協定；直連正常、全域正常、規則失敗，則應重點檢查規則與策略組。這種三模式對照法可以快速縮小範圍，但每次測試應使用相同目標、相同網路與新建連線，避免快取干擾。

策略組決定最終出口

模式只決定如何進入策略判斷，策略組才決定具體使用哪個出口。常見策略組類型包括手動選擇、自動測速、故障轉移與負載分配。手動選擇最容易理解，適合重要情境；自動測速會依據測試位址與間隔選擇結果較好的節點，但測試延遲不等於實際存取速度；故障轉移會在目前節點無法使用時切換至備用項目，更適合重視連續性的設定。不同客戶端對策略組類型的中文名稱可能不同，應以設定中的 type 為準。

自動選擇不能取代實際驗證。測試位址可達，只表示節點能完成該測試請求；目標網站可能使用不同線路、協定或地區策略。遇到節點延遲看似正常但網頁很慢時，查看實際連線的建立時間、下載過程與丟包情況，並手動比較少量節點。頻繁設定過短的測速間隔會增加背景請求，也可能導致策略在節點間反覆切換。日常設定更適合使用合理間隔，並為重要策略保留手動選擇能力。

第六章

規則分流：匹配順序、規則類型與覆寫方法

規則由上至下匹配，首次命中即停止

Clash 規則最重要的行為是順序。請求從規則清單頂部開始檢查，命中第一條後就採用該規則指定的策略，不再繼續向下。具體網域規則通常應放在較寬泛的網域後綴、GeoIP 或最終兜底之前。若寬泛規則提早命中，後面的精確規則即使寫得正確也不會執行。排查「自訂規則未生效」時，先在連線記錄中查看實際命中了哪一條，再回到規則清單比較位置。

常見規則包括 DOMAIN 精確網域、DOMAIN-SUFFIX 網域後綴、DOMAIN-KEYWORD 網域關鍵字、IP-CIDR IPv4 網段、IP-CIDR6 IPv6 網段、GEOIP 地理 IP 分類、PROCESS-NAME 程序名稱，以及最終的 MATCH。網域規則在網域仍可見時判斷最直接，IP 規則依賴解析結果，程序規則則依賴平台與接管方式，不是所有系統與客戶端都能提供一致的程序識別能力。

從精確條件寫到寬泛兜底

新增規則時先確定目標：是一個具體主機、整個網域後綴、一段 IP，還是某個應用程式程序。能用精確網域解決時，不要直接使用過寬的關鍵字，因為關鍵字可能誤傷包含相同片段的其他網域。網域後綴規則會涵蓋主網域及其子網域，適合結構穩定的服務。IP 網段規則適合沒有網域資訊，或明確按位址分流的服務，但位址可能隨 CDN 與網路區域變化，需要後續維護。

rules:
  - DOMAIN,api.example.com,工作策略
  - DOMAIN-SUFFIX,example.net,手動選擇
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,手動選擇

no-resolve 用於告訴核心在匹配該 IP 規則時，不要為了判斷而額外解析網域，適合私有網段等明確的位址條件。是否新增要視規則類型與實際需求而定，不應機械式地附加在所有規則後。MATCH 是最終兜底，通常放在末尾；前面沒有命中的請求都會進入指定策略。若把 MATCH 放在中間，後續規則將永遠沒有機會執行。

規則集與 Geo 資料需要可追蹤

大型設定通常透過 rule-providers 引用規則集，避免在主設定中塞入數千甚至數萬條規則。規則集便於獨立更新，但也增加了來源、行為與更新時間三個變數。使用前應了解規則集涵蓋哪些類別、採用何種格式、由哪個策略引用，以及更新失敗時是否繼續使用快取。不要同時疊加多個範圍高度重疊的規則集，否則同一網域命中哪一份會取決於排列順序，後續很難說明。

GeoIP 與地理網站分類依賴本機資料檔案。資料過時時，新分配的位址或新網域可能分類不準確；資料下載失敗時，客戶端也可能繼續使用舊快取。進行 Clash GeoIP 更新時，應先查看客戶端是否提供資料更新入口，再確認日誌中的下載與載入是否成功。更新後若分流行為突然改變，應比較更新前後的命中規則，不要只憑目標網站的頁面內容或公司所在地推測 IP 分類。

本機覆寫要放在正確的插入點

客戶端提供的「前置規則」、「後置規則」、「合併規則」意義可能不同。前置規則通常插入遠端規則之前，適合需要優先命中的個人規則；後置規則若位於遠端 MATCH 之後，實際上不會生效。使用覆寫功能時，先查看最終產生的執行設定或日誌中的規則順序，確認自訂內容真正進入 MATCH 之前。只在編輯框中看見規則，不代表核心載入後的排列相同。

規則除錯應從一個目標開始。清除連線篩選，存取目標網域，記錄網域、解析 IP、命中規則、策略組與最終節點。接著只調整一條規則，重新載入設定並建立新連線。瀏覽器 DNS 快取、連線重用與服務工作執行緒都可能保留舊路徑，必要時關閉相關頁面或重新啟動目標應用程式。更完整的語法與覆寫案例，請繼續閱讀Clash 自訂規則語法詳解。

第七章

TUN 與 DNS：接管更多流量並保持解析一致

系統代理與 TUN 的接管範圍不同

系統代理主要影響讀取作業系統代理設定的應用程式，瀏覽器與部分桌面軟體通常支援良好，但遊戲、命令列工具、商店應用程式、虛擬機器程式或自行實作網路堆疊的軟體可能繞過。TUN 會建立虛擬網路介面，透過系統路由將更多 IP 流量交給核心，因此覆蓋範圍更廣。它不是「更快的系統代理」，而是另一種入口機制，也會帶來路由、DNS、權限、區域網路與其他 VPN 的相容性問題。

首次啟用 TUN 前，應確保系統代理模式已能正常運作。如此可以證明訂閱、節點與基本規則大致有效，TUN 失敗時就能將範圍縮小到權限、虛擬網卡、路由與 DNS。若一開始同時啟用 TUN、自訂 DNS、IPv6 與多套覆寫，發生斷網後很難知道是哪一層造成。建議先關閉系統代理，只啟用預設 TUN 參數測試；確認請求進入連線記錄後，再逐項調整 DNS 與繞過規則。

權限、路由與網路堆疊參數

TUN 需要建立虛擬介面並修改系統路由，因此桌面系統通常要求管理員權限、輔助服務或網路延伸功能。Windows 上要留意服務模式、驅動程式狀態與其他 VPN；macOS 要確認網路延伸功能授權；Linux 需要 TUN 裝置及相應 capability 或管理員權限。權限不足時，日誌通常會出現建立介面、設定路由或存取裝置失敗。此時反覆更換節點不會改變結果，應先處理系統權限。

常見 TUN 堆疊名稱包括 system、gVisor 或 mixed，實際可用值取決於核心與客戶端。system 更依賴作業系統網路堆疊，gVisor 在使用者空間處理更多網路行為，mixed 則按協定組合處理。沒有明確問題時保留客戶端預設值。遇到特定應用程式無法連線、UDP 異常或休眠恢復後網路不通，可以在記錄原值後切換堆疊進行對照，但每次只修改一項，並重新啟動核心，讓虛擬介面重新建立。

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

auto-route 負責自動寫入路由，auto-detect-interface 用於識別目前的預設網路介面。裝置同時連接有線網路、Wi-Fi、虛擬機網卡與其他 VPN 時，自動識別可能選錯出口；通常表現為啟用 TUN 後所有連線逾時。可以先退出其他網路工具並重新啟用 TUN，觀察預設介面的變化。strict-route 會加強路由約束，可能減少流量繞行，但也更容易影響區域網路、虛擬機或特殊路由，首次設定不宜盲目啟用。

DNS 模式決定網域如何進入規則

DNS 不只是將網域轉換為 IP，它還會影響規則能否看見網域、連線使用哪個出口，以及是否發生解析路徑不一致。Clash DNS 常見的增強模式包括 redir-host 與 fake-ip。redir-host 更接近回傳實際解析結果；fake-ip 會先回傳保留位址映射，再由核心在連線階段還原網域，方便將網域資訊保留到規則匹配。少數區域網路服務、裝置探索、遊戲或依賴真實 IP 的程式，可能需要加入 fake-ip-filter。

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  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"
    - "time.*.com"

範例中的公共解析器只是語法展示，實際選擇應結合所在網路、設定規則與隱私需求。若設定支援按代理與直連路徑拆分 DNS，應確保用於解析代理目標伺服器的解析器不會反過來依賴尚未建立的代理，避免啟動迴圈。遇到 Clash DNS 洩漏疑慮時，不要只看單一檢測網頁的結論；先確認系統 DNS 請求是否已由 TUN 或 DNS 劫持接管，再查看核心日誌、目前監聽連接埠，以及實際請求發往哪個解析器。瀏覽器內建的加密 DNS 也可能繞過系統路徑，應納入檢查。

TUN 故障應優先恢復網路

啟用 TUN 後完全斷網，先關閉 TUN 並確認路由恢復；若關閉後仍無法連網，退出客戶端，檢查系統中是否殘留虛擬介面、代理設定或其他 VPN。接著重新啟動客戶端，只用系統代理驗證基礎連線。基礎連線正常後，再檢查 TUN 日誌中的介面建立、預設路由、DNS 監聽與權限錯誤。區域網路裝置無法存取時，檢查私有網段是否維持 DIRECT、嚴格路由是否攔截，以及區域網路位址是否被 fake-ip 處理。

休眠喚醒、Wi-Fi 切換或從有線網路切換至個人熱點後斷網，常見原因是預設介面與路由發生變化。先等待客戶端自動重建，未恢復時關閉再開啟 TUN；若頻繁發生，查看客戶端是否支援網路變更重新載入，並檢查 auto-detect-interface。若系統同時執行容器、虛擬機或遠端接入工具，應記錄它們建立的網段，避免 TUN 路由覆蓋。TUN 穩定的標準不是開關能點亮，而是在切換網路、休眠恢復與存取區域網路時，都能得到可解釋的結果。

第八章

日常維護與故障排查：從設定有效性開始

建立輕量維護節奏

日常維護不需要每天修改設定。更可靠的做法是定期更新訂閱與規則資料，更新後進行一次最小驗證：設定能否載入、常用策略組是否有節點、規則模式下普通網頁是否可存取，以及連線記錄是否符合預期。客戶端或核心更新前，記錄目前設定、TUN 狀態、連接埠與本機覆寫；更新後先驗證基礎連線，再恢復複雜選項。若工作環境要求穩定，可以稍後再跟進新功能更新，但遇到系統升級或協定相容性問題時，應查看目前維護狀態。

備份重點是本機新增內容，而不是快取。建議保存訂閱來源的取得方式、本機覆寫規則、DNS 調整、策略組修改與服務設定。若節點清單完全由訂閱產生，無需長期複製多個快照；真正需要保留的是那些無法從訂閱重新取得的個人設定。備份檔案應標註用途與日期，並避免公開其中的訂閱網址、節點憑據與區域網路資訊。

已連線但無法上網的固定順序

第一步檢查設定是否成功載入，以及策略組是否存在可用選項。第二步切換至直連模式驗證本地網路，再切換至全域模式並選擇一個明確節點，排除規則影響。第三步確認系統代理或 TUN 是否真的接管流量：若連線記錄沒有新請求，問題在入口；若有請求且快速失敗，查看規則、策略鏈與錯誤類型。第四步檢查 DNS，比較網域存取與直接 IP 連線的表現。第五步檢查連接埠衝突、TUN 權限、其他 VPN、防火牆與系統時間。

「已連線」通常只代表節點握手成功或客戶端正在執行，不代表每個目標都可達。若只有一個網站失敗，先查看該網站涉及的多個網域與命中規則；若所有網站都失敗，再檢查出口與系統網路。若瀏覽器可用但命令列無法使用，確認命令列工具是否讀取系統代理，或為目前終端機設定代理環境變數。臨時測試可以使用本機 mixed-port，連接埠以客戶端實際顯示為準：

Windows PowerShell:
$env:HTTP_PROXY="http://127.0.0.1:7890"
$env:HTTPS_PROXY="http://127.0.0.1:7890"

macOS / Linux:
export HTTP_PROXY="http://127.0.0.1:7890"
export HTTPS_PROXY="http://127.0.0.1:7890"

環境變數只對目前終端機及其啟動的程序生效，關閉終端機後通常會失效。若客戶端連接埠不是 7890，應替換為實際值。測試結束後不要將臨時變數誤寫入全域 shell 設定，尤其是在客戶端不常駐的裝置上，否則日後關閉客戶端時，命令列會持續指向不存在的連接埠。更完整的逐項流程可參考Clash 已連線但無法上網排查清單。

延遲、逾時與速度問題要分開看

Clash 節點延遲測試通常會傳送一個較小的 HTTP 請求，結果受測試位址、DNS、握手方式與目前網路影響。延遲低不代表下載速度高，也不代表目標服務一定可用。逾時可能來自節點無法連線、測試位址遭阻擋、協定握手失敗或本地網路丟包。比較節點時，應使用相同測試位址與相近時間，並結合實際網頁或下載行為，不要只按一次排序結果判斷。

速度突然下降時，先確認是否只有單一目標受到影響，再比較直連、全域不同節點與規則模式。查看連線是否送往預期策略、節點是否頻繁自動切換，以及背景是否正在更新訂閱或規則。無線網路不穩定、系統省電、行動網路切換與其他下載工作也會影響結果。若只有晚間或特定線路出現問題，可能屬於網路路徑變化，頻繁重裝客戶端通常沒有幫助。

日誌只收集與問題時間相近的部分

排障時將日誌層級暫時調至 info 或 debug，重現一次問題後立即記錄時間、目標、模式與錯誤行。debug 日誌內容較多，不適合長期開啟，也不應未經處理直接公開。分享前刪除訂閱網址、節點伺服器、認證資訊、本機使用者名稱與檔案路徑。有效日誌應包含問題發生前後的啟動、DNS、規則匹配與連線錯誤，而不是只截取最後一句「timeout」。

HTTPS 憑證錯誤應先檢查系統時間、瀏覽器策略、系統憑證鏈與網路中間設備，再判斷是否與代理路徑有關。一般 Clash 轉送不要求為所有網站安裝解密憑證；若某軟體啟用了流量分析、腳本改寫或其他中間處理，則需要個別確認。可依照代理後 HTTPS 憑證錯誤處理方法逐層檢查，避免透過忽略憑證警告來繞過問題。

第九章

進階路線：從穩定設定走向可維護設定

先把個人需求寫成可驗證條件

進階設定不是堆疊更多規則與開關，而是將需求轉化為可驗證的行為。例如「工作網域始終使用固定策略」、「區域網路與開發環境維持直連」、「行動網路切換後 TUN 自動恢復」、「規則集更新失敗時仍可使用快取」。每個目標都應對應一組設定、一種觀察方式與一個回退方案。若無法說明某個覆寫要解決什麼問題，就先不要加入長期設定。

建議建立基線設定與實驗設定。基線只包含穩定訂閱、清楚的策略組、必要規則，以及已驗證的 DNS/TUN 參數；實驗設定則用於測試新規則集、不同網路堆疊或策略組行為。實驗成功後，再將單項變更移入基線。如此即使設定解析失敗或路由異常，也能快速切回可用狀態，不必從大量歷史修改中猜測原因。

使用 proxy-providers 管理動態節點

當節點來源與主設定分開維護時，可以用 proxy-providers 定義遠端或本機節點提供器，再讓策略組引用。如此策略組與規則可以保持穩定，節點清單則依計畫更新。提供器需要明確設定類型、路徑、更新間隔與健康檢查。快取路徑應避免多個提供器共用同一檔案，健康檢查位址也應選擇長期穩定、回應較小且符合實際網路條件的目標。

proxy-providers:
  primary:
    type: http
    url: "https://example.com/subscription"
    path: "./providers/primary.yaml"
    interval: 21600
    health-check:
      enable: true
      interval: 900
      url: "https://www.gstatic.com/generate_204"

proxy-groups:
  - name: "自動選擇"
    type: url-test
    use:
      - primary
    url: "https://www.gstatic.com/generate_204"
    interval: 600

範例位址只用於說明結構。實際訂閱網址應由可靠來源提供，並妥善保存。更新間隔不是越短越好：過短會增加遠端請求與本機重新載入，節點頻繁變化還可能中斷長連線。健康檢查同樣不代表完整可用性，只能證明節點能存取測試目標。重要業務仍應保留手動策略組，必要時將自動選擇作為候選，而不是唯一出口。

使用 rule-providers 拆分規則職責

規則數量增加後，可以依用途拆分為區域網路、工作、媒體、開發、直連與攔截等規則集。主設定只保留引用順序與最終策略，讓每份規則集的職責清楚。拆分時避免按網站逐一建立過細的檔案，否則維護成本會轉移到大量小檔案。更實用的界線是：更新來源相同、策略目標相同、維護週期相近的規則放在一起。

更新遠端規則集前應保留快取，並確認格式與 behavior 類型一致。domain、ipcidr 與 classical 規則集的內容結構不同，類型寫錯會導致解析失敗或匹配異常。規則集成功載入後，仍要透過連線記錄驗證幾個代表性目標。只看到下載成功，不能證明規則順序正確，也不能證明目標已進入預期策略。

核心部署需要補齊服務與權限管理

在伺服器或路由器上直接執行 Mihomo 時，圖形客戶端代為處理的工作需要自行完成，包括設定路徑、工作目錄、日誌、程序守護、啟動順序、更新與權限。先用前景命令載入設定，確認沒有語法錯誤，再交由系統服務管理。不要一開始就讓程序在背景靜默執行，否則啟動失敗時很難看到原因。設定中引用的相對路徑以工作目錄為基準；服務管理器使用的目錄若與手動測試不同，規則集與資料庫檔案可能找不到。

mihomo -t -f ./config.yaml
mihomo -d ./runtime -f ./config.yaml

第一條命令用於檢查設定，第二條指定執行目錄並載入檔案。實際可執行檔名稱與路徑以下載內容為準。服務帳戶應擁有讀取設定、寫入快取與建立必要網路介面的權限，但不應為了省事而對整個設定目錄開放不必要的寫入權限。設定變更後先執行檢查，再重新載入服務；若遠端裝置依賴該代理維持管理連線，更新前還要準備本機主控台或可回退路徑。

按階段擴展，而不是一次完成所有功能

可以將進階路線分成四個階段。第一階段穩定使用規則模式，能透過連線記錄解釋一次請求；第二階段整理本機覆寫與規則集，讓訂閱更新不會覆蓋個人設定；第三階段啟用並穩定 TUN、DNS 與網路切換；第四階段再考慮 provider、伺服器部署、自動更新與監控。每個階段都至少執行一段時間，確認日常網路、休眠恢復、區域網路與常用應用程式沒有異常後，再進入下一階段。

學習過程中應優先記錄現象與結論，而不是收藏大量未經驗證的設定片段。同一個欄位在不同核心、客戶端與作業系統上的預設值可能不同，複製前先確認目前執行設定。遇到 Windows 系統代理、訂閱與 UWP 回環問題，可查看Windows 安裝 Clash 全流程；需要重新整理首次初始化步驟時，可回到Clash 首次安裝設定清單。

後續每次變更都可以沿用同一套流程：寫清目標、備份基線、只修改一項、重新載入後查看日誌與連線記錄，再用直連、全域與規則模式進行對照。需要更換客戶端或重新安裝時，前往客戶端下載頁確認平台與架構；只需快速恢復首次連線時，依照快速入門教學重新建立最小狀態。系統手冊的作用不是讓設定變得複雜，而是讓每個開關都有明確位置，每次故障都有固定起點。