先看記錄：哪個監聽位址啟動失敗
Clash 用戶端顯示「連接埠遭占用」，通常表示核心無法在指定位址建立監聽。最常見的原因是另一個代理用戶端仍在背景執行，或同一套用戶端的服務程序與手動啟動的核心重複執行。先別急著重新安裝，也不要直接結束所有名稱中含有 Clash 的程序；找出失敗的連接埠和占用程序，就能縮小處理範圍。
在用戶端記錄中搜尋 bind、listen、address already in use 等關鍵字。Windows 也可能顯示「通常每個通訊端位址只允許使用一次」的訊息。以下是用來辨識問題的記錄範例，實際前綴會因核心版本而異：
listen tcp 127.0.0.1:7890: bind: address already in use這則訊息指向本機迴路位址上的 TCP 7890，而不是遠端節點伺服器的連接埠。修改訂閱中的節點連接埠無法解決本機監聽衝突。若記錄顯示 permission denied 或「不允許存取」，則還需檢查系統保留連接埠、權限及安全性原則，不能直接認定是有程序占用。
| 設定欄位 | 用途 | 排查重點 |
|---|---|---|
mixed-port | 在同一入口接收 HTTP 與 SOCKS 代理要求 | 常見範例為 7890，請以實際設定為準 |
port / socks-port | 分別提供 HTTP、SOCKS 代理入口 | 檢查是否與混合入口重複指定相同的監聽位址和連接埠 |
external-controller | 提供控制 API，供介面或面板使用 | 常見範例為 127.0.0.1:9090，並非上網代理連接埠 |
dns.listen | 接收 DNS 查詢 | 若衝突發生在 53 或自訂 DNS 連接埠，應另外檢查 DNS 服務 |
連接埠衝突也與監聽位址及傳輸協定有關。0.0.0.0:7890 代表監聽所有 IPv4 介面，可能與 127.0.0.1:7890 衝突；IPv6 通用監聽是否也涵蓋 IPv4，取決於系統和通訊端設定。TCP 與 UDP 使用相同號碼的連接埠並非同一個監聽資源，排查時請依記錄中的協定確認。
Windows：用 PID 找出占用 7890 的程式
先查監聽狀態，再確認程序名稱
在 PowerShell 中執行以下指令。第一個指令只篩選 TCP 7890 的監聽項目，第二個指令則用來進一步確認程式路徑。若查詢結果範例中的 PID 是 6248，就將這個數字帶入第二個指令；實際操作時請使用本機回傳的 PID。
Get-NetTCPConnection -LocalPort 7890 -State Listen |
Select-Object LocalAddress, LocalPort, OwningProcess
Get-Process -Id 6248 | Select-Object Id, ProcessName, Path若習慣使用命令提示字元，也可以使用系統內建的 netstat 和 tasklist：
netstat -ano -p tcp | findstr ":7890"
tasklist /FI "PID eq 6248"findstr 是文字篩選工具，也可能比對到遠端連接埠或 78900 這類數字，因此必須再確認「本機位址」欄位是否確實以 :7890 結尾，並確認狀態為 LISTENING。只有 TIME_WAIT 的記錄，不能證明仍有程式在監聽；不要把所有連線記錄都當成衝突來源。
- 占用者是另一個代理用戶端：先從它的系統匣選單正常結束，再重新查詢連接埠。
- 占用者是目前用戶端的核心：確認是否已啟用服務模式，同時又手動執行了一份核心。
- 程序結束後立刻以新的 PID 出現：開啟「工作管理員」→「服務」，或執行
services.msc，確認是否有相關背景服務負責重新啟動它。
查不到監聽項目，卻仍顯示繫結失敗
先確認錯誤指向的確實是 7890，而不是 9090 或其他位址。若 Windows 記錄顯示存取權限問題，可檢視 TCP 排除連接埠範圍：
netsh interface ipv4 show excludedportrange protocol=tcp
netsh interface ipv6 show excludedportrange protocol=tcpHyper-V、容器及相關網路元件可能會保留連接埠。若目標連接埠位於排除範圍內，通常改用已確認可用的連接埠更合適，而不是刪除來源不明的系統保留設定。以系統管理員身分執行用戶端，也不一定能解除這類限制。
macOS 與 Linux：區分桌面用戶端和背景服務
macOS 使用 lsof
開啟「應用程式」→「工具程式」→「終端機」，查詢 TCP 7890 的監聽程序。-nP 會保留數字位址和連接埠，避免名稱解析影響判讀；若權限不足而無法查看完整結果，再使用 sudo 查詢。
lsof -nP -iTCP:7890 -sTCP:LISTEN
ps -p 6248 -o pid,ppid,command查看輸出中的 COMMAND 和 PID，再用第二個指令檢查完整的啟動命令。有些用戶端關閉視窗後仍會常駐於選單列，需從選單列選擇結束。若程式會在登入時自動啟動，可前往「系統設定」→「一般」→「登入項目與延伸功能」檢查；不同 macOS 版本的最後一層選項名稱可能略有不同。
Linux 使用 ss
在 Linux 上，ss 可以同時查看監聽位址和程序資訊。以下兩個指令分別檢查 TCP 與 UDP；只有記錄或特定功能涉及 UDP 時，才需要執行第二個指令。
sudo ss -ltnp 'sport = :7890'
sudo ss -lunp 'sport = :7890'
ps -p 6248 -o pid,ppid,args若程序由 systemd 管理，只結束程序可能會觸發自動重新啟動。可先執行 systemctl status 6248，嘗試透過 PID 查找所屬的系統服務；使用者層級的服務則檢查 systemctl --user。確認實際的單元名稱後，再使用相應的 stop 操作停止服務；不要假設所有安裝方式使用相同的服務名稱。
使用 Docker 或其他容器時，也要確認主機端的連接埠對應。容器內監聽 7890 與主機發布 7890 是兩層不同的設定；若衝突發生在主機端，只修改容器內的設定，未必會改變主機端的占用狀況。
修改 mixed-port：變更實際執行的設定，而非只改訂閱副本
若必須保留占用中的程式，可以為 Clash 更換代理入口。本文以將 7890 改為 7893 為例：7893 僅為範例，不保證本機未被占用，修改前請先用相同指令查詢。
先確認用戶端實際使用哪一份設定
圖形介面用戶端通常會根據「訂閱原始內容、覆寫設定、用戶端連接埠設定」產生執行中的設定。只修改下載的 YAML，可能在更新訂閱後被覆蓋，也可能根本不會套用至核心。各用戶端介面上的選項名稱不盡相同，請搜尋「連接埠」、「混合連接埠」或「Mixed Port」，並優先使用用戶端支援的持續性設定或覆寫機制。
- 圖形介面用戶端：記下目前的連接埠值，在設定中修改混合連接埠，套用後重新啟動核心，並查看啟動記錄確認最終監聽位址。
- 直接執行核心：檢查啟動命令中的
-f設定檔參數及-d工作目錄，編輯實際載入的檔案。 - 服務或容器：檢查服務啟動參數、掛載路徑和連接埠對應，避免修改到另一份同名設定。
以下是適用於 mihomo 的頂層設定片段，並非完整的訂閱設定。請合併至現有設定，而不是取代整個檔案；若已有同名鍵，直接修改其值，不要新增重複鍵。
mixed-port: 7893
allow-lan: false
bind-address: 127.0.0.1mixed-port 可同時接收 HTTP 與 SOCKS 要求，但不代表它可以與獨立的 port 或 socks-port 在相同位址重複繫結。請檢查現有的獨立入口，避免也將它們設定為 7893。監聽位址也可能受用戶端產生設定的方式影響，因此最終應以系統查詢結果為準。
直接管理 mihomo 設定時，可以先檢查語法與設定。以下指令假設終端機目前所在目錄中有實際的 config.yaml：
mihomo -t -f ./config.yaml檢查通過不代表連接埠一定能成功繫結：設定檢查與執行時建立監聽是兩回事。套用設定後，仍需查看記錄和連接埠狀態。圖形介面用戶端也可能需要「重新啟動核心」才能完整套用監聽連接埠的變更，不能只確認輸入欄位是否成功儲存。
控制連接埠 9090 衝突：別用它取代代理連接埠
external-controller 是控制 API 的監聽位址，用戶端介面會透過它讀取連線、切換策略或變更執行狀態。它不是 HTTP 上網代理。若衝突發生在 127.0.0.1:9090，只修改 mixed-port 無法解決問題；反過來說，把瀏覽器代理設為 9090，也無法正常轉送網頁要求。
自行管理設定和控制面板時，可先確認連接埠未被占用，再將控制位址改為以下範例值：
external-controller: 127.0.0.1:9093修改後，請同步更新外部面板的控制位址，並保留原有的 secret 驗證設定。若控制連接埠由圖形介面用戶端管理，應優先在用戶端提供的設定中修改；只覆寫核心欄位而未更新介面的連線參數，可能導致「核心仍在轉送流量，介面卻顯示未連線」的狀況。
變更代理連接埠後，哪些設定必須同步更新？
將連接埠從 7890 改為 7893 後，所有仍指向舊入口的應用程式都會連線失敗。用戶端顯示「核心執行中」，只代表核心已啟動，無法證明瀏覽器、終端機和其他工具已改用新位址。
| 使用情境 | 需同步更新的內容 |
|---|---|
| 系統代理 | 重新套用用戶端的系統代理設定，確認位址已變更為 127.0.0.1:7893 |
| 瀏覽器代理擴充功能 | 將手動設定的 HTTP 或 SOCKS 連接埠改為 7893；使用跟隨系統設定的模式則需另行確認 |
| 終端機環境變數 | 更新 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY，以及實際使用的小寫變數 |
| 開發工具 | 檢查 Git、套件管理工具和 IDE 各自儲存的代理位址 |
| 區域網路裝置 | 若原先允許區域網路連線，請同步更新連接埠並檢查防火牆；不要將 127.0.0.1 當成另一台裝置的位址 |
Windows 11 可前往「設定」→「網路和網際網路」→「Proxy」檢查手動代理；macOS 可前往「系統設定」→「網路」→目前的網路連線→「詳細資訊」→「Proxy」檢查。用戶端重新設定系統代理後，也建議在系統設定頁面確認實際值，避免被既有工具再次覆寫。
僅修改目前終端機工作階段的範例
# macOS / Linux：目前的 shell
export http_proxy=http://127.0.0.1:7893
export https_proxy=http://127.0.0.1:7893
# PowerShell：目前工作階段
$env:HTTP_PROXY = "http://127.0.0.1:7893"
$env:HTTPS_PROXY = "http://127.0.0.1:7893"這裡的 HTTPS 代理變數仍使用 http://，表示透過本機 HTTP 代理的 CONNECT 機制存取 HTTPS 目標，並非將目標網站降級為 HTTP。若原本使用 SOCKS，可將支援 SOCKS 的應用程式指向 socks5h://127.0.0.1:7893；是否會讀取這些環境變數，需依各應用程式分別確認。
TUN 模式會透過虛擬網卡接管流量，與應用程式主動連線至混合連接埠的路徑不同。因此，TUN 模式下某個應用程式仍能上網，不代表舊的 7890 代理設定已修復；手動設定代理的工具仍可能連線至舊連接埠。
分三層驗證：監聽狀態、代理要求、應用程式實際連線
- 確認監聽程序：重新查詢 7893，確認預期的核心正在監聽，且沒有新的繫結失敗記錄。
- 確認代理協定：明確指定新連接埠發出一次要求，不依賴系統代理是否已更新。
- 確認常用應用程式：開啟瀏覽器或開發工具，並在用戶端的連線清單中檢查對應要求及規則比對結果。
# macOS / Linux
curl -I --connect-timeout 5 --max-time 15 --noproxy "" --proxy http://127.0.0.1:7893 https://example.com
# Windows PowerShell：明確呼叫 curl.exe
curl.exe -I --connect-timeout 5 --max-time 15 --noproxy "" --proxy http://127.0.0.1:7893 https://example.com上述測試將連線逾時設為 5 秒、總時間限制設為 15 秒，並清除該次要求的代理略過清單。若顯示無法連線至 127.0.0.1:7893，請優先確認監聽是否成功。若代理連線已建立，之後才出現 TLS 錯誤、上游逾時或策略錯誤，排查重點就應轉向節點、DNS 和規則，而非繼續更換本機連接埠。
收到目標 HTTP 回應有助於確認要求鏈路，但不代表節點頻寬、所有網站或所有應用程式都正常。某些網站也可能拒絕 HEAD 要求，請配合回應內容判斷。測試時一次只變更一個變數，並保留修改前的連接埠記錄，會比同時調整規則、DNS 和 TUN 更容易找出問題。
常見問題：重新啟動、雙用戶端與反覆遭占用
重新啟動電腦後恢復正常，還需要繼續排查嗎？
若只發生一次，可以先觀察；若每次登入後都復發，請檢查自動啟動的用戶端和背景服務。重新啟動可能暫時改變啟動順序，卻沒有消除兩個程式爭用同一連接埠的原因。保留一次衝突時的 PID、程式路徑和記錄，比反覆重新啟動更有幫助。
兩個 Clash 用戶端可以同時執行嗎？
可以分配不同的代理連接埠和控制連接埠，但系統代理設定、TUN 路由和 DNS 接管仍可能互相影響。日常使用時，通常保留一個負責接管流量的用戶端會比較容易維護。只更換 7890，無法自動隔離兩個用戶端的所有系統層級設定。
剛改好連接埠，更新訂閱後又變回 7890，該怎麼辦？
這通常表示修改的是會重新產生的設定層。請檢查用戶端的連接埠設定或持續性覆寫功能，更新訂閱後再查看最終執行設定和監聽記錄。不要只根據訂閱編輯器顯示的內容，判斷核心目前使用的值。
處理這類故障的步驟可以固定下來：先看記錄確認位址與協定，再找出監聽程序，接著決定結束重複執行的實例或調整連接埠，最後同步更新應用程式設定並進行測試。若要了解用戶端的基本匯入與流量接管流程，可參閱Clash 使用指南；核對設定欄位時，可參考協定與設定參考。