先看錯誤訊息：是連接埠占用，還是監聽權限問題？

Clash 介面能開啟，不代表 Proxy 核心已正常監聽。日誌出現 listen tcp 127.0.0.1:7890: bind，並伴隨「通常每個通訊端位址只允許使用一次」或 Only one usage of each socket address，通常表示已有程序使用相同的監聽位址與連接埠。此時反覆切換系統 Proxy 開關，無法釋放連接埠。

7890 是常見的本機 Proxy 連接埠，但不是所有用戶端都必須使用的固定值。實際連接埠請以目前生效的設定和核心日誌為準。HTTP 連接埠、SOCKS 連接埠、混合連接埠和控制介面連接埠用途各不相同，不能只因數字相近就互相替換。

日誌或現象優先檢查
位址已在使用、Only one usage查詢監聽程序，確認是否同時執行了兩個核心。
不允許存取、forbidden by its access permissions檢查 Windows 排除連接埠範圍、系統原則和安全軟體限制。
核心監聽正常，但瀏覽器連線遭拒檢查瀏覽器或系統 Proxy 是否仍指向舊連接埠。
日誌顯示其他連接埠發生錯誤，例如 9090依照日誌中的實際連接埠排查，不要只修改 mixed-port。

使用 netstat 找出監聽 7890 的程序

步驟一：篩選 TCP 監聽紀錄

開啟 Windows 終端機中的 PowerShell 或命令提示字元，執行以下命令。一般權限通常就能查看監聽連接埠；若出現權限提示，再以系統管理員身分開啟終端機。

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

-a 顯示連線和監聽連接埠，-n 以數字顯示位址，-o 顯示 PID。篩選字串中，7890 後方保留一個空格，可避免把 78900 之類的連接埠也列入。以下為格式範例，最後一欄的 12480 僅供示範：

  TCP    127.0.0.1:7890    0.0.0.0:0    LISTENING    12480
  • 127.0.0.1:7890 表示只在 IPv4 迴路位址上監聽。
  • 0.0.0.0:7890 表示監聽所有 IPv4 本機位址，可能與迴路位址上的監聽發生衝突。
  • [::]:7890 是 IPv6 萬用位址監聽，是否衝突需視實際通訊端設定而定。
  • 同一個 PID 出現多行，不一定代表有多個程式，也可能是同一個程序監聽多個位址。

步驟二：依 PID 確認程序身分

按下 Ctrl + Shift + Esc 開啟工作管理員，切換到「詳細資料」，依 PID 找到對應程序。若看不到 PID，請在欄位標題上按右鍵，選擇顯示該欄。對目標程序選擇「開啟檔案位置」，確認它屬於哪個用戶端或服務。

tasklist /FI "PID eq 12480"

執行時，將命令中的範例數字替換成剛才查到的實際 PID。常見原因包括舊用戶端仍在系統匣執行、另一個用戶端也已啟動，或以服務模式執行的核心尚未結束。不要只因程序名稱包含 Clash 或 mihomo 就直接結束它，請先確認路徑和所屬用戶端。

使用 PowerShell 查詢的替代方法

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

輸出中的 OwningProcess 就是 PID。若命令沒有傳回監聽紀錄，請參照當時的日誌再做判斷；短暫啟動後就結束的核心，可能在查詢前已釋放連接埠。

排除衝突：關閉重複執行的用戶端，或改用未占用的連接埠

若占用連接埠的是另一個不再使用的用戶端，建議先從系統匣選單正常結束。若該用戶端啟用了獨立服務，關閉視窗可能只會隱藏介面，不會停止服務核心；請從該用戶端的服務管理入口停止對應服務，再重新查詢連接埠。

  1. 記下原本的系統 Proxy 位址和連接埠，暫時關閉系統 Proxy，避免排查期間其他應用程式繼續連線到失效的入口。
  2. 正常結束重複執行的用戶端，必要時透過 services.msc 確認對應服務。
  3. 再次執行 netstat，確認舊的監聽紀錄已消失。
  4. 啟動要保留的用戶端，查看日誌確認是否已成功監聽 7890。

若占用連接埠的是必須保留的程式，不必強行結束它。替 Clash 更換為未占用的連接埠通常更直接。本文以 7897 為例，但無法保證每台電腦都能使用此連接埠，修改前請先檢查：

netstat -ano -p tcp | findstr LISTENING | findstr ":7897 "

修改 mixed-port：變更本機 Proxy 入口

mixed-port 會讓同一個本機監聽連接埠接受 HTTP 和 SOCKS Proxy 連線。它不是節點伺服器連接埠，也不是訂閱連結的連接埠。設定中 Proxy 節點的 port 屬於遠端連線參數，無法解決本機 7890 的監聽衝突。

先確認用戶端實際使用的設定檔

不同用戶端的連接埠設定位置和儲存方式各不相同。先到設定中尋找「連接埠」、「混合連接埠」或 mixed-port；若有圖形介面可供設定，優先在介面中修改。使用 mihomo 核心的用戶端也可能透過覆寫、合併設定或執行階段設定來管理連接埠；直接編輯訂閱快取檔案，可能會在下次更新時被覆蓋。

若需要編輯 YAML，請先備份原始檔案，再將生效設定中既有的 mixed-port 修改為目標值。以下僅列出需要調整的欄位，並非完整設定檔，請勿用它覆蓋整份訂閱：

