一、拿到手的第一小时:先确认你拿到的是什么

大部分教程从「输入 IP 开始」,但真正省时间的第一步是先花五分钟把商家给你的配置和你预期的对上。这一步做对了,后面所有操作都顺;跳过这一步,常见后果是装完一堆环境才发现磁盘只有 20 GB。
第一步:核对交付清单。 商家交付时通常会给出这几项,逐项确认:
| 项目 | 怎么核对 | 对不上时怎么办 |
|---|---|---|
| IP 地址 | 与购买页填写的 IP 一致 | 立刻联系客服,可能是分配错了 |
| SSH 端口 | 与商家面板一致,非默认 22 时必须记下 | 用错端口会直接超时 |
| 初始密码或密钥 | 尝试登录一次 | 密码过期需重置 |
| 系统版本与位数 | 登录后看内核版本 | 与你要装的软件不匹配要重装 |
| 磁盘与内存 | 用系统命令读实际值 | 与订单不符要申请换机 |
| 流量配额与带宽 | 记下数值,后面要做监控 | 记清楚可以避免超额 |
# 登录后第一组命令:把实际硬件读出来
# 内存总量与 CPU 核数
free -h && nproc
# 磁盘容量与挂载点,注意看实际挂载的是哪块盘
lsblk -f && df -h
# 内核版本与架构,判断能装什么包
uname -a
# 公网 IP 与网卡,确认这张网卡对外
ip addr show | grep inet
# 系统版本
cat /etc/os-release | head -3
第二步:把上面这组输出和你订单上的配置对一遍。 这一步之所以重要,是因为内存和磁盘是 VPS 里最容易出现「订单与实物不符」的地方——尤其是超售机型,宣传页写的是标称值,实际分配的可能打了折扣。核对不上的处理方式很简单:拍下命令输出,直接申请换机或调整,不要将就。 迁就一台配置不达标的机器,比换机的时间成本高得多。
第三步:确认这台机器在你手里的定位。 新买的 VPS 一般有两种初始状态:已装好面板(宝塔、aaPanel 之类)和纯净系统(只有最小化 SSH 环境)。这两种的上手路径完全不同,下面的教程以纯净系统为主线。
如果商家给的是已装面板的机器,判断标准很简单:看有没有 /www/server 这类目录、看 systemctl 里有没有面板服务。 有面板的话,面板本身会接管防火墙、数据库、Nginx 的管理,此时手工改系统配置反而容易和面板打架——下面的命令要结合面板的实际情况调整,不能盲目照抄。
第四步:确认这台机器的地理位置和线路类型。 这一步和上面的核对一样,属于「交付清单」的一部分,不该等到出问题才问。机房位置决定了首字节延迟的物理下限,线路类型决定了这条路径的实际质量,而这两样在机器到手后是无法更改的。在下单前问清楚「这台机器在哪个机房、走的是哪种回程线路」,比事后补救便宜得多。
第五步:问清楚这台机器的流量配额是多少,以及超额之后按什么标准收。 渠道库里有些机型明确标注了超额重置价,这意味着流量跑超之后的账单不是按比例算的,而是一个固定的、可能接近月租的数字。在开始跑业务之前知道这个数字,比流量真的跑超之后再知道要好得多。
二、第 0 步先算账:这台机器该买多大、每月要花多少

