配置教程 精选 标签： Clash 旁路由 透明代理 nftables 网关

Clash 旁路由透明代理连不上外网？网关与 nftables 规则逐步核对

很多人把 Clash 或 Mihomo 跑在软路由、小主机或树莓派上当旁路由，希望内网手机、电脑只改默认网关就能走透明代理；实际却常见完全上不了网、只有浏览器能开但游戏或 App 仍直连、或网页能开但解析结果仍是运营商。这类问题往往不是「订阅坏了」一条线能解释，而是家庭网络里网关、回程、内核转发、nftables／iptables 与 DNS 劫持叠在一起。本文按从外到内、从二层到四层的顺序给你一套可照抄的核对流程；若你更关心桌面端 TUN 或 fake-ip 本身，可再对照本站 Windows TUN 与路由排障 以及 fake-ip 与 DNS 专文。

约 24 分钟阅读
Clash 编辑部
文章目录

一、你在解决什么问题

旁路由透明代理的典型诉求是：主路由继续拨号、发 Wi‑Fi、跑 DHCP；旁边再接一台跑 Clash 的机器，内网设备把默认网关改成这台旁路由的 LAN 地址，期望所有 TCP／UDP（或至少大部分流量）被重定向进 Clash 监听的端口，或直接被 TUN 网卡收走，从而「不用每台设备安装客户端」。

这条链路里任意一环不对，症状都会很像「Clash 坏了」：例如主路由没有把去往旁路由背后网段的包正确回程；旁路由没开IP 转发；nftables 规则把 LAN 口也误伤；或终端虽然改了网关，DNS 仍指向主路由，结果被运营商劫持到错误 CDN。下文不绑定某一发行版固件名，而是按通用 Linux 与 OpenWrt 系思路写清核对顺序，你可以把命令换成自己系统上的等价工具。

建议：排障时准备三台视角——主路由、旁路由（SSH）、一台改了网关的测试机；每一步都在测试机上重复 ping 旁路由、主路由、公网 IP 与域名，观察在哪一跳开始异常。

二、拓扑与网关：先画清数据路径

最常见的家庭拓扑是：光猫桥接 → 主路由 WAN 拨号 → LAN 网段例如 192.168.1.0/24。旁路由双网口时，可以 WAN 接主路由 LAN、LAN 接交换机；单网口时则旁路由与所有终端同网段挂在主路由交换芯片下，仅占用一个 192.168.1.x 地址。两种拓扑下，默认网关该指向谁、主路由要不要写静态路由，答案并不相同。

若旁路由与终端同网段，终端网关改为旁路由 IP 后，发往公网的包会先给旁路由；旁路由若没有做 SNAT／MASQUERADE，公网回程包会仍回到主路由，而主路由可能不知道「这台内网 IP 应该从旁路由回来」，于是出现能 ping 旁路由却不能上网。解决办法通常是：在旁路由上对「经 Clash 出去的流量」做源地址伪装，或在主路由为旁路由子网（若你刻意划了子网）写静态路由。先把你属于哪种拓扑写在纸上，再对照下一节的回程核对。

主路由 DHCP 与「只改网关」是否冲突

若主路由 DHCP 仍把网关与 DNS填成自己，终端每次续租都会把设置改回去。常见做法有两种：其一，在主路由 DHCP 里把网关／DNS改成旁路由地址（全家默认走旁路由）；其二，保留主路由网关，只在需要翻墙的设备上静态绑定网关与 DNS。所谓「只改网关」若靠手工改系统设置，记得关闭终端上的随机 MAC 与路由器上的强制 DHCP 绑定重置之类功能，否则你会看到「时而走旁路由时而恢复主路由」的假象。

三、旁路由本机：Clash 与系统能否出网

在折腾nftables 之前，先在旁路由 SSH 里确认：不经过透明转发时，本机能否解析与访问外网。若旁路由自己都上不了网，改终端网关只会把故障放大。可依次检查：系统 DNS 是否能解析；curl -I 访问一个 HTTPS 站点是否 200；Clash 进程是否监听预期端口（mixed-port、redir-port 或 TUN 设备）。

