自建VPS详细教程步骤：可行做法与顺序

一、自建VPS详细教程步骤先要分清：两种「自建」完全不是一回事

「自建 VPS」这个说法在中文语境里至少有两种含义，走错路的话会浪费很多时间。 先把这个分清楚，后面所有步骤才有意义。

第一种是「买一台 VPS 自己配置」。 你从服务商那里买一台虚拟服务器（VPS 或云主机），拿到 IP 和账号，然后自己装系统、配环境、部署站点。这条路的服务器是别人的物理机器，你只是分到了一块虚拟资源。 这也是绝大多数人说的「自建 VPS」的真实含义。

第二种是「用自己手上的硬件搭一台服务器出来」。 你可能有一台闲置的台式机、一台旧笔记本、一台 NAS，甚至一个树莓派，用它装 Linux、装虚拟化、开一个虚拟机对外提供服务。这条路的机器是你自己的，服务器的成本是一次性的，但电费、带宽、IP 都要自己解决。

两条路的差别是结构性的，值得逐项对比：

对比项	买 VPS 自己配置	自有硬件搭服务器
单月成本	19.99 美元起（RosCloud-01）	电费加宽带，无月租
起步速度	付款后十几分钟可用	装系统、装虚拟化、调试，至少一个周末
公网 IP	商家分配独立 IPv4	要单独申请，且是固定成本
带宽	500 到 10000 Mbps 端口速率	取决于你家宽带的上行
上行速度	端口速率，通常跑不满	家宽上行往往只有下行的几分之一
断电风险	商家机房供电保障	家里停电就断
维护成本	商家管硬件	你管一切，包括换硬盘
适合谁	绝大多数人	有闲置硬件且懂运维的人

查看 iwebfusion 当前月价与库存

从这张表能看出一个关键差别：第二条路的瓶颈几乎总是「上行带宽」和「公网 IP」。 家宽的上行速度通常是下行的几分之一，很多人家里 500M 宽带上行只有 30M。用家宽做网站服务器意味着你的下行能力受限于上行，因为所有访客的请求都要从你家里「推」出去。这是物理限制，不是配置问题。

所以第一条判断很简单：如果你手上没有闲置硬件，或者不懂 Linux 和网络运维，买 VPS 是唯一合理的选择。 所谓「自建更省钱」，在没有闲置硬件的前提下是不成立的——你需要付出的学习成本和时间远超省下的钱。

如果确实有闲置硬件，第二条路也有一条硬门槛：这台机器必须能被公网访问到。 这需要三样东西：一个公网 IP（家宽通常没有，需要向运营商申请固定 IP，这是额外成本）、一个开放入站流量的方式（多数家庭宽带默认屏蔽入站连接）、以及一个路由器上的端口映射。家用宽带这三样往往要额外付费或额外配置。

最后一条现实约束：IP 信誉。 家庭宽带的 IP 段往往已经被各种爬虫和邮件垃圾源用烂了，用来发邮件或对外提供服务时很容易被判定为滥用源。而 VPS 的 IP 通常更干净。这不是商家好坏的区别，是 IP 段使用历史的客观事实。

二、自建 VPS 的第一步：装什么系统、怎么选版本

系统选型这一步定了，后面几乎所有教程的命令都跟着定了，所以值得想清楚。

主流选择是三个：Ubuntu Server、Debian、Rocky/AlmaLinux（CentOS 替代）。 它们的定位完全不同。

Ubuntu Server 是新手最常遇到的，因为绝大多数 VPS 商家默认装它。它的优点是文档多、社区大、软件源新。缺点是 LTS 版本两年才发一次大版本，安全更新节奏慢于滚动发布的版本。 如果你跟着的教程是 Ubuntu 的，命令和 Debian 基本通用，但要注意包名差异（比如用 apt 而非 dnf）。

Debian 更保守也更稳。 它以「不崩」为第一目标，版本更新慢但每一版都很可靠。如果你要跑的是长期在线的服务，Debian 的稳定性收益是实在的。

Rocky Linux 和 AlmaLinux 是 RHEL 系的社区重建版，和以前的 CentOS 命令几乎完全一致。如果你的业务环境是企业软件（尤其是需要特定 RHEL 生态的工具），这是对的选择，但对纯建站来说，社区文档量不如 Debian 系。

