Clash 核心報錯、瀏覽器打不開網頁、訂閱明明更新過卻仍無法連線——這類問題的成因通常集中在五個環節:本機連接埠是否被佔用、系統代理開關是否真正生效、目前節點是否可用、DNS 解析是否被劫持或污染,以及防火牆或安全軟體是否攔截了核心處理程序。逐一排查比反覆重新啟動用戶端更省時間。本清單按照由內到外的順序編排:先確認核心本身能不能正常監聽連接埠,再確認系統層面是否把流量轉發給了核心,然後確認轉發出去的流量能否真正抵達目標網站。
本文以 Clash Meta 核心(mihomo)及主流圖形用戶端(Clash Verge、Clash for Windows 系分支、ClashX Meta 等)為基準,命令列範例區分 Windows、macOS、Linux 三個平台,操作前請確認用戶端已完全退出並重新啟動一次,排除暫時性異常。
第一步:檢查本機連接埠佔用
Clash 核心預設會監聽混合連接埠(通常是 7890)、控制面板連接埠(9090)以及部分用戶端使用的 DNS 連接埠(53 或 1053)。如果這些連接埠已經被其他程式佔用,核心會啟動失敗或靜默降級,表現為用戶端介面顯示「執行中」但實際沒有流量經過。
Windows
netstat -ano | findstr "7890"
netstat -ano | findstr "9090"輸出中最後一欄是處理程序 PID,可用工作管理器或 tasklist /FI "PID eq 處理程序編號" 查看該處理程序是誰。若發現連接埠被非 Clash 處理程序佔用,可在用戶端設定裡把混合連接埠改為 7891 等空閒值,或結束佔用的處理程序後重新啟動核心。
macOS / Linux
lsof -i:7890
lsof -i:9090指令會列出監聽該連接埠的處理程序名稱與 PID。如果輸出為空,表示核心根本沒有成功監聽該連接埠,需要回到用戶端記錄面板查看核心啟動報錯,常見原因是設定檔裡連接埠欄位拼寫錯誤或連接埠號超出合法範圍。
第二步:檢查系統代理開關狀態
用戶端介面上的「系統代理」開關本質是在寫入系統的代理設定欄位,而不是直接控制核心。開關顯示為「已開啟」不代表系統真的採用了這份設定,常見於開關被安全軟體重置,或者系統同時存在多套網路設定(如 VPN 與 Wi-Fi 共存)導致代理寫入了錯誤的網路介面。
Windows 校驗
reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings" /v ProxyEnable
reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings" /v ProxyServerProxyEnable 傳回值為 0x1 表示系統代理已啟用,ProxyServer 應顯示為 127.0.0.1:7890 之類的位址。若位址與用戶端實際監聽連接埠不一致,需在用戶端裡重新點擊一次系統代理開關以刷新寫入。
macOS 校驗
networksetup -getwebproxy Wi-Fi
networksetup -getsecurewebproxy Wi-Fi如果目前使用的是有線網路,把 Wi-Fi 換成 Ethernet 或對應的介面名稱(可先用 networksetup -listallnetworkservices 查看介面清單)。
Linux 校驗
大部分 Linux 圖形用戶端不會直接改寫系統層級代理,而是依賴桌面環境或瀏覽器擴充功能讀取環境變數,建議直接檢查:
echo $http_proxy
echo $https_proxy若為空,表示系統代理需要手動在網路設定或 shell 設定檔中宣告,或改用 TUN 模式接管流量以繞開系統代理這一層。
第三步:檢查節點可用性
系統代理生效不代表節點能通,常見於訂閱節點到期、機場臨時維護,或者目前選中的節點延遲測試顯示逾時。排查順序建議為:先看用戶端節點清單裡的延遲數值,再用主控台單獨測一次目標節點。
- 延遲欄顯示「逾時」或「N/A」:該節點目前不可用,先切換到延遲正常的備用節點。
- 所有節點延遲皆異常:多半是訂閱整體失效或本機網路中斷,建議先確認本機能否直接連上其他一般網站。
- 延遲正常但仍無法存取目標網站:該節點可能被目標網站單獨封鎖,嘗試切換出口地區。
透過控制面板 API 也能驗證節點連通性,前提是控制連接埠已在設定裡開放:
curl -x http://127.0.0.1:7890 https://www.google.com -I --max-time 5回傳 HTTP/2 200 或 30x 狀態碼表示代理鏈路本身是通的;如果指令逾時或回傳連線拒絕,表示問題出在代理鏈路而非瀏覽器或應用程式本身,應回到節點或訂閱層面繼續排查,而不是反覆檢查瀏覽器設定。
訂閱連結對應的機場存在單帳號裝置數限制,同一訂閱在多台裝置同時使用時,部分機場會隨機拒絕新連線,表現為節點延遲正常但請求依舊失敗,遇到此類情況建議先在其他裝置上退出用戶端再測試。
第四步:檢查 DNS 解析
Clash 支援在設定檔裡單獨定義 DNS 伺服器、啟用 fake-ip 或 redir-host 模式,如果本機系統 DNS 與 Clash 內建 DNS 出現衝突,常見現象是網頁能打開但載入緩慢,或者部分網域始終解析到錯誤的 IP。
確認目前生效的 DNS
# Windows
nslookup www.google.com
# macOS / Linux
nslookup www.google.com
dig www.google.com +short如果開啟了 fake-ip,解析結果通常落在 198.18.0.0/16 這一保留段,這是正常現象,代理會在傳輸層根據網域重新建立連線,不代表解析出錯。若結果落在真實公網 IP 段但網站仍打不開,需要進一步排查是否命中了錯誤的分流規則,把該網域導向了直連而非代理。
驗證 Clash 內建 DNS 是否被正確呼叫
nslookup www.google.com 127.0.0.1 -port=1053連接埠號需與設定檔中 dns.listen 欄位一致。如果該指令逾時,表示核心 DNS 模組沒有正常啟動,應回到設定檔檢查 dns.enable 是否為 true,以及上游 DNS 伺服器位址是否可達。
第五步:檢查防火牆與安全軟體攔截
作業系統內建防火牆、第三方安全軟體、企業內網的終端管控軟體都可能針對 Clash 核心處理程序做攔截,這類攔截往往沒有明顯報錯,只是連線請求被靜默丟棄,排查時容易被誤判為節點問題。
Windows Defender 防火牆
netsh advfirewall firewall show rule name=all | findstr /i "clash"如果沒有相符結果,表示防火牆裡不存在為 Clash 核心放行的規則,可在「允許應用程式通過防火牆」設定裡手動為用戶端可執行檔及核心處理程序(常見檔名為 clash-meta.exe 或 mihomo.exe)勾選專用網路與公用網路。
macOS 應用程式防火牆
路徑為「系統設定 → 網路 → 防火牆 → 選項」,確認 Clash 用戶端及其核心處理程序狀態為「允許傳入連線」。部分安全軟體(如企業 EDR)會在系統防火牆之外單獨攔截,需要在對應軟體的信任清單裡補充放行。
Linux iptables / ufw
sudo iptables -L -n | grep 7890
sudo ufw status verbose確認沒有針對代理連接埠的 DROP 或 REJECT 規則。若使用 TUN 模式,還需確認虛擬網卡對應的路由表項目已正確寫入,可用 ip route 查看是否存在指向 utun 或 tun0 的預設路由。
逐項勾選清單
把上述五個步驟壓縮成一份可直接對照使用的檢查表:
- 混合連接埠(7890)與控制連接埠(9090)未被其他處理程序佔用,核心記錄無連接埠衝突報錯。
- 系統代理欄位(
ProxyServer/networksetup輸出)與用戶端實際監聽連接埠一致。 - 目前選中節點延遲正常,或已切換到延遲正常的備用節點。
curl -x測試透過代理能正常存取目標網站,回傳合法 HTTP 狀態碼。- DNS 解析結果符合預期(
fake-ip段或正確的真實 IP),未命中錯誤的分流規則。 - 系統防火牆及安全軟體均已為 Clash 用戶端與核心處理程序放行網路權限。
- 若使用 TUN 模式,虛擬網卡路由表項目已正確寫入且未被其他 VPN 搶占預設路由。
如果以上七項全部通過但依舊無法存取特定網站,大概率是目標網站單獨對代理出口 IP 段做了封鎖或驗證碼攔截,屬於網站端策略問題,不應繼續在本機網路設定上反覆調整。
建議把這份清單保存為本機筆記,每次遇到連線異常時按順序執行,而不是隨機嘗試重新啟動、換節點、重灌用戶端。多數連線失敗問題在完成前兩步(連接埠與系統代理)後就能定位,剩下的節點、DNS、防火牆三步用於處理少數頑固場景。