Clash 首次連線教學：選擇節點、測試延遲與驗證代理狀態

首次連線前先釐清四個環節

Clash 用戶端完成安裝，不代表網路流量已經經過代理。一次完整連線通常包含四個彼此獨立的環節：設定成功載入、策略組已選擇出口、用戶端核心處於執行狀態，以及作業系統或應用程式流量進入 Clash。任何一個環節未完成，都可能出現「用戶端已開啟但網頁沒有變化」的情況。

訂閱負責提供節點、策略組與規則等設定內容；節點是實際使用的代理出口；規則決定不同請求交給哪個策略組；系統代理或 TUN 模式則負責將流量送入 Clash。首次使用時應依這個順序檢查，而不是反覆開關用戶端或連續更換節點。

不同用戶端的選單名稱可能略有差異，例如「設定」也可能顯示為 Profiles，「代理」可能顯示為 Proxies，「一般」可能顯示為 General。基於 Clash Meta（mihomo）核心的用戶端還可能提供更多 DNS、TUN 與規則覆寫選項，但首次連線無需立即修改這些進階項目。先使用訂閱原有設定完成最小連線閉環，更容易判斷問題出在哪一步。

匯入訂閱並確認設定已生效

從服務提供者取得 Clash 或 Clash Meta 相容的訂閱網址後，進入用戶端的設定頁面，透過 URL 匯入功能新增訂閱。桌面用戶端通常允許貼上訂閱網址並下載設定；行動裝置可能將這個入口稱為「從 URL 匯入」或「建立新設定」。訂閱網址屬於帳戶設定資料，不宜發布到公開頁面，也不要將它誤當成一般節點網址逐一新增。

匯入成功後，設定清單中應出現一筆新紀錄。檢查是否顯示更新時間、設定名稱或節點數量，並主動將該設定設為目前使用項目。僅下載到清單但沒有選取時，用戶端可能仍在使用內建空白設定、舊設定或先前匯入的其他訂閱。

如何判斷訂閱匯入成功

• 設定頁面出現對應紀錄，手動更新時沒有格式解析錯誤。
• 代理頁面能看到策略組與組內節點，而不是只有 DIRECT 和 REJECT。
• 規則頁面存在網域、IP、程序或兜底規則，設定內容並非空白。
• 用戶端記錄沒有連續出現設定檔不存在、YAML 解析失敗或連接埠被占用的提示。

如果設定可以下載，但代理頁面沒有節點，先檢查訂閱類型是否適用於 Clash。有些服務同時提供通用訂閱、單節點連結和 Clash 設定，用戶端需要的是明確標示為 Clash 或 mihomo 設定的入口。若更新時返回登入頁面、權限錯誤或到期提示，應先處理訂閱帳戶狀態，重新安裝用戶端通常無法解決遠端訂閱失效問題。

設定更新後，策略組的選擇結果可能會保留，也可能依新設定重新建立。節點名稱與分組發生變化時，應重新進入代理頁面確認目前選擇，避免繼續指向已從訂閱中移除的舊節點。

理解規則模式、全域模式與直連模式

Clash 常見的執行模式包括規則模式、全域模式與直連模式。首次連線建議優先使用規則模式，因為它會依照設定中的規則決定請求去向：需要代理的流量交給代理策略組，本地網路或指定網站可以直接連線，最終未命中的請求則由末端兜底規則處理。

全域模式會將進入 Clash 的大部分流量交給全域策略組，適合短時間驗證某個節點能否作為出口，但這不等同於作業系統層面的「所有程式必然都被接管」。流量是否進入用戶端，仍取決於系統代理、TUN 模式以及應用程式本身的網路行為。

直連模式通常會讓流量繞過代理出口。它適合暫時排除代理節點的影響，卻不適合作為首次連線的最終狀態。若用戶端顯示執行正常，但外部連線結果一直與直連相同，應確認模式沒有停留在 DIRECT，也要檢查目前策略組是否選中了 DIRECT。

選擇策略組與節點

進入代理頁面後，通常會看到多個策略組。常見組名可能代表節點選擇、自動測速、故障轉移、串流媒體或最終出口。組名由訂閱設定提供，並非所有用戶端都完全相同。首次連線應先找到負責主要代理流量的選擇組，再查看該組目前指向的是具體節點、另一個策略組，還是 DIRECT。