版本选择上有个常见误区：新手往往选「最新版」。 实际上更稳妥的选择是选那个教程针对的版本，而不是选最新版本。教程里写 Ubuntu 22.04 的命令，你装了 24.04，遇到的差异会消耗你大量时间。

确认当前系统的版本和基本信息：

cat /etc/os-release
uname -a
hostnamectl

装好系统后，第一件事是更新。这一步很多教程会跳过，导致后面装软件时各种版本对不上。

apt update && apt upgrade -y

如果是 RHEL 系：

dnf update -y

更新完成后确认一下磁盘和内存，这决定了你能装多少东西：

free -m
df -h
lsblk

关于「要不要用面板」这个在第一阶段就该定下来的问题：命令行的基础打扎实之后，面板只是锦上添花；反过来，先用面板把环境跑起来，你就永远不知道自己机器上装了什么。我的建议是：第一次自建走纯命令行，把 Nginx、PHP、数据库、证书这四样手动配通一遍，之后再决定要不要加面板。

另外一件必须在早期做完的事：设置时区。 服务器默认 UTC，日志里的时间和你的本地时间差八小时，排查问题时非常容易混乱：

timedatectl set-timezone Asia/Shanghai
timedatectl

查 racknerd 在售套餐与库存

这几步做完，你的机器就处于「可以开始干活」的状态了。 注意此时 SSH 还是密码登录、root 还能直接登，这两件事要尽快改掉——但那是下一步的事。

三、拿到机器后必须先做的五件事：安全加固

机器交付之后、装任何东西之前，先做安全加固。 顺序很重要：先配好密钥登录，再关密码登录，最后才改端口。 反过来做会把自己锁在外面。

第一步：生成密钥对。 在你自己的电脑上执行，不是服务器上：

ssh-keygen -t ed25519 -C "your-vps"

这会生成两个文件：~/.ssh/id_ed25519 是私钥，~/.ssh/id_ed25519.pub 是公钥。 私钥永远不要传到服务器上，更不要发给别人。

第二步：把公钥传到服务器。

ssh-copy-id -p 22 root@你的公网IP

第三步：测试密钥登录能用。 先别关密码登录，先开一个新终端测试：

ssh -i ~/.ssh/id_ed25519 -p 22 root@你的公网IP

能登进去，才继续下一步。 这一步是整段流程里最不能省的——跳过它直接关密码登录，配置写错的话就只能走商家控制台的带外重置，那通常要等商家回复工单。

第四步：改 SSH 配置。

vi /etc/ssh/ssh_config

Port 你的高位端口
PermitRootLogin prohibit-password
PasswordAuthentication no

这里三个参数的作用要分开理解：Port 改端口只是让扫描器找不到，减少无意义的爆破尝试；PermitRootLogin prohibit-password 是禁止 root 用密码登录但保留密钥登录；PasswordAuthentication no 是彻底关闭密码认证。后两条是真正的安全措施，第一条更多是减少噪音。

第五步：重载 SSH 服务，再开一个新终端测试。

systemctl reload sshd

新终端能登进去、旧窗口先别关。 确认无误后再关旧窗口。

第六步：装防火墙，只放行真正需要的端口。

# Debian/Ubuntu
ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable

# RHEL 系用 firewalld
firewall-cmd --permanent --add-service=http
firewall-cmd --permanent --add-service=https
firewall-cmd --reload

如果你改了 SSH 端口，记得把防火墙规则也改成同一个端口。 这是最常见的把自己锁在外面的原因——SSH 端口改了但防火墙还是放行 22，结果新端口进不去、旧端口已经不让密码登录了。

最后一步：设置免密 sudo 并检查登录日志：

# 给普通用户 sudo 权限
visudo
# 确认没有异常登录记录
last -a | head -20
journalctl -u sshd | tail -30

关于要不要禁用 root 直接登录：这不是必须的，但更规范的做法是创建一个普通用户，日常用它登录，需要管理操作用 sudo。 因为 root 权限一旦被利用就没有中间层了。

查 cloudcone 在售套餐与库存

这几步做完，你的机器才算「可以开始装东西」的状态。

四、配置和带宽怎么按业务量选：把配置换算成能承载多少访问

「几核几 G 够用」这句话的正确用法是把它换算成可验证的数字。 这一节做三件事：看真实配置的分布、按内存算并发上限、按流量算能撑多少访问。

