VPS搭建网站教程：完整步骤与常见报错

一、VPS搭建网站教程第一步：先确定这台机器要干什么

教程的第一步不是敲命令，是想清楚这台机器要跑什么。跳过这一步的人，通常会在第四步（配置环境）发现自己买错了机器。

只需要回答三个问题：

问题一：你的站点是什么类型？

站点类型	内存需求	硬盘需求	说明
纯静态（HTML/CSS/JS）	1 GB 够	20–40 GB 够	Nginx 就能跑，不需要 PHP 和数据库
博客/CMS（WordPress、Typecho）	2–4 GB	40–80 GB	需要 PHP + MySQL
后端 API / 小程序后端	2 GB 起	40 GB 起	Node/Python/Java
电商/论坛（带用户体系）	4 GB 起	80 GB 起	数据库是主要负载
多站合用 / 加面板	4 GB 起步	80 GB 起	面板本身要吃内存

查看 iwebfusion 当前月价与库存

问题二：你的访问量大概多少？ 这个数决定你要看的是内存还是流量。月 PV 一万以内、每次浏览传 800 KB 的站点，月流量不到 10 GB——任何一款主流套餐的流量配额都远超这个数，流量根本不是你的约束条件。 反过来，如果你做的是软件分发、视频站、大文件下载，月流量就是几 TB 起，这时候流量配额和超额价格才是决定性因素。

问题三：你的访客主要在哪？ 决定了机房位置，也决定了你要不要为优化线路付溢价。

这三个问题答完，就能对着真实价格做判断了：

- 纯静态站 + 小流量：RosCloud-01 每月 19.99 美元，2 vCPU、1 GB 内存、20 GB 硬盘、500 Mbps、1024 GB 流量，这个配置就是为这一档准备的；

- WordPress 博客：RosCloud-03 每月 39.99 美元，4 vCPU、4 GB 内存、80 GB 硬盘、3072 GB 流量，每 GB 内存 10 美元，这是这条产品线的性价比拐点；

- 电商或带数据库的业务：至少 4 GB 内存起步，硬盘要留出数据库增长空间；

- 大流量分发：看的不是内存而是每 TB 流量成本，商品库里 LAX-MEDIUM 每 TB 3.413 美元、LAX-LARGE 每 TB 3.413 美元，是香港机型（17.92 美元起）的五分之一。

一条通用建议，也是本教程反复出现的一条：第一台机器按月买。 商品库里也有年付更便宜的（比如 LAX-STARTER 年付 200 美元、折合每月 16.67 美元），但年付锁死 12 个月付款，在你还没验证机器是否符合预期时不该做这个决定。 先跑一个月，测完五项验收再转年付。

这一节还要说清"买之前应该问商家什么"。 三个问题，比任何宣传页都管用：

问题一：流量用完会怎样？ 是限速到某个值，还是额外收费，还是直接停机？商品库里有些机型标了流量重置价格（云途 HK.DS.M 是 200 美元、HK.DS.P 是 500 美元、DS.ES.B 是 450 美元），这意味着流量用完不是停机，是要额外付钱。对 HK.DS.M 来说，200 美元是它折月价 350 美元的 57%，一次超额等于白干半个多月，这个数字必须写进预算表。

问题二：这台机器的带宽是独享还是共享？ VPS 的带宽标称值通常是端口分配上限，独享和共享在晚高峰的表现可能差好几倍。

问题三：支持按月付费吗？退款窗口多长？ 第一台机器一定要按月买，这条没有例外。

再算一笔账，把"流量到底够不够"这件事量化。 假设你的站点月 PV 3 万，每次浏览传输 800 KB：

- 月流量 = 30000 × 0.0008 GB ≈ 24 GB；

- RosCloud-01 每月 1024 GB 流量，用掉 2.3%；

- LAX-MEDIUM 每月 20000 GB 流量，用掉 0.12%。

结论很明确：只要你不是做下载和分发，流量配额对中小站来说完全不是约束条件。 这时候把注意力放在内存、磁盘和线路上，而不是被"月流量 1 TB"这种参数吸引——那个数字对绝大多数站点是无关的。

反过来，如果你做的是软件分发、镜像站、大文件下载，月流量是几 TB 起，这时候每 TB 流量成本就成了唯一该看的数字。 商品库里 LAX 系列稳定在每 TB 3.413 美元，这是全场最低档；香港机型从 17.92 美元起，高出五倍。

