一、先分清三种崩溃，不要一上来就重装
VPS 崩溃不是一个问题，是三个不同的问题，处置顺序完全相反。 绝大多数人一看到站点打不开就执行重装，结果把唯一有价值的现场信息（日志、内存曲线、OOM 记录）全部抹掉。正确做法是先花三分钟分类，再决定动作。
第一类：进程崩溃。 网站还在、Nginx 还在监听，但某个后端进程死了。典型现象是访问站点返回 502 或 504，后台能登录。这一类不需要碰系统，只需要重启那个进程。
第二类：内存打满被 OOM Killer 干掉。 现象是机器突然 SSH 连不上，但过一两分钟又好了，或者负载飙升后反复掉线。这类问题的元凶在内核日志里，能看到 Out of memory: Killed process。这一类也不能重装，要改配置。
第三类：整机失联。 SSH 端口不通、控制台也进不去、ping 不通。只有这一类才需要重装或联系商家。
分类命令（一行搞定）：
# 1) 先看机器活没活
uptime
# 2) 看内存还剩多少
free -m
# 3) 看有没有 OOM 记录（关键）
sudo dmesg -T | grep -i -E "out of memory|killed process|oom"
# 4) 看服务状态
sudo systemctl status nginx mysql php-fpmdmesg 里出现 Killed process 1234 (php-fpm) total-vm:... 就是第二类。 如果 dmesg 干净、服务状态全是 active 但外网访问 502，那就是第一类。如果 uptime 都执行不出来、SSH 直接超时，就是第三类。
为什么必须先分清：三类问题的处置成本差了两个数量级。 第一类重启一个进程，几十秒；第二类改配置文件再重启服务，五分钟；第三类重装系统，站点数据可能丢、重新配环境一小时起，还可能因为 IP 被封、机房故障而反复发生。在没有分类之前执行重装，等于用第三类的代价去解决第一类的问题。
还有一种情况经常被误判成崩溃：网站没变但访问变慢。 如果你的监控显示 5xx 错误没涨，但页面加载时间从 1 秒变成 10 秒，那不是崩溃，是资源耗尽的前兆。区分方法很简单：崩溃是「访问不了」，资源耗尽是「访问得了但很慢」。 前者查 systemctl status 和 dmesg，后者查 top 的 CPU 占用和 iostat 的磁盘队列深度。
判断时机的把握也很重要：不要在流量高峰做这些排查。 同样一台 4GB 机器，凌晨 3 点跑 free -m 可能显示内存用了 400MB，早上 10 点跑就显示 1.8GB。排查崩溃的最佳窗口是故障发生时，其次是凌晨低峰期，绝不要在白天高峰去跑那些排查命令——那等于给已经濒临崩溃的机器再加负载，很容易把「还能抢救一下」变成「彻底失联」。
一个实用的准备动作：在机器还正常的时候，先把这段分类命令存成脚本。 存成 ~/triage.sh 并赋予执行权限：
#!/bin/bash
uptime
free -m
sudo swapon --show
sudo dmesg -T 2>/dev/null | grep -i -E "out of memory|killed process|oom" | tail -10
df -h /
systemctl is-active nginx mysql php-fpm 2>/dev/null
ps -eo comm,rss --sort=-rss | head -8这样你在 SSH 掉线又恢复的那个瞬间，只要敲 ./triage.sh 就能拿到全部关键信息，不用临时拼命令、也就不会漏掉关键输出。 需要提醒的是，dmesg 在部分系统上需要 root 才能读取完整内容，普通用户会看到「Operation not permitted」的提示——遇到这个提示时用 sudo dmesg -T 重跑，不要以为是没有 OOM 记录。
二、第一类：进程崩溃的十分钟复活流程
确认是进程问题后，处置顺序是「先取证、再重启、后看日志」。 直接重启会丢掉崩溃瞬间的现场。
第一步：确认是哪个进程死了。
sudo systemctl status nginx
sudo journalctl -u nginx -n 100 --no-pager常见报错与含义：
Failed to start nginx.service: Unit nginx.service not found. —— 服务名不对。Debian/Ubuntu 上是 nginx，CentOS 上是 nginx 或 httpd，宝塔面板装的可能叫 nginx 但实际由 bt 托管。执行 systemctl list-units --type=service | grep -i nginx 找到真名。
Job for nginx.service failed because the control process exited with error code. —— 进程起来了但随即退出。这时直接看日志：
sudo journalctl -u nginx -n 50 --no-pager | tail -30第二步：看是否是配置错误。 Nginx 配置改错是最常见的崩溃原因，而且它有专门的语法检查命令：
sudo nginx -t输出 syntax is ok / test is successful 才说明配置能加载。 如果报 unknown directive，多半是复制了带中文注释的配置导致解析失败。这一条命令能在重启前就避免一次「重启即挂」的二次事故。
第三步：带上调试信息重启，看它到底在哪一步退出。
sudo systemctl restart nginx
sudo systemctl status nginx
sudo journalctl -u nginx -n 50 --no-pager第四步：如果服务反复自己挂掉，那不是崩溃，是守护没配好。 查看是否设置了自动重启：
sudo systemctl cat nginx | grep -i restart输出里没有 Restart=always 或 Restart=on-failure，就加上：
sudo systemctl edit nginx在打开的编辑器里写入下面三行（这是 systemd 的 drop-in 覆盖文件，不要直接改原 unit 文件）：
[Service]
Restart=on-failure
RestartSec=5s保存后执行 sudo systemctl daemon-reload && sudo systemctl restart nginx 生效。
但要记住：反复崩溃本身不是被处理掉了，是被掩盖了。 服务自动重启只能保证「站点不长时间不可用」，不能保证「根因消失」。
还有两个高频的「假崩溃」值得单独说，因为它们太常见了。
第一种是磁盘满导致的 502。 现象是网站突然大面积 502 或 503，但 systemctl status nginx 显示服务是 active 的，nginx 日志里只有「connect() failed (111: Connection refused)」。这个报错的意思是 nginx 活着，但转发给后端 PHP-FPM 的连接被拒绝了——因为 PHP-FPM 已经因为磁盘满而无法启动（它要写 PID 文件和 session 文件）。辨别方法很直接：
df -h /
sudo systemctl status php-fpm
sudo tail -50 /var/log/php*-fpm.logPHP-FPM 日志里出现 Unable to write to .../php-fpm.pid (No space left on device) 就实锤了。 这时候千万不要去反复重启 PHP-FPM，重启多少次都是同样的错误，要先把磁盘清出来。
第二种是证书过期导致的 502。 现象是浏览器提示证书错误，但 curl 访问返回 502。排查方法：echo | openssl s_client -connect 你的域名:443 -servername 你的域名 2>/dev/null | openssl x509 -noout -dates，输出里的 notAfter 日期如果已经过期，就是证书问题，重新签发并 reload 即可，和 VPS 配置无关。 Let's Encrypt 的证书有效期是 90 天，自动续期没配好是这类问题的头号来源。
最后一条经验：把「服务挂了」和「服务在但配置错」分开。 前者重启就好，后者重启会让情况更糟——比如 Nginx 配置写错了，systemctl restart nginx 会直接让已经正常运行的 nginx 也起不来，站点从「返回 502」变成「完全拒绝连接」。所以永远先跑 nginx -t 再重启。
三、第二类：OOM 崩溃——查清是谁吃掉了内存
内存打满导致的崩溃，特征是「机器自己好了，但期间不可用」。 这是因为内存耗尽时内核触发了 OOM Killer，杀掉了占用最大的进程——很多时候被杀的是 SSH 守护进程，于是你掉线了；等别的进程退出、内存释放，SSH 又恢复了。这种「时好时坏」的现象是 OOM 最典型的指纹。
查证命令：
sudo dmesg -T | grep -i -E "oom|killed process" | tail -20
sudo journalctl -k --since "1 hour ago" | grep -i oom常见输出原文与含义：
[12345.678] Out of memory: Killed process 2311 (php-fpm) total-vm:2031452kB, anon-rss:1310720kB, file-rss:0kB, shmem-rss:0kB —— 凶手是 php-fpm，单进程常驻内存 1.28GB（anon-rss 1310720kB ÷ 1024 = 1280MB），虚拟内存 1.9GB。
oom-kill:constraint=CONSTRAINT_MEMORY_POLICY,nodemask=(null),cpuset=... —— 触发了 cgroup 内存上限，说明你的 VPS 有容器隔离，宿主机上其他租户的内存压力也会传导进来。
swap: no swap 或 swap 使用率为 0 —— 没有交换分区，内存一到顶就是硬杀，没有任何缓冲。
确认是谁吃了内存，用这张表：
ps -eo pid,comm,rss --sort=-rss | head -15
free -m
sudo swapon --showrss 列单位是 KB。 一个正常的静态站点 + PHP-FPM + MySQL 的 1GB 机器，稳定态 RSS 大致是：nginx 5MB、php-fpm 8MB/进程、mysqld 350MB 左右。如果看到 mysqld 占了 700MB 以上，那不是 MySQL 正常状态，是 InnoDB buffer pool 设大了。
先看是不是「配置撑爆的」而不是「业务撑爆的」。 MySQL 是小内存 VPS 上最常见的元凶，默认 innodb_buffer_pool_size 常常是物理内存的 50%–70%，在 1GB 机器上就是 512MB–700MB，加上连接、排序缓冲、临时表，实际占用轻松过 1GB。
处置顺序：
第一步，先加交换分区止血。 这不会让机器变快，但会让它不再被硬杀——内存不够时系统用 swap 顶着，而不是直接杀进程。
sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstabswapon --show 能看到 /swapfile 就说明成功了。 注意 chmod 600 不能省，swapfile 是可读写的文件，权限放宽等于把内存内容暴露给任何本地用户。
第二步，看内存谷值和峰值。 判断依据不是「内存满了没有」，而是「内存谷值离天花板还有多少」：
# 每 5 秒采一次，共 5 分钟
for i in $(seq 1 60); do
echo "$(date +%T) $(free -m | awk 'NR==2{print $3}')"
sleep 5
done这条命令会输出 60 行，第三列是已用内存 MB。 把这 60 个数的最小值当谷值、最大值当峰值。
第三步，按下面的阈值判断该动哪里：
| 谷值（已用内存 MB） | 峰值（已用内存 MB） | 判断 | 动作 |
|---|---|---|---|
| 谷值 ＜ 15% 总量，峰值 ＜ 60% | 正常 | 业务量还小 | 不用动，加监控就行 |
| 谷值 ＜ 15% 总量，峰值 ＞ 85% | 有突发尖峰 | 内存被瞬时吃满 | 改 PHP-FPM worker 数上限，加 swap |
| 谷值 ＞ 40% 总量 | 持续偏高 | 有东西在慢慢泄漏或配置过大 | 查 MySQL buffer pool 和 PHP 进程数 |
| 谷值 ＞ 70% 总量 | 一直在高位 | 配置已经超配 | 必须加内存或改配置 |
注意第一列的阈值写的是「谷值 ＜ 15%」而不是「内存小于 15%」——判断内存健康度要看谷值不是峰值。 一个谷值 10%、峰值 95% 的站点和一个谷值 80%、峰值 85% 的站点，处置方式完全不同：前者要削峰，后者要扩容。
四、第三类：整机失联的处置顺序与止损点
这一类不能远程自救，唯一能做的是止损加留证。
第一步，先分清是「你的机器死了」还是「你的网络死了」。 换一条线路试：
# 测端口，不测 ping（很多机房禁 ping）
nc -zv YOUR_SERVER_IP 22如果 ping 通但 22 端口不通，是防火墙或 sshd 挂了；如果 ping 和 22 都不通，是机器本身的问题。 很多 VPS 默认禁 ICMP，只禁 ping 不代表机器死了。
第二步，去商家控制台看两件事：
一是电源状态。 显示 Powered Off 的，是被自动关机了——通常是流量超限、欠费或者触发了滥用条款自动停机。流量超限自动关机是很多服务商的标准策略，恢复后必须立刻改配置或购买流量包，否则重启就再关。
二是重置电源（Reboot / Power Cycle）而不是重启（Restart）。 两者区别在于：重启是走操作系统自身的 shutdown 流程，硬重启是直接断电重新上电。机器已经 unresponsive 的时候，只能用硬重启。 硬重启对文件系统有风险：如果当时有写盘操作，ext4 可能需要 fsck，MySQL 也可能留下未回滚的事务。
第三步，硬重启后第一件事是查文件系统。
sudo touch /forcefsck && sudo systemctl reboot
# 或者手动检查（必须先卸载）
sudo umount /dev/vda1 && sudo fsck -y /dev/vda1fsck -y 的 -y 表示对所有提问自动回答「是」，这在无人值守的恢复场景是必须的，但也意味着它会强行修复可能有问题的区块。 数据量大、重要站点建议先做快照再执行。
第四步，查 MySQL 是否需要恢复。
sudo systemctl status mysql
sudo journalctl -u mysql -n 50 --no-pagerInnoDB: corruption detected in tablespace 或 Plugin 'InnoDB' init function returned error 说明 InnoDB 没起来。 强制恢复：
sudo mysqld --skip-grant-tables --innodb-force-recovery=1 &innodb-force-recovery 只允许 1 到 6，数字越大能恢复的数据越少但越容易启动成功。 从 1 开始试，能起来就立刻用 mysqldump 把能导的数据导出来。
常见报错原文：
Job for mysql.service failed because a timeout was exceeded. —— 启动时在等某个锁，加 TimeoutStartSec=300 到 service 覆盖文件里。
mysqld: Could not open file '/var/log/mysql/error.log' for error logging. —— 日志目录不存在或权限不对，sudo mkdir -p /var/log/mysql && sudo chown mysql:mysql /var/log/mysql 后重启。
止损点在哪：写清楚自己的止损顺序。 我的建议是——先确认快照或备份存在，再做硬重启；硬重启后 30 分钟内数据服务仍起不来，先导出可导数据再考虑重装系统；重装前必须确认「配置已记录在别处」，否则你会花一整天重建环境。
五、崩溃后的取证清单：把这三项存下来
每次崩溃后立刻执行下面这段脚本，把现场打包存到别处。 这是本文最实用的一段命令，建议直接存成 ~/crash-collect.sh：
#!/bin/bash
TS=$(date +%Y%m%d-%H%M%S)
OUT=/root/crash-$TS
mkdir -p $OUT
# 1) 内核日志（OOM 证据在这里）
sudo dmesg -T > $OUT/dmesg.txt 2>&1
sudo journalctl -k --since "-2 hours" > $OUT/journal-k.txt 2>&1
# 2) 服务日志
for s in nginx mysql php-fpm php8.1-fpm php8.3-fpm; do
sudo journalctl -u $s -n 500 --no-pager > $OUT/journal-$s.txt 2>&1
done
# 3) 资源快照
free -m > $OUT/free.txt 2>&1
uptime > $OUT/uptime.txt 2>&1
ps -eo pid,ppid,comm,rss,vsz --sort=-rss | head -40 > $OUT/ps.txt 2>&1
sudo swapon --show > $OUT/swap.txt 2>&1
ss -s > $OUT/ss.txt 2>&1
df -h > $OUT/df.txt 2>&1
# 4) 磁盘占用（大文件是占满磁盘的主因）
sudo du -xh / --max-depth=2 2>/dev/null | sort -rh | head -30 > $OUT/du.txt 2>&1
tar czf $OUT.tar.gz -C /root $(basename $OUT)
echo "打包完成: $OUT.tar.gz"关于取证的三条经验：
第一，dmesg 的证据会消失。 很多系统配置了 dmesg_restrict 或日志轮转，重启后 dmesg -T 只剩当前启动周期的内容。所以必须在大硬重启之前先打包。 如果已经重启了，就只能靠 journalctl -k --list-boots 翻历史启动记录：
journalctl --list-boots
journalctl -b -1 -k | grep -i oom第二，du 命令要加 -x。 不加 -x 会跨越挂载点，去扫远程挂载或者巨大的虚拟文件系统，命令可能跑几十分钟不结束。在 1GB 内存的机器上跑一个失控的 du，本身就是把机器推向第二次崩溃。
第三，磁盘比内存更容易先出问题。 很多站点「崩溃」其实是磁盘写满导致 MySQL 无法写入而退出。df -h 里 / 超过 85% 就要处理了。
磁盘占满的清理顺序（按安全度从高到低）：
sudo journalctl --vacuum-size=100M
sudo apt clean && sudo apt autoremove
docker system df && docker image prune -a --filter "until=168h"
sudo find /var /home /opt -xdev -type f -size +500M -exec ls -lh {} \; 2>/dev/null第三条只在用 Docker 时需要。 第四条命令在 1GB 内存的机器上慎用不带 -x 的全盘 find——它会跨越挂载点遍历整个文件系统，遇到大文件时 page cache 会被撑满，反而触发一次 OOM，等于为了排查崩溃把机器又搞崩了一次。 所以上面已经把搜索范围限制在 /var /home /opt。
journalctl --vacuum-size=100M 几乎总是安全的，但前提是你不需要保留历史日志做审计。 如果日志是排查入侵的唯一证据，先 journalctl --vacuum-time=7d 导出到别处再清理。
还有一个常被忽略的磁盘占用来源：已删除但仍被进程占用的文件。 用 lsof +L1 能查出来：
sudo lsof +L1 | head -20输出里的文件大小是「已删除但仍占着磁盘」的空间，只有在占用它的进程退出后才真正释放。最常见的场景是删了巨大的日志文件但没重启服务，于是磁盘一点没腾出来。 处理办法是重启对应服务，而不是继续删文件。
最后是备份策略的最低要求，崩溃后能不能救回来取决于这一条。 至少做到「数据库每天异地一份、配置每次改动后留一份」：
sudo crontab -e
17 3 * * * mysqldump --single-transaction --quick dbname | gzip > /backup/db-$(date +\%F).sql.gz--single-transaction 是不锁表导出 InnoDB 表的关键参数，不加它在数据量大时会锁表，导出过程本身可能把站点拖垮。--quick 让 MySQL 边读边写，不把整张表缓存到内存。 这两个参数在小内存机器上尤其重要。
注意 crontab 里的 % 必须写成 \%。 这是 crontab 的历史遗留设计，不转义会导致语法错误或命令被截断。这是新手最常踩的 cron 坑之一，报错现象是「cron 任务就是不执行，但 crontab -l 看着完全正常」。
六、算账：不同内存档位一个月能扛多少次崩溃
处理崩溃的核心不是「修好这一次」，是「选一台扛得住的机器」。 这一节用公开商品库的报价把账算清楚。
先确立单位成本。 按商品库 2026-11-11 09:33 的快照，折合每 GB 内存的价格是：RosCloud-06（24GB，69.99 美元/月）2.92 美元/GB、RosCloud-05（16GB，59.99 美元/月）3.75 美元/GB、RosCloud-04（8GB，49.99 美元/月）6.25 美元/GB、RosCloud-03（4GB，39.99 美元/月）10.00 美元/GB、RosCloud-02（2GB，29.99 美元/月）14.99 美元/GB、RosCloud-01（1GB，19.99 美元/月）19.99 美元/GB。
折合每 GB 硬盘：RosCloud-06 是 0.219 美元、RosCloud-05 是 0.25 美元、RosCloud-04 是 0.312 美元、RosCloud-03 是 0.5 美元、RosCloud-02 是 0.75 美元、RosCloud-01 是 0.999 美元。
这条曲线的含义是明确的：内存档位越大，单位内存越便宜，但便宜的幅度在递减。 从 1GB 到 2GB，单位成本从 19.99 降到 14.99，降了 25%；从 8GB 到 16GB，从 6.25 降到 3.75，相对降幅只有 40%，绝对差距也远不如前一次明显；再往上从 16GB 到 24GB，只从 3.75 降到 2.92。
现在算「一次崩溃的代价」。 假设你的站点平均每个 PV 传输 100KB，流量除以 0.1MB 就是 PV 上限。按商品库标注的月流量：
| 机型 | 内存 | 月流量 | 可承载 PV（100KB/PV） |
|---|---|---|---|
| RosCloud-01 | 1GB | 1024GB | 约 1073 万 |
| RosCloud-02 | 2GB | 2048GB | 约 2147 万 |
| RosCloud-03 | 4GB | 3072GB | 约 3221 万 |
| RosCloud-04 | 8GB | 4096GB | 约 4295 万 |
| RosCloud-05 | 16GB | 5120GB | 约 5369 万 |
| RosCloud-06 | 24GB | 6144GB | 约 6442 万 |
看这张表的比值：从 1GB 到 8GB，PV 上限只从 1073 万涨到 4295 万，涨了 4 倍而不是 8 倍，因为流量总额是跟着配置走的而不是翻倍。 这告诉你一个关键事实：小内存机器在流量效率上并不吃亏，买小机器不是「浪费流量额度」，而是「用更少的钱覆盖当前需求」。
真正的账在崩溃次数上。 假设一个站点每月因为 OOM 崩溃 3 次，每次恢复耗时 25 分钟（含诊断、重启、验证），恢复期间 PV 损失按每秒 20 PV 估算，一次崩溃损失 20 × 60 × 25 = 30000 PV。每月因崩溃损失 90000 PV。
如果你的站点日均 10 万 PV，一台 1GB 机器的月流量 1024GB 按 100KB/PV 折算能支撑约 1073 万 PV/月，看起来流量够用；但内存 1GB 在跑 MySQL 加 PHP-FPM 时常态就已经占用 600MB 以上，谷值轻松超过 60% 阈值，属于本文第三节表格里的「谷值偏高」一档。 这时候崩溃不是偶发，是每周一次。
结论很直白：如果你的站点会崩，1GB 档位省下的 20 美元会被「每月多崩 2 次 × 每次 25 分钟」吃掉。 直接选 4GB 档位（RosCloud-03，39.99 美元/月）是更理性的决策。
另一种算法是「崩溃恢复成本 × 崩溃频率」对比「升配的年成本」：
升一档内存的增量成本：RosCloud-01 → RosCloud-02 是 10.00 美元/月（每年 120 美元）；RosCloud-02 → RosCloud-03 是 10.00 美元/月；RosCloud-03 → RosCloud-04 是 10.00 美元/月；RosCloud-04 → RosCloud-05 是 10.00 美元/月；RosCloud-05 → RosCloud-06 是 10.00 美元/月。
每档固定增加 10 美元/月。换句话说：「每月多花 10 美元换一个数量级的稳定性」是这条产品线里最干净的决策路径。 只要你的站点当前因为内存问题每月崩溃 2 次以上，这 10 美元几乎立刻回本——每次崩溃的代价是 25 分钟不可用加上你半夜被叫醒排查的隐性成本。
七、算账：换机房和换线路的性价比对比
有时候崩溃的根因不是配置，是机房。 比如某台机器的磁盘经常出现 I/O 错误、或者网络频繁丢包导致 SSH 断连——这类问题加内存一点用没有。
商品库里有一组可以直接对比的同配置不同机房机型：LAX-STARTER（2 核 2GB 40GB 2000Mbps 5000GB 流量，200 美元年付，折合 16.67 美元/月，洛杉矶）、Residential-STARTER（同配置，260 美元年付，折合 21.67 美元/月，住宅 IP）、IRVINE-PRO-STARTER（同配置，350 美元年付，折合 29.17 美元/月，尔湾优化线路）。
三台机器配置完全一样，价格却差 12.50 美元/月和 7.50 美元/月。 差价不是配置换来的，是机房位置和线路类型换来的。
如果你的站点崩溃时伴随「SSH 时断时续」「控制台显示网络异常」，那问题在网络不在内存。 这时候加内存是纯浪费，应该把钱花在换线路上。同样的 2GB 内存配置，换成优化线路机型的增量是 12.50 美元/月。
反过来，如果你确认崩溃是 OOM 引起的，换机房一分钱都不该多花。 校验方法：崩前后各跑一次 sudo dmesg -T | tail -50，如果两次都看到 Killed process，那和线路无关，是内存不够。
另一组值得对比的是带宽单位成本。 sixtynet 的 LAX-MICRO（4 核 4GB 80GB，4000Mbps，10000GB 流量）折合月价 33.33 美元，每 Mbps 带宽 0.0083 美元；LAX-Storage-500G（4 核 4GB 500GB，10000Mbps，10000GB 流量）折合月价同样 33.33 美元，每 Mbps 带宽 0.0033 美元，硬盘每 GB 只要 0.067 美元。两台机器月价一样，一台带宽 4000Mbps 硬盘 80GB，一台带宽 10000Mbps 硬盘 500GB。 如果你的崩溃伴随大文件下载、备份同步或者视频转码拖慢整站，那该选的是后一台，钱要花在带宽和 IOPS 上，不是花在内存上。
这一节还要算另一个账：年付和月付的差价。 sixtynet 的 LAX-MICRO 是 400 美元年付，折合 33.33 美元/月；RosCloud 的 RosCloud-03 是 39.99 美元月付。年付看起来贵一倍，但折合月价后其实是同一量级。
对比同配置的三档：LAX-STARTER 200 美元年付折合 16.67 美元/月、Residential-STARTER 260 美元年付折合 21.67 美元/月、IRVINE-PRO-STARTER 350 美元年付折合 29.17 美元/月。 三个机型的内存、硬盘、带宽、流量完全相同（2 核 2GB 40GB 2000Mbps 5000GB），唯一的差别就是机房和线路。
所以「哪家更划算」这个问题本身是错的，正确的问题是「哪种线路对应我的访客分布」。 访客在国内，选优化线路机型，那 12.50 美元/月的差价买的是延迟；访客在北美本地，普通机房机型就够；需要住宅 IP 规避风控的，住宅机型的 5 美元/月差价也是必要的。这三档没有优劣，只有匹配和不匹配。
另一个必须纳入考虑的成本维度是流量超额单价。 商品库里明确给出了超额流量的重置价格：
| 机型 | 月流量 | 超额重置价 | 每 TB 超额成本 |
|---|---|---|---|
| 云途 HK.DS.M | 10000GB | 200 元 | 20.48 元 |
| 云途 DS.ES.F | 10000GB | 200 元 | 20.48 元 |
| 云途 HK.DS.P | 40000GB | 500 元 | 12.80 元 |
| 云途 HK.DS.S | 40000GB | 500 元 | 12.80 元 |
| 云途 DS.ES.B | 30000GB | 450 元 | 15.36 元 |
结论很实用：如果流量可能会超，选额度大的那档比选额度小但单价低的更划算。 云途 HK.DS.M 超额每 TB 20.48 元，HK.DS.S 是 12.80 元，便宜了 37.5%——每月超 1TB 流量，一年能省下 92.16 元。
反过来也要注意带宽与流量的不匹配。 云途 HK.DS.B 是 128GB 内存、2000GB 硬盘，但带宽只有 1000Mbps，是同厂其他机型的一半。它适合「大内存大硬盘、流量中等」的负载，比如数据库集群或大数据处理，不适合跑高并发访问的网站。 判断方法：你的业务是「每个人下载很多」还是「很多人各下载一点」？ 前者看带宽，后者看流量。
RosCloud 和 sixtynet 的机型没有列出超额流量重置价，所以流量超额成本需要按官网当日报价为准，本文不做推算。 这也意味着：如果预计流量会超，优先考虑明确标注了重置价的方案，因为你能算出上限成本；没有标注的方案，超额成本是个未知数。
八、什么情况下不该选更大的配置（缺陷分析）
这一节讲的是「什么时候加内存是错的」。 依据只用公开事实：机房位置、线路类型、计费方式、IP 资源类型。
场景一：崩溃是磁盘写满导致的，加内存完全无效。 判断依据是 df -h 显示 / 使用率超过 85%，以及 dmesg 里没有 OOM 记录而是 EXT4-fs error 或 no space left on device。磁盘问题和内存问题在日志里是能分辨开的：OOM 有 Out of memory: Killed process 字样，磁盘满有 no space left 或 I/O error。 此时加内存一台钱都不值，替代方案是清理日志和上传目录（用上一节的 journalctl --vacuum-size 和 du -x 定位），或者直接换一台硬盘更大的机型——商品库里 LAX-Storage-500G 的硬盘是 500GB，每 GB 0.067 美元，LAX-Storage-1TB 是 1000GB，每 GB 0.058 美元，硬盘单价是所有机型里最低的一档。买内存前先确认崩溃原因，别买错了地方。
场景二：崩溃是 DDoS 导致的，加内存无效。 判断依据是崩溃前流量曲线突然垂直上升，同时 dmesg 干净、free -m 显示内存有大量剩余。这种情况的替代方案不是升配，而是加防御或改用带清洗能力的线路。 商品库里的 Los Angeles China Unicom-Premium 折合月价 208.33 美元，带宽只有 100Mbps 且不含流量配额，产品定位就是线路质量而非性能，对于只要求线路稳定、不跑高并发业务的场景，它比高配通用机型更合适。 反过来，如果你需要的是抗攻击吞吐，那 100Mbps 的端口本身就是瓶颈。
场景三：站点是纯静态或定时任务，加内存是浪费。 判断依据是 ps 输出里没有 php-fpm 和 mysqld，或者两者 RSS 都很小。纯静态站加定时脚本，稳定态内存占用通常在 200MB 以内，1GB 机器的谷值能压在 15% 阈值内。 这种情况下 RosCloud-01（19.99 美元/月，1GB，1024GB 流量）足够，虽然它的单位流量成本 19.99 美元/TB 是 RosCloud-06（11.665 美元/TB）的 1.7 倍——但这不重要，因为你的流量用不完，配置成本才是真实支出。 别为「以后可能要用」提前付费。
场景四：需要多个独立 IP 的场景，加内存解决不了 IP 资源问题。 依据是 IP 资源类型和数量是独立于内存的采购项。商品库显示 RosCloud 系列每台都是 1 个 IPv4，云途系列标注为「IPv4（原页未注明具体数量）」，这意味着多 IP 需求要单独确认。如果你的业务依赖多个 IP（比如做 SEO 站群、或者需要为不同服务分配不同出口），那么加内存解决不了 IP 不够的问题，正确做法是选按 IP 数量计费的方案或直接咨询商家确认可分配数量。
场景五：你的业务有严格的时间延迟要求，加内存帮不了回程线路。 依据是机房位置和线路类型。中国大陆访客访问美国西海岸机房，物理距离决定了延迟下限，加多少内存都改不了光速。 替代方案是选择面向国内优化的线路机型——同配置下 LAX-STARTER 16.67 美元/月、IRVINE-PRO-STARTER 29.17 美元/月，差价 12.50 美元/月，买的是线路不是配置。同理，如果访客主要在东南亚，则应该看香港节点，云途 HK.DS.M 是 350 元/月（32GB 内存、480GB 硬盘、1000Mbps 带宽、10000GB 流量），它的每 GB 内存成本 10.94 元、每 TB 流量 35.84 元，是国内访问延迟最低的那一档。
九、给三类人的具体推荐（别写视情况而定）
如果你属于下面三类中的一类，直接照做，不用再比了。
第一类：个人博客、WordPress 小站，日均 1 万 PV 以内。 你的需求是「跑起来不崩就行」。选 2GB 内存、40GB 硬盘、含 5000GB 以上流量的入门档。 具体可以是 LAX-STARTER（16.67 美元/月，2 核 2GB 40GB，5000GB 流量，2000Mbps 带宽）或 Residential-STARTER（21.67 美元/月，同配置，住宅 IP）。为什么不是最便宜的 1GB： 1GB 机器跑 MySQL 加 PHP-FPM 谷值就超过 60% 阈值，属于「随时会崩」的区间；2GB 的谷值能压在 30% 以内，峰值也有余量。为什么不是 4GB： 你用不到，多花的 13.32 美元/月（LAX-MICRO 33.33 对 LAX-STARTER 16.67）是你收入的百分之几，没有意义。上线后 30 天去看一次 free -m 的谷值，低于 15% 说明买对了。
第二类：有真实业务（日均 10 万 PV 起）、跑商城或带后台的业务系统、或者过去 3 个月崩溃过 3 次以上。 选 4GB 内存起步、8GB 硬盘起步、流量 3000GB 以上的档位，并且一定要有 swap。 具体可以是 RosCloud-03（39.99 美元/月，4 核 4GB 80GB 硬盘，500Mbps，3072GB 流量）、LAX-MICRO（33.33 美元/月，4 核 4GB 80GB，4000Mbps，10000GB 流量）或云途 DS.ES.C（700 元/月，64GB 内存，800GB 硬盘，2000Mbps，40000GB 流量）。这一类的核心不是挑最便宜的，是挑「崩溃一次你不用半夜爬起来」的。 按前面算的账，每升一档加 10 美元/月，1GB 到 8GB 全走完是每月多 30 美元，换来的是从「每周崩」到「基本不崩」。同时把上一节的取证脚本挂到定时任务里，每小时存一次 free -m 和 dmesg 摘要，崩溃前你就有证据。
第三类：跑 PHP 8.3 加 OPcache 加多站点、或者做站群和采集的主力机。 选 8GB 以上内存，硬盘按站点数量算，流量按 10000GB 起步。 具体是 LAX-MEDIUM（66.67 美元/月，8 核 8GB 160GB，10000Mbps，20000GB 流量，每 GB 内存 8.33 美元）、RosCloud-04（49.99 美元/月，5 核 8GB 160GB，500Mbps，4096GB 流量，每 GB 内存 6.25 美元）或者云途 HK.DS.S（800 元/月，128GB 内存，6000GB 硬盘，2000Mbps，40000GB 流量，每 GB 内存 6.25 元）。这一类必须自己算一件事：内存里除了 PHP 和数据库，还留不留得下 OPcache 和队列。 按 8GB 机器预留 384MB 给系统、每个 PHP-FPM worker 占 128MB 算，理论上能开 61 个 worker；实际配置应该留一半余量，开 30 个左右，剩下 4GB 给 OPcache 和数据库。同时确认流量够用——商品库标注的 40000GB 流量按 100KB/PV 折算能支撑约 4.19 亿 PV/月，对绝大多数站群远远过剩，真正的约束是内存而不是流量。
这之外的第四种情况——做视频转码、跑大数据处理、或者需要 10000Mbps 满速跑大文件传输—— 选 LAX-Storage-500G（33.33 美元/月，10000Mbps，500GB 硬盘，每 GB 内存 8.33 美元，每 GB 硬盘 0.067 美元）或 LAX-Storage-1TB（58.33 美元/月，10000Mbps，1000GB 硬盘，每 GB 硬盘 0.058 美元）。它们的内存不大，但硬盘单价和带宽单价是全库最低的档，因为定位就是存储与带宽型机器。 用错方向（给转码机买大内存）是这类场景最常见的浪费。
按你的情况，下一步该看哪家
上面讲的是判断标准，但多数人最后还是想问一句「那我该买谁」。按你的实际情况对照下面几条，直接去看对应的机型页比继续比价更快：
- 只想搭个站、预算优先：先看价格最低那档够不够用，别为用不上的配置付钱。看 iwebfusion 当前机型与价格
- 主要访客在国内、在意打开速度：先确认回程线路，再谈配置。看 racknerd 当前机型与价格
- 只是开发测试、临时用：按小时或月付，用完就删，别买年付。看 cloudcone 当前机型与价格
价格与库存以商家页面当日显示为准，下单前建议先确认退款窗口与是否支持按月付费。
十、上线后的预防：把这四项做成日常
处理崩溃的价值有一半在「防止下次再崩」。 四件事，配置一次，长期受益。
第一，swap 必须存在。 上一节的 fallocate 加 swapon 加 fstab 三条命令做一次。判断标准：free -m 的 Swap 行不是 0。 1GB 机器建议 2GB swap，2GB 机器建议 2GB，4GB 以上建议 1GB 就够。
第二，PHP-FPM 的 worker 数要设上限。 配置文件在 /etc/php/版本号/fpm.d/www.conf，三个关键项：
pm = dynamic
pm.max_children = 30
pm.max_requests = 500pm.max_children 不能超过你按内存算出来的上限。 按 4GB 机器预留 384MB 系统、128MB 每 worker 算是 29 个，取 30 刚好卡在边界——所以实际上应该配 25，把余量留给 OPcache 和数据库。
pm.max_requests = 500 这一行治的是内存泄漏。 每个 worker 处理 500 个请求后重启，把累积的内存泄漏清掉。如果你的 worker 数设对了但内存还是慢慢涨，先查这个值。
第三，MySQL 的 buffer pool 要按内存改。 在 /etc/mysql/ 下的配置文件里设置：
[mysqld]
innodb_buffer_pool_size = 512M
max_connections = 50
tmp_table_size = 32M
max_heap_table_size = 32M4GB 机器上 512M 是合理起点（留一半给其他），2GB 机器上设 256M。 max_connections = 50 对小站是够的——每个连接在 MySQL 侧的内存开销约 1MB 到 2MB，100 个连接就是 100MB 到 200MB，这是 1GB 机器崩溃的常见隐藏原因。改完重启后用 SHOW VARIABLES LIKE 'innodb_buffer_pool_size'; 确认生效。
第四，加监控。 三个数字盯住就够了：内存谷值百分比（应低于 15%）、磁盘使用率（应低于 80%）、5 分钟平均负载（应低于 CPU 核数）。 用一条 cron 每 10 分钟采集并超阈值告警：
*/10 * * * * /usr/local/bin/mem-watch.sh >> /var/log/mem-watch.log 2>&1脚本里判断内存谷值的写法（用 free 输出换算百分比）：
TOTAL=$(free -m | awk 'NR==2{print $2}')
USED=$(free -m | awk 'NR==2{print $3}')
PCT=$((USED * 100 / TOTAL))
if [ "$PCT" -gt 85 ]; then
echo "ALERT mem=${PCT}% used=${USED}MB total=${TOTAL}MB"
fi关于这个脚本有两个容易出错的地方。 第一，free -m 的第二行第二列是 total，第三列是 used，列的位置在不同版本里可能差一列，所以要先跑一次 free -m 看清列序再写脚本，写错列会一直误报。第二，用的是瞬时值不是谷值。 瞬时值超过 85% 报警是合理的，但如果想做真正的谷值监控，应该每 10 分钟采一次、写进日志，然后每天取最小值。
更完整的监控应该同时看三个数字，缺一不可：内存谷值百分比（标准低于 15%，留出应对突发的余量）、磁盘使用率（标准低于 80%，比内存宽松是因为磁盘写满是慢性问题，80% 给你留出清理窗口）、5 分钟平均负载（标准低于 CPU 核数，高于核数说明已有进程在排队）。
看负载的命令和解读：
cat /proc/loadavg
# 输出三个数字：1分钟 5分钟 15分钟的平均负载第一个数字高、后两个低，说明是刚出现的尖峰；三个数字持续高，说明是持续过载。 持续过载时该做的是加 CPU 核数，或者找出会话和定时任务里的慢查询。
顺带说一个和崩溃高度相关的监控项：OOM 事件计数。
grep -i oom /proc/vmstat输出里的 oom_kill 字段就是这个系统启动以来触发 OOM Killer 的次数。 做成 cron 任务，每次采集后和上次比较，差值大于 0 就说明这段时间内发生过 OOM。这比解析日志更轻量，适合小内存机器。
最后一个必做项：限制日志大小。 日志无上限增长是磁盘崩溃的头号原因：
# /etc/logrotate.d/myapp
/var/log/myapp/*.log {
daily
rotate 7
compress
delaycompress
missingok
notifempty
copytruncate
}copytruncate 是关键：先复制日志再清空原文件，不用重启服务就能释放空间。 如果你的应用不支持 reopen，用 postrotate 加上 systemctl reload 更稳妥。
这四项配完之后，机器就具备了「崩溃前兆可见、崩溃根因可查」的完整闭环。 接下来的问题变成选哪一档配置——这正是第六节和第九节要回答的。
十一、常见报错速查表
把散落在前面各节的报错集中在一张表里，方便你排查时直接查。
| 报错原文 | 含义 | 处理 |
|---|---|---|
Out of memory: Killed process |
内存耗尽，内核杀了进程 | 加内存、改 worker 数、加 swap，见第三节 |
no space left on device |
磁盘写满 | 清日志、清上传目录，见第五节 |
Failed to start nginx.service: Unit nginx.service not found. |
服务名不对 | systemctl list-units 查真实服务名 |
nginx: [emerg] unknown directive |
配置里有解析不了的行 | nginx -t 定位，通常是中文注释或缺少分号 |
Job for mysql.service failed because a timeout was exceeded. |
启动超时等锁 | service 覆盖文件加 TimeoutStartSec=300 |
InnoDB: corruption detected in tablespace |
InnoDB 启动失败 | innodb-force-recovery=1 起步，能起来就导出数据 |
mysqld: Could not open file '/var/log/mysql/error.log' |
日志目录不存在或权限不对 | mkdir -p /var/log/mysql && chown mysql:mysql /var/log/mysql |
Could not open '/proc/net/tcp' |
容器里没挂 proc 网络视图 | 改用 netstat -tulnp |
systemd[1]: Failed to start ... Unit not found |
unit 文件被删或路径错 | systemctl daemon-reload 后重试 |
Killed 出现在 dmesg 且进程名是 sshd |
SSH 被 OOM 杀掉 | 属 OOM 类，换机器或加内存 |
read-only file system |
根分区被重挂为只读 | 先备份配置，fsck 后修 fstab 挂载参数 |
「read-only file system」这一条要特别提醒：出现这个错误说明内核已经把分区降级为只读保护数据，此时任何写入都会失败。 处置顺序是先用另一台机器备份 /etc/fstab 和重要配置，然后 fsck 修复，修好后用 mount -o remount,rw / 尝试恢复写权限。不要在只读状态下强行写入，那会损坏超级块。
十二、完整决策清单：30 分钟走完一遍
把全文压缩成一个可以照着走的清单。
第 1 步（3 分钟）：分类。 执行 uptime、free -m、dmesg -T | grep -i oom、systemctl status nginx mysql。有 OOM 记录走第二类，服务活着但 502 走第一类，SSH 都连不上走第三类。
第 2 步（10 分钟）：取证。 执行第五节的 ~/crash-collect.sh。这一步不能省，因为下次崩溃时这些日志是唯一证据。
第 3 步（5 分钟）：判定根因。 对照下表：
| 现象 | 根因 | 该花钱的地方 |
|---|---|---|
Killed process + 内存谷值高 |
内存不够 | 内存，每档 +10 美元/月 |
no space left |
磁盘满 | 硬盘，LAX-Storage 档每 GB 0.058–0.067 美元 |
| 内存有富余，流量曲线垂直上升 | 攻击或流量尖峰 | 防御或高带宽线路 |
| 内存有富余，SSH 时断时续 | 线路问题 | 优化线路，IRVINE-PRO 档 +12.50 美元/月 |
| 内存有富余，硬盘 I/O 报错 | 存储介质 | 换 NVMe 机型 |
第 4 步（5 分钟）：定性阈值。 采 5 分钟内存曲线，按第三节的表判断谷值与峰值。谷值高于 40% 就该动手了，不用等崩溃。
第 5 步（7 分钟）：选配置。 按第九节的三类人定位表直接选。核心结论不变：每升一档加 10 美元/月，1GB 到 8GB 是每月 30 美元；如果你每月崩溃 2 次以上，这笔钱在第一次崩溃时就回本了。
最后一句话的建议：下单前先按月付跑一个月，把 free -m 谷值、dmesg 里的 OOM 记录、df -h 的磁盘使用率三个数字记下来，一个月后再决定要不要转年付。 转年付能省下不少钱——sixtynet 的年付机型折合月价只有 16.67 到 138.33 美元——但只有在你已经确认配置够用之后才值得，否则年付半年发现不够用，换机成本比省下的钱多。
喜欢 
高兴
鬼脸
呵呵
无聊
伤心
