先釐清「已連線」指的是哪一段連線

Clash 用戶端顯示正在執行、節點顯示延遲數值，或系統顯示 VPN 已連線，都不代表從瀏覽器到目標網站的整條連線都正常。正在執行通常只表示核心程序已啟動；節點延遲測試通常只會連線至設定的測試網址；Android 顯示 VPN 圖示，主要表示本機 VPN 服務已建立。網頁連線還會經過應用程式代理設定、本機監聽連接埠、分流規則、節點出口和目標網站，其中任何一環異常，都可能讓網頁一直載入。

以下內容適用於相容 Clash 的用戶端；使用 Clash Meta（現稱 mihomo）核心時，也可依相同順序排查。各用戶端的開關名稱和預設連接埠不盡相同，範例中的 7890 只是待確認的本機混合連接埠，不能直接視為這台裝置的實際設定。

  1. 記下目前的設定名稱、選取的節點、代理模式、HTTP 或混合連接埠，以及系統代理和 TUN 開關的狀態。
  2. 先暫停其他代理用戶端和 VPN。桌面版先關閉 TUN，只透過系統代理進行排查，以減少路由與 DNS 接管帶來的變數。
  3. 分別開啟一個原本可直接連線的網站，以及一個需要透過目前代理線路連線的網站，記下瀏覽器顯示的完整錯誤碼。
  4. 每次只修改一個項目，再重新開啟同一個網址。確認有效後保留變更；無效就還原，避免同時改動連接埠、DNS 和規則。

第一步：檢查訂閱是否到期，以及設定是否確實載入

訂閱更新成功，不代表節點可用

前往用戶端的訂閱或設定頁面，確認目前啟用的是哪份設定，而不只是檢查清單中最近更新的項目。更新成功表示訂閱內容已下載，不代表帳戶仍有可用流量，也不保證節點伺服器目前可連線。反過來說，訂閱更新失敗時，用戶端可能繼續使用快取中的設定，因此清單裡仍看得到節點。

  • 確認帳戶狀態：前往訂閱服務商的帳戶頁面，查看到期日、剩餘流量和裝置數量限制；不要只依據用戶端顯示的快取數值判斷。
  • 檢查回應狀態：若記錄中出現 HTTP 401 或 403，請檢查授權、帳戶狀態和服務商的存取限制；若出現 404，則確認網址是否已失效或複製不完整。單看狀態碼無法確定問題原因。
  • 檢查格式：若出現 YAML 解析錯誤，可能是下載到登入頁、錯誤頁，或內容不是目前用戶端支援的 Clash 設定格式。
  • 檢查核心：如果設定包含目前核心不支援的協定或欄位，應改用服務商明確支援的訂閱格式，或改用相容核心；反覆重新匯入無法解決這類問題。

固定使用單一節點，排除自動選擇造成的干擾

在目前的策略組中手動選取一個節點，並確認請求實際經過該組。先測試節點 A，再測試節點 B，每次都開啟同一個網站。延遲測試通過但網頁仍無法開啟，可能是測試網站可連線、目標網站無法連線，也可能是目標網站的規則指向另一個策略組。請一併查看連線記錄中的出口路徑，不能只靠延遲數字判斷。

若所有節點都無法連線，但直連網站正常，請優先檢查訂閱帳戶、節點網址解析和節點連接埠是否可連線。不要將訂閱網址貼到不熟悉的線上轉換或檢測網站；網址通常含有存取憑證，分享截圖時也應遮住權杖和 QR Code。

第二步：確認混合連接埠正在監聽，排除連接埠衝突

如果系統代理指向 127.0.0.1:7890，但核心實際監聽的是 7897，瀏覽器就無法透過該入口轉送流量。另一種常見情況是舊版用戶端仍占用連接埠；新版用戶端介面雖已啟動，核心卻因綁定失敗而無法提供代理服務。先確認目前執行設定中的 mixed-port 或 HTTP port，再檢查記錄是否出現 address already in use。

在 Windows PowerShell 中執行以下命令，檢查範例連接埠 7890。若使用的連接埠不同，請先將命令中的數字換成實際值。

Get-NetTCPConnection -State Listen -LocalPort 7890 |
  Select-Object LocalAddress, LocalPort, OwningProcess

若沒有監聽結果，請檢查核心是否已啟動、設定是否載入失敗；查到處理程序 ID 後，再用以下命令確認該程序屬於哪個應用程式。不要直接結束不明程序，也不要為了修復本機代理而將監聽位址改成所有網路介面。

Get-Process -Id (Get-NetTCPConnection -State Listen -LocalPort 7890).OwningProcess

略過瀏覽器，直接測試代理入口

