連線疑難排解 · Clash 技術部落格

Clash Verge Rev 連接埠被佔用怎麼修？

Clash Verge Rev 報 address already in use 或 mixed-port 啟動失敗時，先查監聽者，再區分殘留核心、其他程式或保留連接埠；給出檢查、修復、還原與驗證步驟。

閱讀正文返回部落格
  • Clash Verge Rev
  • address already in use
  • mixed-port
  • 連接埠佔用
  • 服務模式
本文目錄
發布日期
預計閱讀
約 10 分鐘

先確認日誌是不是連接埠綁定衝突

本文只處理日誌明確出現 address already in use、Bind failed 或 Start Mixed(http+socks) server error 的情況。問題報告中的 7890 和 1053 只是實例，檢查時必須使用自己日誌中的 mixed-port、DNS 或 external-controller 連接埠。

Mihomo 文件說明，mixed-port 是同時接受 HTTP(S) 與 SOCKS 請求的本機入口。新核心無法綁定它時，系統代理即使仍指向這個連接埠，也不會得到可用的新連線。

Clash Verge Rev issue #7861 記錄了 macOS 服務模式下 GUI 異常結束後，root 使用者執行的 verge-mihomo 繼續佔用 mixed-port 與 DNS 連接埠。Issue #6741 則記錄了 Linux 重新登入時新舊核心爭用 mixed-port。

兩專案前仍是 open issue，根因分析來自報告者，不能寫成維護者已經確認的普遍結論。

先從第一條 bind 錯誤記下實際連接埠
Start Mixed(http+socks) server error: listen tcp :7890: bind: address already in use
Start DNS server(TCP) error: listen tcp 0.0.0.0:1053: bind: address already in use
Start DNS server(UDP) error: listen udp 0.0.0.0:1053: bind: address already in use

按第一條錯誤分流

日誌或現象更可能的方向下一步
只有 mixed-port 報 address already in use舊用戶端、其他程式、殘留核心或 Windows 保留連接埠查實際監聽者
mixed-port 與 DNS 連接埠同時失敗另一份核心同時持有整組連接埠的可能性較高查處理程式屬主與啟動時間
只有 external-controller 連接埠衝突控制介面或 Dashboard 使用相同連接埠單獨檢查控制連接埠
日誌只有 connection refused，沒有 bind 錯誤目標連接埠未監聽，不是連接埠已被佔用檢查核心啟動與設定
只有一個網站打不開規則、DNS 或節點問題不要按本文結束處理程式

檢查前先讓系統能夠直連

先關閉 TUN 和系統代理，確認裝置不依賴 Clash Verge Rev 也能聯網，再從系統匣完整退出用戶端。儲存目前 Profile、連接埠設定和故障日誌，不要在定位過程中同步訂閱或改規則。

退出後等待幾秒並重新檢查連接埠。若監聽已經消失，先只啟動一次用戶端觀察；只有連接埠仍被佔用，才繼續查佔用者。

開始檢查前

  1. 記錄實際連接埠

    從第一條 bind 錯誤記下 mixed-port、DNS 或 external-controller 的具體連接埠。

  2. 恢復基礎網路

    關閉 TUN 與系統代理，確認用戶端停止時裝置仍能直連。

  3. 正常退出用戶端

    先從系統匣完整退出，等待幾秒，不要直接強制結束處理程式。

  4. 儲存設定與日誌

    保留目前 Profile、連接埠值和第一條錯誤，公開意見回饋前隱藏訂閱 URL、密碼與 secret。

按系統查清是誰在監聽

連接埠佔用不是處理程式名稱猜謎。先找到 PID，再核對處理程式名、屬主、啟動時間和程式路徑，才能區分正在工作的目前核心、退出後殘留的舊核心與無關程式。

下面的 7890、1053 和 12345 都是示例。執行前替換為日誌中的連接埠和剛查到的 PID；只讀查詢沒有結果時，不要為了得到結果而隨意結束處理程式。

Windows PowerShell：查詢 TCP 與 UDP 監聽者
$Port = 7890
$Tcp = Get-NetTCPConnection -LocalPort $Port -State Listen -ErrorAction SilentlyContinue
$Tcp | Select-Object LocalAddress, LocalPort, OwningProcess
$Tcp | ForEach-Object {
  Get-Process -Id $_.OwningProcess | Select-Object Id, ProcessName, Path
}
Get-NetUDPEndpoint -LocalPort 1053 -ErrorAction SilentlyContinue |
  Select-Object LocalAddress, LocalPort, OwningProcess
macOS：查詢監聽者並核對處理程式
PORT=7890
sudo lsof -nP -iTCP:${PORT} -sTCP:LISTEN
sudo lsof -nP -iUDP:1053
ps -o user,pid,ppid,lstart,command -p 12345
Linux：查詢監聽者並核對處理程式
sudo ss -ltnp 'sport = :7890'
sudo ss -lunp 'sport = :1053'
ps -o user,pid,ppid,lstart,cmd -p 12345

根據監聽者選擇最小修復

連接埠屬於另一款 Clash、VPN、開發伺服器或本機代理

從該程式自己的介面正常退出，或讓兩款程式使用不同連接埠；不要結束未知系統處理程式。

Clash Verge Rev 已退出，連接埠仍屬於 verge-mihomo

這才符合殘留核心特徵。儲存 PID 與屬主後，只向這一 PID 傳送正常終止請求。

處理程式屬於 root 或管理員，結束後馬上再次出現

