報錯訊息解讀:為什麼會出現 address already in use
Clash 與基於 Clash Meta(mihomo)核心的用戶端啟動時,會嘗試監聽設定檔裡指定的幾個連接埠:混合連接埠(mixed-port,同時接受 HTTP 與 SOCKS5 請求)、獨立的 HTTP 連接埠(port)與 SOCKS5 連接埠(socks-port),部分用戶端還會額外監聽一個 RESTful API 連接埠(external-controller,常見預設值 9090)。當其中任意一個連接埠已經被系統裡另一個程序佔用,核心在綁定(bind)階段就會失敗,日誌或彈出視窗裡通常會看到類似下面的資訊:
panic: listen tcp 127.0.0.1:7890: bind: address already in use
這條報錯本身已經把問題說得很清楚:核心想監聽 7890 連接埠,但作業系統拒絕了,因為這個連接埠已經「名花有主」。這類問題不是設定檔語法錯誤,也不是訂閱或代理節點的問題,純粹是本機連接埠資源衝突,處理思路統一分兩步:先找出佔用連接埠的程序,再決定「停掉它」還是「換個連接埠給 Clash 用」。
如果你同時裝了兩個 Clash 系列用戶端(例如 Clash Verge Rev 和 ClashX Meta),又都設定成開機自動啟動,幾乎必然會互相搶佔預設連接埠。這種情況優先解除安裝或關閉其中一個,而不是反覆改連接埠。
Windows:用 netstat 與 PowerShell 定位佔用連接埠的程序
Windows 上最直接的辦法是開啟命令提示字元或 PowerShell,用 netstat 查看連接埠對應的程序 ID(PID),再用工作管理員或 taskkill 反查、結束程序。以預設的 7890 連接埠為例:
netstat -ano | findstr :7890
輸出的最後一欄就是 PID,例如顯示 12480,再執行:
tasklist | findstr 12480
就能看到是哪個執行檔佔用了這個連接埠。如果確認這個程序可以關閉,可以直接結束它:
taskkill /PID 12480 /F
PowerShell 使用者也可以用一條命令直接拿到連接埠對應的程序名稱,資訊更直觀:
Get-Process -Id (Get-NetTCPConnection -LocalPort 7890).OwningProcess
常見的佔用來源包括:上一次 Clash 用戶端異常退出後殘留的背景程序(尤其是透過工作管理員強制關閉視窗、但核心程序未隨之退出的情況)、其他基於 Clash 核心的工具,以及部分下載工具或本機代理偵錯工具預設也會佔用 7890 附近的連接埠段。
macOS:用 lsof 排查連接埠佔用
macOS 下最常用的是 lsof(list open files),它可以按連接埠號反查佔用程序:
sudo lsof -i :7890
輸出中 COMMAND 欄是程序名稱,PID 欄是程序編號。確認無誤後,結束程序:
kill -9 對應的PID
如果習慣用 netstat,macOS 也保留了相容寫法,但普遍建議直接用 lsof,資訊更完整。另外要注意,ClashX、ClashX Meta 這類基於選單列的用戶端,退出選單列圖示不一定會同步終止背景的核心程序,遇到連接埠衝突時先確認核心程序是否真的退出了,而不是只關閉了介面。
ps aux | grep -i clash
這條命令能把目前系統裡所有和 clash 相關的程序列出來,方便一次性清理殘留執行個體。
Linux:用 ss 與 fuser 定位並結束程序
較新的發行版建議用 ss 代替已經逐漸被棄用的 netstat:
sudo ss -tulnp | grep 7890
輸出裡 users:(("程序名",pid=1234,...)) 部分即為佔用資訊。也可以用更簡潔的 fuser 直接定位並選擇性結束:
sudo fuser -k 7890/tcp
該命令會直接結束佔用 7890 連接埠的程序,適合確認佔用方是可以安全終止的舊程序時使用。如果透過 systemd 管理 mihomo 或 clash 服務,更穩妥的做法是先檢查是否存在兩個服務執行個體同時啟動:
systemctl status mihomo
systemctl status clash
如果兩個服務都在執行且都嘗試監聽同一連接埠,應停用其中一個,而不是靠改連接埠「繞過去」,否則規則、訂閱更新等功能會分裂在兩個程序上,狀態不一致,排查起來更麻煩。
修改 Clash 設定檔中的混合連接埠
如果佔用連接埠的程式不方便關閉(比如是系統服務或另一個長期在用的工具),更省事的辦法是讓 Clash 換一個連接埠監聽。Clash Meta(mihomo)核心建議直接使用混合連接埠欄位:
mixed-port: 7895
allow-lan: false
bind-address: "*"
external-controller: 127.0.0.1:9096
secret: ""
只需要把 mixed-port 的值從預設的 7890 改成一個未被佔用的連接埠(建議選 10000 以上、且不與常見軟體衝突的號段,如 7895、17890 等),儲存後重新啟動用戶端即可。如果同時使用舊式的 port(HTTP)與 socks-port(SOCKS5)欄位而不是 mixed-port,也要一併檢查是否有衝突:
port: 7891
socks-port: 7892
external-controller: 127.0.0.1:9097
external-controller(RESTful API 連接埠,預設常見為 9090)同樣會佔用一個連接埠,如果 Clash 面板(Dashboard)打不開,報錯訊息裡出現的是 9090 而不是 7890,原理和處理方式完全一樣,只是要改的欄位不同。
大多數圖形介面用戶端(Clash Verge Rev、Clash Plus、FlClash 等)也提供了在設定頁直接填寫連接埠號的入口,效果等同於修改設定檔裡的對應欄位,改完後同樣需要重新啟動核心或用戶端才會生效。修改連接埠後,別忘了同步更新系統代理設定或瀏覽器外掛裡填寫的連接埠號,否則會出現「用戶端正常運作,但瀏覽器仍然連不上」的情況——這其實不是連接埠衝突本身的問題,而是連接埠改了之後系統代理沒跟著改。
常見佔用元兇與規避建議
根據回饋整理,7890 附近連接埠段最常見的衝突來源包括以下幾類,提前了解可以省掉一輪排查:
- 上一個 Clash 程序未徹底退出:直接點右上角關閉視窗,核心程序可能仍在背景執行,再次啟動就會自己跟自己搶連接埠。
- 同時安裝了多個 Clash 系列用戶端:例如電腦上既有 Clash Verge Rev 又有舊版 Clash for Windows 殘留,兩者若都設定了開機自動啟動,極易衝突。
- 其他代理/偵錯工具:部分本機開發偵錯代理工具、封包截取工具預設也會監聽 7890 或相近連接埠。
- 容器或虛擬化環境的連接埠轉發:使用 Docker 或虛擬機做連接埠映射時,容器內服務映射到主機的連接埠有時會恰好落在這個區間。
規避建議很簡單:只保留一個正在使用的 Clash 系列用戶端,解除安裝或徹底停用其餘的自動啟動項;如果確實需要多個代理工具並行,提前為每個工具規劃互不重疊的連接埠區間,而不是等報錯了再臨時改。
常見問題
改了連接埠之後,用戶端還是提示連接埠被佔用,是為什麼?
先確認設定檔儲存路徑和用戶端實際載入的設定檔是同一個檔案——有些用戶端支援多設定切換,改的可能不是目前生效的那份。另外要檢查新填的連接埠是否恰好又撞上了別的服務,可以換一個更冷門的四位或五位數連接埠重試,並用前文的命令再查一次該連接埠是否空閒。
結束佔用連接埠的程序安全嗎,會不會影響系統?
如果確認佔用方是殘留的 Clash 程序或其他可以重新啟動的一般應用程式,結束它是安全的。但如果 lsof/netstat 顯示佔用方是系統級服務或不熟悉的程序,建議先搜尋該程序名稱確認用途,或者直接選擇給 Clash 換連接埠,避免誤殺系統服務。
手機端(Android/iOS)也會出現連接埠佔用問題嗎?
行動端沙盒機制更嚴格,連接埠衝突主要出現在同時執行多個 VPN/代理類應用程式時,系統通常只允許一個 VPN 設定生效。遇到連線失敗,先檢查是否有其他代理類 App 正在背景執行 VPN 服務,關閉其一即可,處理邏輯比桌面端簡單。