Clash 從零到精通：安裝、訂閱與規則分流完整手冊

本手冊依學習順序編排，前一章是後一章的前提：先弄清楚內核與客戶端的分工，才能理解後面每個設定項目歸誰管；先把訂閱匯入進來，規則與 TUN 才有東西可以調度。建議第一次閱讀時按順序走一遍，之後把它當成查閱手冊，遇到具體問題時從上方目錄直接跳到對應章節。文中所有設定片段都可以複製到 config.yaml 的對應段落裡，範例中的伺服器位址、密碼、訂閱連結均為佔位值，實際使用時由訂閱或自己的伺服器端提供。

核心概念：Clash、內核與客戶端的關係

Clash 這個詞在不同語境下指三樣東西：一套規則化代理的設定規範、實作這套規範的內核程式，以及在它之上加上圖形介面的客戶端。初學者最容易卡住的地方，是把「下載一個 Clash」理解成下載一套軟體——實際上，日常點開的是 GUI 客戶端，真正建立連線、解析網域、按規則轉送資料的是內核。理解這兩層分工，後面所有設定項目放在哪裡、為什麼有些設定改了要重啟內核，都會順理成章。

內核：真正處理流量的那一層

內核是一個沒有介面的命令列程式。它啟動時讀取一份 YAML 設定檔，然後做四件事：監聽本機連接埠接收應用程式送來的連線、把設定裡的節點資訊組織成可用的出站、按 rules 段逐條決定每條連線走哪個出站、把決策過程寫進日誌。

mihomo（原名 Clash Meta）是目前社群維護的主線內核，原版 Clash 內核已停止維護，新發布的客戶端基本上都基於 mihomo。內核本身不管訂閱：它不會主動去下載設定，也不會自動更新——它只認啟動時讀到的那個檔案。設定檔變了，需要重新載入或重啟內核才會生效。

GUI 客戶端：設定管理與互動外殼

GUI 客戶端負責內核之外的所有事情：把訂閱連結下載成 config.yaml、提供開關切換模式與節點、把內核日誌呈現成可讀面板、在系統匣或通知列常駐、在開機時拉起內核。不同客戶端對同一份設定的呈現方式不同，但最終都是把檔案交給內核執行。

這件事有一個很實用的推論：換客戶端時，訂閱連結通常可以直接沿用，需要重新適配的只是客戶端自己那部分設定——連接埠號、TUN 開關、規則覆寫的位置。節點定義不在客戶端裡，換外殼不用重建節點。

一份設定檔的三層結構

一份典型的 config.yaml 分三段：基礎設定（連接埠、模式、日誌等級、DNS）、出站定義（proxies 與 proxy-groups）、分流規則（rules）。三段的先後順序在檔案裡可以調整，但邏輯關係是固定的：先定義有哪些節點和出口組，再決定什麼流量走哪個出口。

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

proxies:
  - name: "node-a"
    type: ss
    server: 203.0.113.10
    port: 8443
    cipher: aes-128-gcm
    password: "your-password"

proxy-groups:
  - name: "PROXY"
    type: select
    proxies: ["node-a", "DIRECT"]

rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

範例裡的 203.0.113.10 是文件保留位址，實際設定中 server 與 password 由訂閱提供，不需要手寫。這一段已經是一個最小可執行骨架：本機 7890 連接埠接收連線，規則模式，一個手動選擇組，三條規則由上而下比對。

本手冊與快速上手教學的分工

快速上手教學是三步主線：匯入訂閱、選擇模式、驗證連線，目標是盡快跑起來。本頁是系統查閱手冊：同樣是九個階段，但每個階段展開原理、參數含義、邊界情況與排錯分支。建議第一次安裝時先跟著教學頁走完主線，遇到「為什麼這樣設定」的問題再回到本頁對應章節。

選擇客戶端：依平台與維護狀態篩選

三條判斷標準

第一看內核。客戶端是否基於 mihomo 或相容 Clash 設定語法，決定了它能解析哪些欄位。基於原版 Clash 內核的客戶端無法跟進新的協定與規則類型，訂閱裡出現不認識的欄位時會直接報錯或默默忽略，表現為「訂閱更新成功了但節點少了一半」。

第二看維護狀態。客戶端的更新頻率決定了它對系統新版本的適配速度。已停止維護的客戶端仍然能執行，但系統更新或內核新功能出現時不會再有修正，遇到問題只能自己解決。

