代理節點逾時但網路正常：訂閱狀態、DNS 與連線路徑檢查順序

一、先區分延遲測試逾時與實際連線失敗

瀏覽器能開啟平時常用的本地網站，但 Clash 用戶端將節點標示為「逾時」，兩者並不矛盾。本機連線正常，只代表某條直連路徑可用；節點延遲測試通常還會經過代理伺服器、協定握手與指定測試網址。任何一段失敗，都可能在介面上統一顯示為逾時。

用戶端負責介面、訂閱與設定管理，核心則負責代理連線、規則與 DNS 等處理。Clash 與 Clash Meta（現多稱為 mihomo）在欄位支援與行為上有所差異，不同用戶端的測試入口、預設 URL 與逾時門檻也不完全相同。排查時應記錄用戶端版本與實際執行的核心版本，而不只是記住應用程式名稱。

二、本機網路檢查：排除入口網站驗證與代理殘留

先儲存目前設定，再關閉用戶端的系統代理與 TUN 接管。如果還有其他 VPN 或代理應用程式，也應在獲得使用許可的前提下退出。關閉介面視窗不一定會停止背景服務，更不一定會清除系統代理，因此要核對系統設定，而不是只看系統匣圖示。

Windows 上確認直連基準

1. 開啟 Windows 11「設定」→「網路和網際網路」→「代理伺服器」，記錄自動設定指令碼與手動代理原本的狀態。由組織下發的設定不要擅自修改。
2. 造訪兩個平時能直連的網站，確認 Wi-Fi 沒有停留在飯店、校園或公共熱點的驗證頁面。能開啟路由器管理頁面，只能證明區域網路連通。
3. 檢查「設定」→「時間與語言」→「日期與時間」，確認日期、時區與時間同步正常。明顯的時鐘偏差可能導致 TLS 憑證驗證失敗。

如果系統已安裝 curl，可在 PowerShell 中執行以下直連請求。Windows 請使用 curl.exe，避免部分 PowerShell 環境將 curl 解讀為其他命令。macOS、Linux 可將命令名稱替換為 curl。

curl.exe --noproxy "*" --connect-timeout 5 --max-time 15 -I https://example.com/

--noproxy "*" 會讓 curl 不使用已設定的顯式代理，但無法繞過仍在執行的 TUN、透明閘道或組織網路政策。這裡的 example.com 只是示範目標，可替換為你確認能直連的網址；單一示範網站無法連線，不代表本機網路中斷。5 秒是連線階段上限，15 秒是本次操作總上限，兩者都不是實測延遲。

三、訂閱狀態檢查：更新成功不等於節點可用

在用戶端目前使用的設定詳細資料中，確認最近一次更新是否成功、節點數量是否符合預期，以及更新後是否真的切換到這份設定。有些用戶端會保留舊設定繼續執行，因此「節點清單還在」不能證明剛才的訂閱更新成功。

• 帳戶狀態：前往訂閱提供方的帳戶頁面，檢查有效期限、剩餘流量、裝置或同時連線數限制。用戶端未顯示用量資訊時，不應據此推斷流量充足。
• 回應狀態：401 或 403 表示授權或存取政策有問題；429 通常需要停止頻繁更新並等待；5xx 則應優先確認伺服器端狀態。
• 回應內容：HTTP 200 也可能回傳登入頁面或錯誤說明。完整 YAML、只含節點的資料與單節點分享連結，不一定由同一個匯入入口處理。
• 更新路徑：部分用戶端允許為訂閱更新選擇直連或代理。若更新所依賴的節點已經失效，就可能出現「更新需要代理、代理又需要新訂閱」的循環。

只有在用戶端明確提供相關設定時，才嘗試更換訂閱更新路徑，接著手動更新一次並查看記錄。不要連續點擊更新，也不要把私人訂閱 URL 貼到公開的線上轉換或診斷服務。URL 中的權杖往往就是存取憑證。

四、節點參數檢查：分開確認連接埠連通與協定握手

