VPS安全设置：完整步骤与常见报错

一、先做一次威胁盘点：你的机器到底在暴露什么

安全设置的第一步不是装防火墙，而是搞清楚「什么在暴露」。 大多数人打开安全教程直接跳到第一步改 SSH，结果改完发现服务没法访问了，或者发现自己的 22 端口本来就没暴露给公网，做了一堆无用功。

先看监听端口。 这一条命令的输出就是你的暴露面清单：

sudo ss -tulnp

输出里每一行代表一个正在监听的端口。看两列：Local Address:Port 里 IP 是 0.0.0.0 还是 127.0.0.1，决定了这个端口能不能从公网访问到。

必须理解的第一条规则：0.0.0.0 表示监听所有网卡，公网可达；127.0.0.1 表示只监听本机回环，公网完全访问不到。 很多安全教程会告诉你「关闭监听端口」，但更准确的做法是：不需要对外的服务，应该改成监听 127.0.0.1 而不是关闭它。 关闭了会连本地调用都失败，改成回环则本机照常工作、外部访问不到。

常见报错与含义：

sudo: ss: command not found —— 精简版系统没装 iproute2。Debian 系执行 sudo apt install -y iproute2，RHEL 系执行 sudo yum install -y iproute。

ss: cannot open '/proc/net/tcp': No such file or directory —— 容器环境里没挂载 proc 网络视图，改用 netstat -tulnp 或 lsof -i -P -n。

第二件要确认的事是：系统有没有在跑不必要的服务。 很多镜像预装了一堆你根本用不上的东西：

systemctl list-units --type=service --state=running

输出里如果有 avahi-daemon、cups、snapd、cockpit 这类你用不上的服务，直接停掉。 命令是 sudo systemctl disable --now 服务名。不是「可能有用」，而是「你不知道它有什么用」的服务就应该关掉——因为你无法评估一个你不了解的攻击面。

第三件要确认的是有没有异常账户和定时任务。这是排查入侵痕迹的标准动作：

sudo last -a | head -20
sudo cat /etc/passwd | awk -F: '$3 >= 1000 && $3 < 65534'
sudo crontab -l
sudo ls -la /etc/cron.d/ /var/spool/cron/crontabs/

/etc/passwd 里 UID 在 1000 到 65534 之间的普通账户，每一个你都应该能说出它是干什么的。 说不出名字的账户要查来源。恶意程序藏身的最高频位置就是 crontab 和 /etc/cron.d，因为这里的东西开机自启、权限看起来正常、但内容往往是下载执行脚本。

查看 iwebfusion 当前月价与库存

盘点做完你会得到一张表，列出「端口 / 是否公网可达 / 是否需要 / 处置动作」。 这张表是后面所有步骤的依据。

二、账号体系：把日常操作从 root 挪开

这一步的价值不是「安全」，是「出错时你能自救」。 用 root 跑所有事，一旦一条命令写错，机器当场失去控制，而且没有任何回退余地。

创建一个日常使用的普通用户，并给它 sudo 权限：

sudo adduser deploy
sudo usermod -aG sudo deploy

注意 usermod -aG 里的 -a 不能省。 漏掉 -a 会把用户从所有其他组里移除，这是新手高频踩的坑——执行之后 sudo 会立刻报「deploy is not in the sudo group」，而你已经把自己踢出去了。

验证办法：

sudo -u deploy id

输出里应该能看到 groups=...sudo...。 如果没有，就重新执行带 -a 的那条命令。

给普通用户配置 SSH 密钥，这是比禁用密码登录更根本的一步。 在你自己的电脑上生成密钥对：

ssh-keygen -t ed25519 -C "[email protected]"

然后把公钥推到服务器上：

ssh-copy-id deploy@your-server-ip

如果服务器上已经有你的旧密钥，直接追加也是安全的：

cat ~/.ssh/id_ed25519.pub >> ~/.ssh/authorized_keys

权限必须对，否则 SSH 会拒绝使用这个密钥：

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

权限不对时的报错原文是：Bad permissions: try 'chmod 700 ~/.ssh' or 'chmod 600 ~/.ssh/authorized_keys'. 这条报错会直接告诉你该改什么，按它说的做即可。

关于 root 账号要不要禁用，有个需要说清的取舍。 禁用 root 直接登录（PermitRootLogin no）能挡掉一批自动化扫描，但会切断「出事了还能用 root 抢救」的退路。如果你已经配置好普通用户的密钥登录，并且验证过新会话能正常 sudo，那么禁用 root 是安全的；如果你还没验证过，就先保留 root 密码登录，等密钥登录确认可用后再关。

查 racknerd 在售套餐与库存

