Clash 用戶端介面速覽：代理頁、設定頁與日誌頁各自管理什麼

先了解用戶端的四層結構

常見的 Clash 圖形化用戶端雖然名稱與版面配置各不相同，但核心資訊大致可分為四層：設定決定有哪些代理節點與規則，代理頁決定策略組目前使用哪個出口，連線頁顯示目前經過核心的工作階段，日誌頁記錄核心如何處理這些工作階段。系統代理、TUN 模式與連接埠設定則位於更底層，負責將裝置流量送入 Clash 或 mihomo 核心。

以採用 mihomo 核心的桌面用戶端為例，左側通常會看到「總覽」「代理」「設定」「連線」「日誌」與「設定」。有些用戶端將設定稱為「訂閱」、將代理稱為「策略」，也有用戶端把核心設定放在獨立的「服務」頁面。名稱可能不同，但資料流向基本不變。

總覽頁適合判斷「是否有流量進入」

總覽頁通常會顯示核心狀態、上傳速度、下載速度、活動連線數與記憶體用量。開啟系統代理後造訪一個新網頁，如果連線數從 0 增加到 6，下載速度短暫出現 320 KB/s，表示至少有流量進入核心。這個現象只能證明應用程式與 Clash 之間已建立連線，無法單獨證明遠端代理節點可用。

如果總覽頁始終維持 0 B/s，應先檢查系統代理開關與監聽連接埠，而不是頻繁切換節點。若總覽頁已有流量但網頁仍無法開啟，再前往代理頁、連線頁與日誌頁查找節點逾時、DNS 失敗或規則誤判。

代理頁：策略組與節點不是同一層

代理頁最容易造成誤解。頁面上較大的卡片通常是策略組，展開策略組後列出的才是節點或另一個策略組。設定檔透過 proxy-groups 定義這些關係。規則通常指向策略組名稱，而不是直接寫死某個節點。

例如，一條規則將流量交給「節點選擇」，該策略組目前選取「自動選擇」，而「自動選擇」又透過延遲測試選中「東京 02」。實際鏈路會呈現為「節點選擇 → 自動選擇 → 東京 02」。在連線詳細資訊中看到多層鏈路屬於正常情況。

常見策略組類型

• 手動選擇：對應 select，由使用者指定節點或下層策略組。選擇會持續到重新載入設定、選項失效或用戶端重設狀態。
• 自動測速：對應 url-test，依測試位址與間隔測量節點，通常選取延遲較低且測試成功的結果。
• 故障轉移：對應 fallback，優先使用清單中位置較前且通過健康檢查的節點。
• 負載平衡：對應 load-balance，依設定策略在多個可用節點之間分配連線。
• 直連與拒絕：DIRECT 表示直接連線至目標，REJECT 表示阻止符合條件的流量。

延遲數值應該怎麼看

節點右側的 38 ms、126 ms 或 Timeout，通常來自一次 HTTP 健康檢查。它不是完整網頁的載入時間，也不等同於 ICMP Ping。測試過程還可能包含 DNS、TCP、TLS 與 HTTP 回應時間，具體取決於設定中的測試 URL 與用戶端實作。

穩妥切換節點的順序

1. 在代理頁找到規則實際引用的主要策略組，例如「節點選擇」或「代理」。
2. 先執行一次延遲測試，排除顯示 Timeout 的節點。
3. 選擇延遲穩定的節點，不要只比較單次測試中的最小數值。
4. 新開一個瀏覽器分頁，避免舊連線繼續沿用原有鏈路。
5. 進入連線頁，檢查新連線的策略鏈是否包含剛選擇的節點。

設定頁：訂閱、本機檔案與目前設定

設定頁管理的是核心輸入。一份完整設定通常包含連接埠、DNS、代理節點、策略組與規則。訂閱連結是設定來源之一，本機 YAML 檔案則是另一種來源。將訂閱加入用戶端，只代表設定項目已儲存；只有將它設為目前設定並成功載入後，代理頁才會出現對應的策略組。

設定卡片上的資訊分別代表什麼

• 設定名稱：方便辨識來源，可以是用戶端產生的名稱，也可以手動修改。
• 更新時間：最近一次成功取得或儲存設定的時間，不代表當時所有節點都可用。
• 更新間隔：用戶端預定重新取得訂閱的週期，常見設定為 6、12 或 24 小時。
• 目前標記：表示核心正在使用這份設定。僅選取卡片但未載入時，狀態可能不會變更。
• 流量資訊：部分訂閱回應標頭會提供已用流量、總流量與到期時間；未提供時用戶端無法顯示。

