Clash 已連線卻無法上網？從連接埠到規則的逐項檢查清單

先釐清：核心執行、節點測速與網頁連線

Clash 客戶端顯示「已連線」或服務正在執行，只能表示某個執行環節已啟動。瀏覽器請求仍須經過應用程式代理設定、本機監聽連接埠、規則選擇、節點連線及目標網站。節點測速顯示毫秒數，也只代表測速網址當時可連線，不代表所有網站和通訊協定都能正常使用。

本文以桌面客戶端搭配 mihomo 核心的常見組合為例。不同客戶端的設定名稱可能不同，請以介面實際顯示的監聽連接埠和生效設定為準。先記下客戶端名稱、版本、核心版本、目前設定名稱及故障發生時間；不要一開始就同時重新安裝客戶端、更換訂閱並修改 DNS。

建立三項可重現的觀察指標

• 故障範圍：是所有網站都無法連線，還是只有特定網域失敗？是只有瀏覽器出問題，還是終端機及其他應用程式也受影響？
• 請求入口：目前使用系統代理、瀏覽器代理擴充功能，還是 TUN 模式？是否也啟用了其他 VPN？
• 現場證據：重新整理頁面時，在客戶端的「連線」清單搜尋目標網域，並在「日誌」中查看同一時間的錯誤。

第一步：確認瀏覽器確實使用系統代理

以 Clash Verge Rev 常見介面為例，在「設定」→「系統代理」確認開關狀態，再到作業系統檢查實際代理位址。只在客戶端選取節點，不會自動讓所有應用程式都使用該節點；系統代理也無法接管所有不遵循系統設定的應用程式。

1. 在客戶端查看實際的「混合連接埠」。例如介面顯示 7897，本機代理位址就應為 127.0.0.1:7897。其他客戶端可能使用 7890，請勿直接照抄預設值。
2. Windows 11 開啟「設定」→「網路和網際網路」→「Proxy」，查看「使用 Proxy 伺服器」的位址和連接埠。請注意，自動設定指令碼也可能影響實際連線路徑。
3. macOS 開啟「系統設定」→「網路」→目前連線的網路→「詳細資訊」→「代理伺服器」，確認網頁代理伺服器與安全網頁代理伺服器是否指向預期位址。
4. Firefox 開啟「設定」→「一般」→「網路設定」→「設定」，確認使用系統代理，或檢查手動代理設定。其他瀏覽器的代理擴充功能也可能覆寫系統設定。

排查時先暫時停用瀏覽器代理擴充功能，只保留一個明確的代理入口。請勿將 HTTP 混合連接埠填入 SOCKS 專用連接埠，也不要把控制器連接埠當作流量入口：external-controller 用於管理介面，不負責代理網頁請求。

使用明確指定代理的請求，繞過瀏覽器設定

假設目前混合連接埠確實是 7897，請在 Windows PowerShell 執行下列命令。這裡使用 curl.exe，避免部分 PowerShell 環境中的同名別名影響參數解析；macOS 和 Linux 則可將命令名稱改為 curl。

curl.exe --noproxy "" --proxy http://127.0.0.1:7897 --connect-timeout 10 --max-time 20 -I https://example.com/

接著將測試網址換成實際無法開啟的網站。若明確指定代理的請求成功、瀏覽器卻失敗，請優先檢查瀏覽器擴充功能、系統代理、快取連線或瀏覽器本身的安全 DNS 設定，不必立刻更換節點。若回應為 403 或 405，表示已收到 HTTP 回應，但網站可能限制存取或不接受 HEAD 請求；可移除 -I 再比較，不能直接判定代理未連線。

第二步：確認混合連接埠監聽狀態與連接埠衝突

若明確指定代理的請求立即顯示無法連線至 127.0.0.1，請先檢查本機監聽狀態。此時請求尚未抵達節點，切換遠端伺服器通常無濟於事。Windows 可在 PowerShell 中執行：

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