mixed-port: 7897
  • 此欄位需放在 YAML 頂層，不要放進 proxies、proxy-groups 或 rules 清單中。
  • 同一份最終設定中，不要出現重複的 mixed-port 鍵。
  • 若也啟用了 port: 7890 或 socks-port: 7890，舊連接埠仍可能發生衝突，需分別檢查這些獨立監聽項目。
  • external-controller 是用戶端管理核心的控制介面，不應當作瀏覽器 Proxy 連接埠使用。

重新載入後，確認監聽狀態已更新

儲存後，使用用戶端提供的重新載入設定或重新啟動核心功能。只儲存檔案而不重新載入，舊程序可能仍使用原本的連接埠。接著查看日誌並再次查詢 7897：應能看到目標核心的 PID 正在監聽。若介面顯示 7897，日誌卻仍是 7890，請優先檢查設定是否被覆寫，以及目前啟用的設定是否為剛才修改的檔案。

同步 Windows 系統 Proxy 與應用程式內的 Proxy 設定

連接埠修改成功後，並非所有用戶端都會自動同步系統 Proxy。若核心已監聽 7897，但 Windows 仍指向 127.0.0.1:7890，瀏覽器就可能出現 Proxy 連線失敗。請先確認新連接埠已成功監聽，再重新啟用用戶端的系統 Proxy 功能，並檢查 Windows 儲存的位址。

  1. Windows 11：前往「設定」→「網路和網際網路」→「Proxy」→「手動設定 Proxy」→「使用 Proxy 伺服器」旁的「設定」。
  2. Windows 10：前往「設定」→「網路和網際網路」→「Proxy」，檢查手動 Proxy 設定。
  3. 位址請使用 127.0.0.1，連接埠須與目前的混合連接埠一致，本例為 7897。若使用 Proxy 指令碼，也要確認指令碼實際傳回的 Proxy 入口。

Firefox、開發工具、Git 和終端機環境變數可能各自設有 Proxy，不一定會沿用 Windows 設定。可先在終端機查看目前工作階段的 Proxy 變數：

Get-ChildItem Env: | Where-Object Name -Match 'proxy'

若結果仍指向 7890，請同步修改對應的應用程式或變數。若只要修改目前 PowerShell 工作階段，可使用以下兩行；這不會自動更新已開啟的其他終端機，也不會修改所有程式的設定。

$env:HTTP_PROXY = 'http://127.0.0.1:7897'
$env:HTTPS_PROXY = 'http://127.0.0.1:7897'

在 HTTPS_PROXY 中使用 http://，代表透過本機 HTTP Proxy 建立通道，並不是將目標 HTTPS 網站降級為 HTTP。排查時也不要任意執行 WinHTTP 重設命令：WinHTTP Proxy 與瀏覽器常用的 Windows 使用者 Proxy 設定，並非相同的設定入口。

沒有程序監聽連接埠，仍無法繫結

若 netstat 查不到占用程序，但日誌顯示「不允許存取」，可在系統管理員終端機查看 Windows 的 TCP 排除連接埠範圍。Hyper-V、WSL、容器或其他網路元件可能影響這些保留範圍，但不能只因安裝了某項功能就認定問題由此造成。

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

確認 7890 或預計使用的 7897 是否落在輸出的起始和結束連接埠範圍內。若在範圍內，優先選擇範圍外且未被監聽的連接埠。不要為了釋放單一 Proxy 連接埠就直接刪除系統保留範圍，這可能影響虛擬網路服務。

留意日誌中的通訊協定和位址

本文主要排查 TCP Proxy 監聽。若錯誤明確指出 UDP，請檢查對應的 UDP 端點，而非只查詢 TCP 的 LISTENING。UDP 輸出沒有相同的監聽狀態欄位，可使用以下命令查看：

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

若日誌顯示要繫結的區域網路位址已不存在，還需檢查 bind-address。若只供本機使用，請勿為了避開錯誤而任意開放區域網路存取；啟用 allow-lan 會改變可存取範圍，與解決本機連接埠衝突是兩回事。

確認問題已排除：分別檢查監聽、入口與出口

網頁重新開啟，還不足以確認所有設定都已同步。建議依下列三個層面檢查，更容易區分連接埠、Proxy 規則和節點連線問題。

  1. 確認監聽：查詢 7897，確認 PID 屬於目標用戶端的核心，且日誌不再出現繫結失敗。
  2. 確認入口：使用明確指定 Proxy 的請求，略過系統 Proxy 設定來測試本機入口。
  3. 確認出口：在用戶端連線紀錄中查看該請求套用的規則、策略群組和實際出口，確認是否符合預期。
curl.exe -I --connect-timeout 10 --max-time 20 --proxy http://127.0.0.1:7897 https://www.microsoft.com/

上述命令會明確連線至本機 HTTP Proxy。若立即顯示無法連線到 127.0.0.1:7897，請繼續檢查監聽狀態和連接埠；若 Proxy 連線已建立，但目標請求逾時，則應進一步檢查節點可用性、DNS、規則或遠端網路。收到 HTTP 回應不代表請求一定經過 Proxy 節點：Rule 模式仍可能讓目標直接連線，請以連線紀錄為準。

最後重新開啟瀏覽器和需要使用 Proxy 的應用程式，再重新啟動一次用戶端，確認連接埠設定能保留下來。若每次重新啟動或更新訂閱後又變回 7890，請修正用戶端的持久化設定或覆寫設定，而非反覆修改暫存檔案。TUN 模式也無法用來釋放連接埠；即使部分流量已交由虛擬網卡處理，失效的本機 HTTP Proxy 入口仍須另外修復。