最后一句关于类型的判断：站点类型决定配置，用户位置决定机房，这两件事是分开算的。 搞混了就会出现"人在国内访客为主，却买了美西大流量机"这种组合——流量是够的，但延迟不对。

二、第二步：SSH 登录、改密码、换端口、装防火墙

现在动手。这一步是整套教程的地基，四件事一件都不能省。

登录服务器：

ssh root@你的服务器IP

第一次连接会问你要不要接受主机指纹，输入 yes 回车。 之后输入密码时屏幕上不会有任何字符显示，包括星号，这是 SSH 的正常行为，很多人以为卡住了然后反复敲回车——结果是第一次就把密码敲错了。

改密码：

passwd

换 SSH 端口。 先确认新端口没被占：

ss -tlnp | grep -E ':22|:2222'

没有 2222 的输出就说明可用。 改配置：

vi /etc/ssh/sshd_config

把 Port 22 改成两行：

Port 22
Port 2222

保留 22 是为了留后路。 改完重启，然后开一个新终端测试：

ssh -p 2222 root@你的服务器IP

新终端能登录、且 ss -tlnp 里 22 端口还在监听，这两步都确认后，再把 Port 22 那行删掉重启。 顺序反了就可能把自己锁在门外——这是新手最常见、也最容易补救的错误（因为 22 还开着）。

装 fail2ban 防爆破：

apt update && apt install -y fail2ban
systemctl enable --now fail2ban

装防火墙：

apt install -y ufw
ufw default deny incoming
ufw default allow outgoing
ufw allow 2222/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable

这里最容易出错：如果你已经换了端口，规则里就得写 2222 而不是 22。 规则和实际端口对不上，ufw enable 之后你就连不上服务器了。改防火墙前先确认当前 SSH 端口，这是铁律。

验证：

ufw status verbose
ss -tlnp

看到 Status: active、规则里有 2222 和 80、443，端口列表里没有不认识的服务，这一步就完成了。

额外两件小事，顺手做掉：

timedatectl set-timezone Asia/Shanghai
timedatectl set-ntp true
timedatectl status

看到 System clock synchronized: yes 就算好。 服务器时间不准会让证书校验、定时任务、日志排查全乱套。

再加一条：建一个日常用的普通账号，别天天用 root 登录。

adduser ops
usermod -aG sudo ops
rsync --archive --chown=ops:ops ~/.ssh /home/ops

改完之后日常登录用 ops，需要提权时才 sudo。 公网上的 VPS 每天都在被自动扫描，用 root 直接登录等于把最大的权限放在最常被攻击的入口上。这一步做起来只要一分钟，省的是以后出事的概率。

第二步的验收信号汇总成一张表：

检查项	命令	合格表现
新端口可登录	`ssh -p 2222 root@IP`	正常进入
旧端口已关闭	`ss -tlnp`	22 不在列表
fail2ban 运行中	`systemctl is-active fail2ban`	active
防火墙已启用	`ufw status`	Status: active
端口暴露最小	`ss -tlnp`	只有 2222、80、443
时钟同步	`timedatectl status`	synchronized: yes

查 racknerd 在售套餐与库存

六项全过再进第三步。 这一步省下的时间，会在后面每一次排错时还给你。

三、第三步：装环境，Nginx + PHP + 数据库

环境是第三步。先说清三套方案的区别，再给命令。

方案 A：纯静态站，只需要 Nginx。 最省资源，1 GB 内存就能跑得很舒服：

apt update && apt upgrade -y
apt install -y nginx
systemctl enable --now nginx

方案 B：WordPress 这类 CMS，需要 Nginx + PHP + 数据库：

apt update && apt upgrade -y
apt install -y nginx php-fpm php-cli php-mysql php-nginx php-mbstring php-xml php-curl php-opcache
apt install -y mysql-server
systemctl enable --now nginx php8.2-fpm mysql

php-opcache 一定要装。 它把 PHP 文件的解析结果缓存在共享内存里，对 WordPress 这种文件多、逻辑重的 CMS，这个开关带来的提速常常超过加 1 GB 内存。

方案 C：Node 或 Java 应用：