若你使用 TUN 模式，注意旁路由上是否同时开了系统自带防火墙，把转发链拦死；若使用 redir／tproxy，要核对 Clash 配置里的端口与 nftables 目标端口一致。Linux 上把 Clash 做成常驻服务可参考本站 Ubuntu 与 systemd 部署文，先把「进程能稳定跑」与「本机出站正常」立住，再继续加透明规则。

注意：不要在未确认本机出站正常前，就把主路由 DHCP 的网关全局改成旁路由——一旦旁路由规则写错，可能出现全家断网，排障成本会陡增。

四、IP 转发与回程：为什么一改网关就「单向断」

透明代理依赖内核把不是发给本机的 IP 包转发出去。请确认 net.ipv4.ip_forward=1（IPv6 则对应 net.ipv6.conf.all.forwarding）在运行时为 1，且重启后仍生效（写入 sysctl.d）。若转发未开，终端把网关指到旁路由后，常见现象是旁路由能 ping 通，公网 ping 全挂。

回程问题更隐蔽：终端发包到旁路由，旁路由经 Clash 出 WAN，回程包若未经 NAT 回到主路由，主路由可能把包直接投给终端 MAC，却带着错误的源路径记录，导致部分协议通、部分不通。实践中在旁路由 WAN 或唯一出口接口上对「由内网网段发起、将离开旁路由」的流量做 MASQUERADE，往往能把这类「单向通」直接消掉。具体接口名在 OpenWrt 上多为 br-lan／eth0，在 Debian 系上可能是 ens18，请以 ip route 默认路由出口为准。

# Check IPv4 forwarding (1 = enabled)
sysctl net.ipv4.ip_forward

# Show default route and interface
ip route show default

五、nftables 与 iptables：透明转发的常见写法

新内核与发行版普遍迁移到 nftables，但网上仍有大量 iptables 文档；二者可以并存（通过 nft 兼容层），也可能互相覆盖。排障时请先执行 nft list ruleset 与 iptables -t nat -L -n -v，确认到底哪条链在生效，避免你改了一处、另一处旧规则仍在抢流量。

透明代理常见需求是：对来自 LAN 网段、目标为非内网地址的 TCP（有时含 UDP）做 REDIRECT 到 Clash 的 redir-port，或把流量交给 TUN。规则里务必排除旁路由自身与 Clash 上游节点 IP，否则会出现「规则把 Clash 自己的握手也重定向」的死循环。下面是一段示意性 nftables 片段，接口名与地址请替换为你的环境；勿直接复制到生产而不做 dry-run 验证。

table ip clash_transparent {
  chain prerouting {
    type nat hook prerouting priority dstnat; policy accept;
    # Replace LAN with your subnet; exclude router itself
    ip saddr 192.168.1.0/24 tcp dport != 53 redirect to :7892
  }
}

若你使用 tproxy 处理 UDP，还要配合策略路由与 mangle 链把标记的包送到正确的本地表；这比纯 TCP redir 更容易写错。遇到「TCP 网站能开、语音与游戏全挂」时，优先怀疑 UDP 未进代理 或 conntrack 状态异常，而不是先去调 Clash 策略组。

与主路由防火墙的交互

部分主路由会对「来自 LAN、源 IP 却是旁路由 NAT 之后地址」的回流包做额外检查。若你启用了 IPS／家长控制或硬件加速分流，尝试暂时关闭_OFFLOAD 或硬件 NAT做对照，看透明转发是否立刻恢复。此类问题与 Clash 版本几乎无关，却常年被误报为「内核不支持透明代理」。

六、TUN 模式与 DNS：别漏了劫持与 fake-ip

