Clash 連接埠被占用怎麼辦：查出 7890 衝突並修改 mixed-port

先查看記錄：確認是否為監聽衝突

建議依序處理：確認錯誤連接埠、查出監聽程序、決定釋出連接埠或修改設定，最後同步更新使用端。7890 只是 Clash 設定中常見的代理連接埠，並非固定值。改用閒置的 7893 可以避開衝突，但必須先套用新設定，並將瀏覽器、系統代理和終端機一併改用新連接埠。

在用戶端的記錄頁面搜尋 bind、listen 或 address already in use。不同核心與作業系統顯示的完整訊息可能不同，重點是查看錯誤中的位址、連接埠和通訊協定。例如，以下記錄表示 TCP 無法監聽 7890，不能據此判斷代理伺服器是否可用：

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

• 127.0.0.1:7890：監聽本機迴路位址的 7890 連接埠。
• 0.0.0.0:7890：嘗試監聽所有 IPv4 介面，可能與既有的迴路位址監聽發生衝突。
• [::]:7890：IPv6 萬用位址；是否也影響 IPv4，取決於作業系統與通訊端設定。
• connection refused：通常表示目標未在監聽或主動拒絕連線，與連接埠被占用不同。

分清 mixed-port 與控制連接埠

Clash 用戶端負責管理介面，實際監聽通常由核心程序執行。使用 Clash Meta（現稱 mihomo）的用戶端也採用相同分工。介面中的「連接埠」可能代表不同入口，請依記錄中的連接埠號碼追查，不要看到 7890 就把所有欄位都改掉。

例如，mixed-port: 7890 可同時供 HTTP 與 SOCKS5 使用，不必再將 port 和 socks-port 也設為 7890。多個獨立監聽欄位使用相同位址與連接埠，可能造成設定彼此衝突。若只需要一個混合入口，確認用戶端支援後，可保留混合連接埠並移除未使用的獨立入口。

external-controller: 127.0.0.1:9090 則屬於另一種服務。系統代理不應設定為 9090；修改此值也無法解決 7890 代理監聽失敗。控制連接埠涉及管理權限，應維持綁定本機並保留原有驗證設定，排查衝突時不要任意開放給區域網路使用。

Windows：使用 netstat 找出程序

第一步：查詢監聽記錄與 PID

開啟 PowerShell 或命令提示字元，執行以下指令。第一個指令會篩選包含 7890 的列；第二個則使用 PowerShell 精確查詢本機監聽連接埠：

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

powershell -NoProfile -Command "Get-NetTCPConnection -LocalPort 7890 -State Listen | Select-Object LocalAddress,LocalPort,OwningProcess"

查看 netstat 輸出時，先確認「本機位址」的連接埠是 7890，再找出狀態為 LISTENING 的列。只看包含該數字的整列，很容易把遠端連接埠或 17890 誤認為目標。最後一欄是 PID；例如查到 PID 為 6240，再查詢程序名稱：

tasklist /FI "PID eq 6240"

這裡的 6240 只是指令範例，請替換為實際查詢結果。若要確認執行檔路徑與啟動參數，可在 PowerShell 中繼續檢查；查看其他使用者的程序資訊可能需要系統管理員權限：

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

第二步：依程序所屬來源處理

• 其他代理用戶端：從系統匣選單結束程式，確認背景核心已停止，再啟動要使用的用戶端。
• 同一用戶端的殘留核心：先正常結束用戶端，再次檢查連接埠；確認程序路徑與所屬來源後，再透過工作管理員結束殘留程序。
• 需要保留的本機服務：不要強制結束，改用已確認閒置的代理連接埠。
• 不明程序或系統服務：先確認路徑與服務來源，不要只憑 PID 就執行強制結束指令。

如果查不到監聽記錄，卻出現「以一種存取權限不允許的方式嘗試存取通訊端」的錯誤，請進一步確認是連接埠保留還是權限問題。可執行 netsh interface ipv4 show excludedportrange protocol=tcp 查看 TCP 排除範圍；若候選連接埠落在範圍內，優先改用範圍外的閒置連接埠，不要任意刪除系統保留項目。

macOS 與 Linux：使用 lsof、ss 檢查

macOS：只查看 TCP 監聽

開啟終端機並執行以下指令。-nP 會以數字顯示位址與連接埠，-sTCP:LISTEN 則只列出監聽狀態，方便排除一般連線。需要查看其他使用者的程序時，再加上 sudo：

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

留意輸出中的 COMMAND、PID 與 NAME。如果占用者是其他用戶端，請先從選單列結束該程式；若結束後很快又出現，請檢查是否啟用了登入時啟動、背景服務或自動重新啟動功能。

Linux：分別檢查 TCP 與 UDP

sudo ss -ltnp 'sport = :7890'
sudo ss -lunp 'sport = :7890'

# 已安裝 lsof 時，也可檢查 TCP 監聽
sudo lsof -nP -iTCP:7890 -sTCP:LISTEN

ss 的 -t 用於查詢 TCP，-u 用於查詢 UDP，-p 則會顯示程序資訊。TCP 與 UDP 使用不同的連接埠空間：發現 UDP 7890 正在使用，不代表它就是 TCP 綁定失敗的原因。請依記錄中的通訊協定分別檢查。

如果 mihomo 由 systemd 管理，關閉桌面視窗不一定會停止服務。只有在服務單元名稱確實是 mihomo.service 時，才使用 systemctl status mihomo.service 查看狀態；確認要停用後，再執行 sudo systemctl stop mihomo.service。若實際單元名稱不同，請以部署時使用的名稱為準，否則可能會誤以為核心已停止。

