路由器代理会在代理应用前置一个方案，比如 ss_tproxy 与 iptables 透明代理分流
硬路由追求的就是一个转发，但是套一个分流就会产生一个鱼跟熊掌的问题：流量只要经过了 sstproxy 处理，代理部分先不谈，哪怕是直连，相当于直接进了内核，理论上说，流量就变成软路由器方式。要是这么想这个事，路由器再好，还不如直接上 x86 软路由，性能差距摆在那
当然这不是分流的问题，准确来说是防火墙规则与芯片处理的问题。厂商也不是不知道这事，所以普遍增加了个 npu 协调处理这事。当人家厂商是给预设功能设计的，比如防火墙、qos 、流量统计……npu 能帮上忙那属于是定制优化的。当咱们去主动用 sstproxy ，这优化能帮上多少忙真不好说。毕竟硬件驱动都是闭源的，到底怎么处理的属于厂商的黑箱操作，不排除流量不走芯片直接进内核了，绕过了这部分优化。路由器分流需求属于用户 diy 需求，并不在产品功能设计需求之内
目前所知最好的方案是 mt7621 的 padavan：如果 padavan 开启硬加速，那防火墙、qos 、流量统计……这些功能都会失效。所有流量经过 sstproxy 后，该硬件加速加速，除非真用了 iptables ，把流量标记转发了。也就是硬件上天然尽可能忽视各种设置，细看这不像是刻意设计，更像 bug：硬件功能凌驾在系统功能之上了。但是这对分流可太友好了。而现有的芯片，不是提升 cpu 就是 npu 优化，属于尽可能在防火墙处理与芯片处理上找个平衡，功能逻辑越来越复杂，只从分流角度来看就越来越不可控
硬路由追求的就是一个转发，但是套一个分流就会产生一个鱼跟熊掌的问题：流量只要经过了 sstproxy 处理，代理部分先不谈，哪怕是直连，相当于直接进了内核，理论上说，流量就变成软路由器方式。要是这么想这个事，路由器再好，还不如直接上 x86 软路由，性能差距摆在那
当然这不是分流的问题，准确来说是防火墙规则与芯片处理的问题。厂商也不是不知道这事，所以普遍增加了个 npu 协调处理这事。当人家厂商是给预设功能设计的，比如防火墙、qos 、流量统计……npu 能帮上忙那属于是定制优化的。当咱们去主动用 sstproxy ，这优化能帮上多少忙真不好说。毕竟硬件驱动都是闭源的，到底怎么处理的属于厂商的黑箱操作，不排除流量不走芯片直接进内核了，绕过了这部分优化。路由器分流需求属于用户 diy 需求，并不在产品功能设计需求之内
目前所知最好的方案是 mt7621 的 padavan：如果 padavan 开启硬加速，那防火墙、qos 、流量统计……这些功能都会失效。所有流量经过 sstproxy 后，该硬件加速加速，除非真用了 iptables ，把流量标记转发了。也就是硬件上天然尽可能忽视各种设置，细看这不像是刻意设计，更像 bug：硬件功能凌驾在系统功能之上了。但是这对分流可太友好了。而现有的芯片，不是提升 cpu 就是 npu 优化，属于尽可能在防火墙处理与芯片处理上找个平衡，功能逻辑越来越复杂，只从分流角度来看就越来越不可控
Select Language