Clash 從入門到精通：安裝、訂閱、規則與 TUN

核心概念：先分清用戶端、核心與設定

Clash 不是單一安裝檔

「Clash」通常指一套圍繞規則代理形成的用戶端與核心生態，而不是只有一個固定介面的軟體。使用者直接操作的是圖形用戶端，例如 Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasu、Clash Meta for Android 或 ClashX Meta；真正負責建立代理連線、解析設定與比對規則的部分則是核心。目前常見用戶端多以 mihomo 核心為基礎運作，介面負責將核心能力整理成開關、清單與狀態頁。

理解這層關係很重要。介面無法開啟、訂閱無法更新與某條規則未生效，往往屬於不同層級的問題。介面當機應先檢查用戶端本身；協定或規則行為異常，則需查看核心記錄與設定；訂閱內容不完整，應先檢查訂閱來源。把三者混在一起排查，容易反覆重新安裝，卻始終找不到真正原因。

一條連線會經過哪些環節

應用程式發起網路請求後，流量需要先進入 Clash。系統代理透過作業系統提供的代理設定，引導支援該設定的應用程式；TUN 模式則建立虛擬網卡，從網路層接收更廣泛的流量。核心取得請求後，會辨識目標網域、目標 IP、連接埠與程序等資訊，再依照設定檔中的規則由上而下比對。比對結果會指向某個策略群組，策略群組再決定使用特定節點、直接連線或拒絕連線。

網域請求還會經過 DNS。DNS 不只是把網域轉換成 IP，也會影響規則能否看見原始網域、是否發生解析污染，以及 IPv4 與 IPv6 連線如何選擇。正常鏈路可簡化為：應用程式發起請求 → 系統代理或 TUN 接管 → DNS 取得位址或建立網域對應 → 規則比對 → 策略群組選擇出口 → 節點建立連線。後續章節中的大多數設定，都是在調整這條鏈路的某一段。

訂閱、設定檔與節點的差異

訂閱連結是取得設定內容的入口。用戶端存取訂閱連結後，伺服器可能直接回傳完整 YAML，也可能回傳經過編碼的節點清單。完整設定通常包含代理節點、策略群組、規則、DNS 與其他核心參數；只有節點清單的訂閱，則需要用戶端範本或訂閱轉換服務補齊策略群組與規則。節點只是連線出口，不能取代完整設定。

本機儲存的設定檔通常以 YAML 撰寫。YAML 對縮排敏感，層級一般使用空格，不應混用定位字元。同一層級的欄位必須保持相同縮排，清單項目以連字號開頭。許多「設定解析失敗」並非協定不相容，而是冒號後缺少空格、縮排錯位、同名欄位重複或特殊字元未正確加上引號。修改前保留一份原始檔案，比事後憑記憶復原穩妥得多。

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

proxies:
  - name: "Example Node"
    type: socks5
    server: 192.0.2.10
    port: 1080

proxy-groups:
  - name: "PROXY"
    type: select
    proxies:
      - "Example Node"
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.org,PROXY
  - MATCH,DIRECT

控制面板中的幾種常見狀態

「系統代理」表示用戶端正在修改作業系統的代理設定，但不代表所有程式都會遵循它。「TUN」表示虛擬網卡接管已啟用，但仍需確認路由、DNS 與權限是否正常。「Rule」是規則模式，表示連線依規則分流；「Global」是全域模式，通常將請求交給單一策略群組；「Direct」則會盡量直接連線。這些狀態是不同維度的開關，並非只能擇一。例如可以同時啟用系統代理與 Rule 模式，也可以使用 TUN 搭配 Rule 模式。

初學階段不必一次理解所有欄位。先記住用戶端負責操作、核心負責執行、設定負責描述行為、訂閱負責更新設定、規則負責選擇出口。之後每增加一項功能，都能放回這五個位置中判斷。如此一來，遇到陌生用戶端時，即使介面名稱不同，也能依功能找到對應設定。

選擇用戶端：依平台與使用方式決定

先選圖形用戶端，還是直接使用核心

多數桌面與手機使用者應從圖形用戶端開始。圖形用戶端已處理設定儲存、系統代理、開機啟動、訂閱更新、策略群組切換與記錄查看，遇到問題時也更容易觀察狀態。直接執行 mihomo 核心則更適合伺服器、路由器、容器環境，或需要自行管理服務程序的使用者。這種方式需要手動準備設定、監聽連接埠、啟動參數與常駐服務，也要自行處理權限與記錄輪替。

本站下載頁依 Windows、macOS、Android、iOS、Linux 與核心分類。Clash Plus 是各主要平台的首選，適合希望維持相近操作流程、直接匯入訂閱的使用者。Clash Verge Rev、FlClash 與 Clash Nyanpasu 提供桌面圖形介面；Clash Meta for Android 與 Surfboard 面向 Android；ClashX Meta 屬於停止維護的 macOS 封存用戶端；Clash for Windows 同樣已停止維護，只適合需要查看舊設定或遷移資料的情境。

Windows 與 macOS 如何取捨