使用 Windows 內建的 curl.exe，明確指定本機 HTTP 代理。macOS 或 Linux 可使用 curl 搭配相同參數。以下網址僅用來確認 HTTPS 請求能否完成，不適合作為節點速度基準。

curl.exe --noproxy "" -x http://127.0.0.1:7890 -I --connect-timeout 10 --max-time 20 https://example.com/
測試結果優先判斷下一步
立即顯示無法連線至本機連接埠監聽位址或連接埠錯誤，核心未啟動重新檢查監聽程序和執行設定
本機已連線，之後逾時出口節點、規則或解析流程異常比對同一時間的核心記錄
收到目標網站的 HTTP 回應標頭該目標的明確代理連線可用檢查瀏覽器和系統代理設定
收到代理驗證錯誤本機入口已設定驗證確認驗證設定及用戶端是否支援

HTTPS 請求中只看到 200 Connection established，不一定表示目標網頁已成功回應；還要檢查後續的 TLS 交握和目標網站回應。目標網站回傳 403 或 429 也不代表代理已中斷，可能是網站的存取政策或流量限制所致。

第三步：確認系統代理與瀏覽器設定一致

如果明確指定代理的測試成功，但瀏覽器仍無法開啟網頁，請確認瀏覽器是否真的使用相同入口。系統代理不會透明接管整台裝置的流量；應用程式可能忽略系統設定，也可能被擴充功能、PAC 指令碼或自訂代理設定覆蓋。

  • Windows 11：開啟「設定」→「網路和網際網路」→「Proxy」，檢查手動代理位址、連接埠，以及是否啟用了設定指令碼。使用用戶端的系統代理開關時，應確認此處顯示的設定，而不只是看系統匣圖示。
  • macOS：開啟「系統設定」→「網路」→目前使用的網路服務→「詳細資訊」→「代理伺服器」。確認 HTTP、HTTPS 或自動代理設定與目前方案一致，並移除已失效的 PAC 網址。
  • Firefox：開啟「設定」→「一般」→「網路設定」→「設定」，確認是否選用系統代理設定，或手動指定了其他代理。
  • Android：通常由用戶端透過 VPN 服務接管流量，不能直接照搬桌面系統代理的檢查步驟。請檢查每個應用程式的代理清單，確認瀏覽器未遭排除，並留意是否有其他 VPN 搶占連線。

暫時停用瀏覽器代理擴充功能後再試，並完全關閉瀏覽器再重新開啟，避免重用舊連線。Windows 中執行 netsh winhttp show proxy 查詢的是 WinHTTP 代理，不代表所有瀏覽器使用的系統代理狀態，不能只靠這項結果判斷。

第四步：檢查規則命中結果和實際出口策略

在用戶端切換至規則模式後，開啟「連線」或相應的請求清單，再造訪一次無法開啟的網站。記下目標網域、命中的規則、所選策略組和最後使用的節點。Clash 規則通常依序比對，前面的寬泛規則可能先命中，讓後續的網域規則無法生效。

  1. 確認目標請求有出現在連線清單中。若沒有記錄，優先確認應用程式是否未走代理、重用了既有連線，或由其他網路工具接管。
  2. 如果最後的出口是 DIRECT，請確認該網站是否應直接連線，以及網域規則是否漏掉登入、圖片或 API 網域。
  3. 如果最後的出口是 REJECT，請檢查封鎖規則是否誤擋，不要直接刪除所有規則。
  4. 如果流量經過代理組，請展開群組選項，確認沒有選到不可用的節點或 DIRECT。
  5. 暫時切換至全域模式，手動選取已測試過的節點，再開啟同一個網址；比對完成後，切回規則模式。

如果全域模式能開啟網頁、規則模式卻不行，請繼續比對兩次請求的實際出口差異，不要把「全域模式可用」當成永久解法。全域模式會改變大量連線的出口，可能影響本機服務、工作網路和帳戶登入。如果兩種模式都無法連線，就繼續檢查節點和 DNS 解析，不必反覆新增網域規則。

自訂規則應透過用戶端支援的覆寫或合併機制保存。直接修改訂閱產生的檔案，下一次更新時可能會被覆蓋。先保留最精簡、針對性明確的規則，再確認網頁所需的 API 網域；避免使用範圍過大的網域後綴規則，影響不相關的流量。

第五步：分辨 DNS 污染、解析失敗與 Fake-IP 的正常運作

瀏覽器顯示解析失敗，不一定是 DNS 污染。上游 DNS 逾時、加密 DNS 伺服器無法連線、節點網域無法解析，或瀏覽器的安全 DNS 與用戶端使用不同解析路徑，都可能出現類似情況。先查看記錄中解析失敗的是目標網站網域，還是代理節點本身的網域。

先確認目前 DNS 查詢經過哪條路徑

