这应该不是微信干的，而是打包者的操作

这种上下文我来打包可能会尝试用 bwrap 伪装

动作幅度太大的会晕，比如 APEX 和 Titan Fall

这种情况是典型的非对称路由？
这肯定不是好事情，建议能解决非对称路由的问题就先解决它，比如导入一个更合理的路由表解决出入路径不一致的问题
确实在 wireguard 内部维护一个 saddr 状态也是一个办法，但是上游肯定不会喜欢，因为 wireguard 没必要为了非对称路由擦屁股

先看看你的源里面有没有 systemd-resolved ？这东西就自带 DoT 客户端

我之前遇到过类似的问题，下载 IO 高负债就会崩溃，一开始也怀疑是内存问题，但是因为内存是 ECC 内存&kdump 没看到 EDAC 报错，并且错误是在 iommu 的驱动上的 BUG()，更新了几个内核版本之后就消失了

先打开 kdump 看看更完整的崩溃的 dmesg ？不过考虑到 kernel panic 可能性也就硬件故障和驱动 bug 两种可能性了

建议在路由器上做禁止入站，因为在 NAS 上设置这类规则比较麻烦
原因是运营商分配的前缀会变，要是想要在设备上设置只允许局域网的规则的话，要么想办法每次拿到前缀变了就更新，要么配置防火墙去匹配 fib/nexthop

草，goodplayer 要能打败同学的版本？卷起来了
之前本科程序设计的五子棋也这样，要带 pve,带禁手，要班内互相卷。最后成品程序都群魔乱舞

不过我又看了下，gcc 遇到 alloca 或者 vla 就会避免内联 https://gcc.gnu.org/onlinedocs/gcc/Inline.html

@senninha 所以说要是一个函数用了 alloca 然后被内联到了循环体里面就会出事

WireGuard 不是为了反审查而提出的协议（它解决的问题是简化组网），要防识别建议套一层 udp2raw 之类的混淆

不过我个人一直使用 WireGuard 过墙跑大流量没有被干掉，估计我没有遇到类似的针对性识别？

主要是 7zip 整个就不需要特权就能运行，整个漏洞给我感觉更像是 Windows 上的 hh.exe 有类似 UNIX 上的 setuid 的东西，然后 7zip 自带的帮助文件导致 hh.exe 的特权泄漏了？

然后整个问题最令人不解的就是为什么 hh.exe 会有特权

@AllenHua
我之前会卡住是因为暂时只能用顺序读写没网速快的盘导致的，后来换了 HC320/HC550 （顺序读写 200M+）也就没卡了

其实我怀疑 BT 的读写没那么顺序导致了卡住，看看 iowait 应该能看出来端倪

我猜就是 io 卡住了导致卡住了别的线程
因为 qbittorrent-nox 高负载失去响应的问题我甚至在 32C+128G 内存的服务器上遇见过，显然不会因为是 CPU 瓶颈 /内存瓶颈

仔细看了下图的线和点的关系也不那么像是拉格朗日插值，没准是正交多项式空间的傅立叶？

图应该是拉格朗日插值法，以及阶数过高的插值带来龙格现象？

> 我记得软路由要搞 2 个 Virtual Switch ，作为 WAN 、LAN 的，还要装 LEDE

不要这么机械，软路由也不一定需要 Virtual Switch, 装 LEDE 更不需要，只要设置了两个 interface 之间的转发规则的设备自然就成为了软路由。整 Virtual Switch 的目的只是让多个网口都能“连在一起”

Virtual Switch 是在模拟交换机，交换机（一般意义上）工作在二层，只是按照 MAC 地址转发包。在 NAS 上搞一个虚拟交换机，把电脑连到 NAS 上和用一个物理交换机是等价的。

不过虚拟交换机每次转发都要经过一次内核的收包发包流程，开销相当大，除非你的 CPU 很强劲不要指望在高 pps 的情况下性能能和物理交换机比较

prefix=~/.local