Clash 第一次連線實作：選節點、測延遲、確認代理生效的三步檢查

開始前確認：設定已載入，連接埠沒有衝突

第一次連線時，應先將問題拆成三層：設定是否正常載入、節點能否建立連線，以及應用程式流量是否真正進入 Clash。只看客戶端主畫面的「已啟動」狀態並不足夠。這通常只代表核心程序正在執行，不代表訂閱中的節點可用，也不代表瀏覽器已使用本機代理連接埠。

開啟客戶端後，先進入「設定」或「Profiles」頁面，確認剛匯入的訂閱處於選取狀態。設定旁通常會顯示更新時間、檔案名稱或訂閱名稱。若頁面顯示解析失敗、設定檔為空，或切換設定後核心立即退出，應先解決匯入問題，再進行節點測試。

檢查本機監聽連接埠

常見設定使用 HTTP 連接埠 7890、SOCKS5 連接埠 7891，也有較新的設定透過 mixed-port: 7890 在同一個連接埠接收 HTTP 與 SOCKS5 流量。實際數值由設定檔與客戶端設定決定，不必強行改成固定連接埠，但系統代理填寫的連接埠必須與 Clash 實際監聽的數值一致。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9090

在圖形化客戶端中，連接埠通常位於「設定」→「參數設定」→「連接埠」或「General」→「Port」。若 7890 已被其他代理程式佔用，客戶端可能顯示 bind failed、address already in use 或啟動失敗。此時可關閉佔用連接埠的軟體，或將 Clash 連接埠改為 7892，再重新開啟系統代理。

第一步：在策略組中選擇合適的節點

匯入訂閱後，節點通常不會直接出現在首頁，而是位於「代理」或「Proxies」頁面的策略組中。常見組名包括「節點選擇」「代理」「Proxy」「手動選擇」。先找到負責主要流量出口的選擇型策略組，再從組內選取一個節點。不要只在包含 DIRECT、REJECT 等項目的總覽頁面中隨意點選。

從手動選擇組開始

1. 進入「代理」→「節點選擇」，確認目前模式為「規則」或 Rule。
2. 展開主要代理策略組，選擇地理位置較近、名稱資訊完整的節點。
3. 若其他策略組引用了「節點選擇」，讓它們維持指向該組即可，不必逐組重複指定。
4. 返回首頁，確認核心狀態為執行中，再開啟「系統代理」。

第一次測試適合手動固定一個節點。這樣可以明確知道後續測速、IP 查詢與連線記錄對應的是哪個出口。如果一開始就選擇 url-test、自動選擇或負載平衡組，客戶端可能在測試期間切換節點，容易造成前後結果不一致。

節點名稱只能作為篩選線索

節點名稱中的地區、倍率、專線等文字由訂閱提供者定義，不代表即時品質。實際體驗主要受本機至伺服器的網路路徑、伺服器負載、協定參數與目標網站線路影響。距離較近的節點通常往返時間較低，但不保證下載速度最高；低倍率節點也不等於連線更穩定。

如果策略組中只有 DIRECT，或節點清單完全空白，通常不是「沒有選取節點」，而是訂閱內容未成功轉換成目前核心支援的設定。此時返回「設定」頁面更新訂閱、查看錯誤記錄，並確認所用客戶端的 mihomo 核心版本能辨識設定中的代理協定與欄位。

第二步：測試延遲並判斷節點是否可用

選取節點後，在策略組右側點擊延遲測試按鈕。不同客戶端可能以測速圖示、閃電圖示或「Test」表示。測試網址通常是一個很小的 HTTP 或 HTTPS 頁面，客戶端會記錄建立連線並取得回應所需的時間，結果以毫秒顯示。

如何解讀延遲結果

• 50–150 ms：常見於線路較近且狀態正常的節點，網頁互動通常較順暢。
• 150–300 ms：仍可用於一般瀏覽與下載，但即時互動的等待感可能增加。
• 300–800 ms：可能存在繞路、壅塞或節點負載較高的情況，應與同地區其他節點比較。
• Timeout：在測試時間內未取得有效回應，需要區分測試網址無法連線、節點失效與本機網路遭攔截。

這些區間僅供排查參考，不是固定合格標準。一次顯示 82 ms、下一次顯示 210 ms，表示線路存在波動；連續測試三次分別為 86 ms、91 ms、89 ms，則比只看單次最低值更有參考價值。第一次篩選時，可保留兩至三個連續成功且波動較小的節點。

