故障排除 閱讀時間約 11 分鐘

Clash 7890 連接埠遭占用：查出占用程序並更改混合連接埠

Clash 啟動時若提示連接埠遭占用，可用 netstat、lsof 找出占用程序，再修改 mixed-port 和外部控制連接埠，並同步更新系統代理設定。

先確認記錄檔中的監聽位址與連接埠

Clash 顯示連接埠遭占用，通常表示核心無法在指定位址建立監聽。常見原因包括同時啟動兩個代理用戶端、舊核心未完整結束，或背景服務占用了相同連接埠。此時更新訂閱、切換節點或修改分流規則，都無法排除本機的監聽衝突。

先開啟用戶端的「記錄檔」頁面，找出包含 bind、listen 或 address already in use 的完整記錄。Windows 也可能顯示 Only one usage of each socket address。以下僅為辨識錯誤類型的範例，並非本機實際輸出：

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

第一行涉及本機代理入口，第二行則是控制介面。請依實際發生錯誤的連接埠排查，不要看到 Clash 啟動異常就只檢查 7890。若記錄檔顯示 permission denied 或套接字存取遭拒，還需檢查權限、系統保留連接埠範圍或安全性原則，不應直接認定是其他程序占用。

設定項目用途與範例修改後的影響
mixed-portHTTP 與 SOCKS 共用入口，例如 7890需同步更新系統代理及手動指定代理的應用程式
port / socks-port分別提供 HTTP、SOCKS 入口，實際值以設定為準需同步更新使用相應通訊協定的應用程式
external-controller控制介面，例如 127.0.0.1:9090面板或用戶端連線至核心的設定可能需要同步更新

Windows：用 netstat 查詢 PID，再確認程式路徑

在 PowerShell 中找出監聽程序

在「開始」按鈕上按右鍵，選擇「終端機」，然後在 PowerShell 分頁執行以下命令。一般查詢不需要系統管理員權限；若無法查看程序資訊，再以系統管理員身分開啟終端機。

netstat -ano -p tcp | findstr ":7890"

請確認本機位址欄是否以 :7890 結尾，以及狀態是否為 LISTENING。遠端位址剛好包含 7890，或連線狀態為 TIME_WAIT，都不足以證明有程式正在監聽本機的 7890。每行最右側的數字就是 PID。

若只想列出指定連接埠的監聽程序，可直接使用 PowerShell：

Get-NetTCPConnection -LocalPort 7890 -State Listen -ErrorAction SilentlyContinue |
  Select-Object LocalAddress, LocalPort, OwningProcess

假設查到的 PID 是 1234，接著確認程序名稱與路徑。1234 僅為範例，執行時請換成剛查到的數字：

tasklist /FI "PID eq 1234"
Get-Process -Id 1234 | Select-Object Id, ProcessName, Path

確認來源後再結束程序

  1. 若是另一個代理用戶端，請從該用戶端的系統匣選單選擇「結束」，不要只關閉主視窗。
  2. 若是目前用戶端留下的舊核心，請先正常結束用戶端，再次查詢 PID，確認背景程序是否仍在執行。
  3. 若是其他應用程式，請讓該程式繼續執行，並改用未占用的代理連接埠。
  4. 若 PID 對應的是服務或系統程序，請先查看「工作管理員」中的「詳細資料」與「服務」，不要直接強制終止。

程序名稱含有 mihomo 或 clash，不代表它一定是殘留程序。啟用服務模式的用戶端可能會讓核心持續在背景執行。若只結束程序，卻未關閉系統匣程式或服務，核心可能會立即重新啟動。

macOS 與 Linux：用 lsof、ss 查詢監聽來源

macOS：分辨主視窗與選單列程序

開啟「應用程式」→「工具程式」→「終端機」，查詢 TCP 7890 的監聽程序：

lsof -nP -iTCP:7890 -sTCP:LISTEN

-nP 會保留數字位址與連接埠，避免名稱解析影響判讀。輸出中的 COMMAND、PID 和 NAME 分別用來識別程序、程序編號與監聽位址。若一般查詢沒有結果，但錯誤仍然存在，可執行 sudo lsof -nP -iTCP:7890 -sTCP:LISTEN，檢查由其他使用者擁有的程序。

確認來源後，從選單列圖示結束對應的用戶端。在 macOS 中，關閉視窗通常不代表結束應用程式。若要進一步查看特定 PID 的啟動命令，可執行：

