Clash 連接埠 7890 被佔用怎麼辦：找出衝突程序並修改 mixed-port 的完整步驟

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

Clash、Clash Meta（mihomo）及其圖形化客戶端啟動時，需要在本機建立一個或多個監聽連接埠。常見錯誤包括 address already in use、bind: Only one usage of each socket address、listen tcp 127.0.0.1:7890: bind，以及客戶端介面中的「連接埠被佔用」。這些訊息表示作業系統拒絕新的監聽要求，但不代表整份設定檔已損壞。

7890 是 Clash 設定中常見的代理連接埠，並非強制固定值。使用 mixed-port: 7890 時，同一個連接埠可接受 HTTP 與 SOCKS5 代理連線。部分舊設定會分別使用 port: 7890 與 socks-port: 7891。mihomo 設定還可能包含透明代理、DNS 和控制介面所需的其他連接埠，因此排查前應先讀取完整錯誤行。

常見連接埠與用途

設定項目	常見值	用途	發生衝突時的現象
`mixed-port`	`7890`	HTTP 與 SOCKS5 混合代理	系統代理與手動代理無法連線
`port`	`7890`	HTTP 代理	瀏覽器 HTTP 代理失效
`socks-port`	`7891`	SOCKS5 代理	使用 SOCKS5 的應用程式無法連線
`external-controller`	`127.0.0.1:9090`	面板與客戶端控制介面	核心可能正在執行，但面板顯示已斷線
`dns.listen`	`0.0.0.0:1053`	本機 DNS 服務	DNS 模組啟動失敗或解析異常

在 Windows 找出佔用 7890 的程序

先完全退出目前的 Clash 客戶端，再重新啟動一次。若錯誤仍然出現，表示背景可能還有另一個核心程序，或其他代理軟體正在使用該連接埠。不要只關閉視窗：許多客戶端的關閉按鈕會將程式縮到通知區域，核心仍會在背景監聽。

方法一：使用 netstat 與 tasklist

以一般權限開啟「終端機」或「命令提示字元」，執行：

netstat -ano | findstr :7890

典型結果如下：

TCP    127.0.0.1:7890    0.0.0.0:0    LISTENING    18432

最後一欄 18432 是程序 PID。只有狀態為 LISTENING 的記錄，才能直接表示連接埠目前正在監聽。大量 TIME_WAIT 連線通常不代表監聽衝突，不要因此結束程序。接著查詢 PID 對應的程式：

tasklist /FI "PID eq 18432"

如果結果是 mihomo.exe、clash.exe 或某個客戶端附帶的核心檔案，通常屬於殘留程序。如果顯示為其他代理工具，應先在該工具中停止服務或退出程式，再決定是否修改 Clash 連接埠。

方法二：使用 PowerShell

PowerShell 可以直接讀取監聽端點與程序名稱：

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

Get-Process -Id 18432

若第一個指令提示權限不足，可用系統管理員身分開啟 Windows 終端機後重試。也可以在「工作管理員」→「詳細資料」中依 PID 排序，核對程序路徑與啟動時間。若路徑位於目前客戶端目錄，但啟動時間明顯早於這次操作，殘留核心的可能性較高。

安全停止殘留程序

優先透過通知區域選單選擇「退出」，讓客戶端同步關閉核心、系統代理與服務。介面已無法操作時，再使用：

taskkill /PID 18432 /T

一般終止失敗且確認 PID 無誤後，可加上強制參數：

taskkill /PID 18432 /T /F

在 macOS 與 Linux 查詢連接埠佔用情況

macOS 使用 lsof

開啟「終端機」，查詢 TCP 7890 的監聽程式：

lsof -nP -iTCP:7890 -sTCP:LISTEN

輸出中的 COMMAND 是程序名稱，PID 是程序編號，NAME 會顯示監聽位址。若沒有輸出，請確認錯誤記錄實際指向的是 7891、9090 或 1053。也可以移除監聽狀態條件，查看與該連接埠相關的所有連線：

lsof -nP -i :7890

確認是殘留的 mihomo 或 Clash 核心後，先嘗試正常終止：

kill 18432

等待約 2 秒，再次執行 lsof。若程序仍存在，請檢查是否有圖形化客戶端或背景服務自動將其重新啟動。直接執行 kill -9 只能終止目前的程序，無法解決守護程序反覆啟動的問題。