在使用教程之前必须先算一笔账,因为算账的结果会反过来改写你后面每一步的操作——配置买多大、装什么环境、要不要做这些优化,全部由它决定。而且算账还能直接帮你省钱:同一份钱在不同档位上买到的单位成本差了好几倍。
单位成本是唯一能横向比较的口径。 直接比总价会得出错误结论:RosCloud-01 是 19.99 美元/月,LAX-LARGE 是 133.33 美元/月,看起来差了 6 倍多;但按每 GB 内存每月算,前者是 19.99 美元,后者是 8.33 美元,后者的单位内存成本只有前者的 42%。
下面这张表是渠道库在售机型按月价折算后的单位成本:
| 机型 | 折合月价 | 内存 | 硬盘 | 月流量 | 每 GB 内存/月 | 每 GB 硬盘/月 | 每 TB 流量/月 |
|---|---|---|---|---|---|---|---|
| RosCloud-01 | 19.99 美元 | 1 GB | 20 GB | 1024 GB | 19.99 美元 | 1.00 美元 | 19.99 美元 |
| RosCloud-02 | 29.99 美元 | 2 GB | 40 GB | 2048 GB | 15.00 美元 | 0.75 美元 | 15.00 美元 |
| RosCloud-03 | 39.99 美元 | 4 GB | 80 GB | 3072 GB | 10.00 美元 | 0.50 美元 | 13.33 美元 |
| RosCloud-04 | 49.99 美元 | 8 GB | 160 GB | 4096 GB | 6.25 美元 | 0.31 美元 | 12.50 美元 |
| RosCloud-05 | 59.99 美元 | 16 GB | 240 GB | 5120 GB | 3.75 美元 | 0.25 美元 | 12.00 美元 |
| RosCloud-06 | 69.99 美元 | 24 GB | 320 GB | 6144 GB | 2.92 美元 | 0.22 美元 | 11.67 美元 |
| LAX-STARTER | 16.67 美元 | 2 GB | 40 GB | 5000 GB | 8.33 美元 | 0.42 美元 | 3.41 美元 |
| LAX-MICRO | 33.33 美元 | 4 GB | 80 GB | 10000 GB | 8.33 美元 | 0.42 美元 | 3.41 美元 |
| LAX-MEDIUM | 66.67 美元 | 8 GB | 160 GB | 20000 GB | 8.33 美元 | 0.42 美元 | 3.41 美元 |
| LAX-LARGE | 133.33 美元 | 16 GB | 320 GB | 40000 GB | 8.33 美元 | 0.42 美元 | 3.41 美元 |
| LAX-Storage-500G | 33.33 美元 | 4 GB | 500 GB | 10000 GB | 8.33 美元 | 0.07 美元 | 3.41 美元 |
| LAX-Storage-1TB | 58.33 美元 | 8 GB | 1000 GB | 15000 GB | 7.29 美元 | 0.06 美元 | 3.98 美元 |
这张表能读出三条硬结论:
第一条:内存单价随容量递减,且递减得很陡。 RosCloud 系列从 01 到 06,每 GB 内存的单价从 19.99 美元掉到 2.92 美元,降了 85%。如果你真的需要 8 GB 内存,买 RosCloud-04(49.99 美元)比买四台 RosCloud-01 更划算,而且省掉四倍的运维成本和四个公网 IP。小内存单机便宜但每 GB 极贵,是典型的入门价陷阱。
第二条:硬盘单价是独立于内存的另一条曲线。 LAX-Storage-500G 的每 GB 硬盘只要 0.07 美元,是全表最低,比同内存的 LAX-MICRO(0.42 美元)低 83%。所以当你需要的是大硬盘而不是大内存时,正确的做法是把预算花在硬盘档位上,而不是去凑内存档位。 同一个厂商的云途系列更能说明问题:HK.DS.S 是 800 元人民币/月、128 GB 内存、6000 GB 硬盘,折合每 GB 内存 6.25 元、每 GB 硬盘 0.13 元;而 DS.ES.A 同样 800 元,只有 32 GB 内存和 800 GB 硬盘,折合每 GB 内存 25.00 元、每 GB 硬盘 1.00 元。同价位的两个档位,单位成本能差 4 倍,不算清楚就买贵了。
第三条:流量单价和总配额要一起看。 LAX 系列每 TB 流量都在 3.41 美元左右,但注意 LAX-Storage-1TB 的总流量只有 15000 GB,比 LAX-MEDIUM 的 20000 GB 少,单价 3.98 美元反而更高。「流量够不够」是绝对值问题,「流量买得贵不贵」是单价问题,两个都要算。
把单位成本倒推回用途,就得到一张配置对照表:
| 你的用途 | 内存下限 | 硬盘 | 月流量 | 可参考机型 | 月成本 | 单位内存成本 |
|---|---|---|---|---|---|---|
| 纯静态展示页、下载页 | 2 GB | 40 GB | 5000 GB | LAX-STARTER | 16.67 美元 | 8.33 美元 |
| WordPress 等带后台的动态站 | 4 GB | 80 GB | 10000 GB | LAX-MICRO | 33.33 美元 | 8.33 美元 |
| Node/Python 常驻服务加 Redis | 8 GB | 160 GB | 20000 GB | LAX-MEDIUM | 66.67 美元 | 8.33 美元 |
| 大资源量静态站、视频分发 | 4 GB | 500 GB | 10000 GB | LAX-Storage-500G | 33.33 美元 | 8.33 美元 |
| 内存吃得多的批量任务 | 16 GB | 240 GB | 5120 GB | RosCloud-05 | 59.99 美元 | 3.75 美元 |
这张表里最值得注意的一行是最后一行:内存吃得多的场景,单位成本反而最低。 RosCloud-05 的 3.75 美元/GB/月 只有 LAX 系列的 45%,如果你确定要用到 16 GB 以上内存,别在 LAX 系列里选,直接看 RosCloud 的大内存档位。
还有一笔账不能漏:超额流量的重置价。 渠道库明确记录了云途各档位的超额重置价——HK.DS.M 和 DS.ES.F 是 200 美元,DS.ES.C、HK.DS.P、HK.DS.S 是 500 美元,DS.ES.B 是 450 美元。对比它们 350、399、700、750、800、1500 元人民币的月租,重置价大致在月租的一半到一倍之间。这意味着流量一旦跑超,重置费本身就接近甚至超过一整台机器的月租,属于要立刻找商家沟通的量级。
最后是全文通用的一组验收阈值。 后面每个环节的检查都围绕这几个数字转,达不到就换机器或调配置,不要将就:
| 检查项 | 合格标准 | 低于标准时的现象 |
|---|---|---|
| HTTP 首字节时间 | 低于 300 毫秒 | 用户明显感到「这网站有点慢」 |
| 1 MB 文件下载 | 低于 2 秒 | 页面出现可感知空白 |
| 内存谷值 | 不超过总内存的 15% | 高峰期触发 OOM,进程被杀 |
| 随机写 IOPS | 不低于 3000 | 后台保存文章明显卡顿 |
| CPU steal | 低于 3% | 高峰期配置缩水,响应抖动 |
| 磁盘使用率 | 低于 80% | 写不进去,服务报错 |
| 流量用量 | 在配额的 50% 以内 | 触发超额重置或限速 |
关于价格的说明:本文涉及的价格、配置与流量配额,来自渠道库在售机型快照(时间 2026-11-06 13:28);实际价格、库存与线路以商家官网当日报价为准。
三、第一次登录:SSH 的正确用法与常见报错