Windows 使用者首先確認系統架構。目前一般電腦多使用 x64，ARM Windows 裝置則需要對應架構的軟體套件。安裝程式通常能建立捷徑並處理解除安裝，壓縮檔版本則便於獨立存放，但更新與檔案關聯可能需要手動管理。首次執行若出現系統防火牆提示，應依實際使用範圍決定是否允許專用網路存取；只有需要讓區域網路裝置連線至本機代理連接埠時，才需進一步開啟區域網路存取。

macOS 使用者要區分 Apple Silicon 與 Intel。Apple Silicon 套件對應採用 M 系列晶片的裝置，Intel 套件則對應較早的 x86_64 裝置。架構安裝錯誤可能無法啟動，也可能透過相容層執行，但會帶來額外問題。用戶端首次修改系統代理、建立網路延伸功能或啟用 TUN 時，系統會要求管理員授權，這是寫入網路設定所需的正常步驟。若只想先驗證訂閱，可以暫時不開啟 TUN，先使用系統代理完成基本連線。

行動平台的重點不在功能數量

Android 用戶端通常透過系統 VPN 介面接管流量。安裝完成後，需要允許用戶端建立 VPN 連線，並依系統廠商設定調整電池最佳化、背景活動與自動啟動權限。若用戶端切到背景幾分鐘後連線消失，應優先檢查系統省電策略，而不是立即修改節點。分應用程式代理可以控制哪些應用程式進入通道，但不同用戶端的「包含模式」與「排除模式」意義相反，儲存前應仔細閱讀說明。

iOS 與 iPadOS 同樣透過系統 VPN 設定運作。首次連線會出現系統授權視窗，確認後才能建立通道。行動端切換 Wi-Fi 與行動網路時，短暫重新連線屬於網路路徑變化；若一直無法恢復，可以先中斷再連線，並檢查訂閱中的節點是否可用。行動裝置資源有限，不建議一開始就載入規模過大的規則集與過多設定副本。

如何處理停止維護的用戶端

停止維護不代表既有設定會立即失效，但意味著未來的系統更新、協定變化與安全問題可能不再獲得相容支援。Clash for Windows 與 ClashX Meta 適合用於舊環境遷移，不適合作為新安裝的長期首選。遷移時先匯出或找到原有設定目錄，記錄常用的策略群組選擇，再於新用戶端重新匯入訂閱。不要將舊用戶端的整個程式目錄直接覆蓋到新用戶端目錄，兩者的資料結構與設定欄位可能不同。

選擇用戶端時，不必追求設定項目最多。能穩定更新訂閱、正確開啟系統代理或 TUN、方便查看記錄，已涵蓋大多數需求。需要特定安裝檔時前往下載中心，依平台標籤選擇即可。先確認平台與架構，再下載對應檔案，就能避開許多看似複雜、實際只是套件類型不符的問題。

安裝與首次啟動：先讓基本鏈路運作

安裝前先整理舊環境

同一台裝置可以儲存多個用戶端，但不建議同時讓它們修改系統代理或建立 TUN。安裝新用戶端前，先在舊用戶端中關閉系統代理與 TUN，再完全退出程式。Windows 可至系統網路代理設定確認手動代理已關閉；macOS 可在目前網路服務的代理頁檢查 HTTP、HTTPS 與 SOCKS 項目；行動端則確認舊 VPN 已中斷。這樣可避免兩個用戶端爭用連接埠、反覆覆寫系統設定。

如果準備遷移舊設定，先複製設定目錄或匯出 YAML。需要保留的是訂閱網址、自行修改的規則、策略群組偏好與 DNS 調整，而不是快取、記錄與暫存資料庫。訂閱網址屬於個人使用資訊，不應發布在公開截圖、論壇或程式碼儲存庫。完成備份後，再從下載中心選擇對應平台的安裝檔。

Windows 安裝與首次檢查

Windows 安裝程式下載完成後，依精靈選擇安裝位置並啟動用戶端。若系統提示需要安裝網路元件或要求管理員權限，應先確認目前操作的確實是剛下載的用戶端，再繼續。應用程式啟動後不要急著開啟所有開關，先找到「設定」或「訂閱」頁面，確認介面能正常載入；接著查看設定頁中的混合連接埠、系統代理與 TUN 狀態。

常見的本機混合連接埠是 7890，但連接埠不必固定使用這個數值。只要未被其他程式佔用，且手動設定代理的應用程式使用相同連接埠即可。如果記錄出現「address already in use」，表示監聽連接埠發生衝突。可先退出其他代理程式，或將 mixed-port 改為未使用的連接埠。連接埠變更後，瀏覽器擴充功能、開發工具與命令列環境中的代理位址也要同步修改。

netstat -ano | findstr :7890

curl.exe -x http://127.0.0.1:7890 https://example.com/

第一個指令用於查看 Windows 上是否有程序佔用 7890 連接埠，第二個指令用於明確透過本機 HTTP 代理發出請求。測試網址只用來確認代理連接埠能接收連線，不代表業務網站是否可存取。若 curl 無法連線至 127.0.0.1，應先檢查用戶端核心是否啟動，而不是檢查遠端節點。

