先釐清用戶端狀態與網頁請求

Clash 用戶端顯示「已連線」，通常代表核心正在執行、代理已啟用，或某次連線測試成功，但不表示瀏覽器的每個請求都已經過節點。完整連線路徑包括應用程式的代理入口、核心規則、出口節點、網域解析和目標服務。任何一個環節出錯，都可能讓網頁一直轉圈。

每次排查只調整一個變數。先保留目前的設定與覆寫檔，並記下用戶端名稱、核心版本、所選策略和錯誤時間。不同用戶端的設定名稱不盡相同，以下以設定欄位、系統入口和可觀察的結果為準，不把特定用戶端的按鈕名稱當成通用選單。

  • 所有應用程式都無法上網：先關閉代理與 TUN，確認 Wi-Fi、網路線、預設閘道和網路驗證是否正常。
  • 只有瀏覽器無法開啟網頁：檢查瀏覽器擴充功能、獨立代理設定、安全 DNS 和快取。
  • 只有部分網站無法開啟：優先檢查命中規則、節點出口和目標網站的限制。
  • 只有開啟 TUN 後才斷網：先使用系統代理建立可用基準，再檢查路由接管。

步驟一：確認系統代理指向實際監聽的連接埠

系統代理常見入口是 127.0.0.1:7890，但 7890 並非固定值。請以目前執行中的設定所指定的 mixed-port 為準。此連接埠可同時接收 HTTP 和 SOCKS 代理連線；external-controller 是控制介面，不能填入瀏覽器的代理連接埠。

檢查系統和瀏覽器設定

  • Windows 11：開啟「設定」→「網路和網際網路」→「Proxy」，檢查手動代理的位址和連接埠。若用戶端使用自動設定指令碼，請確認目前啟用的入口，避免手動代理與舊指令碼混用。
  • macOS：開啟「系統設定」→「網路」→目前的網路連線→「詳細資訊」→「代理伺服器」，確認 HTTP、HTTPS 或 SOCKS 的設定與用戶端一致。
  • Firefox：開啟「設定」→「一般」→「網路設定」→「設定」，確認使用系統代理，或核對手動設定的位址和連接埠。
  • 手機通常透過本機 VPN 接管流量，不能直接套用桌面系統代理的設定方式；請先確認系統目前啟用的是哪個 VPN 設定檔。

確認連接埠確實在監聽

以下 Windows PowerShell 指令用來檢查 TCP 7890 是否正在監聽，以及對應的處理程序編號。若沒有輸出，表示目前沒有 TCP 服務監聽此連接埠，不應再假設系統代理已連上核心。

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

在 macOS 或已安裝 lsof 的 Linux 系統中，也可以檢查相同的連接埠：

lsof -nP -iTCP:7890 -sTCP:LISTEN

若設定改為 mixed-port: 7891，系統代理、命令列代理和應用程式內的手動代理都要同步改成 7891。僅供本機使用時，監聽位址設為迴環位址是正常的，不必為了排查問題直接啟用區域網路存取。

步驟二：透過明確指定代理的請求排除瀏覽器問題

先暫時關閉 TUN，保持核心執行，再用指令明確指定代理。這樣可略過瀏覽器擴充功能和系統代理的選擇流程。Windows 請使用 curl.exe，避免某些 PowerShell 環境將 curl 解讀為其他指令；macOS 和 Linux 則使用 curl。

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

此處的 example.com 是公開測試網域，不代表固定的測速目標。--noproxy "" 可避免環境中的代理略過清單影響測試。若要測試未明確指定代理的連線路徑，請在關閉 TUN 後執行：

curl.exe --noproxy "*" --connect-timeout 10 --max-time 20 -I https://example.com
觀察結果接著檢查
顯示無法連線至 127.0.0.1:7890檢查監聽連接埠、核心是否已關閉，以及用戶端是否套用目前的設定。
明確指定代理後可連線，瀏覽器卻不行檢查系統代理、擴充功能、瀏覽器獨立代理和安全 DNS；建立新的瀏覽器設定檔再測試。
收到 407 回應檢查本機代理的驗證設定，以及請求使用的帳號和密碼。
建立連線後逾時或 TLS 失敗接著檢查出口節點、目標連線、系統時間和憑證錯誤的詳細資訊。

