Clash 7890 連接埠遭占用怎麼辦：查出占用程序並更改混合連接埠

先看錯誤訊息：確認衝突的是代理連接埠還是控制連接埠

Clash 或 mihomo 啟動時出現 bind: address already in use，表示核心無法依目前設定繫結要監聽的本機位址與連接埠，常見原因是已有程序占用相同的監聽位址。此時先檢查本機監聽狀況，不必重新購買訂閱，也不用先更換代理節點。訂閱中的遠端伺服器連接埠，與電腦上的 7890 是不同位置。

開啟用戶端日誌，複製包含 listen、bind 和連接埠號碼的完整一行。以下是用來辨認欄位的範例，並非所有用戶端都會輸出相同的前綴：

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

表中的連接埠是用來說明的設定值，並非所有用戶端的預設值。請以日誌和最終生效的設定為準。若日誌顯示 9090，就先檢查控制介面；只把 mixed-port 從 7890 改成其他值，無法排除控制介面的衝突。

Windows：使用 netstat 和 PowerShell 找出占用程序

1. 查詢監聽 7890 的 PID

開啟「開始」→ 搜尋「終端機」或「PowerShell」。先執行查詢；若讀取其他使用者的程序或停止服務時出現權限不足，再以系統管理員身分開啟。以下指令只會讀取狀態，不會結束程序：

netstat -ano -p tcp | findstr ":7890"

請留意本機位址為 127.0.0.1:7890、0.0.0.0:7890 或 [::]:7890，且狀態為 LISTENING 的列。最後一欄是 PID。包含 :7890 的結果也可能只是遠端連線，不要把每一列都當成監聽占用。若要精確篩選本機監聽，請使用：

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

2. 查詢程序路徑，區分系統匣程式與背景服務

假設查詢結果傳回 PID 1234，請將以下指令中的數字替換成實際 PID。先查看名稱，再查看執行檔路徑與啟動參數：

tasklist /FI "PID eq 1234"

Get-CimInstance Win32_Process -Filter "ProcessId = 1234" |
  Select-Object ProcessId, ExecutablePath, CommandLine

常見情況是舊版用戶端仍在系統匣中執行，新版用戶端又啟動了另一個核心；也可能是服務模式中的 mihomo 已在監聽，圖形介面又啟動了第二個執行個體。優先從對應用戶端的選單選擇「結束」，或在「工作管理員」→「詳細資料」核對 PID。若確認是背景服務，請開啟「服務」管理員檢查服務名稱和執行檔路徑，再決定要停止哪個服務。

若正常結束後程序仍未停止，可對已確認的 PID 執行 Stop-Process -Id 1234。結束前請先儲存設定，並確認該服務不是其他使用者正在使用的項目。不要使用依名稱批次終止所有代理程序的指令。

3. 查不到監聽結果，但仍無法繫結

請先重新查看最新日誌，區分 address already in use 與 access permissions。後者可能與系統保留連接埠或安全性原則有關，不能直接視為一般占用。Windows 可進一步查詢 TCP 排除範圍：

netsh interface ipv4 show excludedportrange protocol=tcp
netsh interface ipv6 show excludedportrange protocol=tcp

若目標連接埠位於列出的範圍內，請優先選擇範圍外且未被占用的連接埠。不要為了固定使用 7890 而任意刪除系統排除範圍；虛擬化、容器和網路共用功能可能會用到這些設定。

macOS 與 Linux：查詢監聽位址，再確認啟動來源

macOS：使用 lsof

開啟「應用程式」→「工具程式」→「終端機」，執行以下指令。-nP 會保留數字位址和連接埠，避免名稱解析影響判讀；-sTCP:LISTEN 只會顯示 TCP 監聽。

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

讀取輸出中的 COMMAND、PID 和 NAME。假設 PID 為 1234，請繼續確認啟動指令：

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

先透過選單列結束對應的用戶端。若是手動啟動的核心，請回到原本的終端機按 Control-C。確認是可停止的殘留程序後，才使用 kill -TERM 1234。如果 PID 很快變更並重新開始監聽，請檢查「系統設定」→「一般」→「登入項目與延伸功能」，以及自行設定的 launchd 服務，找出並處理自動重新啟動的來源。