先看商品库里的真实配置。 RosCloud 月付系列从 2 核 1 GB 到 7 核 24 GB，带宽一律 500 Mbps，流量 1024 GB 到 6144 GB。sixtynet 年付系列从 2 核 2 GB 到 16 核 16 GB，带宽 2000 到 10000 Mbps，流量 5000 到 40000 GB。云途的规格跨度最大，1 核 32 GB 到 2 核 256 GB，带宽 1000 到 2000 Mbps。同样是「4G 内存」，这三条线对应的核数和流量配额完全不同。

按内存算并发上限，用这套规则：

总内存 = 操作系统 256 MB
       + MySQL 缓冲池（总内存的 25%）
       + PHP-FPM worker 数 × 每个 worker 40 MB
       + 剩余的 10% 作为安全余量

按这套规则算出来：1 GB 机器约 11 个 worker，2 GB 约 28 个，4 GB 约 63 个，8 GB 约 132 个。 换句话说，内存直接决定你能同时处理多少个动态请求。

按流量算能撑多少访问，公式是「月流量配额 ÷ 单页体积」：

月流量配额	单页 0.3 MB（纯静态）	单页 1.2 MB（含图片的展示页）
1024 GB	340 万次	87 万次
5000 GB	1700 万次	426 万次
10000 GB	3400 万次	853 万次
40000 GB	1.36 亿次	3400 万次

digitalocean 官网机型与实时报价

这张表说明一件事：流量配额对绝大多数中小站点来说是过剩的。 月访问 5 万次的站点、单页 1.2 MB，流量需求只有 58.6 GB，而最低配的 1024 GB 配额是它的 17 倍。 真正会卡住你的是内存和 CPU，不是流量。

带宽那一栏也要换算成体感数字。 Mbps 除以 8 得到 MB/s：500 Mbps 是 62.5 MB/s，1000 Mbps 是 125 MB/s，2000 Mbps 是 250 MB/s，10000 Mbps 是 1250 MB/s。用 1 MB 文件除一下传输时间：500 Mbps 需要 0.016 秒，1000 Mbps 是 0.008 秒，10000 Mbps 是 0.0008 秒。

注意这里的结论：只要访问量不构成持续的大带宽占用，几百兆带宽在网页场景里早就不是瓶颈了。 真正会卡住你的是并发连接数过多时的排队，而不是峰值带宽数字。一个每天一万次访问的个人博客，1000 Mbps 和 200 Mbps 的实际体感差别很小；但一个做图片站或者文件下载的站点，流量配额才是那道墙。

CPU 侧也要算一笔。 一个普通的动态页面请求大约消耗 50 毫秒 CPU 时间，单核每秒处理 20 个动态请求，2 核 40 个，4 核 80 个，8 核 160 个。折算成每小时，1 核 7.2 万次，4 核 28.8 万次，8 核 57.6 万次。

这三笔算完，选配置就变成了一道算术题。 而判断配置够不够的最终标准是实测：free -m 的 available 列，在业务稳定运行 24 小时后应保持在总内存 15% 以上。 低于这个数就是买小了。

五、装 Web 服务和运行环境：Nginx 与 PHP-FPM 的配置要点

Web 服务选 Nginx 是最不会出错的选择，但有几个配置点必须做对，做错了就是排查半天的问题。

先装：

apt update && apt upgrade -y
apt install -y nginx
systemctl enable nginx
systemctl start nginx
nginx -v

验证它起来了：

systemctl status nginx --no-pager
curl -sI http://127.0.0.1 | head -3

正常会看到 HTTP/1.1 200 OK。 如果 curl 没响应，先看错误日志：tail -50 /var/log/nginx/error.log。

接下来装 PHP-FPM（如果你跑的是 PHP 站点）：

apt install -y php8.2-fpm php8.2-mysql php8.2-curl php8.2-gd php8.2-mbstring php8.2-xml php8.2-zip unzip
systemctl enable php8.2-fpm

装完 PHP 扩展有两个常见坑：一是漏装必需扩展，二是版本对不上。 WordPress 需要 php8.2-gd 生成缩略图、需要 php8.2-mbstring 和 php8.2-xml，缺一个的表现是后台白屏或者安装向导卡在某一步。