HTTPS 代理記錄中的 200 Connection established 只表示 CONNECT 通道已接受，還要檢查後續的 TLS 交握和目標伺服器回應。目標伺服器回傳 403 或 405，表示至少收到一次 HTTP 回應，但不代表網站服務可正常使用；必要時可改用一般 GET 請求再次確認。

步驟三：檢查模式、規則和最終出口

開啟用戶端的連線清單，重新載入一次出問題的網頁，再依網域或處理程序尋找對應連線。重點是查看匹配規則、策略群組和最終節點，而不只是首頁目前選取的節點名稱。規則可能會將該網域導向 DIRECT、REJECT 或其他策略群組。

  • rule：依規則順序比對，由第一條符合的規則決定策略。檢查較前面的網域規則、規則集，以及最後的 MATCH。
  • global：可暫時用於對照測試，並確認 GLOBAL 策略實際選取了預期節點。切換至全域模式不代表節點一定可用。
  • direct：進入核心的連線會以直連方式處理，無法用來驗證代理節點是否暢通。

如果同一網址在全域模式可用、規則模式卻失敗，請查看規則模式實際使用的出口。常見原因是訂閱規則讓目標網域直連，或巢狀策略群組仍選用無法使用的節點。修改後請切回 rule，再確認新連線命中預期策略。

連線清單沒有記錄時

先確認清單沒有套用篩選、網頁不是直接從快取載入，而且核心記錄確實涵蓋測試時段。若仍找不到請求，請優先回頭檢查應用程式入口和 TUN 接管，不要急著重寫規則。瀏覽器可能使用獨立代理、VPN 或其他網路擴充功能，導致請求根本沒有進入目前的核心。

步驟四：驗證節點，不只看延遲數字

節點顯示延遲，代表它完成了用戶端指定的探測請求，但這個結果無法涵蓋所有目標網域、UDP 流量、IPv6 路徑或長連線。即使探測位址可連線，目標網站仍可能限制出口，因此會出現「延遲正常，網頁卻無法開啟」的情況。

  1. 固定同一個目標網址，分別使用兩個節點測試，避免同時更換節點和網站。
  2. 檢查訂閱服務的有效期限、流量餘額，以及節點參數是否已更新。只從既有且可信的訂閱入口更新，切勿將訂閱網址提交到線上檢測網站。
  3. 查看記錄中的具體錯誤，例如連線至節點逾時、驗證失敗、TLS 交握失敗或網域解析失敗。
  4. 確認系統日期和時間。時間偏差可能造成憑證驗證失敗，不應透過停用憑證驗證來掩蓋問題。

如果所有節點都在連線至伺服器階段逾時，也要檢查目前的網路是否限制相關傳輸連接埠。切換到手機熱點可用來比對網路路徑，但這只是定位問題的方法，不能據此認定節點設定一定正確。

步驟五：區分系統 DNS、核心 DNS 和瀏覽器安全 DNS

排查 DNS 問題時，先確認「由誰負責解析」。系統解析器、mihomo 的 DNS 模組和瀏覽器的加密 DNS 可能使用不同路徑。系統的 nslookup 成功，不足以證明核心 DNS 正常；核心 DNS 正常，也不代表瀏覽器使用相同的解析入口。

先觀察，再修改 nameserver

Windows 可先查看系統 DNS 的回應結果。指令會顯示使用中的伺服器和回應位址；若要求逾時，請接著確認該 DNS 伺服器是否可透過網路連線。

nslookup example.com

若正在使用 mihomo，並想單獨觀察核心 DNS，請先確認連接埠未被占用，再將以下片段合併至現有的 dns 區段。這只是診斷片段，不包含節點、策略群組或規則，不能單獨作為完整設定執行。

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 1.1.1.1

此處的 1.1.1.1 是一般 DNS 上游範例，能否連線取決於目前的網路環境。若企業或校園網路要求使用既有 DNS，請保留符合網路環境的設定，不要把公共 DNS 當成通用解法。設定生效後，可在已安裝 dig 的終端機中查詢指定連接埠：

dig @127.0.0.1 -p 1053 example.com A

