Clash 首次連線檢查清單：測速選節點，確認代理是否生效

1. 匯入訂閱後，先確認設定已啟用

訂閱匯入成功，只代表用戶端已取得設定內容。若要讓瀏覽器連線經過代理，還得啟用設定、選擇代理組中的節點，並讓流量進入代理。首次連線建議先用系統代理測試瀏覽器請求，暫時關閉 TUN 模式，避免兩種接入方式同時運作，讓問題難以判斷。

不同用戶端可能將設定入口稱為「設定」、「訂閱」或「Profiles」。進入相應頁面後，請檢查以下四項，別只看「更新成功」的提示。

1. 目前使用的設定：確認匯入的項目已選取或啟用，而非僅儲存在清單中。
2. 更新時間：手動更新一次，確認沒有驗證失敗、下載逾時或解析錯誤。
3. 核心狀態：確認 Clash 或 mihomo 已啟動，且記錄中沒有設定載入失敗、連接埠遭占用等錯誤。
4. 代理組內容：確認看得到節點或已載入的節點提供者，不是只有空白群組和 DIRECT。

若設定提示欄位不支援，請先確認訂閱要求使用的核心。Clash 與 mihomo 支援的設定功能並不完全相同。反覆切換系統代理無法解決設定語法或通訊協定相容性問題，應先讓核心正常載入設定。

2. 在代理組中選擇節點並測試延遲

開啟用戶端的「代理」或「Proxies」頁面，找到預設代理組。組名由訂閱設定，可能是「節點選擇」，也可能是其他名稱。先確認規則最後使用哪個代理組，再從組內選擇節點。若代理組內還有巢狀代理組，請繼續查看下一層，直到確認最終出口。

延遲數值代表什麼？

用戶端的延遲測試通常是透過節點連線至指定測試 URL，而非單純執行 ICMP Ping。結果會受到測試網址、逾時設定、DNS 與當下線路狀況影響。這項測試適合篩選目前可連線的節點，但不直接代表下載頻寬，也無法保證所有網站都能存取。

• 先測試 2～3 個節點，盡量使用相同的測試網址與逾時條件。
• 連續測試 3 次，觀察結果是否穩定，別只憑一次最低值選節點。
• 先確認一般網頁能正常瀏覽，再測試大型檔案，避免消耗不必要的流量。

例如，某條線路三次測得 85、92、88 毫秒；另一條則是 45 毫秒、逾時、310 毫秒。前者雖然最低延遲較高，但波動較小，更適合用來驗證首次連線。這只是判讀結果的範例，並非任何節點的實測報告。

逾時與自動選擇的處理方式

單一節點逾時，可改測同組的其他節點；若全部逾時，請檢查本機網路、訂閱效期、系統時間與核心錯誤。測試網址本身無法連線，也可能造成大量逾時，因此還應改用實際要瀏覽的網站確認。

若選擇 url-test 自動測速組，目前的出口會由測試結果決定；fallback 組通常依可用性與設定順序選擇；load-balance 組則可能讓不同連線使用不同節點。為了讓首次檢查更容易重現，可暫時在手動選擇組中固定一個節點，檢查完再恢復自動策略。

3. 使用規則模式並開啟系統代理

首次在桌面用戶端驗證時，建議使用規則模式。用戶端會依設定中的 rules 由上而下比對，請求可能交由代理組處理，也可能符合 DIRECT 或 REJECT。系統代理則會將遵循系統代理設定的應用程式請求導入本機監聽連接埠。兩者用途不同，必須分別確認。

「全域模式」不代表接管系統的所有流量。未進入核心的連線，不會因切換至全域模式就自動經過代理。瀏覽器代理擴充功能、應用程式個別代理設定與系統代理之間也可能互相覆蓋；排查時請先關閉其他代理擴充功能。

確認本機位址與監聽連接埠

在用戶端設定中尋找 HTTP 連接埠或混合連接埠。常見範例為 127.0.0.1:7890，但實際值應以目前設定為準。mixed-port 可接收 HTTP 與 SOCKS 代理請求；external-controller 是控制介面，不能當作瀏覽器代理連接埠。

• Windows 11：「設定」→「網路和網際網路」→「Proxy」→「手動設定 Proxy」，確認用戶端設定的位址與連接埠。首次操作建議優先使用用戶端提供的系統代理開關。
• macOS：「系統設定」→「網路」→目前使用的網路服務→「詳細資訊」→「代理伺服器」，檢查目前生效的代理項目。不同系統版本的選單名稱可能略有差異。

本機使用時，不必為了「連線成功」而開啟允許區域網路存取，也不需要開放控制介面。若監聽連接埠發生衝突，請先關閉占用該連接埠的其他代理程式，再重新啟動目前的用戶端。

4. 透過連線記錄確認規則與實際節點

開啟系統代理後，打開用戶端的「連線」或「Connections」頁面，再用瀏覽器新增一個分頁，前往要測試的網站。請查看剛產生的請求，而非只觀察總流量數字有沒有變化。部分短連線很快就會結束，可搭配記錄頁面查看。

1. 確認目標：網域或目標位址是否符合剛才造訪的網站。
2. 確認命中規則：查看套用的是網域規則、規則集、地區規則，還是最後的 MATCH。
3. 確認策略鏈：查看顯示的是 DIRECT，還是預期的代理組及其最終節點。
4. 確認傳輸狀況：請求是否有傳送與接收資料，是否持續出現連線失敗或逾時。

