Sukka 写前端、网络和基础设施时，习惯先把边界和代价摊开。把「有催人跑的意思 —— 使用 PPPoE 半桥帮助 UniFi 网关突破性能瓶颈 | Sukka's Blog」整理成可落地的中文笔记：问题在哪、默认做法会踩什么坑、该怎么选。原站导航和广告已去掉。

楔子

英文版链接： https://arcbox.dev/blog/unifi-pppoe-half-bridge-acceleration 英文版标题： We fixed UniFi Slow PPPoE Performance by Offloading PPPoE to a Separate Device with Half-Bridge

绝大部分 UniFi 网关设备（不论是否是 Cloud Gateway 云网关），如 UDM Pro/SE/Pro Max、UXG Pro、EFG 等，其搭载的 CPU 都不支持 PPPoE 和 NAT 硬件加速。因此 UniFi 网关上使用 PPPoE 拨号的宽带时，性能会受到严重影响，无法达到 UniFi 标称的理论速度，这一点在 UniFi 社区中已经广为人知：

PPPoE

PPPoE（Point-to-Point Protocol over Ethernet）是一种将 PPP（点对点协议）帧封装在以太网帧中传输的网络协议，ISP 通过 PPPoE 实现宽带的认证和计费。虽然 PPPoE 会在以太网帧和 IP 包之间插入额外的 PPPoE 头部（6 字节）和 PPP 协议头部（2 字节），但这额外的 8 字节头部开销微不足道，丝毫不影响速率。真正导致 PPPoE 性能问题的根本原因是 PPPoE 协议本身的设计。

当使用 PPPoE 拨号的宽带时，路由器对发送的每一个数据包都需要添加 PPPoE 头部和封装、对接收的每一个数据包都需要剥离 PPPoE 头部和解封装。考虑到路由器需要处理的数据包数量，这通常需要大量的 CPU 资源、或者专门设计的硬件加速电路（ASIC）才能完成。

外置 PPPoE 半桥加速与公网 IP 透传

对于没有 PPPoE 硬件加速的支持路由器来说，更雪上加霜的是，几乎所有的 PPPoE 的处理都是单线程的 —— 即使路由器搭载了多核 CPU，PPPoE 的封装/解封装工作也往往只能由单个 CPU 核心来完成。虽然 pfSense 的 if_pppoe 实现了独立于网卡的 RSS（Receive Side Scaling）、Linux 内核内置的 pppoe 模块实现了 RPS/XPS，但是这都仅限于同时存在多个 PPPoE 会话的场景；对于单个 PPPoE 会话的场景（即单条宽带单次拨号），PPPoE 的处理仍然只能由单个 CPU 核心来完成。

直到本文写就（2026 年 4 月），UniFi 只有极少数网关设备（如采用联发科 Filogic 880 方案的 UCG-Fiber）在 SoC 中内置了 PPPoE 硬件加速支持；而且越高端的 UniFi 网关设备、采用的 OEM 方案（如 EFG 所使用的 Marvell OCTEON TX2 Infrastructure 系列、UDM Beast 和 EFG Core 所使用的 ARM N2 系列）越不可能内置 PPPoE 硬件加速。

使用 OpenWrt 实现 PPPoE 半桥

既然 UniFi 绝大部分网关设备采用的 OEM 方案大多不内置 PPPoE 硬件加速，那么不论 UniFi 怎么通过固件更新的方式，都无法从根本上解决 PPPoE 性能问题；更何况，由于 UniFi 技术团队众所周知的低下水平，他们甚至连软件层面的 PPPoE 性能优化都做不好。

即使在 2026 年，世界上仍然有大量 ISP（如加拿大 Bell、美国 AT&T Fiber、Xfinity，以及欧洲、亚洲和中国的绝大部分 ISP）仍在使用 PPPoE。如果 UniFi 网关本身无法提供足够的 PPPoE 性能，我们可以尝试将 PPPoE 拨号的任务交给一个专门的设备来处理，当这个设备通过 PPPoE 拨号得到一个 IP 地址（如公网 IP）后、将该 IP 从 PPPoE 虚拟网卡（如 ppp0）上剥离、然后将该 IP 通过 DHCP 的方式下发给下游的 UniFi 网关，这样 UniFi 网关可以通过 DHCP 获得一个公网 IP 地址、又不需要承担 PPPoE 拨号的 CPU 负载、从而专注于路由、IDS/IPS 和 NAT：

