Clash 連接埠被佔用怎麼辦：找出程序並修改監聽連接埠

Clash 啟動時需要在本機建立一個或多個監聽連接埠。瀏覽器、作業系統和其他應用程式會將代理請求傳送到這些連接埠，再由 Clash 依照設定檔中的規則與策略組處理流量。如果目標連接埠已由另一個程序監聽，系統會拒絕再次繫結，核心通常會回報位址已在使用中、監聽失敗或連接埠被佔用。

常見情況包括：舊的 Clash 程序未完整退出、同時啟動兩個用戶端、其他代理工具使用相同連接埠、設定中將多個監聽器指定為同一個連接埠，以及控制介面或 DNS 服務與本機開發服務發生衝突。正確的處理方式不是反覆點擊啟動，而是先確認衝突發生在哪個位址與連接埠，再找出對應程序，最後決定關閉佔用者或修改 Clash 設定。

一、從錯誤訊息辨識連接埠衝突

不同用戶端會以不同程度整理核心日誌，但底層錯誤通常包含 bind、listen、address already in use 或「連接埠被佔用」等關鍵字。日誌中最有價值的是通訊協定、監聽位址和連接埠號碼。例如 127.0.0.1:7890 表示只在本機迴路位址監聽 7890；0.0.0.0:7890 表示嘗試在所有 IPv4 網路介面上監聽該連接埠。

listen tcp 127.0.0.1:7890: bind: address already in use
listen tcp 0.0.0.0:9090: bind: address already in use

第一行通常對應 HTTP、SOCKS 或 mixed 代理入口，第二行則較可能對應外部控制介面。單憑連接埠號碼無法判斷是哪項設定，因為使用者可以修改預設值。應同時檢查日誌上下文與目前生效的設定。

如果日誌沒有出現繫結失敗，而是提示 TUN 裝置建立失敗、權限不足、路由設定失敗或網路介面不存在，那麼問題不一定與代理連接埠有關。此時更換 7890 之類的連接埠通常無法解決故障，應改為檢查系統管理員權限、虛擬網路卡、TUN 驅動程式和系統路由。

二、確認 Clash 正在使用哪些監聽連接埠

Clash 與 mihomo 設定中可以存在多個本機監聽器。實際欄位取決於用戶端功能與目前設定，最常見的項目如下。

設定項目	用途	發生衝突時的影響
`mixed-port`	在同一個連接埠接收 HTTP 與 SOCKS5 代理連線	系統代理與手動代理可能同時失效
`port`	HTTP 代理監聽連接埠	使用 HTTP 代理的應用程式無法連線
`socks-port`	SOCKS5 代理監聽連接埠	使用 SOCKS5 的應用程式無法連線
`redir-port`	接收重新導向流量，主要用於特定系統網路方案	透明代理鏈路無法建立
`tproxy-port`	接收 TPROXY 流量，常見於 Linux 路由環境	透明代理規則無法將流量交給核心
`external-controller`	為用戶端介面或外部面板提供控制 API	介面可能無法讀取核心狀態或修改策略
`dns.listen`	提供本機 DNS 服務	網域名稱解析請求無法進入 Clash DNS 模組

mixed-port 已可同時處理 HTTP 與 SOCKS5 請求。若設定採用 mixed 模式，通常不需要再將 port 或 socks-port 設為相同數值。兩個監聽器不能在同一個位址上佔用完全相同的傳輸協定與連接埠組合。

還要區分「訂閱設定」與「用戶端執行設定」。部分桌面用戶端會在執行時產生最終設定，將介面中的連接埠、控制介面和 TUN 選項合併到訂閱內容中。此時直接編輯訂閱檔案，可能在更新訂閱或重新啟動用戶端後被覆寫。優先在用戶端的基本設定、連接埠設定或覆寫設定中修改；只有確認用戶端直接讀取 YAML 時，才編輯對應欄位。

三、在 Windows、macOS 與 Linux 找出佔用程序

Windows：查詢 PID 與程序名稱

以 7890 連接埠為例，在命令提示字元中執行：

netstat -ano | findstr :7890

結果中的 LISTENING 表示程序正在監聽連接埠，最後一欄是 PID。接著查詢該 PID 對應的程式：

tasklist /FI "PID eq 1234"

也可以在 PowerShell 中使用結構化命令：

Get-NetTCPConnection -LocalPort 7890 -State Listen
Get-Process -Id 1234

如果命令提示權限不足，可以使用系統管理員終端機重新查詢。工作管理員的「詳細資料」頁面也能依 PID 找到程序。發現另一個 Clash 用戶端或舊核心時，應先從對應介面正常退出，確認系統匣中的程序已結束，再考慮終止程序。

macOS：使用 lsof 查看監聽程式

sudo lsof -nP -iTCP:7890 -sTCP:LISTEN

