Clash 連接埠被佔用怎麼辦：定位衝突程序與修改監聽連接埠完整流程

先確認衝突的是哪個監聽連接埠

Clash、Clash Meta（mihomo）或圖形化客戶端啟動失敗時，日誌中常見的關鍵訊息包括 bind: address already in use、listen tcp 127.0.0.1:7890 或 Only one usage of each socket address is normally permitted。這些訊息都指向同一類問題：核心準備監聽本機連接埠，但該位址與連接埠組合已被另一個程序佔用。

不要看到 7890 就直接修改設定。先閱讀完整日誌，確認失敗的是 HTTP、SOCKS、混合代理、控制器還是 DNS 監聽。不同連接埠負責的功能不同，修改後需要同步調整的客戶端設定也不一樣。

日誌中的位址也要一起查看

• 127.0.0.1:7890：只監聽 IPv4 本機迴路位址，區域網路裝置無法直接存取。
• 0.0.0.0:7890：監聽所有 IPv4 網路介面，通常與客戶端中的「允許區域網路」有關。
• [::]:7890：監聽所有 IPv6 介面。在部分系統上，也可能影響相同連接埠的 IPv4 監聽。
• 127.0.0.1:9090：通常是外部控制器，不是瀏覽器應填寫的代理連接埠。

連接埠號碼相同但監聽位址不同，不一定會發生衝突；能否並存取決於作業系統、IPv6 雙堆疊行為與程式設定。排查時應同時記錄通訊協定、監聽位址、連接埠與程序 ID，而不是只記一個數字。

Windows 使用 netstat 找出連接埠佔用程序

Windows 10 與 Windows 11 都能直接使用系統內建的 netstat。先完全關閉 Clash 客戶端，再以一般權限開啟 PowerShell 或命令提示字元，確認 7890 是否仍有監聽者。

步驟一：尋找 7890 的監聽記錄

netstat -ano | findstr :7890

輸出可能包含多行。請重點尋找狀態為 LISTENING 的 TCP 記錄，最後一欄是 PID。例如以下範例的 PID 為 14672：

TCP    127.0.0.1:7890    0.0.0.0:0    LISTENING    14672

findstr :7890 也會比對正在連線到遠端 7890 連接埠的記錄，因此不能只看連接埠數字。必須確認 7890 位於「本機位址」欄位，且狀態為 LISTENING。

步驟二：將 PID 對應至程式

tasklist /FI "PID eq 14672"

如果回傳 mihomo.exe、clash.exe 或其他代理客戶端的核心檔案，通常表示舊執行個體尚未退出。若回傳開發伺服器、容器連接埠轉送工具或其他本機網路程式，則需要判斷哪個程式更適合修改連接埠。

也可以開啟「工作管理員」→「詳細資料」，點選 PID 欄排序後尋找 14672。工作管理員預設未顯示 PID 時，請在表頭按右鍵選擇「選取欄」→「PID（處理程序識別碼）」。

步驟三：使用 PowerShell 分別檢查 TCP 與 UDP

Get-NetTCPConnection -LocalPort 7890 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

Get-Process -Id 14672

DNS、TProxy 或部分轉送入口也可能使用 UDP。檢查 UDP 端點時，請執行：

Get-NetUDPEndpoint -LocalPort 1053 |
  Select-Object LocalAddress, LocalPort, OwningProcess

UDP 沒有 LISTENING 狀態，因此不能直接套用 TCP 的篩選條件。如果 Clash 日誌明確寫著 listen udp，應使用 Get-NetUDPEndpoint 或 netstat -ano -p udp。

步驟四：優先正常退出，不要直接強制結束

1. 如果佔用者是另一個代理客戶端，請從其系統匣選單選擇退出。
2. 如果佔用者以 Windows 服務執行，請開啟 services.msc，找到對應服務後將其停止。
3. 確認程序不再負責下載、容器轉送或開發工作後，再考慮結束程序。
4. 重新執行 netstat -ano | findstr :7890，確認監聽記錄已消失。

強制結束程序只能解除目前的佔用。如果該程式設定了開機啟動、服務自動復原或當機後重新啟動，連接埠會在幾秒後再次出現。此時應修改啟動項目，或為其中一個程式分配固定的新連接埠。

macOS 與 Linux 使用 lsof、ss 找出衝突