apt install -y nodejs npm
# 或者装 Java 环境

装完检查服务状态：

systemctl status nginx php8.2-fpm mysql

三个都该是 active (running)。 有任何一个不是，先修好再往下走。

再改一个 MySQL 参数，小内存机器上这一步不做必然后面出问题：

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

在 [mysqld] 段加：

innodb_buffer_pool_size = 128M
performance_schema = OFF

1–2 GB 内存用 128M，4 GB 用 256M。 MySQL 默认的 buffer pool 是按大机器算的，小机器上直接吃掉大半内存，结果就是 OOM Killer 随机杀数据库进程，表现为"站点莫名其妙空白"。

面板路线（宝塔、1Panel）什么时候选？ 只在你完全不想碰命令行、且这台机器是测试性质的时候。 面板的优势是点鼠标，代价是内存占用高、端口多、路径依赖严重。1 GB 内存装面板加数据库，内存谷值轻松超过 85%。 装的话记得三件事：面板安全入口路径要记牢；它会自己改 SSH 端口，装完用 ss -tlnp 核对；装完立刻改上面那个 MySQL 参数。

第三步做完，用这几条命令确认一遍环境是健康的：

# 服务是否都起来了
systemctl is-active nginx php8.2-fpm mysql

# 内存当前用量
free -m

# 磁盘当前用量
df -h /

# 监听端口全景
ss -tlnp

判读标准： 三个服务都返回 active；free -m 的 available 行不低于总内存的 15%；df -h / 使用率低于 50%（给后面留空间）；ss -tlnp 里除了 2222、80、443 和数据库的 3306（只监听 127.0.0.1 才正常），不该有别的对外端口。

MySQL 默认监听 3306，如果它监听的是 0.0.0.0:3306，那你的数据库是暴露在公网上的。 检查并改成本地监听：

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

确认有这一行：

bind-address = 127.0.0.1

查 cloudcone 在售套餐与库存

改完重启 MySQL。 这一步比很多人以为的重要——公网暴露的 3306 是最常被批量扫描的端口之一，而一旦数据库密码弱，整台机器就完了。

四、第四步：Nginx 配置怎么写，每一行为什么这么写

配置是最容易出错的一步。先给完整配置，再解释关键行。

mkdir -p /var/www/example.com/public
chown -R www-data:www-data /var/www/example.com
chmod -R 755 /var/www/example.com
vi /etc/nginx/sites-available/example.com

server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;

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

    client_max_body_size 32m;

    access_log /var/log/nginx/example.com.access.log;
    error_log /var/log/nginx/example.com.error.log;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

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

    location ~ /\. {
        deny all;
    }
}

逐条解释为什么这么写：

root 指向 public 目录——WordPress 的规范安装方式就是把站点根设在 public 或 public_html，这样 wp-config.php 不会被直接访问到。直接指向站点根目录的安装方式，配置文件是可以被 URL 猜到的，这是被入侵的常见入口。

index index.php index.html;——指定目录访问时优先找哪个索引文件。

try_files $uri $uri/ /index.php?$query_string;——这是 WordPress 伪静态的核心。意思是：先找真实的文件，找不到就找目录，再找不到就把请求交给 index.php 处理。 少了这行，WordPress 的固定链接会全部 404。

fastcgi_pass unix:/run/php/php8.2-fpm.sock;——版本号必须和实际安装的一致，查法：

ls /run/php/

看到 php8.2-fpm.sock 就写 8.2。 写错会报 connect() failed (2: No such file or directory)。

location ~ /\. { deny all; }——禁止访问所有隐藏文件（以点开头的）。.env、.git、.htaccess 这些文件暴露出去是安全事故，这条规则挡住它们。

client_max_body_size 32m;——上传大小限制，不改的话默认只有 1 MB，传稍大的文件就报 413。

启用配置并重载：

ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/
nginx -t
systemctl reload nginx

nginx -t 绝对不能省。 语法错误时 nginx -t 报错但 Nginx 保持旧配置继续运行，业务不受影响；直接 reload 则可能让 Nginx 起不来。这一条能避免绝大多数"改完配置网站就挂了"的事故。

改任何配置前先备份：

cp /etc/nginx/sites-available/example.com /etc/nginx/sites-available/example.com.bak