云主机还有一个特殊情况：很多云平台的 VNC 或控制台救援模式可以直接绕过 SSH 登录系统。 这种情况下即使你把所有 SSH 配置改到极致，攻击者拿到控制台权限一样能进来——所以云主机的安全底线是「云账号本身要开双因素认证」，而不是「SSH 配置要完美」。

三、关端口：防火墙规则要按最小权限写

这一节是安全设置里最具体、最可执行的部分。规则本身很简单，难的是判断哪些端口该开。

先装防火墙并设好默认策略：

# Debian / Ubuntu 系
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

RHEL 系：

sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload
sudo firewall-cmd --list-all

三个默认策略要理解清楚：deny incoming 意味着没显式放行的入站连接一律拒绝；allow outgoing 意味着出站不受限制。 出站放行是必要的，因为系统要访问软件源、DNS 服务器、你的业务上游 API。

「只留业务真正需要的那几个」这句话需要落实成具体判断。 对一个普通网站，规则表就是三条：22、80、443。如果你不跑游戏服、不做代理、不开数据库对外服务，那就只有这三条。

关于数据库：MySQL 和 PostgreSQL 绝对不要监听 0.0.0.0。 如果你需要从另一台机器连数据库，正确的做法是绑定内网 IP 或用 SSH 隧道，不要直接把 3306 暴露到公网。改绑定地址：

# MySQL
sudo sed -i 's/^bind-address.*/bind-address = 127.0.0.1/' /etc/mysql/mysql.conf.d/mysqld.cnf
sudo systemctl restart mysql

# PostgreSQL
sudo sed -i "s/^#\?listen_addresses.*/listen_addresses = '127.0.0.1'/" /etc/postgresql/14/main/postgresql.conf
sudo systemctl restart postgresql

改完一定要验证，因为改错不会有任何提示：

sudo ss -tulnp | grep -E '3306|5432'

如果输出里还有 0.0.0.0:3306，说明没改成功。 这是唯一可靠的验证方式。

常见报错：

ERROR: Invalid syntax 在 ufw 执行后出现 —— 规则语法写错了。端口和协议要用 sudo ufw allow 22/tcp，而不是 sudo ufw allow 22 tcp（少一个斜杠会被理解成两个参数）。

FirewallD is not running（RHEL 系） —— 先 sudo systemctl start firewalld && sudo systemctl enable firewalld。

Command failed with error code 100 —— 通常是 IPv6 相关规则的解析问题，加 IPV6=yes 到 /etc/default/ufw 后重试。

关于云平台的防火墙，还有一层要配。 大多数云主机有安全组（Security Group），它作用在虚拟化层，比系统防火墙更早生效。两层的正确顺序是：安全组先放行你要的端口，系统防火墙再收一遍。 如果你在系统里配好了却访问不了，先看安全组——这是最常见的「明明配对了但就是不通」原因。

查 cloudcone 在售套餐与库存

最后一个关键点：改防火墙规则时，一定要保留一条当前 SSH 会话不要关，另开一个新窗口测试。 新窗口能连上再关旧窗口。这是唯一安全的操作顺序，否则一条写错的规则会让你永远失去这台机器。

四、SSH 加固：三个参数挡住大部分自动化攻击

这一节是投入产出比最高的。全球被扫描最多的端口就是 22，配置正确的 SSH 能让绝大多数自动化攻击直接失败。

修改配置文件：

sudo nano /etc/ssh/sshd_config

三个最关键的参数：

PermitRootLogin no —— 禁止 root 直接登录。

PasswordAuthentication no —— 关闭密码认证，只允许密钥。

PubkeyAuthentication yes —— 显式开启公钥认证（默认就是开的，写出来更明确）。

另外两个值得加的限制：

MaxAuthTries 3 —— 单次连接的认证尝试次数上限，默认是 6。改成 3 能让暴力破解的每台机器尝试次数减半。

AllowUsers deploy —— 只允许指定用户登录，其他账号即使有密钥也不许登。这条在多用户机器上非常有用。

改完必须验证语法再重载：

sudo sshd -t && sudo systemctl reload ssh

sudo sshd -t 这一步绝对不能省。 语法错误时直接 systemctl restart ssh，服务起不来，你就彻底失去这台机器了——因为密码登录已经被你关掉了。先 -t 检查，通过了再 reload，出错时现有连接不受影响。

sudo sshd -t 报错的常见原文与处理：

/etc/ssh/sshd_config line 12: Bad configuration option: PermintRootLogin —— 拼写错误，Permint 应为 Permit。改完再 -t 一次。

Missing privilege separation directory: /run/sshd —— sudo mkdir -p /run/sshd && sudo chmod 755 /run/sshd。

