先確認無法監聽的是哪個連接埠

Clash 用戶端啟動時出現 address already in use，通常表示核心準備監聽的本機位址與連接埠已被占用。這發生在本機建立代理入口的階段，不代表訂閱失效，也無法據此判斷遠端節點是否可用。此時反覆更新訂閱或切換節點，通常無法排除本機連接埠衝突。

先開啟用戶端的記錄頁面，找出包含 listen、bind 或 in use 的完整錯誤行，記下位址、連接埠與通訊協定。以下是錯誤格式範例，並非裝置上的實際偵測結果：

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

這裡要排查的是本機 TCP 7890。若記錄顯示 127.0.0.1:9090，應檢查外部控制介面，而不是直接修改代理連接埠。0.0.0.0:7890 代表監聽所有 IPv4 介面，可能與相同連接埠的單一位址監聽衝突；看到 [::]:7890 時，還要配合系統的 IPv6 雙堆疊行為判斷。

設定欄位 用途 修改後需同步更新的位置
mixed-port 在同一個連接埠提供 HTTP 與 SOCKS 代理入口 系統代理、瀏覽器代理及命令列代理環境變數
port 獨立的 HTTP 代理入口 使用此入口的 HTTP 代理設定
socks-port 獨立的 SOCKS 代理入口 應用程式內的 SOCKS 代理設定
external-controller 供用戶端或控制面板存取的控制 API 用戶端或控制面板的控制介面連線設定

Windows：用 netstat 找出占用連接埠的程序

確認本機位址、監聽狀態與 PID

開啟 Windows 終端機或命令提示字元，執行以下指令。一般權限通常可以查看連線；讀取部分程序資訊或管理服務時，可能需要系統管理員權限。

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

輸出各欄依序包含通訊協定、本機位址、遠端位址、狀態與 PID。務必檢查本機位址欄，並確認連接埠確實是 7890；文字篩選也可能比對到遠端位址或較長的連接埠號碼。對於 TCP 代理入口，請留意狀態為 LISTENING 的項目，不要只因某一行含有 7890 就結束程序。

也可以在 PowerShell 中精確篩選連接埠，減少人工辨識：

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

假設查詢結果中的 PID 是 4321，接著執行以下指令查看程式名稱。此處的 4321 僅用來示範指令格式，實際操作時請換成查到的 PID。

tasklist /FI "PID eq 4321"

確認程序來源，再決定要結束或保留

  • 另一個代理用戶端：從系統匣選單正常結束，再重新查詢連接埠。只關閉視窗可能仍會在背景執行。
  • 目前用戶端的舊版核心：先結束用戶端，再透過工作管理員確認殘留程序的路徑與命令列。確認是殘留核心後再結束程序。
  • 以服務模式啟動的核心：關閉視窗後，服務可能仍在執行。請使用用戶端提供的服務管理功能停止對應服務，避免程序結束後立即重新啟動。
  • 仍需使用的其他程式：保留該程式，為 Clash 改用其他未占用的連接埠；不要為了釋出連接埠而盲目停用系統服務。

可在工作管理員的「詳細資料」頁確認 PID，並按一下欄位標題後選擇「選取欄」，顯示命令列。若占用者是系統程序，切勿只憑連接埠號碼就強制結束；應繼續查明相關服務，或改用其他連接埠。

macOS 與 Linux：用 lsof 或 ss 確認監聽程序

在 macOS 的「終端機」執行以下指令。-nP 會保留數字位址與連接埠，-sTCP:LISTEN 則將結果限定為 TCP 監聽通訊端：

lsof -nP -iTCP:7890 -sTCP:LISTEN

請留意 COMMAND、PID 與 NAME。若懷疑監聽程序屬於其他使用者，而一般查詢未顯示完整資訊，可在具備相應權限時加上 sudo 重試。Linux 若未安裝 lsof，可使用通常隨 iproute2 提供的 ss：

sudo ss -ltnp 'sport = :7890'

若要進一步確認程序的啟動命令，可依實際 PID 查詢：

ps -p 4321 -o pid,ppid,command