macOS 安裝與系統授權

macOS 下載後通常需要將應用程式移入「應用程式」資料夾，再從該資料夾啟動。首次執行可能出現來源確認或權限提示，應透過系統提供的安全性設定完成確認。修改系統代理時，用戶端可能要求管理員授權；啟用 TUN 或網路延伸功能時，也可能要求允許新增 VPN 設定。授權完成後回到用戶端，確認開關狀態確實變成開啟，不能只以視窗消失判定成功。

若選單列已有另一個代理用戶端圖示，先退出舊程式。系統代理開關顯示開啟，但瀏覽器完全不受影響時，可至「系統設定 → 網路 → 目前網路 → 詳細資訊 → 代理」核對位址是否指向 127.0.0.1，以及連接埠是否與用戶端一致。關閉用戶端前，最好先關閉系統代理，讓用戶端主動清理設定。若程式異常退出造成代理殘留，也可在系統網路設定中手動取消。

Android、iOS 與 Linux 的首次啟動

Android 安裝後先授予建立 VPN 連線所需的權限。若系統開啟「永遠開啟的 VPN」並綁定其他應用程式，需要先調整該設定，否則新用戶端無法接管。部分系統會限制背景網路與電池使用，若連線能建立但鎖定螢幕後中斷，應將用戶端加入允許背景執行的範圍。首次測試階段先關閉複雜的分應用程式規則，確認所有應用程式都能連線後，再逐步增加排除項目。

iOS 或 iPadOS 從 App Store 安裝 Clash Plus 後，首次連線需要允許新增 VPN 設定。系統狀態列出現 VPN 標誌，只代表通道已建立，不代表訂閱中的每個節點都可用。仍應回到用戶端查看連線記錄，並用一般網頁進行驗證。若行動網路可用而 Wi-Fi 不行，需要檢查目前 Wi-Fi 的 DNS、驗證頁面與路由限制。

Linux 圖形用戶端的安裝方式取決於套件類型與發行版。Debian、Ubuntu 及其衍生系統可安裝 deb 套件；其他發行版應選擇相容的套件類型。安裝後若系統匣圖示遺失，不一定代表核心未執行，可從應用程式視窗與程序清單檢查。單獨執行 mihomo 核心時，應明確指定設定目錄，並先執行設定測試。

mihomo -t -d ./clash-config
mihomo -d ./clash-config

-t用於檢查設定是否能解析，-d指定包含設定檔與執行資料的目錄。先測試再啟動，可以將 YAML 格式錯誤與網路連線錯誤分開。作為長期服務執行時，還應使用系統服務管理器處理自動啟動、當機重啟與記錄輪替，而不是讓終端視窗一直停留在前景。

首次啟動後的最小驗收

安裝完成後依固定順序檢查：用戶端介面正常開啟；核心狀態顯示執行中；本機連接埠成功監聽；系統代理或 VPN/TUN 至少選擇一種接管方式；匯入設定後能看到策略群組；選取可用節點後能產生連線記錄。不要把「某個網站能否開啟」當作唯一標準，因為網站本身、DNS、規則與節點出口都可能影響結果。

如果基本鏈路尚未運作，先不要調整 Fake-IP、規則集與腳本。維持預設設定更容易定位問題。下載與安裝相關的常見疑問可查看下載頁常見問題區；希望只走一遍最短操作流程，可回到使用指南。

訂閱匯入：從連結到可用設定

匯入前先確認訂閱回傳內容

訂閱連結通常由服務提供者產生，可能帶有識別參數，因此應像帳號資訊一樣保存。不要將完整網址放入公開截圖、瀏覽器同步筆記或公開儲存庫。匯入前可以先確認連結是否仍在有效期限內，以及服務方是否明確提供 Clash 或 mihomo 格式。瀏覽器能開啟連結，不代表用戶端一定能解析；瀏覽器下載到文字，也不代表內容就是完整 YAML。

完整設定至少應包含代理節點與策略群組，常見欄位包括 proxies、proxy-groups 與 rules。如果回傳內容只有一串編碼文字，用戶端可能需要先辨識為通用訂閱，再轉換成 Clash 設定。若轉換由遠端服務完成，需要注意訂閱網址會被該服務讀取。優先使用服務提供者明確支援的格式，能少經過一層就少一個故障點。

在用戶端中新增訂閱

不同用戶端的入口可能稱為「訂閱」「設定」「Profiles」或「遠端設定」，操作邏輯大致一致：建立遠端設定、貼上連結、填寫方便辨識的名稱、儲存並觸發更新。更新成功後，選擇這份設定作為目前設定，再到策略群組頁面選擇所需出口。只將連結加入清單，卻沒有切換至該設定，是初次使用時很常見的遺漏。

設定名稱建議描述用途，例如「日常訂閱」或「備用設定」，不必將存取憑證寫入名稱。自動更新間隔不宜過短。訂閱內容通常不會每分鐘變動，頻繁重新整理只會增加請求，也可能觸發伺服器限制。每天更新，或依服務方建議更新即可；需要立即取得變更時再手動重新整理。