常見操作路徑是「設定」→「新增」→「從 URL 匯入」，貼上訂閱位址後儲存；接著在設定卡片選單中選擇「設為目前」或「啟用」。不同用戶端也可能將入口寫成「訂閱」→「新增訂閱」。更新時應使用卡片上的更新按鈕，而不是反覆刪除後重新匯入。

本機 YAML 設定適合精細控制

本機檔案允許直接查看與修改欄位。YAML 使用空格表示層級，使用 Tab 縮排或層級錯置都可能導致載入失敗。以下是一段用於說明介面關係的簡化結構，其中連接埠、策略組與規則會分別對應到設定頁、代理頁及連線詳細資訊：

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

proxies:
  - name: example-node
    type: socks5
    server: 127.0.0.1
    port: 1080

proxy-groups:
  - name: 節點選擇
    type: select
    proxies:
      - example-node
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,節點選擇
  - MATCH,DIRECT

mixed-port: 7890 表示 HTTP 與 SOCKS 入站可共用 7890 連接埠。mode: rule 表示依規則處理連線。最後的 MATCH,DIRECT 是兜底規則：前面的規則都未命中時直接連線。實際訂閱設定通常還會包含 DNS、規則集合、provider 與更多策略組。

更新設定後，為什麼選擇會改變

訂閱更新可能會新增、刪除或重新命名節點。如果策略組先前選中的節點不再存在，核心會回到組內可用選項，具體結果取決於用戶端的狀態持久化與策略組類型。代理頁突然從「東京 02」變為「自動選擇」，不一定是開關失效，也可能是新設定中沒有同名節點。

更新後可從三個位置核對：設定頁確認更新時間已變更，代理頁確認策略組內容已重新整理，日誌頁確認重新載入設定時沒有報錯。只看到「下載成功」還不夠，因為下載完成與核心成功載入是兩個階段。

連線頁：確認某個程式究竟經過哪裡

連線頁是驗證分流結果最直接的位置。每筆記錄通常包括來源位址、目標網域或 IP、網路類型、上傳下載量、命中規則、策略鏈與建立時間。瀏覽器開啟一個頁面時可能同時建立十幾筆連線，因此應搭配網域篩選，而不是只查看清單頂端。

重點查看四個欄位

1. Host 或目標位址：確認記錄屬於正在測試的網站。如果只顯示 IP，DNS 解析方式或應用程式協定可能沒有提供網域名稱。
2. Rule：顯示命中的規則，例如 DomainSuffix、GeoIP、RuleSet 或最後的兜底規則。
3. Chains：顯示從策略組到最終節點的選擇鏈，例如「節點選擇 → 香港 01」。
4. Process：在系統與權限允許時顯示處理程序名稱。TUN 模式下能否辨識處理程序，取決於平台與用戶端實作。

假設存取 example.com 後，連線詳細資訊顯示規則為 DomainSuffix，策略鏈為「節點選擇 → 新加坡 03」，即可確認這筆新連線依網域規則進入指定策略組，最後使用新加坡 03。如果策略鏈顯示 DIRECT，應檢查規則順序、執行模式與設定是否已切換。

舊連線可能繼續使用舊節點

切換策略組不會強制遷移已建立的 TCP 連線。瀏覽器也可能重複使用 HTTP/2 或 HTTP/3 工作階段，因此切換節點後立即重新整理頁面，連線頁仍可能短暫顯示舊鏈路。可以關閉對應連線、新開無痕視窗，或等待舊工作階段結束後再測試。直接使用「關閉所有連線」會中斷正在進行的下載與其他網路工作，應謹慎操作。

日誌頁：從層級與關鍵字定位錯誤

日誌頁記錄核心的執行過程。正常存取時會看到連線、規則命中與出站資訊；設定或網路異常時可能出現解析失敗、連線被拒絕、逾時、TLS 握手失敗等記錄。日誌量較大時，先依層級篩選，再搜尋網域、連接埠或策略組名稱，效率高於逐行捲動。

三個常見錯誤方向

