从发现问题、找到问题、修复、测试、到向上游提交修复代码，共将近180天。

2023年第一次软路由代理插件就是Passwall，因此熟悉程度和喜爱超过其他任何的代理插件。
但从错误的旁路组网改为正确、简单的主路由组网没多长时间，便让我遇到了一个大问题，让我一度怀疑“主路由作为唯一路由”是否正确。

具体可见图片中所描述的现象，没有日志也没有任何征兆，突然就死机、且直连流量只能通一点点。

开启了漫长的排查之路，耗时将近两个月，期间试过OpenClash/Nikki插件但无一例外觉得不适合我自己，具体原因不展开说，总的来说是不喜欢全部FakeIP和自建节点支持不友好，导致我继续使用Passwall这款插件。

直到有人告诉我可能是IPV6之类的问题，我便恍然大悟！果然是厉害的大佬，一眼点破问题关键。
随即开始我未曾设想的拉取源码开始找问题。我的代码技巧很烂，当时又只有慢的要死、智商不如豆包的gemini CLI，虽然勉强解决了问题，但代码被改的一团糟。

我决定学一些额外的知识，配合上CodeX重新找到问题，并只修复必要的部分。
在5月份，我在路由器上成功的运行了含有修复的Passwall插件，并运行到现在，仍未出现任何死机现象。

病因

update_wan_sets 先 nft flush set psw_wan6 再写回，中间 WAN6_IP_RETURN 匹配不到地址 → 发往本机 IPv6 的包落进 TProxy → 自环

这是一个概率问题，如果开启定时重启+机场定时拉取订阅+WAN口地址频繁变动，这个现象出现的会更加明显。
发作期间会疯狂占用内存到100%，且不会被OOM，只能重启解决。

多年仍未发现

大多数人主动禁用掉IPV6，可能是旁路结构、可能是作为二级路由存在。
同时，这个问题只有在定时重载频繁的场景才出现，是一个随机概率问题。

不想更新插件、解决问题？

在不更新插件的情况下解决此问题，有几种方案：
关闭IPV6透明代理（旁路结构、无IPV6环境）
关闭机场定时拉取订阅（大幅度降低风险）
WAN口的PPPoE拨号尽可能的不要手欠去重启、或配置定时重拨（运营商侧强制重播，可能已经过了好几天。可极大降低风险。）
更换插件

漫长的测试之路

在以往，死机现象是经常发生的事情，可能过几个小时或者过几天，甚至是15天，完全是随机的，但没有超过30天uptime。
截止到目前，uptime为59d 20h 52m 37s，而且这还是停电重启之后的uptime，足以证明稳定性！
测试时间 2026年5月17日编译第一版含修复的固件 --> 2026年9月24日将修复代码的提交Passwall官方仓库。

成为贡献者之一

https://github.com/Openwrt-Passwall/openwrt-passwall/graphs/contributors?from=2026%2F6%2F20
十分荣幸能贡献自己的力量到Passwall仓库中，为伟大的翻墙事业添砖加瓦。