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

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

Clash Verge Rev 報 address already in use？檢查 mixed-port 佔用處理程式與保留連接埠，按殘留核心或其他程式處理；驗證系統代理和退出後的直連。

閱讀正文回到部落格
  • Clash Verge Rev
  • address already in use
  • mixed-port
  • 連接埠佔用
  • 服務模式
本文目錄
文章作者
Clash 官方
發布日期
更新時間
預計閱讀
約 10 分鐘

關閉視窗後，代理核心或其他本機程式可能仍占用同一個連接埠。新程式無法啟動，不代表訂閱已損壞；先把實際連接埠和占用程序對應起來，再只處理已確認衝突的程式，保留仍在運作的連線。

address already in use：哪個實際連接埠無法綁定？

先保留日誌中的 address already in use、Bind failed 或 Start Mixed(http+socks) server error，並記下它們指向的本機連接埠。出現這些錯誤時，新程式尚未完成連接埠綁定。

連接埠是程式接收請求的入口編號；使用自己日誌中的 mixed-port、DNS 或 external-controller 數值，報告中的 7890 和 1053 只是示例。

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、連接埠設定和首條故障日誌，期間不更新訂閱或改規則；公開意見回饋前隱藏訂閱 URL、密碼與 secret。

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

根據 PID、執行帳戶和路徑確認佔用連接埠的程式

不能只憑處理程序名稱判斷誰佔用了連接埠。先找到 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，才終止該程序並重新檢查連接埠。macOS/Linux 先傳送 TERM；Windows 的 Stop-Process 會直接終止程序，-Confirm 只增加確認提示。不要使用範圍過廣的 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. 使用用戶端入口

    可從目前用戶端的服務模式設定中停用或解除安裝舊服務。Windows 上只有確認所用服務元件符合官方安全公告的修復要求，才可修復、重新安裝或啟用；未確認時保持停用。其他系統沿用用戶端的解除安裝、修復或重新安裝入口，等待權限提示與操作完成。

  4. 必要時重啟系統

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

  5. 只恢復一項功能

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

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

透過目前 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 能看到測試請求
  • 正常退出用戶端後連接埠釋放，系統代理也能恢復
  • 再次啟動或重新登入後沒有出現第二份殘留核心

系統代理的實際 HTTPS 請求透過後才按需啟用 TUN。若只在 TUN 開啟後斷網、日誌又沒有綁定錯誤，轉查 DNS 與路由，不繼續換 mixed-port。

改連接埠或重裝服務無效時，恢復直連並保留證據

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

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

提交官方 issue 前保留

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

參考資料