輸出會列出程序名稱、PID、使用者和監聽位址。若檢查的是 DNS 服務，還需要查詢 UDP，因為本機 DNS 監聽可能同時涉及 UDP 與 TCP：

sudo lsof -nP -iUDP:1053
sudo lsof -nP -iTCP:1053 -sTCP:LISTEN

Linux：使用 ss 或 lsof

sudo ss -lntp 'sport = :7890'
sudo lsof -nP -iTCP:7890 -sTCP:LISTEN

ss 的 -l 表示只查看監聽中的通訊端，-n 可避免將連接埠轉換為服務名稱，-t 用於查詢 TCP，-p 則顯示程序。檢查 UDP 監聽時可以使用：

sudo ss -lnup 'sport = :1053'

四、關閉佔用程序，還是修改 Clash 連接埠

找出佔用者後，處理方式取決於程序用途。若佔用者是先前遺留的 Clash 核心，正常退出舊用戶端通常最合適。若兩個用戶端都需要保留，就必須為它們分配不同的代理連接埠、控制連接埠和 DNS 監聽連接埠。只修改 mixed-port，卻保留相同的 external-controller，第二個核心仍可能啟動失敗。

如果連接埠屬於長時間執行的開發服務、容器映射或區域網路服務，修改 Clash 連接埠通常更穩定。選擇新連接埠時，應先用系統命令確認沒有程序正在監聽。連接埠範圍必須介於 1 至 65535 之間，並避免將 HTTP、SOCKS、控制介面和 DNS 服務重複設定在同一個位址與連接埠。

若佔用程序已退出，但連接埠查詢仍顯示監聽狀態，可能有以下情況：

關閉用戶端介面後，程序仍駐留在系統匣，核心程序尚未結束。
服務管理器自動重新啟動了該程序，例如系統服務或容器的重新啟動策略。
同時安裝了多個用戶端，其中一個設定為開機啟動。
查詢的是另一種網路協定，例如只檢查 TCP，而衝突來自 UDP DNS 監聽。
設定同時在 IPv4 與 IPv6 位址上監聽，需要結合日誌中的具體位址進行檢查。

強制結束程序應作為確認身分後的處理手段。Windows 可使用工作管理員結束工作，macOS 與 Linux 則可先傳送一般終止訊號，讓程式有機會儲存狀態。若程序持續自動出現，應關閉其開機啟動、背景服務或容器重新啟動設定，而不是反覆結束 PID。

五、修改 mixed-port、HTTP 與 SOCKS 監聽設定

只需要一個統一代理入口時，可以保留 mixed-port，並移除重複的 HTTP 與 SOCKS 獨立監聽項目。以下範例將統一入口改為 7893，並將控制介面設為 9091：

mixed-port: 7893
external-controller: 127.0.0.1:9091
allow-lan: false
mode: rule

需要讓不同應用程式分別使用 HTTP 與 SOCKS5 時，可以設定兩個不同的連接埠：

port: 7893
socks-port: 7894
external-controller: 127.0.0.1:9091
allow-lan: false
mode: rule

不要將設定寫成 mixed-port: 7893、port: 7893 和 socks-port: 7893 的組合。即使某些用戶端在產生設定時會忽略部分欄位，也不應依賴這種不明確的行為。每個實際啟用的獨立監聽器都應使用清楚且不重複的連接埠。

修改 YAML 時也要維持正確的縮排與資料類型。連接埠通常應寫成整數。儲存後，應在用戶端重新載入設定或重新啟動核心，並查看日誌確認新連接埠已開始監聽。如果用戶端提供「混合連接埠」、「HTTP 連接埠」、「SOCKS 連接埠」等介面選項，應優先透過介面修改，避免執行設定與介面顯示不一致。

修改連接埠後同步更新系統代理

核心成功監聽新連接埠，不代表應用程式已自動改用該連接埠。系統代理仍可能指向舊的 127.0.0.1:7890。在用戶端中關閉並重新啟用系統代理，通常可以重新寫入目前的連接埠。若瀏覽器、命令列工具、下載工具或開發環境使用手動代理，也要逐項更新。

例如，應用程式原本使用 HTTP 代理 127.0.0.1:7890，而新的 mixed-port 是 7893，則應改為 127.0.0.1:7893。使用 SOCKS5 的應用程式也可以連線至 mixed-port，但代理類型仍要在應用程式中選擇 SOCKS5。只修改連接埠卻選錯代理協定，可能導致連線失敗或驗證格式錯誤。

六、TUN 模式、DNS 監聽與區域網路位址的特殊情況

TUN 模式透過虛擬網路介面接管流量，應用程式不一定會直接連線至 mixed-port。不過，只要設定中啟用了 mixed、HTTP、SOCKS 或控制介面，核心啟動時仍會嘗試建立對應的監聽。因此，TUN 已啟用並不代表可以忽略一般代理連接埠衝突。