在 Windows 中可使用以下命令查看系統預設 DNS 的查詢結果。這只反映該次系統查詢，不能代表瀏覽器、Clash 內建 DNS 或遠端代理的解析結果。

nslookup example.com
ipconfig /flushdns

第二個命令會清除 Windows DNS 用戶端快取，但不會一併清除瀏覽器快取或核心 DNS 快取。變更 DNS 設定後，應依用戶端功能重新載入設定或重新啟動核心，並重新建立瀏覽器連線。不要只因兩台 DNS 回傳不同 IP 就認定遭到污染；CDN 本來就可能依狀況回傳不同結果。

Fake-IP 回傳虛擬位址，不代表網域解析錯誤

使用 Fake-IP 模式時，用戶端可能回傳 198.18.0.0/16 範圍內的虛擬位址，實際範圍依設定而異。這個位址用來記錄網域與連線之間的對應關係，不是目標網站的真實伺服器位址。單看這個位址不能判定故障；應確認該連線是否正確交由用戶端接管，以及核心是否保有對應的映射。

  • 如果只有特定應用程式異常，先確認它是否使用獨立 DNS、快取了舊的 Fake-IP 位址，或繞過代理連線。
  • 若記錄顯示上游解析逾時，請確認 nameserver 中的伺服器能否從目前網路連線；不要一次加入大量來源不明的 DNS 位址。
  • 若節點使用網域名稱，請檢查解析是否形成「必須先連上節點才能使用 DNS，卻又必須先解析才能連上節點」的循環；mihomo 可依設定需求使用 proxy-server-nameserver 指定節點網域的解析器，舊版核心的相容性則需另外確認。
  • 若瀏覽器啟用了安全 DNS，可暫時關閉並進行一次比對；測試後依實際需求恢復設定，並記下是哪一條解析路徑造成差異。

更換 nameserver 或 fallback 前，先備份原有設定。fallback 是否啟用，以及其結果如何參與選擇，取決於核心與過濾設定；它不是簡單的「第一個失敗才改用第二個」。遇到解析問題時，請根據記錄和目前核心的文件調整，不要直接用來源不明的範例取代整段 DNS 設定。

第六步：只有開啟 TUN 才失敗時，檢查路由與 DNS 接管

如果關閉 TUN、使用明確指定的代理時一切正常，但開啟 TUN 後就無法連線，問題範圍便縮小至虛擬網卡、權限、路由、DNS 接管或與其他 VPN 的衝突。TUN 能接管哪些連線，取決於路由、排除項目及平台實作；開啟 TUN 不代表所有應用程式都一定會走代理。

  1. 確認用戶端已取得目前平台所需的服務或網路權限，並檢查啟動記錄是否出現建立裝置或新增路由失敗的訊息。
  2. 暫停其他 VPN、網路加速工具，以及重複執行的 Clash 用戶端；若是工作裝置，應依管理規定處理安全軟體和企業 VPN。
  3. 檢查是否設定了自訂路由排除或每個應用程式的略過設定，並確認發生問題的應用程式和目標位址沒有被排除。
  4. 確認 dns-hijack 設定符合目前使用的核心。接管傳統 DNS 連接埠，無法直接解密應用程式自行發出的 HTTPS DNS 請求。
  5. 恢復成單一且容易判讀的流量接管方案後再測試。排查問題時，避免同時啟用系統代理、多個 VPN 和複雜的路由覆寫。

如果小型網頁正常，只有較大的網頁或下載會停住，排除節點和網站因素後，再考慮 MTU 或路徑問題。不要一開始就修改 MTU；先記下原值，一次只調整一個參數，使用相同請求進行比較，若沒有改善就還原。

整理排查結果：以最少必要資訊定位問題

完成以上步驟後，應能判斷問題出在設定無效、本機入口未監聽、應用程式繞過系統代理、規則誤判，或節點與 DNS 解析路徑異常。若仍需尋求協助，提供以下資訊，比只傳一張「已連線卻無法開啟網頁」的截圖更有助於判斷。

  • 作業系統、用戶端名稱與確切版本、核心名稱與版本；可從用戶端的「關於」頁面或啟動記錄查詢。
  • 實際監聽的連接埠、系統代理和 TUN 狀態，以及問題是否只發生在某個瀏覽器。
  • 同一網址在明確指定代理、規則模式和全域模式下的測試結果，以及測試的確切時間。
  • 失敗請求命中的規則、策略組及相關錯誤記錄；請遮蔽帳戶資訊、訂閱權杖和敏感位址。

最後，還原暫時調整的代理模式、瀏覽器安全 DNS 和記錄層級，只保留已確認有效的變更。若需重新安裝用戶端，請先備份本機覆寫設定和規則；重新安裝無法解決訂閱到期、節點失效或網站拒絕存取。