Clash 啟動時顯示連接埠被占用：找出占用程序並修改 mixed-port

先查看記錄：確認連接埠、位址與錯誤類型

Clash 或 Clash Meta（現稱 mihomo）啟動時若發生連接埠繫結失敗，請先確認是哪個監聽器啟動失敗。7890 常設定為本機代理入口，但不是固定要求，也不是遠端節點的伺服器連接埠。修改本機入口通常不必更動訂閱中的節點位址、密碼或代理規則。

在用戶端的記錄頁面搜尋 listen、bind、address already in use 等關鍵字，記下完整的本機位址與連接埠。例如，以下記錄表示 TCP 的 IPv4 迴路位址繫結失敗：

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

Windows 也可能顯示 Only one usage of each socket address。若出現 permission denied 或 An attempt was made to access a socket in a way forbidden by its access permissions，還應檢查權限、安全性原則或系統保留連接埠，不能直接判定是另一個 Clash 程序占用。

排查時要看的是「協定 + 本機位址 + 連接埠」，不只是數字。127.0.0.1:7890、0.0.0.0:7890 與 [::]:7890 的監聽範圍不同；萬用位址與雙堆疊監聽可能和更特定的位址衝突。

Windows：使用 netstat 與 PowerShell 找出程序

查詢監聽記錄並確認 PID

開啟 PowerShell，先執行以下指令。第一個指令可快速查看，第二個則依本機 TCP 連接埠精確篩選。若要查看其他程序的完整資訊，可能需要以系統管理員身分執行終端機。

netstat -ano -p tcp | findstr ":7890"
Get-NetTCPConnection -LocalPort 7890 -State Listen -ErrorAction SilentlyContinue |
  Select-Object LocalAddress, LocalPort, State, OwningProcess

netstat 最後一欄是程序識別碼 PID。請留意，findstr 也可能比對到遠端位址或 78900 等字串，因此要確認「本機位址」欄確實是 7890，且狀態為 LISTENING。TIME_WAIT 是連線狀態，不應因此任意結束程序。

假設查到的 PID 是 4321，接著查看程序名稱、執行檔路徑與命令列。這裡的 4321 僅為範例，執行前務必換成實際查詢結果。

tasklist /FI "PID eq 4321"
Get-CimInstance Win32_Process -Filter "ProcessId = 4321" |
  Select-Object Name, ExecutablePath, CommandLine

若該程序是由另一個代理用戶端啟動的 mihomo，請優先從該用戶端的系統匣選單結束，或關閉其背景服務。只關閉視窗不一定會停止核心。若 PID 屬於系統服務或不熟悉的軟體，請先確認路徑與用途，不要直接強制結束程序。

沒有監聽記錄，卻仍顯示繫結失敗

• 確認記錄指向的是否為 7891、9090 或其他連接埠，而非 7890。
• 確認用戶端是否在失敗後反覆重新啟動核心，導致查詢時剛好遇上程序退出的空檔。
• 若記錄明確指出 UDP，請使用 Get-NetUDPEndpoint -LocalPort 7890 查詢，不要只查 TCP。
• 若錯誤與存取權限限制有關，可執行下方指令查看 IPv4 TCP 排除連接埠範圍。若連接埠落在此範圍內，改用其他可用連接埠通常比刪除系統保留範圍更妥當。

netsh interface ipv4 show excludedportrange protocol=tcp

macOS：使用 lsof 查看監聽程序與背景服務

在「終端機」執行下方指令。-nP 可避免將位址與連接埠轉換成名稱，-sTCP:LISTEN 則只顯示監聽中的通訊端，方便區分本機服務與一般對外連線。

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

結果中的 COMMAND 是程序名稱，PID 是程序識別碼，NAME 顯示監聽位址。若看到 *:7890，表示它並非只繫結到某個指定的本機介面。接著查詢完整命令列，確認核心是由哪個用戶端或啟動項目執行：

