Clash 已連線卻無法開啟網頁：系統代理、連接埠衝突與規則排查清單

先分清「用戶端正在執行」與「要求已經透過代理」

先開啟用戶端的「連線」和「日誌」頁面，再重新載入無法開啟的網頁。視窗顯示「執行中」、系統匣圖示亮起，或節點顯示延遲數字，只能表示部分環節正常，無法證明瀏覽器這次要求已經透過代理，更不能證明目標網站可以存取。

Clash 是代理核心與用戶端的常見統稱；Clash Meta 後續以 mihomo 的名稱持續維護。不同圖形化用戶端的開關位置不盡相同。以下以 Windows 11 的系統設定路徑、常見用戶端的「系統代理」、「代理模式」、「連線」、「日誌」功能，以及 mihomo 設定欄位為參考；連接埠範例統一使用 7890，實際操作請以目前的設定為準。

1. 記錄目前狀態：記下用戶端名稱、核心版本、目前使用的設定檔名稱、目前節點、混合連接埠與 TUN 開關狀態。
2. 排除基本斷網問題：關閉系統代理與 TUN 後，嘗試開啟平常可直接連線的網站。若仍無法連線，先檢查 Wi-Fi、閘道器、寬頻認證或校園網路登入狀態。
3. 縮小測試範圍：只保留一個用戶端執行，使用同一個目標網址反覆測試，每次只調整一個項目。
4. 查看連線記錄：重新載入後沒有連線記錄，優先檢查流量入口；有記錄但連線失敗，再檢查出站節點、規則與 DNS。

檢查系統代理：瀏覽器是否連到本機連接埠

確認位址、連接埠與代理例外清單

在 Windows 11 開啟「設定」→「網路和網際網路」→「Proxy」→「手動 Proxy 設定」→「編輯」。一般瀏覽器的 HTTP 代理伺服器位址應與用戶端的監聽位址相符；若用戶端只監聽本機，通常填入 127.0.0.1，連接埠則填寫實際的 HTTP 連接埠或混合連接埠，例如 7890。不要把控制面板的 API 連接埠當成代理連接埠。

在 macOS 開啟「系統設定」→「網路」→目前使用的網路服務→「詳細資訊」→「Proxy」，檢查網頁代理與安全網頁代理。不同系統版本的名稱可能略有差異。若啟用自動代理設定，也要確認 PAC 位址可以存取，且指令碼規則沒有讓目標網域直接連線。另請檢查代理例外清單，避免目標網域被意外排除。

• 用戶端重新啟動後，請再次確認系統設定；舊程序結束時可能還原成另一組代理值。
• Firefox 可在「設定」→「一般」→「網路設定」→「設定」中選擇「使用系統代理設定」，或自行明確填入代理設定。
• 暫時停用瀏覽器代理擴充功能，避免擴充功能覆寫系統代理。受企業管理的瀏覽器也可能受到管理政策限制。
• 系統代理不會接管所有應用程式。終端機工具、遊戲和部分商店應用程式可能需要個別設定，或在確認一般代理正常後改用 TUN。

使用明確指定代理的要求，排除瀏覽器設定問題

在 Windows PowerShell 中使用 curl.exe，避免舊版 PowerShell 的 curl 別名造成干擾。以下指令會透過本機 HTTP 代理送出一次要求，總逾時時間為 15 秒；example.com 僅供連線測試，接著請換成實際無法連線的網站再測一次。

curl.exe -v --connect-timeout 5 --max-time 15 --proxy http://127.0.0.1:7890 https://example.com/ -o NUL

macOS 與 Linux 可執行對應指令：

curl -v --connect-timeout 5 --max-time 15 --proxy http://127.0.0.1:7890 https://example.com/ -o /dev/null

如果指令能取得 HTTP 回應，但瀏覽器仍無法連線，請優先檢查瀏覽器擴充功能、獨立代理設定與快取連線。如果出現連線 127.0.0.1:7890 遭拒，先檢查本機監聽狀態，不要立刻更換訂閱。即使收到 403，也應與網路逾時分開判斷：這表示已有 HTTP 服務回應，但目標網站或中間設備可能拒絕了存取。

檢查連接埠占用：確認監聽程序是目前使用的核心

mixed-port 提供 HTTP 與 SOCKS 混合代理入口；external-controller 則用於控制 API，兩者用途不同。範例設定中的 9090 不能直接填入瀏覽器代理欄位。以下設定片段僅供核對欄位，請勿用來覆蓋完整訂閱內容：

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

在 Windows PowerShell 中查看監聽程序：

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

將輸出中的 OwningProcess 數字填入 Get-Process -Id，即可查看程序名稱。macOS 可使用第一個指令，Linux 可使用第二個；部分程序資訊需要相應權限才能顯示。

lsof -nP -iTCP:7890 -sTCP:LISTEN
ss -ltnp 'sport = :7890'

不要只憑連接埠號碼就強制結束不明程序。請先確認程序名稱與來源。若將混合連接埠改為 7891，也必須同步更新系統代理、瀏覽器獨立代理設定和終端機環境變數，否則要求仍會送往舊連接埠。

檢查節點：延遲數字不代表目標網站可以連線

開啟「代理」頁面，找到實際負責出站連線的策略組。策略組可能指向另一個組，也可能選擇了 DIRECT；介面上反白某個節點，不代表目前連線一定經過該節點。回到「連線」詳細資訊，確認要求網域、策略鏈與最終出站節點。