登录 VPS 只需要一个命令,但怎么用这个命令,决定了你后面所有的操作是顺手还是痛苦。
最基本的一条:
ssh root@你的服务器IP
但生产环境建议一开始就用密钥登录,而不是密码。 原因不是「密码不安全」这种泛泛之谈,而是密码登录意味着你每次连接都要人工输入,而且一旦密码泄露就是直接沦陷。 密钥登录同时解决了自动化和安全性两件事。
完整流程,从本地生成密钥到验证登录:
# 第一步:在本地生成密钥对,rsa 兼容性最好,ed25519 更短
ssh-keygen -t rsa -b 4096 -C "vps-服务器IP"
# 第二步:把公钥传到服务器(会要求输入一次密码)
ssh-copy-id -i ~/.ssh/id_rsa.pub root@你的服务器IP
# 第三步:验证免密登录通了没
ssh root@你的服务器IP
第四步:确认密钥能用了,再关掉密码登录。 顺序反了会把你自己锁在门外——这是新手最常见也最致命的操作失误。
# 先确认 authorized_keys 里有你的公钥
cat ~/.ssh/authorized_keys
# 确认能免密登录后,再改配置
sed -i 's/#PermitRootLogin.*/PermitRootLogin prohibit-password/' /etc/ssh/sshd_config
sed -i 's/#PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
# 改完不要关掉当前窗口,另开一个新终端测试
# 新终端能登录再执行这步,否则原连接断了就进不去了
systemctl restart sshd
这里必须讲清楚 SSH 最常见的四类报错,以及它们的根因:
报错一:Connection timed out(连接超时)
根因通常是三个,挨个排查: 一是商家给的 SSH 端口不是默认 22,要用 ssh -p 端口号 root@IP;二是机器还在重装或启动中,状态没就绪;三是安全组或防火墙拦了你的来源 IP。
# 用 nc 测端口通不通,这一步能区分「网络不通」和「认证失败」
nc -zv 你的服务器IP 22
# 如果系统不支持 nc,用 bash 内置的
timeout 5 bash -c 'cat < /dev/null > /dev/tcp/你的服务器IP/22' && echo "端口通" || echo "端口不通"
报错二:Connection refused(连接被拒绝)
这个和超时不同:超时是没人应答,拒绝是明确地拒绝了。 常见根因是 sshd 服务没起来,或者你连的端口上根本没有 SSH 服务。
# 通过商家提供的 VNC/控制台登录进去检查
systemctl status sshd
ss -tlnp | grep ssh
报错三:Permission denied (publickey)
根因是公钥没放对位置或权限不对。 SSH 对权限极其敏感:
# 三个目录权限必须正确,否则 sshd 会拒绝读取公钥
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chmod 700 ~/.ssh/id_rsa
报错四:Host key verification failed(主机密钥验证失败)
根因是服务器的 SSH 主机密钥变了,或者你换过机器但本地还存着旧的记录。 处理办法是删除旧记录后重连:
ssh-keygen -R 你的服务器IP
ssh root@你的服务器IP
这一节还有一个必做的动作:把本地的 SSH 配置写进 ~/.ssh/config,之后所有连接都简化成一条命令。
# 在本地执行
cat >> ~/.ssh/config << 'EOF'
Host myvps
HostName 你的服务器IP
User root
Port 22
IdentityFile ~/.ssh/id_rsa
ServerAliveInterval 60
ServerAliveCountMax 3
EOF
# 之后直接 ssh myvps 就行
ssh myvps
ServerAliveInterval 60 这两行的作用是防止空闲断连——默认情况下长时间没数据传输,中间设备会掐断连接,表现为「跑着跑着任务就停了」。对要跑长任务的人,这两行能省掉大量重跑。
四、系统初始化:把一台空白机器变成能用的服务器

