Nginx 蓝绿部署实测：单台 VPS 切换前必须验证哪些指标

TL;DR：Nginx 蓝绿部署在单台 VPS（虚拟专用服务器）上能帮助小团队把发版风险降下来，但切换前必须先证明新版本可用。本文教你按 6 类指标检查：进程独立、端口隔离、健康检查、静态资源、Nginx reload、日志与回滚耗时。只要这些指标没有跑通，就不要把真实用户流量切到新版本。

这里讨论的不是多节点高可用，而是更常见的单机发布：blue 版本继续承接流量，green 版本先在旁路启动；验证通过后，Nginx 把 upstream 从 8081 切到 8082。如果机器宕机、磁盘损坏或数据库不可用，单机蓝绿并不能兜底。它解决的是“新版本上线前能否先验货、出错后能否快速切回”的问题。

基础资料可以参考 WHT 技术教程、VPS 主机讨论区 和 WordPress 建站栏目。如果你正在中文用户常用的海外主机环境里落地，也可以结合 Hostease 专区 的线路与主机讨论一起看。

一、先确认单机蓝绿的资源边界

单机蓝绿最容易被高估。两个版本虽然目录不同、端口不同，但 CPU、内存、磁盘 I/O、上传目录和数据库仍然共享。假设旧版本常态占用 650MB，新版本启动后再占 700MB，而机器只有 1GB 内存，那么切换前就可能触发 swap 抖动，表现为页面延迟升高或应用进程被系统杀掉。

在我的测试环境中，2 核 2GB 的 VPS（虚拟专用服务器）跑两个轻量 Web 进程问题不大；如果同机还跑数据库、缓存和队列，2GB 就会比较紧。先看资源余量，再写切换脚本，这是单机蓝绿能稳定的前提。

二、进程、端口和 upstream 要彼此独立

蓝绿部署不是复制一个目录就完事。更可靠的结构是：/var/www/app-blue 对应 app-blue.service 和 8081 端口，/var/www/app-green 对应 app-green.service 和 8082 端口；Nginx 通过 /etc/nginx/conf.d/app-upstream.conf 软链接指向当前版本。这样切换时只改 upstream，不改完整 server 块，能减少误动 SSL（安全传输协议）证书、日志路径和缓存规则的概率。

ss -lntp | grep -E '8081|8082'
systemctl is-active app-blue app-green
readlink -f /etc/nginx/conf.d/app-upstream.conf
nginx -t

这组命令要确认 3 个事实：两个应用进程都能单独启动；两个端口只绑定本机地址；当前 upstream 指向的文件和预期一致。准备从 blue 切到 green 时，green 只是候选版本，不能让它提前接收公网访问。

三、健康检查不能只看首页 200

上线前只 curl 首页是不够的。首页 200 只能说明入口有响应，不能证明数据库连接正常、登录接口正常、静态资源路径正确。建议把健康检查拆成两层：基础存活检查 /health、端口和进程；业务可用检查首页、关键接口和静态文件。接口返回只保留 ok，不要泄露数据库地址、密钥或完整环境变量。

TARGET_PORT=8082
curl -fsS "http://127.0.0.1:${TARGET_PORT}/health" | grep -q "ok"
curl -fsS "http://127.0.0.1:${TARGET_PORT}/" >/dev/null
curl -fsS "http://127.0.0.1:${TARGET_PORT}/assets/app.css" >/dev/null
curl -fsS "http://127.0.0.1:${TARGET_PORT}/api/ping" >/dev/null

任意一步失败，本轮发布就应该停止。对单台 VPS（虚拟专用服务器）来说，用户流量不是测试工具。类似分层验证思路，也可以参考 CDN（内容分发网络）与高防协同关系：先内部确认，再放大到公网。

四、切换动作要短，并且能复读

推荐的切换顺序是：修改 upstream 软链接，执行 nginx -t，通过后 reload，再分别检查本机和公网响应。不要把依赖安装、数据库迁移、文件同步和 reload 塞进一个超长脚本；一旦失败，排查会非常被动。

sudo ln -sfn /etc/nginx/conf.d/upstream-green.conf /etc/nginx/conf.d/app-upstream.conf
sudo nginx -t
sudo systemctl reload nginx
curl -I http://127.0.0.1/
curl -I https://example.com/

nginx -t 必须放在 reload 前面，失败时直接退出。reload 后立刻观察 access.log 和 error.log，重点看 502、499、504 是否异常增加。访问量不大的站点，可以人为发 20 到 50 次请求，确认连接复用、静态资源和关键接口没有明显波动。

五、回滚要在切换前准备好

蓝绿部署的价值在于快速回滚，但前提是旧版本还在、旧 upstream 可用、回滚命令可执行。建议设置硬触发条件：切换后 5 分钟内 5xx 明显高于平时；关键业务路径失败 2 次以上；应用日志持续报错。满足任意条件，先回滚，再排查。

sudo ln -sfn /etc/nginx/conf.d/upstream-blue.conf /etc/nginx/conf.d/app-upstream.conf
sudo nginx -t
sudo systemctl reload nginx
curl -I http://127.0.0.1/
tail -n 80 /var/log/nginx/error.log

数据库变更要尤其谨慎。更稳的发布方式是先新增字段或新表，再上线读取逻辑，观察稳定后才清理旧字段。不要在同一次发布里删除旧字段并切换应用版本，否则 Nginx 回滚了，旧应用也可能因为表结构不兼容而失败。

六、共享资源要单独列入清单

Nginx 配置通常不是最大风险，共享状态才是。上传目录、缓存、定时任务、队列消费者、临时文件和数据库连接池，都可能让 blue 与 green 互相影响。发布前至少确认以下 5 点：

• 上传目录放到 /data/uploads 这类共享路径，切换后抽测 3 个历史文件 URL。
• 缓存结构变化时增加版本前缀，并设置 10 到 30 分钟过渡期。
• 定时任务同一时间只允许一个环境执行，避免邮件或订单重复触发。
• 队列消费者要兼容旧消息格式，或在切换前暂停旧消费者。
• 保留 blue、green 和最近一次备份后，根分区可用空间建议高于 25%。

如果站点面向国内访客，晚高峰线路波动也会干扰判断。切换前后可从本机、海外节点和国内方向各抽测一次；若公网抖动明显，先以内网健康检查和服务器本地日志为准，不要把线路问题误判成版本故障。相关优化可延伸看 美国 VPS（虚拟专用服务器）速度因素与优化。

总结：先证明能切，再真的切

总结来看，单台 VPS（虚拟专用服务器）上的 Nginx 蓝绿部署，不是为了把流程做复杂，而是为了让发版有证据。建议你先在非核心业务演练 2 到 3 次：第一次只部署 green 并跑健康检查；第二次切换并观察 10 到 15 分钟；第三次专门演练回滚。等进程、端口、健康检查、日志和回滚耗时都稳定后，再把流程用于正式站点。如果你需要在 Hostease 这类中文用户常用环境中落地，也推荐先把发布记录、监控告警和回滚脚本做稳，再考虑多节点架构。