選取一個失敗節點，核對其協定、server、port 與驗證參數。使用 TLS、WebSocket 或 gRPC 的節點，還需要核對服務方提供的伺服器名稱、傳輸類型、路徑或服務名稱。Reality 等擴充參數要求核心支援，不能將其他協定的欄位任意移植過來。

先檢查節點伺服器的 TCP 連接埠

以下是 Windows PowerShell 的互動式檢查，執行時輸入目前節點的實際伺服器位址與連接埠。伺服器位址只填主機名稱或 IP，不要加上 https:// 前綴，也不要輸入訂閱 URL。

$nodeHost = Read-Host "輸入節點 server 位址"
$nodePort = [int](Read-Host "輸入節點 port 數值")
Test-NetConnection -ComputerName $nodeHost -Port $nodePort -InformationLevel Detailed

這項檢查應在已關閉 TUN 等接管功能的直連基準下進行，否則結果可能會經過現有代理。TcpTestSucceeded: True 只證明該次 TCP 連線建立成功，不代表密碼、UUID、TLS 或代理協定正確。結果為 False 時，應繼續檢查位址解析、遠端監聽與中間網路限制。

這不是 UDP 節點的通用檢測工具。例如以 QUIC 為基礎的代理協定主要使用 UDP，TCP 連接埠測試失敗不能證明它不可用。同樣地，ping 測試的是 ICMP；伺服器不回應 ICMP，也可能正常提供代理服務。

• 連接埠可以連線，但記錄顯示驗證失敗：核對帳戶與節點參數，先不要調整 DNS。
• 出現憑證名稱不相符：核對伺服器名稱、系統時間與伺服器端憑證，不要把停用憑證驗證當作常規修復方式。
• 只有特定網路失敗：在允許的情況下，使用同一台裝置切換至手機熱點重新測試，記錄差異；一次切換網路的結果仍不足以確定是電信商限制。

五、DNS 排查：分別驗證節點網域與目標網域

代理連線至少可能涉及兩類網域：一類是節點伺服器本身的網域，另一類是瀏覽器要存取的目標網域。前者解析失敗時，連線通常還沒到達節點；後者如何解析，則與協定、DNS 設定及流量進入核心的方式有關。

在前一步的 PowerShell 視窗中執行以下命令，可查看系統解析節點網域的結果。若 server 已經是 IP 位址，可略過此項。

Resolve-DnsName -Name $nodeHost -Type A
Resolve-DnsName -Name $nodeHost -Type AAAA

沒有 AAAA 記錄不一定是異常；有 AAAA 記錄也不代表目前網路的 IPv6 路由可用。若記錄顯示正在連線至 IPv6 位址並逾時，而 IPv4 路徑可用，應檢查 IPv6 連線與核心的位址選擇設定，避免直接將整個系統永久停用 IPv6。

系統解析成功，為什麼核心仍然報錯？

• 核心啟用了自己的 DNS 處理，使用的上游伺服器與系統不同；系統命令成功不能取代核心記錄。
• 加密 DNS 上游本身需要網域解析或代理通道，設定不當可能形成啟動依賴循環。
• 規則或覆寫設定改變了 DNS 路由，目前執行中的設定與訂閱檔案內容並不完全相同。

部分 mihomo 版本支援 proxy-server-nameserver，用於指定解析節點伺服器網域時所使用的上游伺服器；是否採用仍應根據實際版本與完整 DNS 設定確認。未經核對，不適合將它加入所有 Clash 設定。欄位關係可參考設定大全中的 DNS 說明。

調整 DNS 後，依照用戶端支援的方式重新載入設定，並重新建立測試連線。Windows 的 ipconfig /flushdns 只會清除系統 DNS 快取，不會同時清除瀏覽器快取、核心快取與既有連線。

六、代理接管檢查：使用本機連接埠隔離系統設定

確認節點與 DNS 沒有明顯異常後，檢查應用程式請求是否進入核心。系統代理只對遵循該設定的應用程式有效；TUN 透過虛擬網路介面與路由接管流量，需要相應的系統權限，也可能與其他 VPN 的路由衝突。啟用 TUN 不會自動修復失效節點，也不代表所有流量一定會進入代理。

