先分清介面、核心與設定檔

Clash 客戶端通常由三層組成：圖形介面負責顯示按鈕與狀態，Clash Meta（目前常用名稱為 mihomo）等核心負責接管連線、執行 DNS 與規則比對，YAML 設定檔則用來定義連接埠、節點、策略組與規則。在介面上點選「節點 A」，本質上是向核心控制介面提交一次策略組選擇；點選「更新訂閱」，則是下載遠端設定並讓核心重新載入。

不同客戶端可能將欄目翻譯為「代理」、「策略」、「Proxies」，也可能把「設定」寫成「訂閱」或「Profiles」。按鈕位置也會因桌面版與行動版而異，但資料關係大致相同。閱讀介面時不要只記住圖示位置，應先判斷目前區域是在控制核心、管理設定，還是查看執行紀錄。

頂端狀態區通常會顯示什麼

以常見桌面設定為例，混合代理連接埠可能設為 7890，外部控制連接埠可能設為 9090。舊版設定也常將 HTTP 與 SOCKS 分別放在 7890 和 7891。這些只是常見值，不是固定標準；判斷實際連接埠應查看「設定」→「網路」→「連接埠設定」，或直接讀取目前 YAML 的 mixed-port、port 與 socks-port。

代理頁：策略組、節點與延遲數值

代理頁不只是簡單的伺服器清單。它會先顯示設定中的策略組，再列出每個組內可選的節點或下層策略組。規則最後會指向策略組名稱，再由策略組決定連線使用哪個節點。理解這層關係後，才能解釋為什麼切換某個節點只會影響部分流量。

如何查看策略組卡片

一個策略組通常包含組名、類型、目前選項與候選清單。例如規則將串流媒體網域交給「串流媒體」，而「串流媒體」組目前選擇「香港節點」。此時修改「節點選擇」組未必會影響串流媒體，因為兩條規則可能指向不同的策略組。

DIRECT 表示連線直接從本機網路送出，REJECT 表示拒絕連線。兩者都是內建策略，不是遠端伺服器。若某個廣告網域命中 REJECT，日誌中可能會出現拒絕紀錄，而代理頁不會顯示節點延遲。

延遲測試結果不能當成頻寬

節點旁的 68 ms、214 ms 等數值，通常來自對測試 URL 發出 HTTP 請求所耗費的時間。它能反映當下的連線回應速度，但不能直接代表下載速度。測試 URL、DNS 解析、TLS 交握、節點負載與本機 Wi-Fi 都會影響結果。一次測得 80 ms 的節點，吞吐量可能高於 50 ms 的節點。

  1. 先點選個別策略組的測試按鈕，等待所有候選項目回傳結果。
  2. 對顯示逾時的節點再測試一次，排除瞬間封包遺失。
  3. 選擇候選項目後重新開啟目標網站，讓新連線使用新的策略。
  4. 如果舊頁面仍使用原節點，請在連線頁終止對應連線，或等待連線自然關閉。

設定頁：訂閱、目前設定與覆寫

設定頁管理的是設定來源。常見項目包括遠端訂閱、本機 YAML、客戶端產生的暫存設定，以及經過覆寫處理後的執行設定。一個客戶端可以儲存多份設定，但核心同一時間通常只會載入其中一份目前設定。

訂閱卡片上的操作各自有什麼作用

更新訂閱後，先確認「最後更新」時間是否變更，再查看節點數量與策略組是否符合預期。如果時間更新但內容不變，可能是遠端回傳了相同設定；如果出現 HTTP 401、403 或 429，應檢查訂閱權限、連結有效期限與請求頻率；如果下載成功但載入失敗，則應繼續檢查 YAML 語法與欄位相容性。

覆寫與直接編輯的差異

遠端訂閱會在下次更新時重新下載。直接修改快取檔案，通常會被新內容覆蓋。覆寫功能則會在訂閱下載後、核心載入前追加或調整欄位，更適合保留本機連接埠、DNS 或 TUN 參數。不同客戶端可能將入口放在「設定」→「覆寫」，也可能放在設定卡片的更多選單中。

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

external-controller: 127.0.0.1:9090

這段通用欄位表示混合代理在本機 7890 監聽，執行模式為規則模式，日誌層級為 info，區域網路裝置無法直接存取該代理連接埠，控制介面只監聽回送位址。若圖形介面顯示的連接埠與檔案不同，應確認客戶端是否透過覆寫產生了另一份執行設定。

日誌頁：從一筆紀錄還原連線路徑

日誌頁用於查看核心事件。內容既包括設定載入、監聽連接埠、DNS 初始化等執行訊息，也包括連線目標、規則命中與策略鏈路。排查「客戶端顯示已連線但網站無法開啟」時，日誌通常比代理頁的延遲數值更直接。