在 fake-ip 模式下，回傳設定範圍內的對應位址可能是正常現象。這些位址用來關聯網域與後續連線，並非目標網站的真實公網位址。若應用程式取得對應位址後，後續連線卻繞過核心，網頁就可能無法載入；因此，必須一併檢查 Fake-IP 和實際的流量接管路徑。

  • 節點伺服器使用網域名稱：先確認伺服器網域可以解析。mihomo 的 proxy-server-nameserver 可指定節點伺服器網域的解析上游，避免建立代理連線前就依賴該代理，形成循環。
  • 使用 fallback：此功能會搭配 fallback-filter 參與解析結果的選擇，並非所有連線逾時問題都適用的通用備援開關。
  • 使用瀏覽器安全 DNS：暫時切換回系統解析進行比對，之後再還原所需設定。不要同時變更瀏覽器和核心的多組上游。
  • 只有部分網站載入緩慢：比較 A、AAAA 記錄與 IPv6 連線狀態。先用 curl -4 和 curl -6 比對，不要預設關閉 IPv6 就能解決問題。

Windows 可在變更解析設定後執行 ipconfig /flushdns，清除系統 DNS 快取，並重新啟動瀏覽器。這不會清除所有瀏覽器快取或核心的 Fake-IP 對應，也無法修復無法連線的 DNS 上游。

步驟六：系統代理正常後，再排查 TUN 和防火牆

如果明確指定 HTTP 代理的測試成功，但開啟 TUN 後失敗，應優先檢查流量接管。TUN 仰賴虛擬網卡、路由和執行權限；用戶端顯示已啟用，不足以證明路由已成功安裝。先查看啟動記錄，確認沒有權限不足、裝置建立失敗或路由衝突。

檢查接管範圍與 DNS 劫持

mihomo 的 tun.auto-route 用來自動設定路由，tun.auto-detect-interface 則可協助辨識出口介面；實際支援情況應以目前的核心和平台為準。若有多張網卡、其他 VPN 或虛擬機器網路，自動辨識結果可能不如預期。

tun.dns-hijack 可將符合條件的傳統 DNS 請求交由核心 DNS 處理。常見項目為 any:53；若要匹配 TCP 53，請依核心支援情況設定 tcp://any:53。這不會自動接管瀏覽器傳送至 HTTPS 443 的加密 DNS 請求，也無法取代可用的上游解析器。

  1. 暫時退出其他 VPN、網路加速器或重複執行的代理用戶端，再只啟動一個流量接管程式。
  2. 確認用戶端要求的服務已安裝並執行，或依照說明以所需權限啟動，接著檢查記錄。
  3. Windows 使用 route print，Linux 使用 ip route 查看路由並確認實際出口，切勿盲目刪除系統路由。
  4. 在防火牆設定中，確認目前核心的執行檔已獲准連線。用戶端更新後若路徑改變，舊規則可能就不再適用。
  5. 若只有在 TUN 模式下，大型檔案或部分 HTTPS 頁面會卡住，再檢查 MTU、路徑 MTU 探索和 UDP 支援；沒有明確證據時，不要反覆切換網路堆疊。

恢復日常使用前：確認設定生效且結果可重現

用戶端可能同時有訂閱原始設定、覆寫設定和最終執行設定。編輯某個 YAML 檔案，不代表核心實際讀取的就是該檔案。請先在用戶端確認目前的設定來源，再查看實際套用的連接埠、DNS 和 TUN 欄位。

若使用獨立版 mihomo，可在設定目錄中執行以下 Windows 指令檢查語法。此指令假設目前目錄已有 mihomo.exe 和 config.yaml；圖形介面用戶端應優先使用內建的設定檢查功能，避免另外啟動第二個核心而占用連接埠。

.\mihomo.exe -t -f .\config.yaml

語法檢查通過只代表設定可以解析，無法保證節點、DNS 或網路可連線。修復完成後，請依照以下順序收尾：

  • 切回日常使用的規則模式，並檢查一個直連目標和一個代理目標的實際出口。
  • 重新開啟瀏覽器，重測先前無法開啟的網址，並核對同一時段的連線記錄。
  • 將臨時除錯記錄恢復為日常等級，並移除不再需要的測試監聽連接埠。
  • 記下最終連接埠、修改的欄位和設定生效方式，避免下次更新訂閱時覆蓋修復內容。

若仍找不到問題，請提供用戶端和核心版本、系統版本、故障時間、系統代理與 TUN 的啟用狀態，以及已去除敏感資訊的單次請求記錄。清楚且精簡的重現步驟，比一張「已連線」截圖更有助於釐清問題。基礎設定可參考使用指南，欄位說明請參閱mihomo 進階設定。