排查 TUN 時，首先要看錯誤發生在哪個步驟。如果日誌明確指向 127.0.0.1:7890 或 0.0.0.0:9090 的繫結失敗，請按連接埠衝突處理。如果日誌指向虛擬網路卡、路由表、權限或防火牆，則應檢查 TUN 環境。兩類問題可能同時存在，需要依照日誌逐項解決。

DNS 模組是另一個容易被忽略的衝突來源。範例設定可能包含：

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip

如果 1053 已被本機 DNS 轉送器佔用，Clash DNS 服務會啟動失敗。應同時查詢 TCP 與 UDP 的佔用情況，再決定調整 Clash 的 dns.listen，還是修改另一項服務。更換 DNS 監聽連接埠後，還要檢查系統、路由腳本或其他轉送程式是否仍將請求傳送到舊連接埠。

啟用區域網路存取時，監聽範圍可能從迴路位址擴展到網路介面。某個程式只監聽 127.0.0.1:7890，另一個程式嘗試監聽 0.0.0.0:7890，也可能產生衝突，因為後者希望涵蓋所有 IPv4 介面。判斷時必須連同位址一起查看，不能只比較連接埠號碼。

七、驗證連接埠修復是否完整

修復完成後，建議依照固定順序驗證，避免將系統代理殘留、設定尚未切換或節點故障誤判為連接埠問題。

重新啟動核心，確認日誌中不再出現 bind 或 address already in use。
使用 netstat、Get-NetTCPConnection、lsof 或 ss 檢查新連接埠，確認監聽程序確實是目前的 Clash 核心。
在用戶端確認目前的 Profile 已選取，規則模式、全域模式或直連模式符合測試目標。
重新啟用系統代理，確認代理位址與修改後的連接埠一致。
檢查控制介面能否讀取節點、策略組和連線資訊，排除控制連接埠仍發生衝突的情況。
使用瀏覽器或指定代理的命令列請求進行測試，再查看連線日誌中是否出現對應請求。
若使用 TUN，還要檢查虛擬網路卡、DNS 解析和路由是否正常。

連接埠已在監聽但網頁仍無法存取時，問題通常已從「監聽衝突」轉移到其他層面。此時應檢查設定是否成功載入、節點是否可用、規則是否將目標交給正確的策略組、DNS 是否回傳有效結果，以及應用程式是否確實使用了新的代理位址。連接埠監聽成功只表示本機入口已建立，不代表上游代理鏈路一定可用。

也可以先將模式暫時切換到便於判斷的測試狀態，觀察連線日誌中是否出現請求，但測試後應恢復日常規則模式。若日誌完全沒有新連線，重點檢查系統代理與應用程式代理；若出現連線但失敗，則重點檢查節點、DNS、規則與網路連線能力。

八、連接埠被佔用的常見問題

7890 被佔用後，可以直接改成任意數字嗎？

可以選擇 1 至 65535 範圍內尚未被佔用的連接埠，但應避開系統服務和現有應用程式。修改前先查詢監聽狀態，修改後同步更新系統代理、瀏覽器和其他手動代理設定。

為什麼關閉 Clash 視窗後連接埠仍被佔用？

部分桌面用戶端關閉視窗後仍會在系統匣中執行，核心程序也會繼續保留。應從系統匣選單完整退出，再透過 PID 查詢確認程序已結束。若程序自動恢復，還要檢查開機啟動或背景服務。

mixed-port 和 socks-port 可以使用同一個連接埠嗎？

不應這樣設定。mixed-port 本身已接收 HTTP 與 SOCKS5 請求。若還需要獨立的 socks-port，應分配另一個連接埠；否則兩個監聽器會爭用同一個位址與連接埠。

修改連接埠後，Clash 顯示正在執行但系統無法上網，該怎麼辦？

先檢查系統代理是否仍指向舊連接埠。關閉並重新啟用用戶端中的系統代理，再核對目前的 Profile、執行模式和連線日誌。使用固定代理位址的應用程式也需要單獨修改。

9090 衝突會影響代理流量嗎？

9090 常用作外部控制介面。發生衝突後，核心可能無法啟動，或用戶端介面無法連線至核心、讀取策略組和連線記錄。即使 mixed-port 沒有衝突，也應為控制介面分配獨立且可用的連接埠。

使用 TUN 模式後還需要保留 mixed-port 嗎？

取決於使用情境。TUN 可以接管系統流量，但瀏覽器除錯、命令列工具或其他裝置仍可能需要明確的代理入口。如果保留 mixed-port，就必須確保它能正常監聽；不需要時，則透過用戶端支援的設定停用。

連接埠衝突的核心判斷標準很明確：某個監聽位址與連接埠已被程序佔用，而 Clash 又嘗試繫結相同組合。記錄日誌、查詢 PID、確認程序用途、調整設定並同步系統代理，可以將問題限制在具體環節。處理完成後再驗證 Profile、規則、DNS 與 TUN，就能避免將後續網路故障繼續歸咎於連接埠。