第三看功能覆蓋。三個差異最大的點：是否支援 TUN 模式、是否支援多份設定快速切換、是否支援規則覆寫與合併。只做瀏覽器代理的使用者對第一項無感，而需要代理遊戲或 UWP 應用程式的使用者必須確認第一項。

桌面端：Windows 與 macOS

Windows 上，Clash Plus 是目前的首選，安裝包涵蓋 x64 與 ARM64 兩種架構；Clash Verge Rev 與 FlClash 提供相近的設定管理能力，介面組織方式不同；Clash Nyanpasu 的介面更簡潔，適合只需要基本功能的使用者。Clash for Windows 已停止維護，僅在舊環境相容或歷史設定移轉時作為封存選項。

macOS 上同樣以 Clash Plus 為首選，Clash Verge Rev 與 FlClash 作為備選。ClashX Meta 已停止維護，從它移轉過來的使用者請注意設定差異：策略組命名、DNS 段結構在新內核裡更嚴格，舊設定裡的簡寫欄位可能不被識別。

行動端：Android 與 iOS

Android 生態裡，Clash Plus、Clash Meta for Android、FlClash 都支援 TUN 與分應用程式代理——分應用程式代理決定哪些應用程式走代理、哪些直連，在手機上比桌面端更實用。Surfboard 使用另一套設定格式，匯入訂閱前要確認訂閱是否提供對應格式的輸出。

iOS 上客戶端受系統限制，只能透過 App Store 安裝。Clash Plus 在 App Store 提供，官網網址是 clashplus.io，設定匯入方式與其他 iOS 代理工具類似，走系統 VPN 設定描述檔。

Linux 與伺服器場景

Linux 桌面發行版可以用 Clash Verge Rev 或 FlClash，deb、rpm 套件都有。伺服器與路由器上沒有圖形介面，直接使用 mihomo 內核：下載對應架構的壓縮檔，解壓後以命令列啟動，搭配 systemd 單元或行程守護腳本常駐。這條路徑的好處是資源佔用最低，代價是所有設定都要手寫。

完整的橫向對比與選擇建議在選型指南；所有安裝包依平台分類在下載頁，平台入口直達對應區塊。選型階段不必糾結太久：同一份訂閱在多數客戶端之間可以通用，先裝一個用起來，再依實際缺少的功能調整。

安裝：系統需求、權限與首次啟動

安裝前確認三件事

系統版本。Windows 10 1809 及以上，低於這個版本只能用系統代理模式，虛擬網卡驅動程式與部分系統介面無法使用。macOS 需要較新的系統版本以支援網路擴充機制，舊系統上 TUN 無法授權。Android 需要允許安裝來自瀏覽器或檔案管理員的應用程式，部分 ROM 會在安裝時二次確認。Linux 發行版需要符合客戶端的 glibc 版本需求，太舊的發行版建議直接用內核命令列方案。

權限。TUN 模式需要管理員（Windows）或 root、網路擴充授權（macOS、Linux）。只使用系統代理模式時一般權限即可。安裝階段可以先不開啟 TUN，等設定匯入完成後再開，避免兩個變數同時變動。

網路環境。首次啟動可能需要下載規則集或 GEOIP 資料庫，網路不通時客戶端會停在初始化狀態。如果所在網路存取受限，先確認客戶端內建的初始化請求是否被攔截，再決定是否改用離線設定。

Windows 安裝順序

• 從下載頁的 Windows 區塊選擇對應架構的安裝包：一般 PC 選 x64，ARM 裝置選 ARM64，裝錯架構會直接提示不相容。
• 執行安裝程式，安裝目錄保持預設即可。
• 首次啟動時如果跳出管理員權限請求，請允許——這是為 TUN 模式準備虛擬網卡驅動程式。
• 啟動後確認系統匣圖示出現，右鍵選單裡應該能看到模式切換、設定管理和結束三項。
• 如果安裝後無法啟動：先看系統是否攔截了未簽署的驅動程式安裝，再看防毒軟體是否把主程式隔離，最後檢查是否有舊版本殘留的服務行程佔用連接埠。

macOS 與 Linux

macOS 下載 dmg 後拖進應用程式目錄。首次開啟如果被 Gatekeeper 攔下，到「系統設定 → 隱私權與安全性」裡選擇仍要打開。啟用 TUN 時系統會要求授權網路擴充，這一步必須允許，否則 TUN 無法接管流量；授權後如果仍然不生效，重啟一次客戶端讓擴充重新載入。

