折腾完NAS和Docker后，把玩客云改成旁路由

折腾玩客云的时候，我和大多数人一样，先是幻想把它改成 NAS、再跑个 Docker、顺便挂一堆服务，结果折腾了一圈才发现，很多情况下，以它这颗老掉牙的 S805 和 1G 内存，性能是完全不够用的，每次有点什么需要性能的任务直接挂掉。真正最适合、也最稳的角色，其实就是旁路由。

后来我干脆把目标收缩到一件事：让玩客云专心做单臂路由，把去广告、分流、科学上网这些工作接过去，把拨号、Wi-Fi 覆盖都留给主路由，Docker各种服务则跑在 NAS上，物理拓扑完全不动：光猫 → 主路由 → 交换机 / AP，我只悄悄把一根网线插进了玩客云。

真正的变化在逻辑拓扑。我把需要特殊待遇的设备（比如自己的电脑和电视）的默认网关，从 192.168.1.1（主路由）改成了 192.168.1.2（玩客云）。这意味着：这些设备的所有出网流量，先交给玩客云，由它决定是直连还是走代理，处理完再转给主路由出国。理论上是这样，直到我第一次踩坑：能 ping 通，后台也能进，就是网页死活打不开。

问题出在非对称路由。一开始我没做源地址转换，终端 → 玩客云 → 主路由这一路没问题，但主路由看到包的源 IP 还是终端自己，于是回程直接发回终端，把玩客云绕过去了。请求走旁路由、响应不走，TCP 会话状态就乱了。

解决这个问题的关键只有一句话：让回程被迫经过玩客云。在 OpenWrt 后台「网络 → 防火墙 → 自定义规则」里，添加 NAT 规则：

iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE

此时所有从 eth0 丢出去的包，源 IP 都被伪装成玩客云自己的 IP（192.168.1.2）。主路由只认识这一个出口，回程必定先回到玩客云，内核再用 conntrack 还原成真实终端 IP，整个连接终于闭环。

在网络配置上，我给玩客云的 LAN 接口固定成 192.168.1.2，掩码 255.255.255.0，网关和 DNS 都指向主路由 192.168.1.1。这样它在局域网里就像一台有固定 IP 的 Linux 服务器，自己能上网、能更新、能拉包。我试过两套 DHCP 策略：一种是让主路由继续发地址，只给指定设备手动改网关指向玩客云，这种最稳；另一种是直接关掉主路由 DHCP，全由玩客云发地址，全屋透明走旁路由，但一旦玩客云死机，全家断网。

玩客云性能有限，我也顺手做了点轻量优化。在 OpenWrt 防火墙里勾上 Software Flow Offloading，让已经建立的连接走加速路径，CPU 占用可以下来一些。然后在 sysctl.conf 里把拥塞控制改为 BBR：

net.ipv4.tcp_congestion_control = bbr

对大延迟、高丢包的场景，带宽利用率的提升很直观，尤其是走代理的时候。再配上 AdGuard Home 做 DNS 去广告、简单的策略路由分流，对我这种家庭环境来说，玩客云已经算是物尽其用了。