Clash 新手常見問題：訂閱、模式與連線狀態十問

開始前：先分清四種狀態

Clash 用戶端通常由圖形介面、Clash 或 mihomo 核心、設定檔與系統網路設定四個部分共同運作。視窗能夠開啟，只代表圖形介面已啟動；成功匯入設定，也不代表流量已經進入代理。判斷是否完成初始化，應依序確認設定、節點、代理入口與實際請求。

1. 設定狀態：目前設定檔可由核心載入，介面沒有顯示 YAML 解析錯誤或欄位不相容。
2. 策略狀態：代理策略群組已有可用節點，需要手動選擇的策略群組也不是空值。
3. 接管狀態：系統代理或 TUN 模式至少啟用一種，應用程式流量能夠進入 Clash 監聽連接埠。
4. 連線狀態：連線清單出現新記錄，日誌顯示規則比對結果，目標請求取得正常回應。

如果只盯著「已啟動」或系統匣圖示，很容易把設定問題、節點問題與系統代理問題混在一起。以下十個問題依照實際操作順序展開，遇到故障時也可以直接跳到對應章節。

訂閱與設定：匯入不等於連線

問題一：匯入訂閱網址後，為什麼沒有節點？

訂閱網址本質上是遠端設定入口。用戶端需要連線到該網址、下載回應內容，再將內容解析成代理節點、策略群組與規則。匯入完成但清單為空，常見原因包括網址複製不完整、訂閱已失效、目前網路無法連線至訂閱伺服器、伺服器回傳網頁而非設定檔，以及用戶端不支援回傳內容所使用的格式。

先在設定或訂閱管理頁面執行一次手動更新，查看更新時間與錯誤提示。如果提示逾時，應檢查目前網路與訂閱伺服器之間的連線；如果提示解析失敗，應確認匯入的是訂閱網址，而不是登入頁、控制台網址或 QR Code 圖片連結。部分服務會分別提供通用訂閱、Clash 設定與單節點連結，桌面版 Clash 用戶端通常應選擇明確標示為 Clash 或相容 Clash 的設定入口。

還要區分「節點為空」與「尚未選擇策略群組」。節點可能已存在於設定中，但首頁只顯示策略群組。進入代理或 Proxies 頁面，展開具體策略群組後再查看成員。如果策略群組由規則提供方動態產生，也應等待設定下載與解析完成後再操作。

問題二：更新訂閱會覆蓋手動修改嗎？

通常會。遠端訂閱更新等同重新下載一份設定，直接修改由訂閱產生的節點名稱、規則或 DNS 欄位，下次更新時可能會被遠端內容取代。不同用戶端對覆寫、合併設定、指令碼處理與設定修補的實作不同，但基本原則一致：遠端設定負責可更新內容，本地自訂內容應放在用戶端提供的覆寫層中。

新手不建議一開始就大幅編輯 YAML。先保留原始設定並確認基本連線可用，再依照用戶端功能加入本地規則。編輯後若出現啟動失敗，優先檢查縮排、冒號後的空格、清單符號與欄位層級。YAML 使用空格表示層級，定位字元、全形標點與錯誤縮排都可能導致整個檔案無法載入。

節點與延遲：測試數值不等於實際速度

問題三：延遲最低的節點一定最快嗎？

不一定。延遲測試主要反映用戶端與測試目標完成一次連線或請求所需的時間，適合判斷節點是否在線上以及互動回應是否敏捷。下載速度還會受到節點出口頻寬、線路壅塞、跨網路由、目標網站限速、協定負擔與本地網路品質影響。一個延遲只有幾十毫秒但壅塞的節點，實際傳輸量可能低於延遲稍高但線路穩定的節點。

選擇節點時可分三步：先排除逾時節點，再從低延遲節點中進行實際網頁或檔案請求，最後觀察一段時間內是否頻繁斷線。遊戲、遠端終端機與即時通話更重視延遲與抖動；影片與大型檔案下載更重視持續傳輸量；一般網頁則需要兼顧 DNS、握手速度與穩定性。

用戶端中的 URL Test 策略群組可以依固定網址定期測試，並選擇表現較好的節點，但測試結果只代表該測試目標與測試當下的情況。Fallback 策略較偏向故障切換，負載平衡策略則可能依設定將不同連線分配至多個節點。具體行為取決於設定中的策略群組類型，不應把所有「自動選擇」都理解成單純挑選最低延遲。

