1 前言

在上一篇文章中(参见：家庭数据中心系列 用 X-WRT 改造退役小主机：主路由的另类选择)，我拿一台闲置的 J2900 x86 小主机来折腾软路由，跑起来倒是没问题，性能绰绰有余，系统也稳定。但问题在于，它并不是我科学上网的主力设备，纯粹只是”技术尝试”而已——也就是说，这机器每天开着，却几乎没什么事干。而它的待机功耗却稳定在 20 多瓦，看着电表跳的时候，还是有点心在滴血的感觉。

如果这机器真是主路由，那耗这么点电也认了；可现在只是个支线角色，说闲置吧偶尔又会用，说在用吧每天的利用率又低，长期跑着总觉得不值当，然后按需开关机我又觉得别扭～。于是我开始琢磨，有没有一种设备，价格别太贵，体积小巧，功耗低到可以24小时开着都不心疼，同时还能跑得稳、玩得转，足够我自由折腾的？

在网上翻了一圈之后，我还真找到了这样一个合适的选择：NanoPi R2S/R2S Plus：

不到 300 元的价格，功耗也非常友好：就算开启一些额外服务，待机功耗也不过 4W ~ 6W，和 J2900 的 20W+的功耗相比，完全是两个量级。

小小一个盒子，却能撑起一个轻量但实用的网络环境，开着也完全不费心费电。而更重要的是，NanoPi 自家就为这类设备准备了专属固件 —— FriendlyWrt。这比我之前用的通用型系统X-WRT省心太多(当然，你要刷X-WRT也是可以的)，不需要各种适配，也不用折腾驱动和模块，开箱即用，体验非常完整。说实话，这才是真正让这台小设备变得”好用”的关键。

2 友善 NanoPi 系列路由器介绍

在折腾软路由的圈子里，友善 NanoPi 系列路由器可以说是出镜率相当高的一类设备。它是由友善电子(FriendlyElec)推出的一系列小型化、开源化的 ARM 平台设备，定位有点像树莓派，但又更侧重在网络转发、软路由这类场景。尤其在国内外的 OpenWrt / X-WRT 社区中，NanoPi 的多个型号都受到了高度支持和优化，软硬件生态相对成熟。这里简单列举一下这一系列主流型号的区别和特点，便于有需求的朋友做参考：

简单总结一下选购思路：

• 预算有限、轻度使用：R2S(或 R2S Plus)足够稳定省心；
• 希望稍微拓展一点能力，比如跑多个服务：R3S 是个平衡之选；
• 要跑多用户科学、高负载旁路、ZeroTier、广告过滤等：建议直上 R4S 或 R4SE；
• 带宽要求高、有多网口需求、未来准备搞透明代理或软路由聚合：那就考虑 R5S，不便宜但可以用得久。

经过一番考虑，我最终选择了 **R2S Plus，并不是因为它有多强，而是它刚好卡在一个很舒服的位置上。我平时对科学上网的性能要求其实不高，不刷视频、不看奈飞(奈飞电影数量太少了，码率还不高，对我来说就是鸡肋，远不如我自己的收藏～)，最多就是网页看看，Google搜搜，和ChatGPT 聊聊天，真正带宽上来不了几个 Mbps。所以像 R4S、R5S 那种性能怪物，对我来说反而是资源浪费，而且价格也上了一个台阶，很不划算。

相比之下，R2S Plus就显得轻巧而”刚刚好”——性能上应对主流家用网络毫无压力，功耗低、发热小，放角落里长时间运行也很安心。它采用 Type-C 接口供电，适配线材广泛，部署灵活、桌面也更清爽。最关键的是，其内置eMMC存储，可以从eMMC引导系统，我实在是对TF卡运行系统这种方式没什么信心(当然，不到300元的价格才是致命一击～)。

