先分清代理監聽連接埠與控制連接埠

啟動 Clash 或使用 Clash Meta（mihomo）核心的用戶端時，如果日誌出現 address already in use，通常表示核心要監聽的位址與連接埠已被其他監聽程序占用。先記下錯誤中的通訊協定、位址和連接埠，再決定要關閉哪個程式或修改哪個欄位。若只看到「啟動失敗」就反覆更換訂閱，通常無法解決本機監聽衝突。

常見日誌片段
listen tcp 127.0.0.1:7890: bind: address already in use
listen tcp 127.0.0.1:9090: bind: address already in use

這兩行分別對應不同功能：7890 常作為代理入口，9090 常作為控制介面，但這些只是常見設定值，並非所有用戶端都使用固定連接埠。請以目前設定和啟動日誌為準。

欄位用途發生衝突時的常見情況
mixed-port在同一連接埠接收 HTTP 和 SOCKS 代理連線應用程式無法連上本機代理
port獨立的 HTTP 代理監聽連接埠透過此 HTTP 入口傳送的請求失敗
socks-port獨立的 SOCKS 代理監聽連接埠透過此 SOCKS 入口傳送的請求失敗
external-controller供用戶端或面板呼叫的控制 API 位址面板無法連線、讀取狀態或切換策略

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

步驟一：查詢 TCP 監聽狀態與 PID

開啟 PowerShell 並執行以下指令。範例只查詢本機正在監聽的 7890、9090，不會混入連線至遠端相同連接埠的一般連線。若權限不足或程序資訊不完整，請改用系統管理員身分執行終端機。

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

假設輸出中 7890 對應的 OwningProcess 是 14620，接著查詢程序名稱、執行檔路徑和啟動參數。此處的 14620 僅為範例，執行時請使用本機實際查到的 PID。

PowerShell · 程序詳細資訊
Get-Process -Id 14620 | Select-Object Id, ProcessName, Path
Get-CimInstance Win32_Process -Filter "ProcessId = 14620" |
  Select-Object ProcessId, ExecutablePath, CommandLine

步驟二：確認是否為重複啟動的核心

  • 舊版代理用戶端：優先從系統匣選單退出舊用戶端，再啟動要使用的用戶端。
  • 同一用戶端的背景服務：先在用戶端中停止核心或服務，再正常退出；直接終止子程序可能會觸發自動重啟。
  • 其他開發工具或服務：保留該程序的監聽，替 Clash 選擇另一個未使用的連接埠。
  • 無法辨識的系統程序：先確認服務的所屬項目，不要為了釋出連接埠而直接強制終止。

也可以在命令提示字元中執行以下指令。請注意，findstr :7890 可能會比對到遠端位址或 78900 等相近連接埠；務必確認「本機位址」的連接埠正好是 7890，且狀態為 LISTENING。

Windows 命令提示字元
netstat -ano -p tcp | findstr :7890
tasklist /FI "PID eq 14620"

如果日誌明確指出 UDP 綁定失敗，請改用 Get-NetUDPEndpoint -LocalPort 7890 查詢占用情況。TCP 和 UDP 的連接埠彼此獨立，不能只因數字相同就判定兩者衝突。

macOS 與 Linux：確認監聽位址和服務來源

macOS 可用 lsof 查詢 TCP 監聽狀態；Linux 可用 ss 檢視通訊端和程序。以下指令只會讀取狀態，不會停止任何服務。若沒有輸出，也請確認用戶端是否已因啟動失敗而退出。

macOS
sudo lsof -nP -iTCP:7890 -sTCP:LISTEN
sudo lsof -nP -iTCP:9090 -sTCP:LISTEN
Linux
sudo ss -ltnp 'sport = :7890'
sudo ss -ltnp 'sport = :9090'
ps -p 14620 -o pid,ppid,user,args

請特別確認監聽位址：127.0.0.1:7890 是 IPv4 本機迴路位址；0.0.0.0:7890 表示監聽所有 IPv4 介面，通常會與其他程式綁定相同連接埠上的特定 IPv4 位址互相影響。[::]:7890 則涉及 IPv6，是否同時接受 IPv4 連線取決於系統和通訊端設定。