不要反覆強殺，轉到用戶端的服務模式修復或重裝流程。

重新登入或快速重啟用戶端後偶發衝突

可能是新舊核心交接競態；先關閉重複自啟動入口，並只啟動一次用戶端驗證。

Windows 查不到監聽者但仍無法綁定

檢查連接埠是否落入 Windows excluded port range。

只有確認 PID 是用戶端退出後殘留的 verge-mihomo，才執行單處理程式終止。先使用正常終止並再次查詢連接埠；不要從寬泛的 pkill 或強制信號開始。

macOS / Linux：僅終止剛確認的單一 PID
# 把 12345 换成刚才确认的 PID
sudo kill -TERM 12345
Windows PowerShell：確認後終止單一 PID
# 把 12345 换成刚才确认的 PID
Stop-Process -Id 12345 -Confirm

Windows 沒有監聽者時檢查保留連接埠

Issue #6947 的 Windows 記錄中，更換連接埠並重啟系統代理後恢復使用；專案協作者同時建議先看 Mihomo 日誌中的 Bind failed，並檢查 Windows 或 Hyper-V 的保留連接埠。這個分支只適用於沒有查到監聽處理程式、但日誌仍明確綁定失敗的情況。

如果目前 mixed-port 落在保留範圍內，在 Clash Verge Rev 的連接埠設定中選擇一個沒有監聽、也不在保留範圍內的新連接埠，再返回首頁重新啟用系統代理。只改連接埠而不核對佔用者，不能處理仍在執行的殘留核心。

只讀查看 Windows TCP 與 UDP 保留連接埠
netsh interface ipv4 show excludedportrange protocol=tcp
netsh interface ipv4 show excludedportrange protocol=udp
netsh interface ipv6 show excludedportrange protocol=tcp
netsh interface ipv6 show excludedportrange protocol=udp
用候選連接埠前先確認沒有監聽者
# 17890 只是示例，不能保证每台电脑都可用
Get-NetTCPConnection -LocalPort 17890 -ErrorAction SilentlyContinue
Get-NetUDPEndpoint -LocalPort 17890 -ErrorAction SilentlyContinue

殘留核心反覆出現時修復服務模式

Clash Verge Rev v2.5.2 原始碼提供服務安裝、卸載、重裝和 repair 命令；repair 路徑會執行強制重裝並等待服務 IPC 恢復。不同系統和建置的按鈕名稱可能不同，應使用目前用戶端設定中的服務模式入口，不要手動刪除服務檔案。

v2.5.2 發布說明提到更健壯的服務生命週期管理，但這不能證明後續報告的殘留核心和連接埠競態已被穩定版徹底修復。本文提供的是故障恢復路徑，不是版本修復公告。

服務模式恢復順序

  1. 保持直連

    關閉系統代理與 TUN，確認用戶端停止時系統仍可聯網。

  2. 儲存診斷結果

    記錄連接埠、PID、處理程式屬主、用戶端版本和第一條 bind 錯誤。

  3. 使用用戶端入口

    從服務模式設定中卸載、修復或重新安裝服務，並等待權限提示與操作完成。

  4. 必要時重啟系統

    若管理員核心仍持有連接埠，重啟後先確認連接埠已釋放，再啟動用戶端。

  5. 只恢復一項功能

    先啟動原 Profile 和系統代理；確認正常後，再按需要恢復 TUN。

修復後驗證連接埠、代理與退出釋放

先確認啟動前目標連接埠為空，再啟動 Clash Verge Rev，檢查只有一份預期核心監聽。隨後把示例連接埠替換為目前 mixed-port，透過本機代理髮起一次實際 HTTPS 請求，並在 Connections 中核對記錄。

只有系統代理路徑驗證透過後再開啟 TUN。若一開 TUN 才斷網且日誌沒有綁定錯誤，應轉到 TUN、DNS 和路由檢查，不要繼續更換 mixed-port。

透過目前 mixed-port 驗證實際請求
# 把 7890 换成当前 mixed-port
curl -I -x http://127.0.0.1:7890 https://example.com

完成標準

  • 啟動前目標連接埠沒有未知監聽者
  • 啟動後 mixed-port 只由一份預期的 verge-mihomo 監聽
  • 新日誌不再出現 address already in use 或 Bind failed
  • 透過 mixed-port 的 curl 請求能收到 HTTP 回應
  • 系統代理指向目前實際連接埠，Connections 能看到測試請求
  • 正常退出用戶端後連接埠釋放，系統代理也能恢復
  • 再次啟動或重新登入後沒有出現第二份殘留核心

失敗時還原並提交有效證據

更換連接埠或重裝服務後若問題更嚴重，先關閉系統代理和 TUN，讓裝置保持直連。只有舊連接埠已經釋放時才恢復原連接埠；服務重裝失敗時先保持服務模式關閉，不要繼續手動刪除系統檔案。

向官方意見回饋時，把本機結論寫成觀察結果，而不是替維護者宣佈根因。不要上傳完整設定、訂閱 URL、節點密碼、控制器 secret 或未脫敏日誌。

提交官方 issue 前保留

  • Clash Verge Rev 完整版本與安裝來源
  • 作業系統版本和 CPU 架構
  • 是否啟用服務模式、TUN 和開機自啟
  • GUI 是正常退出、崩潰還是被強制結束
  • 第一條 address already in use 日誌及實際連接埠
  • 監聽者的 PID、屬主、啟動時間和程式路徑
  • 退出用戶端後連接埠是否釋放，修復服務後是否復現

參考資料