VPS服务器搭建教程:完整步骤与常见报错
来源: 飞翔小编 2026/11/4 10:04:51 浏览量:0
一、搭建流程其实只有六个阶段,别把顺序搞反

VPS服务器搭建这件事,本质是一条有依赖关系的链:买机器之前想不清楚要什么配置,买完之后才发现登录方式变了,装环境的时候才发现系统版本对不上,上线之后才发现端口全开着。任何一步顺序颠倒,后面都要返工,而返工的成本远高于一开始花十分钟算清楚。
把流程拆成六个阶段,每个阶段有一个明确的产出物和一个明确的验收标准:
| 阶段 | 要做的事 | 产出物 | 验收标准 |
|---|---|---|---|
| 一、选型 | 算单位成本、定配置 | 一张配置表 | 内存单价和流量单价都知道 |
| 二、开机 | 记录连接信息 | 一份连接信息表 | IP、端口、密码、时区四项齐全 |
| 三、登录 | 确认机器状态 | 首屏输出 | 磁盘、内存、CPU 三项读数正常 |
| 四、初始化 | 换源、建用户、改 SSH | 一个非 root 管理用户 | 禁用密码登录后仍能登录 |
| 五、加固 | 防火墙、端口、权限 | 开放的端口清单 | 只留 22/80/443 三类 |
| 六、上线 | 装环境、跑实测 | 验收报告 | 首字节、下载、内存三项达标 |
这张表的价值在于它把「搭建完成」从一个主观感受变成了一张可以打勾的清单。很多人以为自己搭完了,其实只是登录进去看了一眼 motd,端口全开、面板密码是默认值、swap 是 0,这些隐患要等到被扫描或者被入侵时才暴露。
还有一个必须先说的前提:搭建步骤的顺序,和你买的是年付还是月付、线路是国内优化还是国际线路、系统是 Debian 还是 CentOS,这三个因素完全无关。命令层面的差异很小,差异大的是你在第二步抄下来的那串信息,以及你在第六步跑出来的实测数字。如果你的目的是快速上线,这一篇从第三节开始读就够;如果你的目的是搞清楚「为什么同样一台 VPS,别人搭出来比我快两小时」,从第二节开始。
二、先算账:同样两 GB 内存,月付与年付差在哪里