配置生效的验证方法：

sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication|maxauthtries'

sshd -T 会输出最终生效的完整配置，而不是文件里的文本。 这能帮你发现「配置文件写了但被 Include 的其他文件覆盖了」的情况——这是 SSH 配置最隐蔽的一类坑。

再配一个防爆破工具 fail2ban，它能自动封禁反复尝试的 IP：

sudo apt install -y fail2ban
sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

查看当前被封的 IP：

sudo fail2ban-client status sshd

fail2ban 默认的封禁时长是 10 分钟。如果你的机器正被大规模扫描，可以在配置里调长：

sudo nano /etc/fail2ban/jail.local
# [sshd] 段里设置
bantime = 1h
findtime = 10m
maxretry = 3

改完重启生效：

sudo systemctl restart fail2ban

digitalocean 官网机型与实时报价

注意 fail2ban 只对「密码爆破」有效，对「公钥爆破」效果有限——因为公钥爆破需要极大量尝试，多数扫描器会直接放弃。

五、自动更新：把补丁从人工任务变成系统任务

服务器被入侵的排名第一位的原因不是漏洞多，而是补丁装不上。 很多人知道要更新，但每次更新都要 SSH 上去跑一遍命令，一忙就忘了。

Debian / Ubuntu 系用 unattended-upgrades：

sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

RHEL 系用 dnf-automatic：

sudo dnf install -y dnf-automatic
sudo systemctl enable --now dnf-automatic.timer

让它只自动装安全更新，而不是所有更新——这一点很重要。 全自动更新可能在半夜给你升级内核，然后某个依赖版本变了导致服务起不来，而你根本不知道发生了什么。只自动装安全补丁，是风险和便利之间比较合理的平衡点。

Debian 系配置自动安全更新的文件：

sudo nano /etc/apt/apt.conf.d/50unattended-upgrades

里面有一行控制哪些更新会自动装：

Unattended-Upgrade::Origins-Pattern {
        "origin=Debian,codename=${distro_codename},label=Debian-Security";
        "origin=Debian,codename=${distro_codename}-updates,label=Debian-Security";
};

改完后做一次 dry-run 确认它能正常工作：

sudo unattended-upgrade --dry-run -d

接下来是重启这个绕不开的问题：内核更新必须重启才生效。 查看有没有待重启的标记：

cat /run/reboot-required 2>/dev/null && echo "需要重启" || echo "不需要重启"

自动化重启要谨慎。 无人值守重启听起来省事，但你的服务如果没配自启动，重启后就是全站 502。在配自动重启前，先确认关键服务都设了自启动：

sudo systemctl list-unit-files --state=enabled | grep -E 'nginx|apache|php|mysql|docker'

确认无误后再开自动重启，并把它安排在流量最低的时段。 比如凌晨 4 点：

sudo nano /etc/apt/apt.conf.d/50unattended-upgrades
# Unattended-Upgrade::Automatic-Reboot "true";
# Unattended-Upgrade::Automatic-Reboot-Time "04:00";

查 hostwinds 在售套餐与库存

最后提醒一句：自动更新更新的是操作系统包，不更新你的 PHP、WordPress、Docker 镜像。 应用层的更新是另一套流程，需要你自己安排——这一点很多人在出事之后才发现。

六、日志与监控：出事之后能不能查得到

这一节的判断标准很简单：如果现在有人删了你的网站文件，你能查到他什么时候删的、从哪个 IP 删的吗？ 查不到，说明日志配置有问题。

先确认系统日志在正常工作：

sudo systemctl status rsyslog
sudo journalctl -n 50 --no-pager

审计登录行为。 这是发现暴力破解最直接的办法：

sudo journalctl _COMM=sshd | grep -i "failed password" | tail -20
sudo lastb -a | head -20

lastb 显示的是失败的登录记录，last 显示的是成功登录记录。 两者对照着看，异常一目了然。

统计暴力破解来源：

sudo journalctl _COMM=sshd | grep -i "failed password" | awk '{print $10}' | sort | uniq -c | sort -rn | head -10

如果某个 IP 的失败次数特别高，把它直接加进防火墙黑名单：

sudo ufw deny from 203.0.113.45

接着是访问日志。 Nginx 的访问日志默认在 /var/log/nginx/access.log，里面记录了每个请求的时间、来源 IP、状态码、响应大小。配置日志格式让分析更容易：

log_format detailed '$remote_addr - $remote_user [$time_local] '
                    '"$request" $status $body_bytes_sent '
                    '"$http_referer" "$http_user_agent"';
access_log /var/log/nginx/access.log detailed;

改完先 sudo nginx -t 再 reload。