ps -p 4321 -o pid,ppid,user,command

若確認是舊用戶端殘留，請先正常結束對應的應用程式；若仍未停止，可在「活動監視器」中選取已確認的程序並嘗試結束。使用命令列時，可對實際 PID 傳送 kill -TERM 4321，讓程序有機會正常清理。不要一開始就使用 kill -9。

若程序剛結束就出現新的 PID，通常表示有自動重新啟動機制。macOS 13 及後續版本可前往「系統設定」→「一般」→「登入項目」（部分版本稱為「登入項目與延伸功能」）檢查背景項目；透過 Homebrew 安裝的服務也應檢查 brew services list。請從對應的服務管理介面停用服務，不要反覆結束子程序。

Ubuntu 與 Linux：使用 ss 找出 systemd 服務與重複執行的核心

在 Ubuntu 上，建議優先使用 ss 查詢 TCP 監聽狀態。加上 sudo 後，通常能看到其他使用者程序的 PID 與程式名稱；省略權限時可能只能看到通訊端，無法辨識程序。

sudo ss -ltnp 'sport = :7890'
sudo ss -lunp 'sport = :7890'

第一個指令查看 TCP，第二個查看 UDP。TCP 輸出中的 LISTEN 代表正在監聽；UDP 通常顯示 UNCONN，兩者的狀態名稱不同。若系統已安裝 lsof，也可使用與 macOS 相同的 sudo lsof -nP -iTCP:7890 -sTCP:LISTEN。

桌面用戶端與 systemd 同時執行

常見衝突情況是伺服器部署留下的 systemd 服務已占用 7890，桌面用戶端又嘗試啟動另一個核心。若 PID 是 4321，可先查看命令列與所屬服務，再決定要保留哪一套：

ps -p 4321 -o pid,ppid,user,args
sudo systemctl status 4321

systemctl status 可依 PID 查詢所屬單元；若確認它屬於名為 mihomo.service 的自訂服務，而目前要改用桌面用戶端，可停止該服務：

sudo systemctl stop mihomo.service
sudo ss -ltnp 'sport = :7890'

服務名稱請以本機查詢結果為準。若之後也不需要開機啟動，再執行 sudo systemctl disable mihomo.service；單獨執行 disable 不會停止目前執行的程序。使用者層級的服務則使用 systemctl --user 操作。若服務啟用了自動重新啟動，直接結束核心往往只會讓它再次啟動。

若監聽者顯示為容器相關程序，也應確認容器的主機連接埠對應。不要只為了釋出一個代理連接埠就停止整個容器執行環境；可以調整該容器的連接埠對應，或替本機代理更換入口。

修改 mixed-port：區分介面設定與實際生效的設定

若占用者是必須保留的程式，可將 Clash 的本機入口從 7890 改為 17890。17890 僅為本文範例，不保證在你的裝置上可用；修改前請先使用前述指令查詢這個新連接埠。

優先在圖形介面用戶端中修改設定

各用戶端的介面名稱不盡相同，通常可在「設定」中的「連接埠」、「代理連接埠」或「核心設定」找到相關選項。請先確認目前顯示的是混合連接埠，而非控制器連接埠。用戶端可能會將設定寫入產生的設定檔，並覆寫訂閱檔中的同名欄位，因此不要只修改下載到本機的訂閱 YAML。

獨立執行 mihomo 時，修改根層級欄位

若核心直接讀取設定檔，請編輯啟動參數 -f 指定的檔案；若有使用工作目錄 -d，則確認該目錄中的實際設定檔。以下為入口欄位的修改範例，並非包含節點與規則的完整設定：

mixed-port: 17890
allow-lan: false
bind-address: 127.0.0.1
mode: rule
log-level: info