然后配站点虚拟主机：

server {
    listen 80;
    server_name example.com www.example.com;
    root /var/www/example;
    index index.html index.php;

    location / {
        try_files $uri $uri/ =404;
    }

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.2-fpm.sock;
    }

    client_max_body_size 32m;
}

这个配置里有四处必须做对的：

第一，fastcgi_pass 后面那个 socket 路径必须和实际安装的 PHP 版本对上，这是 502 报错的头号原因。 查实际版本：

ls /run/php/

列出来的是 php8.2-fpm.sock，配置里就写 8.2。

第二，改完配置必须先测语法再重载：

nginx -t && systemctl reload nginx

nginx -t 这一步千万不能省。 直接 restart 时如果配置有语法错误，服务可能直接起不来，网站全挂；用 reload 则老配置继续跑。养成先 -t 再 reload 的习惯，这一个动作能挡掉绝大多数配置事故。

第三，client_max_body_size 决定上传文件上限，默认往往只有 1 MB。 不改这一行，后台上传会直接报 413 Request Entity Too Large。

第四，root 指向的目录要存在且权限正确。 权限不对直接 403：

mkdir -p /var/www/example
chown -R www-data:www-data /var/www/example
find /var/www/example -type d -exec chmod 755 {} \;
find /var/www/example -type f -exec chmod 644 {} \;

上面两条 find 都要跑，一条只改目录、一条只改文件，只改文件不改目录的话 Nginx 依然无法进入目录，403 依旧。 另外不要图省事对整个站点执行 chmod -R 777，那等于把目录写权限开放给任何进程。

如果需要 Node 环境：

curl -fsSL https://deb.nodesource.com/setup_22.x | bash -
apt install -y nodejs
npm install -g pm2
pm2 start app.js --name mysite --max-memory-restart 512M
pm2 save
pm2 startup

查 hostwinds 在售套餐与库存

--max-memory-restart 512M 的作用是进程内存超过 512 MB 就自动重启——Node 进程的 V8 垃圾回收会不断扩张老生代，内存占用会慢慢爬升，不设上限迟早 OOM。2 GB 机器设 512 MB 或 768 MB 合理。

六、数据库怎么装才安全：绑定地址和账号权限

数据库这一步的核心不是「装上」，而是「装上且没暴露」。 大量 VPS 被入侵，入口就是数据库监听了公网地址、密码又是弱密码。

安装：

apt install -y mysql-server
mysql_secure_installation

mysql_secure_installation 会依次问几个问题：设置 root 密码、删除匿名用户、禁止 root 远程登录、删除测试库、刷新权限。这些都要做，尤其第二条和第四条。

装完第一件事是确认绑定地址：

ss -lntp | grep 3306

输出里看到 127.0.0.1:3306 才对。如果看到 0.0.0.0:3306，说明数据库暴露在公网，必须改配置后重启：

vi /etc/mysql/mysql.conf.d/mysqld.cnf

[mysqld]
bind-address = 127.0.0.1

systemctl restart mysql

这一条比任何安全插件都重要。 数据库一旦暴露在公网，扫描器几小时内就会找到它。

然后建库建用户，并且给最小权限：

mysql -u root -p

CREATE DATABASE example CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'wpuser'@'localhost' IDENTIFIED BY '这里换成你自己的强密码';
GRANT ALL PRIVILEGES ON example.* TO 'wpuser'@'localhost';
FLUSH PRIVILEGES;
EXIT;

三个细节值得说明：

第一，用户名后面是 'localhost' 而不是 '%'。 写 '%' 表示允许从任何主机连接，即使 bind-address 限制了监听地址，多一层限制也更稳妥。需要远程连接时单独为指定 IP 授权。

第二，utf8mb4 而不是 utf8。 MySQL 的 utf8 实际上是 utf8mb3，三个字节，最多支持 BMP 范围内的字符，存 emoji 会报错。utf8mb4 才是真正的四字节 UTF-8。

第三，密码里带特殊字符时要注意转义。 如果密码里有单引号，SQL 会语法错误。

配完 CMS 之后要确认连接正常，最直接的验证方式是看错误日志里有没有连接被拒：

tail -50 /var/log/mysql/error.log

如果 CMS 报 SQLSTATE[HY000] [2002] Connection refused，含义是「连接被拒绝」，不是密码错误。 密码错误是另一条：

