先確認監聽失敗，再決定是否更改連接埠

Clash 顯示 7890 連接埠遭占用時，先確認是哪個程序正在監聽，再決定要關閉重複執行的執行個體，或改用其他監聽連接埠。只修改系統代理的連接埠數字，不會改變核心實際監聽的位置；只改設定檔、未更新系統代理，瀏覽器仍會連線到舊連接埠。

本文以本機代理位址 127.0.0.1:7890 為起點，並以 17890 作為替代範例。17890 不保證是未使用的專用連接埠，使用前仍須查詢。Clash、Clash Meta（現稱 mihomo）及其圖形用戶端的預設連接埠可能不同，請以目前生效的設定與啟動記錄為準。

分別處理不同的錯誤訊息

記錄或現象優先檢查項目
address already in use已有程序正在監聽、核心重複執行，或設定中多個入站項目使用相同的位址與連接埠。
Only one usage of each socket addressWindows 常見的位址占用錯誤；先查詢本機監聽連接埠與 PID。
permission denied 或 access permissions可能是權限、安全軟體或系統保留連接埠範圍所致，不應直接判定為其他軟體占用。
瀏覽器顯示代理連線失敗確認代理位址是否正確、核心是否已啟動；僅憑此現象無法證明是連接埠衝突。

先開啟用戶端記錄，記下出錯的位址、連接埠與通訊協定。若記錄實際指向 9090，應檢查控制介面，而非修改 7890。若設定未啟用 mixed-port，則應排查實際使用的 port 或 socks-port。

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

先在終端機檢查 TCP 監聽狀態。開啟 PowerShell 或命令提示字元，執行以下命令；若程序資訊不完整，再以系統管理員權限重試。

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

找出「本機位址」欄位以 :7890 結尾、狀態為 LISTENING 的記錄。不要把「外部位址」中的 7890，或狀態為 TIME_WAIT 的連線誤認為正在監聽的服務。以下僅為格式範例，不代表目前裝置的實際輸出：

  TCP    127.0.0.1:7890    0.0.0.0:0    LISTENING    6420

最末欄的 6420 是範例程序識別碼。請將它替換成實際 PID，再查詢程序名稱：

tasklist /FI "PID eq 6420"

使用 PowerShell 精確篩選本機連接埠

若以字串篩選得到太多結果，可改用以下命令。查無結果通常表示查詢當下未發現該 TCP 監聽；若命令出現權限或其他錯誤，應先排除錯誤，不能據此認定連接埠未被占用。

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

Get-Process -Id 6420 |
  Select-Object Id, ProcessName, Path
  1. 若占用者是另一個 Clash 用戶端，請先從系統匣選單正常結束程式，並確認背景核心也已停止。
  2. 若占用者是同一用戶端的舊核心，先關閉用戶端，再確認服務模式是否仍在執行。請透過用戶端提供的服務管理介面停止服務，避免反覆啟動而產生更多執行個體。
  3. 若占用者是必須保留的開發服務或其他代理程式，請讓該程式繼續使用原連接埠，並為 Clash 指定新的未使用連接埠。

macOS 與 Linux：使用 lsof 檢查監聽狀態

在 macOS 的「終端機」中執行 lsof；Linux 若未安裝此工具，可改用 ss。以下命令只檢查 TCP 監聽，方便先排查瀏覽器透過 HTTP 代理建立連線的入口。

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

-nP 會停用位址與連接埠的名稱解析；輸出中的 COMMAND 是程序名稱，PID 是程序編號，NAME 是監聽位址。也可以進一步檢查完整啟動命令，分辨由桌面用戶端啟動的核心與手動執行的服務：

ps -p 6420 -o pid,ppid,command

Linux 也可以執行：

sudo ss -ltnp 'sport = :7890'

127.0.0.1:7890 表示監聽 IPv4 回送位址；0.0.0.0:7890 表示監聽所有 IPv4 位址。萬用位址的監聽可能與相同連接埠的回送位址監聽衝突。若看到 [::]:7890，也須考量系統的 IPv6 雙堆疊行為，不要只因它不是 IPv4 位址就排除衝突。