• connection refused：目標連接埠明確拒絕連線。可能是節點服務未監聽、位址寫錯，或本機要連線的控制連接埠尚未啟動。
• i/o timeout：在限定時間內未完成讀寫。需要進一步區分 DNS、TCP 建立連線、TLS 握手或遠端回應階段。
• address already in use：監聽連接埠已被其他處理程序佔用。如果混合連接埠設為 7890，應檢查是否已有另一個代理用戶端佔用 7890。

排查時可先清除目前日誌，開啟 Info 層級，然後只重現一次問題。例如清除後存取某個目標網域，等待 5 秒，再暫停捲動並搜尋該網域。這樣能避免舊記錄與背景應用程式連線干擾判斷。如果 Info 資訊不足，再暫時切換至 Debug；持續開啟 Debug 會大幅增加日誌數量。

設定頁：系統代理、TUN 與連接埠各自負責一層

設定頁決定流量如何進入核心。系統代理會修改作業系統的 HTTP、HTTPS 或 SOCKS 代理設定，適合遵循系統代理的瀏覽器與桌面應用程式。TUN 模式會建立虛擬網路介面，涵蓋範圍更廣，可接管不讀取系統代理設定的應用程式，但需要相應的系統權限，以及正確的路由與 DNS 設定。

不要混用連接埠欄位

• Mixed Port：混合代理連接埠，常見值為 7890，可接收 HTTP 與 SOCKS 連線。
• HTTP Port：僅用於 HTTP 代理。有些設定使用 7890。
• SOCKS Port：僅用於 SOCKS5 代理，傳統設定中常見 7891。
• External Controller：供圖形介面或 Dashboard 控制核心，常見位址格式為 127.0.0.1:9090。它不是瀏覽器代理連接埠。

如果用戶端採用混合連接埠 7890，終端機程式的 HTTP 代理通常應指向 http://127.0.0.1:7890，而不是控制連接埠 9090。具體值應以目前設定與設定頁為準。修改連接埠後，系統代理位址、瀏覽器手動代理與終端機環境變數也要同步更新。

系統代理與 TUN 的選擇

第一次使用時，建議先啟用系統代理以驗證基本鏈路。此時瀏覽器產生流量、代理頁節點可用、連線頁能看到規則命中，表示設定與出口基本正常。如果某個應用程式不遵循系統代理，再考慮開啟 TUN。這樣可以分開處理「節點不可用」與「TUN 路由異常」。

部分桌面用戶端需要先安裝服務模式，才能以較穩定的權限啟用 TUN。常見路徑是「設定」→「服務模式」→「安裝」，再返回「設定」→「TUN 模式」開啟。實際路徑取決於用戶端版本。開啟後應檢查是否出現新的虛擬網卡、DNS 是否可解析，以及區域網路與本機開發服務是否仍能按預期存取。

10 分鐘完成一次介面核對

首次匯入設定後，可以依固定順序完成檢查。這個順序從設定來源開始，經過節點選擇與流量入口，最後用連線與日誌驗證結果，能減少在多個頁面之間反覆切換。

1. 第 1 分鐘：開啟設定頁，確認訂閱或本機檔案存在，並標記為目前設定。
2. 第 2 分鐘：執行一次更新，確認更新時間變更，且沒有設定解析提示。
3. 第 3 至 4 分鐘：進入代理頁，對主要策略組執行延遲測試，選擇連續兩次回應穩定的節點。
4. 第 5 分鐘：進入設定頁，確認核心正在執行，且混合連接埠與系統代理位址一致。
5. 第 6 分鐘：開啟系統代理，新開瀏覽器視窗存取測試頁面。
6. 第 7 至 8 分鐘：進入連線頁，依目標網域篩選，查看命中規則與最終節點。
7. 第 9 分鐘：返回總覽頁，確認連線數以及上行、下行流量有所變化。
8. 第 10 分鐘：進入日誌頁篩選 Warning 與 Error，確認沒有持續出現的連接埠、DNS 或逾時錯誤。

發生問題時依現象返回對應頁面

了解介面後，排查思路可以濃縮成一條鏈：設定頁確認「載入了什麼」，代理頁確認「選擇了什麼」，設定頁確認「流量如何進入」，連線頁確認「實際經過什麼」，日誌頁解釋「為什麼成功或失敗」。這五個問題對應五個頁面，也涵蓋大多數首次連線故障。