Clash 從零到精通：用戶端、訂閱與規則分流

一、核心概念：用戶端、核心與流量路徑

理解 Clash 的第一步不是背下一串設定欄位，而是分清三個層次：用戶端介面、代理核心與外部訂閱服務。用戶端負責顯示設定檔、策略組、連線狀態與系統開關；mihomo 是實際解析 YAML、比對規則並建立代理連線的核心；訂閱服務則負責提供一份或多份節點與策略設定。不同軟體可能使用相近的介面名稱，但只要核心、設定格式與系統接管方式不同，操作結果就可能不同。

一次普通的網頁請求通常先由應用程式交給系統網路堆疊，再依據用戶端開啟的系統代理、增強模式或 TUN 接管方式進入核心。核心讀取目前設定，依序處理 DNS、規則比對、策略組選擇與出站連線，最後將回應交還給應用程式。在規則模式下，網域可能先經過 DNS 解析，也可能以網域形式直接參與比對；實際行為取決於 DNS 模式、嗅探設定與設定檔寫法。因此看到「用戶端已執行」並不代表每個應用程式都已經透過代理。

1.1 設定檔、代理組與節點的差異

節點是具體的出站連線定義，包含伺服器位址、連接埠與協定相關參數；代理組是多個節點或其他策略組的選擇器，常見類型包括手動選擇、自動選擇、故障轉移與負載平衡；設定檔則將代理、代理組、規則、DNS 與連接埠等部分組合起來。一個節點可以被多個代理組引用，一個代理組也可以將另一個代理組作為成員。看到策略組名稱卻沒有可用選項，通常表示節點未成功解析，或組內引用的名稱與實際代理名稱不一致。

「代理連接埠」與「混合連接埠」也不應混為一談。HTTP 連接埠只接收 HTTP 代理請求，SOCKS 連接埠接收 SOCKS 請求，混合連接埠通常同時支援兩種常見協定。系統代理設定一般只需填入混合連接埠，或用戶端明確標示的 HTTP 連接埠；若誤將控制連接埠填入系統代理，瀏覽器可能顯示連線失敗，但用戶端本身仍處於執行狀態。控制連接埠只用於外部 API 或介面通訊，不承擔一般網頁流量。

1.2 先建立可觀察的判斷順序

排錯時建議依序確認「應用程式是否發出請求、系統是否將請求交給用戶端、用戶端是否比對到規則、策略組是否選出有效出站、遠端連線是否成功」。不要一開始就大量修改 DNS 或規則。先在用戶端的連線、日誌或請求清單中觀察目標網域；若完全沒有記錄，問題多半出在系統代理、TUN 或應用程式本身的代理支援；若有請求但規則命中 DIRECT，表示設定行為符合目前規則，需要檢查規則順序；若命中代理組但全部連線失敗，再轉向節點、網路與 TLS 排查。

二、選擇用戶端：依平台、核心與接管範圍安裝

選擇用戶端應先看平台與使用範圍，再考量介面偏好。Windows、macOS、Linux 通常需要桌面用戶端提供系統代理、設定管理與日誌檢視；Android 需要支援行動系統 VPN 介面；iOS 則透過 App Store 安裝 Clash Plus。對於伺服器、旁路由或需要長時間在背景執行的環境，直接使用 mihomo 核心更合適，但它缺少桌面用戶端提供的圖形化設定入口，維護要求也較高。

本站下載頁將 Clash Plus 列在各平台首位，原因是涵蓋範圍較完整，適合希望採用一致操作方式的使用者。Clash Verge Rev、FlClash、Clash Nyanpasu、ClashX Meta 與其他用戶端各有平台取向。已停止維護的軟體仍可能在舊裝置上執行，但不應作為新安裝的首選。安裝前先確認系統架構與套件格式；Windows 常見的是安裝程式或壓縮檔，macOS 要區分 Intel 與 Apple Silicon，Linux 則需確認發行版支援的安裝格式。

2.1 安裝前的三項確認

第一項是平台架構。Windows 的 ARM64 裝置不能直接使用只面向 AMD64 的程式；macOS 的 Apple Silicon 與 Intel 版本也不應混裝。第二項是用戶端的執行權限。系統代理、開機啟動與 TUN 通常需要額外的系統權限，安裝程式能開啟並不表示這些權限已獲授予。第三項是設定來源。只從可信的訂閱入口複製網址，避免將網頁網址、控制台網址或含有額外說明文字的整段內容貼到訂閱欄位。

