Clash 第一次連線教學：選擇節點、測試延遲並確認代理是否生效

連線前先確認訂閱已載入

第一次使用 Clash，建議先將流程拆成四個獨立狀態：設定可用、節點可用、策略組已選擇、系統流量已接入。客戶端顯示「執行中」只代表核心程序已啟動，不表示瀏覽器已透過代理存取網路。

檢查設定名稱與更新時間

以下操作以 Clash Verge Rev 2.4.x 與 mihomo 1.19.x 的常見介面為例。不同客戶端的按鈕名稱可能略有差異，但設定、代理、連線、選項這幾個頁面的職責大致相同。

開啟「訂閱」或「設定」頁面，確認剛匯入的設定已出現在清單中。
點選設定卡片，讓它成為目前啟用的設定。僅下載到本機但未選取時，核心不會使用其中的節點與規則。
查看更新時間。若顯示的是數週前的時間，請先執行一次「更新訂閱」。
進入「代理」頁面，確認看得到策略組與節點名稱，而不是空白清單。

啟動核心並查看錯誤訊息

返回「設定」→「Clash 設定」或「設定」→「核心設定」，確認目前核心為 mihomo。啟動成功後，日誌通常會出現設定載入、監聽連接埠與規則初始化資訊。常見的本機監聽值是 HTTP 連接埠 7890、SOCKS5 連接埠 7891，或統一使用 mixed-port: 7890。

如果日誌出現 address already in use，表示連接埠已被其他程式佔用；如果出現 YAML 解析錯誤，則是設定格式有問題。此時不要繼續測試節點，應先讓核心穩定執行。

在正確的策略組中選擇節點

Clash 的「代理」頁面通常會同時顯示節點與策略組。節點是具體線路，策略組則決定某類流量最終交給哪條線路。第一次連線時，最常見的問題不是沒有選節點，而是在不參與實際分流的組別中選了節點。

先辨識策略組類型

常見名稱	典型類型	首次連線時的處理方式
節點選擇、PROXY、Proxy	`select`	手動選擇一條具體節點，適合首次排查。
自動選擇、Auto	`url-test`	依測試結果自動使用較快的節點，但初次排障不如手動選擇直觀。
故障轉移、Fallback	`fallback`	優先使用清單中可用的前置節點，失敗後再切換。
負載平衡、Load Balance	`load-balance`	在多條線路間分配連線，不適合用來判斷單一節點的品質。
DIRECT、直連	直連出口	流量直接存取目標，不經過代理節點。

建議先開啟名稱類似「節點選擇」「手動選擇」或 PROXY 的組別，選取一條明確標示地區的節點，例如「日本 01」或「新加坡 02」。之後再檢查頁面頂端或主要策略組是否引用了這個組別。若主組仍選中 DIRECT，即使節點卡片亮起，也不會改變出口。

第一次測試先使用規則模式

在「設定」→「系統設定」或客戶端首頁找到代理模式，選擇「規則」。規則模式會依設定中的規則由上到下比對：區域網路與常見的中國大陸位址通常直連，需要代理的目標交給策略組，最後由 MATCH 處理未命中的流量。

規則模式：適合日常使用，也能驗證訂閱中的分流是否正常。
全域模式：大部分流量交給全域策略組，適合短時間排除規則問題。
直連模式：繞過代理。誤選此模式時，IP 檢測會一直顯示本地出口。

測試延遲時要看延遲、逾時與波動

客戶端中的延遲測試通常不是 ICMP Ping。Clash 會透過指定節點存取測試 URL，並記錄建立連線、TLS 協商或收到回應所需的時間。這個結果更接近代理可用性，但仍不等於下載速度。

執行一次可比較的批次測試

進入「代理」頁面，找到目前使用的策略組。
點選組別右上角的測速按鈕，等待所有節點完成，不要連續重複點選。
記錄延遲、逾時節點數量，以及同一節點連續三次結果的變化。
從延遲合理且波動較小的節點中手動選取一條，再進行網頁測試。