代码上传：这一节插在配置之前讲，因为上传方式会影响后面所有步骤。

方式一，Git 拉取（长期迭代的站点用这个）：

apt install -y git
cd /var/www
git clone https://github.com/你的用户名/你的仓库.git

以后更新只要 cd /var/www/你的仓库 && git pull，不用重新传一遍。 如果站点会长期迭代，这个优势很实在。

方式二，SCP 直接传：

# 在本地机器执行
scp -r ./我的站点 root@服务器IP:/var/www/

方式三，rsync 增量同步（大文件多、要反复同步时用）：

rsync -avz --delete --exclude '.git/' ./我的站点/ root@服务器IP:/var/www/example.com/

--delete 会删除目标目录里源目录没有的文件。 路径写错的后果是删掉服务器上别的东西——这是本文所有命令里最危险的一条，用之前务必确认源和目标路径都写对了。

方式四，WordPress 直接下官方包：

cd /var/www
wget https://cn.wordpress.org/latest-zh_CN.tar.gz
tar -xzf latest-zh_CN.tar.gz
mv wordpress example.com

解压出来是 wordpress 这个目录，名字太通用，多人共机时容易撞名，建议改成你的站点名。

传完之后一定要设对权限，这是 403 的根源：

chown -R www-data:www-data /var/www/example.com
chmod -R 755 /var/www/example.com
chmod -R 775 /var/www/example.com/wp-content/uploads

最后那行针对 WordPress：上传目录需要可写权限，否则后台传图片会失败。 其他目录保持 755 就好——权限给得越宽，攻击面越大。

第四步的验收信号：

nginx -t
curl -I http://127.0.0.1

nginx -t 输出 syntax is ok / test is successful；curl -I 返回 HTTP/1.1 200 OK（有 index 文件）或 404（没有文件但 Nginx 活着）。 后者也是正常的——Nginx 响应了，只是目录里还没放东西。

再补一条 Nginx 常见但容易漏的配置：默认站点要关掉。

rm /etc/nginx/sites-enabled/default

Debian/Ubuntu 的 Nginx 默认带一个 default 站点，它会抢占 80 端口成为默认虚拟主机。 你的站点配置如果没生效、或者访问 IP 显示的是默认页，通常就是它。删掉软链接（不要删 sites-available 里的原文件，删错了还能恢复），然后 systemctl reload nginx。

还有多站点的情况。 同一台机器放两个站，就是再加一个配置文件：

cp /etc/nginx/sites-available/example.com /etc/nginx/sites-available/another.com
vi /etc/nginx/sites-available/another.com

digitalocean 官网机型与实时报价

改里面的 server_name 和 root，然后同样用 ln -s 启用。 两个站点的 server_name 不能相同，端口也不能冲突——这是新手多站点配置失败的最常见原因。

五、第五步：常见报错逐个拆解，报错原文对照处理

这一节是教程里最实用的一段。 报错原文和处理方式一一对应。

502 Bad Gateway——PHP-FPM 没跑起来，或 socket 路径不对：

systemctl status php8.2-fpm
ls /run/php/

404 Not Found——文件位置错了：

ls -la /var/www/example.com/public/

403 Forbidden——权限不对，Nginx worker 以 www-data 身份运行，读不到就是 403：

chown -R www-data:www-data /var/www/example.com
chmod -R 755 /var/www/example.com

413 Request Entity Too Large——上传超限。改 client_max_body_size（第四节已给）。

nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)——80 端口被占：

ss -tlnp | grep :80

nginx: [emerg] invalid number of arguments in "user" directive——配置语法错。nginx -t 会指出具体行号，照着改。

php-fpm.service failed to start——PHP 配置语法错：

php-fpm -t

Killed process 1234 (mysqld)——内存不足被 OOM Killer 杀了：

dmesg -T | grep -i "killed process\|out of memory"

能看到记录就证明真被杀过。 1 GB 机器跑 MySQL 是硬扛不住的，解决办法是升配到 4 GB 或关掉不必要的服务。

Can't create/write to file '/var/run/mysqld/mysqld.pid'——目录不存在或属主不对：

mkdir -p /var/run/mysqld && chown mysql:mysql /var/run/mysqld

mysqld_safe: Please read "Security" section of the manual to find out how to run mysqld as root!——这不是错误，只是提醒你不要用 root 跑数据库。

