為什麼老是看到 7890 與 mixed-port？

在許多圖形化 Clash／Clash Meta（Mihomo 核心）用戶端的預設範本裡，mixed-port 常落在 7890 附近：同一個埠同時承載類 HTTP 與 SOCKS 的「混合」監聽，讓瀏覽器或系統只要把 Proxy 指到 127.0.0.1:7890，就能沿用大部分教學文與截圖。好處是心智負擔低；壞處是只要任何程式先佔了 7890，核心在綁定（bind）時就會失敗，介面上便出現「連接埠已被佔用」「address already in use」或僅有英文 bind: Only one usage... 之類訊息。

因此，Clash 連接埠佔用本質上是作業系統層的資源競爭：同一台機器、同一個 TCP 埠號，同一時間只能有一個監聽者。常見「加害者」包含：先前未關乾淨的 Clash 實例、另一套仍開著系統代理的代理軟體、開發工具內建的區域 Proxy、甚至是某次測試留下的本機服務。接下來我們用 Windows 內建工具把「誰佔了 7890」講清楚，再談要關掉對方還是改 mixed-port 並同步系統設定。

第一步：用 netstat 找出佔用連接埠的 PID

以系統管理員身分開啟「命令提示字元」或 PowerShell（是否管理員視你的環境而定；若下列指令看不到 PID，可改以系統管理員重試）。先查 7890（若錯誤訊息寫的是別的數字，把指令中的埠號一併替換即可）：

netstat -ano | findstr :7890

輸出列中請留意 LISTENING 狀態那一行，最後一欄即為 PID（處理序識別碼）。若同時看到多行，可能包含已建立的連線與監聽，請以監聽在 0.0.0.0:7890 或 127.0.0.1:7890 的行為準。記下 PID 後，開啟「工作管理員」→「詳細資料」分頁→依「PID」排序，即可對應到實際處理序名稱與路徑。

若你更習慣 PowerShell，也可使用內建的連接埠查詢語法（同樣以 7890 為例，環境不同時指令可能需微調）：

Get-NetTCPConnection -LocalPort 7890 -State Listen -ErrorAction SilentlyContinue

重點不在背指令，而是建立固定儀式：埠號 → PID → 程式身份 → 決策。當你能指名道姓說出「7890 是誰在聽」，後面要改設定或結束程式就不會淪為亂試。

第二步：要結束程式，還是改 mixed-port？

對應到工作管理員之後，通常有兩條路。若 PID 屬於你自己剛剛以為已關閉的 Clash／內核服務，或舊版匣道程式仍在背景，最乾淨的做法是從匣圖示「完全結束」、必要時在詳細資料中結束工作樹，再重新啟動單一用戶端。若 PID 屬於你仍需要使用的其他軟體（例如另一套本機開發用的 Proxy），則不應強殺，而應讓 Clash 改聽別的埠。

實務上很多人會同時安裝兩代產品或測試多個分支，導致雙實例互搶 mixed-port。此時請先確認開機啟動項目與匣道圖示：只保留一套會寫入系統 Proxy 的程式為「權威來源」，其餘改為手動啟動或關閉其「開機自啟」「接管系統代理」選項。若你正在撰寫腳本或說明給同事用，也建議在文件裡寫死「本機 mixed-port 與系統 Proxy 必須同一組數字」，減少口耳相傳造成的漂移。

第三步：修改 mixed-port 並重載設定

在設定檔中，mixed-port 是核心真正監聽的埠號（若你的檔案仍使用舊式分欄 port／socks-port 而沒有 mixed，可對照所使用核心版本說明，逐步收斂到官方推薦寫法）。將 mixed-port 改為一個目前 netstat 確認無人監聽的埠，例如 7891、7892 或你偏好的高位埠，存檔後在圖形介面執行「重載設定」或重啟核心。若用戶端有「覆寫（override）」功能，請確認覆寫層沒有把埠號改回 7890，否則你會陷入「改了檔、載入卻仍是舊埠」的錯覺。

少數情境下，訂閱或遠端範本會自帶埠號相關欄位，與本機手動編輯互相覆蓋；排錯時可暫時關閉遠端覆寫、只保留最小可啟動設定，確認核心能順利 bind 後再逐段加回。這與「訂閱與快取」裡談的多層合併是同一套心智模型：看得見的 YAML 未必是唯一真相，合併順序才決定最後監聽哪個埠。

第四步：同步 Windows 系統 Proxy

只改 mixed-port 而沒改「設定 → 網路和網際網路 → Proxy」裡的位址，瀏覽器與支援系統 Proxy 的程式仍會連到舊的 7890：要嘛連到錯誤的程式，要嘛直接失敗。圖形用戶端若提供「一鍵設定系統 Proxy」，請在改埠後重新開關一次，讓它寫入新的 127.0.0.1:新埠。若你手動在系統裡設定，請確認 HTTP 與 HTTPS（若分欄）都指向同一個本機位址與埠號，與 Clash 實際監聽一致。

使用 TUN 或僅依應用程式內建 Proxy 的讀者，仍建議在排錯階段確認系統層沒有指向殘留埠號，避免「以為走 TUN，實際某支程式仍從系統 Proxy 突圍」的雙路徑混亂。更完整的堆疊與權限說明可併讀 Clash Verge Rev 的 Windows 教學；若你讓 WSL2 透過宿主機連線，請一併把 Linux 側環境變數改到新的 mixed-port，細節見 WSL2 與 Clash 連接埠設定。

常見陷阱與進階線索

第一，防火牆與允許清單：變更埠號後，若首次出現連線詢問視窗，請確認允許的是「正確的那支執行檔」，避免規則仍綁在舊路徑。第二，服務型安裝：有些發行版會註冊 Windows 服務，匣道圖示關閉後服務仍在聽埠；需在「服務」主控台確認狀態。第三，快速重開機：若懷疑 TCP TIME_WAIT 或殘留控制代碼，完整重開機往往比連續手動殺程序更省時間──前提是開機啟動項不要自動拉起兩套 Clash。

若改埠後仍無法連線，請改從規則與 DNS排查，而非一直換埠號；可搭配 連線日誌 觀察實際命中節點與錯誤類型。開源授權、上游議題與原始碼仍可在獨立分頁查閱 GitHub；日常安裝與取得 Windows 用戶端則建議以 說明文件 與本站下載頁為主，與原始碼連結分開管理，緊急排障時較不易誤點非預期建置產物。

小結

Clash 連接埠佔用在 Windows 上幾乎永遠可以先還原成一道算術題：誰在 LISTENING、PID 是誰、與你預期的 mixed-port 是否一致。用 netstat 或 PowerShell 把 PID 查出來，其餘只是產品決策：釋放 7890 給 Clash，或把 Clash 改到閒置埠並讓系統 Proxy、腳本與子系統（如 WSL）全部跟著改。把這套順序寫進個人備忘，下次更新用戶端或換機時，就不會再被同一則錯誤訊息絆第二次。

相較於散落論壇的過期截圖，使用持續維護、與 Meta 核心對齊的用戶端，並為本機埠號與系統代理保留「單一真相來源」，長期維運會穩定得多。當監聽、系統 Proxy 與你預期的策略組終於對齊，日常分流與開發流量也會回到可控節奏。→ 立即免費下載 Clash，開啟流暢上網新體驗