Linux 桌面發行版優先使用 deb 或 rpm 套件，安裝後從應用程式選單啟動。部分客戶端採用「介面 + 服務」分離的架構：內核以服務身分執行，介面透過本機介面控制它，這樣介面不需要 root 權限。依安裝提示裝好服務元件即可。伺服器場景不裝 GUI，下載 mihomo 內核壓縮檔，解壓後直接用 -d 指定設定目錄、-f 指定設定檔啟動。

行動端安裝

Android 安裝 APK 後首次啟動會請求 VPN 權限，這個權限是 TUN 模式的基礎，拒絕後只能手動設定系統代理，而行動端手動設定系統代理的體驗很差。iOS 從 App Store 安裝後，首次連線會引導加入 VPN 設定描述檔，依提示在系統設定裡允許，之後回到客戶端內匯入訂閱。

首次安裝的常見陷阱（權限、連接埠、系統代理三類）整理在部落格《Clash 首次安裝與初始設定》裡，安裝完成後可以對照檢查一遍。

訂閱匯入：連結、託管設定與本機檔案

訂閱連結的本質

訂閱就是一個 URL：客戶端請求它，回傳一份 YAML 設定或一段編碼後的節點清單。Clash 系客戶端需要 Clash 格式（YAML），如果服務方給的是通用格式，需要先轉換或選擇支援該格式的訂閱輸出。連結通常帶一個查詢參數作為身分識別，所以連結本身就是憑證，不要公開分享，也不要在截圖裡暴露完整參數。

匯入的操作順序

• 完整複製訂閱連結，包括問號後面的全部參數。
• 打開客戶端的設定或訂閱頁面，新建一個設定項目。不同客戶端把這個入口叫做 Profiles、訂閱、設定或節點，位置一般在側邊欄第一項。
• 貼上連結並命名——名字只影響本機顯示，不影響連線。
• 點擊下載或更新，等待設定拉取完成。這一步會同時拉取節點清單和規則，網路不佳時可能要多試一次。
• 選中這份設定，讓內核載入它。
• 回到代理頁面，確認節點清單已經出現，隨便選一個節點。

託管設定與本機修改的衝突

遠端訂閱每次更新都會整份覆蓋本機檔案，所以直接修改訂閱下載下來的 config.yaml，會在下次更新時遺失。這是新手最常見的挫折點：花了半小時寫的規則，一夜之間沒了。三種應對方式：

• 用客戶端內建的覆寫或合併功能。把自訂規則寫進獨立的覆寫檔案，更新訂閱時自動合併進去，原始訂閱保持不動。
• 本機設定。把訂閱內容另存為本機檔案，之後手動維護。好處是完全可控，代價是節點清單不會自動更新。
• 自建託管。自己維護一份完整設定，把訂閱裡的節點段透過 proxy-providers 引入，規則與策略組全部自己寫。

proxy-providers:
  provider-a:
    type: http
    url: "https://example.com/subscribe?token=xxxx"
    interval: 86400
    path: ./providers/provider-a.yaml
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 300

interval 單位是秒，86400 表示一天更新一次；health-check 決定節點延遲測試的目標位址與頻率。用 provider 引入節點後，proxy-groups 裡用 use: ["provider-a"] 引用，而不是逐一列出節點名稱——訂閱更新後節點變化，策略組不需要改。

更新失敗怎麼處理

先看客戶端日誌裡請求訂閱的回傳碼：401 或 403 多半是連結失效、參數被改或服務方限制了目前 IP；請求逾時是本機到訂閱伺服器這一段不通；回傳內容解析失敗表示拿到的不是 Clash 格式，可能服務方依客戶端類型回傳了不同格式。更新後如果只有部分節點變化，屬於正常現象——服務方調整節點是常態，不需要處理。

多部裝置之間怎麼讓設定保持一致，見部落格《Clash 多裝置設定同步》，三種方案的適用場景與維護成本對比寫在那篇裡。

代理模式：規則、全域、直連與系統代理

三種模式的分工

規則模式（rule）按 rules 段逐條比對，命中哪條走哪條，日常使用預設這個。全域模式（global）讓所有流量都走目前選中的節點，忽略規則——它的價值是排查：懷疑規則寫錯時切到全域，如果連線正常，問題就在規則裡。直連模式（direct）全部不走代理，用來排除客戶端本身的影響：直連也不通，表示問題不在代理鏈路。

