裝了兩個代理軟件，為什麼「顯示已連接卻上不了網」？
介面綠燈、進程在跑、節點也選好了，但網頁就是打不開——這是多客戶端共存時最難查的一種故障。原因往往不在節點，而在本地端口被另一個軟件先搶走了。這篇把端口、系統代理、TUN 三條通路拆開講清楚，並給出能自己敲的驗證命令。
關鍵詞：兩個代理軟件衝突、顯示已連接上不了網、7890 端口被佔用、代理客戶端共存、系統代理與 TUN 區別
最後更新： · 內容維護：易聯 Residential IP Solution
- 多客戶端衝突集中在三條互不相干的通路：本地端口、系統代理、TUN；「顯示已連接卻上不了網」絕大多數是端口被搶。
- Clash 系客戶端預設混合端口幾乎都是 7890，誰先啟動誰綁定，後啟動的那個介面照樣顯示已連接。
- 共存做法：端口錯開、只讓一個開 TUN、系統代理讓給另一個；不必卸載，也不必結束對方進程。
先給結論
多客戶端衝突集中在三條互不相干的通路上，搞清楚是哪一條，問題就解決一半：
- 本地端口——同一個端口只能一個進程綁，誰先啟動誰贏，後來者靜默失敗；
- 系統代理——作業系統全局只有一份設定，誰後寫誰生效；
- TUN／虛擬網卡——兩個客戶端都開 TUN 才會搶路由。
「顯示已連接但上不了網」這個具體症狀，絕大多數是第一條。
為什麼端口衝突這麼難發現？
Clash 生態的客戶端——Clash Verge、ClashX、mihomo-party、FlClash 以及各種基於它們的分支——預設混合端口幾乎都是 7890。這是歷史沿用下來的慣例，好處是配置通用，代價就是：你機器上只要同時裝了兩個，誰先啟動誰綁到 7890，後啟動那個的內核其實沒監聽成功。
要命的地方在於，後啟動那個客戶端的介面通常照樣顯示「已連接」——因為 UI 反映的是「配置載入了、節點選好了」，不是「端口真的綁上了」。於是你看到的是：軟件一切正常、進程也在、節點延遲還能測出來，但瀏覽器打不開任何網站。
這一點我們自己踩過：易聯桌面端早期沿用了同一個預設端口，用戶機上先跑了別的 Clash 客戶端時就會重現這個症狀。後來我們把預設混合端口改成不常用的值，並對舊配置做了自動遷移（只遷移仍是預設值的，用戶自己改過的一律不動），這類「裝了兩個就瞎」的報障才明顯減少。
三條通路對照表
| 通路 | 作用範圍 | 衝突表現 | 解決方向 |
|---|---|---|---|
| 本地端口（如 7890） | 顯式走該端口的程式 | 顯示已連接但完全上不了網 | 錯開端口，不必殺進程 |
| 系統代理 | 遵守系統設定的程式 | 後開的軟件「搶」走設定 | 讓其中一個改走 TUN |
| TUN／虛擬網卡 | 路由層，幾乎全部流量 | 兩個都開 TUN 才會搶 | 只讓一個開 TUN |
關鍵認知：這三條是不同層的機制，不是同一件事的三種叫法。所以「A 佔了系統代理」並不妨礙「B 走 TUN 正常工作」——它們可以並存，這也是多客戶端共存的基礎。
怎麼自測？三步定位
第 1 步：查端口被誰佔了
macOS / Linux：
lsof -nP -iTCP:7890 -sTCP:LISTEN
Windows：
netstat -ano | findstr 7890
看列出來的進程名。如果不是你現在想用的那個客戶端，端口就是被搶了。解決辦法是把其中一個客戶端的混合端口改掉（改成 27890 之類不常用的值），而不是去結束對方進程。
第 2 步：確認出口是不是你以為的那個
端口通了不代表走對了線路。打開 易聯 AI IP 檢測，或直接：
curl -s https://ipinfo.io/json
看返回的 org / 地區是不是你選的那條線路。如果顯示的是另一個軟件的出口，說明流量實際走了別人那條通路。
第 3 步：分清是端口問題還是分流問題
如果大部分網站正常、只有某一兩個服務打不開或報 403，那多半不是端口衝突，而是分流規則把那個域名匹配到了不合適的出口。快速判據：切到全局模式複測。全局正常、規則模式異常，基本可以鎖定是規則問題；兩種模式都不行，才回頭查端口和線路。
兩個客戶端能不能共存？正確做法
不要卸載，也不要結束別人的進程。很多人裝多個客戶端各有用途，而且某些組網／內網工具可能是你訪問公司資源的唯一通道，強行關掉可能造成更大麻煩。
穩妥的分工是：
- 端口錯開——每個客戶端用自己獨有的混合端口，這一步能消掉大部分衝突；
- 只讓一個開 TUN——TUN 在路由層接管，兩個同時開必然打架；
- 系統代理讓給另一個——它和 TUN 分屬不同層，可以各用各的。
常見誤區
「介面顯示已連接就代表端口綁上了」——不是。UI 通常只反映配置狀態，端口綁定失敗也可能照樣顯示綠燈。
「換個節點試試」——端口衝突和節點無關，換多少個節點都一樣打不開。
「裝兩個就一定衝突，必須卸載一個」——錯開端口 + 只讓一個走 TUN，多數情況可以共存。
「某個服務 403 就是線路不通了」——先切全局複測。規則模式下的單點異常，更常見的是分流規則匹配錯了出口。
下一步建議
照上面三步走一遍，基本能分清是端口被搶、走錯線路，還是分流規則。如果確認出口本身沒問題、只是想讓 AI 工具和跨境業務更穩，再考慮線路本身的畫像乾不乾淨。