Linux 使用 ss 或 lsof

多數現代發行版預先安裝了 ss：

sudo ss -ltnp 'sport = :7890'

也可以使用：

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

如果 mihomo 透過 systemd 執行，不要只終止核心程序。systemd 會依照服務設定重新啟動它。請先查詢服務狀態，再停止對應單元：

sudo systemctl status mihomo
sudo systemctl stop mihomo

服務名稱可能取決於安裝方式，不一定固定為 mihomo。可以執行 systemctl list-units --type=service | grep -Ei 'clash|mihomo' 搜尋。若採用容器部署，還要檢查 Docker 的連接埠映射；主機上的 127.0.0.1:7890 可能由容器代理程序佔用，而不是直接由容器內的核心顯示。

判斷應結束程序還是修改 mixed-port

找到佔用程式後，不要立即修改連接埠。先判斷兩個程式是否都需要長期執行。若佔用者只是同一客戶端上次異常退出後留下的核心，結束殘留程序並重新啟動即可。若需要同時執行兩套代理工具，或 7890 已由本機開發服務固定使用，就應為其中一套程式分配新的連接埠。

適合結束舊程序的情況

佔用者與目前客戶端使用相同的核心檔案與設定目錄。
工作管理員或活動監視器中出現兩個 mihomo、Clash 核心程序。
舊客戶端已解除安裝，但開機啟動項目、服務或排程工作仍然存在。
釋放連接埠後只需要執行一個代理客戶端。

適合更換連接埠的情況

7890 被另一個必須持續執行的代理程式或除錯工具佔用。
需要同時執行穩定設定與測試設定，兩套核心必須彼此隔離。
集中管理環境已為應用程式分配固定的連接埠範圍。
目前設定還與其他裝置共用，直接停止佔用程式會影響現有工作流程。

新的連接埠應選擇尚未被監聽的本機連接埠，例如 7893、17890 或 27890。修改前使用相同的查詢指令檢查候選值。連接埠範圍為 1 到 65535；一般桌面設定宜避開 1 到 1023 的常見系統服務連接埠，也不要與設定中的控制介面、DNS 監聽和透明代理連接埠重複。

修改設定檔中的 mixed-port

直接編輯 YAML 時，找到頂層的 mixed-port。以下設定會將混合代理從 7890 改為 7893：

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

mixed-port 必須位於設定檔頂層，不能縮排到 proxies、proxy-groups 或 dns 底下。冒號後保留一個空格，連接埠請寫成整數。儲存後需要讓核心完整重新載入設定；僅切換策略群組不會重新建立監聽連接埠。

不要同時保留重複監聽

如果設定已使用混合連接埠，通常不需要再為 HTTP 和 SOCKS 分別設定相同數值。以下寫法會讓多個監聽器爭用 7893：

mixed-port: 7893
port: 7893
socks-port: 7893

應選擇其中一種方案。需要單一入口時，只保留：

mixed-port: 7893

確實要分開提供 HTTP 與 SOCKS5 時，請使用不同連接埠，並移除 mixed-port：

port: 7893
socks-port: 7894

在圖形化客戶端中修改連接埠

不同客戶端的選單名稱有所差異，常見入口是「設定」→「參數設定」→「連接埠」，或「設定」→「核心設定」→「混合連接埠」。將 7890 改為已確認閒置的 7893，儲存後執行「重新啟動核心」，或完整退出並重新開啟客戶端。

有些介面會同時顯示 HTTP、SOCKS 和 Mixed 三個項目。啟用 Mixed 後，應以混合連接埠作為主要入口；如果客戶端允許關閉個別的 HTTP、SOCKS 監聽，可以關閉未使用的入口，減少重複設定。若介面將連接埠鎖定為唯讀，通常表示數值由目前的設定檔或覆寫規則控制，需要返回設定管理頁面修改。

同步更新系統代理

修改連接埠後，系統代理仍可能指向舊的 127.0.0.1:7890。此時核心已正常啟動，但瀏覽器會顯示無法連線。重新關閉並開啟客戶端的「系統代理」開關，通常就會寫入新的連接埠。也可以在作業系統中手動核對：