將結果中的處理程序編號代入 Get-Process -Id 1234，確認連接埠是否由目前使用的核心占用。此處的 1234 僅為命令格式範例，請替換成查詢結果。macOS 可執行下列命令查看監聽中的處理程序：

lsof -nP -iTCP:7897 -sTCP:LISTEN

若需要變更連接埠，可選擇尚未被占用的連接埠，例如從 7897 改為 17897，再讓核心重新載入設定。接著同步檢查系統代理、瀏覽器擴充功能及終端機的 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY。若只修改客戶端、卻保留舊入口，仍會連到錯誤的連接埠。

第三步：比較規則模式與全域模式

確認本機入口正常後，檢查客戶端「代理」頁面的模式選擇。規則模式依規則決定使用哪個策略；全域模式使用全域策略選擇；直連模式則不透過代理節點轉送。這些設定決定流量如何處理，與是否啟用系統代理或 TUN 模式屬於不同層級。

1. 使用規則模式瀏覽目標網站，記下連線詳細資料中的規則、策略群組、最終節點及錯誤訊息。
2. 短暫切換至全域模式，並在全域策略中明確選擇可用節點。若全域策略仍選取 DIRECT 或 REJECT，比較就沒有意義。
3. 再次瀏覽同一個網站。若全域模式可用、規則模式不可用，請優先檢查規則及其指向的策略群組。
4. 測試完成後切回原本的規則模式，避免長期保留臨時診斷設定。

若兩種模式都失敗，請查看日誌是否出現節點連線逾時、驗證失敗、TLS 交握失敗或憑證錯誤。可換另一個節點交叉測試，但請保持目標網址和測試入口不變。節點測速成功但實際網站無法瀏覽，可能與出口限制、目標網站限制或節點通訊協定參數有關，不能只憑延遲值排除節點問題。

第四步：檢查規則順序、策略群組與最終出口

mihomo 通常會由上而下比對規則，符合後便執行對應策略。同一個網域可能先被較前面的規則導向直連或拒絕策略，導致後續正確規則無法生效。排查時應以「連線」詳細資料中的實際命中結果為準，而不是只搜尋設定檔裡有沒有該網域。

先查看連線詳細資料，再修改設定

• 命中 DIRECT：確認是否屬於預期的直連範圍，以及是否有範圍過廣的網域後綴規則或 IP 規則提前命中。
• 命中 REJECT：檢查封鎖規則或外部規則集，確認網站所需的資源網域是否也遭到拒絕。
• 命中代理群組：繼續展開群組選項。群組名稱是「代理」，不代表最終一定會使用遠端節點；它也可能選到直連或另一個群組。
• 落入 MATCH：檢查後備策略；這通常表示前面的規則沒有涵蓋該請求。

以下僅示範規則順序，並非可取代訂閱的完整設定。引用的 PROXY 必須對應現有設定中的節點或策略群組名稱：

rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - GEOIP,LAN,DIRECT
  - MATCH,PROXY

實際網站通常會同時請求登入、靜態資源和 API 網域。若首頁 HTML 成功載入，但頁面一直轉圈，可能是 API 網域命中了另一條規則。開啟瀏覽器開發人員工具的「網路」面板，找出失敗請求的網域，再到客戶端連線清單查詢對應紀錄。

更新訂閱可能會覆蓋直接編輯的訂閱內容。若要長期修正規則，請優先使用客戶端提供的覆寫、合併或擴充設定功能，並確認修改已套用至生效設定。不要將訂閱中現有的節點和策略群組整段替換成網路上的範例。

第五步：分別檢查系統 DNS 與 mihomo DNS

DNS 錯誤通常會顯示網域解析逾時、解析失敗，或解析結果無法用於連線。請先確認由哪個元件負責解析：系統解析器、瀏覽器安全 DNS、核心 DNS，還是遠端代理伺服器。它們不一定使用相同的連線路徑，因此只執行一次 nslookup，無法證明整條代理連線正常。

