一、先釐清「核心正在執行」與「網頁可以連線」的差別

用戶端顯示正常，通常只代表核心已啟動，或系統代理開關已開啟。節點延遲測試成功，也只能證明當下的測試請求有完成；瀏覽器連線到另一個網域時，可能會套用不同規則、策略群組或 DNS 解析路徑。因此，看到「已連線」不代表問題一定出在網站，也不要一次修改連接埠、DNS 和規則。

開始排查前，先記下用戶端名稱、核心類型、目前使用的設定檔、工作模式與本機監聽連接埠。Clash 與 Clash Meta（現稱 mihomo）的設定功能不盡相同，圖形介面的選單也會因用戶端而異。下文會以「系統代理」、「連線」、「日誌」等功能名稱說明，並列出作業系統中的具體路徑。

  1. 確認目前使用的設定檔確實已選取，而不只是成功下載訂閱。
  2. 記下網頁顯示的錯誤，例如 ERR_PROXY_CONNECTION_FAILED、ERR_NAME_NOT_RESOLVED 或連線逾時。
  3. 選一個無法連線的網址作為固定測試目標，每次變更設定後重新送出請求並記錄結果。
  4. 暫時退出其他代理用戶端、瀏覽器代理擴充功能與網路加速工具，避免多個程式同時變更代理設定。

二、關閉代理，確認本機網路是否正常

先關閉用戶端的系統代理與 TUN，再確認系統中是否仍留有手動代理設定。Windows 11 可開啟「設定」→「網路和網際網路」→「Proxy」；macOS 可開啟「系統設定」→「網路」→目前的網路連線→「詳細資訊」→「代理伺服器」。若使用 PAC 自動設定指令碼，也請記下指令碼網址，避免將 PAC 與手動代理混淆。

接著，嘗試連線到目前網路通常可直接存取的網站，並確認 Wi-Fi 是否需要登入驗證。飯店、校園或公共網路若尚未完成驗證，即使用戶端已啟動，也無法繞過本機網路的存取限制。可在終端機執行下列命令，確認能否直接建立 HTTPS 連線：

curl -I --noproxy "*" --connect-timeout 10 https://example.com/

Windows 建議使用 curl.exe，避免舊版 Windows PowerShell 將 curl 解讀成其他命令。此命令只會測試指定網站，測試失敗不代表整個網路都中斷；請再搭配另一個本機可存取的網站或手機熱點確認。若關閉所有代理後，連路由器管理頁面和常用的直連網站都無法開啟，請優先處理網路連線、登入驗證或系統網路設定。

三、檢查系統代理位址與本機監聽連接埠

先確認連接埠，再開啟系統代理

在用戶端設定中找到 HTTP 連接埠或混合連接埠，並逐一比對作業系統中的代理位址。例如，若設定實際監聽 mixed-port: 7890，同一台電腦上的手動代理可設為 127.0.0.1:7890。此處的 7890 僅為範例，並非所有用戶端的固定預設值；若介面顯示 7897，命令與系統設定都應使用實際值。

HTTP 代理連接埠不可任意與僅支援 SOCKS 的連接埠互換。若系統設定指向已停止的連接埠，瀏覽器通常會直接顯示代理連線失敗。可略過系統代理設定，明確指定 HTTP 代理進行測試：

curl -I --proxy http://127.0.0.1:7890 --connect-timeout 10 https://example.com/
  • 明確指定代理後成功，瀏覽器仍失敗：檢查系統代理是否遭其他程式變更、瀏覽器擴充功能是否覆寫設定，以及瀏覽器是否使用獨立的代理設定。
  • 立即顯示無法連線至 127.0.0.1：先檢查核心是否已啟動、連接埠是否正在監聽；此時還不必調整遠端節點。
  • 顯示 200 Connection established 後仍然失敗：這只代表 HTTP 代理接受了通道請求，不代表後續 TLS 交握與網頁回應都已成功。
  • 回傳 407：檢查本機代理是否設定了身分驗證，不要將驗證失敗誤判為節點逾時。

