Clash 混合連接埠與區域網路代理共享：監聽位址、防火牆與裝置連線

先說結論：共享代理需要同時打通四個環節

在一台電腦上執行 Clash，再讓同一區域網路中的手機、平板或另一台電腦透過它使用代理，重點不只是開啟「允許區域網路連線」開關。完整鏈路包含四個環節：Clash 核心必須監聽其他裝置可存取的網卡位址；區域網路存取開關必須啟用；主機防火牆必須允許該連接埠的入站連線；接入裝置必須填寫正確的主機區域網路位址與連接埠。任何一環不成立，用戶端都可能出現逾時、拒絕連線或只有部分應用程式可用。

常見且便於管理的做法是啟用一個 mixed-port，讓 HTTP 代理與 SOCKS5 代理共用同一個連接埠。手機系統的 Wi-Fi 手動代理通常填寫 HTTP 代理；支援 SOCKS5 的桌面軟體或網路工具則可連線至同一個連接埠，並依 SOCKS5 協定完成交握。混合連接埠只是統一入口，不會混淆一般 HTTP 請求與 SOCKS5 請求，核心會依連線協定辨識流量。

基本設定可以如下所示。不同圖形化用戶端可能透過介面開關產生這些欄位，也可能在訂閱更新後重新覆寫設定，因此修改後應重新開啟實際執行中的設定確認結果，而不是只檢查訂閱原始檔案。

mixed-port: 7890
allow-lan: true
bind-address: "*"
mode: rule
log-level: info

mixed-port 指定代理入口，allow-lan 允許來自本機以外的區域網路連線，bind-address 決定監聽哪些本機位址。使用星號代表監聽可用介面，設定簡單但範圍較廣。更嚴格的部署方式可以繫結執行 Clash 的區域網路網卡位址，例如 192.168.1.20，前提是該位址保持穩定。

混合連接埠解決什麼問題

傳統 Clash 設定可以分別宣告 port 與 socks-port，前者提供 HTTP 代理入口，後者提供 SOCKS5 代理入口。這樣便於分別控管兩類協定，但接入裝置較多時，需要記住兩個連接埠，也容易在系統代理設定中填錯。mixed-port 將兩種入口合併至同一個 TCP 連接埠，適合家庭區域網路、測試裝置與臨時共享情境。

混合連接埠不會自動接管區域網路裝置的全部流量。接入裝置仍需明確設定 HTTP 或 SOCKS5 代理，或由該裝置上的應用程式主動連線至代理。手機 Wi-Fi 設定中的「手動代理」通常只涵蓋遵循系統 HTTP 代理設定的應用程式；部分應用程式使用獨立網路堆疊、直接連線目標位址或主動忽略系統代理，因此可能不會經過 Clash。遇到「瀏覽器可用、某個應用程式無法使用」時，應先判斷該應用程式是否支援系統代理，而不是立即修改節點或規則。

SOCKS5 的 UDP 轉發能力還會受到接入應用程式、核心版本與具體協定實作影響。不能因為 TCP 請求能透過混合連接埠成功，就推斷所有 UDP 流量也會以相同方式處理。遊戲、即時通訊與依賴 QUIC 的應用程式需要個別驗證。若目標是接管一台裝置的大部分網路流量，應在該裝置本機使用相容的 TUN 模式，而不是把遠端混合連接埠當成完整的虛擬網卡方案。

混合連接埠與規則模式的關係

連接埠只負責接收連線，最終選擇直連、代理節點或拒絕連線，仍由 Clash 的執行模式、規則集與策略群組決定。在 rule 模式下，區域網路裝置傳來的網域名稱或目標位址會進入同一套規則比對流程；在全域模式下，流量通常交由全域策略群組處理；在直連模式下，即使裝置成功連線至混合連接埠，請求也可能直接存取目標。

因此，測試共享代理時需要同時記錄目前的模式與策略群組選擇。若手機能開啟網頁，但出口位址沒有變化，應檢查規則是否命中 DIRECT，以及目標網域是否被本機 DNS 解析成與預期不同的位址。連接埠連通只代表接入鏈路成立，不等於某條代理規則已經命中。

allow-lan 與監聽位址必須搭配檢查

allow-lan: true 代表允許其他主機存取代理監聽器，但實際能從哪張網卡接收連線，還取決於監聽位址。若程序僅監聽 127.0.0.1，該連接埠只對本機回送介面開放，其他裝置即使能 ping 通電腦，也無法連線至代理。若監聽 0.0.0.0 或由設定中的星號涵蓋所有介面，連接埠會出現在多個 IPv4 介面上；若繫結特定區域網路 IP，則只會透過對應介面提供服務。

更穩妥的設定方式是先確定共享範圍。只有一張家庭網卡且網路環境受控時，可以使用全介面監聽，再透過防火牆限制來源網段。電腦同時連線至公司 VPN、虛擬機網卡、容器網路與個人熱點時，建議繫結實際區域網路位址，避免代理入口出現在不需要的介面上。繫結特定位址後，若 DHCP 重新分配 IP，Clash 可能無法繼續監聽舊位址，因此應在路由器中設定 DHCP 位址保留，或在位址變更後同步修改設定。