如果程序由 systemd 或其他服務管理器啟動，請優先透過所屬服務停止或調整設定。只執行 kill 可能會讓服務管理器立刻重新啟動程序，造成「才剛結束，連接埠又被占用」的情況。若在主機上查到的是容器連接埠轉送程序，也要檢查容器的連接埠對應，而不只是容器內部設定。

修改 mixed-port：先確認連接埠可用，再修改持久設定

如果原連接埠要保留給其他程式，可以將混合代理入口從 7890 改為 17890。17890 僅為本文範例，請先用前述指令確認沒有被占用；查無輸出只能表示查詢當下未發現該類監聽，最後仍須以重新啟動後的綁定結果為準。

圖形介面用戶端與 YAML 檔案的修改方式

  1. 在用戶端設定中尋找「連接埠」、「混合連接埠」或「Mixed Port」。若有搜尋欄，可直接搜尋 mixed-port。
  2. 如果用戶端提供全域連接埠設定，請優先從該處修改。各用戶端的選單位置不盡相同，不要把某個版本的「設定」路徑當成通用步驟。
  3. 直接執行 mihomo 時，請修改啟動參數 -f 指向的設定檔；若透過服務啟動，也要檢查服務實際使用的參數和工作目錄。
  4. 如果用戶端會根據訂閱產生執行設定，請使用用戶端支援的持久覆寫或合併設定機制，避免訂閱更新後連接埠又被改回原值。
config.yaml · 僅列出需要調整的頂層欄位
mixed-port: 17890
allow-lan: false
external-controller: 127.0.0.1:9090

不要用這三個欄位取代整份訂閱設定。請在原設定的相應位置修改，並保留既有的代理、策略群組、規則、DNS 和驗證設定。mixed-port 是頂層欄位，不可縮排到 proxies 或 proxy-groups 底下；同一個映射中也不要重複設定同名鍵。

如果設定中同時有 port: 7890 或 socks-port: 7890，只修改混合連接埠可能仍會嘗試監聽舊連接埠。請依需求分別調整或停用獨立的監聽入口，避免多個入口使用相同且互相衝突的位址與 TCP 連接埠。

修改 external-controller：同步面板連線位址

如果錯誤明確指向 9090，可以保留混合連接埠 17890，將控制介面移至已確認未占用的 19090。控制介面不處理瀏覽器的一般代理請求，因此不要順手把系統代理連接埠也改成 19090。

config.yaml · 控制介面遷移範例
mixed-port: 17890
allow-lan: false
external-controller: 127.0.0.1:19090

如果現有設定有 secret，請保留並在外部面板中使用相同密鑰。使用獨立面板時，請將 API 位址同步改為 http://127.0.0.1:19090。有些桌面用戶端會自行管理控制連接埠和密鑰，手動修改產生的檔案反而可能讓介面與核心失去連線；遇到這種情況，請透過用戶端支援的設定修改。

  • 代理連接埠可用、面板卻連不上：優先檢查控制位址、密鑰，以及用戶端是否仍連到舊連接埠。
  • 面板能顯示狀態、瀏覽器卻無法連線：接著檢查混合連接埠和應用程式的代理設定，不要因此認定代理入口已正常運作。
  • 需要從遠端存取面板：必須另外規劃監聽位址、存取控制和防火牆規則，不要只為了解決衝突就開放所有介面。

allow-lan: false 用來限制代理入口的區域網路存取，不能取代控制 API 的位址綁定和驗證。控制介面只在本機使用時，維持迴路位址是更直接的安全界線。

修改連接埠後：同步更新系統代理和應用程式設定

遷移連接埠包含兩個步驟：核心改在新連接埠監聽，呼叫端也要連到新連接埠。若只完成前者，瀏覽器仍連到舊的 7890，就會出現「核心正常運作，但網頁打不開」的情況。