確認佔用連接埠的確實是目前使用的用戶端

在 Windows 終端機執行下列命令，查看監聽狀態與處理程序編號；macOS 可使用第二個命令查看監聽中的處理程序：

netstat -ano | findstr ":7890"
lsof -nP -iTCP:7890 -sTCP:LISTEN

查看 Windows 輸出時，請留意本機位址與 LISTENING 狀態，再前往「工作管理員」→「詳細資料」，依 PID 核對處理程序。輸出中出現連接埠號碼，不代表監聽狀態正常。若連接埠遭舊版用戶端佔用，請正常退出舊程式，或為目前用戶端改用閒置連接埠，並同步更新系統代理設定。若僅供本機使用，通常不必開啟「允許區域網路連線」。

四、從連線紀錄找出規則與策略群組

維持規則模式，開啟用戶端的「連線」或「日誌」頁面，再重新載入無法開啟的網頁。記下目標網域、符合的規則、策略群組與最終出口。既有的長連線可能仍會使用舊出口，因此切換節點後，請關閉對應連線或重新啟動瀏覽器再測試。若完全沒有紀錄，先確認日誌沒有篩除目標請求；若仍然沒有，請回頭檢查代理入口。

觀察到的結果優先檢查項目下一步
目標連線符合 REJECT網域規則、規則集與廣告封鎖規則找出符合的規則項目，確認是否誤擋登入、驗證或靜態資源網域
目標連線走 DIRECT確認此網站是否適合目前的網路直連檢查符合的網域規則與最後的預設規則
連線進入代理群組，但仍然逾時群組中實際選取的節點與巢狀策略群組改用另一個可用出口，重新測試相同網址
只有部分資源載入失敗圖片、指令碼與 API 各自使用的出口依失敗的網域逐一檢查，不要只看網頁的主網域

Clash 會依序比對規則，並套用第一條符合的規則。若前面有範圍過大的 DOMAIN-SUFFIX 規則，後續較精確的規則可能永遠不會生效。若懷疑是規則問題，可暫時切換至全域模式，並明確選取一個可用節點作為對照：若相同網址在全域模式可用、規則模式卻無法連線，請優先比對出口與符合的規則紀錄，而不是長期使用全域模式掩蓋設定問題。

五、分辨系統 DNS 與核心 DNS 問題

瀏覽器顯示網域解析失敗，不一定是系統 DNS 出錯。系統解析器、瀏覽器的安全 DNS、核心 DNS 與遠端節點都可能參與解析；實際路徑取決於代理方式與設定。先執行以下命令，檢查系統解析器對目標網域的回應：

nslookup example.com

nslookup 成功，只能證明這次系統端查詢收到回應，無法證明核心使用的上游 DNS 正常；反過來，系統查詢失敗，也不代表由代理端解析網域的請求一定會失敗。使用 HTTP 代理存取 HTTPS 時，用戶端通常會收到目標網域；SOCKS 測試中的 socks5:// 與 socks5h:// 涉及不同的網域解析位置，比較結果時請留意這項差異。

依實際解析路徑逐層檢查

  1. 在日誌中搜尋 DNS、resolve、timeout，核對出錯的網域與上游位址，不要只看最後一筆逾時紀錄。
  2. 若已啟用 DoH 或 DoT，請確認上游位址本身可以連線；若上游使用網域，也要檢查其引導解析是否造成循環依賴。
  3. 暫時關閉瀏覽器的「安全 DNS」進行比對，測試後再還原設定。瀏覽器自行建立的加密 DNS 連線，可能採用不同於系統解析器的路徑。
  4. 使用 fake-ip 時，看到 198.18.0.0/15 範圍內的對應位址，不代表解析一定出錯；還要確認後續連線是否由核心接管，並正確還原網域。

在 Windows 變更 DNS 後，可執行 ipconfig /flushdns 清除系統快取；用戶端核心與瀏覽器的快取可能仍須分別清除。請勿以「直接連線到網站 IP」取代完整測試：HTTPS 網站需要透過網域進行憑證驗證、SNI 與虛擬主機選擇，直接連線 IP 失敗可能與 DNS 無關。

