Clash 第一次啟動後，介面能夠開啟並不代表代理已經接管網路。一次完整連線至少包含四個獨立環節：設定成功載入、代理群組已選定節點、作業系統或應用程式將流量交給 Clash，以及目標連線依照規則通過指定出口。任何一個環節未完成，都可能出現「節點看似可用，但網頁仍直接連線」或「系統代理已開啟，但所有請求逾時」的情況。

不同用戶端的選單名稱可能略有差異。基於 Clash Meta（mihomo）核心的用戶端通常會將設定、代理、連線、日誌、系統代理與 TUN 分成獨立頁面；舊版 Clash 用戶端也遵循相近邏輯。首次使用時應依照資料流順序操作，不要同時修改 DNS、規則模式、連接埠與 TUN 參數。先建立一條可驗證的基礎連線，再處理特定應用程式的相容性問題。

一、連線前確認用戶端狀態

啟動用戶端後，先檢查核心是否正常執行。介面中常見的狀態包括 Running、Started、Core Running 或「服務執行中」。如果頁面能夠顯示，但核心狀態為 Stopped、Error 或反覆重新啟動，後續訂閱匯入與節點測試可能無法得到有效結果。此時應先開啟日誌，確認是否存在設定解析失敗、監聽連接埠被佔用或權限不足。

還要確認系統日期、時間與時區正確。HTTPS 連線依賴憑證有效期限判斷，裝置時間偏差過大時，訂閱更新與節點交握都可能失敗。網路本身也必須能夠連線至訂閱服務：先暫時關閉系統代理，再用瀏覽器確認一般網站可以開啟。如果基礎網路未連通，Clash 無法取代本地 Wi-Fi、網路線或行動網路建立底層連線。

檢查項目 正常表現 異常時優先處理
核心狀態 持續執行，沒有反覆退出 查看啟動日誌與設定錯誤
本地網路 關閉代理後可存取一般網站 檢查閘道、驗證頁面與 DNS
系統時間 日期、時間與時區準確 啟用系統時間同步
監聽連接埠 HTTP、SOCKS 或 mixed 連接埠成功監聽 結束佔用連接埠的舊程序

二、匯入並啟用訂閱設定

Clash 使用 YAML 設定描述代理節點、代理群組、規則、DNS 與執行參數。訂閱連結通常是設定服務提供的更新網址，用戶端需要先請求該網址，再將回傳內容儲存為本地設定。複製連結時應保留完整查詢參數，不要手動刪除問號後的 token、裝置參數或編碼內容，也不要將訂閱管理網頁的網址誤當成訂閱網址。

  1. 進入「設定」、「Profiles」或「訂閱」頁面。
  2. 選擇從 URL 匯入，將完整訂閱網址貼到輸入框。
  3. 執行下載或匯入，等待用戶端顯示更新完成。
  4. 在設定清單中選取剛匯入的項目，使其成為目前使用中的設定。
  5. 返回代理頁面，確認可以看到代理群組及群組內的節點。

「下載成功」與「設定已啟用」是兩種不同狀態。有些用戶端更新訂閱後只會將檔案加入清單，不會自動切換目前設定。若代理頁面仍顯示舊節點，應回到設定頁檢查選取標記、啟用狀態或最近更新時間。設定啟用後，如果用戶端提示 YAML 解析錯誤，應記下具體行號與欄位；不要反覆點擊更新，因為同一份錯誤內容不會因重複下載而自動修正。

訂閱回傳空內容、HTML 頁面或不受支援的格式時，用戶端可能提示 invalid config、unexpected token、proxy group not found 或缺少 proxies 欄位。這類問題發生在設定載入階段，與節點速度無關。可以在瀏覽器中開啟訂閱網址確認服務回應，但含有存取憑證的訂閱 URL 不應發布到聊天群組、截圖或公開日誌中。

三、選擇代理群組與節點

設定正常載入後，進入「代理」、「Proxies」頁面。這裡通常不是單純的節點清單，而是多個代理群組。常見群組類型包括手動選擇的 select、自動測速的 url-test、故障切換的 fallback，以及負載分配的 load-balance。規則引用的是代理群組名稱，再由代理群組決定目前使用哪個節點。因此，只在某個無關的分組中點選節點，不一定會改變實際出口。

先找到負責主要流量的群組。它可能叫做「節點選擇」、「代理」、「PROXY」，也可能由設定提供者自訂。進入該群組後，選擇一個地區明確且可進行測試的節點。如果主群組中選取的是另一個代理群組，還需要繼續進入下一層查看最終節點。鏈式分組是有效的設定方式，但首次排查時必須知道最後套用的是哪個代理項目。