在动手之前必须把「搭建一台机器要花多少钱」变成一个可以比较的数,否则你只有感觉没有判断。判断的第一步是把总价拆成单位成本,单位成本才是可以横向比较的指标。
下面是同一条产品线六档真实在售价格的单位成本拆解,按月付费,全部来自商家在售机型库:
| 机型 | 月费 | 内存 | 系统盘 | 月流量 | 内存单价 | 磁盘单价 | 流量单价 |
|---|---|---|---|---|---|---|---|
| RosCloud-01 | 19.99美元 | 1 GB | 20 GB | 1024 GB | 19.99美元/GB | 1.00美元/GB | 19.99美元/TB |
| RosCloud-02 | 29.99美元 | 2 GB | 40 GB | 2048 GB | 14.99美元/GB | 0.75美元/GB | 15.00美元/TB |
| RosCloud-03 | 39.99美元 | 4 GB | 80 GB | 3072 GB | 10.00美元/GB | 0.50美元/GB | 13.33美元/TB |
| RosCloud-04 | 49.99美元 | 8 GB | 160 GB | 4096 GB | 6.25美元/GB | 0.31美元/GB | 12.50美元/TB |
| RosCloud-05 | 59.99美元 | 16 GB | 240 GB | 5120 GB | 3.75美元/GB | 0.25美元/GB | 12.00美元/TB |
| RosCloud-06 | 69.99美元 | 24 GB | 320 GB | 6144 GB | 2.92美元/GB | 0.22美元/GB | 11.67美元/TB |
三张单价表摆在一起,结论有三条。
第一条,内存单价从 19.99美元/GB 降到 2.92美元/GB,降幅超过 85%,而流量单价只从 19.99美元/TB 降到 11.67美元/TB,降幅 41%。也就是说这条产品线是按流量台阶定价的,内存和磁盘是在台阶上顺带附赠的。你如果是一个纯自用脚本机器、几乎不产生流量,那么买大内存档是浪费;你如果是一个下载站或者带图的内容站,那么流量单价才是你真正要对比的指标。
第二条,从 01 档到 06 档内存翻了 24 倍,价格只涨了 3.5 倍;但流量只涨了 6 倍,价格同样涨 3.5 倍。流量涨得比内存慢,但慢得没有内存那么多。所以「买高一档一定划算」这句话在这条线上只在内存和磁盘维度成立。
第三条,把流量换算成可承载的访问量,按每次访问平均消耗 2 MB(页面加图片加样式脚本)计算:
| 机型 | 月流量 | 折合月访问量 | 折合日均访问量 |
|---|---|---|---|
| RosCloud-01 | 1024 GB | 约 53.7 万次 | 约 1.79 万次 |
| RosCloud-03 | 3072 GB | 约 161 万次 | 约 5.37 万次 |
| RosCloud-06 | 6144 GB | 约 322 万次 | 约 10.7 万次 |
年付线的情况完全不同。另一家在售产品线的起步档是年付 200 美元,折合每月 16.67 美元,配置 2 核 2 GB、40 GB 磁盘、5000 GB 月流量、2000 Mbps 带宽。它的单位成本是:内存 8.33美元/GB、磁盘 0.417美元/GB、流量 3.413美元/TB。
把两台放在一起对比:同样 2 GB 内存,月付的 RosCloud-02 是 29.99美元/月、2048 GB 流量;年付的起步档折合 16.67美元/月、5000 GB 流量。年付档价格低 44%,流量多 2.44 倍,流量单价便宜了将近五倍。这就是搭建教程第一课:先算账,再决定月付还是年付,而不是反过来。
三、下单那一刻,这五项信息必须抄进备忘录

搭建出问题的案例里,超过一半不是技术问题,而是「信息没保存」。商家面板关掉之后,IP 可以从账单里翻,密码只能重置,重置要等人工或邮件,所以正确的做法是在下单完成、机器亮起绿灯的那一分钟,把下面这些信息一次性抄下来。
第一项:公网 IP 地址。这个最容易抄错,因为很多商家在面板里给的是 IPv6,邮件里给的却是 IPv4。抄之前先确认位数:IPv4 是四段十进制数字,IPv6 是带冒号的十六进制串。SSH 用的是 IPv4。
第二项:SSH 端口。VPS 的 SSH 端口不一定是 22,多数商家默认是 2222、10022 或者随机的高位端口。这个端口如果不抄下来,你后续所有连接都要靠试,而每试错一次就可能触发商家的暴力破解封禁。
第三项:root 密码。抄的时候注意字符区分:数字 0 和字母 O、小写 l 和数字 1、大写 I 和小写 L 在密码里极易混淆。抄完立刻自己手动敲一遍验证,别相信「我看清了」。
第四项:控制面板地址和账号。很多商家给的是自研面板而不是常见的网页控制台,地址在邮件里。如果用的是默认密码,拿到机器后第一件事就是改掉。
第五项:时区和系统版本。时区设成 UTC 而你以为它是本地时间,服务器日志和你的日志就会差八小时,排查问题时会得出完全错误的结论。
| 信息项 | 抄错的后果 | 补救代价 |
|---|---|---|
| IP 地址 | 连不上,怀疑机器坏了 | 找商家核对,耗时半天 |
| SSH 端口 | 连不上,报 Connection refused | 逐个试端口,可能触发封禁 |
| root 密码 | 无法登录,只能重置 | 重置需等待,短则几十分钟 |
| 面板地址 | 无法自行重装系统 | 联系客服 |
| 时区 | 日志错位八小时 | 可改,但排查成本已经产生 |
第六个建议:下单时把付款方式记清楚。如果用的是自动续费的支付方式,还要额外确认退款窗口和续费价格是否与首单一致。有些商家首单价格低、续费按原价,这一差额在搭建阶段不会显现,到第二年才暴露。
四、第一次登录:三行命令确认机器状态对不对

