Clash 首次連線步驟：選擇節點、測試延遲與確認代理狀態

Clash 客戶端首次啟動後，介面正常顯示並不代表代理鏈路已經可用。一次完整連線至少涉及設定載入、策略組選擇、節點連通、運作模式、系統流量入口和目標存取驗證六個環節。任何一環未生效，都可能表現為「節點有延遲但網頁打不開」、「客戶端顯示執行中但出口位址沒有變化」或「部分應用程式可以連線、瀏覽器卻無法連線」。

最穩妥的操作方式是沿著資料路徑逐段確認，而不是連續切換多個開關。先確保設定可被客戶端解析，再選擇可用節點，接著啟用正確的流量入口，最後透過日誌與實際存取結果交叉驗證。以下步驟適用於常見的桌面版 Clash 客戶端，也適用於使用 Clash Meta（mihomo）核心的圖形化客戶端；具體按鈕名稱可能不同，但檢查邏輯一致。

PROFILE INPUT

第一步：匯入訂閱並確認設定已載入

訂閱位址不是節點本身，而是客戶端取得設定內容的入口。伺服器回應通常包含代理節點、策略組、規則、DNS 設定以及遠端規則集參照。匯入成功的判斷標準不只是清單中出現一筆訂閱記錄，還要確認該記錄已設為目前設定，而且客戶端沒有回報 YAML 語法、欄位型別或遠端資源下載錯誤。

匯入訂閱的標準順序

1. 複製完整訂閱位址，確認開頭為 https://，同時避免連同位址前後的空格一起複製。
2. 在 Profiles、設定或訂閱頁面選擇「從 URL 匯入」，貼上位址並執行下載。
3. 等待設定記錄顯示名稱、更新時間或設定大小，再點選該記錄將其設為目前設定。
4. 開啟日誌頁面，確認沒有持續出現解析失敗、欄位無效、資源下載失敗或設定載入失敗。
5. 回到代理頁面，檢查是否出現策略組和節點。若設定名稱空白、完全沒有策略組，就不能繼續進行節點測試。

部分客戶端會同時儲存多個設定，但執行時只會啟用其中一個。匯入新訂閱後仍看到舊節點，通常是目前設定尚未切換，或新設定匯入後尚未重新載入。可以先記下目前設定名稱，再執行一次切換；首次驗證階段不要同時啟用多個覆寫指令碼，因為覆寫結果可能改變代理組、DNS 或連接埠欄位。

如何區分訂閱問題與客戶端問題

NODE SELECTION

第二步：選擇節點並正確理解延遲測試

設定載入後，進入 Proxies 或代理頁面。頁面通常依策略組組織節點，例如「節點選擇」、「自動選擇」、「故障轉移」或按地區劃分的群組。規則最終引用的是策略組，因此只在某個地區群組中點選節點，卻沒有讓上層策略組引用該群組，實際流量仍可能經由其他出口。

先查看策略組的引用關係

首次測試建議找到規則主要使用的手動選擇組，再直接選取一個具體節點。若主要選擇組目前指向「自動選擇」，則由自動測速組決定實際節點；若指向某個地區組，還需要進入該地區組確認第二層選擇。可以將關係理解為：

規則命中 → 主要策略組 → 地區組或自動組 → 具體代理節點

當客戶端提供鏈路詳細資訊時，應確認最末端顯示的是具體節點名稱，而不是停留在未選取的策略組。修改選擇後通常會立即生效，新建立的連線會使用新節點，已建立的長連線可能繼續使用舊鏈路。驗證時可關閉目標網頁分頁後重新開啟，必要時終止舊連線。

延遲數值代表什麼

客戶端的延遲測試通常會透過指定的測試 URL 發起 HTTP 或 HTTPS 請求，並記錄建立連線或取得回應所需的時間。它可以快速判斷節點是否具備基本連通性，但不等同於 ICMP Ping，也不代表所有目標網站的存取速度。測試伺服器位置、TLS 交握、節點壅塞、本地網路抖動與測試逾時時間都會影響結果。

• 顯示具體毫秒數：表示測試請求在限定時間內完成，節點具備基本可達性。
• 顯示逾時：可能是節點無法連線、測試位址遭封鎖、通訊協定參數失效，或本地網路無法建立連線。
• 數值偶爾很高：先連續測試兩到三次，觀察是否持續異常，不要只憑一次結果下判斷。
• 延遲低但網頁載入失敗：繼續檢查規則、DNS、系統代理與目標網站鏈路，不能把延遲測試成功視為完整驗證。