Linux：使用 ss，檢查 systemd 服務

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

ss 的 -l 代表監聽，-t 代表 TCP，-n 使用數字格式，-p 顯示程序。若輸出指出核心由 systemd 管理，請先確認實際的單元名稱。只有在安裝時確實使用了 mihomo.service，才執行以下指令：

systemctl status mihomo.service
sudo systemctl stop mihomo.service

使用者層級的服務則以 systemctl --user 查詢和管理。若採用 Docker 部署，也請檢查 docker ps 中的主機連接埠對應；占用主機 7890 的可能是容器發布的連接埠，而非目前的桌面用戶端。

更改 mixed-port：先選擇未占用的連接埠，再修改生效設定

若原有程式確實需要繼續使用 7890，可為目前的 Clash 用戶端改用其他入口，例如 17890。這個數字僅供示範，不保證本機未被占用；請先將前述查詢指令中的 7890 換成 17890 進行檢查。

最精簡的本機監聽設定

mixed-port: 17890
allow-lan: false
bind-address: 127.0.0.1

external-controller: 127.0.0.1:19090
secret: "local-api-19090-change-before-use"

這只是用來說明監聽欄位的 YAML 片段，不包含節點、策略群組或規則，不能直接取代完整訂閱。範例也示範將控制連接埠設為 19090；若原本的控制連接埠沒有衝突，可以保留原值。secret 的範例內容需改成自行產生的隨機字串，並同步更新管理面板。

• 頂層欄位請勿重複：修改現有的 mixed-port，不要在檔案末尾再新增第二個同名鍵。YAML 縮排請使用空格，不要使用 Tab。
• 檢查獨立連接埠：若同時啟用了 port 或 socks-port，請勿讓這些獨立監聽與混合連接埠使用相同的位址和連接埠。若只需要混合入口，可依用戶端支援的方式停用多餘入口。
• 確認監聽範圍：僅供本機使用時，請維持 allow-lan: false。不要為了解決衝突而改成監聽所有網路介面，這可能擴大代理入口的可存取範圍。
• 控制介面僅供本機使用：external-controller 用於管理 API。請繫結至 127.0.0.1 並設定密鑰，不要直接公開至網際網路。

訂閱檔案、覆寫與執行中設定的差異

圖形介面用戶端通常會合併訂閱與本機設定，產生實際交給 mihomo 使用的設定。直接編輯下載快取中的 YAML，可能在下次更新訂閱時被覆寫；編輯暫存的執行檔，也可能在重新啟動時遺失。請優先尋找用戶端提供的「混合連接埠」、「連接埠設定」或「覆寫」選項，實際名稱以目前用戶端介面為準。

修改後請儲存並重新啟動核心，而不只是關閉設定視窗。接著查看啟動日誌中的監聽連接埠，或重新執行監聽查詢。若使用獨立 mihomo 執行檔，可先在設定檔所在目錄執行 mihomo -t -f config.yaml 檢查設定；語法檢查通過不代表連接埠一定能繫結，還需確認實際啟動結果。

更改連接埠後，同步更新系統代理與命令列環境

核心改為監聽 17890 後，仍將流量傳送至 7890 的應用程式會連線失敗，或誤連到原本的另一個代理執行個體。可以先關閉用戶端的「系統代理」，再重新啟用，並檢查作業系統最終儲存的位址。

• Windows 11：「設定」→「網路和網際網路」→「Proxy」→「手動設定 Proxy」。若使用手動 Proxy，伺服器請填入 127.0.0.1，連接埠填入 17890。若使用 PAC，請檢查 PAC 規則指定的目標，而非只修改手動 Proxy。
• macOS：「系統設定」→「網路」→ 目前的網路連線 →「詳細資訊」→「Proxy」。請核對已啟用的網頁 Proxy、安全網頁 Proxy 或 SOCKS Proxy 連接埠。
• 獨立應用程式：瀏覽器 Proxy 擴充功能、下載工具、編輯器和 Git 的自訂 Proxy 不一定會隨系統設定更新，請分別檢查。

命令列也可能會讀取環境變數。以下分別查看 Windows PowerShell 與 macOS、Linux 目前終端機中的 Proxy 變數：

# Windows PowerShell
Get-ChildItem Env: | Where-Object Name -Match 'proxy'