拿到 IP、端口、密码之后,第一件事不是安装任何东西,而是确认你拿到手的是一台状态正常的机器。养成这个习惯,可以在十分钟内发现磁盘没分区、内存被超售、CPU 被限速这三类问题,而不是等到装完环境才发现慢。
用系统自带客户端连,不要一上来就用第三方工具:
ssh -p 端口号 root@你的IP
连上之后,先跑这三条:
df -h
free -m
nproc
三条命令的读数怎么算,才算状态正常。
df -h 看磁盘。至少要有两个挂载点:根目录 / 和 boot 分区。有 /boot 说明系统是分区安装的;只有 / 一个挂载点,说明商家用了整盘镜像或云盘快照。真正要盯的是已用百分比和容量。如果标称 20 GB 系统盘,df -h 显示 14 GB,说明商家给的实际是 15 GB 左右的可用空间——这个差额必须在第一天知道,而不是等到系统盘满了打不开面板。
free -m 看内存。重点看 total 这一行的数值是不是等于你买的规格。买 2 GB 的机器,total 显示 2048 上下是正常的;如果显示 2016 或者更低,多出来的那部分是内核保留,这很正常。但如果你买的是 2 GB,total 显示 1900 以下,那就要问商家了。另一个关键指标是 available:在 Debian 12 或 Ubuntu 22.04 上,刚开机的 available 通常在 800 到 950 MB 之间,如果只有 200 多,说明系统里已经跑了别的东西。
nproc 看 CPU。输出数字应与订单规格一致。同样,共享型架构下宿主机超售是常态,所以 nproc 对得上不代表 CPU 是独享的,这一条只用来发现「规格给错」,不用来判断性能。
| 读数 | 正常范围 | 异常信号 |
|---|---|---|
| df -h 已用 | 新机 5% 到 20% | 超过 40% 说明不是新机 |
| free -m available | 1 GB 机型约 800–950 MB | 低于 400 MB |
| nproc | 与订单一致 | 少于订单规格 |
顺带确认一下时区和时间:
timedatectl
Time zone 那一行如果不是你的本地时区,用 timedatectl set-timezone Asia/Shanghai 改掉。这个命令需要 systemd,在 CentOS 7 这类老系统上会报 "Failed to connect to bus",改用编辑 /etc/localtime 的软链接方式。
五、系统初始化:四步换成一个能长期用的状态

初始化的目标是:用非 root 账号日常登录,用密钥而不是密码登录,把系统更新到当前小版本。这四件事做完,这台机器才算进入可长期使用的状态;没做完就往上装环境,等于在裸奔的系统上跑生产服务。
第一步,更新系统。Debian/Ubuntu 一系:
apt update && apt upgrade -y
CentOS 一系:
yum update -y
更新前先看一遍将要升级的包列表。如果列表里出现内核大版本升级(比如从 5.10 跳到 6.x),建议更新后立刻重启一次,否则新内核不会生效,你以为加固了其实跑的还是老内核。重启用 reboot,然后等两三分钟重新连。
第二步,换软件源。默认源在海外机器上拉取会慢到几十 KB/s。用国内镜像源可以把这个过程从几十分钟缩短到一两分钟。以 Debian 12 为例:
cp /etc/apt/sources.list /etc/apt/sources.list.bak
sed -i 's|deb.debian.org|mirrors.aliyun.com|g; s|security.debian.org|mirrors.aliyun.com|g' /etc/apt/sources.list
apt update
注意 cp 那一步必须先做,源地址写错了系统会直接 apt update 报错。改完跑一次 apt update 验证,出现 Hit 和 Fetched 才算成功。如果只看到 Err,把备份还原回去:
cp /etc/apt/sources.list.bak /etc/apt/sources.list
第三步,建管理用户并给 sudo。
adduser deploy
usermod -aG sudo deploy
usermod 加 -aG 而不是 -G,这两个参数顺序写反的后果不一样:-aG 是追加到现有组,-G 是覆盖组列表。如果只写 -G sudo,用户原有的其他组就没了。
第四步,改 SSH 配置。这一步有严格的先后顺序,顺序错了会把自己关在门外:
vim /etc/ssh/sshd_config
要改的项是这几条:
Port 你的端口
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
改完先在当前这个已登录的终端里另开一个新终端测试:
ssh -p 端口号 deploy@你的IP
能登进去,再在另一个终端执行 systemctl restart sshd。不要先关密码登录再测,那样你只有一个会话可以救。确认新会话能用之后,才执行 exit 断开旧连接。
如果你在改配置时发现自己被踢出来了,最常见的恢复办法是商家控制台的「重置 SSH 配置」或者「VNC/Console 登录」,从控制台进去把 PasswordAuthentication yes 改回来。这个功能不是每个商家都有,所以改 SSH 之前先确认你的商家提供控制台登录,这是一条实操上的硬性前置条件。
六、防火墙与端口:留三类,其余全关