注：友善 NanoPi 系列路由器所有型号都提供TF卡插槽，这是为了支持从TF卡引导启动，毕竟内置eMMC的型号只是一部分。如果采用TF卡启动的方式，也可以像上一篇文章中讲的内容一样直接部署X-WRT，烧录X-WRT的方式和上一篇文章中烧录U盘是一样的，只是要记得选择”Generic EFI Boot”下的”X-WRT-25.04-b202506151427-armsr-armv8-generic-ext4-combined-efi.img.gz”这个镜像即可：

3 固件选择

3.1 概述

---

友善 NanoPi 系列路由器在固件选择上其实是非常灵活的，适合不同人群的使用需求：如果你不想折腾、希望开箱即用，那么直接使用官方提供的专属固件 —— FriendlyWrt 是最省心的选择。它本质上是基于 OpenWrt 定制的版本，结合了友善自己做的驱动适配、图形界面优化和常用插件整合，功能完整、界面友好，日常使用几乎不需要手动配置，适合想要”即插即用”的用户。

当然，如果你更倾向于可控性和定制性，或者已经比较熟悉 OpenWrt 体系，也完全可以刷其他社区版本的固件。比如 X-WRT 社区、immortalwrt 等都对 NanoPi 系列有很不错的支持。这些第三方固件在 OpenWrt 的基础上加入了更多扩展功能、插件平台或性能优化，有更大的自由度，也有更多的折腾空间。尤其是 R2S / R4S / R5S 这种用户基数大的型号，网上可以找到非常多的刷机教程和使用经验，适配也非常成熟。

简单来说，想稳就用 FriendlyWrt，想玩就上社区版本(TF卡引导)，而 NanoPi 系列恰好两头都能兼顾，这是它受欢迎的重要原因之一。

---

