先看記錄：7890 是代理入口，9090 是控制介面

Clash 或使用 mihomo 核心的用戶端啟動失敗時，先展開核心記錄，找出包含 listen、bind 和具體位址的錯誤行。若看到 address already in use，通常表示該位址與連接埠已有程序在監聽。Windows 上也可能出現「通常每個通訊端位址只允許使用一次」的提示。先記下連接埠、繫結位址與通訊協定，再決定要停止程序或修改設定。

7890 和 9090 是常見設定值，但並非所有用戶端都固定使用這些連接埠。實際入口請以目前生效的設定和啟動記錄為準。兩種連接埠用途不同，別看到一個錯誤就把所有連接埠都改掉。

設定項目範例值用途與影響
mixed-port7890在同一個入口接受 HTTP 代理與 SOCKS5 連線，瀏覽器、終端機或系統代理可能會使用此連接埠。
external-controller127.0.0.1:9090提供控制 API，讓用戶端或 Web 面板讀取狀態、切換策略；不是網頁代理入口。
port7892獨立的 HTTP 代理入口；只有啟用此項目時才需要檢查。
socks-port7893獨立的 SOCKS 入口，不能只改 mixed-port 就以為它也跟著變更。

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

步驟一：查看監聽狀態，不要只搜尋數字

開啟 PowerShell，執行以下兩個指令。輸出中的「本機位址」應以目標連接埠結尾，狀態應為 LISTENING；最後一欄是程序 ID，也就是 PID。單純搜尋 7890 也可能找到遠端位址或其他連接埠中的數字，因此務必確認完整欄位。

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

也可以直接在 PowerShell 依本機連接埠篩選監聽程序，避免把已建立的連線誤認為連接埠遭占用：

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

127.0.0.1:7890 表示 IPv4 迴路位址正在監聽；0.0.0.0:7890 則表示監聽所有 IPv4 介面。後者通常也會阻止其他程序在本機繫結相同連接埠。IPv6 的 [::]:7890 是否也影響 IPv4，還取決於通訊端設定；排查時別忽略 IPv6 的輸出。

步驟二：確認程式路徑，再關閉重複執行的程序

以下以 PID 1234 示範查詢指令；實際執行時，請替換成前一個指令輸出中的 PID。PID 會隨程序重新啟動而改變，切勿照抄範例直接結束程序。

tasklist /FI "PID eq 1234"
Get-Process -Id 1234 | Select-Object Id,ProcessName,Path
  • 其他代理用戶端：先從系統匣結束其他用戶端，同時關閉其開機啟動或自動啟動核心的功能，再啟動要保留的用戶端。
  • 同一用戶端的背景核心：關閉視窗可能只是將程式縮到系統匣。請使用系統匣中的結束選項，再確認監聽狀態是否消失。
  • 由服務管理的程序：先確認服務所屬程式，再透過該用戶端或「服務」管理員停止服務。只結束子程序的話，監控程序可能會立即重新啟動它。
  • 其他開發工具：若連接埠屬於仍在使用的服務，建議保留該服務，改用其他 Clash 連接埠通常更合適。

查詢路徑時若遇到權限不足，可用系統管理員身分重新開啟終端機。不要只因程序名稱相似就結束系統服務，也別把「以系統管理員身分執行」當成解決所有繫結衝突的方法：系統管理員權限不會自動釋放已被其他程序占用的連接埠。

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

在 macOS 的「終端機」中可使用 lsof。若 Linux 已安裝此工具，也能使用相同指令。-nP 會保留數字位址與連接埠，-sTCP:LISTEN 則只列出 TCP 監聽項目，方便直接核對 PID 與程序名稱。

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

Linux 也可用 ss 一次查詢兩個連接埠。若一般使用者看不到程序資訊，再提高權限，不必先反覆重新啟動核心。

sudo ss -ltnp '( sport = :7890 or sport = :9090 )'

桌面用戶端與 systemd 服務不要重複啟動同一個入口