模式選擇也會影響結果：

  • 規則模式（Rule）：依規則由上到下進行比對。不同網域可能分別採用代理、直連或拒絕策略，適合作為日常預設模式。
  • 全域模式（Global）：大多數被接管的連線會統一交給全域群組，適合暫時確認節點出口，但不代表所有系統流量都必然會被接管。
  • 直連模式（Direct）：由 Clash 接收的流量會直接連線至目標，不經過代理節點，不能用來驗證遠端代理出口。

首次驗證可以先使用規則模式。如果無法判斷某個測試網站套用了哪條規則，可短暫切換到全域模式比較結果。測試完成後再恢復規則模式。模式決定 Clash 收到連線後的處理方式，系統代理或 TUN 則決定連線是否會抵達 Clash；這兩個開關不能互相取代。

四、正確理解延遲測試

節點旁的「測速」通常會執行 HTTP 探測：核心透過該節點存取設定指定的測試 URL，並記錄建立連線及取得回應所需的時間。顯示 80 ms、200 ms 或 Timeout，只能代表該次探測結果。它不等同於下載頻寬，也無法完整反映影片穩定度、尖峰時段壅塞、封包遺失率或目標網站對出口位址的限制。

測試時可以先對一個代理群組執行完整延遲測試，再從同一地區的可用節點中選擇數值較低且連續結果穩定的項目。不要只根據一次最低數字做決定。連續測試中，一個節點在 90 ms、95 ms、100 ms 附近波動，通常比在 40 ms 與 700 ms 之間劇烈變化的節點更容易維持互動穩定。跨地區節點的實體距離更遠，基礎延遲增加屬於正常現象。

Timeout 表示在測試期限內沒有取得預期回應，可能由節點離線、線路受阻、測試網址無法連線、TLS 交握失敗或本地網路波動引起。若所有節點同時逾時，應先懷疑本地網路、訂閱設定、核心狀態或測試 URL，而不是逐一判定節點故障。若只有單一節點持續逾時，切換同組其他節點會更有效。

五、啟用系統代理或 TUN

選定節點後，需要讓應用程式流量進入 Clash。最常見的方法是開啟「系統代理」。用戶端會將作業系統的 HTTP 與 HTTPS 代理指向本機監聽位址，常見形式為 127.0.0.1 加上一個本地連接埠。遵循系統代理設定的瀏覽器與桌面應用程式會將請求傳送給 Clash，再由規則決定直連或代理。

系統代理並不涵蓋所有程式。有些遊戲、命令列工具、背景服務或自行實作網路堆疊的應用程式會忽略作業系統代理；UDP 流量也不一定會透過一般 HTTP 代理。遇到這類需求時，可以考慮 TUN 模式。TUN 會建立虛擬網路介面，由核心接收更廣泛的 IP 流量，通常需要系統管理員權限，並可能受到防火牆、防毒軟體、其他 VPN 或虛擬網卡影響。

第一次連線建議先測試系統代理，因為鏈路較簡單、故障點較少。確認瀏覽器代理成功後，再依需求開啟 TUN。不要同時執行多個會改寫系統代理或路由表的用戶端，否則一個程式可能覆蓋另一個程式的設定。切換用戶端前，應先關閉原用戶端的系統代理與 TUN，再結束其背景程序。

使用系統代理時，也可以檢查作業系統代理位址是否與用戶端目前連接埠一致。設定中的 mixed-port、port 與 socks-port 用途不同；手動填寫時不能將 SOCKS 連接埠當作 HTTP 連接埠使用。由用戶端自動管理系統代理通常更穩妥，連接埠變更時也能同步更新。

六、確認代理是否實際生效

驗證不能只看開關顏色。應同時檢查出口結果、連線紀錄與規則命中情況。先讓已知節點保持選取狀態，開啟系統代理，然後使用新開的瀏覽器隱私視窗，存取能顯示公開出口資訊的服務。記錄目前的出口地區或位址，再關閉系統代理並重新整理比較。如果兩次結果如預期變化，表示瀏覽器流量已進入代理鏈路。

接著開啟用戶端的「連線」、「Connections」頁面，再造訪一個新網站。正常情況下會出現新的網域、目標位址、連線類型、上傳下載量、命中規則與代理鏈。代理鏈可能顯示「目標策略群組 → 選定節點」，也可能顯示 DIRECT。看到 DIRECT 不一定是錯誤：在規則模式下，本地網路、特定地區網站或設定指定的網域原本就可能直連。

