在日常网络运维中，很多人会用到内网穿透工具，比如 frp、ngrok 或花生壳这类软件。尤其是在没有公网 IP 的环境下，想从外网访问家里的 NAS、摄像头或者测试中的网站，穿透工具几乎是必备方案。但用得多了，难免会发现一个问题：机器的内存占用好像变高了。
穿透工具到底吃不吃内存？
答案是：看情况。大多数轻量级的穿透工具本身设计就很精简，单个进程占用几十 MB 内存很常见。比如 frp 客户端在空闲状态下，通常只占 20~50MB 内存，对现代服务器或路由器来说压力并不大。
但如果你开了多个隧道，比如同时映射了 Web 服务、SSH、远程桌面，再加上传输的数据量不小，那内存占用自然会上去。特别是某些图形化客户端，背后可能还套了一层 Electron 框架，光界面就占上百 MB，这时候别说穿透功能了，UI 本身就成了“内存杀手”。
影响内存使用的几个关键点
第一个是并发连接数。每个外部请求进来，穿透工具都要维持一个内外网之间的转发通道。连接越多，需要维护的状态也就越多，内存自然水涨船高。比如你在做直播推流，几百人同时连，frpc 进程的内存跑到 100MB 以上也不奇怪。
第二个是日志级别。有些用户为了排查问题，把日志设成 debug 模式，所有通信细节都记下来。时间一长，日志缓存堆积，内存就被悄悄吃掉。建议日常使用选 info 级别就够了，真出问题再临时调高。
第三个是工具本身的实现方式。Go 写的程序像 frp，运行时自带 runtime，启动快、资源控制好；而一些基于 Python 或 Node.js 的穿透脚本，解释器本身就耗资源，加上垃圾回收机制不同，长时间运行容易出现内存滞留。
怎么判断是不是工具的问题？
最直接的方法是用 top 或 htop 看进程资源占用。比如在 Linux 上执行：
top -b -n 1 | grep frpc看看 RES（常驻内存）那一列的数值。如果长期稳定在合理范围，说明没问题；如果持续增长不回落，可能是有内存泄漏，得考虑升级版本或换工具。
也可以通过配置限制资源使用。比如在 frp 配置文件里控制最大连接数：
[common]
server_addr = x.x.x.x
server_port = 7000
max_pool_count = 5这样能防止单个服务占用过多连接，间接控制内存增长。
实际场景参考
有个用户在家搭了个 mini k8s 集群，用树莓派跑 frpc 做管理面板穿透。刚开始一切正常，后来加了 Prometheus 抓指标，又开了 Grafana 页面映射，结果树莓派内存经常飙到 90% 以上。最后发现不是 frpc 本身的问题，而是 Grafana 启动后太吃资源，frpc 只是背了锅。
另一个例子是公司测试环境用 ngrok 共享本地服务，开发人员每人起一个隧道，十几个实例跑在一个低配云主机上，内存直接爆了。换成统一部署 frps 服务端，客户端共用通道后，整体资源下降一半。
小内存设备怎么用更稳妥？
如果是路由器、树莓派这种内存紧张的设备，建议选命令行工具，关掉不必要的日志输出，定期重启进程释放内存。还可以写个简单的监控脚本，发现内存超限就自动重启：
#!/bin/bash
MEM=$(ps aux | grep frpc | grep -v grep | awk '{print $6}')
if [ $MEM -gt 100000 ]; then
systemctl restart frpc
fi虽然不能根治问题，但至少避免长时间运行导致卡死。
归根结底，穿透工具本身不一定占很多内存，但使用方式和环境会影响最终表现。合理配置、按需启用，才能让它们低调干活，不拖慢系统。”}