必要時另外檢查 UDP

TCP 與 UDP 使用不同的連接埠空間。UDP 7890 遭占用，不代表 TCP 7890 一定無法啟動；但若已啟用相關 UDP 入站功能，仍應根據記錄繼續排查。

# macOS / 已安裝 lsof 的 Linux
sudo lsof -nP -iUDP:7890

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

確認程序屬於哪項服務後，優先透過該應用程式介面或服務管理工具停止。若服務由自動重啟機制管理，單獨結束子程序可能會觸發重新啟動，連接埠很快又會被占用。

方法一：在用戶端設定中修改連接埠

圖形用戶端通常會在啟動時產生執行設定。這類用戶端應優先透過設定介面修改連接埠，不要先編輯暫時產生的檔案。不同用戶端與版本的選單名稱不盡相同，可先在「設定」中尋找「連接埠」、「代理連接埠」或「混合連接埠」。

  1. 先依照前述命令檢查 17890，將查詢中的 7890 替換為 17890。
  2. 記下目前的連接埠與系統代理開關狀態。若用戶端持續啟動失敗，可暫時關閉系統代理，避免應用程式持續連線至無法使用的入口。
  3. 開啟用戶端「設定」，找出「混合連接埠」或標示為 mixed-port 的欄位，填入 17890。不要誤改「外部控制」、「API」或「控制器連接埠」。
  4. 儲存設定，並依介面提示重新載入設定或重新啟動核心。只關閉設定視窗，不一定會套用變更。
  5. 檢查記錄與系統監聽狀態，確認目標核心已監聽 17890，再重新啟用系統代理。

若用戶端分別顯示「HTTP 連接埠」與「SOCKS 連接埠」，請先確認目前是否啟用混合連接埠。不要將三個欄位全部改成 17890；它們並非三種可互換的名稱。若無法確認欄位用途，請先參閱設定參考。

方法二：修改 config.yaml 的 mixed-port

直接執行核心或明確使用本機設定時，可以修改實際載入的 YAML 檔案。先查看啟動參數或用戶端顯示的設定路徑，確認編輯的是目前生效的檔案。檔名為 config.yaml，不代表它一定正在使用中。

以下是本機使用情境的頂層欄位片段。請合併至現有設定，保留原有節點、策略群組與規則；這不是可直接取代整份訂閱的設定檔。

mixed-port: 17890
allow-lan: false
mode: rule
log-level: info
  • mixed-port：同一個監聽入口可接受 HTTP 代理與 SOCKS 代理連線，應用程式仍須選擇正確的代理通訊協定。
  • allow-lan: false：適用於僅供本機使用的情境；不要為了解決本機連接埠衝突而任意開啟區域網路存取。
  • mode: rule：保留規則分流模式。修改入站連接埠不需要同時變更分流模式。
  • log-level: info：方便查看啟動資訊；排除問題後可還原原本的記錄層級。

檢查重複鍵與其他入站設定

欄位應位於 YAML 頂層，並使用空格縮排；不要放在 proxies 或 proxy-groups 之下。同一層級不要重複寫入 mixed-port；不同解析器處理重複鍵的方式可能不同，不應依賴「後寫的值覆蓋先寫的值」。

也要搜尋現有的 port、socks-port 與其他入站監聽設定。不要讓 port: 17890 與 mixed-port: 17890 同時嘗試占用相同的 TCP 位址。是否保留獨立入站，應依應用程式的實際需求決定。

驗證設定後重新載入

直接使用 mihomo 時，可透過核心的設定測試參數檢查語法。以下範例假設目前目錄中的設定檔就是執行時使用的檔案；若實際路徑不同，請改用正確路徑。

mihomo -t -f ./config.yaml

設定測試通過，不代表已成功開始監聽。儲存後還要重新載入或重新啟動核心，再查看啟動記錄。訂閱管理的檔案可能會在更新訂閱時覆蓋手動修改；請使用用戶端支援的持續性覆寫方式，或交由用戶端的全域設定管理連接埠。

同步更新系統代理與應用程式代理