三種模式在設定檔裡由 mode 欄位決定，也可以在客戶端介面暫時切換，重啟後以設定檔為準。

系統代理與 TUN 的差別

系統代理是客戶端修改作業系統的代理設定（Windows 的網際網路選項、macOS 的網路偏好設定），只對遵守系統代理的程式生效。瀏覽器和大部分命令列工具遵守；部分遊戲、UWP 應用程式，以及自己實作網路堆疊的軟體不受影響，流量會直接出去。

TUN 模式建立一張虛擬網卡，把系統路由表的預設路由指向它，所有 IP 層流量都會被內核接管，不受應用程式是否遵守系統代理的限制。代價是需要管理員權限，並且與部分 VPN、虛擬機網路存在路由衝突。

兩者的另一處差別是 DNS：系統代理模式下，應用程式的 DNS 查詢由系統處理；TUN 模式下 DNS 也由內核接管，這樣才能配合 Fake-IP 做基於網域的規則比對，第 7 章會展開。

連接埠與控制介面

mixed-port 同時提供 HTTP 與 SOCKS5 兩種協定，是目前推薦的單一入口；舊設定裡可能分成 port（HTTP）與 socks-port（SOCKS5）兩個欄位。external-controller 是控制介面，面板透過它讀取連線清單與日誌。預設只監聽 127.0.0.1，只有本機能存取；需要區域網路內其他裝置存取面板時，改監聽位址為 0.0.0.0 並設定 secret，否則等於把控制介面開放給整個區域網路。

mixed-port: 7890
allow-lan: false
external-controller: 127.0.0.1:9090
secret: "your-password"
mode: rule
log-level: info

allow-lan 控制是否允許區域網路裝置透過本機代理上網，與 external-controller 是兩件事：前者開的是代理連接埠，後者開的是控制介面。

選擇順序的建議

先用系統代理加規則模式跑通，確認節點可用、瀏覽器能正常存取；遇到程式不生效再開 TUN。不要一開始就開 TUN：出問題時需要同時判斷節點、DNS、虛擬網卡、路由表四個因素，排查成本高很多。節點連不上時的七個排查環節寫在部落格《Clash 節點逾時無法連線》裡。

規則分流：rules 語法、策略組與優先順序

比對機制：由上而下，命中即停

內核從 rules 陣列的第一條開始逐條比對，第一條命中的規則決定這條連線的去向，後面的規則不再參與。所以陣列順序就是優先順序：範圍最窄、最明確的規則放前面，寬泛的兜底放最後。MATCH 必須放在最後一條，寫在前面會讓它後面所有規則失效——這是規則寫錯裡後果最嚴重的一種。

常用規則類型

• DOMAIN：精確比對網域，只命中寫出來的那一個。
• DOMAIN-SUFFIX：比對網域後綴，example.com 同時命中 a.example.com 和 b.example.com。
• DOMAIN-KEYWORD：網域包含關鍵字即命中，範圍寬，容易誤傷，慎用。
• IP-CIDR：比對目標 IP 段。純 IP 規則需要先拿到 DNS 解析結果才能判斷，加上 no-resolve 可以避免為了比對規則而多做一次解析。
• GEOIP：依 IP 歸屬地比對，常用來把中國大陸位址直連，通常放在網域規則之後。
• PROCESS-NAME：依發起連線的程式名稱比對，桌面端可用，行動端一般不支援。
• RULE-SET：引用外部規則集檔案，把成百上千條規則放進獨立檔案維護。
• MATCH：兜底規則，比對所有剩餘連線，必須最後一條。

策略組：規則指向的出口

proxy-groups 定義規則可以指向的出口組，組裡既可以放節點，也可以放其他組。四種常用類型：select 手動選擇，介面上點哪個用哪個；url-test 定期對組內節點測速，自動選延遲最低的；fallback 依順序取第一個可用的節點；load-balance 在多個節點間分攤連線。

組可以巢狀。常見的三層結構是「手動選擇組 → 自動測速組 → 具體節點」：日常用自動測速組，需要指定時在手動組裡切換。

proxy-groups:
  - name: "PROXY"
    type: select
    proxies: ["AUTO", "DIRECT"]
  - name: "AUTO"
    type: url-test
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    proxies: ["node-a", "node-b"]

rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - DOMAIN-KEYWORD,analytics,DIRECT
  - IP-CIDR,203.0.113.0/24,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