延遲正常不代表所有網站都能開啟

延遲測試只驗證「本機 → 節點 → 測試網址」這條請求鏈路。它不會測試所有目標網站，也不會測量大檔案吞吐量。某個節點延遲為 95 ms，但特定網站仍可能因規則命中 DIRECT、目標網站限制、DNS 結果異常或節點出口網路不同而無法存取。

相反地，Timeout 也不一定代表節點完全失效。測試 URL 可能受到目標網路限制，或客戶端設定的逾時時間過短。可在「設定」→「延遲測試」中檢查測試網址與逾時值。常見逾時值為 5000 ms。更換測試網址後，若所有節點都恢復結果，問題更可能出在原測試網址，而不是整份訂閱。

所有節點同時逾時時先檢查本機

如果十幾個節點在同一時間全部 Timeout，逐一更換節點的效益不高。先切換到另一個網路，例如從家用 Wi-Fi 切換到手機熱點，再重新測試。若在熱點下恢復，問題可能出在路由器、目前寬頻或本機網路過濾；若兩種網路都失敗，再檢查訂閱更新時間、系統時間、核心記錄與節點協定參數。

電腦時間偏差也可能導致 TLS 交握失敗。Windows 可進入「設定」→「時間與語言」→「日期與時間」，開啟自動設定時間並立即同步；macOS 可進入「系統設定」→「一般」→「日期與時間」，確認已啟用自動設定。同步後重新啟動核心，而不是只重新整理代理頁面。

第三步：確認流量確實經過代理

節點顯示延遲後，還要完成流量驗證。最可靠的判斷由三部分組成：系統代理或 TUN 已啟用、出口 IP 與直連狀態不同，以及 Clash 連線面板能看到剛才產生的請求。三項同時成立，才能將「節點可用」與「應用程式已使用代理」連結起來。

先記錄直連出口 IP

1. 暫時關閉 Clash 的「系統代理」與「TUN 模式」。
2. 在瀏覽器開啟可信任的 IP 查詢頁面，記錄目前的公網 IP 與地區。
3. 關閉該頁面，重新開啟 Clash，並維持先前選定的節點。
4. 再次開啟查詢頁面，比較公網 IP、網路業者與地區。

若代理後的出口 IP 與直連 IP 不同，且地區與節點出口大致一致，表示瀏覽器請求很可能已經過代理。但 IP 查詢只能確認這次存取使用的出口，不能證明所有應用程式與所有協定都已被接管。部分瀏覽器還可能快取頁面，因此測試前可使用無痕視窗，或強制重新整理頁面。

在連線面板核對請求鏈路

開啟客戶端的「連線」或「Connections」頁面，然後在瀏覽器存取一個之前未開啟過的網站。連線清單應出現新的網域、目標位址、規則名稱、策略組與實際節點。常見記錄如下：

Host: example.com
Network: TCP
Rule: DomainSuffix
Chain: 節點選擇 → HK-01
Upload: 3.2 KB
Download: 18.7 KB

其中 Chain 或 Chains 表示策略組最終連到哪個節點。若鏈路顯示「節點選擇 → HK-01」，表示請求經過該節點；若顯示 DIRECT，則請求依照規則直接連線。在規則模式下出現 DIRECT 屬於正常現象，區域網路位址、中國大陸網站或設定指定的網域可能本來就應該直連。

連線面板完全沒有新請求，通常表示應用程式沒有使用 Clash。此時檢查「設定」→「系統代理」是否已開啟，並核對系統代理位址是否為 127.0.0.1、連接埠是否與 Clash 的 HTTP 或 mixed 連接埠一致。若瀏覽器安裝了代理擴充功能，確認它沒有覆寫系統設定並指向其他連接埠。

系統代理與 TUN 模式的涵蓋範圍

系統代理主要影響遵循作業系統代理設定的應用程式，例如常見瀏覽器與部分桌面軟體。某些遊戲、命令列程式、商店應用程式與 UDP 流量不會自動讀取系統代理。需要接管這類流量時，可在客戶端的「設定」→「網路」→「TUN 模式」中啟用 TUN。

TUN 會建立虛擬網路介面，將更多 IP 層流量交由 mihomo 處理。第一次啟用時可能需要管理員權限，Windows 也可能安裝或啟用相關網路元件。啟用後再次查看「連線」面板，確認目標程序產生的連線已經出現。不要同時將系統代理錯誤地指向另一個程式，否則 HTTP 請求與 TUN 流量可能呈現兩套不同結果。