服务器暴露在公网上,扫描器在开机后的几分钟内就会开始探测。防护的第一道不是装什么安全软件,而是默认拒绝,只放行必须的端口。这一节的验收标准是明确的数字:最终开放的端口数量不超过三类。
SSH 端口。保留你第二阶段抄下来的那个端口。
HTTP 与 HTTPS。80 和 443 两个都要开,因为 80 不只是给 HTTP 用的,绝大多数场景下还要用它做 HTTPS 的跳转和 ACME 证书签发验证。如果你的站点只用 443,签发证书时 80 也得临时放行。
数据库端口。这一条是新手最容易犯错的地方:MySQL 的 3306 和 PostgreSQL 的 5432 绝对不能对公网开放。正确做法是只监听本机:
sudo vim /etc/mysql/mysql.conf.d/mysqld.cnf
把 bind-address 改成 127.0.0.1,改完重启数据库服务。本地客户端用 SSH 隧道连数据库,安全性比公网暴露高一个数量级。
用 ufw 管防火墙的标准做法:
ufw default deny incoming
ufw default allow outgoing
ufw allow 你的SSH端口/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable
ufw enable 会提示可能断开 SSH 连接,它问的正是「你当前的 SSH 端口是不是在允许列表里」。如果你之前用 ssh -p 端口号 连的,而规则里写的是默认的 22,执行这条命令之后你就再也连不上了。确认端口写对了再回车。
验证结果:
ufw status verbose
输出里的 Status: active 是第一道验收,第二道是 ALLOW IN 那一列只列出你放行的那几条。
如果你更习惯直接用防火墙的发行版默认工具,CentOS 用的是 firewalld,命令名不一样但逻辑相同:先 firewall-cmd --permanent --add-service=http 和 --add-service=https,再 firewall-cmd --permanent --add-port=你的SSH端口/tcp,最后 firewall-cmd --reload。
权限的默认值也应该收紧。新建的文件默认 644、目录 755 是通用设置,但私钥必须是 600:
chmod 600 ~/.ssh/id_rsa
chmod 700 ~/.ssh
这一步经常被跳过,导致私钥权限过宽时 SSH 直接拒绝使用该密钥,报 UNPROTECTED PRIVATE KEY FILE——很多人这时候以为是密钥坏了,其实只需要 chmod。
| 检查项 | 达标标准 | 常见错误 |
|---|---|---|
| 入站端口数 | 不超过 3 类 | 数据库端口对公网开放 |
| SSH 密码登录 | 已关闭 | 先关密码后测新连接 |
| 私钥权限 | 600 | 644 导致 SSH 拒用密钥 |
| 防火墙状态 | active | 规则写了但没 reload |
七、一键脚本的能力边界在哪里