和其他通用性固件(比如X-WRT)不同的是，FriendlyWrt官方提供的固件是区分硬件型号的，不能混刷，所以需要先在官方wiki(https://wiki.friendlyelec.com/wiki/index.php/Main_Page)找到自己购买的对应的型号，比如我是R2S Plus，就点击进入自己型号：

然后点击进入”官方固件”：


最后会得到百度网盘和谷歌网盘的下载地址，根据自己的情况选择不同的方式，进入后只需要转存其中的”01_系统固件”目录即可：

在”01_系统固件”目录中有3个子目录：

3.2 固件介绍

3.2.1 01_SD卡固件

该目录下所有的固件都是用于”从SD卡(TF)卡启动运行“这种场景，而固件的命名说明了其用途(官方也为NanoPi 系列路由器提供了现成刷第三方固件的选择，比如Debian 12、Ubuntu 24.04、开源NAS openmediavault等)，详细描述如下：

---

FriendlyWrt 的完整版和精简版（minimal）最大的区别就在于是否预装了 Docker 环境，这一点和我之前在 X-WRT 固件命名规则中提到的”完整版”和”精简版”区别是一致的。如果你只是用来做旁路由或跑点基本服务，其实两者在基础功能上差别不大，系统体验也没太多不同。 需要注意的是，精简版在体积更小的同时，也精简了一些用户空间的常用工具（如部分命令行组件、网络工具等），虽然不会影响基本功能，但对于有一定动手需求或需要手动调试系统的用户来说，可能在使用中遇到工具缺失的情况，需额外通过 opkg 补装。

不过我个人并不太推荐在内存小于 2GB 的设备上运行 Docker：首先，Docker 本身对内存的占用并不低，即使只是运行一些小型容器，也容易让系统变得卡顿甚至出现 OOM（内存溢出）的情况。其次，在存储方面，如果你是跑在 TF 卡上，Docker 的读写操作会极大拖慢性能，甚至加速卡的损耗。

所以，如果你确实有 Docker 需求，我建议至少满足两个条件之一：

• 要么设备带有 eMMC 存储，随机 I/O 和稳定性相对好很多；

• 要么挂载一个 USB 3.0 的外置硬盘或 U 盘，可以显著改善读写瓶颈；

但这两个条件，其实已经超过了很多低端 NanoPi 型号的”定位”。所以对大多数入门用户来说，与其追求完整版，不如选个精简版，系统干净、运行轻快，反而更符合这类设备的最佳使用方式。如果真的非常需要docker功能，建议直接上高端型号。

---

3.2.2 02_SD卡刷机固件(SD-to-eMMC)

该目录下所有的固件都是用于”从SD卡(TF)启动后往eMMC存储中刷固件“这种场景，而固件的命名说明了其用途：

可以发现，与上一节中的命名相比，这里的文件名基本保持一致，唯一的区别是多了一个关键字——eflasher。那么，什么是 eflasher 呢？

简单来说，eflasher 是 FriendlyELEC 官方提供的一种镜像刷写机制，专门用于通过 SD 卡给设备写入系统。它的全称是 eMMC flasher，也就是”eMMC 烧录器”，用于将系统镜像从 SD 卡自动写入设备的内置 eMMC 存储。相比一般的系统镜像，eflasher 版本在启动后会运行一个图形化或命令行的刷机工具，引导用户进行安装操作。

这一机制主要用于量产设备或系统恢复场景，适合初次安装或将系统重置到出厂状态。文件名中带有 eflasher，也就意味着这个镜像是”用于刷机”的版本，而非”直接运行”的版本。

3.2.3 03_USB线刷固件(USB-to-eMMC)

该目录下所有的固件都是用于”从电脑通过USB线往eMMC存储中刷固件“这种场景，而固件的命名说明了其用途：

可以看到，和上一节SD卡刷机的镜像命名相比，只是从”eflasher”变成了”USB”，其他都是一样的。

4 固件刷写

4.1 刷写TF卡启动运行方式的固件

这部分内容我就不打算展开讲了，因为在上一篇关于 X-WRT 的文章中其实已经详细写过。简单来说，就是使用 Balena Etcher 之类的工具，把下载好的 .img 固件文件直接写入 TF 卡里，操作非常简单，无需额外设置。整个过程大多数人只需要点几下鼠标就能完成，没什么可复杂的，真要动手的朋友直接参考上一篇就好。

这里唯一想额外提醒的一点是：TF 卡容量不需要太大。我个人建议选 8G ~ 32G 之间的卡就足够了。系统镜像通常也就 200MB ~ 500MB，剩下的空间基本就是作为 overlay 用，哪怕你安装一些插件或跑个轻量服务也绰绰有余。反而是卡太大，会带来两个不必要的问题：

1. 烧录时间变长 —— 特别是一些写入慢的老卡，烧个 64G 镜像可能得等半天，体验并不好；

2. 容易浪费资源 —— 一张 64G、128G 的高速卡拿来跑路由器系统，有点杀鸡用牛刀了，还不如省下来做 NAS 缓存或媒体存储用。

另外提醒一点：TF 卡的品质比容量更重要，建议选择品牌靠谱、速度较快的(比如 SanDisk 的 Ultra 或更高系列)，能有效减少后期因为 I/O 性能差导致系统卡顿、服务延迟等问题。

4.2 刷写eMMC启动运行方式的固件

4.2.1 概述

eMMC 的刷写操作相比 TF 卡要稍微麻烦一些。虽然除了通过 USB OTG + Windows 烧录工具线刷之外，友善也提供了两种更方便的刷写方式：一是 使用 TF 卡启动后，通过 Web 页面里的”eMMC 刷机助手”进行刷写；二是TF卡烧录官方 eFlasher 镜像，然后使用TF卡引导后通过图形界面或 VNC 操作刷入 eMMC。这些方法整体流程其实并不复杂，对于稍有经验的用户来说操作也不算困难。

但无论是哪种方式，本质上都属于”写一次就别老动“的思路——不像 TF 卡那样，拔下来换一张、重刷一个系统都非常方便。eMMC 更像是一个”固定盘”，用来承载一个长期稳定运行的系统，而不是拿来反复折腾的。

更重要的是，一旦 eMMC 上的系统出问题，哪怕只是引导坏了，也没法靠它自己恢复，必须依赖外部设备介入：要么插入 TF 卡重新引导刷机，要么用 USB 数据线连上电脑进入 maskrom 模式操作，甚至在极端情况下还可能需要用串口调试。这些操作步骤既不友好、也不轻松，一旦踩坑，处理成本远比重刷一张 TF 卡要高得多。

因此我始终建议把 eMMC 当作一个”写入之后长期使用”的目标盘来对待，一旦刷好系统就尽量别动它；日常的测试、换系统、尝鲜等折腾操作，留给 TF 卡来承担就好，灵活、省心，还不容易翻车。

此外也要注意，并不是所有第三方固件都对 eMMC 启动做了完整适配，可能在启动方式、驱动支持、分区布局等方面存在差异，一旦刷错或适配不当，很容易出现启动失败、设备变砖等问题，影响使用体验。

因此，我更推荐在使用 eMMC 启动的场景下，优先选择官方提供的 FriendlyWrt 固件。它本质上是基于 OpenWrt 二次开发的定制版本，专门为 NanoPi 系列设备（特别是带 eMMC 的型号）优化而来，镜像结构合理、驱动支持完善、系统稳定成熟，刷入一次基本就可以安心长期使用，不仅省心，也更安全。

如果你不打算使用 FriendlyWrt，也可以考虑友善官网提供的其他几个官方支持固件，比如：

• buildroot：适合 DIY 能力较强的用户自行构建系统，可高度定制；
• debian-bookworm-core / ubuntu-noble-core：这两个是纯正的 Debian 和 Ubuntu 最小化核心系统，适合用作轻量服务器、旁路由、边缘计算网关等场景。相比 FriendlyWrt，这类系统没有 Web 管理界面，更偏向命令行操作，更灵活但也更”素”；
• friendlywrt-focal：是基于 Ubuntu 核心 + OpenWrt 上层的混合固件，兼顾 Ubuntu 软件生态和 OpenWrt 的网络管理界面，适合希望使用 apt 系统但又不想放弃 LuCI 的用户；
• openmediavault：这个主要用于将 NanoPi 跑成轻量 NAS，友善做了较完整的适配，界面和功能都相对完善，适合以存储为主的使用场景。

当然，如果你是熟悉 OpenWrt 架构、了解 eMMC 操作流程的进阶用户，刷入其他第三方固件也并非不可，只是要做好充分备份，接受踩坑的可能性，并对系统恢复要有一定准备。

4.2.2 从SD卡(TF卡)启动FriendlyWrt并在web页面上往eMMC中刷入固件(推荐)

这应该是最简单的给eMMC刷固件的方法：先用”01_SD卡固件”文件夹下的任意friendlywrt镜像制作一张TF卡启动卡，然后引导并正常运行friendlywrt后，登录GUI页面。在”系统”菜单下找到并运行”eMMC刷机助手”：

烧录完成，注意先弹出SD卡，设备会自动重起并从eMMC引导系统，千万不要直接拔电源，原因我后面讲：

注：我一开始其实还以为”eMMC 刷机助手”这个功能在新版里被砍掉了，因为我用的是 eMMC 启动的 FriendlyWrt，页面里怎么找都找不到；后来才发现，这个功能只在从 TF 卡启动时才会显示，因为系统认为此时你是”外部环境”启动，才允许你去操作 eMMC。设计上也合情合理，但确实挺容易让人误会的，像我就差点冤枉了它。

4.2.3 从SD卡(TF卡)启动使用eflasher往eMMC中刷入固件(SD-to-eMMC)

采用这种方式刷写 eMMC 固件，就需要借助友善官方提供的 eFlasher 机制。简单来说，就是将带有 “eflasher” 字样的固件镜像写入一张 SD 卡(TF 卡)，然后使用这张卡启动设备，此时系统会自动运行一个 VNC 服务器，用图形界面引导你完成刷写操作。

默认情况下，设备的 VNC 服务绑定在固定 IP 192.168.1.231 上，且默认不启用DHCP 功能 —— 也就是说，它不会自动给你电脑分配 IP 地址(这点确实比较反直觉，有点”坑”，我折腾了好一会，一直以为根本没成功启动～～～～)。

因此你需要手动设置电脑的有线网卡 IP 为 192.168.1.x 网段中的任意地址(比如 192.168.1.100)，子网掩码设置为 255.255.255.0 即可。此时 NanoPi 的 LAN 口和 WAN 口是桥接在一起的，随便插哪个口都能访问，不用太纠结。

然后，使用支持 VNC 的客户端(推荐 RealVNC 或 UltraVNC)连接 192.168.1.231:5900，就能看到图形化的 eFlasher 刷机界面。在界面中，你可以选择刷写目标系统到 eMMC，操作过程非常直观，基本都是点几下按钮的事，以TF卡刷写的固件为rk3328-eflasher-multiple-os-20250603-30g.img.gz 为例：

---

这个镜像在压缩包里大约 3GB 多，但解压后是一个约 30GB 的大镜像文件(因为包含多个系统)，所以实际烧录 TF 卡时，必须使用容量大于 32GB 的卡，否则烧录工具，如 Etcher会直接报错无法写入。至于为什么这么大，是因为里面包含了多个系统～)：