Linux 常見的衝突情況是：先前已將 mihomo 設定為背景服務，之後又開啟內含核心的桌面用戶端。兩者讀取不同設定，卻都嘗試監聽 7890。若部署時使用的服務名稱確實是 mihomo.service，可先查看狀態與記錄：

systemctl status mihomo --no-pager
journalctl -u mihomo -n 50 --no-pager

確認要改用桌面用戶端後，可執行 sudo systemctl stop mihomo 停止該服務；是否停用開機自動啟動，請依實際部署情況決定。若服務名稱不同，請使用實際名稱。macOS 則建議先從選單列結束舊用戶端；如果核心是由背景啟動工作執行，應透過原本的管理方式停止，否則結束一次程序後，它仍可能再次啟動。

修改 mixed-port：同步更新設定入口與代理設定

先備份，再確認最終設定由哪裡產生

圖形介面用戶端可能透過設定頁、覆寫設定或設定合併機制產生核心執行檔。直接修改快取中的訂閱 YAML，可能在更新訂閱或重新啟動用戶端後遭到覆蓋。因此請先備份設定，再透過目前用戶端提供的持久設定入口修改連接埠；選單名稱依用戶端而異，別將某個用戶端的選單路徑套用到所有軟體。

  1. 查詢準備使用的新連接埠，例如 7891 和 9091，確認目前沒有程序在監聽。
  2. 若介面提供「混合連接埠」欄位，請將值改為 7891 並儲存；手動部署則修改實際載入的設定檔。
  3. 依用戶端的要求重新載入設定或重新啟動核心，再查看記錄中的實際監聽位址。
  4. 更新系統代理、瀏覽器代理擴充功能、命令列環境變數，以及其他手動設定的代理位址。

以下片段需合併至現有設定的頂層，並非可單獨匯入使用的完整訂閱。請保留現有節點、策略組與規則；若已有同名鍵，請修改原值，不要重複新增。兩個新連接埠僅供示範，使用前仍須確認未被占用。

config.yaml · 連接埠設定片段
mixed-port: 7891
allow-lan: false
external-controller: 127.0.0.1:9091

另外確認是否啟用了獨立的 port、socks-port、redir-port 或 tproxy-port。錯誤指向哪個入口，就處理哪個入口。需要各自監聽的入口，不要設成相同的位址與連接埠。

分別檢查系統代理與終端機變數

Windows 11 可在「設定」→「網路和網際網路」→「Proxy」→「手動設定 Proxy」中確認位址與連接埠；macOS 可在「系統設定」→「網路」→目前的網路服務→「詳細資訊」→「代理伺服器」中確認。若由用戶端自動設定系統代理，通常應讓用戶端重新套用設定，以免手動設定之後又被覆蓋。

終端機環境變數不會隨系統代理變更而自動更新。以下只會修改目前的終端機工作階段，適合用來測試新連接埠；若啟動指令碼或開發工具設定中仍寫著 7890，也要另外修改。

PowerShell · 目前工作階段
$env:HTTP_PROXY = "http://127.0.0.1:7891"
$env:HTTPS_PROXY = "http://127.0.0.1:7891"
macOS / Linux · 目前 shell
export http_proxy=http://127.0.0.1:7891
export https_proxy=http://127.0.0.1:7891

HTTPS_PROXY 這個變數名稱表示用於 HTTPS 目標的代理設定，不代表本機代理位址必須寫成 https://。此處連線的是本機 HTTP 代理入口，因此仍使用 http://127.0.0.1:7891。若也設定了 ALL_PROXY 或應用程式專用代理，請一併檢查；不同工具對變數大小寫與優先順序的處理方式各異。

修改 9090：同步更新控制面板位址與驗證設定

若發生衝突的是 external-controller，將它改為 127.0.0.1:9091 後，也要把 Web 面板中的後端位址改為 http://127.0.0.1:9091。請保留現有的 secret，並在面板中填入相符的驗證資訊。部分桌面用戶端會自行管理控制介面與驗證值，建議優先透過用戶端設定修改，避免前端與核心設定不一致。

  • 代理可用，面板卻無法連線：先確認面板是否仍連線至舊的 9090，再檢查驗證資訊與用戶端記錄。
  • 介面回傳 401：通常表示 HTTP 服務已回應，但請求未附上有效的驗證資訊；這不代表連接埠仍遭占用。
  • 連線遭拒：通常表示該位址當時沒有可接受連線的監聽程序，請繼續確認核心是否已啟動，以及繫結位址是否正確。