macOS 可以使用系統內建的 lsof 檢查監聽者。關閉 Clash 圖形化客戶端後，開啟「終端機」，執行以下命令：

lsof -nP -iTCP:7890 -sTCP:LISTEN

-nP 會保留數字格式的位址與連接埠，避免主機名稱解析影響速度。輸出中的 COMMAND 是程式名稱，PID 是程序 ID。需要查看完整啟動參數時，可以繼續執行：

ps -p 14672 -o pid,ppid,user,command

檢查 UDP 監聽可使用：

lsof -nP -iUDP:1053

如果舊核心由客戶端啟動，請先從 macOS 選單列退出客戶端。直接執行 kill 14672 後，客戶端的守護邏輯可能立即重新啟動核心，結果會呈現 PID 改變，但 7890 始終被佔用。

Linux 優先使用 ss

現代 Linux 發行版通常預先安裝 ss。以下命令會顯示監聽 7890 的 TCP 程序：

sudo ss -ltnp 'sport = :7890'

檢查 DNS 監聽或其他 UDP 連接埠：

sudo ss -lunp 'sport = :1053'

如果 mihomo 由 systemd 管理，還要檢查服務狀態。服務名稱取決於安裝方式，常見命令如下：

systemctl --type=service | grep -Ei 'clash|mihomo'
sudo systemctl status mihomo

確認是重複服務後，使用對應的服務名稱停止舊執行個體，再決定是否停用自動啟動。不了解用途時，不要直接刪除服務檔案，因為服務設定可能還包含 TUN 權限、路由初始化與防火牆清理步驟。

修改 mixed-port、port 與控制器連接埠

如果衝突程式必須繼續使用原本的連接埠，就為 Clash 分配一個未被佔用的連接埠。建議選擇 1024 以上、目前沒有監聽記錄的連接埠，例如將 7890 改為 17890。連接埠範圍為 1 至 65535，但低於 1024 的連接埠在 macOS 與 Linux 上通常需要額外權限，不適合作為一般桌面客戶端的代理入口。

只使用 mixed-port 的設定

mixed-port 可在同一個連接埠接收 HTTP 代理與 SOCKS5 代理。對於只需要一個本機入口的桌面環境，設定相對直接：

mixed-port: 17890
allow-lan: false
bind-address: 127.0.0.1
external-controller: 127.0.0.1:19090

修改後，系統代理的 HTTP 與 HTTPS 位址都應指向 127.0.0.1:17890。使用 SOCKS5 的應用程式同樣填寫 127.0.0.1:17890，但通訊協定類型要選擇 SOCKS5。

分開監聽 HTTP 與 SOCKS5

port: 17890
socks-port: 17891
allow-lan: false
external-controller: 127.0.0.1:19090

這種寫法適合需要明確區分通訊協定的環境。瀏覽器手動代理或系統 HTTP 代理使用 17890，支援 SOCKS5 的終端機工具使用 17891。不要同時將 mixed-port 與 port 設為相同連接埠，否則核心仍會因重複繫結而啟動失敗。

修改 DNS 監聽連接埠的方法

dns:
  enable: true
  listen: 127.0.0.1:11053
  enhanced-mode: fake-ip

將 DNS 從 1053 改為 11053 後，依賴該監聽位址的轉送器也要同步修改。例如本機 dnsmasq、路由規則或客戶端的 DNS 劫持設定若仍指向 1053，網域請求不會自動轉送到新連接埠。

在圖形化客戶端中修改時，請留意設定來源

不同客戶端的選單名稱可能有所不同。常見入口是「設定」→「參數設定」→「連接埠設定」，或「設定」→「Clash 設定」→「混合連接埠」。儲存後應執行一次「重新啟動核心」，而不只是關閉設定視窗。

如果連接埠來自訂閱設定，直接編輯目前的 YAML 可能會在更新訂閱後被覆蓋。更穩定的做法是使用客戶端提供的覆寫功能，例如「設定」→「覆寫」→「連接埠」，將本機連接埠值設為持久設定。若客戶端沒有覆寫功能，應記錄修改項目，並在訂閱更新後檢查連接埠是否恢復。

修改後驗證連接埠、系統代理與實際連線

