Clash 連接埠遭佔用導致啟動失敗：找出佔用程序並修改混合連接埠

先確認是否為連接埠衝突

Clash、Clash Meta（mihomo）核心啟動時，需要在本機監聽一個或多個連接埠。常見設定會將 mixed-port 設為 7890，讓同一個連接埠同時接受 HTTP 與 SOCKS5 代理連線。如果該連接埠已被其他程序監聽，新啟動的核心便無法再次繫結；用戶端可能停留在「啟動中」，也可能直接顯示核心啟動失敗。

當日誌出現以下類型的訊息時，通常可以優先檢查連接埠。不同核心版本與作業系統的措辭略有差異，但關鍵字通常包含 bind、address already in use、Only one usage 或具體的連接埠號碼。

listen tcp 127.0.0.1:7890: bind: address already in use

listen tcp 0.0.0.0:7890:
bind: Only one usage of each socket address is normally permitted

不要只檢查 7890。設定中還可能有獨立的 HTTP 連接埠、SOCKS 連接埠、透明代理連接埠與外部控制連接埠。例如，某份設定可能同時使用 port: 7890、socks-port: 7891 與 external-controller: 127.0.0.1:9090。日誌指出哪個位址繫結失敗，就檢查哪個連接埠。

連接埠衝突與連線失敗並不是同一回事

• 連接埠衝突：核心無法啟動，日誌顯示監聽或繫結失敗。
• 節點連線失敗：核心已經啟動，但代理節點逾時，日誌通常會指向遠端位址。
• 系統代理未更新：核心監聽正常，但瀏覽器仍連線至舊連接埠，表現為網頁無法開啟。
• 控制連接埠衝突：代理連接埠可用，但圖形介面無法連線至核心，常見涉及 external-controller 的 9090 或其他自訂連接埠。

先在用戶端日誌中找出完整錯誤訊息，再檢查對應連接埠，可以避免將節點故障誤判為本機連接埠問題。若日誌顯示的是設定解析錯誤，例如 YAML 縮排錯誤或欄位類型錯誤，修改 7890 並不能解決啟動失敗。

Windows：使用 netstat 找出佔用程序

Windows 10 與 Windows 11 都內建 netstat。請先完全退出 Clash Nyanpasu，再以一般權限開啟「終端機」或「命令提示字元」，執行以下命令：

netstat -ano | findstr :7890

如果連接埠正在被監聽，結果可能如下所示。最後一欄 18432 是程序 PID，不是連接埠號碼。

TCP    127.0.0.1:7890    0.0.0.0:0    LISTENING    18432
TCP    [::1]:7890        [::]:0       LISTENING    18432

接著將查到的 PID 傳給 tasklist，確認程序名稱：

tasklist /FI "PID eq 18432"

如果回傳的是其他代理用戶端、舊版 Clash 核心或仍在背景執行的桌面用戶端，應先從該程式本身的退出選單正常關閉。若只是異常殘留程序，確認名稱與 PID 後即可結束：

taskkill /PID 18432 /F

使用 PowerShell 查看更清楚的結果

PowerShell 可以直接回傳擁有該監聽連接埠的程序 ID。Windows 11 的「終端機」預設通常就是 PowerShell：

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

取得 OwningProcess 後，繼續查詢程序：

Get-Process -Id 18432

如果 Clash 設定還啟用了 UDP 監聽，TCP 查詢沒有結果並不能完全排除衝突。可以補充檢查 UDP：

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

根據監聽位址判斷影響範圍

同一個 PID 同時出現兩行，通常不代表有兩個衝突程序，而是該程式分別監聽 IPv4 與 IPv6。真正需要確認的是，擁有該連接埠的程序是否為目前準備啟動的核心，以及系統中是否殘留另一個實例。

macOS 與 Linux：使用 lsof、ss 查詢連接埠

macOS 可以在「應用程式」→「工具程式」→「終端機」中執行 lsof。以下命令只查看 TCP 7890，並篩選監聽狀態：

lsof -nP -iTCP:7890 -sTCP:LISTEN

輸出中的 COMMAND 是程序名稱，PID 是程序編號。例如：

COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
mihomo   4217 user   11u  IPv4  0x01      0t0  TCP 127.0.0.1:7890 (LISTEN)

先回到選單列，檢查是否仍有 Clash 用戶端正在執行。確認是已失去介面控制的殘留程序後，可以先傳送正常終止訊號：

kill 4217