另外两个不报错但影响体验的问题：

页面平时快、一有并发就卡——PHP-FPM 子进程数不够。改 /etc/php/8.2/fpm/pool.d/www.conf 里的 pm.max_children：1 GB 设 10，2 GB 设 20，4 GB 设 40，然后 systemctl restart php8.2-fpm。

上传图片在后台显示裂图——uploads 目录权限或 PHP 上传限制。chmod -R 775 /var/www/example.com/wp-content/uploads，同时改 php.ini 里的 upload_max_filesize 和 post_max_size（两个都要改，且数值一致）。

通用排错心法：报错信息的第一行通常不是根因，最后一行才是。 顺着报错找占用者，而不是反复重试同一条命令。

最后给一张"症状 → 病因 → 处理"的速查表，这是整份教程里最该截图保存的一段：

症状	最可能的病因	先跑这条命令
网站完全打不开	Nginx 没起 / 防火墙没放行	`systemctl status nginx`、`ufw status`
502	PHP-FPM 没跑或版本写错	`ls /run/php/`
403	目录属主不是 www-data	`ls -ld /var/www/example.com`
404	root 路径错或文件没传上去	`ls -la /var/www/example.com/public/`
413	上传超过默认 1 MB	改 `client_max_body_size`
页面时快时慢	PHP-FPM 子进程数不足	改 `pm.max_children`
站点莫名空白	OOM 杀了 mysqld	`dmesg -T \	grep -i killed`
传不了大文件	PHP 上传限制	改 `php.ini` 两个参数
证书申请失败	DNS 没生效 / 80 被挡	`nslookup`、`ufw status`
只能本机访问	防火墙没放行 80	`ufw status`

查 hostwinds 在售套餐与库存

这张表的用法是：从上往下对照症状，跑了"先跑这条命令"看结果，再决定怎么处理。 比在搜索引擎里反复搜报错原文快得多。

六、第六步：装数据库、建库建用户、连接 CMS

WordPress、Typecho 这类 CMS 都依赖 MySQL。

装完先确认服务起来了：

systemctl status mysql

第一次登录不需要密码：

mysql

建库建用户：

CREATE DATABASE mysite CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'mysite'@'localhost' IDENTIFIED BY '你的强密码';
GRANT ALL PRIVILEGES ON mysite.* TO 'mysite'@'localhost';
FLUSH PRIVILEGES;
EXIT;

utf8mb4 而不是 utf8，这是本节最该记住的一条。 MySQL 里的 utf8 实际是 utf8mb3，最多 3 字节的字符，存 emoji 会报错或被截断。用 utf8mb4 才彻底解决。

测试连接：

mysql -u mysite -p mysite

CMS 后台填的数据库信息必须和上面完全一致：库名 mysite、用户 mysite、密码刚设的、主机 localhost。

密码忘了怎么办？两条路：

路一，免密通道重置（最常用）：

sudo mysql

进去后：

ALTER USER 'mysite'@'localhost' IDENTIFIED BY '新密码';
FLUSH PRIVILEGES;
EXIT;

路二，root 密码也忘了，用初始化流程：

sudo systemctl stop mysql
sudo mkdir -p /var/run/mysqld && sudo chown mysql:mysql /var/run/mysqld
sudo mysqld_safe --skip-grant-tables &
mysql -u root

进去后先执行 FLUSH PRIVILEGES; 再改密码，exit 后 sudo systemctl restart mysql 恢复正常启动。

再补两个数据库的实用操作：

导出和导入（迁移站点时用）：

mysqldump -u root -p --single-transaction --routines --triggers mysite > mysite.sql
mysql -u root -p mysite < mysite.sql

--single-transaction 在生产库上必须加，否则导出会锁表，业务会卡住。

看哪些表最占空间：

mysql -u root -p -e "SELECT table_name, ROUND(data_length/1024/1024) AS mb FROM information_schema.tables WHERE table_schema='mysite' ORDER BY data_length DESC;"

WordPress 表通常不大，uploads 目录才是空间大头——这也是为什么第九节要单独讲清理。

再讲一个真实场景：站点从旧服务器迁到新 VPS 的完整顺序。 这个流程比重新搭一遍更省事：

