一、典型現象：不是「Clash 壞了」這麼單純
旁路由方案最常見的落差，是使用者以為「把 DHCP 的預設閘道改成旁路由 IP」就等於透明代理完成。實務上，封包要進 Clash，還要經過核心是否監聽、nftables 或舊式 iptables 是否把 TCP／UDP 導向正確埠、回程 NAT 是否把內網來源位址改寫成旁路由可路由的形狀；任一環節缺一角，就會出現「Ping 得到閘道但 HTTPS 全掛」「只有手動設 HTTP 代理才通」「網頁能上，查 DNS 卻仍顯示電信」等片斷現象。
本文刻意把閘道與防火牆規則放在 Clash YAML 之前：多數斷線不是規則寫錯，而是家庭網路第 2～3 層沒把流量送進核心。若你已在 Linux 上常駐核心，可先對照 《Ubuntu 22.04 systemd 與 Mihomo》 確認服務與監聽埠無誤，再回到本文做網路層核對。
二、先畫拓樸：主路由、旁路由、兩層閘道
請先用紙筆或圖示標出三個位址：主路由 LAN IP（常見 192.168.1.1）、旁路由在相同子網路內的靜態 IP（例如 192.168.1.2）、以及旁路由對外上網時實際使用的上游閘道。若旁路由本身還要透過主路由上網，則旁路由的預設閘道應指向主路由，而內網客戶端的預設閘道則指向旁路由；兩者角色不可互換後忘記調整。
DHCP 建議仍由主路由發放，但把「預設閘道」改成旁路由；或改由旁路由發放並把 DNS 一併指到旁路由，較利於後續 DNS 劫持。無論哪種，請確認沒有第二台 DHCP 搶答，否則部分裝置會拿到錯的閘道，看起來像「只有某些裝置不走代理」。
ip route 看預設路由是否唯一；若同時存在多條預設路由或 metric 打架，透明轉發階段會出現間歇性斷線。
三、Linux IP 轉送與回程：沒開轉送就不該有透明轉發
透明轉發依賴核心把「不是給本機的封包」再丟出去。請確認 net.ipv4.ip_forward=1（若走 IPv6 再加對應項）。僅改 sysctl 仍不夠：從內網進來的封包若被 Clash 接收後，回程必須能回到客戶端；這通常需要 MASQUERADE 或對稱的 SNAT，把來源改寫成旁路由在該網段的位址，否則主路由不知道要把回程送給誰。
另一個隱坑是反向路徑過濾（rp_filter）。若介面多、或你在主路由上對旁路由做策略路由，嚴格的 rp_filter 可能默默丟封包；除錯期可暫時寬鬆驗證，再回復安全值。
四、Clash 端：監聽位址、透明埠與 allow-lan
旁路由上的 Clash／Mihomo 必須讓區域網路客戶端能把封包送達：常見是 redir-port、tproxy、或開啟 TUN 後由核心路由表接手。若設定檔把 HTTP／SOCKS 只綁在 127.0.0.1，外機永遠打不進來；改綁 0.0.0.0 時請同步檢視防火牆，概念與 Windows 混合埠與區網 類似，只是 Linux 換成 nftables／firewalld。
若你使用 fake-ip 模式，請務必搭配 《fake-ip 與 DNS 排查》，避免「TCP 已進代理、但解析仍在客戶端繞過 Clash」的錯覺。Windows 與 WSL 疊加情境則可參考 《WSL2 與 DNS》，其 DNS 繞路邏輯與旁路由上「誰是 DNS 權威」問題同源。
五、nftables／iptables：把流量導進 Clash 的那條鏈
多數發行版已預設 nftables 作為後端；若你貼的是舊式 iptables 規則，實際可能被 iptables-nft 轉譯。除錯時請以 nft list ruleset 看真實規則，避免文件照抄 legacy 語法卻套在 nft 環境。
常見透明代理鏈路是：在 nat 表的 PREROUTING（或對應 hook）對內網子網路來源做 redirect 到 Clash 的 redir-port；同時排除旁路由本機與已經是 Clash 埠的連線，避免迴圈。UDP 與 TCP 規則常需分開處理；若你使用 tproxy，還要搭配策略路由標記（fwmark）與額外的 mangle 規則，這條路較進階，建議先確認 TCP 80／443 再走 UDP／QUIC。
六、TUN 與 redir：兩條路擇一，不要雙重攔截
TUN 模式把大量流量交給虛擬介面與路由表，較接近「整機 VPN」心智；redir／tproxy 則是在防火牆層把特定埠丟給本機埠。兩者若同時對同一批封包生效，極易出現環路或重複 NAT。選型上：需要連同非標準埠的長尾流量一併走核心時，TUN 較省事；只想攔常見 Web 埠且希望規則透明可讀時，nft redirect 較直觀。
若你從 Windows 實驗室環境遷移，可對照 《TUN 與路由防火牆（Windows）》 的「流量是否真的進核心」檢查思路，把「工作管理員／防火牆」映射成 Linux 的 ss、nft、tcpdump。
七、DNS 劫持：只改閘道不改 DNS，仍會像「沒過代理」
許多手機與瀏覽器會使用私密 DNS、DoH、或硬編碼的解析路徑；即使預設閘道已指到旁路由，查詢仍可能直連公網 443，導致你看到「IP 測試已變、網站地區判斷卻仍錯」的割裂感。解法通常有三層：DHCP 把 DNS 指到旁路由、在旁路由上對 53/udp（與 DoH 常用埠若你要嚴格）做 redirect 到 Clash DNS、以及在 Clash 內用 fake-ip 或 redir-host 與規則對齊。
fake-ip 與 DNS 劫持搭配時，請優先讀 fake-ip 專文 的「解析在誰身上完成」段落；否則你會花大量時間調 rules:，其實問題在客戶端仍用電信 DNS。
八、裝置仍直連或仍電信 DNS：客戶端例外清單
即使旁路由設定完美，這幾類裝置仍常「像沒改閘道」：已啟用私密 DNS 的 Android、關掉 DHCP 手動填 DNS 的桌機、使用公司 VPN 的筆電、以及仍拿到 IPv6 前置並走運營商直連的終端。建議在路由器上暫時關閉 IPv6 或同步做 NDP／路由公告調整，讓問題收斂到單一 IP 版本後再逐一打開。
另一種情況是主路由上仍有強制代理／家長護衛或 DPI，對透明轉發插入 RST；此時在旁路由上用 tcpdump 看握手是否被中途截斷，會比盲目改節點更有效。
九、驗證指令與觀測順序
建議固定順序：先在客戶端確認預設閘道與 DNS；再在旁路由確認轉送與預設路由；接著 ss -lunpt 看 Clash 埠是否聽在對的位址；然後 nft list ruleset；最後才看 Clash 日誌的規則命中。跳過前兩步直接改 YAML，往往只是在旋轉。
十、症狀對照表（快速收斂）
| 你看到的情況 | 優先檢查 |
|---|---|
| 閘道 Ping 通，HTTPS 全失敗 | nft redirect 是否漏排除本機、redir-port 是否與 Clash 設定一致、回程 NAT 是否缺失 |
| 只有瀏覽器手動代理才通 | 透明規則未生效或只綁了本機監聽；確認 ss 監聽位址與防火牆 |
| 網頁能上，地區或解析仍像電信 | 客戶端 DoH／私密 DNS、fake-ip 與規則；見 fake-ip 文 |
| 不定時全斷 | 雙 DHCP、IPv6 外洩、rp_filter、或主路由與旁路由 metric 衝突 |
更細的 YAML 與鍵名仍以 設定說明 與上游文件為準；若你需要圖形客戶端在桌機先行驗證規則，也可自本站 下載頁 取得對應平台安裝包。
十一、合規聲明
請遵守所在地法律、電信條款與服務提供商政策；本文僅描述家庭網路下常見的技術排錯流程，不提供規避監管或未授權存取他人網路之指引。
十二、小結
旁路由加上 Clash 透明代理，成敗多半取決於「閘道是否一致、轉送與 NAT 是否閉環、nftables／iptables 是否把正確五元組送進核心、以及 DNS 是否真的經過旁路由」。把這條鏈分段驗證，比一次改十行規則更能快速定位問題。
相較僅在單機客戶端切換系統代理的工具，Clash 生態在規則、核心與多平台之間更容易沿用同一套設定；當你在旁路由上把網路層打通後，無論回到桌面圖形客戶端或繼續用命令列託管，都能沿用已驗證的邏輯。