先看錯誤訊息：是哪個監聽入口發生衝突

Clash 圖形客戶端可以開啟，但核心啟動失敗，日誌出現 address already in use，通常表示準備繫結的位址和連接埠已被其他監聽程序占用。先記下日誌中的協定、位址和連接埠，再查詢程序；不要一看到「啟動失敗」就重新匯入訂閱。

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

這是錯誤訊息範例，並非實測紀錄。訊息指向本機 TCP 7890 連接埠，不能據此認定節點失效。Windows 上也可能出現「通常每個通訊端位址只允許使用一次」等相應提示。若日誌顯示 access denied 或「不允許存取」，還應檢查連接埠保留範圍與安全性原則，不能直接當成一般占用處理。

欄位用途排查重點
mixed-port在同一連接埠接收 HTTP 與 SOCKS 代理要求例如 7890；也要檢查系統代理和手動設定的代理應用程式
port / socks-port分別提供 HTTP、SOCKS 代理入口不能與其他已啟用的監聽程序共用相同位址和連接埠
external-controller提供核心控制 API例如 127.0.0.1:9090；這不是瀏覽器代理連接埠
dns.listen提供核心 DNS 監聽入口例如 127.0.0.1:1053；留意日誌中的 TCP 或 UDP

Windows：查詢監聽 PID，再確認程序路徑

使用 PowerShell 查詢 TCP 監聽狀態

在開始功能表按右鍵，開啟「終端機」或「Windows PowerShell」。先執行下方指令；若查詢受限，或需要讀取其他使用者的程序資訊，再以系統管理員身分開啟終端機。

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

OwningProcess 是程序 ID。假設結果是 1234，接著查看程序名稱、路徑和啟動參數。1234 僅為說明範例，請務必替換成實際查詢結果。

Get-Process -Id 1234 | Select-Object Id, ProcessName, Path

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

程序路徑和啟動參數比程序名稱更有參考價值。不同客戶端可能都會啟動名為 mihomo.exe 的核心；命令列中的設定檔路徑有助於判斷它隸屬哪個客戶端。不要只因程序名稱含有 Clash 或 mihomo，就直接強制結束程序。

命令提示字元的替代查法

netstat -ano -p tcp | findstr ":7890"
tasklist /FI "PID eq 1234"

使用 netstat 時，請核對「本機位址」欄中的連接埠和 LISTENING 狀態。findstr 只會篩選文字，可能同時比對到遠端位址或更長的連接埠號碼；TIME_WAIT 紀錄也不代表目前有程序正在監聽。

查不到監聽程序，卻仍提示無法繫結

先確認客戶端是否反覆重新啟動核心，導致查詢時監聽已消失。如果日誌顯示存取權限錯誤，可在系統管理員終端機檢查 Windows 的 TCP 排除連接埠範圍：

netsh interface ipv4 show excludedportrange protocol=tcp

若目標連接埠落在排除範圍內，優先改用範圍外且未被占用的連接埠。不要任意刪除系統保留項目；Hyper-V、容器或其他網路元件可能依賴這些設定。若錯誤明確指向 IPv6 位址，也要檢查相應的 IPv6 狀況。

macOS 與 Linux：區分一般程序和背景服務

macOS：使用 lsof 查詢監聽程序

開啟「終端機」，查詢 TCP 7890 的監聽程序。-nP 可避免位址和連接埠轉換成名稱，方便逐項比對日誌。

sudo lsof -nP -iTCP:7890 -sTCP:LISTEN
ps -p 1234 -o pid,ppid,user,command

第一個指令傳回的 PID，才是第二個指令要使用的數字。若發現另一個代理客戶端仍在選單列執行，請先從它的選單正常結束，再重新查詢。有些客戶端關閉視窗後仍會繼續執行；視窗消失不代表核心已停止。

Linux：使用 ss 檢查通訊端

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

-l 表示監聽，-t 表示 TCP，-n 保留數字格式，-p 顯示程序資訊。若發行版未安裝 ss，可在已有 lsof 的環境中使用 macOS 章節的查詢指令。