此外需要提醒一点：刷写过程会完全覆盖 eMMC 原有内容，所以建议在操作前先确认没什么重要数据。如果担心失误，也可以先通过图形界面里的”备份 eMMC 到 TF 卡”功能保存一下当前系统镜像，以防万一：

---

点击选择FriendlyWrt 24.10之后出现以下界面，保持所有选项默认不勾选的状态，然后直接点击右下角的”Next”：

---

关于 “start automatically at startup” 和 “disable overlay filesystem” 这两个选项，我要重点说明一下，尤其是后者，非常关键，很多人第一次刷机时容易忽略它。

• start automatically at startup：这个选项的作用是让系统在插入 TF 卡并启动后，自动进入刷写流程或上次的状态，跳过主界面交互。它并不会每次都重新刷写，而是更像”恢复到上一次停留的阶段”——比如你上次刷完停在”完成页面”，那下次插卡开机它就直接跳到那个页面。因此，如果你只是普通手动刷一次，不需要勾它；只有在批量刷写、无人值守等场景才建议开启。
• disable overlay filesystem：这个选项决定你刷进 eMMC 的系统在运行时是否启用 Overlay 文件系统。默认不勾选时，系统就会正常把 overlay 挂载到 eMMC，可持久保存所有配置修改（比如改密码、装插件），重启后也都能保留。而如果你勾选了这个选项，就会禁用 overlay，导致系统变为纯只读模式，配置改动都无法写入 eMMC，甚至有些固件(尤其是 minimal 精简版)会因为找不到可写挂载点直接启动失败。简单说：如果你想正式安装并长期使用这个系统，这个选项不要勾选，保持默认就对了。