如果組內有「自動選擇」或 URL-Test 類型的策略組，它會按照設定指定的測試網址與週期測量可用性，並從候選節點中選擇結果較合適的一個。Fallback 類型更重視故障切換，通常使用目前可用且排序靠前的節點。Select 類型則需要使用者手動指定。介面中看到延遲數值，不代表所有策略組都會自動更換節點，Select 組仍以手動選擇結果為準。

首次選擇節點的實用標準

1. 先看可達性。能穩定完成延遲測試的節點，優先級高於偶爾出現極低數值但頻繁逾時的節點。
2. 再看延遲。較低延遲通常有利於網頁回應與互動，但不直接代表下載頻寬。
3. 考量使用目的。部分網站會限制出口地區、IP 類型或帳戶地區，應依實際存取目標選擇。
4. 避免一次變更多項設定。首次驗證只選擇一個明確節點，連線成功後再比較其他線路。

策略組可以互相引用。例如「節點選擇」組中可能包含「自動選擇」，而規則又可能將請求交給「節點選擇」。此時實際出口由多層選擇共同決定。遇到選擇後沒有變化時，應沿著策略組引用關係逐層查看，直到確認最末端指向某個具體節點，而不是仍停留在 DIRECT 或不可用的子組。

正確理解延遲測試結果

用戶端中的延遲測試通常不是標準 ICMP Ping。Clash 會透過節點向指定測試 URL 發起 HTTP 或 HTTPS 請求，並記錄建立連線及取得回應所需的時間。因此，測試結果同時受到本地網路、代理協定交握、節點負載、測試網站與線路品質影響。作業系統命令列能 ping 通某台伺服器，也不能直接證明代理協定可以建立連線。

按下全部測試後，先等待一輪完成，再觀察同一節點多次測試是否穩定。顯示幾十或幾百毫秒是特定網路環境下的測量值，沒有適用於所有地區的固定合格線。比單次數字更重要的是連續結果：如果某個節點經常從正常數值跳到逾時，實際瀏覽時也容易出現首屏等待或連線中斷。

若所有節點同時逾時，應優先懷疑共同條件，而不是斷定所有節點一起失效。可檢查本地網路是否能存取外部測試網址、系統時間是否準確、訂閱是否剛更新、DNS 是否異常，以及防火牆是否阻止用戶端核心連線。公司、校園或公共網路也可能限制特定協定或連接埠，可改用手機熱點進行對照測試。

如果只有個別節點逾時，則選擇同組中能穩定回傳結果的節點繼續驗證。延遲測試成功仍不代表目標網站必然可用，因為目標網站可能有地區限制，規則也可能將該網站送往另一個策略組。最終判斷必須結合連線記錄與實際請求。

啟動核心並開啟系統代理

設定與節點準備完成後，確認 Clash 核心已經啟動。部分用戶端開啟介面時會自動執行核心，另一些用戶端則需要啟用「服務」、「執行」或主要連線開關。核心未啟動時，即使系統已寫入代理位址，也可能因為本地監聽連接埠不存在而無法連網。

桌面系統上的「系統代理」一般會將作業系統的 HTTP 與 HTTPS 代理設定指向 Clash 的本地監聽位址。遵循系統代理設定的瀏覽器與應用程式會將請求交給 Clash。某些程式使用獨立代理設定、直接建立連線或自行實作網路堆疊，因此不會自動遵循系統代理。

首次連線不必同時開啟系統代理與 TUN。先使用系統代理驗證瀏覽器流量，路徑較清楚，權限需求也較少。確認基礎代理正常後，若確實需要接管不遵循系統代理的應用程式、UDP 流量或更多系統連線，再依用戶端說明啟用 TUN 模式。

TUN 模式與系統代理的差異

TUN 模式透過虛擬網路介面與系統路由接收流量，涵蓋範圍通常比系統代理更廣。基於 mihomo 核心的用戶端可能提供自動路由、DNS 劫持、嚴格路由等相關設定。啟用 TUN 往往需要管理員權限、網路擴充功能授權或 VPN 權限，也可能與其他 VPN、虛擬網卡或企業安全軟體發生衝突。

首次使用時同時開啟多種接管方式，會增加判斷難度。如果系統代理已經可以讓瀏覽器正常連線，應先記錄這個結果，再單獨測試 TUN。切換前關閉其他 VPN，並在失敗後查看用戶端記錄，不要只憑狀態列圖示判斷是否建立了有效轉送。

用三層檢查驗證代理狀態

