代理顯示已連線，卻無法瀏覽網頁？系統代理、DNS 與規則逐項排查

1. 先分清用戶端狀態與實際連線

Clash 類用戶端顯示「已連線」，可能只代表 Mihomo 核心正在執行、系統代理已啟用，或 Android 的 VPN 介面已建立。這個狀態無法證明瀏覽器請求已進入核心，也不代表目前的節點能連上目標網站。排查時，請沿著「應用程式 → 本機入口 → 規則與策略群組 → 對外節點 → 目標服務」逐段確認。

先記下三種狀況：所有網站都無法開啟，還是只有部分網站出問題；只有瀏覽器無法使用，還是其他應用程式也一樣；停用代理後，原本可直接連線的網站是否恢復。請用同一個完整 URL 重複測試，避免混淆不同網站的連線狀況。

觀察到的狀況	優先檢查項目	下一步要確認的資訊
瀏覽網頁時沒有新的連線記錄	系統代理、應用程式專屬代理、TUN 接管	明確指定本機代理進行測試
連線至本機連接埠時立即遭拒	核心啟動狀態、監聽連接埠、連接埠占用情況	監聽連接埠的程序
記錄中出現網域解析逾時	DNS 上游、節點網域解析、DNS 路由	發生問題的網域與解析器
請求匹配到 DIRECT 或 REJECT	規則順序、規則集、策略群組	實際匹配的規則
已選取代理節點，但對外連線逾時	節點位址、驗證資訊、傳輸設定、網路限制	更換節點與網路後的對照結果

2. 確認系統代理確實指向 Mihomo

系統代理只會告訴遵循系統設定的應用程式使用哪個代理入口，不會自動接管所有程式。部分瀏覽器擴充功能、終端機工具、遊戲與其他 VPN 軟體可能採用自己的網路設定。請先暫時停用瀏覽器代理擴充功能與其他代理用戶端，只保留一個代理入口。

檢查系統設定與本機位址

Windows 11：開啟「設定」→「網路和網際網路」→「Proxy」，確認「手動 Proxy 設定」中的位址與連接埠。若使用設定指令碼，也請確認它是否仍在控制瀏覽器流量。
macOS：開啟「系統設定」→「網路」→目前使用的網路服務→「詳細資訊」→「Proxy」，確認網頁代理、安全網頁代理或 SOCKS 代理設定。不同系統版本的選單名稱可能略有差異。
Android：系統 VPN 圖示表示 VpnService 介面已建立，還要確認用戶端是否在個別應用程式代理設定中排除了瀏覽器。

以下以 127.0.0.1:7890 作為本機混合代理入口範例。7890 僅供示範，並非所有用戶端的固定值。請從目前生效的設定或用戶端連接埠設定中確認實際數值；external-controller 是控制介面，不能作為網頁代理連接埠。

略過系統設定，直接指定代理測試

Windows 請在 PowerShell 使用 curl.exe，避免舊環境中同名命令別名造成差異。macOS 與 Linux 可將以下指令中的 curl.exe 改為 curl。範例目標為 https://example.com/；若目前網路無法連線，請改用已知可存取的 HTTPS 網址。

curl.exe -v --connect-timeout 10 --max-time 20 --noproxy "" -x http://127.0.0.1:7890 https://example.com/ -o NUL

macOS 與 Linux 請將輸出目標 NUL 改為 /dev/null。--noproxy "" 可避免環境中的略過清單影響這次明確指定代理的測試。逾時上限設為 10 秒與 20 秒，僅為排查用參數，並非節點速度的實測結果。

若指令成功但瀏覽器仍無法使用，請優先檢查系統代理、瀏覽器擴充功能、專屬代理設定與快取連線。
若顯示無法連線至 127.0.0.1，請先排查本機連接埠，不要立刻更換 DNS。
若顯示 CONNECT 成功，之後才出現 TLS 或遠端連線錯誤，代表請求至少已抵達代理入口，仍須繼續檢查對外連線路徑。

3. 連接埠衝突與核心啟動失敗

用戶端視窗能開啟，不代表核心已成功載入設定。請查看核心記錄是否出現 address already in use、設定解析失敗、規則集載入錯誤或權限錯誤。若本機連接埠被舊程序占用，瀏覽器甚至可能連到另一個代理程式。

確認監聽程序

Windows PowerShell 可查詢 TCP 監聽連接埠，再用回傳的程序編號確認程式。以下指令只會查詢，不會結束任何程序。

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

Get-Process -Id 1234

