故障排除 預計閱讀 8 分鐘

Clash 啟動報連接埠被佔用怎麼辦:定位佔用處理程序與修改連接埠全流程

7890/9090 連接埠衝突是 Clash 啟動失敗的常見原因。提供 Windows、macOS、Linux 三平台查佔用處理程序的指令,以及在設定檔與用戶端中安全改連接埠的完整步驟。

為什麼會出現「連接埠被佔用」的錯誤

Clash 核心啟動時需要綁定幾個固定連接埠才能對外提供代理服務:混合代理連接埠(通常是 7890,設定欄位名稱為 mixed-port,舊版本可能拆成 port 與 socks-port)、外部控制器連接埠(通常是 9090,欄位名稱 external-controller),部分用戶端還會額外佔用一個 DNS 監聽連接埠。這些連接埠一旦被系統裡其他處理程序提前佔用,作業系統會拒絕再次綁定,核心在日誌裡會報出「address already in use」「bind: 連接埠已被使用」之類的訊息,用戶端表現為啟動按鈕點擊後立刻回彈、連線狀態一直顯示未連線,或者直接彈出錯誤視窗。

造成佔用的來源大致分三類。第一類是「重複啟動」:同一台電腦上裝了兩個 Clash 類用戶端(比如同時裝了 Clash Verge 和 Clash for Windows 的舊版),或者上一次退出沒有徹底結束處理程序,背景仍留有一個殘留實例佔著連接埠。第二類是「連接埠撞車」:其他工具恰好也用了 7890 或 9090,常見的有部分開發偵測代理、企業 VPN 用戶端、路由測試工具,甚至某些資料庫或訊息佇列服務的預設連接埠也可能落在相近區間。第三類是系統層面的連接埠保留,尤其在 Windows 上,某些系統服務會預留一段連接埠區間,恰好把 7890 圈進去,這種情況在工作管理器裡往往看不到直接對應的處理程序名稱。

排查思路統一分兩步:先確認到底是誰佔用了連接埠,再決定「關掉佔用者」還是「幫 Clash 換連接埠」。多數情況下改連接埠更省事,因為不需要動其他軟體的設定,風險也更低。

Windows 下定位佔用處理程序

打開命令提示字元或 PowerShell,先用 netstat 查看連接埠對應的處理程序 ID(PID):

netstat -ano | findstr "7890"

輸出的最後一列數字就是 PID,再用工作管理器或下面的指令反查處理程序名稱:

tasklist | findstr "PID號"

如果 9090 連接埠也報衝突,把指令裡的連接埠號換成 9090 再查一次即可。確認是無關處理程序佔用後,可以直接結束該處理程序,或者打開該軟體的設定改掉它自己的連接埠;如果查出來的處理程序正是 Clash 自身的舊實例(比如 clash-verge.exe 或 mihomo.exe 掛了一個背景殘留),在工作管理器裡手動結束該處理程序後重新啟動用戶端通常就能解決。

注意:部分安全軟體或系統保留連接埠範圍會讓 netstat 查不到具體處理程序(PID 顯示為 0 或系統處理程序),這種情況直接改 Clash 自己的連接埠最省時間,不必糾結找出佔用者。

macOS 下定位佔用處理程序

打開終端機,用 lsof 查看連接埠佔用情況最直接:

lsof -i :7890

輸出裡 COMMAND 欄就是佔用該連接埠的處理程序名稱,PID 欄是處理程序編號。9090 連接埠同理替換數字即可。如果要結束佔用處理程序:

kill -9 對應的PID號

macOS 上比較常見的情況是同時安裝了 Clash Verge 與舊版 ClashX 系列用戶端,兩者預設連接埠一致,只要有一個在背景常駐(比如設定了登入時啟動),另一個再啟動就會衝突。建議在系統設定的登入項目裡檢查一遍,只保留一個預設開機自啟的用戶端。

Linux 下定位佔用處理程序

Linux 系統推薦用 ss 指令(比傳統 netstat 更快、多數現代發行版預設內建):

ss -tulnp | grep 7890

如果系統沒有 ss,可以退回用 netstat 或 lsof:

lsof -i :7890

確認處理程序 PID 後用 kill 結束:

kill -9 對應的PID號

