VPS 突然连不上？宕机排查、SLA 索赔与 Uptime Kuma 监控实战

2026-08-14 · DevCraft Studio

VPS 突然连不上别急着怀疑自己。本文教你查机房官方 Status 页、看懂 SLA 与 99.9% 含义、用 Uptime Kuma（Docker 一键）秒级告警，并附一封能要到补偿的 SLA 赔偿英文工单模板。

一、VPS 连不上，先别慌也别甩锅

某天早上你打开网站，发现打不开，SSH 也连不上，第一反应往往是"我是不是被封锁了"或者"我配置改错了"。先深呼吸——便宜 VPS 宕机太正常了，大概率不是你的问题，是机房那边出事了。真正该做的第一步，是确认"到底是谁的锅"。

判断思路很简单：

  • 只有你的站打不开，别人站正常 → 可能是你这台机器或它所在的母鸡挂了。
  • 你这台和同机房朋友的同时挂 → 机房网络/电力故障，纯等官方修。
  • 国内打不开但国外能开 → 可能是线路/网络封锁的问题，不是 VPS 宕机。

别一上来就重装系统、重置密码，白忙活还可能丢数据。按下面流程走。

顺手记几个一秒出结果的排查命令，能帮你快速定位：用 ping 你的IP 看 ICMP 通不通；用 traceroute 你的IP（Windows 用 tracert）看卡在哪一跳；用 curl -I https://你的域名 看 HTTP 返回什么。如果国内不通但套了代理的国外机器通，多半是线路/网络封锁而非宕机。把这些结果截图留着，后面无论是发工单还是索赔都用得上。

二、查官方 Status 页面：机房自己会"认错"

正经厂商都有状态页（Status Page），机房网络中断、硬件故障、DDoS、计划维护都会在上面公告。先去这里看一眼，能省你 80% 的猜测时间。

常见厂商 status 页

  • OVH：status.ovh.com（之前斯特拉斯堡机房大火，状态页就实时更新着）。
  • Vultr：status.vultr.com
  • DigitalOcean：status.digitalocean.com
  • Linode / Akamai：status.linode.com
  • Hetzner：status.hetzner.com
  • Bandwagon（搬瓦工）：在客户端里看 Notice，或 migoto / bwh8 相关公告。
  • CloudCone：官网有 status 入口；RackNerd 一般靠工单和邮件。
  • 腾讯云 / 阿里云：各自有"健康看板 / 状态"页面。

注意：很多超低价商家没有像样的 status 页，那就只能靠工单和社区（Hostloc、Telegram 群）交叉验证。

用第三方交叉验证，别只信一家

  • Downdetector（downdetector.com）：用户自发上报的故障地图，能看出是不是大面积问题。
  • Ping.cn / 站长工具：从国内多节点 ping 你的 IP，看是全线不通还是部分不通。
  • 探机类：用另一台不同机房的 VPS 去 ping/traceroute 故障 IP，定位是哪一跳断了。

一句话：官方 status + 第三方探测 + 社区反馈，三处对上了，基本就能确定是机房的问题，这时候你只需要开张工单 + 等，顺便记好起止时间，后面索赔用。

三、看懂 SLA：99.9% 到底保你啥

买 VPS 时页面常写"99.9% Uptime 保证"，这玩意叫 SLA（服务等级协议）。它本质是一张"宕机赔付承诺书"。先换算成你能感知的时间：

  • 99.9%：一个月允许宕机约 43 分钟；一年约 8.76 小时。
  • 99.95%：约 22 分钟/月。
  • 99.99%：约 4.3 分钟/月。
  • 99.999%（五个九）：约 26 秒/月——便宜 VPS 基本别指望。

关键认知：SLA 只保"底层可用性"，不保你应用层。也就是说，机房网络断了、母鸡硬件挂了算它违约；但你 Nginx 配错、被 DDoS 打到、欠费停机，都不算。而且——