更新失敗時依回應階段排查

「無法連線」通常表示請求尚未取得有效回應，應檢查目前網路、網域解析、系統時間與連結是否完整。「請求遭拒」或 HTTP 驗證類錯誤，多半與連結過期、參數缺失或存取條件有關。「解析失敗」表示已取得內容，但格式不符合用戶端預期，常見原因是回傳網頁、編碼訂閱、YAML 縮排錯誤或用戶端不支援其中欄位。「更新成功但節點為空」則要檢查訂閱本身是否包含節點，以及是否有篩選規則將節點全部排除。

排查時先將連結複製到目前裝置的瀏覽器網址列，只用來觀察回應類型，不要轉發給他人。如果開啟後跳轉至登入頁、錯誤頁或驗證碼頁面，用戶端自然無法將其解析為設定。若瀏覽器下載了檔案，可用文字編輯器查看開頭欄位。完整 YAML 通常能看到鍵名與縮排；網頁內容往往以 HTML 標籤開頭；編碼訂閱則可能是一整行連續字元。

某些服務會依請求的 User-Agent 回傳不同格式。若用戶端設定中有訂閱 User-Agent 選項，應優先使用服務方要求的值，不要隨意嘗試多個偽裝名稱。需要進一步定位訂閱解析、快取與格式轉換問題，可閱讀Clash 訂閱連結失效自查步驟。

本機修改與遠端更新的覆寫關係

遠端訂閱更新通常會重新寫入設定，因此直接在訂閱產生的 YAML 中新增規則，下次更新後可能會消失。需要長期保留的修改，應使用用戶端提供的覆寫、合併或腳本功能；如果用戶端沒有這些能力，就保留一份獨立的本機設定，並建立清楚的更新流程。不要一邊讓遠端設定自動更新，一邊把它當成永久手寫檔案。

合併邏輯通常分為前置插入、後置追加與欄位覆寫。規則具有順序，若要讓自訂規則優先套用，應插入通用規則之前；DNS、連接埠與模式等單值欄位，則通常由後寫入的值覆寫。不同用戶端對覆寫語法的實作並不完全一致，遷移用戶端時要重新核對，不要假定舊腳本可以原樣使用。

prepend-rules:
  - DOMAIN-SUFFIX,example.org,DIRECT
  - DOMAIN,api.example.net,PROXY

append-rules:
  - MATCH,PROXY

上面的結構用於表達「將特定規則放在前面，並保留最後兜底」的思路，實際欄位名稱應以用戶端的覆寫功能為準。若直接編輯標準 Clash 設定，則應將規則寫入 rules 清單，並確保只存在一個最終兜底。多個 MATCH 中，只有最先遇到的一個有意義。

訂閱轉換應該解決什麼問題

訂閱轉換主要用於將節點清單整理成用戶端可讀取的設定，或套用規則與策略群組範本。它無法修復已失效的節點，也不能憑空提升連線品質。轉換後的節點名稱、策略群組與規則可能改變，更新前應先保存舊設定。若轉換結果突然少了節點，請檢查範本篩選條件、協定支援與節點名稱正規表示式，不要只盯著連結是否能開啟。

完成匯入後，應先在規則模式下選擇一個明確節點，開啟系統代理並觀察記錄。確認基本連線正常後，再開啟自動選擇、複雜規則與 TUN。將驗證步驟拆開，發生問題時才能知道是訂閱內容、策略選擇還是接管方式造成的。

代理模式：Rule、Global 與 Direct 如何選擇

Rule 模式適合長期使用

Rule 模式會依設定中的規則逐條判斷請求應該使用哪個策略群組。常見結果包括 PROXY、DIRECT、REJECT 或自訂策略群組。它的優勢不是「自動變快」，而是讓不同流量依用途選擇出口：本地服務可以直連，需要代理的網域交給代理群組，廣告或已知無效請求則可拒絕。規則設計合理時，不必頻繁手動切換整個用戶端。

規則由上而下比對，命中後就停止繼續搜尋。因此具體規則應放在寬泛規則之前。例如單一網域規則要放在涵蓋範圍更大的網域後綴或規則集之前，區域網路與保留位址通常要在最終代理兜底之前處理。最後一條常用 MATCH 作為兜底，確保未被前面規則辨識的連線仍有明確去向。

Global 模式用於臨時驗證

Global 模式通常將所有可接管的流量交給全域策略群組，再由使用者選擇節點或出口。它適合判斷「問題是否由規則造成」。某網站在 Rule 模式下無法開啟，切換至 Global 後立即正常，表示節點與接管鏈路大致可用，下一步應檢查網域規則、IP 規則與 DNS，而不是重新安裝用戶端。

全域模式不代表裝置上的每一個資料封包都會自動進入代理。是否接管仍取決於系統代理或 TUN。只切換至 Global 卻未開啟任何接管方式，許多應用程式仍會直接連線。反過來，開啟 TUN 但選擇 Direct 模式，流量雖然經過核心，也可能依直接連線處理。模式與接管方式要分開看。

Direct 模式用於快速旁路