下載完成後先啟動用戶端，不要立即同時開啟系統代理、TUN 與瀏覽器擴充功能。先確認介面能載入，能看到設定檔或空白的設定清單，再進行下一項設定。這樣每一步只有一個變數，出現錯誤時便能判斷是安裝、匯入還是系統接管所致。安裝路徑、日誌路徑與設定儲存位置因用戶端而異；若要遷移裝置，優先使用用戶端提供的匯出功能，不要直接複製未知格式的快取目錄。

2.2 圖形化用戶端與直接執行核心的取捨

圖形化用戶端適合個人電腦，因為它提供設定更新、策略組切換、連線日誌與系統代理開關。直接執行核心適合路由器、伺服器或容器環境，透過檔案與指令維護設定，可以減少桌面層依賴，但需要自行處理程序守護、檔案權限、日誌輪替與路由轉送。兩者使用的設定概念相通，卻不能假設每個桌面按鈕都對應一個可直接複製的命令列參數。

三、匯入訂閱：設定產生、更新與回復

訂閱網址本質上是會回傳設定內容的 URL。用戶端請求該網址後，可能取得完整 YAML、經編碼的節點集合，或由伺服器依用戶端類型產生的設定。匯入時應使用用戶端的「訂閱管理」、「設定檔」或類似入口，而不是將網址直接當成一般節點逐一新增。首次匯入後，先觀察設定名稱、代理數量、策略組與規則是否出現，再決定是否啟用。

匯入訂閱前，建議保留目前可用的設定。許多用戶端更新時會覆寫舊檔案；若新內容為空、格式錯誤或策略組名稱變更，回復檔案便能協助恢復工作狀態。更新訂閱時不要只看更新按鈕是否顯示成功，還要開啟設定詳情，檢查更新時間、解析狀態與代理組成員。有些伺服器會回傳 HTTP 成功，但正文其實是登入頁面或錯誤提示；此時用戶端可能只回報解析失敗，實際原因要從訂閱網址的回應內容判斷。

3.1 匯入後的最小檢查

第一步檢查代理組是否有成員。常見的主組名稱可能是「節點選擇」、「Proxy」或服務提供者自訂的名稱，名稱不同不代表功能不同。第二步檢查代理組目前選擇的是實際節點或可用的子策略組，不能停留在已刪除的名稱上。第三步檢查規則是否存在。沒有規則的設定仍可在全域模式下運作，但在規則模式下，很可能所有請求都落到預設策略。第四步檢查 DNS 部分是否與目前網路環境相容，尤其啟用 fake-ip 後，區域網路裝置與某些本機服務可能需要額外規則。

訂閱更新不是越頻繁越好。更新會重新下載設定、重建代理組，並可能觸發節點健康檢查。日常使用可依服務提供者建議更新；如果目前設定穩定，不必因用戶端介面出現提醒就頻繁點選。更新失敗時保留舊設定繼續使用，記錄失敗時間與錯誤文字，再檢查網路連通性、訂閱權限、網址編碼及伺服器回傳類型。

3.2 設定檔的分層思維

設定可以理解為基礎檔案、訂閱內容與本機覆寫三層。基礎檔案定義連接埠、日誌與 DNS 等通用設定；訂閱內容提供節點與策略組；本機覆寫則用於調整規則、加入區域網路直連或變更模式。不同用戶端對覆寫功能的名稱與合併規則不完全一致，因此修改前應先確認最終產生的設定，而不是只看某個編輯框中的片段。若用戶端支援設定驗證，儲存後先執行驗證再啟用。

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

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

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

上面的片段展示了設定的骨架：混合連接埠用於本機 HTTP 與 SOCKS 請求，規則模式依序處理請求，區域網路存取預設不對外開放，最後一條 MATCH 作為預設處理。它不是任何訂閱服務的完整設定，不能直接取代服務提供者提供的節點內容。編輯 YAML 時尤其要注意縮排、冒號後的空格與清單層級；多出一個 Tab 或縮排錯誤，都可能導致整份檔案無法解析。

四、代理模式：規則、全域與直連的驗證方法

代理模式決定請求如何進入策略選擇。規則模式依設定檔中的 rules 由上到下比對，命中後交給指定策略組；全域模式通常將請求統一交給某個代理組，不再依賴網域規則決定 DIRECT 或代理；直連模式則讓請求繞過代理。不同用戶端的按鈕名稱可能略有差異，但判斷方式一致：目前模式、目前策略組與單一請求的實際命中結果需要一併查看。