Windows：「設定」→「網路和網際網路」→「Proxy」，確認位址為 127.0.0.1，連接埠為 7893。
macOS：「系統設定」→「網路」→目前網路→「詳細資訊」→「代理伺服器」，檢查網頁代理與安全網頁代理的連接埠。
瀏覽器擴充功能、開發工具和命令列程式若個別設定了代理位址，也要將 7890 改為 7893。

命令列環境變數同樣可能保留舊值。以下以新的混合連接埠為例：

http_proxy=http://127.0.0.1:7893
https_proxy=http://127.0.0.1:7893
all_proxy=socks5://127.0.0.1:7893

環境變數的設定語法取決於作業系統與終端機。重點是核對所有呼叫端，而不只是確認客戶端介面中的連接埠數字。

TUN 模式下仍需處理監聽衝突

TUN 模式透過虛擬網路介面接收系統流量，但這不代表 mixed-port 可以任意衝突。只要設定中宣告了 mixed-port: 7890，核心通常仍會嘗試建立該監聽器。連接埠繫結失敗可能導致核心啟動中止，或使部分明確代理功能無法使用。

如果只依賴 TUN，也可以依照客戶端與核心設定移除不需要的明確代理監聽；但圖形化客戶端、瀏覽器擴充功能和區域網路裝置可能仍依賴 mixed-port。修改前請先確認是否存在手動代理呼叫。TUN 相關的自動路由、嚴格路由和 DNS 劫持是另一組設定，不應以更換 7890 取代正確的 TUN 設定。

啟用 allow-lan: true 時，客戶端可能監聽 0.0.0.0:7893，讓區域網路裝置存取。僅供本機使用時，應保持 allow-lan: false，或將監聽位址限制在回環介面。無論是否允許區域網路存取，同一位址族上的連接埠都必須保持唯一。

確認新連接埠是否真正生效

第一步：確認監聽狀態

重新啟動核心後，再次查詢新連接埠。Windows 使用：

netstat -ano | findstr :7893

macOS 使用：

lsof -nP -iTCP:7893 -sTCP:LISTEN

Linux 使用：

ss -ltnp 'sport = :7893'

預期結果是 mihomo 或 Clash 核心處於 LISTEN 狀態，同時舊連接埠 7890 不再由該程序佔用。

第二步：直接測試代理入口

安裝 curl 後，可以繞過系統代理設定，直接指定新的連接埠：

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

返回 HTTP 回應標頭表示本機代理入口能夠接收要求。若顯示 Connection refused，表示新連接埠沒有監聽或位址寫錯；若已連線但要求逾時，應繼續檢查節點可用性、策略群組選擇、DNS 與規則，而不是繼續修改連接埠。

第三步：檢查客戶端記錄

在「記錄」頁面篩選 error、listen、bind 等關鍵字。正常啟動後不應再出現 7890 或 7893 的繫結錯誤。若錯誤改為 127.0.0.1:9090，表示 mixed-port 已修復，但控制介面仍與其他程序衝突，需要用相同方法檢查 external-controller。

反覆出現 7890 衝突時的檢查清單

關閉客戶端視窗後，檢查通知區域、選單列和工作管理員中是否仍有核心程序。
檢查是否同時安裝了兩個 Clash 或 mihomo 圖形化客戶端，且都設定為開機啟動。
Windows 檢查「工作管理員」→「啟動應用程式」和服務清單；Linux 檢查 systemd；macOS 檢查登入項目與背景項目。
確認訂閱更新後，執行設定中的 mixed-port 沒有從 7893 恢復為 7890。
確認系統代理、瀏覽器擴充功能、終端機環境變數和區域網路裝置使用的是目前連接埠。
檢查 9090、1053、7891 等其他監聽連接埠，避免修復一個連接埠後，又被下一個衝突阻擋。
保留清楚的連接埠規劃，例如 mixed 使用 7893、控制介面使用 9093、DNS 使用 1053，避免多個程序重複使用。

處理連接埠佔用問題時，應維持固定順序：先從記錄讀取準確連接埠，再用系統工具找出 PID，判斷佔用者是否需要保留，最後決定結束殘留程序或修改設定。修改 mixed-port 後，還要同步更新系統代理與所有手動代理呼叫端。只修改 YAML 而不更新呼叫端連接埠，會把「啟動失敗」變成「核心正常但應用程式無法連網」，增加後續排查成本。