六、確認系統代理正常後，再檢查 TUN

若明確指定代理與瀏覽器的系統代理都正常，只有開啟 TUN 才無法上網，請將排查重點轉向虛擬網卡、路由與 DNS 接管。TUN 用來接管路由至虛擬網卡的 IP 流量，但不保證每個應用程式、每種網路環境都能自動取得正確設定。權限不足、驅動程式異常或其他 VPN 安裝的路由，都可能導致流量走錯介面。

  • 權限與服務：確認已完成用戶端要求的服務模式設定或系統管理員授權，並查看核心是否明確回報 TUN 啟動成功。
  • 路由衝突：暫時中斷其他 VPN，再使用 Windows 的 route print 或 macOS 的 netstat -rn 比較開啟前後的路由。
  • DNS 接管：檢查設定中的 dns-hijack 是否符合實際 DNS 路徑；不要假設接管一般 53 連接埠就能接管瀏覽器的 DoH。
  • IPv6 路徑：若網域同時回傳 A 與 AAAA 紀錄，請分別檢查 IPv4、IPv6 的路由與接管狀態，不要只憑 IPv4 測試成功就認定所有流量都正常。

若網頁可以開啟，但大型圖片或下載容易中斷，可進一步檢查封包遺失、MTU 與通訊協定差異；不過，這些項目應留待代理入口、規則與 DNS 都確認正常後再查。沒有明確依據就直接修改 MTU，容易增加變因，也會讓原本的問題更難重現。

七、只有特定網站無法連線時，檢查上游與瀏覽器

若不同瀏覽器都無法連線到同一個網站，但其他網站正常，請換一個節點連線到相同目標，並檢查訂閱狀態、節點通訊協定參數與系統時間。系統時間不準可能導致 TLS 憑證驗證失敗；訂閱能更新只代表成功取得設定，無法證明每個節點仍可使用。

若只有單一瀏覽器異常，請用未啟用擴充功能的新設定檔進行比對，再檢查獨立代理、安全 DNS、快取與網站權限。無痕視窗仍可能載入部分允許在無痕模式中執行的擴充功能，因此無痕測試不代表已排除所有擴充功能。遇到憑證錯誤時，請記下錯誤代碼與憑證簽發者，不要安裝來源不明的根憑證來消除警告。

節點延遲低但網頁速度慢，也可能與目標網站距離、封包遺失、頻寬或伺服器限速有關。單次延遲測試無法取代實際網頁請求。請在相同網址、相同網路與相同時段進行比對，避免將更換測試目標後的差異歸因於剛才修改的設定。

八、整理排查結果並還原日常設定

排查完成後，請恢復規則模式、撤銷沒有改善問題的暫時變更，並確認系統代理連接埠與用戶端一致，再決定是否啟用 TUN。若關閉用戶端後整台裝置無法上網，請先確認系統是否仍指向已停止監聽的本機代理，而不是立刻重設整個網路。

需要進一步求助時，提供可重現的資訊比只說「已連線但無法開啟網頁」更有幫助。建議依照下列清單整理，並隱去訂閱網址、存取權杖、節點密碼、個人 IP 與其他敏感資訊：

  • 作業系統、用戶端與核心的確切版本，以及使用的是系統代理或 TUN。
  • 無法連線目標的網域與瀏覽器錯誤代碼；請勿公開含有登入權杖的完整網址。
  • 本機監聽連接埠、明確指定代理的測試結果，以及直連是否正常。
  • 同一請求符合的規則、策略群組、最終出口，以及相同時段的錯誤日誌。
  • 切換節點、關閉 TUN 或更換網路後，哪些測試結果有所變化。

建議依序檢查：本機網路 → 代理入口 → 監聽連接埠 → 規則出口 → DNS → TUN 與上游。每次只變更一項，並以同一個請求驗證，才能將「看起來正常」的狀態轉化為可解釋的連線結果。