修改 mixed-port：以 7893 為例

先將前面的查詢指令中的 7890 改為 7893，確認候選連接埠沒有衝突。7893 不保證在所有電腦上都可用，僅作為本次設定範例。修改時應調整用戶端最後實際載入的設定，而不只是編輯未啟用的 YAML 檔案。

1. 在用戶端目前使用的設定或執行設定中，尋找「混合連接埠」、「Mixed Port」或 mixed-port。各用戶端的選單名稱不盡相同，請以實際欄位為準。
2. 若使用 YAML 管理，請修改頂層欄位並使用空格縮排，不要將連接埠寫在 proxies 或 proxy-groups 內。
3. 確認用戶端是否另有連接埠覆寫設定。訂閱設定、覆寫設定與執行設定可能會共同決定最後使用的值。
4. 儲存並套用設定；若用戶端提示需要重新啟動核心，請完成重啟後再檢查記錄與監聽狀態。

以下內容是連接埠相關片段，並非完整訂閱設定。如果仍有應用程式需要獨立的 SOCKS 入口，可使用不同的連接埠：

# 合併至現有設定的頂層；保留其他代理、策略組與規則
mixed-port: 7893
socks-port: 7894
allow-lan: false

# 控制 API 與代理入口分開，維持既有驗證設定
external-controller: 127.0.0.1:9090

只使用混合連接埠時，不必為了範例額外新增 socks-port。若原本設定也啟用了 port: 7890，只修改 mixed-port 後，獨立的 HTTP 入口仍可能繼續報錯，因此請逐一檢查所有監聽欄位。

同步更新系統代理、瀏覽器與終端機

修改連接埠後，最常見的後續問題是核心已在 7893 監聽，但應用程式仍向 7890 傳送要求。此時重新匯入訂閱通常無助於解決問題，應改為檢查流量入口。

如果系統代理由用戶端自動管理，套用新連接埠後，可將用戶端的「系統代理」開關關閉再開啟一次，接著確認系統設定。若環境使用 PAC 自動設定，請檢查 PAC 回傳的代理位址；修改手動代理欄位不一定會影響 PAC 設定。

終端機環境變數範例

在 macOS 或 Linux 的目前 shell 中，可依下列方式設定 HTTP 代理。https_proxy 的值使用 http://，代表透過 HTTP 代理的 CONNECT 方法連線至 HTTPS 網站，並不表示目標網站改用未加密連線：

export http_proxy=http://127.0.0.1:7893
export https_proxy=http://127.0.0.1:7893

# 需要 SOCKS5 且工具支援時，可單獨使用：
export all_proxy=socks5h://127.0.0.1:7893

這些指令只會影響目前的 shell 與之後啟動的子程序，不會自動更新已在執行的應用程式。若同時設定 HTTP 與 SOCKS 變數，優先順序由工具決定；排查時建議明確指定代理，避免混合設定影響判斷。也請檢查 HTTP_PROXY、HTTPS_PROXY 等大寫變數，以及 shell 啟動檔中的舊值。

TUN 模式會接管另一條流量路徑，不會自動排除本機代理入口的綁定衝突。應用程式可能透過 TUN 正常連線，但 7890 仍無法監聽；也可能是設定了錯誤的明確代理，連線尚未進入正常轉送路徑就已失敗。這兩種情況應分開驗證。

驗證修復結果：監聽、要求與重新啟動

1. 確認監聽：再次查詢 7893，確認 PID 屬於預期的核心程序，並檢查記錄中不再出現該入口的綁定錯誤。
2. 測試代理要求：使用明確指定代理的參數送出一次要求，不要一開始就依賴系統代理或瀏覽器設定。
3. 確認日常應用：接著開啟瀏覽器與實際使用的工具，檢查是否仍指向舊連接埠。
4. 確認設定持續生效：重新啟動用戶端並更新一次訂閱，確認連接埠沒有被覆蓋，也沒有其他用戶端自動啟動並搶先占用連接埠。

以下指令會透過新的混合連接埠傳送 HTTP 代理要求。Windows 請使用 curl.exe，可避免部分 PowerShell 環境中同名指令別名造成的差異：

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

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

收到 HTTP 回應表示這次要求已獲得回覆，但不代表一定經過遠端代理節點：在規則模式下，目標仍可能符合直連規則。若出現 Failed to connect，請優先檢查本機監聽與連接埠；若本機代理已接受連線，之後才出現上游逾時或 TLS 錯誤，則應檢查節點、DNS、規則與網路環境，不要繼續盲目更換本機連接埠。

常見的後續問題

• 結束程式後連接埠仍被占用：檢查背景服務、其他使用者工作階段，以及用戶端殘留的核心程序。
• 修改後立即恢復舊值：檢查連接埠覆寫功能與訂閱更新行為，並確認修改的是目前啟用的設定。
• 連接埠閒置仍無法啟動：確認是否為權限、系統排除連接埠、無效的綁定位址或 YAML 解析錯誤，並依新的記錄進一步處理。
• 面板離線但網頁可正常瀏覽：分別確認控制 API 的位址、連接埠與驗證設定，不要將代理入口誤當成面板介面。

完成排查後，建議只讓一個負責日常代理的用戶端自動啟動，並記錄「混合連接埠 7893、是否啟用獨立 SOCKS 連接埠、控制連接埠 9090」等實際設定。日後再次發生衝突時，從監聽程序著手檢查，通常比反覆重新安裝用戶端更容易找出原因。欄位完整說明請參閱設定大全，安裝與初次啟用流程請見快速上手。