常见免赔条款（SLA 里的坑）

  • 计划内维护：提前公告的升级/安全补丁，通常不算宕机。
  • 不可抗力：火灾、地震、战争、政府行为。
  • 外部因素：超容量的 DDoS、上游运营商骨干网故障、DNS 传播延迟。
  • 你自己的锅：第三方软件崩、代码 bug、弱密码被黑、欠费、违反 AUP 被暂停。
  • 超低价商家：很多便宜 VPS 的 TOS 里压根没有 SLA 或写明"不保证可用性"，这种你基本索赔无门，只能自认倒霉或换家。

所以买之前，把 SLA 那页读一遍，看清楚它保什么、不保什么、怎么赔。RackNerd / CloudCone 这类年付几刀的，真别指望它能赔你什么，当"玩具机"用最稳妥。

四、怎么要补偿：Service Credit 索赔实操

如果确实符合 SLA 赔偿条件，补偿形式通常是 Service Credit（服务抵扣券），直接充到你账户下个月账单，一般不能提现。流程各家差不多：

  1. 开工单：在 Billing / SLA Credit 分类下提交，别发到普通技术支持里，容易石沉大海。
  2. 附证据：宕机起止时间、你的监控截图/uptime 记录（这就是下一节要搭的 Uptime Kuma 的价值）、引用具体 SLA 条款。
  3. 算金额：按 SLA 阶梯，比如当月可用性 99.5% 以下赔 10%、99% 以下赔 25% 之类（以你合同为准）。
  4. 注意时效：很多家要求故障后 7~30 天内提索赔，过期不候。
  5. 礼貌但明确：引用条款、给证据、要 Credit，别情绪化骂人，但也别含糊。

经验之谈：主动提才有，不提基本不会自动给。而且 Credit 常不能叠加、不能换现金，聊胜于无。对便宜机器来说，索赔最大的意义是"让厂商知道你在使用并关注可用性"，逼它重视。

五、自己搭个监控：Uptime Kuma 挂机告警

等宕机了才去查 status 页，属于"事后诸葛亮"。真正稳的做法是自己挂一个监控，VPS 一挂秒发你手机。首推 Uptime Kuma：开源自托管，界面好看，支持 HTTP/TCP/Ping/DNS 等十几种监控，通知渠道 90+（Telegram、邮件、企业微信、钉钉、Server 酱、Bark 等），最关键——一条 Docker 命令就能起。

Docker 一键部署

# 装 Docker（没装的话）
curl -fsSL https://get.docker.com | sh
sudo systemctl enable --now docker

# 起 Uptime Kuma
mkdir -p /opt/uptime-kuma && cd /opt/uptime-kuma
docker run -d \
  --name uptime-kuma \
  --restart=unless-stopped \
  -p 3001:3001 \
  -v /opt/uptime-kuma/data:/app/data \
  louislam/uptime-kuma:latest

浏览器开 http://你的监控机IP:3001，首次注册管理员账号即可。建议把监控面板放在另一台机器上（或家里 NAS），这样"被监控的 VPS 挂了，监控面板也跟着挂"的盲区就避免了。

加监控项（Add New Monitor）

  • HTTP(s)：填你的站点 URL，状态码期望默认 200，心跳间隔建议 60 秒，重试 1~2 次。
  • Ping：填 IP/域名，监控主机是否在线（ICMP）。
  • TCP Port：填 域名:端口，监控 SSH(22)、MySQL(3306) 等服务端口是否通。
  • Docker Container：监控某个容器是否在跑。

实战建议：同一个目标加两个 Monitor——一个 HTTP 监控站点、一个 Ping 监控主机，这样能区分"是机器挂了"还是"只是网站进程挂了"。

配置通知（Notifications）

进后台 → Settings → Notifications → 添加通知：

  • Telegram：搜 @UptimeKumaBot 按提示拿 chat id，填 Token 和 Chat ID，最方便，个人首选。
  • 邮件：填 SMTP（QQ 邮箱用 smtp.qq.com:465 + 授权码，不是登录密码）。
  • 微信：走 Server 酱（ServerChan）或企业微信 Webhook，国内用户体验最好。
  • 钉钉 / Discord / Bark：按需选。