# macOS / Linux
env | grep -i proxy

例如原本設定了 HTTPS_PROXY=http://127.0.0.1:7890，就需要同步改用新的連接埠。此處的 http:// 表示與本機 HTTP Proxy 入口的通訊方式，不代表目標網站只能使用 HTTP。修改永久環境變數後，通常需要重新開啟終端機；已在執行的程序不會自動取得新值。

TUN 模式會接管進入虛擬網卡的流量，與混合連接埠監聽屬於不同環節。啟用 TUN 不會自動釋放遭其他程序占用的 7890；明確使用 HTTP 或 SOCKS Proxy 的應用程式仍需檢查其連接埠。切換規則模式或全域模式也無法排除本機監聽衝突。

確認修復結果：分別檢查監聽、代理請求與重新啟動後的設定

1. 檢查監聽程序：重新查詢 17890，確認 PID 對應預期的 Clash 或 mihomo 執行個體。再檢查原本發生錯誤的連接埠，確認是否仍由其他服務使用。
2. 檢查啟動日誌：確認沒有新的繫結失敗。若仍出現 9090、7891 等錯誤，應分別處理，不能只因其中一個入口成功啟動就結束排查。
3. 明確發送代理請求：使用以下 curl 指令測試，避免只憑瀏覽器頁面快取判斷代理是否可用。
4. 確認設定持續生效：重新啟動用戶端後再次檢查。下次更新訂閱後也要確認連接埠設定，確保本機覆寫仍然生效。

# Windows PowerShell
curl.exe --noproxy "" -I --connect-timeout 5 --max-time 15 --proxy http://127.0.0.1:17890 https://example.com/

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

此處的 --noproxy "" 用來清除這次請求的代理略過清單；--connect-timeout 5 和 --max-time 15 分別限制連線階段和整個請求的等待時間。這些是測試參數，不代表速度測量結果。

若立即顯示無法連線至 127.0.0.1:17890，請回頭檢查監聽狀態和位址；若已連上本機代理，後續才出現 TLS、DNS 或遠端逾時，排查重點才應轉向節點、DNS 和規則。在 HTTPS 測試中，只看到 200 Connection established，僅代表代理接受了 CONNECT 通道請求；還需查看目標網站的回應和用戶端日誌。

常見問題：重新安裝、防火牆與同時執行兩個用戶端

重新安裝 Clash 能直接解決 7890 被占用嗎？

若是另一個仍在執行的核心占用了連接埠，重新安裝目前的用戶端通常不會停止該程序。先透過 PID 找出來源，比反覆解除安裝更有效。刪除設定也可能導致訂閱和覆寫遺失，排查前請先保留需要的本機設定。

關閉防火牆能解決 address already in use 嗎？

防火牆主要影響連線能否通過，不會替應用程式釋放已遭占用的監聽連接埠。繫結失敗與區域網路裝置無法連線是不同問題。不要把關閉防火牆當成本機連接埠衝突的第一步。

可以同時執行兩個 Clash 用戶端嗎？

可以分別設定互不衝突的監聽連接埠和控制連接埠，但還需協調系統代理、TUN 路由與 DNS 接管。一般桌面使用情境下，保留一個負責系統網路的核心會更容易維護。若確實需要並行測試，可讓第二個執行個體只提供獨立的本機代理入口，不要同時搶用系統代理和 TUN。

日誌顯示 UDP 連接埠遭占用，也使用同一組指令嗎？

前文主要查詢 TCP 監聽。若日誌明確指出 UDP，請依傳輸協定另行檢查：Windows 使用 Get-NetUDPEndpoint -LocalPort 7890，macOS 使用 sudo lsof -nP -iUDP:7890，Linux 使用 sudo ss -lunp 'sport = :7890'。TCP 和 UDP 使用不同的連接埠空間，查不到 TCP 結果並不能證明 UDP 連接埠未被占用。

修復完成的判斷標準是：預期的核心成功監聽、透過新連接埠發出的請求能正常完成，而且重新啟動及更新訂閱後設定仍一致。若後續仍有連線問題，可前往說明中心區分 DNS、訂閱和規則問題，或在進階設定中進一步確認 mihomo 的設定用途。