「一键搭建」这个词在搜索里出现频率极高,但它的实际含义是「把一堆你已经知道该做什么的命令封装进一个脚本」。它能省时间,省不了理解。搞清楚它的能力边界,你才知道什么时候该用它、什么时候必须自己敲。
一键脚本能替你做的事:装系统依赖、初始化数据库、写好默认配置文件模板、生成证书申请、创建第一个站点目录并配好权限。这部分价值最高,因为它涉及的文件多、参数容易漏。
一键脚本替不了你的事:判断你的业务需要多少内存、决定哪些端口该开、设置数据库密码的强度和备份策略、在面板里配好 CDN 和缓存规则、知道你的访问者在国内还是海外。
最需要警惕的一类脚本是「面板」。图形化面板把服务器管理变得直观,但它的代价写在架构里:面板本身是一个常驻进程(通常 100 MB 到 300 MB 内存),它自带一个 Web 服务(通常监听一个非标准高位端口),它默认会安装自己的防火墙规则、默认会开放面板端口、默认会创建数据库超级用户。装面板之前先算一笔账:
以一台 2 GB 内存的机器为例,裸机系统可用内存约 1350 MB(计算方法见第八节),装上面板加上一套 LNMP 环境之后,剩余可用内存通常只有 600 MB 到 800 MB。如果你的业务本身就要吃掉 1 GB,这台机器在装面板之后是撑不住的。
| 方案 | 内存占用量级 | 上手速度 | 适合谁 |
|---|---|---|---|
| 纯手工安装 | 0 额外开销 | 慢 | 要长期维护、配置复杂 |
| 一键脚本(无面板) | 几十 MB | 中 | 一次性搭建 |
| 图形面板 | 100–300 MB | 快 | 需要可视化、频繁改配置 |
结论是:如果你的机器只有 1 GB 或 2 GB 内存,不要装图形面板;如果机器是 8 GB 以上并且你要频繁调参数,面板能省下的时间是真金白银。这不是说面板不好,而是说它是一笔要用内存去换的账。
还有一条经验:装面板之前,先用 df -h 看系统盘剩余空间。主流面板加上它的数据库和默认软件栈,会占掉 5 GB 到 10 GB 的系统盘。20 GB 的系统盘装完面板就只剩个位数 GB,后续更新和日志会把这个空间吃光,然后你会遇到「服务莫名重启」这种查起来很费劲的问题。
八、上线前的三项实测,把阈值写死

搭建的最后一关是实测。实测必须先定阈值再跑,否则测出来的数字没有意义——「挺快」不是标准,「首字节 280 毫秒」才是。
第一项:首字节响应时间。在服务器本地测:
curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\n" http://127.0.0.1/
再从本地机器测对外的表现:
curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\n" http://你的域名/
验收阈值:工作日 20:00 至 22:00 的晚高峰时段,连续测三次取中位数,首字节低于 300 毫秒为达标。晚高峰测是因为线路质量在晚高峰会显著恶化,白天测出来的好成绩没有参考价值。
第二项:1 MB 文件下载耗时。
curl -o /dev/null -s -w "下载: %{speed_download} B/s\n" http://你的域名/1mb.bin
验收阈值:1 MB 文件在 2 秒内下载完成,即平均速率不低于 500 KB/s。如果你的业务是大图或视频,这个阈值要按实际文件大小重新算。
第三项:内存谷值。
free -m
验收阈值:空闲状态下已用内存占总内存的比例低于 15%。超过这个数说明有常驻进程在偷内存,常见原因是某个服务反复重启后堆积、面板的定时任务,或者 swap 被占着不放。
第四项补充检查:磁盘使用率低于 70%,留出日志和更新的空间;uptime 连续观察 72 小时无重启。
| 指标 | 达标阈值 | 不达标先查什么 |
|---|---|---|
| 首字节响应 | 晚高峰中位数 < 300 ms | 是不是跨洲线路、是不是本地回环 |
| 1 MB 下载 | < 2 秒(≥ 500 KB/s) | 带宽端口是不是被限速 |
| 空闲内存占用 | < 15% | 有无僵尸进程、swap 占用 |
| 磁盘使用率 | < 70% | 日志、系统盘容量 |
| 连续运行 | 72 小时无重启 | 是否有 OOM 或计划任务 |
内存预算的具体算法要记牢。以 1 GB 机器为例:物理内存 1024 MB 减掉内核、systemd 与基础服务常驻约 120 MB,剩 904 MB,乘 70% 作为安全线是 633 MB 可分配。Nginx 空载约 45 MB,PHP-FPM 开 4 个 worker 约 120 MB,MySQL 空载约 380 MB,三者合计 545 MB,余量只剩 88 MB。换算到 2 GB 机器:可用预算约 1350 MB,同样这套环境用掉 545 MB,余量 805 MB,这就是 2 GB 能当建站起点的真正原因。
九、什么情况下不该按这套流程走