SQLSTATE[HY000] [1045] Access denied for user 'wpuser'@'localhost'

新手最常见的误判就是看到任何一个数据库报错就改密码重装，结果密码改了一堆，根因其实是 MySQL 没启动，或者 CMS 连的地址不对。

最后是备份。 这一步必须做成自动的：

mysqldump -u root -p'你的密码' --single-transaction --quick example | gzip > db-$(date +%Y%m%d).sql.gz

查看 interserver 当前月价与库存

--single-transaction 对 InnoDB 表很关键——它不锁表就能拿到一致性快照，备份的时候网站照常能用。 不加这个参数，备份期间你的站点会短暂卡住。

七、域名解析和 HTTPS 证书：签发步骤和三个高频报错

域名解析和证书这两件事有严格的先后顺序，做反了必然失败。

第一步：解析。 在域名服务商那边把 A 记录指向服务器公网 IP。DNS 生效需要时间，通常几分钟到几小时。 验证：

nslookup example.com
dig example.com +short
curl -sI http://example.com

注意 ping 不通不一定有问题，很多机房禁 ICMP。真正要验证的是 80 端口通不通。 还要注意本地可能缓存了旧的解析结果，换 IP 之后尤其要确认。

第二步：签发证书。 必须在解析生效、80 端口放行之后：

apt install -y certbot python3-certbot-nginx
certbot --nginx -d example.com -d www.example.com
certbot renew --dry-run

certbot renew --dry-run 这一条一定要执行。 Certbot 默认会配成每天检查续期，但这个定时任务是否真的在跑，要自己验证一次。证书过期导致的整站打不开，是建站之后最常见也最尴尬的事故。

三个高频报错：

报错一：ACME 验证失败。 原因是 Certbot 需要通过 HTTP 访问 http://你的域名/.well-known/acme-challenge/ 来证明你控制这个域名。所以必须满足三个条件：解析已生效、80 端口没被占用、Nginx 能正常响应。 排查：

nslookup example.com
curl -sI http://example.com
ss -lntp | grep :80

如果 80 端口被别的程序占着（比如你之前装过 Apache，或某个面板自带了 Web 服务），签发必然失败。这时要么停掉占用服务，要么改用 DNS 验证方式手动加 TXT 记录。

报错二：证书签好了但浏览器仍提示不安全。 这通常是证书链不完整——签发机构发的中间证书没有被一起放上去。Certbot 装出来的证书一般链是完整的，如果用的是别的工具手动配置的，务必把中间证书拼接进 fullchain.pem。

报错三：域名不匹配。 证书是给 example.com 签的，访问 www.example.com 就会报错。解决办法是签发时把两个域名都写进去（就是上面命令里的两个 -d），或者做一条 www 到主域名的跳转。

第三步：配好 443 并做强制跳转。

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name example.com www.example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    root /var/www/example;
    index index.html index.php;

    location / {
        try_files $uri $uri/ =404;
    }
}

这里的关键是 ssl_certificate 必须指向 fullchain.pem（完整链），而不是 cert.pem（只有叶子证书）。 用错了本地测试可能正常，外部浏览器访问会报 NET::ERR_CERT_AUTHORITY_INVALID。

查看 itldc 当前月价与库存

改完还是先 nginx -t 再 reload。

八、把网站部署上去：上传方式、权限和部署后必查项

内容部署这一步的选择，取决于你改页面的频率。

第一种是 scp，适合一次性上传：

