zfl9
也许是 aarch64 会这样，我在 aarch64 上出现的。（没有找到稳定的复现方法）
刚才我又复现了，看了下，只是vss虚拟内存大小在增长(而且以2的指数级增长，估计是某个realloc出问题了，明天我再看看代码)，rss实际使用的物理内存没变(一直保持200kb左右)。 2025/3/26 更新：自上次复现后，持续运行了半个多月，暂未复现。上次复现时打印了一些内存分配的log，但还没时间深入研究，后面抽空我再看看。
提示很明显了，安装缺失的 iptables 内核模块。Google 下有解决方案的。
另外，在使用 iptables-nft 后端时，不要执行任何 nft 指令（正如给出的警告所说）。 像往常一样，使用 iptables、ip6tables 即可，内核中将自动使用 nftables 作为后端。
另外，执行 ss-tproxy restart 时是否存在任何报错？
先排除 nft 规则的影响，在 ss-tproxy start 之前，nft list ruleset 最好是空的。
pre_start 里面执行 `nft flush ruleset` ?
nft list ruleset 看看全部规则？ --- 建议使用 raw 表的 -j TRACE 看日志，比手动加 LOG 更方便一些。 --- > log 中，没有任何 matched 的 log，很奇怪。请问可能是什么原因呢？ 确实很奇怪，中间也没有其他规则干扰，难道是 ipv6 的 connmark 模块有问题？
你测试的 本机代理 还是 局域网代理 ? 我看 ipv4 已经搞定了（本机、局域网） ipv6 要不先测下本机代理？ 先以 tcp 2001:4860:4860::8888 为测试用例，避免 log 过多。 ```shell ip6tables -t raw -I OUTPUT -p tcp -d 2001:4860:4860::8888 -j TRACE ip6tables -t...
好像是哈，切换下 group 身份，`sg proxy_dns 'dig +tcp @2001:4860:4860::8888 google.com'`，跳过 chinadns-ng。