网站上线后必做的9项检查：从SSL到监控告警一次配齐

👁 139 次阅读

你花了两天把服务器配好，代码传上去，域名也解析了。浏览器打开首页，一切正常，松了一口气。然后你去干别的事了。

三天后，一个用户发来私信：“你们网站是不是挂了？”你打开一看——首页转圈，数据库连不上，或者更隐蔽：页面正常，但健康检查接口一直在返回 500，你的 cron job 已经三天没跑成功了。

这是大多数个人站长和小团队的真实写照。网站上线不是终点，而是运维的起点。上线那一刻，你只是确认了“在我这台电脑上能打开”。真正的风险——证书过期、磁盘写满、凌晨三点服务挂掉没人知道——都藏在后面。

下面这 9 项检查，是我自己踩过坑之后固定下来的上线清单。不复杂，但每一项都值得花时间做完。

检查一：HTTPS 不是装完就完了，验证真实链路

装 SSL 证书现在很简单，Let‘s Encrypt 一条命令搞定。但“浏览器没有报错”不等于证书配置正确。

你需要验证几件事。第一，用 curl 从外部网络真实走一遍：`curl -I http://你的域名`，看返回的 301/308 跳转目标是不是 `https://` 主域名，不能出现循环跳转。第二，确认证书覆盖的域名范围——如果你同时用了 `example.com` 和 `www.example.com`，证书必须包含两者，否则手机浏览器可能不告警但某些 API 客户端会拒绝连接。第三，最重要的一点：检查自动续期任务是否真的能跑。Let’s Encrypt 证书 90 天过期，不要等到第 89 天才发现 certbot 的定时任务因为权限问题静默失败了。上线后手动执行一次 `certbot renew –dry-run`，看到“success”再收工。

如果你用了 CDN，还要确认 CDN 回源和源站直连的证书行为是否一致。有些 CDN 会终止 TLS 然后用 HTTP 回源，这意味着源站流量可能没有加密——如果你有合规要求，这就不合格。

检查二：健康检查接口不只是一个 `/` 页面

首页能打开，不代表应用健康。你的 `/` 可能是一张静态 HTML，服务器挂了 Nginx 还在，页面照样出。真正的健康检查应该触及核心依赖。

一个合格的健康检查接口（比如 `/health` 或 `/api/status`）应该至少做这几件事：返回 200 状态码、检查数据库连接是否正常、检查关键外部依赖（Redis、对象存储等）是否可达。它不应该做的是：暴露数据库连接字符串、堆栈信息或内部路径。

这个接口是你后续所有监控工具探测的目标。没有它，监控只能告诉你“Nginx 还在”，有它，监控能告诉你“应用实际能不能服务请求”。

检查三：磁盘、时间、日志——上线前必看的三个系统指标

有些问题不解决，后面一定会出事。

磁盘：`df -h` 看一眼。如果使用率超过 80%，立刻处理。日志文件、数据库 binlog、Docker 镜像层是最常见的磁盘杀手。设一个 cron，每周自动清理 7 天前的日志，不要等磁盘满了再删，那时候数据库可能已经写不进去了。

时间：`timedatectl status`。服务器时间偏差会导致 SSL 证书验证失败、定时任务错乱、审计日志不可信。确保 NTP 同步是开着的。这个问题平时无感，一旦出现就是莫名其妙的故障。

日志：`journalctl –disk-usage`。很多默认配置的服务器，systemd journal 会无限增长。限制一下大小，比如 `journalctl –vacuum-size=200M`，或者配置 `SystemMaxUse=200M` 让它自动轮转。

这三个检查花不了五分钟，但能帮你避开最常见的“服务器半夜罢工”场景。

检查四：防火墙不是“开了就行”，要确认关掉了什么

上线的服务器，安全组规则应该是“默认拒绝，按需放行”。80 和 443 对外开放，SSH 端口限制来源 IP 或者至少关闭密码登录只留密钥，数据库端口（3306、5432、6379）绝对不要暴露在公网。

但防火墙的坑在于：你以为你关掉了，实际上没有。用 `ss -tulpn` 列出所有监听端口，对照你的业务清单逐条核对。每个监听中的端口，要么是你故意开的，要么就是问题。

另外，SSH 配置改完之后不要立刻断开当前会话。开第二个终端验证新配置能登录，再执行 `sshd -t` 检查语法，最后 reload。顺序错了你可能把自己锁在门外。

检查五：监控告警——网站挂了，你要比用户先知道

这是我花最多篇幅讲的一项，因为它最容易拖着不做，也最要命。

监控的第一原则是：监控节点必须在你的业务服务器之外。在自己服务器上装个脚本 ping localhost，服务器挂了脚本也挂了，监控一起死，毫无意义。

对于个人站长和小团队，我的首选是 UptimeRobot。免费版给 50 个监控项，检测间隔 5 分钟，支持 HTTP、关键词、端口、心跳等多种监控类型。注册不需要信用卡，商业用途也可以用。我用的是 UptimeRobot，注册地址在这里：https://uptimerobot.com/?red=meng&sub_id=aibsz-3171。配置很简单：添加你的健康检查接口 URL，选 5 分钟间隔，通知渠道填邮箱，五分钟就配好了。

它的定位很清晰：让你用零成本获得“外部视角的可用性告警”。对你最重要的那几个页面——首页、登录接口、支付回调地址——挂上去。5 分钟检测间隔意味着最坏情况下你最多晚 5 分钟知道，对于非实时业务足够了。如果你需要 60 秒甚至更短的间隔，那得升级付费版，或者考虑自托管方案。

说到自托管，Uptime Kuma 是另一个值得认真考虑的选择。它开源、免费，支持 HTTP、TCP、DNS、关键词检查等多种类型，告警渠道超过 90 种（Server酱微信推送、钉钉机器人、飞书、Telegram 都支持）。部署用 Docker 一条命令就起来了，1 核 1G 的 VPS 能跑 50 个以上的监控任务，月成本也就二三十块钱。缺点是你要自己维护这个监控服务——它本身也需要监控。如果你已经在用 Docker 管服务，多跑一个 Uptime Kuma 容器不算负担，而且它自带状态页，客户问“你们服务稳定吗”的时候可以直接甩链接。

Better Stack 的免费版提供 10 个监控和状态页，还带 3GB 日志 ingestion，适合需要日志和监控一体的场景。阿里云监控的优势在于如果你整个业务都在阿里云上，它能直接监控 ECS、RDS、SLB 的内部指标，比如 CPU、连接数、磁盘 IOPS，和站点拨测是互补关系。但它对站长的价值更多在于“云资源层”的监控，站点可用性拨测反而不如 UptimeRobot 或 Uptime Kuma 直接。

我的建议是分层：用 UptimeRobot 或 Uptime Kuma 做外部站点可用性监控，确保用户访问不了的时候你能第一时间知道；用云监控或系统自带工具做服务器资源监控，确保磁盘、CPU、内存不会悄无声息地耗尽。两者不冲突，加起来才完整。

配完监控后，做一次“故意弄挂”测试。临时改掉健康检查接口的返回码，或者停掉 Nginx 十秒钟，确认你的邮箱或微信真的收到了告警。没测试过的告警等于没有告警。