若請求命中 DIRECT，表示請求已進入核心，但被分流為直連；這不代表系統代理未生效。相反地，若完全沒有相關連線記錄，請檢查應用程式是否遵循系統代理、頁面是否來自快取，以及用戶端是否隱藏了部分連線。mihomo 設定也可能調整記錄層級或隱藏相關記錄，不能只根據單一空白頁面下結論。

若看得到目標請求，卻使用了非預期節點，請檢查代理組是否有巢狀設定、是否啟用負載平衡，以及用戶端是否恢復了上次的選擇。暫時固定單一節點，比同時修改規則、DNS 與 TUN 設定更容易找出原因。

5. 比對出口 IP，確認代理確實生效

連線記錄能說明「請求如何傳送」，出口 IP 則能確認「外部服務看到哪個位址」，兩者一起檢查更可靠。先在關閉系統代理與 TUN 的狀態下記錄直連出口，再開啟系統代理、固定節點，並使用同一個 IP 查詢服務再次測試。測試時請避免同時執行其他 VPN，否則直連基準也可能已經經過其他通道。

在規則模式下，IP 查詢服務本身可能被設定為直連。若出口沒有變化，請先查看該請求命中的規則。若要排除規則造成的影響，可短暫切換至全域模式，並在全域選擇器中指定目標節點；完成驗證後再切回規則模式。

使用命令列區分本機代理與系統代理

以下以混合連接埠 7890 為例。第一個指令會明確略過代理，第二個指令則明確連線至本機 HTTP 代理。執行前請確認已關閉 TUN，且沒有其他 VPN 接管路由；並將連接埠改為用戶端實際監聽的值。查詢服務會收到這次請求及其來源位址。

# macOS / Linux：直連請求
curl --noproxy "*" --max-time 15 https://api.ipify.org

# macOS / Linux：明確透過本機代理
curl --noproxy "" --proxy http://127.0.0.1:7890 --max-time 15 https://api.ipify.org

在 Windows PowerShell 中，建議明確使用 curl.exe，避免部分環境將 curl 解讀為其他指令。明確測試代理前，可暫時清除目前終端機的 NO_PROXY 環境變數，再執行：

Remove-Item Env:NO_PROXY -ErrorAction SilentlyContinue
curl.exe --proxy http://127.0.0.1:7890 --max-time 15 https://api.ipify.org

明確指定代理的指令若能成功，代表本機連接埠與該請求路徑可用，但不能單獨證明系統代理設定正確。還要回到瀏覽器，透過記錄確認瀏覽器請求確實進入核心。

出口地區資料庫可能更新較慢，節點名稱也不一定與實際出口城市相符。IPv4 與 IPv6 的結果也可能不同。別只看國旗圖示；請記錄查詢時間、位址類型、命中策略與出口位址。即使 IP 相同，也要搭配規則與策略鏈判斷，以免將共用出口或不同位址家族造成的現象誤認為連線故障。

6. 瀏覽器可用、其他應用程式無法連線時，再檢查 TUN

系統代理並非透明代理。部分遊戲、命令列工具與採用自有網路堆疊的應用程式不會讀取系統代理設定；UDP 流量也無法只靠一般 HTTP 系統代理導入。遇到這種情況，可先確認應用程式是否支援個別設定 HTTP 或 SOCKS 代理，再決定是否使用用戶端的 TUN 模式。

TUN 會透過虛擬網路介面與路由設定，將符合條件的流量導入核心。桌面版可能需要管理員權限、服務模式或網路延伸功能授權；Android 用戶端則通常使用系統 VPN 介面。所需權限與設定入口取決於用戶端及作業系統，不宜直接照搬其他平台的選單路徑。

• 先確認系統代理路徑已驗證成功，再單獨測試 TUN，避免同時排查節點無法使用與路由問題。
• 確認是否與其他 VPN、虛擬機器網路或企業網路政策衝突。
• 啟用後重新檢查目標應用程式的連線記錄，不要只因「TUN 已啟動」就判定代理成功。
• 若區域網路裝置無法連線，請檢查路由排除設定與直連規則，不要直接關閉防火牆。

若能連線至 IP，卻無法解析網域，應進一步檢查 DNS 設定與核心解析記錄。系統代理下的解析行為、TUN 下的 DNS 劫持與 fake-ip 對應並非同一回事。首次檢查時不建議隨意複製整套 DNS 設定；請先保留可正常運作的原始設定，確認是哪個網域、哪一筆解析請求失敗。

7. 常見連線問題與排查順序

每次只調整一個變數：節點、模式、連接埠或接入方式。記錄變更前後的狀況，才容易找出有效的修復方式。遇到憑證錯誤時，請先檢查系統時間與目標網站的憑證資訊；不要略過 TLS 驗證來完成首次連線測試。

8. 首次連線完成後的確認清單

• 目前的訂閱已啟用，核心沒有持續回報錯誤。
• 確認預設代理組與最終節點，不要只記住測速數字。
• 系統代理位址與實際監聽連接埠一致。
• 目標請求出現在連線記錄中，並命中預期策略。
• 出口 IP 與記錄中的結果一致，且已區分直連規則與代理規則。
• 恢復日常使用的規則模式，取消暫時性的測試變更。
• 結束用戶端前關閉系統代理，或確認用戶端能正確還原系統設定。

符合以上條件，才算完成從匯入訂閱到實際瀏覽的完整驗證流程。之後若只有特定網站或應用程式異常，請優先檢查它的規則、解析與連線記錄，不必從重新安裝用戶端開始。基本操作請參閱系統代理設定說明，詳細排查方式請見連線檢查文件。