有没有跑tun不卡的性价比openwrt路由器

我已经登录到你的路由器（[email protected]）采集并审查了底层系统与内核配置。

---

一、 核心结论

结论：当前系统环境下【无法直接运行】dae 和 daed。

原因分析：你的路由器硬件性能（MediaTek MT7981 / ARM64）其实完全足够，但目前安装的官方出厂固件内核版本过老（Linux 5.4），且缺失 eBPF 核心特性支持（缺少 BTF 与 bpf_sk_assign 支持），无法满足 dae 的硬性门槛。

---

二、 路由器现场检测详细报告

检测维度 |
现场实测数据 |
dae / daed 官方要求 |
判定结果 |

设备型号 |
GL.iNet GL-MT3000 (Beryl AX) |
- |
- |

CPU 架构 |
MediaTek MT7981B (双核 A53, aarch64) |
支持 arm64 / aarch64 |
✅ 完美支持 |

系统固件 |
OpenWrt 21.02-SNAPSHOT (GL.iNet 官方定制) |
建议 OpenWrt 23.05+ 或现代 Linux 发行版 |
⚠️ 版本陈旧 |

内核版本 |
Linux 5.4.211 |
必须要求 Linux ≥ 5.17 (最低需 ≥ 5.8) |
❌ 致命不满足 |

内核 BTF 支持 |
/sys/kernel/btf/vmlinux 不存在<br>（未编译 CONFIG_DEBUG_INFO_BTF） |
必须开启 BTF (用于 eBPF CO-RE 特性) |
❌ 致命不满足 |

内存 (RAM) |
总计 512 MB，当前可用约 180 MB |
启动加载 eBPF 需约 100~120 MB 空闲内存 |
⚠️ 偏紧（勉强够用） |

存储空间 (Flash) |
/overlay 剩余可用空间 74.9 MB |
daed (含 Web 前端+守护进程) 需约 30~50 MB |
⚠️ 剩余空间偏紧张 |

---

三、 为什么当前系统会被卡死？（技术原因）

- 缺少关键 eBPF 内核函数（bpf_sk_assign）：

- dae 实现零拷贝、绕过 TUN 虚拟网卡的核心是调用内核的 bpf_sk_assign() 函数（在网卡 TC 阶段直接将数据包绑定到代理 Socket）。

- 该函数在 Linux 内核流量控制（TC / cls_act）下的支持是在 Linux 5.8 才正式合入内核主线的。你的路由器内核为 5.4.211，底层根本没有这个能力。

- 缺少内核 BTF 类型定义支持：

- dae 采用现代 eBPF 的 CO-RE（Compile Once, Run Everywhere）机制，需要读取内核导出的 /sys/kernel/btf/vmlinux。

- 实测你的路由器不仅没有此文件，提取的内核编译配置中也未开启 CONFIG_DEBUG_INFO_BTF，dae 启动加载字节码时会直接报错闪退。

---

四、 后续建议与解决方案

如果你确实非常想体验 dae / daed 的高性能 eBPF 代理：

方案 A：刷入高版本内核的第三方固件（彻底支持 dae）

- GL-MT3000（Filogic 820）社区支持度非常高，可以刷入社区的 ImmortalWrt 23.05 / 24.10 或 原生 OpenWrt 23.05+。

- 这些新固件基于 Linux 5.15 / 6.1 / 6.6 内核，且官方内核默认开启了 eBPF 和 BTF 支持，刷入后即可直接安装运行 dae / daed。

- 注：刷第三方固件会失去 GL.iNet 原厂的特色旅游路由 Web 界面和部分物理按键快捷绑定。

方案 B：保持当前原厂固件（推荐，性价比最高）

- 如果你不想折腾刷机、仍希望保留原厂固件的稳定性和易用性：

- 继续使用 OpenClash，并将 TUN 堆栈配置为 System（系统栈）。

- 原因：MT7981B 的双核 A53 在路由器芯片中算力属于中上水平，跑 OpenClash 的 System 栈（TCP 由内核处理，UDP 由轻量模块拼接）时，日常跑满几百兆甚至千兆宽带的 CPU 负载并不高，完全够用，不需要冒着刷机变砖或失去原厂功能的风险强行上 dae。

^-^

mips栈自己换个新内核然后去zashboard里面不是能改吗 ^-^