配好后回到每个 Monitor 的 Notifications 里勾选对应渠道。服务异常时机器人秒推消息，恢复时再推一条，不用你一直刷。

进阶：公开状态页

Uptime Kuma 能生成一个公开状态页（Status Page），把多个监控聚合展示，地址形如 http://IP:3001/status/你的路径。可以发给用户看"服务是否正常"，体面又省心。正式用建议套一层 Nginx 反代 + HTTPS，别裸奔在 3001。

六、一封能要到补偿的 SLA 赔偿英文工单

下面是可直接改的模板，核心要素：报工单号、给时间、贴证据、引条款、明确要 Credit。把括号里换成你的实际信息。

Subject: SLA Credit Request - Service Interruption on [Instance ID / IP]

Hello,

I am writing to request a service credit under the SLA for an
unplanned outage affecting my instance [INSTANCE_ID / IP] in
[REGION/DATACENTER] on [DATE].

Incident summary:
- Start time (UTC): [START_TIME]
- End time (UTC):   [END_TIME]
- Total downtime:   [DURATION] minutes
- My monitoring (Uptime Kuma) shows 100% packet loss during this window.
  Screenshot attached. The provider status page also listed an incident
  at [STATUS_PAGE_URL].

Per your SLA (section [X]), monthly uptime below [THRESHOLD]% entitles
the affected service to a [PERCENT]% service credit. Based on the
downtime above, this month's availability is approximately [VALUE]%,
which qualifies for the credit.

Could you please review and apply the corresponding service credit to
my account? I have already opened ticket #[TICKET_ID] reporting the fault.

Thank you,
[YOUR_NAME]
[ACCOUNT_ID]

几个要点：用 UTC 时间避免时区扯皮；附监控截图和 status 页链接当证据；引用具体条款让对方没法糊弄；索赔金额写清楚。中文商家用中文模板同理，把上面翻成中文、引用"服务等级协议"对应条款即可。

七、总结 / 避坑清单

VPS 宕机应对，记住这条主线：先确认是谁的锅 → 查 status 页 + 第三方交叉验证 → 自己有监控留证据 → 符合 SLA 就主动索赔。

避坑清单：

  1. 连不上先别重装/重置，先确认是机房问题还是自己的问题。
  2. 收藏好你厂商的 status 页，故障第一时间看官方公告。
  3. 用 Downdetector / Ping.cn / 另一台 VPS 做交叉验证，别只信一面之词。
  4. 买之前读 SLA，看清保什么、不保什么、怎么赔；超低价机大多没 SLA。
  5. 补偿是 Service Credit，一般不能提现，且要主动提、注意 7~30 天时效。
  6. 自己搭 Uptime Kuma 挂机监控，放另一台机器上，VPS 一挂秒推手机。
  7. 同一个目标加 HTTP + Ping 两个监控，区分"机器挂"还是"进程挂"。
  8. 索赔工单附监控截图 + status 链接 + 引用条款，用 UTC 时间，礼貌但明确。
  9. 监控面板本身也要备份数据卷（/app/data），别监控没了记录也没了。

最后一句大实话：便宜 VPS 的 SLA 常常是"心理安慰"，真靠它赔钱很难。真正能让你睡安稳觉的，是自己的监控 + 异地备份 + 必要时两台机器做 HA（见另一篇 Keepalived 实战）。把鸡蛋分开放，比指望厂商赔那几刀抵扣券靠谱得多。

延伸阅读

更多相关攻略推荐：【VPS 硬件选型指南 (CPU 篇) 04】AMD EPYC 还是、【发行版选型 07】Arch Linux 深度科普：滚动发布、pac、【VPS 进阶玩法精选 014】ARM 架构 VPS 值不值得上？A、【对象存储 01】对象存储怎么选：Backblaze B2 vs C、【TCP优化 01】美国 VPS 跑不快？多半是没开 BBR，一个命。