实战：香蕉派 BPI-R4 Pro 配置双路 2000 Mbps 宽带 PPPoE 半桥加速与公网 IP 透传

PPPoE session Hand out public IPv4 ISP <===============> [PPPoE Offloading via OpenWrt] ========================> [UniFi Gateway] Do not own public IPv4 Own public IPv4 from DHCP WAN 这一方案被称为 PPPoE 半桥（PPPoE Half-Bridge，也被称为 Zero IP Bridge）。在这一方案中，PPPoE 硬件加速设备（PPPoE Offload Device）进行 PPPoE 拨号，将 PPPoE 虚拟网卡（如 ppp0 ）上通过拨号得到的 IPv4 地址剥离、在物理网卡上创建一个 DHCP 服务器、将拨号得到的 IPv4 地址通过 DHCP 的方式下发给下游的路由器设备（如 UniFi 网关设备）。这样，PPPoE 硬件加速设备就专注于 PPPoE 拨号，而下游的 UniFi 网关设备既可以通过 DHCP 获取

事实上，部分 ISP 的 ONU/ONT 光猫已经内置这一方案了：部分型号光猫内置了「Advanced DMZ」、「IP Passthrough」、或「DMZplus」功能；开启该功能后，内置了 PPPoE 硬件加速的光猫负责 PPPoE 拨号、将拨号得到的公网 IPv4 通过 DHCP 下发给下游的路由器。但是，仍然有大部分 ISP 的 ONU/ONT 光猫不支持这一功能，此时就需要我们自己实现这一方案。

第 3 步：通过 LuCI 配置 Firewall Zone

在这里，我们使用 OpenWrt、通过 hotplug.d 来实现前述的 PPPoE 半桥加速方案，完整代码和配置案例可以在 arcboxlabs/pppoe-half-bridge GitHub 仓库 中找到。

arcboxlabs/pppoe-half-bridge 的核心代码由 99-half-bridge 和 start-half-bridge.sh 两个文件组成： 99-half-bridge 放置在 /etc/hotplug.d/iface/ 目录下、当 PPPoE 拨号成功、OpenWrt 创建形如 ppp0 的虚拟网卡时触发、并调用 start-half-bridge.sh 来完成 PPPoE 半桥的配置；而 stop-half-bridge.sh 则包含 PPPoE 半桥的核心实现，当 PPPoE 拨号完成时， start-half-bridge.sh 会依次执行下述操作：

值得单独记下的点

• https://www.reddit.com/r/Ubiquiti/comments/1dto912/story_time_investigating_slow_pppoe_speeds_on/
• https://forum.level1techs.com/t/unifi-and-bad-pppoe-speeds-any-solutions/224548
• https://community.ui.com/questions/ETA-on-bugfix-for-UDM-Pro-bad-PPPoE-performance/9119aa98-412f-41c7-9188-a30036c2e4c2
• https://www.reddit.com/r/Ubiquiti/comments/1buqkx1/max_speed_pppoe_on_udm_pro_with_10gbit_wan/
• https://www.reddit.com/r/Ubiquiti/comments/1hctxjk/efg_with_pppoe_uk_testing/
• UDM Pro/SE：使用 PPPoE 拨号时，测速结果普遍在 1200 Mbps ~ 1500 Mbps 左右
• UDM Pro Max：使用 PPPoE 拨号时，测速结果普遍在 1400 Mbps ~ 1800 Mbps 左右
• EFG：使用 PPPoE 拨号时，测速结果普遍在 1400 Mbps ~ 2400 Mbps 左右

落地时建议先做的 5 件事

1. 用自己的流量和设备测，不要只抄厂商推荐最小配置。
2. DNS、CDN、代理分流先画清 Fake IP 和 Real IP 的边界。
3. 前端性能看 CLS、白屏和重复渲染，而不是只看打包体积。
4. 基础设施变更走 Git，能复现、能回滚。
5. 结论写成可检查的清单：接口、超时、失败样本、回滚版本。

和智能体产品怎么接

龙虾PRO做 OpenClaw 落地时，网络、DNS 和前端性能笔记最有用的是「边界」：哪一层该加速、哪一层不该假装智能。数字员工调用外部能力前，先把超时和失败路径写死。

本文侧重全链路风控方法论。落地时请用自身业务单据做回放验证，不要把示例阈值直接当生产策略。 相关：风控体检 · 方案资源