設定成功儲存不代表問題已經解決。完整驗證應包含四個步驟：確認舊連接埠已釋放、確認新連接埠開始監聽、確認系統代理已同步更新，最後發起一次實際的代理請求。

1. 確認新連接埠處於監聽狀態

Windows 執行：

netstat -ano | findstr :17890
Test-NetConnection 127.0.0.1 -Port 17890

Test-NetConnection 的結果中，TcpTestSucceeded 應為 True。macOS 或 Linux 可執行：

lsof -nP -iTCP:17890 -sTCP:LISTEN

同時再次檢查 7890。如果舊連接埠仍由另一個程式監聽，不一定會影響 Clash，但這能證明最初的衝突來源確實仍在，新舊程式目前透過不同連接埠並存。

2. 檢查系統代理是否仍指向舊連接埠

• Windows 11：進入「設定」→「網路和網際網路」→「代理伺服器」，檢查手動代理伺服器的連接埠。
• macOS：進入「系統設定」→「網路」→目前使用的網路→「詳細資訊」→「代理伺服器」，檢查網頁代理與安全網頁代理。
• 瀏覽器擴充功能：檢查代理設定檔中的 HTTP、HTTPS 或 SOCKS5 連接埠。
• 終端機環境變數：檢查 HTTP_PROXY、HTTPS_PROXY 與 ALL_PROXY 是否仍包含 7890。

多數 Clash 圖形化客戶端啟用「系統代理」後會自動寫入新連接埠，但手動設定的瀏覽器、開發工具與命令列環境不會自動更新。修改連接埠後若出現「客戶端顯示正在執行，瀏覽器卻無法存取」的情況，通常就是呼叫端仍在連線到舊連接埠。

3. 使用 curl 發起明確的代理請求

curl -I -x http://127.0.0.1:17890 https://example.com

如果使用獨立的 SOCKS5 連接埠 17891，可以執行：

curl -I --socks5-hostname 127.0.0.1:17891 https://example.com

命令能夠回傳 HTTP 回應標頭，表示本機連接埠接受連線、代理協定相符，且請求已完成。若出現 Connection refused，表示新連接埠沒有監聽；若長時間逾時，應繼續檢查節點、策略組、DNS 與網路連通性；若回傳協定錯誤，可能是將 HTTP 客戶端連到只接受 SOCKS5 的連接埠。

4. 觀察核心日誌與連線清單

開啟客戶端的「日誌」頁面，將層級設為 info。發起測試請求時，應看到目標網域、符合的規則與最終策略，例如網域符合 DOMAIN-SUFFIX 後轉送到某個代理群組。接著開啟「連線」頁面，確認來源位址為 127.0.0.1，並檢查上傳、下載位元組數是否變化。

連接埠衝突反覆出現時的排查順序

修改連接埠後過一段時間再次發生衝突，通常表示系統中存在自動啟動或設定覆蓋。依照以下順序檢查，比反覆更換連接埠更容易找到根本原因。

1. 檢查是否有兩個 Clash 客戶端同時設定為自動啟動。例如舊客戶端仍保留在登入項目，新客戶端也設定了開機啟動，兩者都會嘗試監聽 7890。
2. 檢查 GUI 與獨立核心服務是否重複。圖形化客戶端已經管理 mihomo 時，不應再讓 systemd、launchd 或 Windows 服務啟動另一份相同設定。
3. 檢查訂閱更新後的覆寫結果。更新前是 17890，更新後又變回 7890，表示本機修改沒有納入持久覆寫。
4. 檢查 external-controller。代理連接埠正常但介面持續提示連線失敗時，衝突點可能是 9090，而不是 7890。
5. 檢查 DNS 的 TCP 與 UDP。某些 DNS 服務會同時監聽兩種協定，只檢查 TCP 可能漏掉 UDP 1053 的佔用。
6. 檢查允許區域網路造成的監聽範圍變化。從 127.0.0.1 切換到 0.0.0.0 後，新監聽會涵蓋更多介面，可能與既有服務發生衝突。

一套可長期使用的連接埠規劃

連接埠號碼本身不會影響規則比對、節點延遲或代理速度。關鍵在於確保每個監聽位址只由預期程序使用，並讓系統代理、瀏覽器、DNS 轉送器與控制面板採用相同的新設定。完成修改後保留一份連接埠記錄，日後升級客戶端、切換核心或更新訂閱時即可快速核對。