依入口比對解析結果

1. 執行 nslookup example.com，記下系統使用的 DNS 伺服器和回傳結果，再針對實際故障的網域重複測試。
2. 在客戶端日誌中搜尋目標網域，判斷是核心 DNS 查詢失敗，還是已成功解析、但節點連線失敗。
3. 若只有瀏覽器發生故障，先記下原設定，再暫時調整瀏覽器的「安全 DNS」進行比對測試；測試後請還原設定，或保留已確認有效的設定。
4. 若設定使用加密 DNS，請確認 DNS 伺服器本身可以連線。若改用目前網路無法連線的解析伺服器，只會造成新的逾時問題。

使用 SOCKS 測試時，也要留意 socks5:// 和 socks5h:// 的差異：在 curl 中，後者會讓代理端解析目標網域。若目前的連接埠支援 SOCKS，可執行下列請求進行比對：

curl.exe --noproxy "" --proxy socks5h://127.0.0.1:7897 --connect-timeout 10 --max-time 20 -I https://example.com/

若遠端解析可用、本機解析失敗，請優先檢查本機 DNS 路徑。不過，仍須搭配連線日誌判讀兩種入口的測試結果，不能只根據單次請求就認定唯一原因。

Windows 修正相關設定後，可執行 ipconfig /flushdns 清除系統 DNS 快取，再關閉並重新開啟瀏覽器。清除快取只是最後的整理步驟，不能取代修正錯誤的 DNS 上游、路由或攔截設定。

第六步：分開驗證 TUN、路由與其他 VPN

若明確指定 HTTP 代理後可以瀏覽，但啟用 TUN 後就失敗，問題較可能出在虛擬網路介面、路由或 DNS 接管路徑。TUN 會透過虛擬網路介面接管流量，不要求應用程式遵循系統 HTTP 代理；但服務權限不足、路由衝突，或其他 VPN 同時改寫網路設定，都可能使流量走錯路徑。

• 在客戶端「設定」中確認服務模式或相關服務運作正常，再檢查「TUN 模式」開關。需要服務權限的客戶端，請依照介面提示完成安裝。
• 在網路政策允許的情況下，暫時關閉 TUN，只啟用系統代理，再以相同瀏覽器和網址進行測試。
• 若只有 TUN 模式失敗，請查看生效設定中的 tun.auto-route、tun.dns-hijack 等項目，並檢查是否與其他 VPN 或虛擬網路介面爭用路由。
• 若只有部分 HTTPS 頁面卡住，請搭配日誌和封包擷取檢查 MTU、IPv6 路由等問題；不要把任意 MTU 數值當成通用修正方案。

公司裝置或受管理網路可能要求使用指定的 VPN、憑證和 DNS 政策。此時請聯絡管理員確認相容方式，不要停用安全元件來規避網路管理。一般個人裝置則可先停止重複執行的代理程式，再考慮清除殘留服務。

記錄排查結果並檢查設定是否還原

完成一輪排查後，參考下表快速判斷接下來應處理哪個層級。記下具體錯誤，比只寫「連不上」更有用，也方便在重新啟動或更新訂閱後確認問題是否再次發生。

回報問題時，請提供客戶端和核心版本、作業系統版本、實際混合連接埠、代理模式、TUN 狀態、重現步驟，以及同一時段的錯誤日誌。分享截圖或設定前，請移除訂閱網址、驗證資訊、控制介面金鑰及個人瀏覽紀錄。

恢復使用前，請將暫時啟用的全域模式切回預期模式，確認瀏覽器和終端機沒有殘留舊連接埠，再測試先前無法瀏覽的網站及其登入、圖片和 API 請求。基本設定可參考Clash 設定教學；若要依錯誤類型繼續排查，請前往故障排除頁面。