呼叫端需確認的設定
Windows 系統代理「設定」→「網路和網際網路」→「Proxy」中的手動代理位址與連接埠
macOS 系統代理「系統設定」→「網路」→ 目前的網路服務 →「詳細資訊」→「代理伺服器」
瀏覽器代理擴充功能擴充功能中手動儲存的 HTTP 或 SOCKS 位址與連接埠
終端機與指令碼HTTP_PROXY、HTTPS_PROXY、ALL_PROXY 和命令列參數
獨立控制面板控制 API 的位址、連接埠與密鑰，不是混合代理連接埠

系統設定路徑可能隨作業系統版本而異。若由用戶端管理系統代理，通常應先關閉再開啟用戶端中的「系統代理」開關，讓它更新代理連接埠；操作後仍須確認實際設定值。使用獨立代理設定的瀏覽器、IDE 和下載工具不一定會套用系統設定。

在終端機中明確指定代理，可避免沿用舊的環境變數。以下使用 HTTP 代理連線至新的混合連接埠；Windows 請使用 curl.exe，macOS 和 Linux 可使用 curl。

明確指定代理的連線測試
curl.exe --proxy http://127.0.0.1:17890 --noproxy "" --connect-timeout 5 --max-time 15 -I https://example.com/

此處的 5 秒是連線逾時，15 秒是請求的總時限，並非預期的測速結果。請選擇目前網路和策略允許連線的網站進行測試；HTTP 狀態碼不一定要是 200，重點是搭配回應和日誌確認請求是否進入代理。TLS 憑證錯誤、遠端拒絕連線和本機連線遭拒，分屬不同層次的問題。

找不到占用程序，仍然無法綁定的情況

錯誤是權限限制，不是位址遭占用

Windows 的 access permissions 和類 Unix 系統的 permission denied 不應直接視為一般連接埠衝突。在 Windows 中，部分連接埠範圍可能由系統或虛擬化元件保留，可用以下唯讀指令檢查；若選用的連接埠落在保留範圍內，請優先改用未保留且未占用的連接埠。

Windows · 檢視連接埠排除範圍
netsh interface ipv4 show excludedportrange protocol=tcp
netsh interface ipv6 show excludedportrange protocol=tcp

不要為了使用 7890 就直接刪除系統保留範圍。Linux 通常需要相應權限或能力授權才能監聽 1024 以下的連接埠，但 7890、17890 都不屬於低連接埠範圍；仍須依據安全策略和服務日誌判斷具體原因。

舊程序自動重啟，或修改了錯誤的設定檔

如果占用程序的 PID 不斷變動，請檢查開機啟動、背景服務和其他用戶端的自動恢復機制。若 PID 固定但日誌仍顯示舊連接埠，請檢查啟動參數、設定合併順序和用戶端的全域連接埠覆寫。修改訂閱檔中的 7890，不代表最終執行設定也已變更。

如果錯誤是 cannot assign requested address，通常還要確認綁定 IP 是否確實屬於目前裝置。例如切換網路後，舊的區域網路位址可能已不存在；這和其他程式占用連接埠是不同問題。

修復驗收：確認監聽、請求與重新啟動

  1. 確認監聽程序：重新查詢 17890 和控制連接埠，確認程序路徑確實屬於要使用的用戶端或核心，而不是只確認連接埠存在。
  2. 確認請求路徑：使用明確指定代理的指令發送請求，查看用戶端的連線記錄是否出現對應連線，並檢查規則命中情況和出口策略。
  3. 確認設定持久生效：重新啟動用戶端，再更新一次訂閱，確認連接埠沒有恢復成舊值，且系統代理和外部面板都能重新連線。

如果明確指定代理後請求成功，但一般瀏覽器仍無法連線，請繼續檢查系統代理、瀏覽器擴充功能和應用程式本身的設定。如果請求已進入核心，卻在解析或連線遠端時失敗，請轉而排查 DNS、節點和規則，不必再反覆更換本機監聽連接埠。

處理連接埠衝突可依序進行：讀取完整的綁定錯誤，依通訊協定和位址找出占用者，選擇停止重複服務或遷移監聽連接埠，最後同步更新所有呼叫端。這樣既能保留必要的背景服務，也能避免「連接埠改了，應用程式仍連到舊位址」的後續問題。