1. 在同一個策略組中手動選擇另一個節點，關閉舊連線後重新載入目標網頁。
2. 暫時切換至全域模式，並在全域策略組中明確選擇一個代理節點，再送出相同要求測試。
3. 若全域模式可用、規則模式失敗，請繼續檢查規則命中情況；若兩種模式都失敗，優先檢查節點與本機網路。
4. 前往服務供應商的帳戶頁面，確認訂閱是否到期、流量是否用盡，以及節點是否有維護公告。

全域模式只會改變進入核心後的路由選擇，不會自動讓所有應用程式的流量都進入核心。測試完成後請恢復規則模式。節點延遲通常是依據用戶端設定的測試 URL 測得，只能證明該次測試要求當時已完成；不能只憑 150 ms 的數字，就推斷影片、登入或特定網站也能正常使用。

檢查規則判斷錯誤：查看第一條命中的規則

規則模式會依序比對，第一條命中的規則決定連線路徑。常見問題包括目標網域被納入直連規則、範圍較廣的規則排在前面，或規則指向的策略組最後選到了無法使用的節點。不要只看設定檔結尾的 MATCH，應以該次連線詳細資訊中的規則記錄為準。

以下範例說明規則順序的影響。此處的 DIRECT 和 REJECT 是內建策略；這段內容不是完整設定，也不應直接加入目前使用的訂閱：

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,REJECT

在此片段中，example.com 及其子網域會優先符合直連規則，其他未符合的要求則會遭到拒絕。如果將兩行順序對調，前面的 MATCH 會攔下所有要求，後面的網域規則便無法生效。這就是「規則明明寫了卻沒有作用」的常見原因。

• 命中 DIRECT 後仍失敗：先確認目標網站是否適合直接連線；若需要代理，請將更精確的網域規則排在相關的寬泛規則之前。
• 命中 REJECT：檢查廣告過濾或自訂封鎖規則，確認是否誤擋登入、驗證碼或靜態資源網域。
• 命中代理組仍然失敗：追蹤該組最後選用的節點，不要只看策略組名稱判斷。
• 更新設定後問題再次出現：使用用戶端支援的覆寫或合併功能儲存自訂規則，避免直接修改訂閱更新時會被覆蓋的內容。

修改規則後，請關閉相關的舊連線再測試。瀏覽器可能重複使用已建立的 HTTP/2 連線，單純重新載入不一定會重新判斷路由。同一個頁面也可能同時要求多個資源網域；如果主頁面正常，但圖片或登入功能失敗，請檢查失敗資源的連線記錄。

檢查 DNS 與 TUN：區分網域解析問題和流量接管問題

先辨識 DNS 錯誤

若出現 Could not resolve host、no such host 或日誌中的 DNS 逾時，請先確認由哪個元件負責解析網域。瀏覽器安全 DNS、系統 DNS 和 mihomo 的 DNS 模組可能使用不同路徑。Windows 的 nslookup example.com 預設測試系統所選 DNS 的回應，並不代表 mihomo 內部解析一定正常；請搭配實際要求的日誌判斷。

啟用 fake-ip 時，看到 198.18.0.0/15 範圍的位址不一定代表異常。這可能是核心替網域配置的映射位址，需要由代理接管後才能還原網域資訊。若關閉 TUN 後，瀏覽器仍快取這類位址，就可能持續連線失敗。請先恢復一致的 DNS 與流量路徑，再重新啟動瀏覽器；Windows 可視需要執行 ipconfig /flushdns 清除系統快取。

不要把 nameserver、fallback 全部換成隨意蒐集的公共位址。請先確認上游 DNS 的位址與傳輸方式在目前網路中可以使用；若上游使用網域名稱，也要考量啟動時的解析路徑。可暫時關閉瀏覽器安全 DNS 作為對照，確認問題後再依實際需求恢復。

確認一般代理正常後，再單獨測試 TUN

TUN 透過虛擬網路介面接管流量，比系統代理涉及更多環節。若明確指定代理的指令可以成功，開啟 TUN 後卻全網無法連線，請優先檢查用戶端服務權限、虛擬介面、路由與 DNS 劫持，不要繼續盲目更換節點。

1. 關閉其他 VPN、虛擬網路與代理用戶端，只保留目前使用的工具，排除路由衝突。
2. 確認用戶端要求的服務模式或權限已正確啟用，並查看 TUN 啟動日誌是否有錯誤。
3. 先關閉 TUN，單獨測試系統代理；再開啟 TUN，依用戶端建議設定系統代理，避免重複路徑影響判斷。
4. 使用 route print（Windows）或 ip route（Linux）查看切換前後的路由；企業網路需要保留的內部路由應另外處理。

mihomo 的 TUN 設定可使用 dns-hijack 接管符合條件的 DNS 要求，但常見的 53 連接埠劫持不代表能接管所有加密 DNS。瀏覽器使用的 DoH 屬於 HTTPS 流量，必須配合實際規則與 DNS 方案處理。

依錯誤訊息完成排查：記錄可重現的最小案例

發生憑證錯誤時，先同步系統日期與時間，確認網路是否需要認證，以及機構網路是否部署了 HTTPS 檢查。不要把略過憑證驗證當成一般修復方式。遇到 403 或 429 也不要反覆重新整理：代理連線可能已經建立，問題可能出在網站存取政策或要求頻率限制。

需要進一步求助時，請提供用戶端與核心版本、系統版本、重現時間、目標網域、系統代理與 TUN 狀態、明確指定代理的測試結果，以及相近時間的錯誤日誌。與其只說「瀏覽器無法開啟」，不如描述「本機連接埠可連線，規則命中某個策略組，但最終節點出站逾時」，這樣更容易判斷處理方向。