Clash 連接埠被佔用怎麼辦:7890 衝突排查與修改監聽連接埠全流程

連接埠衝突是怎麼發生的

Clash 核心(無論是原版 Clash 還是 Mihomo)啟動時會綁定一個本機連接埠來接收代理流量,常見預設值是 7890。這個連接埠在設定檔裡對應 mixed-port 欄位(早期版本分成 port 和 socks-port 兩個欄位,現在多數客戶端已統一為 mixed-port,同時支援 HTTP 與 SOCKS5 協定)。當系統裡已經有另一個進程佔用了這個連接埠,核心綁定監聽連接埠時就會失敗,日誌裡通常會出現類似下面的訊息:

ERRO[0000] Start HTTP server error: listen tcp 127.0.0.1:7890: bind: address already in use

這種錯誤的本質很簡單:同一個連接埠在同一時刻只能被一個進程獨佔監聽。造成衝突的原因常見有三類。第一類是重複啟動,例如上一次 Clash 進程沒有正常退出就直接又開了一個新實例,舊進程還佔著連接埠。第二類是連接埠被其他軟體搶先佔用,常見的有其他代理工具(如 v2ray、trojan、其他 Clash 分支客戶端)、開發環境裡的本機服務,甚至某些容器映射出來的連接埠。第三類是同一台機器上跑了兩套 Clash 相關服務,例如系統層級的 clash 服務與使用者手動跑的測試實例同時存在。

無論原因是哪一種,處理思路都是一樣的:先找出到底是誰佔用了連接埠,再決定結束它還是讓 Clash 換個連接埠。

用 ss / lsof / netstat 排查佔用進程

Linux 下有三個常用工具可以查看連接埠佔用情況,任選一個即可,建議優先用 ss,它是目前主流發行版內建且效能最好的方式。

方法一:ss 指令

sudo ss -tulnp | grep 7890

輸出裡能看到本機位址、連接埠以及佔用該連接埠的進程名稱和 PID,類似:

tcp   LISTEN 0      4096   127.0.0.1:7890   0.0.0.0:*   users:(("mihomo",pid=8123,fd=12))

括號裡的 pid=8123 就是佔用連接埠的進程 ID,"mihomo" 是進程名稱。如果這裡顯示的正是 Clash 自己的核心進程(mihomo 或 clash),表示上一次實例沒退乾淨,直接結束舊進程再重新啟動客戶端即可。

方法二:lsof 指令

如果系統沒裝 ss,或習慣用 lsof,可以這樣查:

sudo lsof -i :7890

輸出會列出 COMMAND、PID、USER 等欄位,同樣能拿到佔用進程的名稱和 PID。lsof 在部分極簡發行版上需要另外安裝,Ubuntu/Debian 系可用 sudo apt install lsof,Fedora 系用 sudo dnf install lsof。

方法三:netstat 指令

netstat 在新版發行版裡逐漸被 ss 取代,但許多腳本和舊教學仍在用,查法如下:

sudo netstat -tulnp | grep 7890

三種指令拿到的資訊本質一致,選一個能在自己系統上跑起來的即可,不需要都裝。

判斷該結束進程還是改連接埠

找出佔用者之後,處理方式取決於這個進程是什麼。

• 是 Clash/Mihomo 自己的殘留進程:表示上一次沒有正常退出,直接結束這個 PID,再重新啟動客戶端即可,不用改任何設定。

  sudo kill 8123
  # 若一般終止無效再用
  sudo kill -9 8123

• 是其他代理工具或長期執行的服務:這類進程通常有明確用途,不建議隨意結束,更穩妥的做法是讓 Clash 換一個不衝突的連接埠。
• 是不認識、無法判斷用途的進程:先用 ps -p PID -o comm=,args= 查看完整啟動指令,確認是否為系統關鍵服務(例如某些容器網路元件、資料庫用戶端代理),不確定就優先選擇改連接埠而不是結束進程,避免影響其他正在使用的服務。

一般經驗是:如果衝突方是 Clash 自己的舊進程,結束它是最乾淨的做法;如果衝突方是無關的第三方服務,改連接埠比結束進程更安全,尤其是在伺服器或多人共用的機器上,隨意砍掉不熟悉的進程風險更高。

修改 mixed-port 並重啟核心

確定要改連接埠後,找到 Clash 的設定檔(GUI 客戶端一般在設定裡能看到設定檔路徑,命令列部署常見路徑類似 ~/.config/clash/config.yaml 或 /etc/clash/config.yaml),把 mixed-port 改成一個未被佔用的連接埠,例如 7891:

mixed-port: 7891
allow-lan: false
bind-address: "*"
mode: rule
log-level: info

如果你的設定檔裡還保留著舊式的 port 和 socks-port 分離寫法,同樣要一起改掉,並確認沒有其他地方還寫著舊連接埠號碼:

port: 7891
socks-port: 7892

改完連接埠之後,新的連接埠號碼本身也要先確認沒有被佔用,可以重複上一步的 ss -tulnp | grep 連接埠號碼 檢查一遍,避免改了半天還是撞上另一個衝突。確認無誤後,重新啟動 Clash 服務或客戶端使設定生效:

# systemd 管理的情境
sudo systemctl restart clash

# 手動執行核心的情境,先結束舊進程再重新啟動
sudo pkill mihomo
mihomo -d /etc/clash

重新啟動後再看一次啟動日誌,確認沒有再出現 bind: address already in use 的錯誤,同時確認監聽連接埠已經切換成功:

sudo ss -tulnp | grep mihomo

同步更新系統代理設定

改完 mixed-port 只是讓核心換了個地方監聽,如果作業系統或瀏覽器的代理設定裡還寫著舊連接埠號碼,流量依然打不通,這一步經常被漏掉,導致排查者以為改連接埠沒生效。

GNOME 桌面環境

gsettings set org.gnome.system.proxy mode 'manual'
gsettings set org.gnome.system.proxy.http host '127.0.0.1'
gsettings set org.gnome.system.proxy.http port 7891
gsettings set org.gnome.system.proxy.https host '127.0.0.1'
gsettings set org.gnome.system.proxy.https port 7891

也可以在「設定 → 網路 → 網路代理」的圖形介面裡直接把連接埠號碼改成新值。

命令列環境變數

如果習慣用環境變數方式走代理,同樣要把連接埠改掉,建議寫進 ~/.bashrc 或 ~/.zshrc 裡長期生效:

export http_proxy="http://127.0.0.1:7891"
export https_proxy="http://127.0.0.1:7891"
export all_proxy="socks5://127.0.0.1:7891"

改完記得執行 source ~/.bashrc 讓目前終端機立即生效,否則已經開啟的終端機視窗仍會使用舊連接埠。

瀏覽器擴充功能

如果透過瀏覽器擴充功能(如 SwitchyOmega 一類的代理切換工具)設定代理規則,同樣要進擴充功能設定裡把連接埠號碼從 7890 改成新連接埠,擴充功能連接埠和系統連接埠是兩套獨立設定,互不連動。

其他容易被忽略的細節

• 開機自動啟動腳本裡的舊連接埠號碼:如果用 systemd 或其他方式設定了開機自動啟動,腳本或環境變數檔案裡可能單獨寫死了連接埠號碼,只改設定檔裡的 mixed-port 是不夠的,啟動腳本要同步檢查。
• 外部控制面板連接埠:設定裡的 external-controller(通常是 9090)是 Clash 的 API 管理連接埠,和代理連接埠 mixed-port 是兩個獨立的欄位,如果 9090 也被佔用會導致面板打不開,處理方式類似,單獨排查即可。
• 多使用者共用一台機器:如果同一台伺服器有多個使用者各自跑了一份 Clash 設定,建議每個使用者使用不同的連接埠區間,避免頻繁衝突,例如約定 7890~7899 給使用者 A,7900~7909 給使用者 B。
• Docker 容器情境:如果 Clash 跑在容器裡,連接埠衝突還可能發生在主機的連接埠映射層,這時要查的是主機上 docker ps 裡的連接埠映射設定,而不是容器內部的 mixed-port。

常見問題

改了連接埠後瀏覽器還是連不上代理? 大概率是系統代理設定或瀏覽器擴充功能裡的連接埠號碼沒有同步改,回到上面「同步更新系統代理設定」章節逐項核對。

為什麼每次重新開機都會遇到一次連接埠衝突? 檢查是否設定了開機自動啟動的 Clash 服務,同時手動又習慣性雙擊圖示啟動一次客戶端,導致兩個實例先後搶佔同一連接埠,只保留一種啟動方式即可解決。

結束佔用進程後還是無法啟動? 用 ss -tulnp | grep 連接埠號碼 再確認一次連接埠是否真的已經釋放,有些進程結束後連接埠會短暫處於 TIME_WAIT 狀態,等幾秒或換一個連接埠測試即可排除疑慮。