用命令列核心(mihomo/Clash 核心)配合 systemd 管理服務的使用者要特別留意:如果核心是透過 systemd 單元檔啟動的,直接 kill 掉處理程序之後 systemd 可能會按重啟策略自動把它拉起來、再次佔住連接埠,這種情況下應該先用 systemctl stop 停掉對應服務單元,確認連接埠釋放後再排查衝突根源,而不是反覆 kill。

在設定檔裡修改連接埠

如果確認連接埠被無法關閉的其他程式佔用,最乾淨的做法是給 Clash 換一個連接埠,而不是折騰對方軟體。核心設定欄位集中在 config.yaml 頂部:

mixed-port: 7891
allow-lan: false
external-controller: 127.0.0.1:9091
secret: ""

把 mixed-port 改成一個空閒連接埠(建議選 1024~65535 區間內、不與常見服務衝突的數字,比如 7891、17890 均可),external-controller 後面的連接埠號同理修改,注意這裡是「位址:連接埠」的完整寫法,不要漏掉冒號前的監聽位址。部分較舊設定檔仍用分離的 port(HTTP 代理連接埠)與 socks-port(SOCKS5 代理連接埠)兩個欄位而不是合併的 mixed-port,同樣按需改成空閒數字即可,原理一致。

提示:改完連接埠後需要重啟用戶端或重新載入設定才會生效,單純儲存 YAML 檔案、核心不重啟是不會自動生效的。

在用戶端介面裡修改連接埠

如果不想直接編輯 YAML,主流用戶端都在設定介面提供了連接埠輸入框,路徑大致如下:

  1. 打開用戶端設定

    找到「設定」或「一般」分類,定位到「混合連接埠」「HTTP 連接埠」「SOCKS 連接埠」或「代理連接埠」字樣的輸入項。

  2. 填入新連接埠號

    填入一個確認未被佔用的連接埠號,建議先用前面的指令驗證一遍該連接埠目前處於空閒狀態。

  3. 同步修改控制連接埠

    如果用戶端還單獨列出了「外部控制連接埠」或「API 連接埠」(對應 external-controller),也一併改成空閒值,兩者不衝突即可。

  4. 儲存並重啟服務

    儲存設定後,用戶端通常會提示重啟核心或重啟應用程式才能生效,按提示操作即可,不要在提示重啟前反覆點擊連線按鈕。

  5. 核對系統代理設定

    如果系統的網路代理設定裡手動填寫過連接埠號(而非跟隨用戶端自動設定),記得把系統代理裡的連接埠號也同步改成新值,否則流量仍會指向舊連接埠導致連線失敗。

改完連接埠後如何驗證生效

重啟用戶端後,先用命令列確認新連接埠已經處於監聽狀態,而不是直接打開瀏覽器測試(瀏覽器測試受系統代理設定、DNS 快取等因素干擾,不夠直接)。Windows 下繼續用 netstat -ano | findstr "新連接埠號",能看到 LISTENING 狀態即表示核心已經成功綁定。macOS 和 Linux 下用 lsof -i :新連接埠號,能查到對應的 Clash 核心處理程序名稱(常見為 mihomo、clash-meta 或用戶端自帶的核心執行檔名稱)即為正常。

確認監聽正常後,再檢查系統代理或瀏覽器擴充功能裡填寫的連接埠號是否與新連接埠一致,兩端對齊才能真正連通。如果用的是控制面板類用戶端自帶的「測試連線」或「延遲檢測」功能,此時應該能正常返回結果,不再報連線被拒絕。

預防連接埠衝突的幾個習慣

為了減少下次再遇到同樣問題,可以養成幾個小習慣:一是同一台裝置盡量只保留一個 Clash 類用戶端,升級新版本前先卸載或完全退出舊版本,避免兩者常駐背景互相打架;二是如果電腦上還跑著別的代理工具或需要固定使用某些連接埠的開發環境,提前把 Clash 的連接埠設成一個明顯不常用的數字(比如五位數的高位連接埠),從源頭上避開撞車;三是每次修改連接埠設定後,順手記一下改成了什麼值,方便下次排查時對照,尤其是團隊共用設定檔的情境,連接埠號變動最好在設定檔開頭加一行註解說明。

如果連接埠衝突反覆出現在同一個程式上(比如某個固定安裝的企業軟體長期佔著 9090),更徹底的做法是直接把 Clash 的預設連接埠永久改掉,而不是每次都臨時挪位置,這樣設定檔和用戶端設定只需要改一次,長期使用不會再被打斷。

下載用戶端