TUN 能把三层流量整体拉进用户态，理论上比单纯 redir 更「全局」；但在旁路由上开 TUN，要确保旁路由本机管理流量（SSH、DNS 查询 Clash 上游、NTP）不会被策略又塞回隧道里造成环路。常见做法是为主机自身地址加白名单，或使用策略路由让「本机 generated 流量」走 main 表。

DNS 劫持是旁路由场景下的高频坑：终端网关已经指向旁路由，但 DNS 仍是主路由或运营商 DNS，解析结果被劫持到「友好提示页」或错误 IP，表现为「能上 QQ、打不开网页」或「只有部分域名异常」。应在 DHCP 或终端上把 DNS 一并指向旁路由，或在旁路由上用 dnsmasq／AdGuard Home 统一转发到 Clash 的 DNS 入站端口。若 Clash 使用 fake-ip，还要保证局域网内没有设备绕过 Clash 去直连 fake-ip 段；细节见 fake-ip 与 DNS 排查。

IPv6 若未完全关闭，部分系统会优先走 v6 直连，让你误以为「透明代理失效」。可在测试阶段先在终端关闭 IPv6 或主路由上停发 RA，确认业务路径与预期一致后，再按需设计 v6 分流。

七、内网终端：真的在用旁路由吗

在手机与电脑上，用 ipconfig／ip route／设置页核对默认网关与 DNS 是否均为旁路由地址。安卓部分机型对「局域网静态 IP」有省电限制，会周期性忽略静态设置；苹果设备若同时安装描述文件与企业 VPN，也可能出现路由表优先级覆盖。

若只有浏览器走代理、游戏仍直连，先不要改 Clash 规则，先用 tracert 或 mtr 看第一跳是不是旁路由；若第一跳仍是主路由，说明分流在二层就没进旁路由。另外检查终端是否安装了「私人 DNS」（DoT）并指向公共解析，从而绕过你在旁路由上的劫持设计。

八、可复制核对清单

把下面清单打印或复制到笔记软件，在每次改拓扑或升级固件后重新打勾，可以显著减少「改了一处忘了另一处」的回归成本。

  • 终端默认网关与 DNS 是否都指向旁路由（或你刻意设计的解析路径）？
  • 主路由 DHCP 是否会覆盖终端的手动网关？
  • 旁路由 ip_forward 是否为 1，重启后是否仍生效？
  • nft／iptables 是否只有一套在生效，旧规则是否已清空？
  • 透明规则是否排除了 旁路由本机 与 节点 IP？
  • 是否需要 MASQUERADE 才能解决回程？
  • UDP 与 tproxy 是否一并配置？
  • IPv6 是否导致半直连？
  • Clash TUN 是否与本机管理流量环路？
现象 优先核对
网关改成旁路由后立刻全断 旁路由本机是否出网；ip_forward；是否误伤 LAN 的 NAT 规则
网页慢或解析奇怪 DNS 是否仍走运营商；fake-ip 与 fake-ip-filter；DoH／私人 DNS 是否绕过旁路由
只有 TCP 通、UDP 游戏全挂 是否仅做了 TCP redir；tproxy／conntrack；主路由硬件加速
间歇性恢复主路由网关 DHCP 租约；随机 MAC；路由器「终端管理」强制策略

更多名词与架构关系也可对照 本站文档总览，把「系统路由表」「策略路由」「Clash DNS 模块」分开理解，排障时就不容易混在一起。

九、小结

旁路由上跑 Clash 透明代理，本质是「在家庭局域网里插入一台会转发的网关设备」。上不了网时，优先怀疑网关与回程、其次内核转发与 nftables／iptables、再其次才是 TUN 与 DNS 劫持。把核对顺序固定下来，比反复重装 Clash 或换订阅更能稳定解决问题。

若你还需要在 PC 或手机上用图形客户端做对照实验，可从本站下载页获取适合你平台的 Clash 衍生版本，用同一套订阅在「客户端 TUN」与「旁路由透明」之间切换验证，更容易定位是线路问题还是网关转发问题。

→ 立即免费下载 Clash，开启流畅上网新体验