ps -p 1234 -o pid=,ppid=,command=

Linux：同時檢查桌面用戶端與服務

多數 Linux 發行版可使用 ss 查詢；若要顯示完整程序資訊，通常需要提升權限：

sudo ss -ltnp 'sport = :7890'

若查到的核心來自 systemd 服務，關閉桌面視窗並不會停止該服務。請先根據輸出的程序路徑確認來源，再到相應的服務管理介面停止重複執行的執行個體。服務名稱取決於安裝方式，不能直接把網路上看到的服務名稱當成本機服務名稱。

  • 127.0.0.1:7890 表示透過 IPv4 本機迴路位址監聽。
  • 0.0.0.0:7890 表示監聽所有 IPv4 網路介面，可能與僅綁定迴路位址的執行個體發生衝突。
  • [::]:7890 表示 IPv6 通用位址；是否同時接受 IPv4，取決於系統與套接字設定。

因此，排查時不能只找文字完全等於 127.0.0.1:7890 的列。通用位址、IPv6 監聽，以及由其他使用者執行的服務，都必須一併檢查。

修改 mixed-port：以實際生效的設定為準

確認占用來源後，有兩種處理方式：結束不需要的重複執行個體，繼續使用 7890；或保留現有程式，將目前的用戶端改用未占用的連接埠。請先用前述命令檢查 17890，再進行修改。以下設定適用於支援這些欄位的 Clash 核心與 Clash Meta（mihomo），並非完整的訂閱檔案。

優先修改由用戶端管理的連接埠設定

  1. 記下目前的混合連接埠、HTTP 連接埠、SOCKS 連接埠與控制介面位址，並備份目前的設定。
  2. 開啟用戶端的「設定」，找到「連接埠」或「混合連接埠」。部分用戶端會將相關選項放在「Clash 設定」或「核心設定」中，選單名稱依用戶端而異。
  3. 將混合連接埠改為 17890，儲存後使用用戶端提供的重新啟動核心功能。
  4. 重新開啟記錄檔，確認新連接埠已成功監聽，再用系統命令檢查 17890 的占用程序是否為預期的核心。

若用戶端透過 YAML 管理這些值，請在實際使用的本機設定或覆寫設定中修改：

# 合併至現有設定中，請勿用此片段覆蓋完整設定。
mixed-port: 17890
allow-lan: false

allow-lan: false 用於限制區域網路存取，並非解除連接埠占用的開關。若僅供本機使用，請勿為了排查問題而將監聽位址改為 0.0.0.0，也不要任意啟用區域網路存取。

檢查舊入口與設定覆寫來源

設定中可能同時定義 port、socks-port 和 mixed-port。修改混合連接埠不會自動移除另外兩個入口；如果錯誤來自其他監聽項目，仍須分別處理。請勿在同一個 YAML 對應項目中重複新增多個 mixed-port 鍵。

訂閱檔案也可能遭用戶端的全域設定、合併設定或覆寫規則覆蓋。直接編輯下載的訂閱檔案，下次更新後可能會還原原值。請使用用戶端支援的持續性設定，並以啟動記錄檔和系統監聽結果確認最終值，不要只看編輯器中儲存的內容。

9090 衝突：另行處理外部控制連接埠

若記錄檔明確指出 9090，請查詢占用 9090 的程序，不要一再修改混合連接埠。控制介面供用戶端或面板管理核心使用，並非讓瀏覽器瀏覽網頁的 HTTP 代理入口。

# 僅在用戶端允許自訂控制介面時合併此項。
external-controller: 127.0.0.1:19090

部分桌面用戶端會自動管理控制位址與驗證資訊。請優先透過用戶端提供的設定介面修改；強行變更產生的設定，可能導致主介面無法連線至核心。手動連線的外部面板則須將控制位址同步更新為 127.0.0.1:19090，並確保驗證金鑰一致。

同步更新系統代理、終端機變數與應用程式內的代理設定

新連接埠開始監聽後，應用程式仍連線至舊連接埠，是最常見的後續問題。此時記錄檔可能不再顯示綁定失敗，但瀏覽器會顯示代理連線失敗，終端機也可能出現 connection refused。請逐一檢查使用代理的程式。