登录不是终点。一台刚从系统镜像装好的 VPS,缺的东西很多,这个环节做扎实,后面部署会顺很多。
第一件事:更新系统。 这一步不做,后面装任何东西都可能遇到依赖版本对不上的问题。
# Debian / Ubuntu 系
apt update && apt upgrade -y
# CentOS / RHEL 系
yum update -y
# 确认内核版本
uname -r
第二件事:设置时区。 这一步看起来琐碎,但日志时间对不上会让排查变得极其痛苦。
# 设置时区为上海
timedatectl set-timezone Asia/Shanghai
# 设置同步时间
timedatectl set-ntp true
# 确认时间正确,这一步同时能验证外网连通
timedatectl status
第三件事:设置主机名。 主机名会出现在日志、邮件、监控里,起一个有辨识度的名字,出问题时一眼能看出是哪台机器。
hostnamectl set-hostname vps-web-01
echo "vps-web-01" >> /etc/hostname
第四件事:配置时区与 locale 之后,再装基础工具。 很多运维脚本依赖这些命令:
apt install -y curl wget vim git unzip htop net-tools lsof rsync chrony
第五件事:设置 swap。 这一步在 1 GB 内存的机器上尤其重要——不是拿来当内存用,而是防止瞬时内存峰值直接触发 OOM 把进程杀掉。
# 检查是否已有 swap
free -h | grep Swap
# 创建 2 GB swap 文件
fallocate -l 2G /swapfile && chmod 600 /swapfile && mkswap /swapfile && swapon /swapfile
# 写入开机自动挂载
echo '/swapfile none swap sw 0 0' >> /etc/fstab
# 调整 swap 使用策略:内存充足时优先用物理内存
echo 'vm.swappiness=10' >> /etc/sysctl.conf && sysctl -p
vm.swappiness=10 这个参数值得解释一下。 默认值 60 的意思是「内存使用超过 60% 就开始倾向用 swap」,这在小内存机器上会造成不必要的换页,反而变慢。调低到 10,是让它只在真正内存不够时才用 swap 兜底。
第六件事:设置文件描述符上限。 这是一个典型的「不出问题不知道,出问题就是 502」的配置。Nginx、数据库这类服务的连接数会消耗文件描述符,默认值往往不够用。
# 查看当前限制
ulimit -n
# 永久生效
echo '* soft nofile 65535' >> /etc/security/limits.conf
echo '* hard nofile 65535' >> /etc/security/limits.conf
# 对当前会话立即生效
ulimit -n 65535
第七件事:配置自动安全更新。 机器暴露在公网上,系统漏洞的修补应该是自动的,而不是等你想起来。
# Debian / Ubuntu
apt install -y unattended-upgrades
dpkg-reconfigure -plow unattended-upgrades
# CentOS / RHEL
dnf install -y dnf-automatic
systemctl enable --now dnf-automatic.timer
这一节的内容做了一个重要区分:这些是通用系统初始化操作,与任何具体商家无关。 具体的环境配置和套餐条款,请以各商家官网当天的说明为准。
五、安全加固:五个必做项和它们的验收标准

上一节把机器变成「能用」,这一节把它变成「敢用」。VPS 与共享主机最大的区别就是它完全暴露在公网上,虚拟主机的安全由服务商兜底,VPS 的安全只有你自己兜。
这五项的顺序不能乱,从最不影响现网服务、但收益最大的开始:
第一项:换掉默认 SSH 端口。 这一项的实际作用是减少日志里被扫描的噪音,让真正的攻击尝试更显眼。
sed -i 's/#Port 22/Port 你的新端口号/' /etc/ssh/sshd_config
改端口后有三个坑必须避开: 一是云服务商的安全组也要放行新端口,只改机器不改安全组会导致连不上;二是改完不要关掉当前 SSH 窗口,另开新窗口测试通了再关;三是要记得新端口。
第二项:启用密钥登录、禁用 root 密码登录。 第二节已经演示过步骤,这里只强调验收:新开终端用密钥能登录、且用密码被拒绝,两个都要确认。
第三项:装 fail2ban 自动封禁。 暴力破解 SSH 是最常见的攻击手法,自动封禁能把这类尝试挡在门外。
apt install -y fail2ban
systemctl enable --now fail2ban
# 查看当前被封禁的 IP
fail2ban-client status sshd
# 默认配置已经够用,暴力破解 5 次就封 10 分钟
第四项:配置防火墙,只开放必要端口。 这是最后一道防线。
# Debian / Ubuntu 用 ufw
ufw default deny incoming
ufw default allow outgoing
ufw allow 你的SSH端口/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable
# 查看规则
ufw status verbose
# CentOS / RHEL 用 firewalld
firewall-cmd --permanent --add-port=你的SSH端口/tcp
firewall-cmd --permanent --add-service=http
firewall-cmd --permanent --add-service=https
firewall-cmd --reload
firewall-cmd --list-all
第五项:关闭不必要的服务。 很多系统镜像自带一堆用不到的服务,每个都是一个潜在的入口。
# 列出所有正在监听端口的服务
ss -tulnp
# 按需停用,比如关闭 cups(打印服务)
systemctl disable --now cups
# 检查开机自启的服务清单
systemctl list-unit-files --state=enabled
这一节必须给出验收标准,否则做完不知道做没做对:
# 验收一:对外只暴露必要的端口
ss -tulnp | grep LISTEN
# 验收二:密码登录确实关闭了
sshd -T | grep passwordauthentication
# 期望输出:passwordauthentication no
# 验收三:root 不能用密码登录
sshd -T | grep permitrootlogin
# 期望输出:permitrootlogin without-password 或 prohibit-password
# 验收四:fail2ban 在工作
systemctl is-active fail2ban
最后一句提醒:这些是通用操作,不针对任何具体商家。 做加固之前,先确认你有一个能登录进去的备用通道(商家的 VNC 控制台),否则一旦规则配错连自己都进不去,只能重装。
六、部署第一个服务:从裸机到能访问