Direct 模式讓流量盡量直接連線，可用於暫時停用代理決策、比較直連與代理差異，或在保留用戶端執行的同時排查本地網路。它不一定等同於完全退出用戶端：本機連接埠可能仍在監聽，TUN 也可能繼續接管後再直接連線。需要徹底恢復原始網路狀態時，應關閉系統代理與 TUN，再退出用戶端。

某些用戶端還有 Script 等擴充模式，行為取決於腳本實作。初學階段不建議將腳本模式作為預設方案，因為腳本錯誤、執行環境與回傳值都會增加排查層級。規則能清楚表達的邏輯，優先使用標準規則。

策略群組才是模式之後的實際出口

規則通常不會直接寫死某個節點，而是指向策略群組。select 群組由使用者手動選擇；url-test 會依測試結果選擇候選節點；fallback 會依順序嘗試可用節點；load-balance 則依策略在多個節點之間分配連線。不同群組解決的問題不同，不應只根據名稱中的「自動」判斷優劣。

自動測試使用指定的測試網址與間隔，只能反映連線至該網址的狀況。測試結果較好，不代表存取所有服務都一樣。節點出口位置、路由、目標網站限制與連線重用都會影響實際體驗。日常可保留一個手動選擇群組與一個自動測試群組：自動群組負責一般瀏覽，遇到特定服務異常時切回手動群組驗證。

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

  - name: "自動選擇"
    type: url-test
    proxies:
      - "節點 A"
      - "節點 B"
    url: "https://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 80

interval表示測試間隔秒數，過短會產生額外請求；tolerance用於避免節點之間只有些微差異時頻繁切換。測試網址應穩定回傳輕量回應。如果目前網路無法存取測試網址，自動群組可能將所有節點判定為異常，此時應更換適合目前環境的檢測網址。

切換模式時如何驗證

先固定一個已知可用的節點，開啟系統代理或 TUN，再分別測試 Rule 與 Global。若兩者都失敗，查看本機監聽、節點連線與 DNS；若 Global 成功而 Rule 失敗，查看記錄中命中的規則與策略群組；若瀏覽器成功而命令列失敗，檢查命令列程式是否讀取系統代理，必要時使用明確代理參數或 TUN。

判斷目前模式不要只看首頁按鈕顏色。查看記錄中的規則命中與出口名稱更可靠。一次完整記錄應包含目標網域或 IP、匹配規則、策略群組與最終節點。掌握這四項後，「某個應用程式無法連線」就能拆解成可檢查的步驟，而不是反覆切換所有開關。

規則分流與 DNS：讓請求走向正確出口

規則類型與匹配順序

網域規則最容易閱讀。DOMAIN只匹配完整網域，DOMAIN-SUFFIX匹配指定後綴及其子網域，DOMAIN-KEYWORD則依網域中的關鍵字匹配。IP 規則依目標位址判斷，常見有 IP-CIDR、IP-CIDR6 與地理資料庫規則。程序規則可以依程式名稱或路徑分流，但不同系統的支援程度與權限要求不同。規則集則將大量規則拆分至獨立檔案，方便更新與重複使用。

規則越寬泛，就越應該放在後面。假設先寫 DOMAIN-SUFFIX,example.com,PROXY，後面再寫 DOMAIN,internal.example.com,DIRECT，內部網域會先命中後綴規則，後面的直連規則永遠沒有機會執行。正確做法是將具體例外放在通用規則之前。最後使用 MATCH 兜底，避免請求落入不明確狀態。

rules:
  - DOMAIN,internal.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,PROXY
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - MATCH,PROXY

no-resolve表示匹配該 IP 規則時，不為了取得 IP 而額外觸發網域解析。它適合已取得目標 IP 的連線，或不希望 IP 規則提前引發解析的情境。並非所有 IP 規則都應機械式加入此選項；如果規則需要依網域解析結果判斷，就要允許解析發生。

規則集、GeoIP 與 GeoSite

規則集將網域、IP 或經典規則放在獨立資源中，主設定只透過 RULE-SET引用。如此可單獨更新規則，不必每次替換整份訂閱。使用時要確認規則集的行為類型與內容相符：domain 類型只包含網域行為，ipcidr 類型用於網段，classical 類型可承載完整規則行。類型寫錯可能導致載入失敗或規則無法命中。

GeoIP 依 IP 地理資料庫分類，GeoSite 則依網域集合分類。它們依賴本機資料庫，資料庫長期未更新會造成新網域缺失或位址歸類偏差。設定可以正常解析，但分流逐漸失準時，應檢查資料庫更新時間與下載來源。具體更新方式可參考GeoIP 與 GeoSite 資料庫更新指南。

DNS 為什麼會影響規則

應用程式存取網域時，可能先自行解析，再向代理發出 IP 連線；也可能將網域直接交給代理。前一種情況下，核心看到的可能只有 IP，網域規則難以參與；後一種情況下，核心能保留網域資訊並依網域規則分流。系統代理、SOCKS、TUN、瀏覽器安全 DNS 與應用程式內建的解析方式，都會改變這條路徑。

