@七号，强烈建议完全去除服务器端渲染，改为纯前端项目，然后把投票帖之类的功能直接添加到后端PHP里。
如果失去响应的问题再出现一次，我就会停止运行hu60next的服务器端。

为了防止bun导致问题，我会把js引擎换回nodejs。

已经把 js 引擎换回nodejs。

hu60next 服务器内存泄漏排查

机器被 Next.js 进程拖死，不是「有点卡」，是换页抖动。

元凶进程

node /vhost/hu60next/node_modules/.bin/next start --hostname 0.0.0.0 --port 8083

整机对照

• 内存 6.77G / 7.29G，几乎顶满
• Swap 已用 1.29G / 8G
• Load 35 / 78 / 75，4 核机器正常该在个位数
• 下面好几条 D（不可中断睡眠）：mariadbd、几个 python3.7 脚本

Load 这么高、真正 Running 却只有 2 个，典型是内存不够开始猛换页，进程卡在磁盘 I/O 上排队。MariaDB、面板脚本、Postgres 都被它挤进等待。

其它服务（Vaultwarden、gunicorn、celery、cloudflared、Java）各自一两百 MB，不是主因。

处置步骤

# 先看它在干什么
sudo ls -l /proc/2101622/cwd
sudo lsof -p 2101622 | head

# 确认是 hu60next 后再杀
sudo kill 2101622
# 几秒还不降，再
sudo kill -9 2101622

停掉后看 load 和 swap 会不会掉。若马上又涨回 4G+，就是这个应用本身泄漏（Next 服务端渲染、缓存、某个 API 死循环），不是「机器太小」能解释的。

顺手两件

1. ⚠️ 截图里 cloudflared --token eyJ... 整段 token 都露出来了，当作已泄露，去 Cloudflare Zero Trust 把这条隧道 token 轮换掉。
2. 这台 4 核 8G 上叠了 Next、Java、MariaDB、Postgres、一堆 gunicorn/celery，即使修好泄漏也偏挤。hu60next 最好限内存，例如 systemd/NODE_OPTIONS=--max-old-space-size=1024，别再让它把整机吃穿。

能提供这个 Next 应用的日志或重启后内存曲线的话，可继续往下看是泄漏还是流量打爆。

当前这种方式确实不够省资源。我会考虑实现一个原生主题

我的2h4g机器上用nodejs跑的，除了构建慢，其他问题没有出过。可能是没流量

@水木易安，cloudflared的token有184字符，泄露的长度还不到一半

@七号，突然想到一个解决方法，docker是支持资源限制的，我把hu60next内存限制到500M就行了，这样它大量泄露只会卡住它自己，不会影响服务器。