# 1. 在旧机器上导出数据库和打包文件
mysqldump -u root -p --single-transaction --routines --triggers mysite > mysite.sql
tar -czf www.tar.gz /var/www/example.com

# 2. 传到新机器
scp mysite.sql www.tar.gz root@新服务器IP:/root/

# 3. 在新机器上解压并恢复
tar -xzf www.tar.gz -C /var/www/
mysql -u root -p -e "CREATE DATABASE mysite CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;"
mysql -u root -p mysite < mysite.sql

# 4. 改 wp-config.php 里的数据库密码和站点地址
vi /var/www/example.com/wp-config.php

第 4 步是最容易漏的： wp-config.php 里的 DB_PASSWORD、DB_NAME、还有 WP_HOME 和 WP_SITEURL 都指向旧环境，不改的话站点会报错或者跳转到旧域名。 改完这一步，再做第七步的域名解析和证书。

迁移后必须重新生成密钥，否则新旧站点会互相踢掉管理员登录：

wp salt shuffle

查看 interserver 当前月价与库存

这条命令在 WordPress 站点迁移后经常被漏掉，症状是"登录时提示用户名或密码错误，但密码是对的"——因为会话 cookie 用了不同的盐值。

七、第七步：域名解析、HTTPS 证书与强制跳转

这是整份教程里最容易白忙一场的一步，也是"网站搭好了却打不开"的头号原因。

第一步，加 A 记录。 在域名服务商处添加，主机记录填 @ 和 www，记录值填服务器 IP。

第二步，确认解析生效：

nslookup example.com

返回的 Address 和你的服务器 IP 一致，才算成功。 解析生效通常几分钟，有些注册商可能长达 24 小时。

第三步，申请证书：

curl https://get.acme.sh | sh -s email=你的邮箱
source ~/.bashrc
~/.acme.sh --issue -d example.com -d www.example.com --nginx

成功标志是输出一串带 https:// 开头的证书路径。 失败的话按这个顺序排查：先 nslookup 看 DNS，再 ufw status 看 80 端口有没有放行，最后看 80 端口是不是被跳转了。

acme.sh 有两种验证方式：

方式	命令	特点
Nginx 插件	`--nginx`	自动改配置、自动 reload，最省事
Standalone	`--standalone`	占用 80 端口，需先停 Nginx

查看 itldc 当前月价与库存

用 --nginx 插件的前提是 Nginx 配置合法。 如果配置有语法错，插件会因为无法 reload 而失败，但报错指向 Nginx 配置而不是证书本身，容易误判成证书问题——这时先 nginx -t。

第四步，安装证书并设置自动续期：

~/.acme.sh --install-cert -d example.com \
  --key-file /etc/ssl/private/example.com.key \
  --fullchain-file /etc/ssl/fullchain/example.com.pem \
  --reloadcmd "systemctl reload nginx"

第五步，Nginx 启用 443：

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

    ssl_certificate     /etc/ssl/fullchain/example.com.pem;
    ssl_certificate_key /etc/ssl/private/example.com.key;

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

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

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

同时把 80 端口的块改成纯跳转：

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

第六步，验证续期真的能工作。 不要默认它没问题：

~/.acme.sh --cron --force

看到输出显示下次续期时间，才算通过。 有些面板会改写 crontab 让续期任务静默失效——这是"证书三个月后突然过期"的典型原因。

八、第八步：让站点跑得快的四个零成本优化

优化前必须先测基线，否则你无法证明优化有没有用：

curl -o /dev/null -s -w 'TTFB: %{time_starttransfer}s  Total: %{time_total}s  Size: %{size_download}\n' \
  https://example.com/

优化一：Nginx 开启 gzip。 文本资源通常能压到原体积的四分之一左右：

gzip on;
gzip_vary on;
gzip_min_length 1024;
gzip_types text/plain text/css application/javascript application/json application/xml;

优化二：静态资源设长缓存。

location ~* \.(jpg|jpeg|png|gif|webp|svg|ico|css|js|woff2)$ {
    expires 30d;
    add_header Cache-Control "public, immutable";
}

这两条组合起来，第二次访问时静态资源几乎不占带宽。

优化三：OPcache。 第三节已经装了，这里再强调一次它的量级：WordPress 站点开了 OPcache 后，PHP 侧的执行时间通常能降一半以上，而且是免费的。