---

然后就开始刷写eMMC，很快就完成，但是，注意左下角的提示：

必须先弹出 TF 卡，这时候设备会自动重启并从 eMMC 启动进入刷好的 FriendlyWrt 系统。如果你按照这个流程来，基本一切顺利，体验丝滑。

但是如果你图省事，刷完后直接拔掉电源，然后再把 TF 卡弹出来——嘿嘿，你就会知道什么叫怀疑人生了：无论你怎么开机，它都打死不肯从 eMMC 引导，哪怕你 TF 卡都拔掉了，设备就是卡在启动前的一片寂静中。

这是因为在 eFlasher 显示”刷写成功”之后，系统并没有立即完成所有写入操作。此时 eMMC 上的镜像数据可能仍有部分缓存留在内存中尚未同步（sync）到磁盘，而刷写工具本身也没有自动卸载 eMMC 分区或刷新启动配置。只有点击”Finish”或”Shutdown”按钮，或者弹出 TF 卡，系统才会执行完整的收尾流程，比如：

• 将 eMMC 的文件系统变更写入磁盘；
• 卸载挂载的分区；
• 清除刷写过程中的临时标记文件；
• 刷新 U-Boot 的启动参数或设置启动顺序；
• 执行 sync 保证数据写入完成；
• 最后安全重启或关机。