如何選擇日誌層級

常見操作路徑是「設定」→「參數設定」→「日誌層級」→「Info」。需要追蹤 DNS 或 TUN 細節時，再暫時切換至 Debug，重現一次問題後恢復 Info。不同客戶端的選單文字略有差異，但最後修改的通常是設定欄位 log-level。

一筆連線日誌包含哪些線索

TCP 127.0.0.1:53142 --> example.com:443
match DomainSuffix(example.com)
using ProxyGroup[Hong Kong 01]

第一行說明本機程序透過 TCP 存取 example.com:443；第二行表示網域後綴規則命中；第三行顯示規則指向的策略組以及最後選擇。實際 mihomo 日誌格式會隨版本與客戶端包裝方式變化，但排查時應持續尋找四項資訊：協定、目標位址、命中規則、出站鏈路。

  1. 清除目前日誌，避免舊紀錄造成干擾。
  2. 關閉目標應用程式的舊連線，重新開啟目標頁面。
  3. 依網域、目標 IP 或連接埠篩選，例如搜尋 :443。
  4. 確認紀錄是 DIRECT、某個代理組，還是 REJECT。
  5. 若完全沒有紀錄，請檢查該應用程式是否讀取系統代理，或是否需要啟用 TUN。

連線頁如何與三大頁面配合

不少客戶端還提供「連線」頁面，顯示目前活動連線的來源位址、目標主機、下載量、上傳量、規則與策略鏈。日誌偏向事件流，連線頁則偏向目前狀態。兩者結合後，可以判斷切換節點後，舊下載為何仍使用原本的路徑。

假設瀏覽器已透過「節點 A」建立 HTTP/2 長連線，此時在代理頁切換至「節點 B」，既有連線通常不會遷移。連線頁仍會顯示舊鏈路，新開啟的連線才會採用節點 B。點選終止連線會中斷目前請求，正在儲存的檔案或即時通話也可能因此中斷，因此不要把「全部關閉」當成日常重新整理按鈕。

系統代理與 TUN 的介面差異

系統代理通常適合瀏覽器及遵循作業系統代理設定的軟體。Windows 11 可在「設定」→「網路和 Internet」→「代理」查看系統代理狀態；macOS 可在「系統設定」→「網路」→「目前網路」→「詳細資訊」→「代理」核對。客戶端啟用系統代理後，位址通常會指向 127.0.0.1 與目前的 HTTP 或混合連接埠。

TUN 模式透過虛擬網卡接管更多流量，適用於不讀取系統代理的應用程式、部分命令列程式，以及需要 UDP 的情境。桌面系統首次啟用時可能會要求管理員權限。若啟用 TUN 後完全無法上網，應檢查虛擬介面是否建立、預設路由是否寫入、DNS 是否由核心接管，以及其他 VPN 或網路過濾軟體是否同時修改路由。

新裝機後的介面檢查順序

第一次開啟客戶端時，不必立即修改複雜規則。先完成一條可驗證的最短鏈路：載入設定、啟動核心、選擇策略、開啟接管、查看日誌。以下順序適用於 Windows 11 24H2、macOS 及常見 Android 客戶端，具體授權提示由系統決定。

  1. 進入設定頁：匯入訂閱或本機 YAML，確認設定能夠解析，策略組與節點數量正常。
  2. 設為目前設定：觀察頂端狀態，確認核心進入執行狀態，而不只是完成檔案下載。
  3. 進入代理頁：對候選節點執行一次延遲測試，在手動選擇組中選定一個能回應的節點。
  4. 開啟系統代理：桌面版先用系統代理驗證瀏覽器流量，監聽位址應為本機位址，連接埠應與設定頁一致。
  5. 開啟日誌頁：保持 Info 層級，造訪一個新網域，確認出現目標、規則與策略紀錄。
  6. 依需求開啟 TUN：僅在應用程式不讀取系統代理、需要接管 UDP，或希望統一管理流量時啟用。

常見介面現象與對應檢查項目

從介面操作轉向閱讀設定

熟悉三個頁面後，可以將每次點選對應回 YAML。代理頁來自 proxy-groups 與 proxies，設定頁管理整個檔案及更新來源，日誌頁呈現 rules 的比對結果。系統代理與 TUN 則決定流量是否先進入核心。這樣閱讀介面，就不必依賴某一版本客戶端的固定版面。

修改設定時應維持驗證閉環：儲存後確認設定重新載入，進入代理頁檢查策略組仍然存在，再用日誌驗證目標網域命中了預期規則。若出現異常，先復原到上一份可用設定，不要在無法啟動的檔案上持續疊加修改。