到这里机器已经可以安全地跑业务了。这一节走完一条完整路径:装 Web 服务 → 配域名 → 上线 → 验证。
第一步:装 Nginx 并配置。
apt install -y nginx
systemctl enable --now nginx
# 验证配置文件语法,这一步能避免重启失败
nginx -t
# 查看运行状态
systemctl status nginx
第二步:建一个站点配置。
mkdir -p /var/www/mysite
cat > /etc/nginx/sites-available/mysite << 'EOF'
server {
listen 80;
server_name example.com www.example.com;
root /var/www/mysite;
index index.html;
# 静态资源缓存,文件名带 hash 的可以设长缓存
location /assets/ {
expires 30d;
add_header Cache-Control "public, immutable";
}
# 限制上传大小,避免单个大文件打满磁盘
client_max_body_size 20m;
# 访问日志和分析日志分开,便于后续排查
access_log /var/log/nginx/mysite.access.log;
error_log /var/log/nginx/mysite.error.log;
}
EOF
ln -s /etc/nginx/sites-available/mysite /etc/nginx/sites-enabled/
nginx -t && systemctl reload nginx
第三步:装数据库并做基础加固。 数据库是网站最常见的性能瓶颈,也是最常见的攻击入口。
apt install -y mariadb-server
systemctl enable --now mariadb
# 安全初始化:设置 root 密码、移除匿名用户和测试库
mysql_secure_installation
# 限制数据库只监听本地,数据库绝对不应该暴露在公网
sed -i 's/bind-address.*/bind-address = 127.0.0.1/' /etc/mysql/mariadb.conf.d/50-server.cnf
systemctl restart mariadb
# 验证:确认 3306 没有对外监听
ss -tulnp | grep 3306
第四步:装 PHP 和常用扩展。
apt install -y php-fpm php-cli php-mysql php-mbstring php-xml php-curl php-zip
systemctl enable --now php-fpm
# 小内存机器上压进程数,这是最有效的一招
# 编辑 /etc/php/*/fpm.d/www.conf,改成:
# pm.max_children = 4
# pm.max_requests = 500
# 确认 PHP 版本与模块
php -v && php -m
第五步:上线并验证。 这一步有几个具体的检查点:
# 检查 80 端口在监听
curl -I http://127.0.0.1
# 检查 Nginx 到 PHP 的链路通不通
curl -s http://127.0.0.1/index.php | head -5
# 配置完防火墙后,从外部实际访问一次,这是唯一有效的验证
curl -I http://你的域名
# 看 Nginx 有没有报权限错误
tail -20 /var/log/nginx/error.log
这一步最容易踩的坑是文件权限。 Nginx 以 www-data 身份运行,如果你的文件属主是 root 且权限是 644,Nginx 能读到;但如果是 600,就报 403。
# 设置网站目录权限
chown -R www-data:www-data /var/www/mysite
find /var/www/mysite -type d -exec chmod 755 {} \;
find /var/www/mysite -type f -exec chmod 644 {} \;
# 单独给上传目录写权限
mkdir -p /var/www/mysite/uploads
chown -R www-data:www-data /var/www/mysite/uploads
chmod -R 755 /var/www/mysite/uploads
第六步:配 HTTPS。 这一步不能省,没有 HTTPS 的站点,浏览器会在地址栏标「不安全」,部分 API 调用会被直接拦截。
# 用 certbot 一键申请证书
apt install -y certbot python3-certbot-nginx
certbot --nginx -d example.com -d www.example.com
# 验证自动续期定时器在跑
systemctl list-timers | grep certbot
第七步:验证自动续期。 这一步是很多人漏掉的,证书三个月后过期、站点突然全挂的案例非常多。
# 模拟续期过程,看会不会报错
certbot renew --dry-run
如果这条命令通过,说明续期机制正常。 这一步花三十秒,能避免三个月后的一次事故。
七、监控与告警:让它出问题的时候告诉你