DNS 設定通常包含監聽、IPv6、增強模式、預設解析器與主要 nameserver。預設解析器用於解析其他 DNS 伺服器本身的網域，應選擇目前網路可直接存取的位址，避免形成「需要先透過代理存取 DNS，但代理節點網域又必須先解析」的循環。主要 nameserver 負責一般查詢，可依網路環境選擇支援 UDP、TCP、DoH 或 DoT 的服務。

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

這段設定展示欄位關係，不代表所有網路環境都應照抄。監聽在 0.0.0.0表示所有本機介面都可能存取該連接埠；若裝置處於不受信任的網路，應搭配防火牆或改為本機監聽。關閉 IPv6 會讓 Clash DNS 不回傳 IPv6 結果，但系統與其他應用程式是否仍發起 IPv6 請求，還取決於接管方式與系統網路。

Fake-IP 與 Redir-Host 的差異

Fake-IP 模式會先向應用程式回傳保留位址，核心負責維護該位址與原始網域的對應。當應用程式連線至保留位址時，核心仍知道原始網域，因此可以更早進行網域規則判斷，並減少某些重複解析。保留位址不是目標網站的真實位址，只在本機對應流程中使用。詳細原理與篩選方式可閱讀Clash Fake-IP 模式說明。

部分區域網路探索、印表機、遊戲、時間同步或依賴真實 IP 回傳值的應用程式不適合 Fake-IP，可加入 fake-ip-filter。篩選項目不宜一次加入大量寬泛網域，否則會削弱 Fake-IP 的網域對應優勢。遇到單一應用程式異常時，先從記錄確認網域，再增加最小範圍的篩選並重新測試。

Redir-Host 更接近先解析真實位址，再處理連線，能相容於某些依賴真實 DNS 結果的程式，但可能更依賴 DNS 路徑品質。兩種模式沒有絕對優劣。桌面日常使用可以先維持用戶端預設值；出現區域網路裝置探索失敗、特定應用程式登入異常或網域規則遺失時，再依記錄決定是否調整。

規則未命中的排查方法

第一步查看連線記錄中顯示的是網域還是 IP。若只有 IP，網域規則自然可能無法匹配，需要檢查應用程式解析方式、TUN 嗅探與 DNS 接管。第二步確認目標規則是否排在更寬泛規則之前。第三步確認規則指向的策略群組名稱完全一致，包括大小寫、空格與符號。第四步檢查規則集是否成功下載，行為類型是否相符。第五步再考慮資料庫與快取。

修改後應重新載入設定，並建立一條新連線進行測試。既有連線可能繼續重用舊出口，重新整理網頁不一定會建立新連線。可以關閉對應應用程式、清除連線記錄，或等待連線結束後再試。不要同時修改規則順序、DNS 模式與 TUN 參數，否則即使恢復正常，也無法知道真正生效的是哪項修改。

TUN 模式：接管不讀取系統代理的流量

什麼時候需要 TUN

系統代理只對主動讀取系統代理設定的程式有效。瀏覽器通常支援良好，但命令列工具、遊戲啟動器、部分桌面應用程式、容器，以及使用自訂網路堆疊的軟體可能會忽略它。TUN 模式建立虛擬網卡，透過系統路由將更廣泛的 IP 流量送入核心，因此適合處理系統代理涵蓋不到的應用程式。

TUN 不是「更進階所以一定要開啟」的開關。只使用瀏覽器與遵循系統代理的應用程式時，系統代理架構更簡單，也更容易排錯。只有明確遇到未被接管的程式，或需要統一處理 UDP、命令列與多個應用程式時，再啟用 TUN。它會引入虛擬網卡、路由、DNS 劫持與權限等額外環節，設定不當時也更容易與其他 VPN、虛擬機網路及安全軟體衝突。

如何理解核心參數

enable控制 TUN 是否啟用；stack決定封包在使用者態與系統網路堆疊之間的處理方式，常見值包括 system、gVisor 與 mixed，具體支援情況以目前核心與用戶端為準；auto-route用於自動寫入路由；auto-detect-interface嘗試辨識預設出口介面；dns-hijack將指定的 DNS 請求交給 Clash 處理。圖形用戶端的開關通常會產生或覆寫這些欄位。

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

mixed通常用於兼顧不同的流量處理路徑，但並非所有裝置都必須選擇它。若用戶端已提供 stack 選項，應先使用預設值。strict-route會更嚴格地限制路由洩漏，在部分系統上可能影響區域網路、個人熱點或虛擬網路。初次啟用時保持關閉，更容易進行驗證；確認基本流量正常後，再依需求測試。

桌面系統的啟用步驟

先關閉其他 VPN 與舊用戶端的 TUN，保留目前用戶端執行。匯入一份已在系統代理模式下驗證可用的設定，固定一個可用節點，再開啟 TUN。系統要求管理員權限時完成授權，接著觀察用戶端是否顯示核心執行中、虛擬網卡已建立且路由寫入成功。此時可暫時關閉系統代理，使用一個原本不讀取系統代理的命令列工具測試，以確認流量確實來自 TUN。