如果程序由 systemd 管理，直接結束程序可能會觸發自動重新啟動。可執行 systemctl status 1234 協助找出所屬服務，再停止已確認的實際服務單元。使用者層級的服務也需透過 systemctl --user 查詢；不要猜測服務名稱後就批次停用。

DNS 衝突請改用 UDP 查詢

前面的指令只檢查 TCP。如果日誌指向 UDP 1053，請改用下列指令；查詢其他連接埠時，請替換數字。同一連接埠號碼上的 TCP 和 UDP 是不同的傳輸協定，TCP 查不到結果不代表 UDP 也未被占用。

# macOS，或已安裝 lsof 的 Linux
sudo lsof -nP -iUDP:1053

# Linux
sudo ss -lunp 'sport = :1053'

判斷衝突來源：重複核心、其他軟體或設定重疊

取得程序路徑後，再選擇處理方式。連接埠遭占用通常不需要解除安裝軟體，也不必先修改節點協定、規則模式或訂閱網址。

  1. 舊客戶端仍在背景執行。例如一個客戶端使用 7890 作為代理連接埠，另一個客戶端啟動時也申請 7890。保留目前要使用的客戶端，正常結束另一個，並檢查它是否設定為開機啟動。
  2. 圖形介面之外還有服務執行個體。手動執行的核心、系統服務或排程工作可能載入另一份設定。先確認程序隸屬哪個服務，再停止對應執行個體，避免服務管理器立即重新啟動它。
  3. 連接埠由其他必要程式使用。若占用程序有明確用途，請保留它，改為 Clash 更換監聽連接埠。不要為了騰出連接埠而結束系統程序或不明服務。
  4. 同一份設定啟用了重疊的監聽入口。檢查 port、socks-port 和 mixed-port 是否使用相同的位址和連接埠。混合入口已能接收兩種要求，不需要再為同一連接埠額外啟用獨立入口。

也要檢查繫結位址。127.0.0.1:7890 僅供本機迴圈介面使用，0.0.0.0:7890 則涵蓋所有 IPv4 介面，兩者可能發生衝突。IPv6 的 [::]:7890 是否同時涵蓋 IPv4，取決於系統和通訊端設定。不要把改成所有介面監聽當作通用解法，這也會擴大代理入口的可連線範圍。

更換監聽連接埠：修改真正生效的設定來源

先查詢 7897，再修改 mixed-port

將前文查詢指令中的 7890 改為 7897，確認目前沒有衝突。若需要長期保留兩套客戶端，請為每套客戶端指定不同的代理入口；也要分別檢查控制 API 等其他監聽入口。

# 僅列出需要核對的欄位，並非完整設定
mixed-port: 7897
allow-lan: false
mode: rule

這段範例適用於僅供本機使用的混合代理入口。合併到現有 YAML 時，請修改已存在的欄位，不要在檔案末尾重複新增第二個 mixed-port。若原本還有獨立的 port 或 socks-port，請依實際用途停用或改用不同連接埠。不要用這三行取代整份訂閱；節點、策略組和規則都要保留。

圖形客戶端設定與訂閱檔案，哪一方優先？

Clash 是核心與設定生態的統稱，不同圖形客戶端的選單和覆寫機制各有不同。先在目前客戶端的「設定」中尋找「連接埠」、「混合連接埠」或「Mixed Port」，記下原值再修改；本文不會將特定客戶端的選單路徑說成適用於所有版本。

  • 客戶端提供連接埠設定：優先在該設定中修改，並依介面指示重新啟動核心。這項設定可能會覆寫訂閱中的同名欄位。
  • 直接執行核心：修改啟動參數指定的設定檔。請確認編輯的是目前載入的檔案，而非另一份下載副本。
  • 訂閱會自動更新：使用客戶端提供的持久化覆寫或合併功能。直接修改下載後的訂閱檔案，更新時可能會被覆寫。

儲存後重新啟動核心，再查看啟動日誌和實際監聽狀態。設定編輯器顯示 7897，不代表執行中的核心已切換連接埠。若修改後仍回報 7890，除了排查占用狀況，也要檢查設定優先順序、設定檔路徑，以及是否重新啟動了正確的執行個體。