如何找到供其他裝置填寫的位址

• Windows 可在網路設定中查看目前 Wi-Fi 或乙太網路的 IPv4 位址，也可以執行 ipconfig，找出正在使用且具有預設閘道的網卡。
• macOS 可在系統網路設定中查看目前連線的詳細資訊，也可以使用 ifconfig 檢查活動介面的位址。
• Linux 可執行 ip address，搭配 ip route 中的預設路由判斷實際的對外介面。

不要把 127.0.0.1 填到手機上。回送位址永遠指向目前裝置本身，手機存取 127.0.0.1:7890 時尋找的是手機本機服務，而不是執行 Clash 的電腦。也不要優先填寫虛擬機、Docker、VPN 或臨時熱點網卡的位址，除非接入裝置確實位於對應網路。

確認核心實際監聽狀態

圖形介面顯示「允許區域網路」並不能取代系統層級的監聽檢查。Windows 可使用 PowerShell 查詢連接埠，macOS 與 Linux 則可查看監聽中的通訊端。若輸出中只有回送位址，表示遠端裝置仍無法連線；若看到區域網路位址或萬用位址，則繼續檢查防火牆。

# Windows PowerShell
Get-NetTCPConnection -State Listen -LocalPort 7890

# macOS
lsof -nP -iTCP:7890 -sTCP:LISTEN

# Linux
ss -lntp | grep 7890

連接埠被其他程式占用時，Clash 可能啟動失敗、自動改用用戶端預設連接埠，或在日誌中回報監聽錯誤。排查時應以目前核心日誌與系統通訊端結果為準。修改連接埠後，所有接入裝置也必須同步更新，舊的 Wi-Fi 代理設定不會自動找到新的連接埠。

防火牆只開放必要的網路與連接埠

當 Clash 已經監聽區域網路介面，但其他裝置連線逾時時，主機防火牆通常是下一個檢查點。防火牆規則應允許混合連接埠的 TCP 入站連線，並盡量限制在目前的家庭或辦公室子網路。例如電腦位址是 192.168.1.20、子網路遮罩是 255.255.255.0，常見來源範圍是 192.168.1.0/24。實際網段必須依路由器與系統網路資訊判定，不能直接套用範例。

Windows 中應先確認目前連線被辨識為私人網路還是公用網路。入站規則可以繫結 Clash 用戶端程式，也可以繫結指定 TCP 連接埠；連接埠規則較容易驗證，但連接埠變更時需要維護。規則的適用範圍應限制為本機子網路或明確位址，而不是對所有遠端位址開放。macOS 首次接收入站連線時可能顯示系統提示，應確認允許的是目前使用的用戶端程序。Linux 則需要依實際使用的 nftables、firewalld、ufw 或發行版防火牆設定入站策略。

防火牆放行後，可以從另一台裝置測試 TCP 連線。若能建立 TCP 連線但代理請求失敗，問題通常已從網路層轉移至代理協定、驗證、規則或上游節點。完全逾時常見於防火牆丟棄封包、用戶端隔離或位址填寫錯誤；立即回傳「連線被拒絕」則更像是目標位址可達，但對應連接埠沒有程序監聽。

路由器的用戶端隔離也會阻斷連線

訪客 Wi-Fi、無線用戶端隔離與部分企業無線網路會禁止同一存取點下的裝置互相存取。此時手機可以連上網際網路，也能看到與電腦相似的網段，卻仍無法連線至電腦的連接埠。應檢查兩台裝置是否連線至同一個主網路、是否其中一台位於訪客網路，以及路由器是否啟用了 AP 隔離。雙路由環境還可能形成兩個子網路，只有從上層到下層的單向路由，導致裝置之間無法直接存取。

手機與電腦如何連線至混合連接埠

接入前先記錄執行 Clash 的電腦區域網路 IPv4 位址、混合連接埠與目前網路名稱。假設電腦位址為 192.168.1.20，混合連接埠為 7890，其他裝置應連線至同一台路由器，並將代理伺服器填寫為 192.168.1.20，連接埠填寫為 7890。範例位址不能直接照抄，位址必須來自實際執行 Clash 的主機。

Android 與 iOS 的 Wi-Fi 手動代理

1. 開啟目前 Wi-Fi 網路的詳細設定，選擇手動代理，而不是自動設定指令碼。
2. 伺服器或主機名稱填寫 Clash 主機的區域網路位址，連接埠填寫混合連接埠。
3. 儲存後先用瀏覽器造訪一般 HTTPS 網站，再檢查 Clash 的連線清單與日誌是否出現該裝置的請求。
4. 測試結束後關閉手動代理，避免離開目前網路後仍持續嘗試連線至無法到達的內部網路位址。

行動裝置系統的 Wi-Fi 手動代理主要面向 HTTP 與 HTTPS 連線。HTTPS 請求通常會透過 HTTP CONNECT 通道轉發，Clash 不需要解密網頁內容即可依目標主機與規則處理連線。部分應用程式不讀取系統代理設定，另一些應用程式使用 UDP 或自訂傳輸，因此不能以單一應用程式的結果代表整個系統。

