先確認衝突的是哪個連接埠
出現「address already in use」、「bind failed」或「連接埠已被佔用」時，通常可以直接判斷：Mihomo 核心準備監聽某個本機連接埠，但該連接埠已被其他程序佔用。常見的衝突連接埠是 7890，也可能是 7891、9090，或設定中自訂的數值。
mixed-port 是混合代理連接埠，同一個監聽入口可以接收 HTTP 代理與 SOCKS5 代理連線。許多 Clash 客戶端預設使用 7890。瀏覽器擴充功能、系統代理與命令列工具通常都會連線到這個連接埠，因此發生衝突時，最直接的結果就是核心啟動失敗或代理無法連線。
| 設定欄位 | 常見連接埠 | 用途 | 能否與 mixed-port 重複 |
|---|---|---|---|
mixed-port |
7890 | 同時接受 HTTP 與 SOCKS5 代理 | 只能由一個程序監聽 |
port |
7890 | 僅提供 HTTP 代理 | 不能使用相同的監聽位址與連接埠 |
socks-port |
7891 | 僅提供 SOCKS5 代理 | 不能使用相同的監聽位址與連接埠 |
external-controller |
9090 | 提供控制介面，不承載一般代理流量 | 應使用獨立連接埠 |
從日誌擷取確切的連接埠
請先開啟客戶端的日誌頁面，搜尋 bind、listen、address already in use 或 連接埠。如果日誌出現 listen tcp 127.0.0.1:7890，需要排查的是 TCP 7890；如果出現 0.0.0.0:7890，表示程式準備在本機所有網路介面上監聽該連接埠，衝突範圍比只監聽 127.0.0.1 更大。
還要檢查同一份設定是否同時寫入 mixed-port: 7890 與 port: 7890。這種情況不需要尋找外部程式，因為設定本身就要求兩個監聽器爭用同一個位址。保留混合連接埠，刪除不需要的獨立 HTTP 或 SOCKS 連接埠即可。
Windows 使用 netstat 找出佔用 7890 的程序
Windows 10 與 Windows 11 都可以使用系統內建的 netstat。先完全退出目前的 Clash 客戶端，再以系統管理員身分開啟「終端機」或「命令提示字元」，執行以下命令：
netstat -ano | findstr :7890典型結果如下。最後一欄的 16420 是程序識別碼，也就是 PID：
TCP 127.0.0.1:7890 0.0.0.0:0 LISTENING 16420只有狀態為 LISTENING 的記錄，才表示某個程式正在監聽該 TCP 連接埠。如果結果只是在遠端位址中包含 :7890，不能直接判定本機連接埠被佔用。應重點核對「本機位址」欄是否為 127.0.0.1:7890、0.0.0.0:7890 或 [::]:7890。
依 PID 查詢程式名稱
取得 PID 後繼續執行：
tasklist /FI "PID eq 16420"也可以在 PowerShell 中查看程式路徑：
Get-Process -Id 16420
Get-CimInstance Win32_Process -Filter "ProcessId = 16420" |
Select-Object ProcessId, Name, ExecutablePath, CommandLine如果結果是另一個 Clash、Mihomo、sing-box 或代理客戶端，通常表示舊核心沒有隨介面一同退出。先從該客戶端的選單正常退出，再等待 3～5 秒重新查詢連接埠。在工作管理員中只關閉視窗，不一定會結束背景核心，系統匣仍可能保留執行圖示。
如果確認可以結束該程序，可在工作管理員的「詳細資料」頁面依 PID 定位，也可以執行：
taskkill /PID 16420 /Fnetstat 沒有結果，卻仍然報錯
- 確認日誌中的連接埠確實是
7890，不要把控制連接埠9090當成混合連接埠。 - 同時檢查 IPv4 與 IPv6。監聽
[::]:7890的程式可能會阻止另一個程序繫結 IPv4 位址。 - 退出客戶端後重新執行命令，避免將目前客戶端自己的正常監聽誤判為衝突。
- 檢查客戶端是否重複啟動了兩個核心實例，例如可攜版與安裝版同時設定為開機啟動。
- 查看日誌是否實際顯示權限不足。權限錯誤與連接埠佔用的處理方式不同。
macOS 使用 lsof 找出監聽程式
macOS 可以使用 lsof 查看哪個程序開啟了 TCP 7890。開啟「終端機」，執行：
sudo lsof -nP -iTCP:7890 -sTCP:LISTEN-nP 會直接顯示數字位址與連接埠，避免網域名稱解析影響速度。結果中的 COMMAND 是程序名稱，PID 是程序編號。例如：
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
mihomo 8421 user 10u IPv4 0t0 TCP 127.0.0.1:7890 (LISTEN)繼續使用以下命令檢查啟動參數，判斷它屬於哪個客戶端：
ps -p 8421 -o pid,ppid,user,command如果程序來自另一個仍在執行的代理客戶端，應優先從選單列圖示正常退出。確認程序已失去回應後，先傳送一般終止訊號：
kill 8421等待幾秒後再次執行 lsof。只有一般終止無效時，才考慮 kill -9 8421。強制結束可能讓客戶端來不及儲存目前設定，因此不應作為第一步。
同時排查獨立 SOCKS 連接埠
如果設定還啟用了 socks-port: 7891，應分別查詢 7890 與 7891。將混合連接埠改成 7892，並不能解決另一個獨立監聽器在 7891 上發生的衝突：
sudo lsof -nP -iTCP:7890 -sTCP:LISTEN
sudo lsof -nP -iTCP:7891 -sTCP:LISTEN
sudo lsof -nP -iTCP:9090 -sTCP:LISTENLinux 使用 ss 檢查連接埠監聽狀態
多數現代 Linux 發行版預設都提供 ss。它可以直接顯示監聽中的通訊端與對應程序。執行：
sudo ss -ltnp 'sport = :7890'參數中的 l 表示只查看監聽狀態，t 表示 TCP，n 表示直接顯示數字連接埠，p 表示顯示程序。也可以使用更直觀的相容篩選方式：
sudo ss -ltnp | grep ':7890'結果可能如下：
LISTEN 0 4096 127.0.0.1:7890 0.0.0.0:* users:(("mihomo",pid=2317,fd=8))如果 Mihomo 由 systemd 管理，不要只使用 kill 結束程序，因為服務管理器可能會立即將它重新啟動。先查詢服務狀態，再停止對應的單元：
systemctl --type=service --state=running | grep -Ei 'mihomo|clash'
sudo systemctl status mihomo
sudo systemctl stop mihomo在容器環境中還要檢查連接埠映射。主機上的 Docker 或 Podman 代理程序可能佔用 7890，即使容器內沒有名為 Mihomo 的主機程序：
docker ps --format 'table {{.ID}}\t{{.Names}}\t{{.Ports}}'
podman ps --format 'table {{.ID}}\t{{.Names}}\t{{.Ports}}'修改 mixed-port 與客戶端監聽連接埠
如果佔用 7890 的程式必須保留，最穩妥的處理方式是替 Clash 或 Mihomo 更換未使用的連接埠，例如 7892。先使用前面的系統命令確認 7892 沒有監聽記錄，再修改客戶端。
從圖形介面修改
具備圖形介面的客戶端通常可以從「設定」→「參數設定」→「混合連接埠」進入。將 7890 改為 7892，儲存後重新啟動核心。不同客戶端的選單名稱可能寫成「Mixed Port」、「混合代理連接埠」或「連接埠設定」，但要修改的目標都是目前核心的 mixed-port。
如果頁面同時列出 HTTP 連接埠、SOCKS 連接埠與混合連接埠，不要替多個項目填入相同數值。只需要單一入口時，可以啟用混合連接埠並關閉未使用的獨立監聽項目，以減少衝突來源。
直接編輯 YAML 設定
在設定檔中，將欄位改為：
mixed-port: 7892
allow-lan: false
mode: rule
log-level: infomixed-port 必須是整數，不能寫成帶冒號的位址，也不能與同一份設定中的 port、socks-port 或控制介面重複。儲存後需要讓核心重新載入設定；只修改磁碟上的檔案，不會自動變更已在執行中的監聽器。
同時存在多個 Profile 時，要確認編輯的是目前啟用的設定。有些客戶端會將訂閱內容複製到應用程式資料夾，訂閱原始檔與執行時設定並不是同一個檔案。可以先在介面查看目前的 Profile 名稱，再從該設定的編輯入口進入，避免修改到未啟用的副本。
確認新連接埠已開始監聽
重新啟動核心後，不要馬上只確認網頁能否開啟。先確認系統確實出現新的監聽器，且舊連接埠不再由目前客戶端使用：
# Windows
netstat -ano | findstr :7892
# macOS
sudo lsof -nP -iTCP:7892 -sTCP:LISTEN
# Linux
sudo ss -ltnp 'sport = :7892'預期結果是本機位址 127.0.0.1:7892 或客戶端明確設定的監聽位址處於 LISTEN 狀態。如果客戶端允許區域網路連線，可能會顯示 0.0.0.0:7892；此時還應檢查存取控制與防火牆規則，不要只為了解決本機衝突就擴大監聽範圍。
同步修改系統代理與應用程式代理
連接埠改好後網頁仍然無法開啟，最常見的原因是系統代理仍指向舊的 127.0.0.1:7890。核心已在 7892 正常執行，而瀏覽器仍繼續連線到 7890，結果看起來就像「修改沒有生效」。
優先讓客戶端重新設定系統代理
- 關閉客戶端中的「系統代理」開關。
- 確認混合連接埠已儲存為
7892，並重新啟動核心。 - 重新開啟「系統代理」。
- 進入作業系統的代理設定頁面，核對位址為
127.0.0.1、連接埠為7892。
Windows 11 可從「設定」→「網路和 Internet」→「代理」檢查手動代理伺服器。macOS 可從「系統設定」→「網路」→目前網路→「詳細資訊」→「代理」核對 Web 代理或安全 Web 代理。通常讓客戶端管理這些項目更穩妥，手動填寫時必須與實際監聽連接埠一致。
檢查瀏覽器擴充功能與命令列變數
代理切換擴充功能可能繞過系統設定，仍保留舊連接埠。需要在擴充功能的代理設定中，將 HTTP 或 SOCKS5 連接埠改為 7892。開發工具也可能透過環境變數指定代理，可分別檢查：
HTTP_PROXY=http://127.0.0.1:7892
HTTPS_PROXY=http://127.0.0.1:7892
ALL_PROXY=socks5://127.0.0.1:7892同一個 mixed-port 可以接收上述兩種協定，但應用程式填寫的協定前綴仍必須正確。如果設定的是獨立的 socks-port，則 ALL_PROXY 應指向該獨立連接埠，而不是直接照抄混合連接埠。
TUN 模式的差異
TUN 模式會透過虛擬網路介面接管流量，正常情況下不依賴系統 HTTP 代理開關。不過，只要設定仍要求 Mihomo 建立 mixed-port: 7890，7890 被佔用仍可能導致核心啟動失敗。解決方式仍是關閉衝突程序或修改監聽連接埠。
排查時建議暫時只保留一種流量接管方式：要麼關閉 TUN，使用系統代理驗證 7892；要麼關閉系統代理，只驗證 TUN。同時啟用兩種方式會增加變數，容易將 DNS、路由或瀏覽器擴充功能問題誤判為連接埠衝突。
修改後仍顯示佔用的檢查順序
如果連接埠已換成 7892，但日誌仍顯示 7890 被佔用，表示執行時設定沒有套用剛才的修改。依照以下順序檢查，可以快速判斷問題出在設定、程序還是系統代理未同步。
- 重新讀取最新日誌。確認錯誤時間是在這次重新啟動之後，並記下日誌中的完整位址與連接埠。
- 確認目前的 Profile。檢查客戶端目前選取的設定名稱，避免編輯測試設定後，實際執行的仍是訂閱設定。
- 執行設定重新載入。儲存 YAML 後使用客戶端的「重新載入設定」或「重新啟動核心」，不要只關閉設定視窗。
- 排查重複的客戶端。檢查系統匣、選單列、開機啟動項目、systemd 服務與容器，確認沒有第二個核心實例。
- 檢查欄位重複。確認
mixed-port、port、socks-port與external-controller沒有使用相同的位址與連接埠。 - 確認新連接埠正在監聽。使用 netstat、lsof 或 ss 驗證 7892，不要只看客戶端介面顯示「執行中」。
- 同步所有代理入口。更新系統代理、瀏覽器擴充功能、終端機環境變數、開發工具與區域網路裝置中的舊連接埠。
使用 curl 進行最後驗證
確認 7892 正常監聽後，可以讓 curl 明確透過混合連接埠發出請求。以下命令會顯示連線過程與 HTTP 回應標頭：
curl -I -v -x http://127.0.0.1:7892 https://example.com輸出中應先出現連線 127.0.0.1:7892，接著建立到目標網站的 CONNECT 通道。如果顯示 Connection refused，表示該位址上沒有可用的監聽器；如果連線成功但目標請求逾時，表示連接埠衝突已解決，下一步應檢查節點、規則、DNS 或網路連通性。
可重複套用的處理結論
- 日誌顯示
address already in use：先查詢監聽程序，不要先更換節點。 - 舊代理程式佔用 7890：退出舊程式並清理重複的自動啟動設定。
- 佔用程式必須保留：將
mixed-port改為已確認閒置的連接埠，例如 7892。 - 核心已監聽新連接埠，但應用程式無法上網：同步修改系統代理與應用程式內的代理設定。
- 訂閱更新後問題再次出現：將連接埠調整放入客戶端的持久化覆寫設定。
- TUN 已啟用但仍然啟動失敗：繼續檢查設定中的混合連接埠與控制連接埠是否衝突。