tolerance 是切換門檻（毫秒）：新節點延遲比目前節點低超過這個值才切換，避免兩個節點延遲接近時反覆橫跳。interval 是測速間隔（秒），設得太短會讓低效能裝置持續跑測速請求。

常見寫錯方式

• MATCH 寫在中間：後面所有規則變成死程式碼。
• GEOIP 放在具體網域規則之前：本該走代理的網域被判成中國大陸位址直連。
• IP-CIDR 不帶 no-resolve：每條連線先做一次 DNS 解析，延遲上升。
• 規則指向不存在的策略組名稱：內核報錯或連線被拒，日誌裡能看到明確提示。
• 類型名稱大小寫混用：domain-suffix 不會被識別，類型名稱必須大寫。
• 規則集檔案路徑寫錯：啟動時默默跳過，表現為該規則集涵蓋的網域全部走兜底。

逐條拆解與更多寫法範例見部落格《Clash 自訂規則語法與優先順序》。

TUN 模式：虛擬網卡、DNS 與 Fake-IP

TUN 做了什麼

開啟後，內核建立一張虛擬網卡（Windows 上是 Wintun，macOS 與 Linux 上是 utun 或 tun），並把系統預設路由指向它。應用程式送出的封包先到虛擬網卡，內核讀出來依規則處理，再決定直連還是走代理。因為工作在 IP 層，不依賴應用程式是否遵守系統代理設定，所以遊戲、UWP 應用程式、自己實作網路堆疊的軟體都能被接管。

代價也來自同一層：路由表被改寫，與 VPN、虛擬機、多網卡環境都可能衝突。

關鍵設定項目

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

stack 決定使用者態協定堆疊的實作：system 效能好但相容性一般，gvisor 相容性好但吞吐略低，mixed 讓內核依場景自行選擇。auto-route 讓內核自動寫路由表；auto-detect-interface 自動識別實體出口網卡——這兩項在多網卡機器上尤其重要，關掉後容易出現回程流量走錯網卡，表現為能連上但速度極慢或頻繁斷流。dns-hijack 把送往 53 連接埠的 DNS 查詢劫持給內核處理，這是 TUN 模式下 DNS 不外洩的前提。

DNS 與 Fake-IP

TUN 模式下 DNS 必須交給內核處理，否則應用程式自己解析出真實 IP，規則裡的網域比對就失效了。

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "+.pool.ntp.org"
  nameserver:
    - 223.5.5.5
    - 119.29.29.29

Fake-IP 的運作方式：內核收到 DNS 查詢後立刻回傳一個 198.18.x.x 段的假位址，同時記下這個假位址對應哪個網域。應用程式連到這個假位址時，內核從對照表裡取出網域，用網域去比對規則。好處有兩個：規則比對始終基於網域，即使應用程式先解析後連線；省掉一次真實解析的等待，首次連線更快。

fake-ip-filter 裡的網域不走 Fake-IP，回傳真實位址。區域網路裝置名稱、NTP 時間伺服器、部分需要真實 IP 的區域網路服務必須放進去，否則會出現網頁能開、區域網路裝置連不上這類奇怪現象。nameserver 填本機可達的 DNS 伺服器，不要填已經被代理的位址，否則解析請求會繞一圈回到自己，形成迴圈。

常見問題

• 開啟後完全無法上網：先看日誌裡虛擬網卡是否建立成功，再看 auto-detect-interface 是否正確識別了實體網卡，最後檢查是否有其他 VPN 在搶佔路由。
• 部分應用程式異常：把它們加入 fake-ip-filter，或在規則裡指定直連。
• Windows 上 UWP 應用程式不生效：UWP 應用程式執行在應用程式容器裡，需要為它啟用回送豁免，客戶端一般提供對應開關。
• 與虛擬機衝突：虛擬機的虛擬網卡會被 TUN 的路由規則影響，需要把虛擬網卡加入排除清單，或分時使用。

節點逾時的完整排查順序見部落格《Clash 節點逾時無法連線》。

日常維護：更新、日誌與多裝置同步

訂閱更新

更新頻率取決於服務方的節點變動頻率，一天一次是常見設定。更新後客戶端會重新載入設定，正在進行的連線會短暫中斷。如果發現節點清單長時間不變，先手動觸發一次更新，再看日誌裡的回傳內容；更新成功但節點沒變，表示服務方確實沒調整。

日誌與連線面板