这一节是本文最该被跳读的部分,因为流程跑通不代表流程适用。下面四个场景,按公开事实推演,不涉及对任何商家的评价。
场景一:你需要的是独立 IP 段而不是一台独立主机。部分产品线的定位是住宅 IP 出口或双 ISP 线路,价格结构与通用云主机完全不同。判断依据是业务是否要求 IP 的属性——需要登录第三方平台、需要固定的住宅属性、需要 IP 段不被标记为机房段,那么通用云主机的 IP 就不适用。替代方案是找明确提供该类 IP 的产品线,它们的价格体系是另一套,不能拿本文的单位成本表去套。
场景二:你的访客主要在国内,而线路是跨洲直连。判断依据是机房位置和回程线路类型。洛杉矶的机房到国内物理距离在 100 毫秒量级起,任何配置都改不了这个物理下限。如果你的业务是纯后台、异步处理、或者面向海外用户,跨洲没有问题;如果首屏打开速度直接决定转化,那么应该看的是回程线路属性,而不是 CPU 和内存。
场景三:你的需求随时会变,但你打算一次买够。判断依据是计费方式。年付在单位成本上确实更优——前文对比过,同规格年付折合月费比月付低 44%,流量单价低近五倍。但年付意味着需求判断错误的成本从一个月变成一年。对需求还在摸索阶段的场景,替代方案是月付跑完整个搭建与实测流程,确认线路和数据都符合预期后再转年付。
场景四:你需要的是可验证的带宽,而不是套餐上写的峰值带宽。在售产品线里出现过带宽 100 Mbps 但未标注流量与内存规格的独立机型,这类按端口计费的产品适合大流量低并发场景,不适合需要明确内存配比的应用。判断依据是套餐是否同时给出 CPU、内存、磁盘、流量四项。四项齐全才能做单位成本对比;只有带宽一项的,无法参与本文的算法,替代方案是选四项齐全的产品线。
| 场景 | 判断依据 | 不该选的原因 | 替代方向 |
|---|---|---|---|
| 要住宅/双 ISP IP | IP 属性 | 机房 IP 属性不匹配 | 专业 IP 线路产品线 |
| 访客在国内、跨洲直连 | 机房位置与回程线路 | 物理距离决定延迟下限 | 优化回程线路的节点 |
| 需求未定却要一次买够 | 计费方式 | 年付把试错成本放大 12 倍 | 先月付跑完实测 |
| 只要端口带宽 | 套餐字段完整性 | 无法算单位成本、无法定容量 | 四项齐全的套餐 |
十、给三类人的具体建议

