Clash 已連線卻無法上網：系統代理、DNS 與規則排查清單

先釐清用戶端運作與網頁連線的差異

Clash 用戶端顯示「已連線」，可能代表核心正在執行、設定檔已載入，或行動裝置的 VPN 介面已建立，但不代表目標網站已成功回應。節點旁顯示延遲，也只能說明測試位址當下可透過指定路徑連線，不能取代對故障網站的檢查。

排查時，保留一個確定能直接連線的網頁，以及一個實際無法開啟的網頁。每次只變更一項設定，並記錄瀏覽器錯誤訊息、請求時間與連線記錄，才能分辨是「修改後剛好恢復」還是某個環節確實有問題。

• 先保存設定：記下目前的設定檔名稱、運作模式、混合連接埠、策略組選擇，以及系統代理和 TUN 的啟用狀態。
• 先排除基本網路問題：暫時關閉用戶端接管的系統代理與 TUN，確認能否直接連線。有些飯店、校園或公共 Wi-Fi 須先完成登入驗證。
• 避免同時啟用多個接管工具：其他 VPN、代理軟體或瀏覽器代理擴充功能可能改變流量路徑。請逐一暫停，檢查後再還原原設定。
• 確認實際使用的核心：在用戶端的「關於」頁面或啟動記錄中，確認是否使用 mihomo。不同用戶端與核心的選單、DNS 欄位和 TUN 功能可能不盡相同。

第一層：確認瀏覽器流量是否進入本機代理

檢查系統代理位址與本機監聽狀態

系統代理仰賴應用程式主動遵循代理設定，不會自動接管所有程式。在 Windows 11 可前往「設定」→「網路和網際網路」→「Proxy」檢查手動代理；在 macOS 可前往「系統設定」→「網路」→目前的網路服務→「詳細資訊」→「代理伺服器」查看。選項名稱可能因系統版本而異。

同一台電腦上的 HTTP 代理通常填入 127.0.0.1 與實際的混合連接埠。若使用自動代理設定指令碼，請確認 PAC 位址仍由目前的用戶端提供。瀏覽器代理擴充功能或 Firefox 的獨立連線設定，都可能覆蓋系統設定。

先透過命令列明確指定本機連接埠，排除系統代理自動偵測的影響。以下命令只會用於這次請求，不會變更系統設定；Windows 請使用 curl.exe，避免部分 PowerShell 環境將 curl 視為其他命令的別名。

# macOS / Linux
curl -I -v --connect-timeout 10 --max-time 20 --noproxy "" --proxy http://127.0.0.1:7890 https://example.com/

# Windows PowerShell
curl.exe -I -v --connect-timeout 10 --max-time 20 --noproxy "" --proxy http://127.0.0.1:7890 https://example.com/

這裡的 example.com 是用來示範命令的真實網域。實際排查時，也應對無法開啟的網站執行相同測試。-I 會送出 HEAD 請求；即使回傳 403 或 405，也代表已收到 HTTP 回應，但不表示網頁已能正常完整載入。

查看連線清單驗證，不要只看開關

開啟用戶端的連線清單，重新載入目標網頁，尋找相同網域或目標 IP。一般系統代理請求通常會出現在連線記錄中。如果完全沒有新增記錄，先檢查瀏覽器連線入口，暫時不要修改 DNS。若已啟用 TUN，未明確指定代理的命令也可能被接管，因此「未明確指定代理」不代表確實繞過了用戶端。

第二層：分辨本機 DNS、核心 DNS 與代理端解析

網頁出現 ERR_NAME_NOT_RESOLVED 時，應先確認由哪一端解析網域。瀏覽器可能使用安全 DNS，作業系統可能向路由器查詢，mihomo 可能使用獨立的上游 DNS，代理協定也可能將網域交由遠端處理。這些路徑的解析結果不一定相同。

先檢查系統解析結果，再與代理請求比較

# 將 example.com 換成實際發生問題的網域
nslookup example.com

