前言
霞葉之前一直在用斐讯 N1 作旁路由（下文统一称旁路网关），虽然有各种小毛病，但忍忍也就过去了。最近添置了 NAS 后，需要使用 IPv6 远程访问 NAS，或者访问电脑。旁路网关在只是用 IPv4 的情况下基本没什么问题；在使用 IPv4 科学上网，而 IPv6 直连的有点小问题，忍忍也能自适应；而在使用 IPv6 科学上网的情况下，就会有很大的问题。
首先面临的就是 IPv6 网关的问题，IPv6 不像 IPv4 那样地址简单。在 IPv4 情况下，我们可以手动设置静态 IP、网关、DNS 等，反正都是局域网 IP，最终经过多层 NAT。而在 IPv6 下没有传统的局域网概念，IPv6 地址长度更长，并且前缀一般都是动态变化的，想要设置静态 IP，光是IP 地址这一栏都不知道怎么填写。更何况移动设备一般都不支持有状态的 IPv6 地址管理 (DHCPv6)，无法手动指定网关。
或者你可能想到，修改网关不方便，那就只修改 DNS 嘛。只要把设备 v4 和 v6 的 DNS 都指向旁路网关，旁路网关使用 Fake-IP 模式，解析境外 IPv6 域名时返回一个 Fake-IP 不就好了吗？想法是好的，但实践起来很麻烦。Windows 中确实有单独修改 IPv6 DNS 的设置，但这个设置是全局的，即使你的网络环境变更了 (例如连接了其他 WiFi)，IPv6 DNS 设置仍会保留，对于偶尔需要携带外出的笔记本不太友好。此外，大部分移动设备都是没法修改 IPv6 DNS 的，更有甚至会内置 IPv6 DNS，例如：安卓手机内置的 ipv6 DNS 会污染 opwrt 旁路由的 DNS，访问不了谷歌，你去搜关键词旁路由和IPv6会看到一堆问题。
要么放弃 IPv6，要么放弃旁路网关？还有一个几乎完美的旁路网关 IPv6 解决方案，关闭主路由的 IPv6 RA，开启旁路网关的 IPv6 RA；或者主路由和旁路网关都开启 RA，但是旁路网关的优先级更高。哇多么好的方案啊，但是如此便失去了“旁路”的意义，所有设备的 IPv6 流量都会由旁路网关处理。更大的问题是，不是所有的硬路由都提供了 IPv6 RA 的相关设置，无法修改主路由的 IPv6 RA 设置，此方案也就无从谈起。
旁路由迷信
所以我放弃了旁路由，使用旁路网关组网的动机何在呢？稳定，这大概是很多旁路网关用户的答案，但软路由作主路由不稳定吗。OpenWrt 并不是一个玩具系统，部分硬路由厂商的系统也是基于 OpenWrt 魔改的，不过是添加了些插件和定制 WebUI，依旧能稳定运行。很多说 OpenWrt 不稳定的，大概是喜欢乱折腾、乱刷第三方固件、乱装所谓的优化插件。
不影响家里其他人，这或许是排名第二的答案。诚然旁路网关对网络结构改动较小，可以随便折腾。但是软路由不论作主路由还是旁路网关，只要不折腾都不会出什么问题。能跑就不要动它，相信很多程序员的朋友都知道这句话的重量。一个好的路由器，在设置好之后，你不会在意它的存在。如果你天天想着去看看路由器的状态，想着去折腾它，那么它作为路由器是失败的。
软路由转发性能行，这也是经常听到的理由。ARM 软路由，RK3566 之类 CPU 跑千兆基本没什么问题，千兆以上的话 R68S 也不贵，再说国内又有多少大于千兆的宽带用户呢。如果你是要内网跑千兆以上，请选择交换机而不是路由器。而 x86 CPU 的话，基本上都是性能过剩的，j4125 + RTL8125B*4 跑 2.5G 都没什么问题，力大砖飞这块。小包转发性能的话，确实是软路由的弱项，但这同样是旁路网关的弱项，如果你对小包转发效率很敏感，就不要使用软路由了。
再说到软路由稳定性，为什么很多人喜欢折腾路由器呢？喜欢在路由器上装一堆插件、跑 docker 容器、甚至是跑 BT/PT 当 NAS 用。这类用户大概率用的 x86 软路由，看到性能过剩的 CPU 闲置着就觉得是浪费，总想着最大化榨干它的剩余性能，于是就开始了 All in One 的”不归路“。我很难评，具体可以去看我的所以我放弃了 All in One那篇文章。如果你追求稳定，那就让路由器回归路由器，只负责网络部分就好，别整什么乱七八糟的。
ImmortalWrt on NanoPi R3S
经过几天的比较，我最终花 230 重金购买了友善的 NanoPi R3S，作为我的主路由，原本的硬路由用作无线 AP。R3S 的硬件资料如下：
- CPU: Rockchip RK3566, Quad-core Cortex-A55
- RAM: 1GB/2GB LPDDR4X
- 网络：一个原生千兆以太网，与一个通过 PCIe 扩展的千兆以太网
- USB 口：一个 USB3.0 A 口，支持 5Gbps
- 存储:32GB eMMC
- 一个 MicroSD 接口，支持启动系统
- 供电：USB-C 5V/2A
- OS/Software: U-boot，Ubuntu-Core，Debian-Core，OpenMediaVault, OpenWrt
R3S 对比 R2S 升级了 CPU、网口、RAM 和 eMMC，我选择的是 2G+32G eMMC 版本，实际使用下来表现很好。为什么我没有选择 x86 设备呢？首先我这的网络不超过千兆，其次是功耗和体积。路由器作为 7*24 小时运行的设备，功耗当然是越低越好。由于是在宿舍使用，最好是被动散热。x86 设备在功耗、体积和散热上都没有优势、而 x86 的性能优势，在我看来又是过剩的，最终便选择了 R3S。这么一个精致小巧的、性能尚可的、功耗低没噪声的、金属外壳的小主机，谁能不爱呢？
至于系统，正如标题所写的，我选择了 ImmortalWrt。系统和硬件同样重要，光有好的硬件，没有好的系统支持也是一坨废铁。R3S 除了厂商自己提供的 FriendlyWRT 外，还有 OpenWrt 和 ImmortalWrt 的官方支持，这也是我选择 R3S 的重要原因。我更喜欢官方的纯净固件，而不是什么稀奇古怪的 iStore、Qwrt 之类的，或者更奇怪的什么高大全能固件。（顺带一提，我之前用的 N1 盒子没有官方支持的固件，也没法在线安装 kmod，想要做什么调整只能重新编译固件，使用起来很麻烦。）但我为什么没有选择原版的 OpenWrt 呢？因为在我看来 ImmortalWrt 有以下这些吸引我的点：
- 更好的本地化，针对国内网络环境优化了默认配置、本地化补丁（例如镜像源、网络优化等）
- 软件源收录了国内用户喜闻乐见的一些软件包
- 内核与功能更进更加积极
- 支持在线安装 kmod 模块
安装 OpenWrt 的过程中还是踩了些坑的，由于我没有 SD 卡，所以采用 USB 烧录的方式，这一部分厂商文档写得有点抽象。通过 USB 没法烧录 ImmortalWrt 固件，需要先烧录厂商的 FriendlyWRT，然后在 FriendlyWRT 中通过 Web 界面刷入 ImmortalWrt。首先需要从厂商网盘下载驱动和固件，安装驱动并解压固件压缩包，例如我下载的rk3566-usb-friendlywrt-24.10-20250811带有 usb 字样，不带 docker 的固件。接下来双击打开解压出来的固件文件夹中的RKDevTool，之后按住 R3S 上的 Mask 键，将 R3S 与电脑连接（最好不要用 C2C 线，也许会有奇怪的问题），直到指示灯亮起三秒后松开 Mask 键。
RKDevTool 应该会提示 “Found One MASKOM Device”，点击Advanced Function，在 Boot栏点击...按钮，选择固件文件夹中的MiniLoaderAll.bin文件，然后点击Download按钮，完成后点击EraseAll擦除 eMMC。接下来烧录 FriendlyWRT 固件，回到Download Image，点击Run按钮即可，固件烧写完成会自动重启。
设备启动后登录到 Web 后台，默认 IP 是192.168.2.1，默认 root 密码是password。选择系统->eMMC刷机助手，将下载好的 ImmortalWrt 固件上传即可。固件烧写过程中，SYS 指示灯会快闪，如果烧写完成了，SYS 灯会慢闪，同时 WAN 灯和 LAN 灯常亮。可以通过灯光状态判断烧写是否完成，完成后直接拔电源重插即可重启。
重启之后便是 ImmortalWrt 系统，如果你没有修改构建脚本，那么默认的信息如下：
Default login address: http://192.168.1.1 or http://immortalwrt.lan, username: root, password: none.
ImmortalWrt 为了兼顾小容量设备，默认的系统空间只有 300M，需要先对系统进行扩容。扩容的操作 ext4 文件系统和 squashfs 文件系统差别很大。我选择的是 squashfs，因为使用 overlay 技术能够支持恢复出厂设置功能。
终于连上网了
扩容完成之后，就可以开始联网了。我使用软路由作为主路由拨号，在网络接口中设置 WAN 口为 PPPoE 协议，输入宽带的账户密码即可。IPv6 设置我参考了OpenWrt IPv6 设置方案，但是我没有取消勾选本地 IPv6 DNS 服务器，经测试 IPv6 DNS 相关功能在我这都是正常的。
科学上网软件我选择了 OpenClash，因为我之前一直使用 Clash 系，分流功能强大，我自己也有一直维护的自用规则。OpenClash 的设置我参考的OpenClash 设置方案，这是一次偶然间看到的方案，初见时就感觉文档写得很好，实际配置使用之后感觉确实很好。该方案非常的简洁，只需要一个 OpenClash 和预装的 Dnsmasq。依赖 OpenClash 的绕过中国大陆功能来实现 DNS 分流，让国内网站不经过 Clash 内核，同时一定程度上避免了 DNS 泄漏。
但是这个方案也有一些小问题，由于使用的 Dnsmasq 转发模式，导致 OpenClash 中无法配置设备黑白名单功能。我的网络中有台 NAS，不需要进行全局的代理。我希望它的所有流量默认都不经过 OpenClash 内核处理，但是可以按需使用 OpenClash 提供的 http/socks5 代理功能。
方案中给出的解决办法很简单粗暴，添加一条 - SRC-IP-CIDR,10.0.0.x/32,DIRECT 直连规则。这样做的问题是，大量的 BT/PT 连接仍然会进入 Clash 内核处理，不仅影响了 P2P 的连接性，还给 Clash 内核带来不必要的连接维护负担。如果是 IPv6 的话，需要先设置设备为 eui64 的地址，然后添加 - SRC-IP-SUFFIX,::0d00:0721:cafe:0721/64,DIRECT 直连规则。此外，该规则还有一个问题，它会将来自该 IP 地址的所有连接都直连，无法实现我想要的按需代理。
然而我在 OpenClash 中发现，使用防火墙转发模式时，黑白名单中可以根据设备的 Mac 地址来设定。这样的话，无论设备的 IP 地址如何变化，无论是 eui64 地址还是隐私都是都无所谓。而遗憾的是，在使用 Dnsmasq 转发模式时是没有这个设定的，如果改成防火墙转发模式，OpenClash 的绕过中国大陆功能就没法使用。这是一个两难的抉择，但在我研究了 Bypass by Mac 的实现原理后，自己动手编写了防火墙规则，成功在 Dnsmasq 转发模式下实现了 Bypass by Mac。这部分受限于篇幅，这部分内容之后会单独写一篇文章讲解。
整个系统目前只安装了 OpenClash 一个第三方插件，没有 docker，没有其他乱七八糟的东西，以后也不会有。之后计划在安装一些跟网络强相关的软件，比如 zerotier/wireguard/tailscale 之一、DNSmasq 去广告插件、ddns-go 等。跟网络无关的软件没必要，也不适合安装在路由器上。
测试表现
对路由器进行了一些测试，供大家参考一下。首先是最让人关注的稳定性测试，这台 R3S 已经稳定运行了 10 多天，没出任何问题。我没有开启计划重启任务，之后会继续更新 Uptime（如果我能想得起这台软路由的话）。
然后是速度测试，测试使用的无线 AP 是水星 D191GM，AC1900 方案。测试环境是宿舍楼，WiFi 信号比较多，信号干扰比较严重，参考价值不是很大。不经过 Clash 内核处理的直连流量，在速度为 550M 左右时，CPU 负载基本上在 30% 以内，速度稳定性较高。
代理流量由于要经过 Clash 内核处理，对 CPU 的要求更高。在 Speedtest 测速，速度在 570M 左右时，CPU 占用率大概为 80%-90%，速度稳定性较高。600M 左右的科学上网速度大概是这只 CPU 的处理上限了，不过一般人应该没这么大的需求吧，真有大带宽科学上网需求的话，为什么不肉身呢 (雾)。
接下来是 IPv6 和 DNS 泄漏测试，主要关注 IPv6 测试即可，DNS 测试在我看来只是测着玩的。IPv6 科学上网速度并不慢，使用体验不错。有些境外网站或者服务器，只有 IPv6 地址，这时候 IPv6 科学上网就很有用。根据我的实际体验，在软路由环境下，IPv6 跑 BT/PT 等的 P2P 连接性也没有问题。使用软路由还能更精细的控制 IPv6 防火墙，而不像大多数硬路由只提供一个防火墙开关（有些甚至都无法关闭防火墙）。
DNS 泄漏实际上是防不胜防的，有时候就算是泄漏了你也不知道，普通人只要防 DNS 劫持即可。网上的所谓防 DNS 泄漏，只是给你设定了一些 DNS 规则，分流到境内/境外 DNS 服务器查询，然后给你几个 DNS 泄漏测试网站去测，此方案同样如此。谁也没法保证规则是全面的，即使你在测试网址中没有泄漏，某些国产 APP 如果给你塞一个冷门域名进去，使用此方案时就会走兜底的漏网之鱼规则，去查询境外 DNS。如果你对 DNS 泄漏非常敏感，可以把漏网之鱼全都直连，或者更进一步，使用 OpenClash 的“仅代理命中流量”功能，但这样的代价就是，冷门境外网站都会直连。
总而言之，我对这台 R3S 软路由还是很满意的，对比之前使用的 N1 旁路网关是一个很大的提升。如果一开始就怕不稳定而使用旁路网关，用起来变扭的还不如不使用软路由呢。