服务器上线之后,长期的稳定性靠的是监控。没有监控的系统,宕机往往是你在客户投诉时才发现的。
监控至少要覆盖四个维度,缺一个就有一类故障看不见:
| 维度 | 监控指标 | 告警阈值 |
|---|---|---|
| CPU | 使用率、load average、steal | 持续超过 80% |
| 内存 | 使用率、swap 换页 | 使用率超过 85% 或有换页 |
| 磁盘 | 使用率、inode 使用率 | 使用率超过 80% |
| 网络 | 带宽、连接数、丢包 | 流量突增 3 倍 |
先装最基础的一组工具,零成本覆盖大部分需求:
apt install -y htop glances
然后配置告警。 这一步的关键不是装什么监控软件,而是让告警能真的送到你手上。常见的失败是:装了监控但告警发到邮箱没人看,或者配了 webhook 但机器人被移出群了。
# 快速自查:当前负载、内存、磁盘三件套
uptime && free -h && df -h /
# 找出占用最高的进程
ps aux --sort=-%mem | head -10
# 找出磁盘占用最大的目录,这个排查最常用
du -h --max-depth=1 /var 2>/dev/null | sort -rh | head -10
装一个轻量的守护进程来做宕机自愈和定时任务:
# 装 monit 监控并自动重启关键服务
apt install -y monit
monit -t && systemctl reload monit
日志轮转也必须配。 一个不配日志轮转的服务,跑上几个月能把磁盘占满,而占满磁盘会让数据库写不进去——这是最典型的连锁故障。
# 检查 logrotate 是否在跑
systemctl status logrotate.timer
# 手动触发一次轮转测试
logrotate -f /etc/logrotate.conf
# 确认日志目录没有爆量的文件
du -sh /var/log/* | sort -rh | head -10
最后给一个可以加到 crontab 里的健康检查脚本,每天给你一份体检报告:
cat > /root/healthcheck.sh << 'EOF'
#!/bin/bash
echo "===== 服务器健康检查 $(date) ====="
echo "--- 负载 ---"
uptime
echo "--- 内存 ---"
free -h | grep -E "Mem|Swap"
echo "--- 磁盘 ---"
df -h / | tail -1
echo "--- 服务状态 ---"
for s in nginx mysql php-fpm; do
systemctl is-active $s 2>/dev/null | xargs echo "$s:"
done
echo "--- 最近 5 条错误日志 ---"
tail -5 /var/log/syslog 2>/dev/null || tail -5 /var/log/messages
EOF
chmod +x /root/healthcheck.sh
# 每天早上 8 点执行,结果写入日志
crontab -e
# 加入这一行:
# 0 8 * * * /root/healthcheck.sh >> /var/log/healthcheck.log 2>&1
为什么是 8 点而不是半夜:半夜的告警你多半不会醒,早上看日志不影响任何业务。 一个没人看的告警,等于没有监控。
八、备份与恢复:不演练的备份等于没有备份

这一节的核心观点只有一句:一份从来没验证过能不能恢复的备份,等于没有备份。
备份要覆盖三样东西,少一样就恢复不完整:
1. 数据库——最容易丢,也最致命;
2. 代码与配置文件——丢了要重做;
3. 上传文件与用户数据——丢了是业务损失,不是技术损失。
数据库备份的正确做法:用 --single-transaction 保证一致性。
# 每日导出并压缩
mysqldump -u root -p --single-transaction --quick 数据库名 | gzip > /backup/db_$(date +%F).sql.gz
# 保留最近 7 份,自动清理更早的
find /backup -name "db_*.sql.gz" -mtime +7 -delete
注意 --single-transaction 这个参数不能省。 不加它,备份过程中数据库会锁表,大库上表现为网站直接卡住几秒到几十秒。加上它之后,备份过程不阻塞业务。
文件同步用 rsync,但有一个参数组合必须记住。
# 同步网站目录到异地存储
rsync -avz --delete --exclude='*.log' /var/www/ backup用户@异地存储:/backup/www/
# 第一次同步前务必先加 --dry-run 看清楚
rsync -avz --delete --dry-run /var/www/ backup用户@异地存储:/backup/www/
--delete 是迁移事故的头号来源。 它会删除目标端有、源端没有的文件——如果你把命令的方向写反了,异地存储上的备份会被清空。 所以永远先加 --dry-run 看清楚要动什么,再去掉这个参数真正执行。
备份必须异地。 机器坏了、机房出事故、账号被盗,这三种情况都会把同机的备份一起带走。备份和被备份的东西不在同一台机器上,才叫备份;否则只是副本。
最重要的是恢复演练。 这一步能救命的场景是:你要迁移到新机器,或者原机器彻底坏了,需要在几小时内恢复服务。 没有演练过,你会在最需要的时候才发现备份文件损坏、密码变了、版本对不上。
# 第一步:验证压缩包完整性,gzip -t 只测试不解压
gzip -t /backup/db_最新.sql.gz && echo "dump 可解压"
# 第二步:抽查表结构
zcat /backup/db_最新.sql.gz | head -50
# 第三步:完整恢复到临时目录验证一次
mkdir -p /tmp/restore_test
zcat /backup/db_最新.sql.gz | mysql -u root -p 测试库
# 第四步:确认数据量对得上
mysql -u root -p -e "SELECT COUNT(*) FROM 关键表;" 测试库
演练的成本是每月十几分钟,收益是不用赌。 这个投入产出比在所有运维工作里是最高的。
九、扩容、迁移与常见故障处理

最后一部分是机器上线之后必然会遇到的三类情况:容量不够了、要换机房了、服务出故障了。
扩容的两种方式:纵向升配和横向加机器。
# 查看当前磁盘使用,找出可以清理的空间
df -h
du -h --max-depth=1 /var 2>/dev/null | sort -rh | head -10
# 清理日志和缓存,这是最快的释放空间方式
journalctl --vacuum-time=7d
apt clean && rm -rf /var/lib/apt/lists/*
rm -f /var/log/*.gz
# 如果要扩容分区,流程是:云控制台扩盘 → 扩展分区 → 扩展文件系统
# 扩展分区(LVM 场景)
pvresize /dev/sda1
lvresize -L +50G /dev/vg0/lvroot
resize2fs /dev/vg0/lvroot
扩容前先算一个数:你要扩的是「配置」还是「数据量」。 如果是数据量涨了,说明业务在增长,纵向加内存的性价比通常不如横向加机器加负载均衡——因为单机的磁盘 IOPS 上限是硬的,加再多内存也提不上去。
迁移的顺序不能乱:
# 第一步:在旧机器上找出所有硬编码了旧 IP 的地方
grep -rn "旧IP" /etc/nginx/ /var/www/ /root/ 2>/dev/null
# 第二步:重点检查这几个位置
# nginx 配置、数据库配置、crontab、监控配置
crontab -l | grep -i "旧IP"
# 第三步:先做数据库导出,再做文件同步,顺序反了会丢增量数据
mysqldump -u root -p --single-transaction --quick 数据库名 | gzip > /tmp/db.sql.gz
rsync -avz --delete --exclude='*.log' /var/www/ root@新服务器:/var/www/
# 第四步:新机器上恢复
zcat /tmp/db.sql.gz | mysql -u root -p 数据库名
# 第五步:验证无误后再切 DNS
# 切之前把 TTL 提前调到 60 秒,让解析切换更快
最后是常见故障的对照处理表。这张表的用法是:先看症状,再照着查。
| 症状 | 最可能的原因 | 排查命令 | |
|---|---|---|---|
| 网站 502 | PHP-FPM 或后端进程挂了 | systemctl status php-fpm、tail -50 /var/log/nginx/error.log |
|
| 网站 504 | 后端响应超时,资源不足 | uptime、free -h、top |
|
| 网站 403 | 文件权限或目录索引缺失 | ls -ld /var/www/站点目录、`nginx -T \ |
grep root` |
| 网站 404 | 站点配置没启用或路径错 | ls -l /etc/nginx/sites-enabled/、`nginx -T \ |
grep server_name` |
| 数据库连接失败 | 数据库没启动或没授权远程 | systemctl status mysql、mysql -u root -p -e "show variables like 'bind_address';" |
|
| 磁盘写满 | 日志没轮转或数据暴涨 | df -h、du -sh /var/log/*、du -h --max-depth=1 /var |
|
| 内存不足被杀 | 触发 OOM | `dmesg -T \ | grep -i "out of memory"` |
| 磁盘 IO 慢 | 随机写不足或 IO 抢占 | fio -name=randwrite -ioengine=libaio -direct=1 -bs=4k -iodepth=32 -size=1G -rw=randwrite |
|
| CPU 被抢 | 宿主机超售 | `vmstat 1 60 \ | awk '$17 > 3'` |
| 服务莫名重启 | 内存耗尽或磁盘写满导致崩溃 | journalctl -u 服务名 --since "1 hour ago" |
|
| 证书过期 | 自动续期失败 | certbot renew --dry-run、journalctl -u certbot.timer |
这张表里最值得单独强调的是 502。 它是 VPS 建站最高频的故障,而根因往往不在网站代码上。排查顺序永远是:先看 Nginx 错误日志的最后 50 行,再确认后端进程是否活着,最后看内存有没有被吃满。 大部分 502 在这三步之内就能定位。
按你的情况,下一步该看哪家
上面讲的是判断标准,但多数人最后还是想问一句「那我该买谁」。按你的实际情况对照下面几条,直接去看对应的机型页比继续比价更快:
- 只想搭个站、预算优先:先看价格最低那档够不够用,别为用不上的配置付钱。看 iwebfusion 当前机型与价格
- 主要访客在国内、在意打开速度:先确认回程线路,再谈配置。看 racknerd 当前机型与价格
- 只是开发测试、临时用:按小时或月付,用完就删,别买年付。看 cloudcone 当前机型与价格
价格与库存以商家页面当日显示为准,下单前建议先确认退款窗口与是否支持按月付费。
十、什么情况下这套流程用不上,以及三类人的具体做法

前面九节给的是一条完整路径,但这条路径不是对所有人都适用。 这一节先说清哪些情况不该走这条路,再按使用者的类型给出具体做法。
三种情况这套流程用不上:
第一种:你用的机器已经装了面板,而且你打算一直用面板。 面板会接管防火墙、数据库、Web 服务的配置,手工改系统配置文件和面板操作会互相覆盖,表现出来是「面板里改了没生效」或「命令行改了面板显示不对」。这种情况下的正确做法是:只用面板做日常管理,只在需要看日志或排查时用命令行,而且不碰面板正在管理的配置文件。
第二种:你的业务依赖特定版本的系统环境,而商家镜像里没有。 常见的比如需要特定内核版本、需要 Windows 而不是 Linux、需要预装商业授权软件。这种情况应该让商家按需重装系统,或者干脆选原生支持该环境的机型,而不是自己在一台不该装的环境上折腾。
第三种:你的负载需要独占物理资源。 VPS 是共享池中划分的资源配额,宿主机上的 CPU 调度、内存带宽、磁盘 IOPS 都是共享的。虽然第二节给的阈值(随机写 3000 IOPS、CPU steal 低于 3%)是「能用」的门槛,但这两条是「够用」的保证吗?不是。 数据库集群、大规模视频转码、持续高写入的缓存服务,应该直接看独立服务器或云服务器的高主频实例——加钱加的是配额,不是独占性。
另外两个不构成排除但会影响决策的条件:
- 如果你的主要访客在境外,那么首字节 300 毫秒这条阈值在物理上可能达不到,这时候应该用多节点加 CDN 的架构,而不是在这台机器上反复优化;
- 如果你的需求还在变动,先月付一台把整套流程跑一遍,确认了再转年付,因为年付中途通常不能按比例全退。
最后是三类人的具体做法:
第一类:完全的新手,第一次买 VPS。
建议按 2 GB 内存起步、按月付、选离访客最近的机房,先做第二节那张对照表里「纯静态展示页」那一行的配置。 具体机型可以看 LAX-STARTER(折合 16.67 美元/月,2 GB 内存,每 GB 内存 8.33 美元)这一档。但它的机房在洛杉矶,你必须用第二节的阈值实测首字节是否低于 300 毫秒,不达标就换机房,不是换配置。 拿到机器后,第三节到第六节的顺序一步都不要跳,尤其不要跳过第五节的安全加固。新手最容易出的两个错:改完 SSH 端口就关掉唯一的登录窗口,以及忘记改数据库的 bind-address。
第二类:有一定基础,要跑生产业务。
建议从 4 GB 内存起步,配置参考第二节对照表里「WordPress 等带后台的动态站」那一行——LAX-MICRO 折合 33.33 美元/月、4 GB 内存、80 GB 硬盘、10000 GB 月流量,每 GB 内存 8.33 美元、每 TB 流量 3.41 美元。 这一档的核心指标是内存谷值低于 15% 和随机写不低于 3000 IOPS。操作上,第七节的监控和第八节的备份演练是重点,不要等到第一次故障才发现没做过演练。如果业务流量稳定超过半年,再考虑转年付锁定长期价——在此之前不要预付。
第三类:要跑吃内存的服务,比如 Node、Python 常驻进程加 Redis,或者做批量处理。
建议直接看 8 GB 到 16 GB 这一档,单位成本在这里最划算。 参考第二节的表:LAX-MEDIUM 折合 66.67 美元/月、8 GB 内存,每 GB 内存 8.33 美元;RosCloud-05 折合 59.99 美元/月、16 GB 内存,每 GB 内存只要 3.75 美元,是 LAX 系列的 45%。如果你的业务确定要用到 16 GB 以上内存,直接看 RosCloud 的大内存档位,别在 LAX 系列里选。 具体的内存加总算法在第二节给过:基础服务加数据库加进程池,再留 15% 到 20% 峰值余量。
这三类人共同的底线是第二节那张阈值表。 达不到就换机器,不要将就一台不达标的机器去做后面的优化——在配置不足的机器上做优化,优化的收益会被硬件的短板吃掉。
关于价格的说明:本文涉及的价格、配置与流量配额,来自渠道库在售机型快照(时间 2026-11-06 13:28),用于说明各环节的配置需求与量级关系;实际价格、库存与线路以商家官网当日报价为准。

喜欢
高兴
鬼脸
呵呵
无聊
伤心