然后是磁盘和内存的监控。 前面说过，磁盘写满是网站挂掉最常见的原因。日常检查：

df -h
free -m

要做成自动告警，把这条写进 crontab：

0 3 * * * /usr/bin/df -h / | awk 'NR==2 {gsub("%","",$5); if ($5+0 > 85) mail -s "disk alert" [email protected]}' | /usr/bin/tee -a /var/log/disk_check.log

如果你想看得更清楚，装一个轻量的监控面板。这里要说明一点：这类面板本身也是攻击面。 公网暴露的监控面板（尤其没改默认密码的）是被入侵的高频入口。如果装，至少要做三件事：改掉默认密码、用强密码或双因素、只允许特定 IP 访问。

关于日志保留期，也要算进成本。 日志留得越久，能追溯的时间越长，但磁盘占用也越大。在日志轮转里设定保留天数：

sudo nano /etc/logrotate.d/rsyslog
# 在末尾加入
/var/log/*.log {
    daily
    rotate 14
    compress
    delaycompress
    missingok
    notifempty
    sharedscripts
}

查看 interserver 当前月价与库存

rotate 14 表示保留 14 天的历史。 这个数字要配合你的磁盘容量选——日志写得凶的机器，保留 7 天可能更实际。

七、备份：不备份等于把命交在硬盘上

这一节的核心观点是：备份的目的不是「防硬盘坏」，而是「能在出事之后恢复到可用状态」。 这两个目标对备份的要求完全不同。

先说三种备份方式，别搞混：

第一种，文件级备份（rsync）。 适合备份配置文件和上传的文件。缺点是恢复慢——几万个文件逐个传回来要很久。

rsync -avz --delete /var/www/your-domain/ backup@backup-server:/backup/your-domain/

--delete 参数要慎用，它会删除目标端多出来的文件。如果目标目录路径写错，可能删掉不该删的东西。用之前先用 --dry-run 跑一遍看它要做什么。

第二种，逻辑备份（mysqldump）。 数据库必须用这个，不能直接复制数据目录。

mysqldump -u yourapp -p --single-transaction yourdb | gzip > /backup/yourdb-$(date +%F).sql.gz

--single-transaction 参数在 InnoDB 表上很重要，它能在不锁表的情况下拿到一致快照。不加这个参数，大表备份时会把业务卡住。

第三种，快照或镜像（云平台快照）。 适合整机级别的灾难恢复，但快照是增量的，恢复粒度粗，且恢复通常需要几分钟到几十分钟，不适合高频恢复。

现在是最容易被忽略的一步：验证备份真的能用。 备份文件存在不等于备份有效。一个空的、损坏的、或者格式不对的备份文件，在你真正需要它的时候才会暴露问题。

验证数据库备份：

gzip -t /backup/yourdb-$(date +%F).sql.gz && echo "压缩包完整"
zcat /backup/yourdb-$(date +%F).sql.gz | head -20

验证文件备份（关键是要看文件数量对不对）：

rsync -avzn --delete /var/www/your-domain/ backup@backup-server:/backup/your-domain/ | wc -l

-n 是 dry-run，输出会是实际会传输的内容。 如果这个数字接近 0，说明两边一致；如果数字很大，说明有大量差异，需要查原因。

最后是最关键的一句：备份要存在机器之外。 备份在同一个硬盘上，等于没备份。最起码的做法是传到另一台服务器或对象存储；更好的做法是遵循 3-2-1 原则——3 份副本、2 种介质、1 份异地。

再补一句关于加密的考量：备份里通常含有数据库密码、API 密钥、用户上传的隐私数据。 传到外部存储时应该加密：

gzip -c /backup/yourdb-$(date +%F).sql | openssl enc -aes-256-cbc -pbkdf2 -salt -out /backup/yourdb-$(date +%F).sql.gz.enc

查看 itldc 当前月价与库存

注意这个加密命令和上面 gzip 备份的命令是两条独立的路径，不要混着跑。 实际使用时选一种即可，加密的那条更完整。

八、应用层加固：代码级的三个高危配置

系统层做完了不代表安全结束。 下面三个配置漏洞是实际攻击中最常用的入口，每一个都有明确的报错和修法。

第一个：目录列表未关闭。 访问一个没有索引文件的目录，Nginx 会列出所有文件。

server {
    # 禁止自动目录列表
    autoindex off;
}

检测方法： 用浏览器访问一个没有 index 文件的目录，看是否显示文件列表。

第二个：敏感文件可被直接下载。 .git 目录、.env 文件、wp-config.php 这些一旦能被直接下载，源码和凭据就全泄露了。

location ~ /\. {
    deny all;
}

location ~* /(wp-config\.php|\.env|composer\.(json|lock)) {
    deny all;
}

验证方法：

curl -I https://your-domain.com/.git/config
curl -I https://your-domain.com/.env

期望结果是 403 或 404。如果返回 200，说明你的配置没生效，要立刻修。

第三个，也是危害最大的一个：上传目录可以执行脚本。 如果你的站点有用户上传功能（论坛、图床、电商），上传目录必须禁止执行任何脚本。

location ~* ^/uploads/.*\.(php|phtml|php3|php4|php5|php7|phar|pht)$ {
    deny all;
}

验证方法（最直接的一条）：

# 在 uploads 目录放一个测试文件
echo '<?php phpinfo(); ?>' > /var/www/your-domain/uploads/test.php
curl -I https://your-domain.com/uploads/test.php

期望 403。返回 200 就是高危漏洞——这个漏洞的真实后果是，任何能上传文件的用户都能在服务器上执行任意代码。

别忘了测试完删掉这个文件。 本 CMS 没有删除接口的教训同样适用于服务器：测试文件留在生产环境里，本身就是一个漏洞。

还有两个容易忽略的应用层设置。 第一是数据库账号权限最小化，上一节说过，应用账号只给 SELECT、INSERT、UPDATE、DELETE。第二是关闭 PHP 的错误显示。 开发时开 display_errors = On 很方便，生产环境必须关掉：

; php.ini 生产配置
display_errors = Off
log_errors = On
error_log = /var/log/php_errors.log

查 spinservers 在售套餐与库存

display_errors = On 泄漏的信息包括文件绝对路径、PHP 版本、甚至数据库连接错误里的用户名和主机名。 这些信息对攻击者来说是现成的地图。

九、常见误区：这些做法看着安全其实更危险

这一节讲的是那些「教程里都在说、但实际用起来有风险」的做法。

误区一：把密码改成「复杂但好猜」的组合。 P@ssw0rd2024! 这种密码在字典攻击里几秒就被破解，因为规则本身就是可预测的。真正有效的是长密码加密码管理器。 一个 20 位的随机密码，比一个 8 位带四个特殊字符的密码更难破解几个数量级。

误区二：盲目关闭所有端口。 前面说过，更安全的做法是把不需要的服务改成监听 127.0.0.1 而不是关闭它。直接关闭的后果是本机调用失败，排查起来很浪费时间。

误区三：安装一堆安全工具但不用。 装了 lynis、aide、clamav、fail2ban、rkhunter，然后不配置、不看报告。这比不装更糟——因为它给了你一种「我已经做过了」的安全感。判断标准很简单：装了一个工具，你能说出它每天检查什么、报告在哪看、不正常时你会做什么动作。三个问题答不上来，这个工具就是负担。

误区四：用 root 跑所有服务。 很多教程为了「简单」让你全程 root 操作。后果是任何一个应用被攻破，攻击者立刻拿到 root 权限。 正确做法是每个服务用独立用户运行，权限边界清晰。

误区五：只在机器上做安全，不考虑供应链。 你装的每一个第三方脚本、每一个 Docker 镜像、每一个 WordPress 插件都是潜在入口。只从官方源安装，定期检查更新，这是最容易被忽略的一层。

误区六：把「装了云厂商的防火墙」当成安全。 云防火墙解决的是网络层暴露面，不解决应用层漏洞、WebShell、被爆破的弱密码后台。它是一层，不是全部。

查 justg 在售套餐与库存

误区七：认为「我没被攻击过所以配置没问题」。 这句话本身不成立。扫描是持续发生的，只是还没成功。 判断配置是否正确，要看你能不能说清楚每一条规则的作用，而不是看有没有出事。

十、做完之后你的机器处于什么状态，以及成本账

这一节把前面十步的结果汇总成一张验收清单，并算清楚做这些配置的成本。

十步做完之后的完整状态检查：

# 1. 监听端口：只有该开的开着
sudo ss -tulnp

# 2. 防火墙规则：默认拒绝入站
sudo ufw status verbose

# 3. SSH 最终配置
sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication|maxauthtries|allowusers'

# 4. 自动更新已启用
systemctl is-enabled unattended-upgrades

# 5. 关键服务已设自启动
sudo systemctl list-unit-files --state=enabled | grep -E 'nginx|php|mysql'

# 6. 防爆破已生效
sudo fail2ban-client status sshd

# 7. 磁盘空间
df -h

# 8. 备份文件存在且完整
ls -lh /backup/ && gzip -t /backup/*.sql.gz 2>/dev/null && echo "备份完整"

八项全过，这台机器才算加固完成。

现在算成本。安全配置本身不花钱，但它的取舍往往和机型选择绑定，这一点很少有人讲清楚。

事实一：安全配置与机器性能无关。 加固主要发生在系统层和配置层，2 GB 内存和 16 GB 内存跑同样的 Nginx + PHP + MySQL，端口规则和 SSH 配置完全一样。所以「安全」不是升级配置的理由，这是常见误解。

事实二：但备份、监控、审计这些操作的资源开销和配置有关。 商品库里的参数可以算出这个差别：LAX-STARTER 是 2 vCPU、2 GB 内存、40 GB NVMe SSD、2000 Mbps 端口、5000 GB 月流量，折月 16.67 美元，每 GB 内存 8.33 美元、每 GB 硬盘 0.417 美元；LAX-MEDIUM 是 8 vCPU、8 GB 内存、160 GB NVMe SSD、10000 Mbps 端口、20000 GB 月流量，折月 66.67 美元，每 GB 内存 8.33 美元、每 GB 硬盘 0.417 美元。

把这两档放在一起看，结论很清楚：每 GB 内存的单价完全相同（都是 8.33 美元），每 GB 硬盘的单价也完全相同（都是 0.417 美元）。 也就是说，在 sixtynet 这条产品线上，升配不会降低单位成本，只会等比例增加总成本。 这和其他产品线的规律不同。

事实三：流量额度影响监控方案的可行性。 LAX-STARTER 的 5000 GB 月流量，配上 fail2ban、sysstat、auditd 这些工具产生的日志流量，在中小流量站点上完全够用；但如果你要在日志里长期保存全量访问日志并定期做统计，20000 GB 额度的 LAX-MEDIUM 会让你在带宽上更从容。

事实四：硬盘容量直接决定备份方案。 40 GB 的盘（LAX-STARTER），本地备份一份完整数据后几乎没有余量做快照，所以用这台机器时必须把备份传到外部存储；160 GB 的盘（LAX-MEDIUM）可以保留多份本地快照。

事实五：机房标识决定维护窗口的时区负担。 商品库字段里能读到的机房标识有三类：RosCloud 全部 6 个机型的 tags 标注为「俄罗斯」；云途 9 个机型的名称前缀是 HK（香港）与 DS（域名与服务器），其产品页地址也在 hk-ds 与 hk-es 这类香港目录下；sixtynet 的 13 个机型按名称分为 LAX（洛杉矶）、Residential、IRVINE-PRO 三条线。机房在香港的机器，配置和重启通常更方便，因为不需要考虑跨时区的维护窗口。

事实六：IP 类型影响安全策略的选择。 sixtynet 的 Residential 系列与 LAX 系列配置几乎相同，但 Residential-STARTER 是折月 21.67 美元、每 GB 内存 10.83 美元，LAX-STARTER 是折月 16.67 美元、8.33 美元；MICRO 档同样是 Residential 38.33 美元对 LAX 33.33 美元。同等配置下 Residential 每月多付 5 美元。 这多出来的成本买到的是住宅属性 IP——这类 IP 在风控系统里被识别得更像真实用户，但也因此被滥用的比例更高，历史行为记录更杂。 如果你的业务需要做账号风控、或者对来源 IP 有分类需求，选 Residential 是有理由的；如果只是普通建站，LAX 系列的 5 美元差价就是纯浪费。

最后是你应该避免的三种做法，这三种都会带来比收益更大的问题：

第一种：把所有服务都暴露在公网只靠密码强度保护。 你无法靠一个复杂密码守住 3306、5432、6379 这些端口。服务必须默认不监听公网。

第二种：为了「方便运维」而长期开着 root 密码登录。 运维便利和安全在这里是直接冲突的。正确解法是配好密钥后关掉密码登录，而不是两个都留着。

第三种：配置完就不管了。 安全配置会随时间失效——软件升级改了默认行为、新装的软件开了新端口、半年后你以为关掉的某个服务被别的脚本重新打开。每隔一两个月把这一节的八项验收重新跑一遍，是最省事的维护方式。

最后给你一个明确的验收标准，做完这些就算合格：

验收项	合格标准（可量化）
公网可达端口	只保留业务必需的端口，总数不超过 5 个；3306、5432、6379 必须不在其中
SSH 密码登录	PasswordAuthentication no，且密钥登录已验证可用
root 直接登录	PermitRootLogin no
暴力破解防护	fail2ban 运行中，maxretry 不超过 3，bantime 不少于 1 小时
自动安全更新	已启用且 dry-run 通过，待重启标记可查
敏感文件访问	.git 与 .env 返回 403 或 404，出现任何一个 200 即不合格
上传目录执行	测试 PHP 文件返回 403，返回 200 即为高危
备份	3 份副本、2 种介质、1 份异地，恢复演练每月至少 1 次

zenlayer 官网机型与实时报价

八项全过，你的 VPS 才算真正安全。 缺任何一项，都还有一个明确的、被利用过的真实攻击路径对应着。

再给一组数字阈值，上面那张表判断「做了没有」，这组阈值判断「做得够不够硬」：

指标	达标线	不达标时改哪里
SSH 密钥强度	RSA 不少于 3072 位，或使用 ed25519	重新生成密钥对并替换 authorized_keys
爆破封禁灵敏度	同一 IP 24 小时内失败 5 次即封禁，封禁时长不少于 1 小时	收紧 jail.local 里的 maxretry 与 bantime
公网监听端口数	不超过 5 个	逐个改绑 127.0.0.1 或停用对应服务
日志保留期	不少于 14 天	修改 logrotate 配置里的 rotate 参数
磁盘占用告警线	使用率超过 85% 触发告警	调低 crontab 里的阈值并接上通知通道
内存占用	上线后 24 小时谷值低于 15%	升档或做进程级排查
备份恢复演练	每月至少 1 次，且压缩包完整性校验通过	补做一次演练并把结果记下来
TLS 版本	只允许 TLS 1.2 及以上	修改 Nginx 配置里的 ssl_protocols

这组阈值里最容易被跳过的是最后两项。 很多人把八项验收跑完就认为安全了，但备份从没恢复演练过、TLS 还开着 1.0 和 1.1——前者会在你真出事那天才暴露，后者是能被公开扫描工具直接识别的漏洞。

十一、什么情况下不该选高配，以及该换什么

这一节按公开字段说明不适用的场景，并给出替代方案。这里讨论的是机房位置、线路类型、计费方式、IP 资源这些客观条件，不是对任何商家的评价。

场景一：你只跑一个静态站或测试环境。这时不该选 8 核 8 GB 档位。 理由来自商品库的单价：LAX-STARTER 是折月 16.67 美元、每 GB 内存 8.33 美元、每 GB 硬盘 0.417 美元；LAX-MEDIUM 是折月 66.67 美元、每 GB 内存 8.33 美元、每 GB 硬盘 0.417 美元。两条线的单位成本完全相同，也就是说在 sixtynet 这条产品线上，升配只会等比例放大总账单，不会让单位成本下降。

替代方案：选 LAX-STARTER（年付 200 美元、折月 16.67 美元）。 2 vCPU、2 GB 内存、40 GB NVMe SSD、2000 Mbps 端口、5000 GB 月流量，跑静态站和小流量测试绰绰有余。但这台机器只有 40 GB 硬盘，备份必须传到外部存储，不能指望本地再留一份快照。

场景二：你的业务吃流量不吃内存。这时不该按内存单价挑机器。 RosCloud-06 每 TB 流量 11.665 美元，LAX-STARTER 是 3.413 美元，差三倍以上；如果月流量超过 10 TB，这个差距会放大成每月 82 美元以上的差额。

替代方案：按流量单价选 LAX-MEDIUM（折月 66.67 美元，每 TB 流量 3.413 美元）。 它的月流量额度是 20000 GB，端口 10000 Mbps，流量单价与 LAX-STARTER 完全相同，额度是四倍。

场景三：你要跑数据库或缓存，同时需要大内存。这时不该选 SAS 机械盘机型。 云途 HK.DS.S 的 disk_type 字段明确标注为 SAS HDD，内存 128 GB、折月 800 美元，但磁盘写入与读取的平均速度低于 100 MB/s 就应视为不达标，机械盘与 SSD 的差距不是「慢一点」，而是数量级。

替代方案：选云途 DS.ES.D（128 GB 内存、800 GB SSD、折月 900 美元、库存 1 台）或云途 HK.DS.P（64 GB 内存、1024 GB SSD、折月 750 美元、库存 5 台）。 两者都是 SSD，内存单价分别是 7.03 美元和 11.72 美元每 GB。

场景四：你想月付、不愿一次性承诺一年。这时不该选 sixtynet 全系。 商品库的 billing_period 字段显示得很明确：sixtynet 的 13 个机型全部是 year，RosCloud 与云途的机型全部是 month。 也就是说这条产品线上不存在月付选项。

替代方案：需要同等配置又按月付，就看 RosCloud 与云途两条线。 但要注意换线意味着换机房：RosCloud 全部机型的 tags 标注为「俄罗斯」，云途的机型名称前缀是 HK 与 DS。

场景五：你的业务流量波动很大、必须提前算清超额成本。这时不该选没写超额条款的机型。 商品库的 traffic_reset_price 字段显示：云途 9 个机型全部填了这个值（HK.DS.M 和 DS.ES.F 是 200 美元，DS.ES.B 是 450 美元，其余六款是 500 美元），而 RosCloud 与 sixtynet 的所有条目这一字段都是空的。没有写明的条款，不代表免费，也不代表限速，付款前必须在商家页面问清楚。

替代方案：流量可预测的业务选云途，把超额条款当保险；流量完全不可预测的业务，选额度与峰值匹配的固定档位，比如 LAX-MEDIUM 的 20000 GB 或 LAX-LARGE 的 40000 GB。

场景六：你需要明确知道能拿到几个 IPv4。这时不该选条目里没填这个字段的机型。 商品库的 ipv4_count 字段里，只有 RosCloud 的 6 个机型填了值，全部是 1，其余 22 个条目都是空的。

isif 官网机型与实时报价

替代方案：需要明确 IPv4 数量，直接看 RosCloud 系列，或者在商家页面确认后下单，别默认「买一台就带一个」。

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

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

• 只想搭个站、预算优先：先看价格最低那档够不够用，别为用不上的配置付钱。看 iwebfusion 当前机型与价格
• 做跨境或店群、需要多 IP：优先看 IP 类型与换 IP 政策，别只看配置。看 racknerd 当前机型与价格
• 跑游戏服或实时业务：看上行抖动与防御能力，普通套餐往往不达标。看 cloudcone 当前机型与价格
• 只是开发测试、临时用：按小时或月付，用完就删，别买年付。看 digitalocean 当前机型与价格

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

十二、常见问题与选型结论：四类人分别买哪一档

先把安全配置的成本和选型结论放在一起说，因为它俩是同一笔账。

第一类：个人博客、小站、练手用，月预算 20 美元以内。 选 LAX-STARTER（年付 200 美元、折月 16.67 美元）。2 vCPU、2 GB 内存、40 GB NVMe SSD、2000 Mbps 端口、5000 GB 月流量，每 GB 内存 8.33 美元。这是折月价最低的一档，也是这十二节安全配置完全跑得动的规格——但你必须把备份传到外部存储，因为 40 GB 盘本地留不下第二份。安全配置按第三节到第九节做完，验收跑第十节那八项。

第二类：企业官网、小型电商，需要长期稳定运行且流量较大。 选 LAX-MEDIUM（年付 800 美元、折月 66.67 美元）。8 vCPU、8 GB 内存、160 GB NVMe SSD、10000 Mbps 端口、20000 GB 月流量，每 TB 流量仍是 3.413 美元，和最低档持平。从 LAX-STARTER 换到这一档，价格涨了 50 美元，换来的是流量额度四倍、端口五倍，硬盘四倍——多出来的硬盘余量让你能留本地快照。 年付前先按月付跑一个周期。

第三类：主要访客在国内，或需要大内存跑数据库缓存。 机房在香港的选 云途 HK.DS.P（折月 750 美元、64 GB 内存、1024 GB SSD、2000 Mbps 端口、40000 GB 月流量、库存 5 台），需要大内存的选 云途 DS.ES.D（折月 900 美元、128 GB 内存、800 GB SSD、库存 1 台）。这两款都写明了 500 美元的超额重置价，流量超了能提前算钱，这是 RosCloud 和 sixtynet 两条线在商品库里没有的信息。下单前先确认库存，HK.DS.P 只有 5 台，DS.ES.D 只有 1 台。

第四类：需要住宅属性 IP 做账号风控或来源分类。 选 sixtynet 的 Residential 系列，Residential-STARTER 是折月 21.67 美元、Residential-MICRO 是折月 38.33 美元，比同配置的 LAX 系列每月多付 5 美元。这笔差价买的是住宅属性 IP——这类 IP 在风控系统里被识别得更像真实用户，但也因此被滥用的比例更高，历史行为记录更杂，所以要按业务的风控需求来定，而不是跟风买。

最后补三句常见问题的直接答案：

问：加固完是不是就安全了？ 不是，加固把已知路径堵住，扫描和新的漏洞一直在发生。判断配置是否正确，要看你能不能说清楚每一条规则的作用，而不是看有没有出事。

问：配置完多久复查一次？ 每隔一两个月把第十节那八项重新跑一遍。安全配置会随时间失效——软件升级改了默认行为、新装的软件开了新端口、半年前你以为关掉的某个服务被别的脚本重新打开。

问：先买便宜的还是先买安全的？ 安全配置本身不花钱，升级配置也不是为了安全——加固发生在系统层和配置层，2 GB 内存和 16 GB 内存跑同样的服务，端口规则和 SSH 配置完全一样。该升配的理由是业务负载和安全是两笔账，别混着算。