优化四：给图片生成缩略图。 一张 3000 像素的原图直接进页面可能要传 2 MB，缩略图 + WebP 转换能把首屏传输量降一个量级，这不需要改服务器配置，只需要一次性处理。

再补一条 WordPress 专属的：清理用不到的东西。

wp plugin list
wp transient delete --all

插件装得越多，页面加载时执行的 PHP 越多。 十个不用的插件带来的开销，可能比加 2 GB 内存还大。

查 spinservers 在售套餐与库存

正确的优化顺序是：先测基线 → 做零成本配置优化（gzip、缓存、OPcache）→ 再测 → 仍不够再考虑升配。 顺序反了就是花钱买不必要的配置。

九、第九步：上线之后的运维四件事

部署完不等于结束。 这四件事决定出问题时的损失大小。

第一，备份，且要自动化。 手动执行一次不难，难的是每周想起来做一次：

mkdir -p /root/backup
echo "3 3 * * * mysqldump -u root -p'你的密码' --single-transaction mysite | gzip > /root/backup/mysite_\$(date +\%F).sql.gz && find /root/backup -name 'mysite_*.sql.gz' -mtime +14 -delete" >> /etc/crontab

gzip 能把几百 MB 的 SQL 压到十分之一左右；find ... -mtime +14 -delete 自动清理老备份，磁盘小的机器上不能省。

文件也要备份：

rsync -avz --delete --exclude 'cache/' /var/www/ user@备份机:/backup/www/

备份不能放在同一台机器上。 机器挂了备份跟着没，这不算备份。

第二，监控内存和磁盘：

free -m
df -h /
cat /proc/loadavg

磁盘使用率超过 80% 就要处理。 日志把根分区写满，会导致 MySQL 写不进去、FTP 传不上去、面板操作全部失败——这是 VPS 上最常见的"突然全挂"原因，很多人第一反应是"服务商坏了"，其实是自己的盘满了。

磁盘占满的常见来源是 WordPress 的 uploads 目录，定期清理可以：

find /var/www/example.com/wp-content/uploads -type f -mtime +90 -exec ls -lh {} \;

先 ls 看清楚再删。 上传目录里可能有你还需要的东西。

第三，防火墙收敛端口。

ss -tlnp
ufw status verbose

除了 SSH、80、443，其余端口都该关掉。

第四，日志轮转。 确认 logrotate 覆盖了 Nginx 和 MySQL：

vi /etc/logrotate.d/nginx

没有轮转的日志会一直涨，最后把磁盘吃满。

再加一个站点存活监控，每 5 分钟探一次：