規則模式適合日常使用，因為區域網路、中國大陸常用服務與需要代理的目標可以分開處理。全域模式適合短時間測試：當規則結果不確定時，將目標統一交給已知可用的代理組，可以判斷問題來自規則還是連線本身。直連模式適合確認原始網路狀態，也適合排查代理是否造成憑證、DNS 或登入問題。測試結束後要切回合適模式，否則瀏覽器表現可能與平時不同。

4.1 從日誌確認模式是否生效

選擇模式後開啟連線日誌，造訪明確的測試網址或重新整理現有頁面。記錄中通常能看到請求網域、命中規則、命中的策略組與最終出站。如果請求命中 DIRECT，先確認目前是否為規則模式，以及規則是否明確要求直連；如果請求命中代理組但頁面無法開啟，切換到代理組中的另一個可用節點，觀察錯誤是否改變。若日誌沒有出現請求，表示流量尚未進入用戶端，應檢查系統代理、瀏覽器獨立代理設定、TUN 狀態或應用程式是否使用自己的網路通道。

不要把「網頁能開啟」當作唯一驗證標準。瀏覽器可能使用快取、IPv6、應用程式自身的代理設定或先前建立的連線。可以關閉快取後重新載入，或在用戶端連線記錄中確認確實產生了新請求。使用命令列驗證時，明確指定代理連接埠比依賴系統環境變數更可靠：

curl --proxy http://127.0.0.1:7890 https://example.com/
curl --socks5-hostname 127.0.0.1:7890 https://example.com/

第一條指令使用 HTTP 代理，第二條使用 SOCKS5，並讓網域在代理端解析。若 HTTP 指令失敗而 SOCKS5 成功，可能是連接埠協定或用戶端監聽設定不匹配；若兩條都失敗，再查看節點連線與日誌。範例中的網域僅用於驗證指令格式，實際測試應選擇能正常存取且允許命令列請求的目標。

4.2 系統代理、應用程式代理與 TUN 的差異

系統代理通常會影響遵循系統代理設定的瀏覽器與桌面應用程式，優點是變更少、容易關閉；不遵循系統代理的程式仍可能直連。應用程式代理是程式內部的設定，瀏覽器擴充功能、開發工具與終端機可能各自使用不同入口。TUN 則在更低的網路層接管流量，涵蓋範圍更大，但會涉及虛擬網卡、系統權限、路由與 DNS，設定錯誤時影響範圍也更廣。排錯時從系統代理開始，確認目標應用程式已被涵蓋後，再考慮 TUN。

五、規則分流：比對順序、策略組與自訂規則

規則分流的關鍵在於順序。核心從第一條規則開始判斷，請求一旦命中就停止繼續向下尋找，並交給規則右側指定的策略組或 DIRECT、REJECT 等動作。因此範圍過大的規則若放在前面，可能覆蓋後方更精確的規則。設定自訂規則時，應先描述目標與範圍，再選擇規則類型，最後放在正確位置，而不是看到某個網域無法開啟就隨意新增 MATCH。

常用規則類型包括 DOMAIN 精確比對單一網域、DOMAIN-SUFFIX 比對網域及其子網域、DOMAIN-KEYWORD 依關鍵字比對、IP-CIDR 比對 IPv4 網段、IP-CIDR6 比對 IPv6 網段、GEOIP 依 IP 地理資料庫比對，以及 PROCESS-NAME 依程序名稱比對。不同核心版本與平台對程序名稱、網路堆疊及嗅探的支援可能不同，使用前應確認目前用戶端的核心能力。規則寫得越寬，誤比對機率越高；優先使用精確網域或明確後綴。

5.1 規則組的組織方式

建議將策略組分成「手動選擇」與「用途分流」兩層。手動選擇組包含具體節點或自動選擇組，負責決定目前出站；用途分流組則負責將不同類別的請求交給手動選擇、DIRECT 或其他組。例如廣告攔截、區域網路、串流媒體與預設請求都可以各自分組。如此一來，修改節點時只需調整手動選擇組，規則側的結構仍能保持穩定。若將大量節點直接寫入每個業務組，訂閱更新後名稱變更便會造成多處維護。

策略組名稱是設定中的引用鍵，必須完全一致，包括大小寫、空格與標點。下面的範例展示一個小型結構：

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

  - name: 自動選擇
    type: url-test
    url: http://www.gstatic.com/generate_204
    interval: 300
    proxies:
      - 節點一
      - 節點二

rules:
  - DOMAIN-SUFFIX,lan,DIRECT
  - DOMAIN-SUFFIX,example.org,節點選擇
  - GEOIP,LAN,DIRECT
  - MATCH,節點選擇