Windows、macOS 與 Linux 接入

另一台桌上型電腦可以在系統網路設定中填寫 HTTP 代理，也可以只在瀏覽器、終端機工具或特定應用程式中設定代理。支援 SOCKS5 的應用程式可將協定選為 SOCKS5，並使用相同的主機位址與混合連接埠。命令列工具是否讀取系統代理取決於工具實作，必要時可在目前終端機工作階段中設定代理環境變數。

HTTP_PROXY=http://192.168.1.20:7890
HTTPS_PROXY=http://192.168.1.20:7890
ALL_PROXY=socks5://192.168.1.20:7890

這些變數只是格式範例。不同工具對大寫、小寫變數以及 socks5、socks5h 的處理方式有所差異，其中 socks5h 通常表示網域解析也交由代理端處理。使用前應查看對應工具文件，並避免同時設定互相衝突的系統代理與應用程式代理。

DNS 如何處理

區域網路裝置連線至混合連接埠時，DNS 路徑取決於代理協定與應用程式行為。HTTP 代理請求通常會將目標主機名稱交給代理伺服器處理；SOCKS5 用戶端則可能傳送網域名稱，也可能先在本機解析為 IP，再提交連線。手機上未經代理的應用程式仍會使用系統 DNS。Clash 設定中的 DNS 模組不會因為開放混合連接埠就自動成為全網 DNS 伺服器，也不應將 Clash 的 DNS 監聽連接埠與混合代理連接埠混為一談。

若規則依賴網域名稱，而用戶端提前將網域解析成 IP，核心可用於比對的資訊可能發生變化。mihomo 可以結合嗅探、DNS 與規則能力改善部分情境，但是否啟用應依設定來源與隱私界線決定。基礎共享情境應先讓 HTTP 代理穩定運作，再處理特定應用程式的網域辨識問題。

依網路層級排查連線失敗

高效排查的關鍵是逐層驗證，而不是反覆更換節點。先確認電腦本機能透過混合連接埠存取，再確認連接埠監聽位址，接著驗證區域網路連通性與防火牆，最後檢查 Clash 規則與上游代理。以下順序可以區分大多數問題。

1. 檢查核心執行狀態。確認目前設定載入成功、混合連接埠沒有衝突，且日誌中不存在監聽失敗或 YAML 解析錯誤。
2. 檢查本機代理。在執行 Clash 的電腦上連線至 127.0.0.1:7890。本機也失敗時，先處理核心、設定與節點，不要繼續調整區域網路設定。
3. 檢查實際監聽位址。確認連接埠監聽於區域網路 IP 或萬用位址，而不是只監聽回送介面。
4. 檢查兩台裝置的網路。核對 IP、子網路遮罩、預設閘道與 Wi-Fi 名稱，排除訪客網路、用戶端隔離與雙路由問題。
5. 檢查主機防火牆。允許目前網路範圍存取指定 TCP 連接埠，並確認規則套用於正確的網路設定檔。
6. 檢查接入端格式。伺服器欄只填寫 IP 或主機名稱，連接埠另行填寫數字，不要把 http://、路徑與連接埠全部塞進主機名稱欄位。
7. 查看連線清單。出現裝置請求表示區域網路鏈路基本成立；接著依目標網域、命中規則、策略群組與錯誤日誌定位後續問題。

設定被訂閱更新覆寫怎麼辦

訂閱通常提供代理節點、策略群組與規則，但區域網路監聽屬於本機執行參數。不同用戶端合併訂閱設定的方式各異：有些會保留介面中的連接埠與區域網路開關，有些直接使用訂閱欄位，另一些則透過覆寫、設定修補程式或全域設定產生最終設定。應優先使用用戶端提供的覆寫功能管理 mixed-port、allow-lan 與 bind-address，避免每次更新後手動編輯暫存檔案。

修改前先複製一份目前可用的設定，並記錄用戶端顯示的實際設定路徑。更新訂閱後重新檢查監聽狀態與連線日誌，可以快速判斷是節點變更，還是本機監聽參數被重設。若使用 Clash Meta（mihomo）核心，還應確認用戶端版本與核心版本的設定支援範圍，不能只根據另一個用戶端的介面名稱，推斷兩者行為完全相同。

TUN 模式不能取代區域網路監聽設定

TUN 模式主要解決執行 Clash 的本機流量接管問題，透過虛擬網路介面、路由與 DNS 協作處理更多應用程式流量。開啟主機 TUN 不代表區域網路中的其他裝置會自動將流量傳送給這台電腦，也不會自動完成閘道轉發。其他裝置若要使用混合連接埠，仍需設定代理；若要將電腦作為區域網路閘道，則涉及 IP 轉發、路由、NAT 與 DNS 等另一套網路設計，複雜度與安全界線都明顯不同。

在家庭環境中，如果只是為手機瀏覽器或測試裝置臨時提供代理，混合連接埠搭配手動代理通常已經足夠。需要長期接入多台裝置時，應固定主機位址、限制防火牆來源、記錄連接埠變更，並定期確認仍有哪些裝置使用該入口。如此可將問題限定在清楚的監聽、網路、代理協定與規則四個層級內。