cat > /usr/local/bin/site_watch.sh << 'EOF'
#!/bin/bash
CODE=$(curl -o /dev/null -s -m 10 -w '%{http_code}' https://example.com/)
if [ "$CODE" != "200" ]; then
  echo "$(date '+%F %T') 站点异常 HTTP=$CODE" >> /var/log/site_watch.log
fi
EOF
chmod +x /usr/local/bin/site_watch.sh
echo "*/5 * * * * /usr/local/bin/site_watch.sh" >> /etc/crontab

zenlayer 官网机型与实时报价

监控日志真正的价值是时间线：出问题后一翻就知道"从今天凌晨 2 点开始连续异常"，这比"可能是最近几天"有用得多。

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

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

只想搭个站、预算优先：先看价格最低那档够不够用，别为用不上的配置付钱。看 iwebfusion 当前机型与价格
做跨境或店群、需要多 IP：优先看 IP 类型与换 IP 政策，别只看配置。看 racknerd 当前机型与价格
主要访客在国内、在意打开速度：先确认回程线路，再谈配置。看 cloudcone 当前机型与价格
只是开发测试、临时用：按小时或月付，用完就删，别买年付。看 digitalocean 当前机型与价格

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

十、第十步：验收清单，以及什么情况下该换方案

部署完成后逐条打勾，全部打上才算完工：

#	检查项	验收方式
1	密码已改，SSH 端口已换	`ss -tlnp` 里没有 22
2	fail2ban 在跑	`systemctl is-active fail2ban` 返回 active
3	防火墙规则与实际端口一致	`ufw status` 里有 SSH、80、443
4	站点正常返回	`curl -I http://127.0.0.1` 返回 200 或 301
5	域名解析生效	`nslookup` 返回你的服务器 IP
6	HTTPS 可用并自动跳转	访问 `http://` 自动跳 `https://`
7	证书续期正常	`~/.acme.sh --cron --force` 显示下次续期时间
8	数据库定时备份	crontab 里有备份任务
9	内存有余量	`free -m` 的 available 高于总内存 15%
10	磁盘有空间	`df -h /` 使用率低于 80%

查 justg 在售套餐与库存

第 9、10 条是要长期复看的两项。 其余八条是部署时一次性的。

再说六种不该用 VPS 建站的情况，每种配一个替代方向：

第一，你只是要放一个静态页或落地页表单。 共享虚拟主机更便宜更省事，你用不上 root、SSH、Nginx 和证书。VPS 的价值在于你要装自己的东西。

第二，访问量小且你没有技术维护能力。 1 GB 跑静态站没问题，但一旦磁盘满、证书过期、服务起不来，你得自己排查。不打算学这些的话，带控制面板的虚拟主机更稳妥。

第三，你需要可预期的稳定带宽。 VPS 的带宽通常是端口分配上限，晚高峰能否跑满取决于共享情况。大流量分发该看独享带宽产品线——商品库里 LAX-MEDIUM 和 LAX-LARGE 都标称 10000 Mbps，LAX-STARTER 标称 2000 Mbps，LAX-Storage-500G 是 500 GB 硬盘加 10000 Mbps。

第四，你要跑长时间吃 CPU 的任务。 渲染、编译、爬虫这类持续满载的活，普通 VPS 共享资源池会被降速。该看的是高核心数机型：RosCloud-06 是 7 vCPU、24 GB 内存、每月 69.99 美元；LAX-LARGE 是 8 vCPU、16 GB 内存、1600 美元/年折合每月 133.33 美元。

第五，站点要长期稳定服务国内用户。 大陆节点需要 ICP 备案，周期和资质都会拖慢上线；用境外节点则要接受首字节延迟比大陆节点高——这是物理距离决定的，不是换机器能解决的。

第六，你要跑的是长连接服务、消息队列、复杂后端编排。 这些该上容器服务或函数计算，不是拿一台 VPS 硬扛。

把整条流程收一下：确定用途 → 安全基线 → 装环境 → 配 Nginx → 排错 → 装数据库 → 域名和 HTTPS → 性能优化 → 运维兜底 → 验收清单。 每一步都有明确的验收信号，第十节的十项检查是你交卷的标准。 十项全过，你的站就能长期活着了。

最后补一条心态上的建议，这条比任何技术细节都重要：搭站是一个可以失败重来的过程，而生产环境上的每一次改动都可能是事故。 所以在非生产环境把每一步先走一遍，你会发现真正上线时根本不会紧张。WordPress 有专门的测试环境主题，Docker 也能在本机跑一整套 Nginx+PHP+MySQL——花一个下午建一套本地环境，能省掉上线后几十倍的排错时间。

反过来，有几条原则是无论测试还是生产都要守的：改配置前备份、数据库操作前导出、rm 和 rsync --delete 前确认路径。 这三条不是技术问题，是纪律问题，它们决定了你是"改坏了改回来"还是"数据没了找不回"。

还有一条容易被忽略的：给站点做一次完整的"故障演练"。 挑一个你方便的时间，故意把 PHP-FPM 停掉，看监控脚本能不能在 5 分钟内记下异常；然后故意把数据库密码改错，看 CMS 后台的报错是不是你能一眼看懂。演练一次之后，你对这套系统的"哪里会坏、坏了长什么样"就有了实感，而不是等真出事那天第一次见。

关于价格，再明确一次本文里所有数字的来源和时效：文中出现的所有机型配置和价格，都取自渠道库快照（数据时间 2026-11-06 13:28），具体到每个套餐的月费、内存、硬盘、带宽和流量配额；没有出现在商品库里的项，本文一律标注以官网当日报价为准。商家会调整价格、库存和线路类型，下单前请以商家页面当日显示为准。

价格与库存来自渠道库快照（数据时间 2026-11-06 13:28），以官网当日报价为准。下单前请确认商家是否支持按月付费、退款窗口多长、流量超额如何计费。

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