等待兩秒後再次執行 lsof。只有在程序未退出且身分已確認無誤時，才考慮強制結束：

kill -9 4217

Linux 優先使用 ss

多數現代 Linux 發行版預裝 ss。若要查看 TCP 7890 的監聽程序，可以執行：

sudo ss -lptn 'sport = :7890'

檢查 UDP 時使用：

sudo ss -lpun 'sport = :7890'

如果系統已安裝 lsof，也可以使用跨平台寫法：

sudo lsof -nP -i :7890

在 Linux 上還要留意 systemd 服務。手動執行的圖形用戶端退出後，系統層級的 mihomo 服務可能仍在背景監聽。可以先查詢服務狀態，再決定是否停止：

systemctl status mihomo
sudo systemctl stop mihomo

服務名稱取決於實際安裝方式，也可能是 clash 或自訂單元名稱。未確認服務用途前，不要直接停用。如果這項服務就是日常使用的代理核心，更合適的做法是保留它，並讓圖形用戶端使用另一組連接埠。

在 Clash Nyanpasu 中修改混合連接埠

如果佔用 7890 的程式必須繼續執行，可以為 Clash Nyanpasu 更換一個尚未使用的連接埠。常見操作路徑是「設定」→「Clash 設定」→「一般」→「混合連接埠（Mixed Port）」。介面名稱會隨版本調整，但應在核心或 Clash 參數區域尋找 mixed-port。

1. 先使用 netstat、lsof 或 ss 檢查預計使用的新連接埠，例如 7893。
2. 將混合連接埠從 7890 改為 7893。
3. 儲存設定，並執行一次核心重新啟動，或完全退出後重新開啟用戶端。
4. 回到日誌，確認出現監聽 127.0.0.1:7893 的紀錄。
5. 重新啟用系統代理，讓作業系統中的代理位址同步至新連接埠。

建議優先選擇 1024 以上且目前未被監聽的連接埠。連接埠號碼最大為 65535。不要為了避開衝突而改用 80、443 等低號連接埠；這些連接埠可能需要額外權限，也更容易與 Web 服務發生衝突。

為什麼修改連接埠後仍然無法開啟網頁

連接埠修改成功，只代表核心已能進行監聽。瀏覽器、終端機與其他應用程式仍需連線至新的連接埠。如果系統代理仍儲存為 127.0.0.1:7890，請求就會繼續傳送至舊位址。最直接的處理方式是先關閉一次「系統代理」，再重新啟用，讓用戶端寫入 127.0.0.1:7893。

終端機中的環境變數不一定會隨系統代理自動更新。如果先前曾手動設定代理，還需要同步修改：

export HTTP_PROXY=http://127.0.0.1:7893
export HTTPS_PROXY=http://127.0.0.1:7893
export ALL_PROXY=socks5://127.0.0.1:7893

使用混合連接埠時，同一個 7893 可以接受 HTTP 代理與 SOCKS5 代理連線，因此上述寫法可以共用連接埠。如果設定採用獨立的 port 與 socks-port，就應分別填入對應連接埠，不能全部照搬 7893。

直接修改設定檔中的 mixed-port

使用 mihomo 命令列、容器或自行管理設定檔時，可以直接編輯 YAML。最簡寫法如下：

mixed-port: 7893
allow-lan: false
mode: rule
log-level: info

mixed-port 是 HTTP 與 SOCKS5 共用的入站連接埠。已使用此欄位時，通常不需要再同時設定相同數值的 port 與 socks-port。重複或重疊的監聽設定可能再次觸發繫結失敗，也會增加排查難度。

如果確實需要分開提供 HTTP 與 SOCKS5 連接埠，可以使用不同數值：

port: 7893
socks-port: 7894
allow-lan: false
mode: rule
log-level: info

外部控制介面也必須使用獨立連接埠。例如：

mixed-port: 7893
external-controller: 127.0.0.1:9091
secret: "change-this-controller-secret"

這裡將代理入口設為 7893，控制介面設為 9091。兩者用途不同：7893 接收應用程式的代理流量，9091 供圖形介面或控制面板呼叫核心 API。如果日誌明確顯示 9090 遭佔用，只修改 mixed-port 不會有效，應修改 external-controller，並同步更新用戶端的控制器連線設定。

修改後先驗證設定，再重新啟動核心

從命令列執行 mihomo 時，可以先使用核心提供的設定檢查參數。實際可執行檔名稱取決於安裝方式：

mihomo -t -f config.yaml