scp -r ./dist/* root@你的公网IP:/var/www/example/

第二种是 rsync，适合反复同步，推荐用这个：

rsync -avz --delete ./dist/ root@你的公网IP:/var/www/example/

--delete 会删除目标目录里源目录没有的文件，用错了目录就是把整个站点清空。第一次用建议加 --dry-run 先看一遍它打算做什么：

rsync -avz --delete --dry-run ./dist/ root@你的公网IP:/var/www/example/

第三种是 git，适合有版本管理习惯的团队：

apt install -y git
git clone https://github.com/你的账号/你的仓库.git /var/www/example

它的好处是每次部署天然有版本记录，出问题能回滚到上一个 commit。 但前提是站点是用构建工具生成的静态文件——静态站点一般需要本地构建好再上传，用 git 直接拉源码是不行的，所以工作流如果是「改源码 → 本地构建 → 传产物」，rsync 最贴。

部署完必须设权限，403 的头号原因就是权限：

chown -R www-data:www-data /var/www/example
find /var/www/example -type d -exec chmod 755 {} \;
find /var/www/example -type f -exec chmod 644 {} \;

如果站点需要 PHP，权限要求更细：静态文件保持 644，而上传目录需要能被 PHP 进程写入：

chown -R www-data:www-data /var/www/example/uploads
chmod -R 755 /var/www/example/uploads

要写入的目录单独开放，其余保持 755，不要整个站点 777。

部署后有四个地方必须逐个确认，不能只看首页能打开：

第一，首页在浏览器里完整加载，不只是 HTML 出来而图片样式全丢。 单独确认静态资源：

curl -sI http://example.com/style.css

第二，后台能登录并且能保存内容。 WordPress 这类程序在数据库权限不足时，首页正常但保存时报 500。

第三，表单能提交。 上传失败通常是 client_max_body_size 没改，或者 PHP 的 upload_max_filesize 和 post_max_size 还是默认值。

第四，手机上打开看看。 很多显示问题只在窄屏出现，桌面端完全看不出来。

查 spinservers 在售套餐与库存

最后把部署脚本化。 每次上线手动敲十几条命令，既慢又容易漏。把 rsync、配置重载、清理临时文件这几步写成一个 shell 脚本放服务器上，用 bash deploy.sh 一键执行。这一步不属于必需动作，但它是让站点能长期维护下去的分界线。

九、上线后的运维：监控、备份和日常检查

网站上线不是终点，是维护的开始。 三件必须做、而且必须做成自动的事。

第一件是备份，要覆盖三样东西：数据库、站点文件、配置文件。 只备份文件不备份数据库是最常见的错误——代码可以重新写，文章和用户数据丢了就没了。

#!/bin/bash
STAMP=$(date +%Y%m%d-%H%M%S)
DIR=/var/backups/mysql
mkdir -p $DIR
mysqldump -u root -p'你的密码' --single-transaction --quick example | gzip > $DIR/db-$STAMP.sql.gz
ls -t $DIR/db-*.sql.gz | tail -n +8 | xargs -r rm --

chmod +x /usr/local/bin/backup-db.sh
17 3 * * * root /usr/local/bin/backup-db.sh

--single-transaction 让备份不锁表，网站照常可用；ls -t | tail -n +8 | xargs rm 保证只保留最近 7 份，不会把磁盘撑满。

文件备份用 rsync，注意这里的 --delete 是故意用的，让备份目录精确镜像源目录：

rsync -a --delete /var/www/example/ /var/backups/site/$STAMP/

备份必须异地存一份。 同一机房、同一线路、同一存储池上的备份，机房级故障时会一起消失。

第二件是监控。最基础的三项：网站可访问性、证书有效期、磁盘使用率。

#!/bin/bash
CODE=$(curl -s -o /dev/null -w "%{http_code}" --max-time 10 https://example.com)
[ "$CODE" != "200" ] && echo "[ALERT] 网站返回 $CODE" >> /var/log/site-monitor.log
USE=$(df / | awk 'NR==2 {gsub("%","",$5); print $5}')
[ "$USE" -gt 80 ] && echo "[ALERT] 磁盘 $USE%" >> /var/log/site-monitor.log
echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null \
  | openssl x509 -noout -enddate >> /var/log/site-monitor.log

chmod +x /usr/local/bin/monitor.sh
*/10 * * * * root /usr/local/bin/monitor.sh

证书那项最值钱，因为证书过期是那种「一晚上之间全站变白」的事故，而它完全可以提前避免。

第三件是日常节奏：每天看监控日志和错误日志，每周更新一次安全补丁（apt update && apt upgrade -y，更新后重启 PHP-FPM 和 Nginx），每月检查一次备份能不能还原，每季度复核流量用量和账单。

流量用量的监控值得单独提，因为流量超额最容易在账单上给惊喜：

apt install -y vnstat
systemctl enable --now vnstat
vnstat -m

vnstat 需要先跑一段时间才能积累数据，装上之后它会自动开始记录。 建议装完立刻启动服务并设成开机自启。