1234 是示範用的程序編號。執行第二個指令前，請改成第一個指令實際回傳的 OwningProcess。macOS 可執行 lsof -nP -iTCP:7890 -sTCP:LISTEN；Linux 可執行 ss -lntp 'sport = :7890'。若要查看其他使用者的程序詳細資訊，可能需要相應權限。

讓系統代理與生效中的設定一致

# 本機混合入口範例，僅用於說明相關欄位
mixed-port: 7890
allow-lan: false
bind-address: 127.0.0.1
mode: rule

這不是完整的訂閱設定，請勿用來覆蓋節點與規則。若將連接埠改為 7891，系統代理與測試指令也要同步修改。部分用戶端會透過覆寫或合併設定產生最終檔案，因此應確認「實際生效的設定」，不能只看訂閱原始內容。保留迴路位址有助於限制本機入口，修復本機上網問題也不需要啟用區域網路存取。

4. DNS 排查：分辨目標網域與節點網域

「DNS 出錯」至少有兩種可能：目標網站的網域解析失敗，或代理伺服器本身的網域無法解析。後者會造成多個網站同時逾時，即使這些網站的 DNS 回應完全正常。查看記錄時，請記下發生錯誤的確切網域，不要只看到 timeout 就判定節點失效。

先檢查系統解析，再查看核心記錄

nslookup example.com

nslookup 通常會查詢系統選用的 DNS 伺服器；若啟用了 TUN 劫持或網路重新導向，請求也可能被接管。因此，它的結果不一定能代表 Mihomo 的所有 DNS 查詢路徑。瀏覽器安全 DNS、系統加密 DNS 與核心內建 DNS，也可能各自使用不同路徑。

確認 DNS 已啟用：確認生效設定中 dns.enable 的狀態，以及使用的 nameserver 是否能從目前的網路連線。
檢查加密 DNS 的依賴項：DoH 或 DoT 上游若使用網域名稱，就需要可用的引導解析路徑。default-nameserver 可用來解析 DNS 伺服器網域，請一併確認它與上游位址之間的關係。
檢查代理節點的解析：proxy-server-nameserver 用於解析代理節點網域。若有設定，請確認解析器可正常使用，避免節點尚未建立連線，就必須依賴同一個節點完成解析。
檢查規則依賴：若使用 respect-rules 等設定，讓 DNS 連線遵循路由規則，就必須一併檢查相關代理與直連解析器，避免解析與代理形成循環依賴。

從 Fake-IP 切換到其他解析模式後，應用程式可能仍保留舊位址。Windows 可執行 ipconfig /flushdns 清除系統快取，再完全關閉並重新開啟瀏覽器。清除系統快取不保證瀏覽器快取、DoH 快取或既有連線也會一併清除，因此請重新發出請求並對照記錄。

不要同時更改 DNS 模式、所有上游伺服器與 TUN 設定。請先確認一條已知可用的解析路徑，再逐項還原原有設定。欄位用途可參考DNS 設定說明。

5. 規則匹配與策略群組：確認實際出口，不只看模式

Mihomo 的規則模式會依序比對規則。通常先匹配到的規則會決定請求的去向，最後的 MATCH 則用來處理前面規則都未匹配的請求。如果目標網域被較前面的規則送往 DIRECT，後續的代理規則就不會再改變它的路徑。

在連線詳細資訊中確認四個項目

目標網域與連接埠是否正是剛才測試的網站；HTTPS 通常使用 TCP 443。
匹配到的規則類型與內容，尤其是網域規則、規則集與預設規則。
匹配到的策略群組，以及該群組最後選擇的節點或 DIRECT。
故障發生在解析、撥號、代理交握，還是 TLS 階段。

先清空用戶端的連線清單，或記下測試時間，再重新開啟目標網頁。若舊連線重複使用，導致結果難以判斷，可關閉對應連線後再試。策略群組名稱只是選擇入口，群組內可能還有其他巢狀群組，因此必須追查到最終出口。

全域模式僅供短時間比對

暫時切換到全域模式，並明確選擇一個節點。如果同一個目標在全域模式下可開啟、規則模式卻失敗，請優先檢查規則順序與策略群組選擇；如果兩種模式都失敗，則繼續檢查節點與網路。全域模式無法修復失效節點，也不會自動接管未進入核心的應用程式流量。

規則集下載失敗也可能影響設定載入或分流結果，請查看 rule-providers 的更新記錄與本機快取狀態。不要只為了暫時開啟網頁就刪除整套規則；請先找出實際匹配項目，再調整必要的順序或策略。排查完成後，請恢復原本的規則模式。

6. 節點可用性：延遲數字不代表網頁能開啟