核心改用 17890 後，所有仍指向 7890 的代理入口都要逐一檢查。系統代理、瀏覽器擴充功能、終端機環境變數與開發工具各自儲存設定，通常不會一併更新。

入口需要確認的設定值
Windows 11「設定」→「網路和網際網路」→「Proxy」→「手動 Proxy 設定」→「使用 Proxy 伺服器」，位址為 127.0.0.1，連接埠為 17890。
macOS「系統設定」→「網路」→目前的網路連線→「詳細資訊」→「代理伺服器」，檢查網頁代理、安全網頁代理，以及已啟用的 SOCKS 代理。
瀏覽器代理擴充功能更新目前設定檔中的伺服器連接埠，確認不再使用 7890。
終端機與開發工具檢查 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY，以及 Git、套件管理工具與 IDE 各自的代理設定。

使用用戶端的「系統代理」開關時，可在新連接埠生效後先關閉再開啟，並到作業系統設定中再次確認。macOS 的「安全網頁代理」是供 HTTPS 網站使用的代理連線名稱，不代表本機代理入口必須啟用 TLS。

若終端機使用環境變數，可在目前的 macOS 或 Linux shell 中更新：

export HTTP_PROXY=http://127.0.0.1:17890
export HTTPS_PROXY=http://127.0.0.1:17890
export ALL_PROXY=socks5h://127.0.0.1:17890

此處的 HTTPS_PROXY 仍使用 http://，表示透過本機 HTTP 代理建立連線；在支援此寫法的工具中，socks5h 表示由代理端解析目標網域名稱。這些命令只會影響目前的 shell 及其後續子程序，不會自動寫入永久設定，而且並非所有工具都會讀取這些變數。

確認修復結果並找出持續衝突的原因

修復後至少確認三件事：新連接埠確實正在監聽、監聽者是預期的核心，以及應用程式能透過該入口送出請求。先用前述命令查詢 17890，再明確指定代理發出請求，避免受到系統代理或環境變數影響。

# macOS / Linux
curl -I --proxy http://127.0.0.1:17890 --connect-timeout 5 --max-time 15 https://example.com/

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

5 秒是連線逾時上限，15 秒是整次請求的時間上限，並非速度測試結果。若出現 Connection refused，優先檢查監聽位址與核心狀態；若代理已接受連線但之後逾時，請繼續查看規則命中、出口節點與 DNS 記錄。收到 HTTP 回應只能證明這次請求經過該入口，不代表所有流量都已依預期代理。

連接埠未被占用但仍無法啟動

  • Windows 保留連接埠：若記錄顯示存取權限錯誤，且沒有監聽程序，可執行下方命令查看排除範圍。新連接埠應避開列出的範圍，不要因此直接刪除系統保留項目。
  • 舊程序自動重新啟動：檢查系統服務、登入啟動項目，以及是否同時執行兩個圖形用戶端。
  • 修改了錯誤的設定檔：確認實際載入路徑、啟動參數與用戶端覆寫設定，再比對重新載入後的記錄。
  • 虛擬化環境的網路邊界不同：Docker、WSL 與主機可能使用不同的網路命名空間，應在實際綁定連接埠的一側檢查；容器內監聽成功，不代表主機的連接埠映射也成功。
netsh interface ipv4 show excludedportrange protocol=tcp
netsh interface ipv6 show excludedportrange protocol=tcp

啟用 TUN 後還需要修改系統代理嗎？

TUN 透過虛擬網卡與路由接管流量，並不等同於讓應用程式連線到 7890。即使 TUN 仍可運作，設定中啟用的混合連接埠也可能無法單獨綁定。反過來說，混合連接埠恢復監聽，也不能證明 TUN 路由與 DNS 已正常。排查時應分別驗證這兩種流量接管方式，不要以「瀏覽器還能開啟網頁」取代監聽檢查。

最後重新啟動一次用戶端，確認連接埠仍設定為 17890，再視需要測試更新訂閱後的設定。若必須恢復為 7890，請先確認原占用程序已結束，並一併還原系統代理與應用程式代理設定。記下排查前後使用的連接埠，可減少下次更換用戶端時重複檢查。