日誌可以補充判斷，但應依時間順序閱讀。一次瀏覽器請求通常會經過 DNS 查詢、規則比對、建立 TCP 或 UDP 連線、連線至節點、存取目標等階段。日誌出現 match、proxy、DIRECT 或具體群組名稱時，重點是確認它是否對應剛才造訪的網域。舊日誌中的 timeout 不能證明目前請求仍然失敗，排查前可以清除日誌或記住測試開始時間。

還應分別測試網域與直接 IP 連線。網頁無法開啟，但連線紀錄中沒有任何新項目，表示流量可能未進入 Clash；有連線項目但顯示 DNS 失敗，應檢查 DNS 模組、網路可達性與模式設定；連線命中正確節點後仍逾時，則更接近節點線路或目標服務問題。依階段定位比連續切換十幾個節點更快。

可重複的驗證流程

  1. 選擇一個延遲測試能夠回應的節點。
  2. 確認目前模式為規則或全域，而不是直連。
  3. 開啟系統代理，暫時保持 TUN 關閉。
  4. 清除或標記連線紀錄與日誌的目前時間。
  5. 使用瀏覽器新視窗造訪出口檢測頁面與一般 HTTPS 網站。
  6. 核對連線紀錄中的網域、規則、策略群組與最終節點。
  7. 關閉系統代理再次測試，確認出口與連線紀錄出現變化。

七、辨識狀態提示與常見故障

Connected 或 Running：通常只表示核心、服務或某條連線處於執行狀態，不保證目標網站可以存取，也不保證目前出口經過代理。仍需結合連線紀錄進行驗證。

Timeout：表示在限定時間內未完成探測或連線。先判斷是所有節點還是單一節點，再區分 DNS、節點交握與目標回應階段。所有節點同時逾時時，通常需要檢查本地網路與核心。

Connection refused：目標位址主動拒絕連線。若被拒絕的是 127.0.0.1 上的本地連接埠，常見原因是核心未監聽或系統代理連接埠填寫錯誤；若發生在遠端節點，則可能是節點服務未在對應連接埠運作。

DNS lookup failed：網域解析未取得可用結果。檢查裝置上是否存在其他 DNS 工具、TUN DNS 劫持是否正常，以及設定中的 nameserver 是否可達。基礎連線尚未確認前，不要同時疊加多個加密 DNS 與自訂 hosts 規則。

TLS handshake failed：可能涉及裝置時間、憑證驗證、SNI、線路中斷或遠端服務狀態。先校準時間，再更換同組節點比較。如果所有節點僅對單一目標失敗，也要考慮目標服務限制，而不是直接修改整份設定。

網頁可以開啟但應用程式無法連線：瀏覽器通常會遵循系統代理，而目標應用程式可能忽略該設定或使用 UDP。先在連線頁面確認應用程式請求是否出現；完全沒有紀錄時，再考慮 TUN、應用程式內代理或程序路由設定。

八、首次連線檢查清單

  • 用戶端核心持續執行，日誌沒有設定解析失敗。
  • 訂閱已下載，並設為目前使用中的設定。
  • 代理頁面可以看到策略群組與節點。
  • 主要策略群組已選取一個實際節點，而非失效項目。
  • 節點延遲測試有回應，連續結果沒有異常波動。
  • 目前模式不是 Direct，且在規則模式下可以查看命中的策略。
  • 系統代理已開啟，作業系統代理連接埠與用戶端監聽連接埠一致。
  • 瀏覽器存取時，連線頁面出現對應的新紀錄。
  • 紀錄中顯示預期的規則、策略群組與最終節點。
  • 出口檢測結果與關閉系統代理時存在預期差異。

完成以上項目後，首次連線的基礎鏈路已經建立。後續如果只有特定程式無法連線，應將排查範圍縮小到應用程式是否遵循系統代理、是否使用 UDP、是否需要 TUN，以及對應網域命中了哪條規則。若所有應用程式同時失效，則回到設定、核心、監聽連接埠與本地網路四個基礎環節重新檢查。

穩定使用的關鍵不是持續追求最低延遲，而是保持設定有效、節點可達、流量入口明確且規則結果可觀察。只要能從連線紀錄中回答「請求是否進入 Clash、命中了什麼規則、最後經由哪個節點」，大多數首次連線問題都能定位到具體階段。