# SOCKS5：由本機解析目標網域
curl -I -v --connect-timeout 10 --max-time 20 --noproxy "" --proxy socks5://127.0.0.1:7890 https://example.com/

# SOCKS5h：將目標網域交由 SOCKS 代理處理
curl -I -v --connect-timeout 10 --max-time 20 --noproxy "" --proxy socks5h://127.0.0.1:7890 https://example.com/

Windows 執行後兩個命令時，同樣請使用 curl.exe。混合連接埠可同時接收 HTTP 與 SOCKS 請求；若目前只設定 HTTP 連接埠，請改用實際的 SOCKS 監聽連接埠。socks5h 只會將目標網域交給本機 SOCKS 代理，後續由核心或遠端解析，仍取決於規則與出站協定。

• 本機解析失敗，交由代理後成功：優先檢查系統 DNS、瀏覽器安全 DNS，以及兩者是否使用不同的網路路徑。
• 兩種請求都失敗：不能直接判定是 DNS 故障；請繼續查看核心記錄，確認是否有解析逾時、規則匹配或出站連線失敗。
• 系統解析成功，瀏覽器仍出錯：檢查瀏覽器安全 DNS；瀏覽器可能沒有使用系統查詢到的結果。

釐清 fake-ip 與 DNS 劫持

mihomo 使用 fake-ip 模式時，用戶端 DNS 回傳映射位址是正常機制，常見的預設範圍為 198.18.0.1/16。不能只憑這個位址就判定 DNS 解析遭到污染。重點是後續連線是否仍由同一個核心接管，以及核心是否保留網域映射。

如果系統取得 fake-ip，但 TUN 或相關路由已關閉，應用程式可能無法連線至該位址。請先恢復一致的流量接管方式，再考慮清除快取。修改 DNS 後，Windows 可執行 ipconfig /flushdns；macOS 可執行以下兩個命令，接著關閉舊連線並重新測試：

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

第三層：確認規則匹配結果與策略組的實際選擇

流量進入核心且網域成功解析後，仍可能被規則導向錯誤的出口。Clash 類型的規則通常依序檢查，優先匹配排在前面的規則；末尾的 MATCH 則是在前面的規則都未匹配時使用的預設規則。只看策略組名稱，無法得知請求實際經過哪個節點。

1. 確認目前使用的是規則模式，而非直連模式。全域模式通常由全域策略選擇出口，適合短時間比對，不宜直接作為故障結論。
2. 在連線詳細資訊中搜尋故障網域，記下匹配的規則類型、規則內容與策略鏈。
3. 確認規則的目標是 DIRECT、REJECT，還是某個策略組；接著展開策略組，確認最後選取的實際節點。
4. 清除該網站的舊連線，再重新載入頁面。切換策略後，既有連線通常不會立即改走新的出口。

以下是規則順序的簡化示意，並非可直接執行的完整設定。其用途是拒絕指定主機，其餘請求直連；實際設定應換成真實網域與現有策略組，並符合自己的分流需求。

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

如果將 MATCH,DIRECT 移到第一行，後面的網域規則就不會再處理這些請求。規則集也須檢查排列順序與載入狀態；訂閱更新成功只代表設定已取得，不表示所有遠端規則集都已成功下載。

短暫切換全域模式，縮小問題範圍

可暫時切換至全域模式，並明確選取一個節點，再開啟同一個網頁。若規則模式失敗、全域模式成功，請返回連線詳細資訊比對匹配差異；若兩種模式都失敗，則繼續檢查出站連線。測試後請還原原模式，避免局部問題影響其他應用程式。全域模式成功也可能是解析路徑改變所致，因此仍須搭配記錄確認。

第四層：驗證出站節點與目標網站

節點延遲測試通常只會連線至設定檔中的某個測試 URL。測試成功不代表所有網站、連接埠和 UDP 都能使用。瀏覽器載入網頁時，也可能同時請求主站、登入網域及圖片網域等多種資源；只要其中一項失敗，就可能出現白畫面或一直載入。