Windows 若開啟後完全無法連網，先關閉 TUN，檢查是否殘留其他虛擬網卡、第三方 VPN、Hyper-V 或安全軟體網路過濾。重新開啟前可重新啟動用戶端並恢復自動路由。macOS 需要注意網路延伸功能或 VPN 設定授權，權限遭拒時開關可能立即回復關閉。Linux 則需要建立 TUN 裝置及修改路由的權限，服務程序還應具備讀取設定與寫入執行目錄的權限。

curl https://example.com/
curl --noproxy "*" https://example.com/

在 TUN 已正確接管的情況下，即使第二個指令要求 curl 不使用傳統代理環境變數，流量仍可能經由系統路由進入 TUN。這項測試可以協助區分「程式讀取了 HTTP 代理」還是「流量被虛擬網卡接管」。測試時還應查看 Clash 記錄是否出現對應連線，不能只根據網頁結果推斷。

DNS 劫持與 Fake-IP 的搭配

TUN 接管 IP 流量後，如果 DNS 仍由應用程式直接傳送至區域網路解析器，核心可能只看到解析後的 IP，網域規則與 Fake-IP 對應就會受到影響。dns-hijack用於將常見 DNS 請求送入 Clash DNS。現代瀏覽器與部分應用程式可能使用加密 DNS，普通 53 連接埠劫持無法直接讀取這類請求，需要在應用程式中關閉獨立安全 DNS，或確保其連線本身能依規則正確處理。

啟用 DNS 劫持後若出現區域網路網域無法解析，應檢查本地域名是否需要由路由器 DNS 處理，並為其設定 nameserver-policy 或合適的回退路徑。印表機、NAS 與公司內部網域往往只存在於特定網路的 DNS 中，公共解析器無法回覆。解決方式應是將這些網域交給正確的本地解析器，而不是把所有 DNS 都改回直連。

區域網路、虛擬機與容器邊界

TUN 改寫路由後，區域網路存取可能經過核心。設定中應保留私有網段直連規則，並注意 IPv6 本機位址。若需要讓其他裝置使用本機代理，應另外開啟 allow-lan、監聽適當介面並設定防火牆；這與本機 TUN 是兩回事。不要為了本機接管，就任意將代理連接埠暴露至所有網路。

虛擬機與容器都有自己的虛擬網卡與網段。TUN 自動路由可能與 Docker、虛擬機橋接、WSL 或企業 VPN 的路由互相覆寫。問題只在虛擬環境出現時，應比較啟用 TUN 前後的路由表，確認目標網段由哪個介面接管。必要時將虛擬網段加入排除路由或直連規則，而不是關閉所有規則。

TUN 失敗的固定排查順序

先確認同一節點在系統代理下可用，排除節點問題；再確認 TUN 開關確實保持開啟，虛擬網卡已建立；接著查看自動路由與預設介面辨識；然後檢查 DNS 是否被接管、記錄中是否出現請求；最後檢查其他 VPN、安全軟體、虛擬網卡與防火牆。每一步只修改一個變數，修改後重新建立連線。

系統代理正常而 TUN 異常，通常不需要重新匯入訂閱。重點應放在權限、路由、DNS 與網路衝突。更完整的工作原理、stack 選擇與平台差異，可繼續閱讀Clash TUN 模式開啟教學。

日常維護與進階路線：讓設定保持可復原

建立穩定的日常檢查節奏

Clash 正常執行時不需要頻繁調整。日常只需留意訂閱是否能更新、常用策略群組是否有可用節點、規則與地理資料庫是否過舊，以及用戶端更新後關鍵設定是否維持不變。訂閱可每日更新，或依服務方建議更新；規則集與資料庫則依實際變化週期更新即可。過於頻繁的自動測試與訂閱重新整理會增加請求，也可能讓節點選擇不斷變動。

用戶端啟動後發現設定恢復預設，先確認是否切換了設定、是否使用便攜目錄，以及設定目錄是否可寫入。系統更新後 TUN 權限遺失，應重新檢查網路延伸功能或虛擬網卡授權。休眠喚醒後短暫斷線，可以先等待網路介面恢復，再重新連線核心；如果每次都無法自動恢復，再檢查預設介面辨識與用戶端背景行為。

哪些內容最值得備份

優先備份訂閱網址清單、自訂規則、覆寫腳本、DNS 調整與本機獨立設定。快取資料庫、暫時連線記錄與一般執行記錄通常不必長期保留。備份檔案可能包含訂閱參數、節點驗證資訊與區域網路位址，應存放在受控位置，不要直接上傳至公開程式碼儲存庫。

多裝置同步時，集中下發訂閱連結最省維護，但裝置專屬設定不應強行共用。例如桌面端的 TUN stack、Android 分應用程式代理與 macOS 網路延伸功能都屬於平台差異。可以讓各裝置共用節點與基礎規則，再將系統相關欄位保留在本機覆寫層。關於訂閱、WebDAV 與手動匯出的取捨，可參考Clash 多裝置設定同步方案比較。

如何閱讀記錄