先透過應用程式選單或服務管理功能正常停止占用連接埠的程序。若確認是失去管理介面的殘留程序，可傳送正常終止訊號，例如 kill -TERM 4321。不要一開始就強制結束：這無法查明程序為何重複出現，也可能略過正常清理程序。

修改 mixed-port：先確認哪一層設定實際生效

確認 7890 被其他必要程式占用後，可以改用 7892，但請先用前述指令確認 7892 未被占用。換成另一個數字只是選擇新的監聽入口，不會自動更新瀏覽器、終端機或控制面板的連線設定。

對於 Clash Meta（mihomo）類核心，以下是局部設定範例。這不是包含節點與規則的完整設定，請合併至現有設定，並保留原有訂閱、策略群組、規則與存取驗證設定。

mixed-port: 7892
allow-lan: false
external-controller: 127.0.0.1:9090

此範例只將混合代理入口改為 7892，並保留控制介面 9090。若記錄沒有顯示控制連接埠發生衝突，就不必一併修改。allow-lan: false 可限制區域網路存取；個人裝置只需在本機使用時，不應為了排除連接埠占用而擴大監聽範圍，開放給整個網路。

圖形介面的連接埠設定可能會覆寫訂閱檔案

  1. 記下目前使用的代理連接埠、控制連接埠與設定名稱，並儲存一份可還原的設定副本。
  2. 檢查用戶端設定中是否有「混合連接埠」、「代理連接埠」或「核心設定」等項目。各用戶端的選單可能不同，請優先使用管理全域監聽參數的設定入口。
  3. 若用戶端支援覆寫或合併設定，請將本機監聽參數放在其實際支援且可持續生效的設定層。不要假設所有訂閱檔案都支援相同的覆寫方式。
  4. 套用變更並重新載入或重新啟動核心，再檢查記錄。是否需要重新啟動才能套用連接埠變更，取決於用戶端與核心的實際行為。

直接修改下載後的訂閱 YAML，可能會在下次更新時被覆寫。反之，修改訂閱檔案也可能不會生效，因為用戶端啟動時可能以介面設定覆寫同名欄位。最終應以生效的設定、核心記錄與系統監聽結果為準，而不是以編輯器中已儲存的內容判斷。

也請檢查是否另有啟用獨立的 port 或 socks-port。請勿讓它們與 mixed-port 使用相同的監聽位址與連接埠，也不要在 YAML 頂層重複設定兩個 mixed-port；重複的鍵可能造成解析錯誤或覆寫結果不明。

控制連接埠衝突：單獨調整 external-controller

如果錯誤發生在 9090，而代理入口 7890 已正常監聽，問題出在控制 API。可能出現圖形介面無法讀取連線、切換策略失敗或控制面板顯示核心已中斷等情況；部分用戶端也可能因此回報啟動失敗。此時應先確認占用 9090 的程序，再決定是否改用未占用的 9091。

external-controller: 127.0.0.1:9091

變更後，獨立控制面板需要連線至新的控制位址；若圖形用戶端自行管理控制介面，請在相應設定中一併修改，讓介面與核心保持一致。只編輯核心檔案而不調整介面連線參數，可能導致代理可用、介面卻無法連線。請保留既有的 secret 驗證，並將其同步至需要存取介面的控制面板；不要為了排除問題而取消驗證。

不要將控制介面改成 0.0.0.0:9091 來嘗試排除衝突。這會擴大介面的暴露範圍，也無法保證避開現有監聽程序。控制介面與混合代理介面是兩項獨立設定，只修改發生衝突的部分，通常更容易驗證與還原。

同步系統代理與應用程式代理，避免繼續連到舊連接埠