• 比較兩個節點：固定使用同一個故障網域、相同的代理入口與模式，只切換最後選用的節點。切換後先關閉該網域的舊連線，再重新測試。
• 檢查訂閱狀態：確認服務提供者顯示的有效期限、流量與節點狀態。更新訂閱後，確認目前執行中的設定確實已切換至新內容。
• 檢查系統時間：時間不準可能影響 TLS 憑證驗證，也可能造成依賴時間的驗證程序失敗。請先啟用系統自動校時，再確認錯誤是否消失。
• 檢查協定相容性：若出現不支援的代理類型、加密方式或設定欄位，請確認目前核心是否支援。用戶端能匯入訂閱，不代表核心已成功啟動所有節點。

記錄中的 connection refused 通常表示某個連線目標主動拒絕連線，或連接埠未監聽；i/o timeout 只表示操作逾時，無法單獨判斷問題出在 DNS、線路或遠端；x509 相關錯誤則應一併檢查憑證網域、有效期限與系統時間。請勿關閉 TLS 憑證驗證來掩蓋問題。

若只有特定網站回傳 403、地區限制或驗證碼，其他網頁都正常，表示請求已到達 HTTP 回應階段，接下來應檢查網站策略與出口條件。此時反覆修改本機混合連接埠通常無濟於事。

TUN 模式與僅瀏覽器故障的補充檢查

系統代理可用，但啟用 TUN 後失敗

TUN 透過虛擬網路介面接管流量，會涉及權限、路由與 DNS。如果明確指定代理的測試正常，只有啟用 TUN 後才無法上網，應優先檢查這些環節，而不是重新匯入訂閱。查看記錄是否出現介面建立失敗、權限不足、路由設定失敗或 DNS 請求逾時。

在 mihomo 設定中，tun.auto-route、tun.auto-detect-interface 與 tun.dns-hijack 分別涉及自動路由、出口介面偵測與 DNS 劫持；實際效果會因平台及用戶端實作而異。切換 Wi-Fi、插拔網路線或連上其他 VPN 後，原有的出口介面與路由可能已不適用。保存記錄後重新啟動 TUN，再比較相同的請求。

命令列連線正常，但只有瀏覽器無法開啟

1. 暫時停用瀏覽器代理擴充功能，並在 Firefox 的「設定」→「一般」→「網路設定」中，確認是否使用獨立代理。
2. 檢查瀏覽器安全 DNS。可暫時關閉以進行比對，確認結果後再還原原設定；不要同時修改核心 DNS。
3. 開啟開發者工具的「網路」面板，確認失敗的是主文件，還是某個指令碼、圖片或登入 API。
4. 若記錄顯示問題出在 UDP 或 QUIC 路徑，請先用一般 HTTPS 命令列請求進行比對。HTTP 請求成功不代表節點支援 UDP。

Android 裝置還須檢查用戶端是否啟用依應用程式代理，以及目標瀏覽器是否列在排除清單中；系統的「私人 DNS」也可能使解析路徑與預期不同。行動裝置上的 VPN 圖示只代表介面已建立，仍應以實際請求與用戶端記錄為準。

還原設定並保留可重現的排查記錄

完成檢查後，請還原暫時調整的全域模式、瀏覽器設定與記錄層級。若要向用戶端維護者或服務提供者回報問題，提供可重現的步驟，比只附上「已連線但無法上網」的截圖更有幫助。

• 記錄作業系統、用戶端與核心的實際版本，以及系統代理和 TUN 是否啟用。
• 說明故障範圍：所有網站、單一網站、單一瀏覽器，或僅在 TUN 模式下發生。
• 附上明確指定 HTTP 代理的測試結果、DNS 比對結果、規則匹配資訊與最終出站節點類型。
• 截取同一次請求前後的相關記錄；分享前請遮蔽訂閱網址、驗證資訊、控制介面金鑰與個人瀏覽記錄。

需要核對設定欄位時，請參閱本站的進階設定；常見安裝與使用問題可前往說明中心搜尋。