以下命令假設目前執行設定的 HTTP 或 mixed 監聽位址為 127.0.0.1:7890。7890 是教學範例，不是所有用戶端的固定值；請先在目前設定或監聽資訊中確認。若該連接埠需要驗證，請依照用戶端說明在本機提供憑證；分享記錄時要刪除敏感內容。

curl.exe --noproxy "" --proxy http://127.0.0.1:7890 --connect-timeout 5 --max-time 15 -I https://example.com/

這個命令會明確連線至本機代理，不依賴瀏覽器是否採用系統代理。空白的 --noproxy 清單用於覆蓋既有的代理繞過設定。測試時仍應查看連線記錄中的規則命中與最終出口：即使請求進入本機連接埠，也可能依規則分流至 DIRECT，不能直接視為節點已可用的證據。

診斷時可以暫時切換至全域模式並明確選擇測試節點，但要記錄原本的模式，並在測試後恢復規則模式。既有連線可能繼續使用舊出口，因此切換後應關閉舊的測試連線，再發起新的請求。不要長期使用全域模式掩蓋規則設定錯誤。

七、測試網址與記錄：定位逾時發生在哪個階段

如果顯式代理能夠存取實際業務目標，而用戶端延遲測試仍然逾時，應優先檢查測試 URL。測試服務可能故障、限制頻繁請求，或無法從某些出口連線；部分實作還會核對預期的 HTTP 狀態碼。不要只因一個紅色延遲標籤就刪除整份設定。

一次只調整一項測試條件

1. 記錄目前的測試 URL 與門檻；若介面支援，可先將 3000 毫秒暫時調高至 10000 毫秒，再對同一節點測試 3 次。這只是診斷設定，不是建議的延遲標準。
2. 改用你有權存取且回應穩定的小型 HTTPS 目標進行對照。更換目標是為了區分測試端故障，不是挑選一個總能回傳成功的數字。
3. 對不支援 HEAD 的目標，將 curl 命令中的 -I 改為 -o NUL，傳送一般 GET 並捨棄回應本文；macOS、Linux 請使用 -o /dev/null。
4. 同時查看核心記錄與連線記錄，確認存取網域、命中規則、策略組及實際節點一致。

curl 的結束碼 7 通常表示無法建立連線，28 表示操作逾時，60 與憑證驗證失敗有關；它們不是統一的「節點離線」代碼。使用 HTTP 代理存取 HTTPS 時，輸出中的 200 Connection established 只代表 CONNECT 通道階段成功，還需要查看後續 TLS 與目標 HTTP 回應。

記錄中的 lookup、dial tcp、handshake 等上下文有助於定位階段，但不要只擷取最後一行「timeout」。保留同一時間附近的記錄，並標註測試目標。暫時提高記錄層級後應及時恢復，避免長期累積存取記錄。

八、恢復設定與回報清單

完成排查後，恢復原本的規則模式、DNS 設定與接管方式，確認是否需要重新啟用自動策略組。不要把調高逾時、暫時固定節點、暫停 TUN 等診斷動作直接當成最終設定。最終驗證至少應包含一次新建立的網頁連線，以及原本失敗的應用程式情境。

• 環境：作業系統、架構、用戶端版本、實際核心版本，以及問題發生時的網路類型。
• 範圍：全部節點還是單一節點、所有目標還是單一目標、系統代理與 TUN 的表現是否不同。
• 證據：準確的測試時間、使用的連接埠、命中規則、實際出口，以及經過去識別化的錯誤上下文。
• 已執行操作：訂閱更新時間、帳戶狀態核查、DNS 結果、切換網路的對照結果，以及是否已恢復原本設定。

截圖或回報前，應遮蓋訂閱 URL、權杖、密碼、UUID 與不希望公開的伺服器資訊。若同一節點在多個網路下都無法完成握手，可向訂閱提供方提交已去識別化的記錄；若顯式代理正常而用戶端接管異常，則更適合向對應的用戶端專案回報。按照失敗發生的層級尋找維護方，比反覆重灌更容易取得可執行的修復建議。