選擇節點不必一味追求最低數字。首次進行連通測試時，優先選擇多次測試都有回應、波動較小的節點。若所有節點同時逾時，更可能是訂閱參數失效、本地網路入口受限、客戶端核心未執行或測試位址無法使用，而不是每個節點同時各自故障。

ROUTING MODE

第三步：確認 Rule、Global 與 Direct 模式

Clash 的運作模式決定連線如何選擇策略。常見模式包括 Rule、Global 和 Direct。首次使用建議維持 Rule 模式，因為它會按照設定中的規則由上而下比對，通常能實現本地位址直連、指定目標使用代理，以及由末尾規則兜底。實際行為取決於目前設定，並非所有 Rule 設定都會採用相同的分流結果。

如果 Rule 模式下某個目標無法存取，而切換至 Global 後恢復，問題通常位於規則命中結果、策略組選擇或 DNS 分流，而不是系統代理入口。此時應開啟連線記錄，查看該目標命中了哪條規則、交由哪個策略組處理，以及最終使用哪個節點。測試結束後切回 Rule，避免將臨時診斷狀態誤當成長期設定。

Direct 模式同樣具有診斷價值：若 Direct 下連常用的本地網站也無法開啟，應先檢查系統代理連接埠、核心執行狀態或防火牆；若 Direct 正常而代理模式失敗，則檢查節點與代理協定參數。切換模式只是改變流量進入 Clash 後的處理方式，無法取代系統代理或 TUN 這類流量接管入口。

TRAFFIC ENTRY

第四步：啟用系統代理，讓應用程式流量進入 Clash

節點測試是由客戶端核心主動發起，即使未開啟系統代理，也可能取得延遲數值。瀏覽器和桌面應用程式要使用 Clash，流量還必須進入本地監聽連接埠。桌面客戶端通常提供「系統代理」開關，用於將作業系統的 HTTP 與 HTTPS 代理指向 Clash 的本地連接埠。

系統代理生效所需條件

1. Clash 核心處於執行狀態，沒有發生連接埠被占用或啟動失敗。
2. 系統代理開關已開啟，作業系統代理位址通常指向本機迴路位址。
3. 瀏覽器或應用程式遵循系統代理設定，沒有使用獨立代理設定覆蓋系統值。
4. 本地防火牆允許客戶端程序監聽並存取相應連接埠。
5. 連接埠設定與系統代理寫入的連接埠一致，修改連接埠後已重新套用系統代理。

常見設定會提供 HTTP 連接埠、SOCKS 連接埠或 mixed-port。mixed-port 可以在同一個連接埠接受 HTTP 與 SOCKS 連線，但是否啟用取決於設定與客戶端實作。不要根據其他裝置的截圖直接填寫連接埠，應以目前客戶端的連接埠頁面與執行日誌為準。

如果瀏覽器安裝了獨立的代理管理擴充功能，可能會繞過或覆蓋系統代理。首次檢查時應只保留一種入口：要麼讓瀏覽器跟隨系統設定，要麼明確將瀏覽器指向 Clash 的本地監聽連接埠。同時修改兩種設定會讓故障來源難以判斷。部分應用程式完全忽略系統代理，這類流量需要在應用程式內單獨設定 SOCKS/HTTP 代理，或在確認基本連線正常後使用 TUN 模式。

VERIFY OUTPUT

第五步：用存取結果、連線記錄與日誌完成驗證

驗證代理狀態不能只看開關顏色。可信的結論至少需要三個訊號：目標頁面能夠載入、Clash 連線記錄出現對應請求，以及該請求使用了預期的策略與節點。若還需要確認公開網路出口，可以在啟用與停用代理時分別存取可信的 IP 查詢服務，比較出口位址是否變化。

建議的驗證順序

1. 維持 Rule 模式，確認主要策略組已選取剛才測試通過的節點。
2. 開啟系統代理，關閉瀏覽器中原有的目標頁面與舊連線。
3. 存取一個本地常用網站，確認基本網路沒有因系統代理設定而整體中斷。
4. 存取需要使用代理的目標，同時觀察 Connections 或連線頁面是否出現網域名稱。
5. 展開連線詳細資訊，核對規則名稱、策略組、最終節點、上傳下載資料與連線狀態。
6. 查看日誌中是否存在 DNS 解析失敗、連線遭拒、交握逾時或路由失敗。