三類常見誤區：看似已連線，實際問題仍在

誤區一：只看首頁開關

首頁顯示「執行中」只代表核心啟動成功。完整狀態至少包括：設定載入成功、節點延遲測試有結果、系統代理或 TUN 已開啟，以及連線面板出現請求。缺少任何一項，都可能出現客戶端正在執行，但網頁仍然直連或無法存取的情況。

誤區二：把最低延遲當成最快速度

延遲測試傳輸的資料很少，主要反映回應時間。下載速度還會受到伺服器頻寬、線路壅塞、節點負載、單一連線限速與目標網站效能影響。兩個節點的延遲分別為 70 ms 和 110 ms 時，後者仍可能擁有更穩定的下載吞吐量。日常使用時，應同時觀察網頁回應、連續連線穩定性與實際傳輸速度。

誤區三：出口 IP 沒有變化就認定節點失效

在規則模式下，IP 查詢網站可能被設定為 DIRECT，因此顯示的仍是本地出口。先到「連線」頁面查看該網域命中了哪條規則。如果記錄顯示 DIRECT，可暫時將模式切換為全域並重新測試；若全域模式下出口發生變化，表示節點本身可用，需要調整規則或選擇正確的代理策略組。

另一種情況是瀏覽器啟用了安全 DNS、獨立代理擴充功能或企業策略。這些設定可能改變網域解析或代理路徑。排查時先關閉額外擴充功能，只保留系統代理這一個入口，再觀察連線面板。DNS 查詢結果與網頁 TCP 連線是兩個環節，不應只根據 DNS 伺服器位置判斷所有流量是否經過代理。

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

遇到網頁無法開啟、測速全部逾時或出口 IP 沒有變化時，依固定順序檢查比隨機切換設定更快。每次只修改一個變數，並在修改後重新發出請求。

1. 設定：確認訂閱處於選取狀態，更新時沒有解析錯誤，節點清單不是空白。
2. 核心：確認狀態為執行中，記錄中沒有連接埠佔用、欄位錯誤或權限錯誤。
3. 節點：固定一個節點測試三次，再更換同地區的另一個節點比較。
4. 連接埠：核對 mixed、HTTP、SOCKS5 連接埠與系統代理設定一致。
5. 應用程式入口：瀏覽器先使用系統代理測試，不讀取系統代理的應用程式再考慮 TUN。
6. 規則：在連線面板查看命中的是 DIRECT、REJECT 還是代理策略組。
7. 網路：切換手機熱點重新測試，區分客戶端設定與目前區域網路問題。
8. 記錄：根據 timeout、connection refused、TLS handshake 等具體資訊定位問題環節。

例如，節點延遲正常、IP 查詢仍顯示直連、連線面板沒有記錄，這組現象優先指向系統代理未生效，而不是節點問題。若連線面板已有記錄，鏈路指向所選節點，但請求顯示 timeout，則應繼續檢查節點與目標網路。若記錄明確顯示 REJECT，則需要檢查規則，而不是修改連接埠。

完成檢查後的建議日常設定

確認連線成功後，可將模式維持為 Rule，讓設定依網域、IP 與規則集決定 DIRECT 或代理。主要策略組可以繼續固定至穩定節點，也可以切換至 url-test 自動選擇組。使用自動組前，應先確認組內節點都能獨立連線，否則自動測試只能在可用範圍內選擇，無法修復失效設定。

• 使用系統代理時，維持本機監聽位址為 127.0.0.1；不需要區域網路共享時，關閉 Allow LAN。
• 需要遊戲、命令列或不讀取系統代理的軟體時，再啟用 TUN，並確認連線面板能辨識其流量。
• 訂閱更新後若節點名稱變更，重新檢查手動策略組是否仍指向有效節點。
• 網頁異常時，先查看連線記錄與規則命中情況，不要直接刪除整份設定。
• 保留一個經過三次延遲測試與實際存取驗證的備用節點，方便快速比對。

第一次連線的重點不是把所有開關全部開啟，而是建立清晰的驗證鏈：先選定一個具體節點，再用延遲測試確認基本連通，最後透過出口 IP 與連線面板確認請求路徑。完成這三步後，日後遇到速度下降、個別網站無法開啟或特定應用程式未使用代理時，就能判斷問題出在節點、規則還是流量入口。