測試結果	一般意義	處理建議
40–120 ms	通常回應較快	可優先用於網頁、聊天與輕量請求。
120–250 ms	可用，但互動延遲較明顯	再測兩次，觀察是否穩定。
250–500 ms	路徑較遠、壅塞或中轉較多	與同地區的其他節點比較，不要只看單次結果。
Timeout	測試時間內未取得有效回應	更新訂閱後重新測試；仍逾時則更換節點。
80、310、95 ms 連續跳動	抖動明顯	即時通訊可能不穩定，優先選擇波動較小的線路。

例如節點 A 三次結果為 86、91、89 ms，節點 B 為 52、420、77 ms。雖然節點 B 的最低值較小，節點 A 通常更適合作為首次連線的測試對象。穩定性比一次偶然的低延遲更具參考價值。

延遲正常但網頁仍然很慢的原因

延遲只反映短請求的回應時間。線路頻寬、尖峰時段壅塞、目標網站限速、封包遺失率與裝置效能都會影響實際體驗。一個 65 ms 的節點可能只有較低的吞吐量，另一個 150 ms 的節點反而能穩定傳輸較大的檔案。

還要檢查測試位址是否可連線。mihomo 設定常使用 https://www.gstatic.com/generate_204 作為健康檢查位址。如果測試位址本身在目前網路環境中受阻，所有節點都可能顯示逾時，但這不一定代表每條代理線路同時失效。

開啟系統代理，讓瀏覽器流量進入 Clash

選好節點後，還要將應用程式流量送到 Clash 的本機監聽連接埠。一般瀏覽器通常可以透過系統代理接入；遊戲、命令列程式、商店應用程式與部分使用 UDP 的軟體，則可能忽略系統代理，需要 TUN 模式或應用程式本身的代理設定。

Windows 與 macOS 的系統代理檢查

在客戶端首頁開啟「系統代理」。Windows 11 可前往「設定」→「網路和 Internet」→「代理」查看手動代理狀態；常見位址為 127.0.0.1，連接埠為 7890。如果客戶端使用其他 mixed-port，系統設定中的連接埠必須保持一致。

macOS 可前往「系統設定」→「網路」→「Wi-Fi」→「詳細資訊」→「代理」檢查 Web 代理與安全 Web 代理。通常會由客戶端自動寫入，不建議在客戶端執行期間同時使用另一個代理工具修改這些項目。

先關閉可能衝突的網路工具

退出其他佔用 7890、7891 或相同控制連接埠的代理客戶端。
暫停瀏覽器中個別設定的代理擴充功能，避免請求被送往另一組位址。
確認系統時間正確。時間偏差過大可能導致 HTTPS 憑證驗證失敗。
首次驗證時暫時關閉應用程式內的自訂 DNS 或代理鏈設定，減少變數。

使用出口 IP 確認代理已生效

能開啟網頁不代表請求一定經過代理。最直接的驗證方式，是在啟用 Clash 前後分別查詢公網 IP，並比較位址、電信業者與地區資訊。測試應在同一個瀏覽器、同一個網路環境中完成。

瀏覽器驗證步驟

暫時關閉客戶端的「系統代理」，開啟 IP 查詢頁面，記錄原始公網 IP 的前兩段與所在地區。
重新開啟系統代理，確認模式為「規則」或「全域」，並選取剛才測試通過的節點。
建立無痕視窗，再開啟兩個不同的 IP 查詢頁面。
如果兩個頁面都顯示代理節點所在的地區，且 IP 與原始出口不同，瀏覽器代理基本上已經生效。
返回 Clash 的「連線」頁面，重新整理查詢頁，查看是否出現對應網域、目標位址、策略組與節點名稱。

例如關閉代理時出口為 203.0.113.24，開啟後變為 198.51.100.76，同時連線記錄顯示該請求命中 PROXY 並交給「新加坡 02」，表示瀏覽器流量已進入 Clash。這裡的位址僅用於說明判斷方法。

使用命令列比較直連與代理請求

Windows 11、macOS 與常見 Linux 發行版通常都可使用 curl。如果本機混合連接埠為 7890，可以分別執行：

curl https://api.ipify.org
curl -x http://127.0.0.1:7890 https://api.ipify.org

第一條命令會依目前的系統與終端機環境存取，第二條則明確指定 Clash 的 HTTP 代理。兩次回傳的 IP 不同，表示本機代理連接埠能夠轉送請求。若瀏覽器仍顯示原始 IP，應檢查系統代理或瀏覽器本身的設定，而不是反覆更換節點。