若發生衝突的是 external-controller，只需修改對應的控制位址，例如從 127.0.0.1:9090 改為已確認未被占用的 127.0.0.1:9097，並同步更新面板連線設定。控制 API 不應填入一般代理連接埠，也不應為了排查問題而公開至網際網路。

變更連接埠後，哪些位置需要同步更新？

核心已在 7897 成功啟動，但瀏覽器仍連到 7890，常見情況是「連接埠錯誤消失了，網頁還是打不開」。此時應檢查使用代理的應用程式，而不是繼續更換節點。

使用位置需同步更新的內容
系統代理確認連接埠已改為 7897；可先透過客戶端關閉再重新啟用系統代理，接著檢查系統設定
瀏覽器代理擴充功能更新手動設定的 HTTP 或 SOCKS 連接埠，位址通常仍是 127.0.0.1
終端機環境變數檢查 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY 及相應的小寫變數
Git、下載工具、開發工具更新各自獨立儲存的代理位址，不要只修改系統代理
區域網路裝置原本使用電腦代理的手機或電視，也要同步更新為電腦區域網路位址所對應的新連接埠
外部控制面板只有控制 API 連接埠變更時才更新連線位址；請與代理入口分開處理

Windows 11 可在「設定」→「網路和網際網路」→「Proxy」→「手動 Proxy 設定」檢查位址和連接埠。macOS 可在「系統設定」→「網路」→目前的網路連線「詳細資訊」→「Proxy」中檢查。系統版本不同，選單名稱可能有所變更；由客戶端管理的設定也可能在啟動時重新寫入。

終端機中的 HTTPS_PROXY=http://127.0.0.1:7897 表示透過 HTTP 代理連線至 HTTPS 目標，不代表本機代理入口本身必須使用 TLS。若應用程式使用 SOCKS，請選擇相應協定；例如 socks5h 通常表示由代理端解析目標網域名稱，實際支援情況請以該應用程式為準。

TUN 模式會透過虛擬網卡接管符合路由條件的流量，不代表所有應用程式都在使用 mixed-port。不過，應用程式中殘留的手動代理設定仍可能將要求送往舊連接埠。TUN 能否啟動、路由是否正確，以及代理監聽連接埠是否衝突，是需要分別檢查的問題。

確認結果：監聽恢復後，再驗證實際要求

  1. 重新查看日誌，確認原本的繫結錯誤不再重複出現，也沒有新的控制 API 或 DNS 連接埠衝突。
  2. 查詢新連接埠，確認監聽程序屬於目前使用的客戶端，而非另一個舊核心。
  3. 使用明確指定代理的要求測試入口，排除系統代理尚未同步的影響。
  4. 接著用瀏覽器開啟目標網站，查看客戶端連線紀錄和規則命中情況。
# macOS / Linux
curl -I --proxy http://127.0.0.1:7897 --connect-timeout 5 --max-time 15 https://example.com

# Windows PowerShell：明確呼叫 curl.exe
curl.exe -I --proxy http://127.0.0.1:7897 --connect-timeout 5 --max-time 15 https://example.com

這裡的 example.com 是測試網址範例，可替換成要驗證的網站。收到目標網站的回應標頭，表示這次要求已完成相應的連線流程；若出現 Connection refused，請優先檢查位址、連接埠和監聽狀態。若本機代理已接受連線，之後才出現逾時、驗證失敗或上游連線錯誤，請改查節點、DNS、網路連線和規則，不要一概歸因於連接埠占用。

連接埠修復完成的標準是：目標核心穩定監聽、系統及應用程式使用新連接埠，且重新啟動客戶端或更新訂閱後設定仍保留。依照「讀取日誌 → 查詢程序 → 判斷來源 → 修改生效設定 → 同步應用程式 → 驗證要求」的順序處理，通常能清楚區分連接埠衝突與其他網路故障。後續設定可參考Clash 設定教學，常見連線問題則請參閱常見問題。