Clash 連接埠被佔用怎麼辦：程序定位與連接埠修改

先確認錯誤是否屬於連接埠衝突

Clash 啟動核心時，需要在本機位址上建立一個或多個監聽連接埠。瀏覽器、系統代理或其他應用程式會將請求送到這些連接埠，再由核心依照代理群組與規則處理流量。如果相同網路協定、相同監聽位址與相同連接埠已被其他程序佔用，新的監聽通常會建立失敗。

常見情況包括：客戶端介面可以開啟，但核心立即停止；系統代理按鈕可以切換，網頁卻無法存取；日誌出現 address already in use、bind、listen tcp 或「連接埠已被佔用」等訊息。部分圖形化客戶端會反覆嘗試啟動核心，因此日誌中可能連續出現相同錯誤。

不要只因為「無法連線」就直接修改連接埠。設定解析錯誤、訂閱內容失效、代理節點無法使用、系統代理未啟用，以及防火牆限制，都可能造成類似現象。判斷連接埠衝突時，應先找出日誌中的完整位址，例如 127.0.0.1:7890、0.0.0.0:7890 或 :9090。冒號後的數字才是需要檢查的連接埠。

連接埠衝突與權限錯誤的差異

「位址已被使用」通常表示已有監聽程序；「權限不足」或 permission denied 則不一定代表連接埠已被佔用。低號連接埠、系統保留連接埠、安全軟體政策或作業系統排除的連接埠範圍，都可能阻止繫結。日常設定建議從未被佔用的高號連接埠中選擇，並避免任意使用常見服務連接埠。

分辨 mixed-port、port 與 socks-port

處理衝突前，應先確認錯誤對應哪個設定欄位。不同欄位面向不同協定，修改後需要同步的應用程式也不同。Clash 與 mihomo 常見的監聽項目如下。

桌面客戶端最常見的衝突是 mixed-port。例如客戶端甲仍在背景佔用 7890，客戶端乙也嘗試使用 7890，後啟動的核心就無法建立監聽。另一個容易忽略的情況是代理連接埠正常，但 external-controller 使用的 9090 已被佔用，結果表現為圖形介面無法連線至核心，或無法讀取執行狀態。

不要同時保留用途重疊且連接埠數字相同的欄位。例如將 mixed-port 與 port 都設為 7890，會讓同一個核心內部發生繫結競爭。若主要使用一般桌面系統代理，保留一個 mixed-port 通常更容易維護；只有明確需要分開 HTTP 與 SOCKS5 入口時，才分別設定 port 和 socks-port。

在 Windows、macOS 與 Linux 找出監聽程序

從日誌確認連接埠後，下一步是查出目前由誰監聽。檢查前應先完全退出目前的 Clash 客戶端，等待幾秒後再執行命令。如果連接埠仍處於監聽狀態，表示佔用者可能是另一套代理客戶端、殘留的核心程序、開發伺服器、容器映射或系統服務。

Windows：從連接埠找出 PID

在命令提示字元中檢查 TCP 連接埠 7890：

netstat -ano | findstr :7890

結果最後一欄是 PID。請優先查看狀態為 LISTENING 的記錄，再用 PID 查詢程式名稱：

tasklist /FI "PID eq 1234"

PowerShell 也能直接列出擁有該監聽連接埠的程序：

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

Get-Process -Id 1234

如果命令提示權限不足，可以使用具備相應權限的終端機重試。看到多筆記錄時，要比較本機位址。有些程式會分別監聽 IPv4 與 IPv6，工作管理員中看起來只有一個程序，但命令會顯示兩筆監聽記錄。

macOS：使用 lsof 查看監聽程序

lsof -nP -iTCP:7890 -sTCP:LISTEN

輸出中的 COMMAND 是程序名稱，PID 是程序編號。如果一般權限無法顯示完整資訊，確認命令內容後可以使用：

sudo lsof -nP -iTCP:7890 -sTCP:LISTEN

在 macOS 上關閉視窗不一定等於退出客戶端。應檢查選單列的狀態項目，並透過客戶端的退出命令結束主程式。若主程式退出後核心程序仍存在，再依據 PID 與程式路徑判斷它屬於哪一套客戶端。