確認檢查通過後，再依原方式啟動。如果仍然失敗，請讀取完整日誌，並確認錯誤訊息中的連接埠是否已變更為 7893。日誌仍顯示 7890，通常表示目前啟動的不是剛才編輯的設定檔，或圖形用戶端在啟動時重新產生了執行設定。

修改連接埠後仍啟動失敗的五項檢查

1. 新連接埠也已遭佔用

不要只憑感覺選擇 7891 或 7892，這些也是代理工具常用的連接埠。修改前請先執行查詢命令。Windows 可執行 netstat -ano | findstr :7893，macOS 可執行 lsof -nP -iTCP:7893 -sTCP:LISTEN。沒有輸出通常表示目前沒有 TCP 監聽者，但啟用 UDP 入站時仍需檢查 UDP。

2. 用戶端同時啟動了兩個核心

自動啟動、服務模式與手動啟動可能形成重複實例。請先完全退出用戶端，確認 7890、7893 與控制連接埠都已釋放，再只啟動一次。如果用戶端退出後連接埠立即再次出現，應檢查系統啟動項目、排程工作、登入項目或 systemd 服務。

3. 設定覆寫並未真正生效

訂閱中的 mixed-port: 7890 可能被用戶端全域設定覆寫，反過來也可能由啟動參數覆寫設定檔。判斷依據應是執行日誌與實際監聽結果，而不只是編輯器中的 YAML。啟動後再次查詢連接埠，確認核心實際監聽的是哪個位址。

4. 外部控制連接埠衝突

代理連接埠空閒，不代表所有監聽都能建立。請檢查日誌是否指向 127.0.0.1:9090、9091 或其他控制連接埠。修改控制連接埠後，圖形介面的連線位址也要同步，否則核心可能已經執行，但面板會顯示「未連線」。

5. 監聽位址或權限不適用

啟用 allow-lan 後，設定可能監聽 0.0.0.0 或指定的區域網路位址。如果該位址已失效，日誌可能顯示「cannot assign requested address」，這不是一般的連接埠佔用。請將監聽位址恢復為有效介面，或僅監聽 127.0.0.1 後再試。使用低於 1024 的連接埠時，也可能遇到權限不足，應改用較高的連接埠。

避免 7890 再次發生衝突的設定習慣

• 只保留一個自動啟動入口：圖形用戶端、背景服務與排程工作不要同時負責啟動核心。
• 為不同用戶端分配不同連接埠：例如主要用戶端使用 7890，測試實例使用 7893，容器實例使用 7895。
• 記錄控制連接埠：將代理連接埠與 external-controller 分開記錄，排錯時依日誌逐項查詢。
• 退出後檢查系統匣：關閉視窗不一定會結束程序，升級或切換用戶端前應使用完整退出操作。
• 讓用戶端管理系統代理：修改混合連接埠後重新切換系統代理，減少舊連接埠殘留。
• 將本機連接埠放在持久化設定中：訂閱負責節點與規則，本機監聽連接埠則由用戶端覆寫或全域設定管理。

如果同一台裝置需要同時執行多個 mihomo 實例，還應為每個實例分配不同的混合連接埠、控制連接埠與執行目錄。僅修改 7890 不足以隔離所有資源；快取、資料庫、Unix socket 或命名管道也可能需要獨立路徑，具體取決於啟動方式與用戶端實作。

快速排查順序

1. 開啟用戶端日誌，記下繫結失敗的完整位址與連接埠。
2. 完全退出 Clash Nyanpasu，觀察連接埠是否隨之釋放。
3. Windows 使用 netstat 或 PowerShell，macOS 使用 lsof，Linux 使用 ss 查詢 PID。
4. 確認程序名稱，正常退出重複用戶端或停止重複服務。
5. 佔用程式必須保留時，將 mixed-port 改為已確認空閒的 7893 等連接埠。
6. 同時檢查 external-controller，避免只解決代理連接埠衝突。
7. 重新啟動核心，並透過日誌與監聽結果確認新設定已生效。
8. 重新啟用系統代理，更新終端機環境變數及手動填寫連接埠的應用程式。

連接埠遭佔用，本質上是本機監聽資源衝突。排查重點不是反覆重新安裝用戶端，而是從日誌找出連接埠，用系統命令定位 PID，再決定結束佔用程序或調整設定。完成修改後，別忘了同步更新系統代理與終端機環境變數，否則核心雖然恢復執行，應用程式仍會繼續存取舊連接埠。