IPv6-only 低配 VPS 上跑 Node 服务：先探查，再动手

很多人拿到一台便宜 VPS 就直接装 Docker、拉镜像，结果在只有 512M 内存、只有 IPv6 出口的机器上，第一步就卡住。其实顺序反了：先探查，再动手，十分钟的检查能省掉几小时的折腾。

第一步，看家底。 先跑 free -m、nproc、df -h，确认内存、CPU、磁盘到底有多少。512M 内存的机器就不要指望 Docker 了，容器本身的开销先吃掉一大块；直接用 Node 二进制安装、systemd 保活，反而更稳。顺便看一眼系统版本，Debian 12 这类稳定版，官方源里的软件版本偏旧，但胜在可预期。

第二步，测网络，分清 IPv4 和 IPv6。 有些 VPS 只有 IPv6 公网地址，IPv4 要走 NAT 出去，而且这条 NAT 可能很慢甚至时断时续。别凭感觉，先分别测：curl -6 走 IPv6 抓一个文件，看速度；再 curl -4 测 IPv4。如果 IPv6 很快、IPv4 很慢，后面装软件就优先走 IPv6 的源和镜像站，apt-get update 也一样。很多"下载慢""装不上"的问题，根子都在这里，而不是软件本身。

第三步，装 Node，别迷信包管理器。 系统源里的 Node 版本常常太旧，直接去官网拉对应架构的二进制包解压，配好 PATH 就能用。装完先跑 node -v 和 npm -v 确认，别等到服务起不来才发现版本不对。没有依赖的纯 Node 服务更省事，npm install 几乎是空跑，部署时间主要花在下载运行时上。

第四步，先前台跑，再交给 systemd。 这是最容易被跳过、也最值钱的一步。先手动在前台启动服务，看它完整打印的启动日志：监听地址、端口、上游地址都对不对，有没有报错。确认没问题再写 systemd unit，设好工作目录、环境变量和自动重启。前台测试通过，systemd 只是把它变成"开机自启、挂了自启"，而不是帮你排错。

第五步，入口单独做一层。 服务本身只监听本地端口，对外入口交给反向代理或隧道去做：反代负责 HTTPS 证书和 80/443 端口，隧道负责把内网服务安全地暴露出去。两者各司其职，服务本身不用关心证书续期，也不用直接暴露在公网上。出问题时也好定位：入口返回 404 还是 502，分别指向不同的环节。

最后，留一条验证的证据链。 部署完不要只看"进程在跑"，从外部实际访问一次入口，确认状态码和响应符合预期；再看一眼服务日志，确认请求真的走到了服务本身。能访问、日志有记录、重启后还在，这三点齐了，才算部署完成。

低配机器不是不能用，只是容错率低。每一步先验证再往下走，慢就是快。