读完前面九节,把结论压缩成可直接执行的判断。
第一类:完全没接触过服务器,目标是尽快把一个站点跑起来。买一台 2 GB 内存、40 GB 系统盘的月付机器,配 2 GB 内存是这一档里性价比拐点的起点——内存单价 14.99美元/GB,相比 1 GB 档的 19.99美元/GB 已经便宜下来,流量也从 1024 GB 涨到 2048 GB。搭建时不要装图形面板,用一键脚本装完 LNMP,把省下的内存留给数据库。第一个月的目标只有一个:把第八节的三项实测全部跑完并记录数字。
第二类:已经在跑站点,需要升级或迁移到更省的方案。先把当前的单位成本算出来——现在的月费除以内存 GB 数、除以磁盘 GB 数、除以月流量 TB 数——再和本文表格里的数字对照。如果你的流量单价明显高于 15.00美元/TB 这一档,说明你在为流量付高价,这时候对比年付线的 3.413美元/TB 这一量级,能省下来的空间远大于省在内存上的。迁移时先迁数据、再切解析,用 DNS 的 TTL 留出回退窗口,不要一次性切完。
第三类:做的是有明确下载或大流量属性的业务。这条线上流量单价最低的是年付线的 3.413美元/TB,对应 5000 GB 起步流量、2000 Mbps 带宽的套餐;另一家在售产品线里 400 美元年付的存储型套餐给到 500 GB 磁盘、10000 GB 流量、10000 Mbps 端口,磁盘单价低到 0.067美元/GB,适合需要本地大文件缓存的场景。这类业务选型的第一原则是先看流量单价,再看内存单价,顺序反了就会为用不上的内存付钱。
三类人都不需要「视情况而定」。共同的动作只有一个:先月付、先实测、先记录数字,再决定年付。
按你的情况,下一步该看哪家
上面讲的是判断标准,但多数人最后还是想问一句「那我该买谁」。按你的实际情况对照下面几条,直接去看对应的机型页比继续比价更快:
- 只想搭个站、预算优先:先看价格最低那档够不够用,别为用不上的配置付钱。看 cloudcone 当前机型与价格
- 主要访客在国内、在意打开速度:先确认回程线路,再谈配置。看 digitalocean 当前机型与价格
- 只是开发测试、临时用:按小时或月付,用完就删,别买年付。看 hostwinds 当前机型与价格
价格与库存以商家页面当日显示为准,下单前建议先确认退款窗口与是否支持按月付费。
十一、常见问题

Q:搭建过程中最常见的报错是什么?
连接类的是 ssh: connect to host ... port ...: Connection refused,绝大多数情况是端口填错或者防火墙规则里没有放行你实际使用的端口;认证类的是 Permission denied (publickey),说明密钥没传到服务器的 ~/.ssh/authorized_keys 或者权限不对(需要 600);改完 sshd_config 后 sshd 起不来并报 Missing privilege separation directory,是 /run/sshd 目录缺失,执行 mkdir -p /run/sshd 即可。
Q:为什么装完环境内存就占了 60% 以上?
先跑 free -m 看 available 那一列而不是 used。Linux 会把空闲内存拿去做页缓存,used 高不代表内存紧张,真正可用的是 available。如果 available 也只剩几百 MB,才需要排查具体进程,用 ps aux --sort=-%mem | head -10 找出占用最高的进程。
Q:1 GB 内存能不能装完一整套环境?
能装完,但要按第八节的预算线来用:可分配约 633 MB,而 Nginx 加 PHP-FPM 加 MySQL 合计约 545 MB,余量只剩 88 MB。结论不是「不能装」,而是「装完之后不能有任何波动」,一次插件更新或一次日志暴涨就会触发换页甚至 OOM。所以 1 GB 的正确用法是静态站点、脚本和定时任务,带数据库的站点从 2 GB 起步。
Q:年付到底什么时候值得买?
当三件事同时成立的时候:第一,你已经用月付跑完实测,晚高峰首字节和 1 MB 下载都达标;第二,你确认这条线路和这个机房在接下来一年不会调整;第三,你的业务不会在半年内因为流量或负载变化而需要换规格。满足这三条,年付的单位成本优势是实打实的;不满足,多花的三个月试错成本会吃掉折扣带来的节省。
Q:服务器时间不对导致日志对不上,怎么修?
先 timedatectl 看 Time zone 和 System clock synchronized 两行。时区不对用 timedatectl set-timezone Asia/Shanghai 改;时钟没同步用 timedatectl set-ntp true 打开,或者手动执行 chronyc makestep 强制对齐。改完记得同步到容器和定时任务里,crontab -l 里的任务如果用了 date 取值,同样要确认时区。