url-test 組會依設定進行可用性測試，並選擇表現較好的成員，但測試網址可連通不一定代表所有目標都能連通，interval 也不宜設定得過短。select 組則由使用者手動選擇。範例中的節點名稱必須確實存在於 proxies 區域，不能直接複製到沒有這些節點的設定中。

5.2 自訂規則的驗證流程

新增一條規則後，不要立即再增加第二條。先儲存並重新載入設定，造訪明確屬於目標範圍的網域，再從日誌確認規則文字與策略組。如果沒有命中，可能是網域實際使用了另一個後綴、請求走 IP、DNS 結果未被嗅探，或規則已被前面的項目提前處理。如果已命中但仍無法連線，表示規則比對已成功，接下來應檢查策略組與出站連線，而不是繼續修改規則。

規則數量較多時，可以用註解依用途分段，但不要在關鍵欄位中加入無法解析的說明文字。遇到訂閱自動產生的規則集，應先確認規則集的更新狀態與引用名稱，再加入本機規則。若本機規則與訂閱規則衝突，應明確哪一方優先，並在更新後再次檢查最終設定。本站常見問題頁面收錄了策略組為空、規則未生效與訂閱更新異常等常見排錯入口。

六、TUN 模式：虛擬網卡、DNS 與系統流量接管

TUN 模式透過虛擬網路介面接收系統層流量，再由核心依據設定轉送。它可以涵蓋不遵循系統代理的程式，因此適合需要統一接管終端流量的情境；同時它也比一般系統代理更接近系統網路底層，啟用後會改變路由與 DNS 行為。TUN 不是「更快的代理模式」，而是一種不同的流量入口。啟用前應先確保一般系統代理已可正常使用，並確認用戶端具備建立虛擬介面的權限。

啟用 TUN 時，通常要處理三個問題：裝置權限、路由接管與 DNS。桌面系統可能跳出管理員授權，Android 則透過系統 VPN 授權建立本機 VPN；Linux 可能需要核心模組、capability 或 root 權限。路由接管決定哪些目標進入 TUN，auto-route、strict-route 等設定的含義依用戶端與核心設定而異。DNS 處理不當會導致網域解析走本地網路，出現規則判斷與實際連線不一致，或區域網路網域無法解析。

6.1 建議的啟用順序

先關閉不必要的第三方 VPN、網路加速器與瀏覽器代理擴充功能，避免多個虛擬介面互相競爭。確認用戶端在一般系統代理模式下可以存取測試目標，再開啟 TUN 並接受系統權限要求。啟用後先測試區域網路閘道、一般網頁與一個明確需要代理的目標，分別觀察能否解析、是否有連線日誌，以及規則命中是否改變。若只有區域網路失效，優先檢查 LAN 規則、路由排除與 DNS；若所有網路都失效，先關閉 TUN、恢復系統代理，再檢查權限與虛擬介面。

在行動裝置上，VPN 圖示出現只代表系統 VPN 已建立，不代表目前設定中的節點可用。依應用程式代理功能可能讓部分應用程式繞過 VPN，也可能因電池最佳化而在背景停止。Android 需要檢查電池背景限制、始終開啟 VPN 的系統選項與應用程式分流清單；iOS 的網路接管能力取決於應用程式本身提供的系統延伸功能，不應將桌面 TUN 的概念直接套用到行動端。

6.2 DNS 行為與 fake-ip 的判斷

fake-ip 模式會為網域指派虛擬位址，讓核心能依網域繼續進行規則處理，適合需要穩定辨識網域的情境。但某些區域網路網域、本機印表機、企業內網與依賴實際位址的程式可能不相容。遇到這類問題，可以為區域網路後綴、私有位址與特定網域加入 DIRECT 或 fake-ip-filter，具體欄位以目前設定與用戶端文件為準。不要為了修復一台區域網路裝置就關閉所有 DNS 處理，應先限定問題範圍。

tun:
  enable: true
  stack: system
  auto-route: true
  auto-detect-interface: true

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-filter:
    - "*.lan"
    - "*.local"

這段設定用於說明常見欄位的關係，不能取代平台實際需要的完整 DNS 伺服器清單。stack、auto-route 與 enhanced-mode 是否可用，應以目前核心支援範圍為準。修改設定後先進行語法檢查，再一次只變更一個欄位。若 TUN 在某個平台無法啟動，可在用戶端設定中關閉增強模式，回到系統代理路徑完成日常使用。

七、日常維護、故障排查與進階路線