而你如果直接断电跳过这些步骤，就等于在系统还没来得及收尾的时候，硬生生把它掐断了。结果就是——eMMC 上的系统可能只写了一半，文件结构不完整、状态混乱，甚至连 boot 分区都没刷完，自然也就别指望它能顺利引导了。

这可真是血的教训——我就在这里整整卡了三个小时。问题其实并不复杂，但全怪自己上来就凭经验操作，既不看说明，也不读帮助文档，直接开干，结果被坑得死死的。经验主义，真的是技术人永远的老对手。

注：另外顺带一提，eFlasher 也支持将系统安装到外接的 M.2 或 USB 存储设备上。你可以在图形界面中选择”引导安装到 eMMC（或 TF 卡）”，同时将系统部分安装到 USB 硬盘或 M.2 SSD，就是在eflasher开始界面选择系统之后的下一步，以刷入ubuntu为例：

只是需要注意：R2S Plus 的 CPU 本身不支持从 USB 或 M.2 直接引导，所以不管系统装在哪，引导还是必须落在 eMMC 或 TF 卡上。这个玩法虽然看上去挺”进阶”，但对多数用户来说没什么必要，了解一下即可。

4.2.4 用电脑通过USB往eMMC中刷如固件(USB-to-eMMC)

这种通过 USB 将电脑识别为 USB-to-eMMC 设备，直接在 PC 上对 eMMC 进行刷写的方式，我并不太推荐。虽然听起来很高级，但实际操作过程既繁琐又容易出错，要进入 maskrom 模式、安装专用烧录工具，还可能涉及驱动兼容、镜像格式转换等问题，远远没有用 TF 卡启动 eFlasher 来得简单直接。

除非你特别熟悉这套流程，或者设备已经无法正常从 TF 卡启动、实在没有别的办法了，否则不如跳过这一折腾路线，省心又安全。

4.2.5 小总结

关于 eMMC 的刷写方式，其实可以按照复杂度和推荐程度大致分为三个层级：

• 最推荐的方式是使用 TF 卡启动进入 FriendlyWrt 后，通过 Web 管理界面中的”eMMC 刷机助手”来操作。只需要上传镜像、点击确认，几分钟就能完成刷写，整个过程几乎零学习成本，既直观又稳定，是我个人最推荐使用的方法。

• 如果你启动的不是 FriendlyWrt，或者希望在图形界面中多做些选择（比如安装到 USB 或 M.2 设备），可以考虑使用官方的 eFlasher 镜像，通过 TF 卡启动后进入内置的刷写界面，支持本地显示或远程 VNC 操作，功能更灵活，但流程略复杂一些。

• 至于通过 USB OTG 连接电脑使用烧录工具线刷 eMMC，虽然也是官方支持的方式，但整个流程较为繁琐，对新手不太友好，一旦操作不当还可能导致系统损坏或刷挂。因此我不太推荐这种方法，除非你熟悉流程，或前两种方式都不可行。

总之，TF 卡启动 + Web 刷写是目前最稳妥、最简单的主流方式；其余方式可以作为备选手段或紧急方案了解即可。

5 初始化

R2S Plus的LAN口默认启用了DHCP服务，接口IP为192.168.2.1，直接使用地址”http://192.168.2.1“登录管理，默认账号密码为root/password：

进入后可以看到默认的状态页：

默认是英文，要改为中文在”System”-“system”-“Language and Style”里修改：

在”系统”-“管理权”-“路由器密码”里修改路由器密码：

和X-WRT不同的是，默认SSH功能都是开放的，不用手动开启：

在”网络”-“接口”里可以分别设置lan口和wan口的连接方式和地址获取方式(注意，wan口是eth0，lan口是eth1)：

至此，FriendlyWrt的初始化工作就完成了。

6 其他

其他的选项OpenWrt系的都差不多，唯一可以多说一嘴的是FriendlyWrt在”服务”菜单里默认提供的应用：

还有比较实用的，其他缺少的就在”系统”-“软件包”里：