log-level 從 silent、error、warning、info 到 debug 逐級變詳細。排查問題時暫時調到 debug，看內核在連線建立時的實際決策——哪條規則命中、走了哪個出口、有沒有解析失敗。日常保持 info 即可，debug 會明顯增加日誌量，長時間開著會拖慢低效能裝置。

external-controller 提供的介面可以被面板讀取，用來查看每條連線的命中規則、出站節點、上傳下載位元組數。判斷規則是否依預期生效，連線面板比日誌更直接：找到那條連線，看它命中的規則編號和出站組名，與寫下的規則對照。

多裝置同步

訂閱連結同步：所有裝置匯入同一條連結，節點清單自動一致。適合以節點為主、本機自訂少的場景，代價是各裝置的規則設定獨立，改一處不會同步到其他裝置。

自建設定託管：自己維護一份完整設定，所有裝置拉同一個位址，規則與策略組完全一致。適合多裝置且規則複雜的場景，維護成本最高——設定出問題會影響所有裝置。

手動匯出匯入：把設定檔透過區域網路或雲端硬碟傳給其他裝置。適合不常變動的場景，也適合當作前兩種方案的備份手段。

資源佔用與穩定性

規則條目數量直接影響每條連線的比對耗時。幾千條規則在桌面端幾乎無感，但在路由器等低效能裝置上要控制規模，把大段規則拆進 RULE-SET 按需載入。GEOIP 資料庫隨內核更新，不需要手動替換。記憶體佔用與活動連線數、DNS 快取規模相關，長時間執行後如果記憶體持續成長，先檢查是不是有大量 url-test 組在頻繁測速，或者日誌等級一直停在 debug。

多裝置同步三種方案的完整對比見部落格《Clash 多裝置設定同步》。

進階路線：內核特性、自建設定與排錯方法

mihomo 帶來的變化

mihomo 在原版 Clash 的基礎上擴充了入站類型、規則類型與 DNS 能力：更多入站協定、更多規則比對維度（處理程序、規則集、邏輯組合）、DNS 支援更細緻的策略、TUN 實作更完整。訂閱裡出現原版內核不認識的欄位時，換到基於 mihomo 的客戶端即可解析。原版 Clash 內核已停止維護，長期使用建議直接以 mihomo 系客戶端為起點。

從訂閱使用者到設定維護者

進階的第一步，是把訂閱當節點來源而不是完整設定。做法在第 4 章已經給出：用 proxy-providers 引入節點，規則、策略組、DNS 全部自己寫。好處是換服務方時只需要改 provider 的位址，規則體系不用動；規則可以依自己的使用習慣精調，而不是受訂閱方預設規則的限制。

第二步是理解規則集的維護方式：把大段規則拆進 RULE-SET 引用的外部檔案，定期更新，主設定保持精簡。規則集的好處是更新時不影響主設定，壞處是多了一層檔案相依，路徑寫錯會默默失效。

第三步是把設定納入版本管理：每次改動前留一份備份，改動記錄寫清楚。設定出問題時能快速還原，比逐行比對快得多。

一套可重複使用的排錯順序

1. 訂閱：最近一次更新是否成功，節點清單是否為空。
2. 節點：切到全域模式單獨測試一個節點，排除規則因素。
3. DNS：Fake-IP 是否開啟，filter 是否誤傷，解析是否正常。
4. 連接埠：本機連接埠是否被其他程式佔用。
5. 系統代理或 TUN：開關狀態是否與實際期望一致。
6. 規則：連線面板裡看到的是否是預期的策略組。
7. 日誌：把上面六步的觀察與日誌對照，定位真正出問題的一層。

這個順序的價值在於：每一步都排除一類因素，而不是同時懷疑所有環節。七步走完仍然不通，表示問題在更底層（實體網路、伺服器端、系統防火牆），可以把日誌帶到服務方或客戶端社群求助。

繼續深入的方向

• 內核設定文件：理解每個設定項目的預設值，比記住推薦值更有用。
• 規則集生態：了解常見規則集的維護方式與更新節奏，選擇活躍維護的來源。
• 網路基礎：DNS 解析鏈路、路由表、TCP 握手——排錯時最有用的三塊知識。
• 自動化：用指令碼管理設定版本與規則更新，把改動記錄下來。

內核差異的具體對比見部落格《mihomo 內核與原版 Clash 差異》；首次安裝的檢查清單見部落格《Clash 首次安裝與初始設定》。想先看客戶端橫向對比，到選型指南；確定之後直接到下載頁取對應平台的安裝包，第一次設定跟著快速上手教學走一遍即可。