將混合連接埠改為 7892 後，仍指向 127.0.0.1:7890 的應用程式會繼續連線失敗。圖形用戶端通常會在啟用系統代理時寫入新值，但是否自動更新仍取決於用戶端的實作。建議先套用新連接埠，再關閉並重新啟用一次系統代理，接著確認系統顯示的實際位址。

  • Windows 11：開啟「設定」→「網路和網際網路」→「Proxy」→「手動設定 Proxy」→「使用 Proxy 伺服器」中的「設定」，確認位址與連接埠。若使用自動設定指令碼，也請確認指令碼提供的代理位址。
  • macOS 13 或更新版本：開啟「系統設定」→「網路」→目前使用的連線→「詳細資訊」→「代理伺服器」，檢查網頁代理伺服器（HTTP）、安全網頁代理伺服器（HTTPS）及 SOCKS 代理伺服器中實際啟用的項目。
  • Firefox：檢查「設定」→「一般」→「網路設定」→「設定」。獨立設定的手動代理不會隨作業系統代理變更而自動同步。
  • 終端機與開發工具：檢查 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY，以及 Git、編輯器和容器內個別設定的代理位址。

混合連接埠可接收 HTTP 與 SOCKS 要求，但應用程式端仍須選擇正確的通訊協定。例如，HTTP 代理位址可設為 http://127.0.0.1:7892；若需要透過 SOCKS 代理解析網域名稱，可在支援此格式的工具中使用 socks5h://127.0.0.1:7892。透過 HTTP 代理為 HTTPS 網站建立通道，不代表本機代理位址必須使用 https://。

TUN 模式會透過虛擬網路介面接管流量，並不等同於系統 HTTP 代理。在某些 TUN 情境下，即使瀏覽器仍可連線，也不能證明舊的 7890 設定已修復；反過來說，一般混合連接埠衝突也不需要解除安裝 TUN 裝置。驗證代理入口時請明確指定新連接埠，避免混淆連線路徑。

確認修復結果與重新啟動後的設定持續性

先確認監聽狀態，再實際送出一次請求

重新查詢 7892，確認它由預期的核心程序監聽，並檢查記錄是否仍出現綁定失敗。接著使用 curl 明確連線至新入口；在 Windows PowerShell 中使用 curl.exe，可避免部分環境中同名命令別名造成的影響。

curl.exe -I --connect-timeout 5 --max-time 15 --proxy http://127.0.0.1:7892 https://example.com/

macOS 或 Linux 使用相同參數，將命令名稱換成 curl。此處的 5 秒與 15 秒分別是連線階段與整體請求的逾時上限，並非測速結果。此範例假設本機代理未啟用驗證；若已設定驗證，請依現有方式提供憑證，避免將密碼貼到公開記錄中。

  • 本機連線遭拒：優先確認新連接埠是否正在監聽、位址是否一致，以及核心是否已結束。
  • 要求已送進核心，但連線逾時：請搭配連線記錄確認規則比對結果、節點與 DNS；連接埠恢復監聽，不代表後續連線路徑一定正常。
  • curl 成功但瀏覽器失敗：檢查瀏覽器獨立代理、代理擴充功能、自動設定指令碼與舊連線，不必立刻再次修改連接埠。
  • 瀏覽器正常但控制面板失敗：重新檢查控制介面位址與驗證設定，不要把控制介面錯誤當成代理入口故障。

結束後重新啟動，再檢查一次

完成測試後，正常結束並重新啟動用戶端，確認監聽連接埠仍是 7892；若問題常在開機後出現，請再檢查登入啟動項目與服務模式。只保留確實需要的自動啟動項目，避免新舊用戶端同時搶用相同連接埠。

若 TCP 查詢沒有找到監聽程序，但仍無法綁定，請先重新確認記錄中的時間、位址與通訊協定。在 Windows 中，address already in use 與 access permissions 的排查方向不同；後者也可能與保留連接埠或安全性原則有關。可用以下指令查看 TCP 排除連接埠範圍，但不要直接刪除系統保留項目：

netsh interface ipv4 show excludedportrange protocol=tcp

最終應同時符合四項條件：核心成功監聽預期連接埠、系統與應用程式都指向新入口、控制介面能正常連線，以及重新啟動後設定仍然保留。若要還原，請先確認原連接埠已釋出，再恢復原設定並同步更新系統代理。準備暫時結束用戶端時，也應關閉由它設定的系統代理，避免系統繼續將要求送往已停止的本機連接埠。