路由器代理 NanoCloud 最佳实践：全屋分流与误操作规避
将订阅挂载到路由器上，是白羊座和射手座之间最核心的差异来源。全屋只需共享一份订阅，面板上的设备并发数便只增加 1 个，家里的手机、平板也无需逐台导入。然而，这种便利的代价是一旦路由规则写错，就会导致全屋设备集体“翻车”。
一、 主路由与旁路由的选择
- 旁路由更安全：直接替换主路由网关虽然省事，但一旦配置失误全屋会立刻断网。建议优先使用旁路由架构，让需要代理的设备手动或通过 DHCP 指向旁路由，而国内普通设备继续走光猫，更适合用来测试 NanoCloud。
- 客户端与更新：在 OpenWrt 上通常使用 Passwall 或 Mihomo 客户端。请注意，电脑上手动更新订阅并不等同于路由端会自动更新，必须在路由管理后台独立进行订阅维护。
- 严禁 BT 下载：路由器环境下最容易触碰红线的是 P2P 下载。如果局域网内的下载器默认网关指向了旁路由，BT 流量便会全部走代理。平台一旦检测到违规，封号通知不会提示具体是哪台内网机器发起的。
二、 智能电视、网盘与 DNS 陷阱
- 电视与网盘限流：当智能电视或 NAS 全局走旁路由时，系统大体积更新包会按倍率疯狂消耗流量。正确的做法是：将电视的代理范围严格收窄至视频 App，其余流量直连；网盘同步同理。如果家里上行带宽被网盘占满，远程办公会议会首先卡死，这并非节点晚高峰，而是路由器未做好 QoS 限速。
- DNS 配置防回环：若在路由上改错 DNS，会导致国内网站也被迫绕出国门。建议前几天严格使用订阅自带的默认规则，确认国内直连正常后再逐步添加自定义域名。如果修改后突然无法打开路由后台，多半是将网关自己的管理地址也送入了代理，此时需要准备一根网线直连旁路由后台进行救援。
三、 旁路由失败时的应急退路
- 分步回退：当全屋断网时，切勿连续盲目保存新规则。第一时间将设备网关改回光猫，确认国内网络恢复正常后，再慢慢排查旁路由。确保用手机移动流量能够重新进入旁路由管理页，才有资格继续修改配置。
- 彻底卸载下载器：局域网内的下载器必须彻底卸载或更换网卡绑定，仅关闭开机启动项是没用的，系统更新后它会自动复活。
- 稳定一周再卸手机客户端：不要在刚搭好的第一天就卸载手机或电脑上的客户端。必须让路由经历至少一周的考验（期间包含重启过、更新过订阅、黄金档顺利看过视频），才算真正稳定。在此之前，手机客户端就是路由崩掉时的唯一救命稻草。
四、 最佳实践：渐进式部署与设备核对
- 第一天只跑默认规则：海外与国内网页双向正常后，再接入电视（仅放行视频 App，更新包直连）。客人设备默认走直连，管理地址排除在代理之外。
- 核对在线设备数：旁路由的核心目的之一是“省名额”。如果搭建完成后，面板显示的在线设备数并没有下降，说明你原先的手机、电脑客户端依然连着，旁路由并没有真正帮你省下名额。