同時查看連線記錄

開啟客戶端的「連線」頁面，正常請求通常會顯示主機名稱、來源位址、上傳下載量、命中規則、策略鏈與最終節點。點選一筆連線後，可以確認它究竟經由 DIRECT、REJECT，還是某個代理節點。

如果 IP 查詢頁面命中 DIRECT，先切換至全域模式進行對照。全域模式下出口改變，表示節點與系統代理都可用，問題位於規則或策略組；全域模式下仍沒有連線記錄，則表示流量根本沒有進入目前的 Clash 執行個體。

系統代理無效時再啟用 TUN 模式

TUN 模式由 mihomo 建立虛擬網路介面，在網路層接收流量。它適合不讀取系統代理的程式，也能處理更多 UDP 情境。第一次連線不必同時開啟所有功能：先驗證一般系統代理，再依應用程式需求開啟 TUN，排障會更清楚。

TUN 的啟用順序

進入「設定」→「Clash 設定」→「TUN 模式」。
依客戶端提示安裝或啟用服務模式。Windows 通常需要管理員權限完成首次安裝。
開啟 TUN 後等待虛擬介面建立，再存取 IP 查詢頁面。
查看「連線」與「日誌」，確認目標應用程式的請求已被記錄。
若網路異常，先關閉 TUN，確認系統網路恢復，再檢查 DNS 與路由設定。

mihomo 的 TUN 通常會搭配 DNS 劫持、自動路由與嚴格路由。不同客戶端會將這些參數封裝成開關。對於初次使用者，不建議在不了解設定來源時同時修改介面名稱、MTU、路由表與 DNS 監聽連接埠。

如何判斷是否為 DNS 問題

如果能存取特定位址，卻無法透過網域名稱開啟網站，或日誌持續出現網域解析失敗，問題可能出在 DNS。使用 Fake-IP 模式時，DNS 模組會先回傳映射位址，再由核心根據原始網域名稱比對規則。看到 198.18.0.0/16 範圍的映射位址，不代表目標網站真的位於該網段。

可以先執行一次客戶端提供的 DNS 清理功能，或重新啟動核心，再重新測試。Windows 也可在終端機執行 ipconfig /flushdns 清理系統快取。若只有某個網域名稱失敗，應在連線日誌中查看它命中的規則與 DNS 回傳結果，而不是直接將所有流量改為全域。

第一次連線失敗快速定位表

現象	優先檢查	下一步
代理頁面沒有節點	訂閱是否成功更新、設定是否已選取	重新載入設定並查看解析日誌。
所有節點都顯示逾時	測試 URL、系統時間、目前網路	切換網路後重新測試，並向訂閱提供者確認線路狀態。
節點延遲正常，瀏覽器卻無法開啟網頁	系統代理位址與連接埠	檢查是否為 `127.0.0.1:7890`，再查看連線記錄。
網頁能開啟，但出口 IP 沒有變化	直連模式、規則命中、瀏覽器代理	暫時切換至全域模式進行對照。
瀏覽器可用，遊戲或終端機卻無法使用	應用程式是否支援系統代理	設定應用程式代理，或依需求啟用 TUN。
開啟 TUN 後無法解析網域名稱	DNS 設定與虛擬介面狀態	關閉 TUN 以恢復網路，再檢查 DNS 日誌。
啟動時顯示連接埠已被佔用	`7890`、`7891` 的佔用程序	退出衝突程式，或統一修改監聽與系統代理連接埠。

完成連線的最低驗證標準

目前設定已選取，更新操作未回傳格式錯誤。
mihomo 核心執行穩定，本機監聽連接埠已建立。
至少一條節點連續三次測試沒有逾時，延遲波動在可接受範圍內。
實際參與分流的策略組已選取該節點，而不是 DIRECT。
瀏覽器請求出現在「連線」頁面，並顯示最終使用的節點。
兩個獨立的 IP 查詢結果都與關閉代理時不同。

完成這六項後，首次連線就已經完成。之後再處理自動測速、策略組細分、規則調整、訂閱自動更新與 TUN 常駐等進階設定。每次只修改一個變數，並用連線記錄與出口 IP 重新確認結果，定位問題會更快。