Linux：同時核對 TCP 與 UDP

sudo ss -ltnp | grep ':7890 '
sudo ss -lunp | grep ':7890 '

第一個命令檢查 TCP，第二個命令檢查 UDP。一般 HTTP、SOCKS5 與控制介面主要關注 TCP；DNS 監聽及部分透明代理情境還應檢查 UDP。如果系統提供 lsof，也可以使用與 macOS 類似的命令。

決定結束舊程序，還是替 Clash 更換連接埠

找出佔用者後，有兩種處理方式。選擇依據不是「哪一步比較快」，而是哪個程序應該長期使用這個連接埠。

適合退出舊程序的情況

• 佔用者是已經不再使用的另一套 Clash 或代理客戶端。
• 同一個客戶端異常退出後，留下獨立執行的舊核心。
• 客戶端設定為開機啟動，但目前準備改用另一套客戶端。
• 測試程式暫時佔用代理連接埠，且確認結束後不會影響其他工作。

優先使用應用程式本身的退出功能或停止服務命令，讓它完成狀態儲存與網路設定還原。確認是失去介面控制的殘留程序後，才考慮依 PID 結束程序。結束後重新執行連接埠檢查命令，確認監聽記錄已消失，再啟動 Clash。

適合修改 Clash 連接埠的情況

• 原連接埠屬於需要持續執行的服務。
• 確實需要同時啟動兩套代理核心，並分別執行不同的測試工作。
• 組織或裝置政策固定保留了某個連接埠範圍。
• 客戶端每次啟動都會與容器映射、開發工具或虛擬機器服務發生衝突。

新連接埠應符合三個條件：目前沒有監聽者、不與設定中的其他欄位重複，而且呼叫端可以同步修改。可以先選擇例如 7891、17890 這類高號連接埠，再用系統命令確認目前沒有被使用。連接埠上限為 65535，不能填寫負數、文字或超出範圍的值。

修改 YAML 設定並避免被訂閱更新覆蓋

如果客戶端允許在設定介面中修改連接埠，應優先使用介面提供的連接埠設定，因為客戶端可能會依此同步產生執行設定。直接編輯 YAML 前，要先確認目前檔案是實際執行設定、訂閱原始設定，還是客戶端產生的暫存副本。

使用單一混合連接埠時，可以這樣設定：

mixed-port: 7891
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9091

如果需要分開提供 HTTP 與 SOCKS5 入口，請為兩個欄位分配不同的連接埠：

port: 7891
socks-port: 7892
external-controller: 127.0.0.1:9091

修改後先進行設定驗證，再重新啟動核心。YAML 使用空格表示層級，Tab、縮排錯位或欄位重複都可能造成新的解析錯誤。連接埠值應寫成整數。如果同一欄位在合併設定、覆寫腳本與訂閱內容中出現多次，最終生效值取決於客戶端的設定合併流程，不能只查看單一檔案。

同時執行兩套核心時，不只代理連接埠要錯開，控制連接埠、DNS 監聽連接埠及透明代理連接埠也要逐項核對。兩個執行個體分別使用 mixed-port: 7890 和 mixed-port: 7891 還不夠；如果兩者都繫結 external-controller: 127.0.0.1:9090，第二個執行個體仍可能啟動失敗。

修改連接埠後同步系統代理與應用程式設定

修復連接埠衝突後仍無法連線，最常見的原因是「監聽連接埠已變更，但請求仍被送往舊連接埠」。例如 Clash 已改為 mixed-port: 7891，Windows 或 macOS 的系統代理仍指向 127.0.0.1:7890，瀏覽器自然無法連線至新的監聽入口。

系統代理

如果由 Clash 客戶端自動管理系統代理，可以先關閉系統代理開關，再重新開啟，讓客戶端寫入新的位址。接著到作業系統的網路設定中，核對 HTTP 與 HTTPS 代理是否指向 127.0.0.1 和新的連接埠。使用 mixed-port 時，HTTP 代理可以直接填寫該連接埠。

瀏覽器與獨立應用程式