或者在命令行下用opkg命令自行安装即可：

其他一些操作OpenWrt 系的都差不多，我就不多说了。

7 小贴士1：解决OpenClash安装后不能正常工作的问题

有一点很值得说一下，在 FriendlyWRT 中安装 OpenClash时，有时候会莫名其妙把系统原本正常的 curl 弄坏，导致命令行执行 curl 时报出诸如”symbol not found”的错误，同时导致OpenClash不能正常工作。

这个问题的本质是：OpenClash 在某些版本中，安装过程可能会拉取一套 与当前系统构建环境不完全兼容的依赖包(比如 libcurl、libmbedtls 等)，这些库一旦被错误覆盖，就会导致 curl 无法正确加载所需的动态符号，出现 relocation 报错。

更麻烦的是，如果你是通过 OpenClash 的 Web UI 进行”依赖修复”或”更新核心”等操作，这种问题反而更容易被触发。所以我个人建议，对于这类工具，最好是自己手动下载 .ipk 安装包进行部署，避免插件自动拉错依赖。如果一旦出现 curl 报错，通常需要卸载相关组件并强制清理干净，再重新用 opkg 安装回正确版本才能恢复，解决方法如下。

第一步，强制移除 curl 和关联库(会一并卸掉 OpenClash)：

opkg remove curl libcurl4 libmbedtls libmbedx509 libmbedcrypto --force-removal-of-dependent-packages

这条命令的效果是：
– 把 curl 和它依赖的动态库都卸载；
– 顺带移除依赖 curl 的 luci-app-openclash（不会影响别的系统组件）；
– 清理出一个干净的 curl 空间。

第二步，重新装回一整套健康的 curl：

opkg update
opkg install curl

此时curl 会自动拉回它真正匹配的 libcurl4、libmbedtls 等依赖，这时候再执行：

curl https://www.baidu.com

如果这条命令成功，说明你系统层的网络能力(以及 OpenClash 所依赖的最基础工具)已经修复完毕。

第三步，重新安装OpenClash：

opkg install /tmp/luci-app-openclash*_all.ipk

这个问题差点把我搞得怀疑人生，让我在开始找不到原因时又无缘无故刷了好几次eMMC～。

如果不想这么重新弄一次，那么理论上应该先安装好所有依赖，这样就锁定住系统自己的 curl 库，不会让 OpenClash 乱替换。

第一步，先把系统所有基础依赖装好：

opkg update
opkg install curl libcurl4 libmbedtls ipset ip-full iptables iptables-mod-tproxy kmod-tun kmod-inet-diag

如果需要用TUN(需要 Clash.Meta / Premium)：

opkg install kmod-tun ip-tiny iptables-mod-tproxy

这样你 FriendlyWrt 上所有系统层 curl / wget 所需要的依赖都已经是官方库，不会再被 OpenClash 覆盖。

第二步，下载并安装OpenClash(请自行修改为自己需要的openclash版本)：

cd /tmp
wget https://github.com/vernesong/OpenClash/releases/download/v0.46.086/luci-app-openclash_0.46.086_all.ipk
opkg install ./luci-app-openclash_0.46.086_all.ipk

然后去 LuCI 启动 OpenClash然后即可在线下载核心。

8 小贴士2：某些特殊场景下NAT不生效的问题

这个问题是真把我坑惨了…..我的主路由是爱快，网络拓扑看上去很合理：爱快的 WAN2 接到 FriendlyWrt 的 LAN（eth1），然后 FriendlyWrt 的 WAN（eth0）再回接到爱快 LAN2。这样就能在爱快做端口分流，把部分流量交给 FriendlyWrt 来科学，示意图如下：

可实际操作时，无论我刷多少遍 FriendlyWrt（精简版、完整版都试过），OpenClash 都始终无法正常工作。Clash 能顺利拉取配置、fake-ip 模式一切看似正常，日志里毫无报错，但就是 HTTP/HTTPS 全都超时。