問題四：節點顯示可用，網頁為什麼仍然無法開啟？

節點測試成功只代表某個測試請求能夠透過該節點，不代表瀏覽器請求一定經過相同路徑。首先查看連線清單中是否出現瀏覽器發出的網域。如果完全沒有記錄，問題通常位於系統代理、瀏覽器獨立代理設定或 TUN 接管層；如果有記錄，則繼續查看命中的規則、最終策略與錯誤資訊。

也可能出現測試網址可以存取，但目標網站無法存取的情況。目標網域可能被規則分配至 DIRECT，策略群組可能選中了另一個節點，DNS 解析結果也可能與連線路徑不一致。切換至全域模式可作為短時間的定位手段：若全域模式可用而規則模式不可用，應檢查規則比對與策略群組；若兩種模式都不可用，則優先檢查節點、DNS、系統時間與本地網路。

規則模式與系統代理：確認流量從哪裡進入

問題五：Rule、Global 與 Direct 三種模式有什麼差別？

Rule（規則）模式會依設定中的規則逐項判斷請求，例如依網域、IP、程序或規則集合決定直連、拒絕，或交由某個策略群組處理。這是日常使用最常見的模式，前提是設定中的規則與策略群組完整且可用。

Global（全域）模式通常會將進入 Clash 的請求統一交給全域策略群組，適合暫時確認節點是否正常運作。這不代表裝置上的每一筆流量都會自動進入 Clash；流量仍需先經過系統代理、應用程式代理或 TUN 介面。

Direct（直連）模式會讓已進入 Clash 的請求直接連線至目標，不經過代理節點。它適合測試代理節點是否造成異常，也可用於暫時保留 Clash 接管狀態，同時停止節點轉發。Direct 不等於完全退出用戶端，因為 DNS、監聽連接埠與連線記錄仍可能由核心處理。

排查時可使用簡單對照：規則模式失敗而全域模式成功，重點檢查規則；全域模式也失敗，重點檢查節點與接管入口；Direct 模式失敗，則本地網路、DNS 或目標服務本身也可能有問題。測試結束後應恢復原本的規則模式，避免長期改變預期的流量分流結果。

問題六：開啟系統代理後，為什麼有些應用程式仍然直連？

系統代理是作業系統提供給應用程式的一組代理設定。瀏覽器與許多桌面程式會讀取這些設定，將 HTTP 或 HTTPS 請求傳送至 Clash 的混合連接埠或對應代理連接埠。但並非所有應用程式都遵循系統代理：部分遊戲、命令列工具、虛擬機器、容器程式與自行實作網路堆疊的軟體會直接建立連線。

先確認開啟系統代理後，作業系統中的代理位址指向本機監聽位址，連接埠也與用戶端目前使用的連接埠一致。連接埠遭其他程式占用、核心未執行，或用戶端切換設定後監聽失敗，都會造成系統代理已存在，但連線無法進入。若瀏覽器曾安裝獨立代理擴充功能，也可能覆蓋系統設定，應暫時停用擴充功能後再測試。

需要涵蓋更多 TCP、UDP，或不讀取系統代理的應用程式時，可以考慮 TUN 模式。TUN 會建立虛擬網路介面，由系統路由將更多流量送入核心處理，通常需要管理員權限。它的涵蓋範圍更廣，但也更容易與其他 VPN、虛擬網卡、安全軟體及自訂路由發生衝突。新手應先讓系統代理模式正常運作，再依實際需求啟用 TUN，而不是同時變更多項網路設定。

連線失敗：依入口、規則、節點、目標分層檢查

問題七：日誌中的 timeout、connection refused 與 DNS error 分別代表什麼？

timeout 表示某個網路階段未能在限定時間內完成，可能發生在存取訂閱、連線至節點、建立目標連線或等待回應時。它通常指向線路不通、封包遺失嚴重、目標回應緩慢或遭防火牆攔截，但僅憑一個 timeout 無法直接確定故障位置。應結合日誌中的目標位址、策略名稱與連線鏈路進行判斷。

connection refused 表示目標位址明確拒絕了連線。若拒絕發生在本機連接埠，可能是 Clash 核心沒有監聽對應連接埠；若發生在代理伺服器，則節點服務可能已停止或連接埠設定不相符；若發生在最終目標，則目標服務可能未開放該連接埠。

