Leadaxe：LxBox 内存表现为 Go 堆峰值而非泄漏，不计划 Rust 重写内核
Leadaxe 解释 Go 运行时不会立即归还堆，常驻内存反映会话峰值；过低内存上限会让 GC 占满 CPU；并说明基于自维护 sing-box 分支迭代的合理性。原文见下方引用。
作者原文@LeadaxeWhat you're describing is normal Go runtime behaviour, not a leak — and it's worth explaining because the number you're watching doesn't mean what it looks like.
Why RAM stays at ~400MB after you close the browser. Go does not return freed heap to the OS immediately. Memory that the collector has reclaimed stays mapped in the process and gets reused for the next allocations instead of being handed back and re-requested — that's cheaper than churning pages with the kernel. So RSS follows the high-water mark of your session, not the current number of connections. Going 340 → 430MB while a browser opens a few dozen connections, then settling near 400MB, is the runtime holding on to buffers it expects to need again. There is nothing to reclaim there; the memory is free from the program's point of view.
We did chase a real version of this, and it was the opposite problem. A hardcoded 200MB limit (v2.10.0) meant the collector ran continuously against a heap that couldn't fit — that was the "phone gets hot" reports, confirmed with a pprof CPU capture showing ~88% of CPU in GC. The fix was raising the ceiling, not lowering it.
So if you want to tune this: VPN Settings → System → Optimization → Memory limit. Default is
Auto, which picks by device RAM (200/384/512MB). Lowering it will not reduce steady-state usage in a useful way — it makes the collector work harder for the same job. There's also Suspend idle tunnels in the same section, which cuts heap substantially when the device is idle.On rewriting the kernel in Rust — no, and this isn't a performance judgement. LxBox runs on our own maintained fork of sing-box; that's what lets us debug all the way down and ship kernel fixes on our own schedule. Rewriting it would mean reimplementing every protocol, every transport and every routing behaviour from scratch, then re-verifying all of it on devices — years of work to arrive at the same feature set. The bottleneck in a proxy client is the network, not the language.
