先把症狀說準:不是某個網站打不開,是所有網站一起啞掉,瀏覽器、通訊軟體、系統更新全不動。這種情況幾乎都出在本機這一段,和節點好不好沒什麼關係。
先分清是代理的問題還是網路本身
- 把用戶端的系統代理開關關掉,用戶端本身別結束。
- 打開一個平常能開的網頁,按一次強制重新整理。
- 網頁回來了:問題在代理鏈路上,接著往下排。
- 網頁還是打不開:先修本機網路。用
ipconfig /flushdns清一下 DNS 快取,檢查網路線和 Wi-Fi,代理這邊暫時別動。
關掉開關網路就回來的話,後面所有動作都只針對代理這一段。別去重設網路卡、別急著打
合作推薦訂閱連結從哪來?本站合作機場註冊即送 1GB 香港高速體驗流量,可直接一鍵匯入。取得高速節點
netsh winsock reset、更不用重灌系統——這幾步會把一個五分鐘的問題拖成半天。用戶端有沒有真的在監聽那個連接埠
netstat -ano | findstr 7890
lsof -i :7890
ss -tlnp | grep 7890
三條分別對應 Windows、macOS 和 Linux,連接埠號換成你自己的 mixed-port。沒有任何輸出就是沒人在監聽,核心根本沒起來;有輸出但程序名既不是 mihomo 也不是用戶端,代表連接埠被別的程式佔用了。這時候用戶端常常是靜默失敗,介面上一切正常。把 mixed-port 改成 7891 這類沒人用的號碼,重啟核心再試。
系統代理指向的位址與連接埠對不對
Windows 在「設定 → 網路和網際網路 → Proxy」,macOS 在「系統設定 → 網路 → 代理伺服器」,看手動代理那一欄填的是不是 127.0.0.1 加用戶端實際在用的連接埠。改過 mixed-port 但系統代理還指著舊的,是很典型的一種:用戶端顯示已連線,系統卻往一個空連接埠送流量。
curl -x http://127.0.0.1:7890 -I https://www.cloudflare.com
curl -x socks5://127.0.0.1:7890 -I https://www.cloudflare.com
這兩條會繞過系統代理設定,直接把請求交給用戶端連接埠。能回傳 HTTP 狀態行,代表用戶端和節點都是通的,問題只在系統代理那一側;回報 connection refused 就是連接埠那頭沒人接,回上一節。
連接埠通了,網頁還是打不開
- 策略群組是空的。訂閱抓取失敗或節點被過濾規則清光時,群組裡一個節點都沒有,流量命中規則後無處可去。
- 沒選中節點。手動群組預設可能停在第一項,而第一項是 REJECT 或另一個空群組。
- 規則最後那條
MATCH指向了不通的群組,所有沒被前面規則命中的流量都從這兒走。 - 翻記錄檔找
timeout、EOF、context deadline exceeded這類字樣。一直在刷,代表請求出去了但節點沒回應,換個節點。
關掉用戶端反而全斷了
這是最常見也最讓人摸不著頭緒的一種。用戶端當掉或被工作管理員強制結束時,來不及把系統代理設定改回去,系統還在往一個已經不存在的連接埠送流量,於是整機斷網,重開用戶端也未必清得掉。去代理設定裡把「使用 Proxy 伺服器」手動關掉,macOS 在網路設定的代理頁取消勾選。下次記得從系統匣圖示正常結束。