• mixed-port 必須寫在 YAML 根層級，前面不要加上 general:，也不要縮排到 dns: 底下。
• 若原設定還有 port、socks-port 等獨立入口，請逐一確認是否仍占用衝突的連接埠。只修改混合連接埠不會自動變更其他入口。
• 修改根層級入口後，請依用戶端要求重新套用設定或重新啟動核心；只切換代理節點不一定會更新監聽器。
• 更新訂閱可能會覆寫直接編輯的內容。若用戶端支援覆寫或合併功能，請在持久化設定或覆寫層中保存本機連接埠設定。

獨立部署時，可使用 mihomo -t -f /etc/mihomo/config.yaml 檢查設定檔是否可解析，並依實際部署調整路徑。設定檢查通過不代表執行時連接埠一定可用，仍須確認啟動記錄與監聽狀態。

同步調整系統代理、瀏覽器與終端機連接埠

將核心連接埠改為 17890 後，若應用程式仍連線至 127.0.0.1:7890，通常會從「核心啟動失敗」變成「代理伺服器拒絕連線」。所有曾手動填入舊連接埠的位置都要同步更新，不只是用戶端介面。

若由用戶端管理系統代理，確認新入口成功監聽後，可先關閉再開啟「系統代理」，讓用戶端重新寫入位址。Firefox 若選擇「使用系統代理設定」，通常不必另外填寫連接埠；若選擇手動代理，則須自行更新。

在 Linux 或 macOS 的目前 shell 中，可視需要更新環境變數。https_proxy 使用 http:// 並不矛盾：這表示應用程式透過 HTTP 代理建立 HTTPS 通道，不是將目標網站改用 HTTP。

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

這些指令只會影響目前的 shell 及其後續子程序，已開啟的應用程式不會自動更新。也請檢查 shell 啟動檔案是否保存了舊值。Git 可先使用 git config --show-origin --get-regexp '.*proxy.*' 查看設定來源，再依實際範圍修改，避免只改了全域設定卻漏掉儲存庫設定。

TUN 模式透過虛擬網卡接管流量，與明確設定的 HTTP/SOCKS 入口不是同一種機制。啟用 TUN 不會釋出已被占用的連接埠；若設定仍要求監聽 7890，該監聽器仍可能報錯。也不要因為 TUN 模式下部分應用程式可用，就忽略舊的系統代理設定。

復原驗證：檢查監聽、請求與重新啟動後的持續性

1. 確認監聽程序。使用對應系統的查詢指令檢查 17890，確認監聽者是預期保留的核心，並核對迴路位址或萬用位址。
2. 傳送明確的代理請求。使用下方指令排除「應用程式是否遵循系統代理」的不確定性，分別測試 HTTP 與 SOCKS5 入口。
3. 檢查用戶端連線記錄。確認測試請求已進入核心，再查看規則比對結果與出口。能連線至本機入口，不代表遠端節點一定可用。
4. 測試日常使用的應用程式。重新開啟瀏覽器或終端機，確認是否仍使用 7890。
5. 確認重新啟動與訂閱更新後的設定。重新啟動用戶端後再次檢查連接埠；更新訂閱後確認持久化設定沒有被覆寫。

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

在 Windows PowerShell 中，建議將上述 curl 明確寫成 curl.exe，避免舊版 PowerShell 的同名別名造成參數差異。--noproxy "" 用於排除繞過代理設定的干擾；5 秒與 20 秒分別是連線逾時與整體請求逾時，不是速度測試結果。

若回應為連線遭拒，請繼續檢查本機監聽狀態與連接埠；若已連上代理但後續逾時，則轉而檢查規則、節點、DNS 與目標網站的連線狀況。若發生錯誤的其實是控制 API 的 9090，應同步修改控制器位址與用戶端連線參數，而不是一再修改 mixed-port。依照「從記錄定位 → 查詢程序 → 處理重複服務或更換連接埠 → 同步應用程式設定 → 驗證」的順序處理，可將本機繫結故障與後續網路問題分開排查。