延遲測試反映的是特定測試 URL、特定時間與目前網路下的一次探測。顯示延遲數值，不代表其他網域、影音服務或 UDP 流量都能正常通過。節點清單中有記錄，也不代表訂閱中的位址、連接埠與憑證仍然有效。

使用相同網路更換節點：保持瀏覽器、目標 URL 與代理模式不變，只更換節點。若換成其他節點後立即恢復，請優先檢查原節點或其伺服器狀態。
使用相同節點更換網路：從 Wi-Fi 切換至手機熱點，重新開啟相同目標。若結果不同，代表接入網路的 DNS、防火牆或路由條件值得進一步檢查。
確認訂閱更新時間：確認訂閱確實更新成功，而不是仍在使用舊快取。更新後也要檢查用戶端覆寫設定是否蓋掉節點相關設定。
確認協定參數：手動設定時，請檢查伺服器位址、連接埠、驗證資訊、TLS 伺服器名稱與傳輸參數。是否需要特定欄位取決於使用的協定，不能直接拼湊其他協定的設定。

connection refused 常見原因是目標連接埠未監聽或遭主動拒絕；i/o timeout 表示等待逾時，不能只憑這一行判斷是伺服器故障，還是中間網路封包遺失。若出現憑證錯誤，請檢查系統時間、目標網域與 TLS 設定。不要長期略過憑證驗證，以免掩蓋交握錯誤。

若只有登入頁或特定網站無法使用，也要檢查網站回傳的 HTTP 狀態碼。403、429 或帳戶限制，與「本機代理連接埠未啟動」並非同一類問題。請先確認回應確實來自目標服務，再考慮出口位址策略或網站本身的限制。

7. TUN、個別應用程式代理與瀏覽器協定的補充檢查

明確指定 HTTP 代理測試正常，但啟用 TUN 後無法連線，是很有用的判斷線索。TUN 仰賴虛擬網卡、路由與權限；啟用 tun.auto-route、介面偵測或 DNS 劫持後，也要檢查是否與其他 VPN、虛擬機器網路或安全軟體衝突。

桌面版先單獨測試 TUN 路徑

記下目前 TUN 與系統代理的狀態，然後暫時關閉 TUN。
只用前面的明確代理指令測試相同 URL，確認本機入口與節點連線路徑。
若明確代理測試正常，再啟用 TUN，並檢查啟動記錄中的權限、網卡建立與路由寫入結果。
若關閉用戶端後仍無法直接連線，請檢查殘留的系統代理、其他 VPN 與路由，不要未經確認就刪除系統路由表。

Android：確認應用程式是否已納入代理

Android 通常一次只能有一個一般應用程式的 VPN 服務處於啟用狀態。切換至其他 VPN、廣告封鎖類 VPN，或工作設定檔中的網路工具時，原本的用戶端可能會被取代。在個別應用程式設定中，「僅代理所選應用程式」與「略過所選應用程式」的意思相反，請確認瀏覽器位於預期的清單中。若只有鎖定螢幕後才出問題，請再檢查背景執行限制與電池最佳化，不要先重寫規則。

只有瀏覽器出問題時，檢查 HTTP/3

HTTP/3 使用 QUIC，通常會用到 UDP 443。明確指定 HTTP 代理的指令成功，不代表瀏覽器的 QUIC 路徑也正常。若問題明確只發生在瀏覽器，可暫時停用 HTTP/3 進行比對；只有結果因此改變，才進一步檢查 UDP 對外連線、節點支援與 TUN 接管。不要把停用協定當成所有網頁故障的固定解法。

8. 還原設定與回報問題的必要資訊

找出故障環節後，請逐項還原測試期間暫時更改的全域模式、DNS 上游伺服器與瀏覽器協定設定，只保留確實解決問題的修改。再次測試一個可直接連線的網站、一個需要代理的網站，以及原本出問題的目標。最後確認關閉用戶端後，系統仍能依預期連上網路。

若仍需回報問題，提供以下資訊會比只附一張「已連線」截圖更有助於定位。記錄只需截取重現問題前後的必要片段，避免公開訂閱憑證、節點密碼與控制介面權杖。

作業系統版本、用戶端版本、實際的 Mihomo 核心版本，以及是否使用用戶端覆寫設定。
系統代理或 TUN 的啟用狀態、本機監聽位址與連接埠，以及個別應用程式代理設定。
問題發生時間、目標網域、使用的網路，以及是否所有目標都無法連線。
明確指定代理指令的結果、實際匹配規則、最終策略群組與節點。
更換節點、更換網路、關閉 TUN 這三種比對方式中，哪些操作改變了結果。