系統代理：確認設定為 17890

  • Windows 11：開啟「設定」→「網路和網際網路」→「Proxy」→「手動設定 Proxy」→「編輯」，確認位址與連接埠。若由用戶端接管，通常先關閉再開啟用戶端的「系統代理」，讓它重新寫入設定。
  • macOS：開啟「系統設定」→「網路」→目前使用的網路服務→「詳細資訊」→「代理伺服器」，檢查網頁代理、安全網頁代理及 SOCKS 代理中實際啟用的項目。
  • 應用程式內的代理設定：瀏覽器代理擴充功能、開發工具與下載工具可能有各自的設定。請將手動填入的 127.0.0.1:7890 改為 127.0.0.1:17890。

若使用自動代理設定指令碼（PAC），代理目的地可能由指令碼指定，而非來自手動代理欄位。請確認目前代理設定的來源，避免同時啟用擴充功能接管與手動系統代理，卻只修改其中一處。

終端機：環境變數不會隨用戶端設定自動更新

在 PowerShell 中，可使用以下命令暫時更新目前視窗的 HTTP 與 HTTPS 代理。這裡的 HTTPS 變數仍使用 http://，因為它指定的是本機 HTTP 代理入口，透過 CONNECT 轉送 HTTPS 請求。

$env:HTTP_PROXY = "http://127.0.0.1:17890"
$env:HTTPS_PROXY = "http://127.0.0.1:17890"

在 macOS 或 Linux 的 sh、bash、zsh 中，可於目前的終端機執行：

export http_proxy=http://127.0.0.1:17890
export https_proxy=http://127.0.0.1:17890

也請檢查大小寫形式的代理變數，以及 ALL_PROXY、all_proxy；不同工具採用的優先順序並不相同。若設定寫在 shell 啟動檔、系統環境變數或工具本身的設定中，也須一併更新持續性設定。暫時執行的命令只會影響目前程序及其後續子程序，不會修改已開啟的其他終端機。

TUN 模式使用的是另一種流量接管方式。啟用 TUN 不會釋放 7890，也無法讓綁定失敗的混合連接埠恢復監聽。排查本機連接埠時，不要把切換 TUN 當成替代處理方式。

驗證修復結果：監聽、代理請求與重新啟動後的設定

分三個步驟驗證，避免把節點無法連線誤判為連接埠仍遭占用。以下提供檢查命令，不預設回應狀態或所需時間。

  1. 確認監聽狀態。將前述查詢命令中的 7890 改為 17890，確認 PID 與程序路徑屬於目前的用戶端。
  2. 明確指定代理。略過系統代理自動設定，直接測試本機的新連接埠。
  3. 重新啟動後確認。正常結束並重新開啟用戶端，確認訂閱或覆寫沒有還原連接埠，再測試瀏覽器與常用終端機工具。

在 Windows 使用 curl.exe，避免部分 PowerShell 環境中的 curl 別名造成參數差異：

curl.exe --noproxy "" --proxy http://127.0.0.1:17890 --connect-timeout 5 --max-time 20 -I https://clash15.com/

macOS 與 Linux 可使用：

curl --noproxy "" --proxy http://127.0.0.1:17890 --connect-timeout 5 --max-time 20 -I https://clash15.com/

--noproxy "" 可避免現有的略過清單使這次測試直接連線。收到目標網站的回應，可用來判斷本次請求路徑，但不能證明所有節點與規則都正常。若仍顯示本機連線遭拒，請先重新檢查監聽狀態；若請求已進入核心記錄，之後才發生 DNS 或遠端逾時，則應改為排查名稱解析、規則或節點。

沒有監聽程序，卻仍提示無法綁定連接埠

請在錯誤發生時立即重新查詢，排除背景執行個體短暫重新啟動的情況。若 Windows 回報存取權限錯誤，可檢查系統排除的 TCP 連接埠範圍：

netsh interface ipv4 show excludedportrange protocol=tcp
netsh interface ipv6 show excludedportrange protocol=tcp

若目標連接埠落在排除範圍內，請優先改用範圍外且未占用的連接埠，不要直接刪除系統保留項目。虛擬化與網路元件可能會用到這些範圍。最後應確認四件事：只有預期的執行個體監聽目標連接埠、啟動記錄不再顯示綁定失敗、應用程式使用新連接埠，而且用戶端重新啟動後設定仍保留。

若要繼續檢查系統代理與模式選擇，請參閱系統代理設定步驟；若請求已進入核心，但發生遠端逾時，請前往連線逾時排查。請先在本機排除連接埠問題，再檢查訂閱與連線路線。

Clash 安裝包下載