部分瀏覽器擴充功能、下載工具、程式碼編輯器、聊天程式與遠端連線工具不會跟隨系統代理，而是儲存自己的代理位址。應逐一檢查其中的 HTTP 或 SOCKS5 連接埠。如果應用程式設定為 SOCKS5，而目前只保留 port，協定也會不相容；可以改用 mixed-port，或為應用程式指定獨立的 socks-port。

終端機環境變數

命令列工具可能會讀取 HTTP_PROXY、HTTPS_PROXY 和 ALL_PROXY。舊工作階段中的環境變數不會因 Clash 設定變更而自動更新。以下以暫時環境變數為例，連接埠需要與實際監聽值一致：

HTTP_PROXY=http://127.0.0.1:7891
HTTPS_PROXY=http://127.0.0.1:7891
ALL_PROXY=socks5://127.0.0.1:7891

不同終端機設定變數的語法並不相同，上述內容僅用於說明位址結構。修改啟動腳本或系統層級環境變數前，應確認沒有其他工具依賴舊連接埠。

區域網路裝置

如果手機或其他裝置透過電腦上的 Clash 代理連線，除了設定 allow-lan: true，還要使用電腦在區域網路中的實際位址與新的連接埠。此時監聽位址、防火牆入站規則與網路隔離設定都會影響連線。不要將 127.0.0.1 填入手機，因為它在手機上指向手機本身。

在 TUN 模式下繼續檢查 DNS 與控制連接埠

啟用 TUN 模式後，許多應用程式不再直接讀取系統 HTTP 代理，因此使用者容易以為 mixed-port 與問題完全無關。實際上，核心仍可能同時啟動混合代理連接埠、控制介面與 DNS 服務，其中任何必要的監聽項目發生衝突，都可能導致核心啟動中斷或部分功能異常。

如果日誌指向 dns.listen，應檢查 DNS 設定，例如：

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

1053 被其他 DNS 轉送器佔用時，可以改用另一個空閒連接埠，但同時依賴該監聽位址的設定也要更新。如果 DNS 由 TUN 自動接管，不應只根據範例盲目修改；應以客戶端產生的實際設定與日誌為準。

控制介面衝突通常表現為核心可能仍在執行，但圖形介面顯示「連線失敗」、「無法取得設定」或狀態持續載入。此時請檢查 external-controller 的連接埠，並確認客戶端連線至核心時使用的是同一個位址。修改控制連接埠後，外部面板書籤或客戶端內的控制器位址也需要同步。

透明代理情境還可能涉及 redir-port、tproxy-port 與防火牆規則。只修改 YAML 而不更新重新導向目標，會讓流量繼續進入舊連接埠。Linux 使用者應同時核對策略路由、防火牆規則與服務啟動參數，確認沒有在獨立腳本中寫死連接埠。

依序完成連接埠衝突複查

完成修改後，不要只把「客戶端介面變綠」當作判斷依據。依照監聽、代理入口、規則處理與實際存取四個層次重新檢查，更容易區分連接埠問題與節點問題。

1. 完全退出並重新啟動客戶端。確認舊核心已經結束，避免測試結果受到殘留程序影響。
2. 檢查啟動日誌。確認原本的 bind 或 address already in use 錯誤不再出現。
3. 查詢新的連接埠。使用 netstat、lsof 或 ss 確認監聽者正是目前的 Clash 或 mihomo 核心。
4. 核對系統代理。位址通常為 127.0.0.1，連接埠必須與 mixed-port 或 port 一致。
5. 檢查獨立應用程式設定。尤其是瀏覽器擴充功能、終端機變數、下載工具及使用 SOCKS5 的程式。
6. 執行本機連線測試。先確認請求能夠進入本機代理，再查看日誌中是否出現對應的連線記錄。
7. 排除節點故障。如果日誌已收到請求並完成規則比對，但目標連線逾時，應繼續檢查代理節點、策略群組與網路環境，而不是再次修改本機連接埠。
8. 執行一次訂閱更新。更新後重新檢查連接埠值，確認本機設定沒有被訂閱內容覆蓋。

處理連接埠衝突的主線可以整理為：從日誌擷取連接埠、查詢實際監聽程序、判斷連接埠歸屬、修改唯一的衝突項目，再同步所有請求入口。依序完成這些步驟，比反覆重裝客戶端或隨機更換多個連接埠，更容易保留可維護的設定。