还有一个必须做的检查：确认日志有轮转配置。 不配的话日志文件会把磁盘写满，而磁盘满了会让整个站点行为异常：

cat /etc/logrotate.d/nginx

zenlayer 官网机型与实时报价

最后提醒一句：每季度花十分钟把备份真的还原一次。 没验证过的备份等于没有备份——很多站点的备份脚本跑了半年从没还原过，等真出事时才发现文件是空的或格式不对。

按你的情况，下一步该看哪家

上面讲的是判断标准，但多数人最后还是想问一句「那我该买谁」。按你的实际情况对照下面几条，直接去看对应的机型页比继续比价更快：

只想搭个站、预算优先：先看价格最低那档够不够用，别为用不上的配置付钱。看 iwebfusion 当前机型与价格
只是开发测试、临时用：按小时或月付，用完就删，别买年付。看 racknerd 当前机型与价格

价格与库存以商家页面当日显示为准，下单前建议先确认退款窗口与是否支持按月付费。

十、自建VPS详细教程步骤常见问题速查

这一节是全文的速查表。

问一：「自建 VPS」到底指什么？ 两种：买商家机器自己配置，或用自有硬件搭服务器。 后者的瓶颈几乎总是上行带宽和公网 IP，家宽上行往往只有下行的几分之一。

问二：系统选 Ubuntu 还是 Debian？ 跟着教程选，别自己升版本。 Ubuntu 文档多、软件源新；Debian 更保守更稳。新手通常直接用商家默认的 Ubuntu Server。

问三：为什么本机 curl 正常，浏览器打不开？ 防火墙拦了。 本机访问 127.0.0.1 不经过防火墙规则。用 ufw status verbose 查放行规则。

问四：改了 SSH 端口就登不上去了？ 大概率是防火墙没同步改。 ufw allow 22/tcp 放行的还是旧端口，新端口没放行。要用带外重置恢复。

问五：502 怎么排查？ 先看 Nginx 错误日志，然后核对 fastcgi_pass 的 socket 路径和 ls /run/php/ 里的实际文件名是否一致。

问六：403 Forbidden 怎么修？ 目录权限。 目录 755、文件 644，站点目录所有者设对。不要整个目录 chmod -R 777。

问七：413 Request Entity Too Large？ 改 Nginx 的 client_max_body_size，同时确认 PHP 的 upload_max_filesize 和 post_max_size 也调了。

问八：数据库连不上，报 Connection refused？ 那不是密码错误，是连接被拒。 查 MySQL 是否启动、bind-address 是否是 127.0.0.1、CMS 连的地址和端口对不对。密码错误是 [1045] Access denied。

问九：证书签不下来？ 三个前置条件：解析已生效、80 端口能通、80 端口没被别的程序占用。 缺一不可。

问十：浏览器提示证书无效，但本地 curl 正常？ 证书链不完整。 ssl_certificate 要指向 fullchain.pem 而不是 cert.pem。

问十一：怎么确认配置够不够用？ 看 free -m 的 available 列，业务稳定运行 24 小时后应保持在总内存 15% 以上。低于就是买小了。

问十二：流量配额够用吗？ 用「月流量 ÷ 单页体积」算。 单页 1.2 MB、月流量 1024 GB，够 87 万次访问。绝大多数中小站点的流量配额是过剩的。

问十三：怎么知道自己的站点有多少并发？ 看 PHP-FPM 的 worker 数。 每个 worker 约 40 MB 内存，1 GB 机器约 11 个、2 GB 约 28 个、4 GB 约 63 个。

问十四：备份做了但不敢保证有用？ 真还原一次。 没验证过的备份等于没有备份。

问十五：系统更新会不会把服务搞挂？ 更新后要重启服务（systemctl restart php8.2-fpm && systemctl reload nginx），PHP-FPM 不重启的话旧进程还在跑旧代码。

最后回到开头那句话：自建 VPS 的难点从来不是「装什么」，而是「装完之后你能不能判断它对不对」。 知道为什么要改 SSH 端口，就知道什么时候可以跳过；知道 fastcgi_pass 的路径为什么必须对上版本号，出错时就知道去核对而不是重装。把这套判断标准建立起来，上面十个步骤才真的可复用。

飞翔声明：飞翔网登载此文出于传递更多信息之目的，并不意味着赞同其观点或证实其描述。