Clash 連接埠被占用怎麼辦？查出衝突程序並變更混合連接埠

先查看錯誤位址，再決定關閉程序或變更連接埠

處理順序：確認無法監聽的連接埠 → 找出占用程序 → 正常退出重複執行個體，或改用未占用的連接埠 → 同步更新系統代理設定。不要先刪除訂閱，也別反覆重新安裝。連接埠衝突發生在本機監聽階段，通常與遠端代理節點是否可用無關。

Clash 系列用戶端的圖形介面負責管理設定，實際監聽連接埠的可能是 Clash、Clash Meta（mihomo）核心，也可能是用戶端啟動的背景服務。關閉視窗不代表核心一定已退出；系統匣、開機啟動項目和服務模式都可能讓監聽程序繼續執行。

從記錄中找出三項資訊

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

這是示意記錄，並非在本機實測的結果。它指出失敗的是 TCP 監聽，位址為 127.0.0.1，連接埠為 7890。Windows 上也可能出現「通常每個通訊端位址只允許使用一次」的提示。先記下實際數字，後續指令都要查詢記錄中的連接埠。

Windows：透過監聽連接埠找出 PID 與程式路徑

開啟 PowerShell，先查詢本機 TCP 監聽狀態。以下以 7890 和 7897 為例。一般權限通常可以查看監聽清單；讀取其他使用者程序的路徑時，可能需要以系統管理員身分開啟終端機。

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

請留意 OwningProcess，這是程序的 PID。假設結果顯示 PID 為 6420，接著查詢程序名稱和可執行檔路徑。6420 只是示範值，實際操作請使用查詢結果，不要照抄這個數字來結束程序。

Get-Process -Id 6420 | Select-Object Id,ProcessName,Path
Get-CimInstance Win32_Process -Filter "ProcessId = 6420" |
  Select-Object ProcessId,ParentProcessId,ExecutablePath,CommandLine

也可以用命令提示字元查詢

netstat -ano -p tcp | findstr ":7890"
netstat -ano -p tcp | findstr ":7897"
tasklist /FI "PID eq 6420"

netstat 的輸出同時包含本機位址和遠端位址。篩選指令只能縮小範圍，仍須確認本機位址的連接埠確實是 7890，且狀態為 LISTENING。遠端位址含有 7890，或狀態為 TIME_WAIT，都不能直接證明有程式占用本機監聽連接埠。

• 路徑指向另一個 Clash 用戶端：從系統匣選單正常退出後，再檢查連接埠。
• 路徑指向目前用戶端的核心：可能已正常執行，也可能有第二個啟動執行個體，請配合記錄時間與父程序判斷。
• 路徑指向其他應用程式：優先調整 Clash 的連接埠，不要為了釋出連接埠而結束無關程序。
• PID 很快就變動：檢查服務模式、工作管理員中的「啟動應用程式」和服務管理員，背景元件可能會自動重新啟動。

確認是已失去介面控制的殘留核心後，才考慮執行 Stop-Process -Id 6420。結束程序會中斷現有連線。若它屬於服務，應先透過所屬用戶端停止服務，避免服務管理員立刻重新啟動；不要一次結束所有名稱含有 Clash 的程序。

macOS 與 Linux：檢查監聽位址及背景服務

macOS：使用 lsof

sudo lsof -nP -iTCP:7890 -sTCP:LISTEN
sudo lsof -nP -iTCP:7897 -sTCP:LISTEN
ps -p 6420 -o pid,ppid,command

-nP 會保留數字位址和連接埠，方便直接比對記錄。lsof 會顯示命令名稱、PID 和監聽位址。建議先從選單列退出舊用戶端，再重新查詢。如果監聽程序是由背景服務啟動，只關閉主視窗仍可能留下核心，請到對應用戶端的服務設定中停止服務。

Linux：使用 ss

sudo ss -ltnp 'sport = :7890'
sudo ss -ltnp 'sport = :7897'
ps -p 6420 -o pid,ppid,args

-l 只顯示監聽狀態，-t 顯示 TCP，-n 顯示數字，-p 顯示相關程序。若程序由 systemd 管理，應先確認實際的服務單元再停止，不要猜服務名稱。有些用戶端使用使用者服務，有些則使用系統服務，請分別在使用者層級或系統層級的服務清單中確認。

一般殘留程序可先用 kill -TERM 6420 要求退出，再查詢連接埠是否已釋出。不要一開始就強制結束，先給程序正常結束的機會。若結束後 PID 改變、連接埠仍被占用，表示應繼續找出自動啟動來源，而不是反覆結束程序。

變更 mixed-port：先確認新連接埠可用，再儲存持久設定

如果必須保留占用連接埠的程序，就將 Clash 混合連接埠改為未占用的數值。例如打算使用 17890，請先將前述查詢指令中的連接埠改成 17890。沒有監聽結果只能表示查詢當下未發現對應的監聽程序，仍須以重新啟動後的綁定結果為準。

1. 在目前的用戶端中找到「混合連接埠」或「Mixed Port」設定，並記下原本的值。選單名稱會因用戶端版本而異，別把核心控制連接埠誤認為混合連接埠。
2. 將混合連接埠改為 17890，儲存後依用戶端提示重新載入或重新啟動核心。
3. 查看執行記錄，確認不再出現該連接埠的綁定失敗訊息。
4. 重新查詢監聽清單，確認 17890 所屬的 PID 與目前用戶端核心相符。