連線記錄是判斷流量是否進入 Clash 的直接證據。瀏覽器正在存取目標，但連線清單完全沒有對應的網域名稱或 IP，表示問題多半發生在 Clash 之前：系統代理未寫入、瀏覽器繞過代理、應用程式使用自己的網路堆疊，或核心監聽連接埠與系統設定不一致。若存在連線記錄卻停留在逾時狀態，則繼續檢查節點、DNS、規則與遠端鏈路。

出口位址沒有變化時如何判斷

先確認測試目標確實命中了代理策略。Rule 模式可能將某些 IP 查詢網站設為直連，因此出口不變不一定代表系統代理失效。可以從連線詳細資訊確認比對結果，或暫時切換至 Global 模式進行對照。若 Global 模式下出口發生變化，表示代理鏈路運作正常，需要調整的是規則或策略組；若 Global 下仍沒有對應連線記錄，則回到流量入口檢查。

還要注意瀏覽器快取、連線重用與 QUIC。已建立的連線可能不會在切換節點後立即重建，某些瀏覽器的 UDP/QUIC 流量也可能與一般 HTTP 代理的表現不同。最簡單的處理方式是關閉相關分頁，等待舊連線結束後重新存取。不要一邊測速、一邊連續切換多個節點與模式，否則日誌很難對應到具體操作。

FAULT ISOLATION

首次連線失敗的分層排查表

首次連線失敗時，依照「設定—核心—節點—入口—規則—DNS」的順序逐層檢查。每次只變更一項設定，並在修改後重新發起連線。如此才能確認是哪一層恢復，而不是偶然得到一組暫時可用的組合。

如何確認是否為 DNS 問題

Clash Meta（mihomo）設定可能使用 fake-ip 或 redir-host 等 DNS 增強模式。它們的解析路徑與快取行為不同，但首次排查的核心相同：確認網域查詢進入預期的 DNS 模組、上游伺服器可以連線，以及規則判斷所需的網域資訊沒有遺失。尚未確認系統代理可用前，不要同時替換多個 DNS 上游。

若日誌明確顯示網域解析逾時，可以先測試其他網域，判斷是單一網域異常還是所有查詢都失敗。若只有特定網域失敗，檢查規則、hosts 覆寫與 fake-IP 過濾項；若所有網域都失敗，檢查 DNS 監聽連接埠、上游協定、網路可達性以及 TUN 下的 DNS 劫持設定。更新設定後還應清除客戶端 DNS 快取或重新啟動核心，避免舊記錄影響判斷。

何時再啟用 TUN 模式

當系統代理下的瀏覽器存取、策略命中與節點出口都已確認正常，但遊戲、命令列程式或不遵循系統代理的應用程式仍無法被接管時，再考慮 TUN。啟用前應記錄目前可用的設定與連接埠，以便快速回復。TUN 通常涉及虛擬網卡、路由表、DNS 接管、管理員權限及嚴格路由設定，故障範圍比系統代理更廣。

啟用 TUN 後，先檢查虛擬介面是否建立、預設路由是否依客戶端預期調整，再查看應用程式連線是否出現在 Clash 連線記錄中。如果開啟後整台裝置的網路中斷，應立即停用 TUN 並恢復基本鏈路，不要同時修改 MTU、DNS、路由與防火牆。基本代理已可用時，TUN 問題通常可以獨立定位。

FINAL CHECKLIST

首次連線完成檢查清單

以下項目全部符合，才能視為首次連線主線完成。後續再依裝置用途調整自動選擇、故障轉移、規則集、DNS 與 TUN，不必在第一輪設定中一次完成所有進階功能。

• 訂閱已成功更新，並已設為目前執行中的設定。
• 代理頁面可以看到策略組與具體節點。
• 至少一個節點經過多次測試，都能回傳穩定結果。
• 主要策略組最終指向該節點，而不是未設定的第二層群組。
• 執行模式為 Rule，臨時診斷模式已恢復。
• Clash 核心正常執行，本地監聽連接埠沒有衝突。
• 系統代理已啟用，瀏覽器流量出現在連線記錄中。
• 連線詳細資訊顯示預期的規則、策略組與最終節點。
• 目標頁面能夠重新建立連線並正常載入。
• 日誌中沒有持續出現解析、DNS 或交握錯誤。

完成以上檢查後，可以儲存目前的設定狀態，並記錄客戶端版本、核心類型、設定名稱與可用節點。日後出現連線異常時，先回到這組基準重新驗證：設定能否載入、節點是否可達、流量是否進入核心、規則是否選取正確出口。相較於反覆重新安裝客戶端，這種沿鏈路檢查的方法更容易定位實際故障點。