穩定使用取決於可回復、可觀察與少變更三項原則。可回復表示保留最近一次能正常連線的設定；可觀察表示知道在哪裡查看日誌、規則命中與系統代理狀態；少變更表示每次只調整一項相關設定。落實這三項原則後，大多數故障都能縮小到設定解析、系統接管、規則判斷或遠端連線其中一個範圍，不必反覆重新安裝用戶端。

7.1 一套可重複的排錯順序

第一步確認用戶端程序與目前設定。若設定未成功載入，先恢復上一份可解析的檔案。第二步確認監聽連接埠，檢查連接埠是否被其他程式占用，並確認應用程式實際使用的是 HTTP、SOCKS 還是混合連接埠。第三步確認請求是否進入用戶端：查看連線清單或日誌，若完全沒有記錄，就不要先修改節點。第四步確認規則命中與策略組選擇，區分 DIRECT、REJECT、代理組與空組。第五步再檢查節點連線、DNS、TLS 與遠端服務狀態。

如果瀏覽器提示代理連線失敗，先查看系統代理位址是否仍指向本機與正確連接埠；如果只有一個應用程式失敗，檢查該應用程式是否使用獨立代理、是否啟用自己的 DNS，或是否遭防火牆阻擋。若所有應用程式都失敗但用戶端日誌沒有請求，問題在接管層；若日誌顯示連線遭拒，問題在策略組或節點；若建立連線後出現憑證或網頁內容錯誤，才進一步檢查 TLS、系統時間、憑證鏈與目標網站回應。

7.2 設定更新與日誌管理

訂閱更新前記錄設定名稱與目前策略組，更新後對照檢查組名、節點數與規則狀態。不要把節點數量當作品質指標，也不要因為某次更新後清單變長，就認為設定一定更好。排錯時可以暫時提高日誌層級，確認問題後恢復到適中的層級，避免長期產生大量檔案。桌面用戶端的日誌儲存位置因專案而異；出現重複錯誤時，複製其中一段包含時間、目標與錯誤原因的記錄即可，不需要上傳整份設定或含有帳戶資訊的訂閱網址。

設定檔中可能包含訂閱產生的敏感內容。分享日誌或尋求協助前，應移除訂閱 URL、驗證資訊、節點位址中不必要的識別欄位與本機路徑。可以保留欄位名稱、規則順序、連接埠類型與錯誤文字，讓排錯者理解結構，但不應公開完整存取網址。若懷疑訂閱網址外洩，應在伺服器端重新產生網址，而不是只刪除瀏覽器歷史紀錄。

7.3 從個人電腦邁向進階設定

完成基礎使用後，可以依以下順序提升：先掌握規則模式與策略組引用，再了解 DNS 與 fake-ip 的界線，之後理解 TUN、路由與區域網路排除，最後再考慮路由器、旁路由或伺服器部署。每一步都應建立在前一步可驗證的基礎上。直接將複雜設定複製到本機，往往會同時引入多個未知變數，發生故障時很難判斷是核心能力、平台權限還是設定語法造成的。

路由器部署還需要考慮轉送路徑、閘道位置、DHCP、IPv6、防火牆與裝置旁路範圍。核心監聽位址如果只綁定本機，區域網路裝置便無法存取；如果直接暴露在不可信網路，又會擴大管理與代理入口。伺服器執行時要設定程序守護、日誌輪替與升級回復，用戶端介面中的「系統代理」按鈕不能取代路由器的流量轉送規則。對於這部分內容，建議先在隔離環境中驗證，再逐步遷移到家庭網路。

7.4 故障記錄範本

每次排錯可以記錄平台、用戶端名稱、目前模式、是否啟用 TUN、設定是否剛更新、目標網域、日誌中的錯誤文字，以及已嘗試的一項變更。這類記錄比「突然不能用了」更容易定位，也能避免重複嘗試相同路徑。若需要進一步查閱，先看常見問題中的分類答案，再回到本文對應章節；Windows UWP 迴圈限制、HTTPS 憑證錯誤與代理模式差異等具體情境，也可以閱讀Windows UWP 應用程式無法使用 Clash 代理與HTTPS 憑證錯誤排查。

Clash 的設定能力來自多個層次的組合，真正可靠的使用方式不是記住一份永遠不變的範本，而是建立觀察與驗證習慣。先讓基礎連線穩定，再逐步加入規則、DNS 與 TUN；每次修改保留記錄，每次更新保留回復點。需要安裝套件時，前往Clash 下載頁面依平台選擇；首次設定則回到快速入門教學完成主要操作。