記錄等級通常有 silent、error、warning、info 與 debug。日常使用保留 info 即可；排查短時間問題時可暫時切換至 debug，問題重現後立即恢復，避免記錄快速增長。閱讀時先找到故障發生的確切時間，再查看目標網域或 IP、命中規則、策略群組、最終出口與錯誤類型。不要從大量記錄中隨機挑一條錯誤就下結論。

連線逾時通常表示請求已發出，但未能及時完成，可能與節點、路由、目標服務或網路限制有關；連線遭拒表示目標位址明確拒絕；DNS 錯誤表示名稱解析階段失敗；TLS 錯誤可能與系統時間、憑證鏈、網域不匹配或中間網路有關；設定解析錯誤則應回到 YAML 行號與欄位。錯誤發生在哪一層，決定下一步該檢查什麼。

通用故障樹：從範圍最小的地方開始

所有網站都無法連線時，先查看用戶端核心、本機連接埠、接管方式與節點；只有一個網站無法連線時，先查看規則命中、DNS、節點出口與網站本身限制；只有一個應用程式無法連線時，先確認它是否讀取系統代理，是否使用獨立 DNS 或 QUIC；只有 TUN 無法連線時，檢查權限、路由與衝突；只有訂閱更新失敗時，不要修改代理規則，直接檢查連結回應與格式。

關閉系統代理後仍無法恢復直連，檢查作業系統代理是否殘留、環境變數是否仍存在，以及瀏覽器是否設定獨立代理。關閉 TUN 後仍異常，檢查虛擬網卡與路由是否已清除，必要時正常重新啟動系統，讓網路堆疊重新建立。不要使用來源不明的「一鍵網路修復」腳本，它可能同時重設 DNS、防火牆與網卡，反而抹去有價值的現場資訊。

# macOS 與 Linux 查看常見代理環境變數
env | grep -i proxy

# 暫時移除目前終端工作階段中的代理變數
unset HTTP_PROXY HTTPS_PROXY ALL_PROXY
unset http_proxy https_proxy all_proxy

# 測試本機代理連接埠
curl -x http://127.0.0.1:7890 https://example.com/

環境變數只會影響讀取它們的程式與目前工作階段，圖形用戶端修改系統代理並不會自動清除終端中手動設定的變數。反過來，終端中設定了 HTTPS_PROXY，也不代表其他桌面應用程式會使用它。釐清每個應用程式透過哪種方式接管，是長期穩定使用的重要習慣。

升級用戶端與遷移設定

升級前查看用戶端提供的更新說明，確認是否涉及設定目錄、核心欄位或網路延伸功能變更。先匯出關鍵設定，再正常退出舊版本並安裝新版本。升級後先檢查設定是否載入、訂閱是否能更新、系統代理與 TUN 權限是否保留，然後再恢復複雜覆寫。不要在升級當天同時更換訂閱、規則範本與 DNS 設定，多項變更疊加會讓問題難以追溯。

從停止維護的 Clash for Windows 或 ClashX Meta 遷移時，建議重新匯入遠端訂閱，而不是複製整個資料庫。手寫規則可以單獨遷移，策略群組選擇則重新確認。新用戶端採用 mihomo 核心時，部分擴充欄位可能更豐富，但舊欄位是否仍相容，仍應透過設定測試與記錄確認。

從日常使用走向進階設定

完成基本連線後，進階學習可以依依賴關係逐步進行。第一階段是讀懂連線記錄與規則順序，能解釋某個請求為何走向特定出口；第二階段是掌握策略群組，讓手動選擇、自動測試與故障回退各司其職；第三階段是理解 DNS、Fake-IP 與規則集，解決網域辨識與分流準確性；第四階段再深入 TUN、程序規則、區域網路共用與多裝置同步。

伺服器或路由器使用者還需要學習服務管理、設定目錄權限、記錄輪替、監聽位址與防火牆。直接暴露控制介面或代理連接埠會擴大存取範圍，因此控制連接埠應限制在可信任的介面，並設定適當驗證。設定中的區域網路存取能力只在確實需要時開啟，同時使用系統防火牆限制來源。

判斷自己是否真正掌握 Clash，不在於設定檔有多長，而在於能否回答四個問題：流量如何進入核心；這個請求命中了什麼規則；規則指向哪個策略群組；策略群組最終選擇哪個出口。能沿著這條路徑定位，換用戶端、換平台或調整設定時都不必從頭摸索。

手冊之後的閱讀順序

如果還沒有完成第一次連線，回到使用指南依步驟操作；需要更換用戶端或確認系統架構，前往下載中心；遇到縮寫與欄位名稱，可開啟術語手冊。訂閱解析、TUN、Fake-IP、資料庫更新與多裝置同步各有獨立技術筆記，可以依目前問題深入，不必一次讀完所有進階設定。

穩定設定的原則很簡單：先讓它運作，再進行分流；先看記錄，再修改參數；一次只改一個變數；修改前保留可復原版本。按照這套順序，Clash 的設定項目雖然很多，但每個問題都能落到明確環節，不會變成一團糾纏在一起的網路線。