連線驗證不應只看用戶端按鈕是否變色。較可靠的方法是依序檢查用戶端記錄、實際網頁存取與出口資訊。三層結果互相印證，能夠區分「核心已啟動」、「請求已進入 Clash」與「請求已透過目標節點完成」這幾種狀態。

第一層：查看連線記錄

開啟用戶端的連線或記錄頁面，然後在瀏覽器重新整理一個網頁。正常情況下應出現新的網域、目標位址、命中規則與策略鏈記錄。記錄可能顯示請求命中了某條規則，並透過某個策略組前往具體節點；若記錄顯示 DIRECT，代表該請求依目前規則直連，不一定是故障。

瀏覽器重新整理後完全沒有新的連線記錄，通常表示流量尚未進入 Clash。此時檢查系統代理是否開啟、瀏覽器是否使用獨立代理、用戶端監聽連接埠是否正常，以及作業系統代理設定是否被其他程式改寫。

第二層：存取一般網頁

選擇一個在目前網路環境中結果明確的網頁進行測試。先確認頁面能夠開啟，再觀察圖片、指令碼與 API 請求是否完整。只開啟首頁並不能涵蓋所有連線，因為頁面資源可能分布在多個網域，並由不同規則處理。若正文出現但圖片或影片載入失敗，應在連線記錄中查找對應資源網域的策略去向。

第三層：核對出口資訊

透過可信的 IP 資訊頁面查看目前出口位址與地區，再與關閉系統代理時的結果進行對照。出口發生變化，且記錄顯示請求透過所選節點，才能說明這次瀏覽器請求完成了代理轉送。出口沒有變化時，應檢查目前策略是否選擇 DIRECT、目標查詢網站是否命中直連規則，以及瀏覽器是否啟用了繞過系統代理的功能。

1. 保持目前節點不變，開啟系統代理並重新整理測試頁面。
2. 在連線清單中找出測試頁面對應的網域請求。
3. 確認策略鏈最終落到預期節點，而不是 DIRECT。
4. 記錄出口資訊，再關閉系統代理進行一次對照。
5. 測試完成後重新開啟所需的接管方式，並確認用戶端狀態。

首次連線失敗時的固定排查順序

排障時每次只變更一個條件，並從設定層逐步檢查到系統層。連續重裝、同時更換訂閱與修改 DNS，會讓原本簡單的問題失去可比結果。以下順序適用於多數桌面與行動用戶端。

遇到「開啟系統代理後所有網頁都無法存取」，先關閉系統代理恢復本地網路，再檢查核心是否執行以及本地連接埠是否被占用。如果記錄出現監聽失敗，可能是另一個代理用戶端正在使用相同連接埠。完全退出其他代理或 VPN 程式後重新啟動 Clash，比任意修改多個連接埠更容易確認原因。

遇到「延遲測試正常但網頁打不開」，重點查看實際請求記錄。測試 URL 與目標網頁不是同一個網站，兩者可能命中不同規則或使用不同 DNS 結果。還應檢查瀏覽器是否啟用了 HTTP/3、獨立 DNS 或擴充功能代理設定。可以暫時改用另一個遵循系統代理的瀏覽器進行對照，但不要同時更換節點與執行模式。

遇到「部分網站正常、部分網站失敗」，通常表示基礎連線已經建立，問題更可能出在規則、策略組、DNS 或目標網站限制。找到失敗網域對應的連線記錄，確認它命中了哪條規則、交給哪個策略組，再檢查該組的實際出口。規則模式會由上到下比對，較早命中的規則會決定處理方式，末端的 MATCH 通常負責兜底。

連線成功後的基本設定

首次驗證完成後，可以再處理自動更新、開機啟動與策略儲存。訂閱更新頻率不宜設定得過於密集，依照服務提供者與用戶端的預設週期即可。更新設定後應留意節點名稱、策略組結構與規則是否變更，並重新確認重要策略組的選擇。

如果啟用開機啟動，還要區分「用戶端自動開啟」、「核心自動執行」與「系統代理自動開啟」。三者可能是獨立選項。共用電腦或經常切換網路的裝置，更適合保留手動開啟系統代理的習慣，避免用戶端核心尚未就緒時留下失效的系統代理設定。

日常使用中可以保留一個穩定節點作為基準。網路異常時，先測試基準節點，再比較其他節點；如此能判斷是單一路線波動，還是本地網路、訂閱或用戶端整體出現問題。需要更廣泛的流量接管時，再逐項設定 TUN、DNS 與路由選項，並在每次變更後重複「連線記錄—網頁存取—出口資訊」三層驗證。