排查了好几天，最后才发现问题根本不在我的拓扑或 Clash 配置，而在于 FriendlyWrt 的 NAT 根本没生效。它的 /etc/config/firewall 虽然写了 option masq ‘1’（IP 动态伪装），但并没有正确下发到 nftables 里的 masquerade 规则，导致这种架构下从 WAN 出口的流量都没有被做 SNAT，直接把「内网源 IP」原样丢出去。

这种架构下 FriendlyWrt 收到的流量，虽然物理上都还是从 LAN（eth1/br-lan）接口进来的，源 IP 看起来也是 172.17.100.x，但由于在爱快已经做过一次 NAT，FriendlyWrt 的流量状态追踪就可能无法命中对应的 NAT 规则链，导致 masquerade 根本不执行。

相比之下，如果让内网设备直接把默认网关指向 FriendlyWrt 的 LAN（eth1），就能 100% 触发 LAN → WAN 的正常 NAT 流程，masquerade 必定生效。

所以这个坑特别隐蔽，看起来和我的网络规划毫无关系，实际上却是由于系统默认没有把 /etc/config/firewall 里的伪装选项转换成有效的 nft 规则，才导致流量无法做 SNAT。要不是我一步步剥离 OpenClash 验证最小链路，单独测试 NAT，恐怕还会继续把时间浪费在 fake-ip、redir-host 这些上层配置上。

如果要解决这种特殊场景下的NAT不生效问题，运行以下命令可以立即生效(我这里用eth0是因为R2S Plus刷FriendlyWrt时，eth0是wan口)：

nft add table ip nat 2>/dev/null || true
nft add chain ip nat prerouting '{ type nat hook prerouting priority 0; }' 2>/dev/null || true
nft add chain ip nat postrouting '{ type nat hook postrouting priority 100; }' 2>/dev/null || true
nft add rule ip nat postrouting oifname "eth0" masquerade

如果要永久生效，如下操作后重启一下即可：

cat >> /etc/firewall.user <<'EOF'
nft add table ip nat 2>/dev/null || true
nft add chain ip nat prerouting '{ type nat hook prerouting priority 0; }' 2>/dev/null || true
nft add chain ip nat postrouting '{ type nat hook postrouting priority 100; }' 2>/dev/null || true
nft add rule ip nat postrouting oifname "eth0" masquerade
EOF

注：这种问题在华硕那类成熟的商用路由器上不会出现，人家固件早就把各种 NAT 场景都照顾得妥妥当当，默认策略也严丝合缝。但在 OpenWrt 系的软路由上就完全不好说 —— 不同发行版、不同防火墙方案（iptables / nftables），甚至不同的配置向导，都会影响 NAT 规则的生成，有时候就差几条 masquerade，问题就会直接爆出来，坑得你措手不及。不过只要你不是在搞什么多重 NAT、回环、或者极限透明代理实验，正常家庭场景一般也用不到这么多魔改，自然也就不会踩到这种坑。

9 后话

总的来说，折腾友善 NanoPi 系列软路由要做好心理准备，它并不是那种插上电就能用、随便改都稳的成品路由器。你需要花点时间了解它的刷机方式、分区布局以及各种小坑(比如刷 eMMC 的 overlay、选择适合自己引导方式等等）。

但也正因如此，它其实非常适合喜欢动手、喜欢把网络完全攥在自己手里的用户。毕竟，花几百块就能获得一个低功耗、小巧、性能可观(比常见路由器 MTK 芯片强多了)的迷你网关，还能装上各种 OpenWrt 衍生系统、自定义插件、科学上网分流或者干脆是其他系统(debian、ubuntu、openmediavault) —— 说实话，这种自由度和可玩性，是绝大多数商用路由永远给不了的。

所以，如果你抱着 DIY 的心态，把它当成一个小服务器、小网关去玩，那么你一定会乐在其中；但如果你只是想要「买回来就一劳永逸的家用路由器」，那么建议你直接选华硕、网件、或者更高端的 All in One 设备，免得后面被各种稀奇古怪的小问题折腾得心态爆炸～～。