DNS 相關錯誤表示網域解析階段未取得有效結果，常見情況包括解析伺服器無法連線、增強模式設定不相容、網路攔截 DNS 請求，或網域本身不存在。遇到這類錯誤，不要只是不斷切換節點。先確認一般網路能否解析網域，再檢查設定中的 DNS 開關、監聽設定、nameserver 與 fallback 等欄位。修改 DNS 後應重新載入設定並重新發起連線，既有連線不會自動採用新結果。

問題八：系統代理已經開啟，為什麼連線清單仍然是空的？

連線清單為空，代表目前觀察到的請求沒有進入 Clash。先重新整理一個從未開啟過的網頁，避免瀏覽器直接使用快取。接著檢查用戶端核心是否正在執行、系統代理是否指向正確連接埠，以及作業系統設定中是否殘留舊用戶端的代理位址。

如果瀏覽器使用隱私代理、擴充功能代理或企業管理政策，可能會繞過系統代理。命令列工具也常有獨立的環境變數，例如 HTTP 代理與 HTTPS 代理變數；這些設定可能指向另一個連接埠。使用 TUN 模式時連線清單為空，則應查看虛擬網卡是否建立成功、路由是否生效，以及是否已授予管理員權限。

也應排除區域網路裝置測試方式錯誤。Clash 預設監聽本機位址時，其他裝置無法直接連線。只有在用戶端允許區域網路存取、監聽位址涵蓋區域網路介面，且作業系統防火牆允許對應連接埠後，手機或其他電腦才能將該裝置作為代理伺服器。開放區域網路監聽前，應確認所在網路可信，並限制可存取的範圍。

更新與維護：避免設定狀態逐步失真

問題九：更新用戶端後設定無法載入，該怎麼辦？

圖形用戶端、核心與設定規範並不是同一個版本概念。更新用戶端可能同時更換核心，也可能繼續使用原本的核心；而訂閱設定可能包含只有特定核心支援的欄位。更新後若無法載入，先記錄完整錯誤行，不要連續修改多個欄位。

如果錯誤指向未知欄位或策略類型，應確認目前用戶端使用的是 Clash、Clash Meta 或 mihomo 核心，以及設定是否針對該核心產生。mihomo 延續並擴充了 Clash Meta 的能力，但舊版用戶端內建的核心未必支援較新的設定項目。若錯誤指向 YAML 行號，則檢查該行附近的縮排、引號與清單結構，因為真正的結構錯誤可能出現在提示行之前。

建議維持固定的處理順序：備份目前檔案，切換至一份已知可用的基本設定，確認核心能夠啟動，再重新更新訂閱。若基本設定可用而訂閱設定失敗，問題集中在訂閱內容或相容性；若所有設定都失敗，則檢查用戶端權限、核心檔案、監聽連接埠與升級過程。這樣可以避免把設定錯誤誤判為安裝錯誤。

問題十：如何判斷 Clash 已經正常運作？

不要只用單一網頁作為結論。完整驗證應涵蓋本機狀態、代理路徑與流量分流結果三個層面。首先確認核心正在執行、設定沒有錯誤、策略群組已選定節點；其次確認系統代理或 TUN 已啟用，開啟網頁時連線清單出現新記錄；最後查看不同請求是否符合預期規則，例如本地服務走 DIRECT，需要代理的目標進入指定策略群組。

可以依照以下檢查表逐項確認：

• 設定頁面顯示最近更新時間，手動更新沒有回傳下載或解析錯誤。
• 代理頁面至少有一個可用節點，目前策略群組不是空值，也不是失效節點。
• 規則模式已啟用，日誌能夠顯示網域、規則與最終策略。
• 開啟新網頁時連線計數有所變化，上傳與下載流量不再持續為零。
• 關閉系統代理後請求路徑出現預期變化，重新開啟後能夠恢復。
• 重新啟動用戶端後設定仍可自動載入，系統代理狀態符合用戶端設定。

如果以上項目都正常，表示安裝、設定、節點與流量入口已形成完整鏈路。之後再處理延遲、規則細化、DNS 最佳化或 TUN 相容性問題，會比反覆重新安裝用戶端更有效。