修改後如何驗證：分別測試監聽、代理與控制介面

一、確認新連接埠由預期的程序監聽

重新執行前面的查詢指令，將連接埠換成 7891 和 9091。除了確認有監聽，也要確認 PID 屬於目前要使用的核心。若舊程序尚未結束，而瀏覽器仍連到舊連接埠，可能會讓人誤以為問題已經修好。

二、明確指定代理，排除系統代理設定殘留

Windows PowerShell 請使用 curl.exe，避免某些環境將 curl 解讀為其他指令。macOS 與 Linux 則使用 curl 即可。以下指令會明確連線至新入口，--noproxy "" 用來清除這次請求的略過清單；範例目標僅供連線測試，不是速度測試基準。

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

收到目標網站的回應，表示本機代理入口至少能處理這次請求。不過請求最後可能依規則走 DIRECT，不能只憑指令成功就判定遠端節點可用。請搭配用戶端的連線記錄，查看該網域符合的規則、策略組與實際出口。

三、單獨測試控制 API

curl.exe --connect-timeout 5 --max-time 10 -i http://127.0.0.1:9091/version

macOS 與 Linux 請將指令中的 curl.exe 改為 curl。未啟用驗證時，正常介面會回傳版本資訊；若已啟用驗證，未附上憑證時可能回傳 401。不要為了方便測試而刪除現有金鑰，也不要公開包含真實金鑰的完整指令或記錄截圖。

找不到監聽程序卻仍無法繫結：檢查保留連接埠與錯誤類型

如果記錄顯示 permission denied、access permissions 或 cannot assign requested address，就不應繼續當成一般占用問題處理。Windows 的連接埠排除範圍、繫結至不存在的本機位址，以及安全軟體限制，都可能造成不同類型的繫結失敗。

Windows 可用以下指令檢查 TCP 排除範圍。若目標連接埠落在範圍內，請優先選擇範圍外且未被占用的連接埠，並檢查虛擬化或網路元件的相關設定；不要直接刪除由系統管理的排除項目。

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

若錯誤指向 UDP 監聽，前文只查詢 TCP 的指令無法提供完整結果。Windows 可執行 Get-NetUDPEndpoint -LocalPort 7890，Linux 可執行 sudo ss -lunp，macOS 可執行 sudo lsof -nP -iUDP:7890。TCP 與 UDP 使用不同的連接埠空間，請依記錄中發生錯誤的通訊協定分別排查。

最後確認是否修改了錯誤的設定檔。以服務方式啟動的 mihomo 可能透過啟動參數指定其他設定目錄；桌面用戶端也可能在執行時產生設定。若重新啟動後仍監聽舊連接埠，應先確認設定來源與覆寫順序，而不是不斷更換數字。

連接埠衝突排查清單

  1. 查看記錄：記下失敗的位址、連接埠、TCP 或 UDP，以及完整錯誤類型。
  2. 確認歸屬：使用 netstat、lsof 或 ss 找出監聽 PID，核對程式路徑與啟動方式。
  3. 做出選擇：停止不再需要的重複執行程序，或為需要同時運作的服務設定不同連接埠。
  4. 修改持久設定：修改實際生效的 mixed-port 或 external-controller，避免訂閱更新後恢復舊值。
  5. 同步更新使用端：代理連接埠對應系統代理與應用程式設定；控制連接埠則對應面板後端位址與驗證資訊。
  6. 分層驗證：先確認監聽狀態，再測試明確指定的代理，最後檢查控制 API 與規則比對結果。

TUN 模式會透過虛擬網卡接管流量，與本機代理監聽屬於不同層面。啟用 TUN 不會自動釋放遭占用的 7890 或 9090。請先處理記錄中明確報錯的監聽入口，再排查 TUN 權限、路由或 DNS，避免多個問題互相干擾。