直接編輯 YAML 時，只修改需要的欄位

mixed-port: 17890
allow-lan: false

這是頂層設定片段，不是完整訂閱內容；請合併到現有設定中，保留原有的代理、策略群組和規則。allow-lan: false 表示此範例不允許區域網路存取。如果現有設定另有用途，請依實際需求保留，不要整份覆寫。

檢查同一份設定中的 port、socks-port、external-controller 及其他監聽入口，避免兩個獨立監聽使用相同的位址和連接埠。不要新增第二個同名的 mixed-port 欄位；重複鍵的處理方式可能因解析器而異。

更新訂閱可能會覆寫訂閱檔案，暫時產生的執行設定也可能在重新啟動時重建。請優先使用用戶端的持久連接埠設定或支援的覆寫機制。如果兩處都設定了連接埠，請查看最終生效設定和記錄，確認實際使用的是 17890。覆寫的合併順序由用戶端決定，不能只看編輯器中的一行就下結論。

欄位用途請參閱混合連接埠設定說明；YAML 縮排規則請參閱YAML 設定入門。這類本機監聽參數不需要修改代理節點的伺服器連接埠。

同步系統代理：變更連接埠後也要更新連線入口

核心已改用 17890，但系統代理仍指向 7890，瀏覽器就會繼續連線失敗。如果由用戶端設定系統代理，先關閉「系統代理」開關，再重新開啟，讓用戶端更新位址。接著查看系統設定確認結果，不要只看開關是否已開啟。

• Windows 11：「設定」→「網路和網際網路」→「Proxy」→「手動設定 Proxy」→「編輯」。確認位址為 127.0.0.1，連接埠為 17890。Windows 10 對應頁面通常使用「使用 Proxy 伺服器」開關。
• macOS 13 及後續版本：「系統設定」→「網路」→目前的網路服務→「詳細資訊」→「代理伺服器」。確認已啟用的網頁代理伺服器、安全網頁代理伺服器或 SOCKS 代理伺服器；使用混合連接埠時，可將所需入口指向同一個本機連接埠。
• Linux 桌面：在桌面環境的網路代理設定中檢查手動代理。GNOME 和 KDE 的選單位置不同，不能假設所有發行版都使用相同的設定入口。

瀏覽器擴充功能、下載工具、IDE 和終端機可能各自使用不同的代理位址，不一定會跟隨系統代理。請將手動設定的 7890 或 7897 同步改為 17890。變更終端機環境變數後，已開啟的終端機或已啟動的程式可能仍保留舊值，需重新開啟。

# 查看目前 shell 的代理環境變數；不同 shell 的輸出可能不同
env | grep -i proxy

# 在 PowerShell 中查看代理環境變數
Get-ChildItem Env: | Where-Object Name -Match 'proxy'

這些指令只會查看，不會自動變更變數。請特別檢查 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY 和 NO_PROXY。透過一般 HTTP 混合入口轉送 HTTPS 網站時，HTTPS_PROXY 常見的寫法仍是 http://127.0.0.1:17890；變數名稱描述的是目標請求類型，不代表本機代理必須使用 TLS。

驗證修復結果：分別檢查監聽、代理入口和實際請求

修復後，使用明確指定代理位址的請求進行驗證，避免受到系統代理快取或瀏覽器擴充功能干擾。以下使用保留的範例網域作為測試目標；這不是頻寬測試，結果也不代表所有網站都能連線。

# Windows PowerShell：明確呼叫 curl.exe，避開舊版別名
curl.exe --proxy http://127.0.0.1:17890 --connect-timeout 5 --max-time 15 -I https://example.com

# macOS / Linux
curl --proxy http://127.0.0.1:17890 --connect-timeout 5 --max-time 15 -I https://example.com

如果出現無法連線至 127.0.0.1:17890 的提示，請先檢查核心是否正在監聽。如果已連上本機代理，卻遇到目標連線逾時、DNS 錯誤或 TLS 錯誤，本機連接埠問題可能已經解決，接著應檢查規則比對結果、目標解析和所選代理。HTTP 標頭或通道回應只能作為排查線索，不要把任意狀態碼都視為整體連線正常。

查不到占用程序時的補充檢查

• 如果記錄顯示失敗的是 UDP：Windows 使用 Get-NetUDPEndpoint -LocalPort 7890，Linux 使用 sudo ss -lunp 'sport = :7890'，macOS 使用 sudo lsof -nP -iUDP:7890。請將連接埠替換為實際錯誤值。
• Windows 出現存取權限錯誤：使用 netsh interface ipv4 show excludedportrange protocol=tcp 查看排除範圍；若涉及 IPv6，也要檢查對應的 IPv6 範圍。優先改用範圍外且未占用的連接埠，不要直接刪除系統保留項目。
• 剛釋出連接埠卻仍然失敗：確認記錄的時間屬於本次啟動，而不是介面保留的舊記錄，接著檢查是否有自動重新啟動的服務。
• 變更連接埠後，重新啟動又恢復舊值：檢查訂閱更新、覆寫優先順序和用戶端持久設定，找出實際寫回設定的來源。

最後保留一份方便追查的紀錄

記下原連接埠、新連接埠、占用程式路徑和修改位置即可。下次開機後，確認只有預期的用戶端正在監聽 17890，且系統代理與應用程式代理都指向同一個入口。如果之後打算停用用戶端，請先關閉系統代理再退出，避免系統繼續連線至已停止的本機連接埠。