一、香港 VPS 刚买来，第一分钟该做什么
很多人在这一步做错，代价在半年后才显现。 买到机器后的第一个小时，正确顺序是：改密码 → 换 SSH 端口 → 装密钥 → 关密码登录 → 关 root 直登 → 装防火墙 → 装 fail2ban → 关无用端口 → 配置自动安全更新 → 做一次快照。
为什么是这个顺序，而不是随便挑几项做？ 因为加固的核心原则是「永远留一条能进来的路」。 如果你在关掉密码登录之前就把密钥配错了，你会把自己锁在门外——只能通过商家控制台的 VNC 或救援模式进去。 所以每一步都是「先开新路、再关旧路」，不是一步到位。
这一节先把概念讲清楚，后面九节是逐项展开。
先说清楚威胁模型。 一台公网 VPS 面对的自动化攻击只有三类： 第一类是无差别扫描——SSH 暴力破解、数据库弱口令、Web 管理面板爆破，这是量最大的一类；第二类是已知漏洞的自动化利用——扫到有漏洞版本的服务就直接打；第三类是针对性攻击——你的 IP 被人工盯上，通常发生在你挂了什么有价值的站或被人知道了地址。
这三类里，第一类占日常噪音的九成以上，而且是可以用很低的成本挡掉的。 本文的做法是：第一类用端口、密钥、限速挡住；第二类用及时更新挡住；第三类用最小暴露面、监控告警和备份兜底。
另外要说清楚一件事：加固不能替代备份。 加固降低的是「被攻破的概率」，备份决定的是「被攻破之后损失多大」。 第七节的备份和第九节的恢复演练，是整套方案里唯一能救命的环节，但也是最常被跳过的。
最后提醒一个前提：IP 资源是公开事实，也是攻击面的第一层。 商品库里香港方向的独立服务器型机型普遍提供 IPv4，云途各机型的 IP 说明标注为「IPv4（原页未注明具体数量）」，RosCloud 全系带 1 个 IPv4。 也就是说你的机器在公网上是直接暴露的，没有前置 NAT 挡着——这与很多家庭宽带不同，也意味着加固必须自己做，不能指望上游。
最后补一个成本视角的提醒，这一节很多文章会跳过，但读者做预算时需要。 加固本身几乎不花钱：换端口、装密钥、配防火墙、装 fail2ban 都是命令行操作，成本是零；自动更新也是零；唯一有成本的是「备份到异地对象存储」和「买第二台机器做冷备」。 所以一个合理的预算是：机器月费的 3% 到 5% 拿来做备份存储，这是最划算的一笔安全支出——因为它的作用是把「被勒索后付赎金」这个可能高达数月月费的场景，变成一次可控的恢复。**
另外要算清楚时间成本，这是更真实的一笔账。 上面九个环节完整做一遍，新手大约需要 2 到 3 小时；有经验的人 40 分钟到 1 小时。 这 2 到 3 小时是一次性的，但「每月检查一次补丁状态、每季度演练一次恢复」是持续投入，每次大约 30 分钟。 把这两项时间写进你的运维清单，比事后花一整天处理入侵划算得多。
二、SSH 怎么加固：端口、密钥、禁 root
SSH 是暴露面最大的一扇门，也是加固收益最高的一扇门。 这一节四个动作按第二节开头说的顺序做：换端口、装密钥、关密码、禁 root。
动作一：换 SSH 端口。 这不是让攻击者找不到，而是把全网扫描的噪音降一个数量级——绝大多数脚本只扫 22。
# 备份配置再改，改错还能救回来
cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
sed -i 's/^#\?Port .*/Port 20222/' /etc/ssh/sshd_config
# 检查语法，没报错再重载
sshd -t && systemctl reload sshd
# 另开一个终端验证新端口能连上，再关掉当前这个会话必须注意的三点： 第一，sshd -t 一定要先跑，语法错误会导致 SSH 完全起不来。 第二，reload 之后不要关掉当前会话，用另一个终端确认新端口连得上再关。 第三，改端口后云服务商的安全组也要放行新端口——安全组没放行的话，你在控制台重装系统都救不回来。
动作二：安装 SSH 密钥。
# 本地生成密钥（用 ed25519，密钥短、速度快）
ssh-keygen -t ed25519 -C "hk-vps-01"
# 把公钥推上去
ssh-copy-id -p 20222 -i ~/.ssh/id_ed25519.pub root@你的服务器IP如果 ssh-copy-id 不可用，手动追加也一样：
mkdir -p ~/.ssh && chmod 700 ~/.ssh
cat ~/.ssh/id_ed25519.pub >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys动作三：关闭密码登录。这一步是不可逆的，必须在动作二确认成功之后做。
sed -i 's/^#\?PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
sed -i 's/^#\?PermitRootLogin.*/PermitRootLogin no/' /etc/ssh/sshd_config
sed -i 's/^#\?PubkeyAuthentication.*/PubkeyAuthentication yes/' /etc/ssh/sshd_config
# 可选：禁用空密码、限制认证尝试次数
sed -i 's/^#\?PermitEmptyPasswords.*/PermitEmptyPasswords no/' /etc/ssh/sshd_config
sed -i 's/^#\?MaxAuthTries.*/MaxAuthTries 3/' /etc/ssh/sshd_config
sshd -t && systemctl reload sshd禁 root 直登之前，先建一个普通账号并给它 sudo 权限，否则你会失去 root 的入口：
adduser deploy
usermod -aG sudo deploy
mkdir -p /home/deploy/.ssh
cp ~/.ssh/authorized_keys /home/deploy/.ssh/
chown -R deploy:deploy /home/deploy/.ssh
chmod 700 /home/deploy/.ssh && chmod 600 /home/ deploy/.ssh/authorized_keys动作四：给普通账号配 sudo 的免密，且只允许密钥。 这一步是给自动化部署留的通道——如果你用 Ansible、Fabric 或者自研的部署脚本，免密 sudo 能省掉大量人工介入；但免密 sudo 意味着私钥泄露即等于 root 泄露，所以私钥必须离线备份、不能放在共享机器上。
这一节做完之后，你的 SSH 暴露面从「全网可扫 + 可爆破」变成了「非标准端口 + 密钥认证 + 限速尝试」。 对自动化扫描来说，这条路基本就断了。
三、防火墙怎么配：ufw 与 firewalld 两套
防火墙的价值不是「阻止攻击」，是「让机器上除了你需要的，没有别的对外开口」。 默认拒绝入站、按需放行，是唯一正确的策略。
Debian / Ubuntu 系用 ufw：
# 1. 默认拒绝入站，允许出站
ufw default deny incoming
ufw default allow outgoing
# 2. 先放行 SSH（注意端口要和 sshd_config 里的一致），再启用
ufw allow 20222/tcp comment 'SSH'
ufw allow 80/tcp comment 'HTTP'
ufw allow 443/tcp comment 'HTTPS'
# 3. 确认规则无误后再启用
ufw enable
ufw status verboseRHEL / CentOS / Rocky 系用 firewalld：
# 放行并重载
firewall-cmd --permanent --add-port=20222/tcp
firewall-cmd --permanent --add-service=http
firewall-cmd --permanent --add-service=https
firewall-cmd --reload
firewall-cmd --list-all两个系统最容易踩的坑，单独讲。
坑一：启用防火墙时把自己的 SSH 端口挡在外面。 上面的命令里「先放行 SSH 再启用」这个顺序不能颠倒。 如果已经关在门外，可以通过商家控制台的 VNC / 救援模式进去，执行 ufw disable 解救，然后重来一遍。
坑二：只配了系统防火墙，忘了云服务商的安全组。 这两层是独立的、都要配。 安全组放行了 22 端口，系统防火墙拒绝入站，实际效果是拒绝——表现是「明明安全组放行了还是连不上」。 排查顺序永远是：先看安全组，再看系统防火墙，最后看服务本身有没有监听。**
再补一条实用规则：只对管理端口限制来源 IP。
# ufw：只允许你的固定办公 IP 访问 SSH
ufw allow from 你的固定IP to any port 20222 proto tcp
# 删除掉原来那条全网放行
ufw delete allow 20222/tcp如果你的办公 IP 是动态的（家庭宽带），这条规则会让 SSH 彻底连不上；这种情况的正确做法是保留全网放行 SSH 但只允许密钥认证，再靠 fail2ban 限速——下一节讲的。
最后是验证：装完防火墙一定要做一次外部扫描确认。
# 从另一台机器扫开放端口
nmap -Pn 你的服务器IP
# 期望结果：只看到你放行的 80、443、20222，以及必要的数据库端口如果扫出了你没有印象的口令，那说明某个服务在监听但你忘了它——这一条能抓出相当多的意外暴露。**
四、fail2ban 怎么配：把暴力破解挡在门外
fail2ban 的机制很简单：读日志，数失败次数，超阈值就封禁来源 IP 若干分钟。 它专门对付第一种威胁——SSH 暴力破解。
安装与基础配置：
# Debian / Ubuntu
apt update && apt install -y fail2ban
# RHEL 系
dnf install -y fail2ban关键点：jail.local 而不是直接改 jail.conf。 升级时 jail.conf 会被覆盖，而 jail.local 不会——这是官方推荐的写法。
# /etc/fail2ban/jail.local
[DEFAULT]
# 找错 5 次封 10 分钟
bantime = 600
# 同一账号在 600 秒内错 5 次
findtime = 600
maxretry = 5
# 封禁期间不重复计数
bantime.increment = true
bantime.factor = 2
bantime.maxtime = 86400
# 白名单：本地和你的办公 IP 永不解封
ignoreip = 127.0.0.1/8 ::1 你的固定IP
# 拉黑名单用的动作
banaction = ufw
banaction_allports = ufw
[sshd]
enabled = true
port = 20222
logpath = /var/log/auth.log
backend = auto
maxretry = 5
findtime = 600
bantime = 3600配置完重启并验证：
systemctl restart fail2ban
# 看正在生效的 jail
fail2ban-client status
# 看 SSH 这个 jail 的详细情况
fail2ban-client status sshd
# 看某台机器的封禁状态
fail2ban-client status sshd报错与排查，这一节是重点。
报错一：ERROR Failed to start jail. There's no directory to log logs 或 Unable to contact the server。 说明 fail2ban 服务没起来。 查 journalctl -u fail2ban -n 50，最常见的原因是 jail 名字写错——Linux 发行版里 SSH 的 jail 名通常叫 sshd，但用 systemd journal 的系统上日志路径是 /var/log/auth.log 还是 journal，取决于 backend 设置。**
报错二：日志文件根本不存在，报 No such file or directory。 Debian / Ubuntu 是 /var/log/auth.log，CentOS / Rocky 是 /var/log/secure，两者不能混。 用 find /var/log -name "*auth*" -o -name "*secure*" 找到实际路径再填。
报错三：配置写了但没有任何人被抓。 两个原因：一是你已经关了密码登录，爆破根本进不来（这是好事）；二是 logpath 没匹配到——用 fail2ban-regex /var/log/auth.log sshd 手动验证能不能解析出失败记录。**
报错四：封了 IP 但自己也被封了。 ignoreip 没配好。 这一条特别重要：如果你没有固定 IP，又配错了 ignoreip，有概率把自己关在门外。 加一行 ignoreip = 0.0.0.0/8 之类的兜底不如确保你有 VNC 救援通道。
关于 fail2ban 的一个提醒要说明白：它只防「撞门」，不防「技术型入侵」。 一个用合法密钥登录后提权的攻击，fail2ban 一点忙都帮不上。 所以它不能替代更新、不能替代最小权限、更不能替代备份。
五、系统更新与补丁策略
补丁策略是加固里最「 boring」但最有效的一环——因为第二类威胁（已知漏洞自动化利用）只对没打补丁的机器起作用。
先看清楚自己的机器上都有什么、版本是多少：
# 发行版版本与代号
cat /etc/os-release
# 内核版本
uname -r
# 已安装包与可升级包
apt list --upgradable # Debian/Ubuntu
dnf check-update # RHEL 系Debian / Ubuntu 的正确姿势是启用无人值守自动更新：
# 安装 unattended-upgrades
apt update && apt install -y unattended-upgrades
# 启用
dpkg-reconfigure -plow unattended-upgrades
# 确认配置
cat /etc/apt/apt.conf.d/20auto-upgrades# /etc/apt/apt.conf.d/50unattended-upgrades
// 常规安全更新自动装
Unattended-Upgrade::Allowed-Origins {
// 允许从这仓库升级
"${distro_id}:${distro_codename}-security";
// 基础系统更新（需要时开）
// "${distro_id}:${distro_codename}-updates";
};
// 自动重启时间（凌晨 4 点）
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "04:00";RHEL 系用 dnf-automatic：
dnf install -y dnf-automatic
systemctl enable --now dnf-automatic.timer# /etc/dnf/automatic.conf
[commands]
apply_updates = yes
[commands_timer]
random_delay = 300
# 每天 4 点检查
on_calendar = *-*-* 04:00:00三个必须想清楚的问题。
问题一：自动更新会不会打断业务？ 会，尤其是内核更新需要重启。 所以上面把自动重启时间设在凌晨 4 点，并且建议生产机的内核更新改成「安装但不自动重启」，由你择期手动重启。 这一步是自动更新和业务连续性之间的取舍，没有两全的方案——但你必须明确选一个，而不是让默认值替你选。
问题二：应该更新到什么程度？ 一个务实的做法是分三层： 安全更新全自动、内核更新自动装但手动重启、业务软件版本由你控制。 第三层尤其重要——很多事故不是系统补丁没打，而是你自己装的某个依赖库有漏洞。
问题三：怎么确认补丁真的生效了？
# 查最近装的包和更新记录
grep " upgrade " /var/log/apt/history.log | tail -20
journalctl -u dnf-automatic | tail -30
# 查某个已知需要更新软件版本
nginx -v && apt-cache policy nginx还有一条很多人忽略的：安全更新之外，端口上的服务版本本身也要关注。 Nginx、PHP、OpenSSH 的新版本常常同时带来安全修复。 判断标准是看发行版仓库里的版本号是否还在支持期内——已经 EOL（停止维护）的发行版，哪怕装了 automatic-updates 也没有安全更新可装。**
所以最后一个动作是：确认你的系统还在支持期内。 Debian 的旧版本、CentOS 7 这类已经 EOL 的系统，是攻击者的重点目标，因为它们的漏洞不再有补丁。 如果发现自己在 EOL 系统上，第一优先级不是加固，是重装到受支持的版本。
六、Web 服务与数据库的加固
SSH 加固做完，攻击者会转向 80 和 443 端口上的服务。这一节讲 Web 层和数据库层。
Nginx 的几条关键加固配置：
# 隐藏版本号
server_tokens off;
server {
listen 80;
server_name example.com;
# 上传大小限制，防止磁盘被撑爆
client_max_body_size 20m;
client_body_timeout 30s;
# 目录列表关掉
autoindex off;
# 关键路径禁止直接访问
location ~ /\.(git|svn|env) {
deny all;
return 404;
}
# 只允许必要的 HTTP 方法
if ($request_method !~ ^(GET|POST|HEAD)$) {
return 405;
}
# 安全响应头
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
location / {
try_files $uri $uri/ /index.php?$query_string;
}
}注意 server_tokens off; 要放在 http 块里（不是 server 块里）。 这是新手最常犯的配置位置错误——放在 server 块里 Nginx 会报 server_tokens directive is not allowed here，然后整个配置重载失败。
数据库的加固，重点三条：
第一条：MySQL 绝不监听公网。 默认配置里 bind-address = 127.0.0.1 就是对的。如果你的应用和数据库在同一台机器上，这是最省事也最安全的做法。 如果必须远程连，走 SSH 隧道，不要开 3306 到公网。
第二条：删除默认与匿名账号。
-- 删除匿名用户
DELETE FROM mysql.user WHERE User='';
-- 删除测试库
DROP DATABASE test;
-- 刷新权限
FLUSH PRIVILEGES;
-- 检查还剩哪些账号
SELECT user, host FROM mysql.user;第三条：应用账号用最小权限，不要用 root 跑业务。
CREATE USER 'app'@'127.0.0.1' IDENTIFIED BY '强密码';
GRANT SELECT, INSERT, UPDATE, DELETE ON yourdb.* TO 'app'@'127.0.0.1';
-- 不需要 DROP / ALTER / GRANT，就不要给
FLUSH PRIVILEGES;还有一条跨系统通用的：管理后台不要暴露在公网。 如果后台只有你自己用，最简单的加固是限制来源 IP：
location /admin/ {
allow 你的固定IP;
deny all;
proxy_pass http://后端;
}如果你的 IP 是动态的，可以考虑用 VPN 回家再访问，或者用 basic auth 加一层。 这两条都比「改个复杂密码」有效——因为改密码防的是撞库，而限制来源防的是根本不让它到达登录页。**
七、备份与快照：加固体系的最后一块
前面六节全是在降低被攻破的概率，这一节决定被攻破之后的损失。 先说一个残酷的事实：很多被勒索的机器，不是被入侵时被加密的，而是备份也在同一台机器上、一起被加密了。
备份的三条铁律。
铁律一：备份必须在机器之外。 本地 /backup 目录不算备份——攻击者拿到 root 后第一个删的就是它。 正确做法是传到异地：另一家厂商的对象存储、另一台机器、或者自己的 NAS。
铁律二：备份必须加密，而且密钥不能和备份放一起。 数据库备份是明文的话，等于把整个库发给了攻击者。 用 mysqldump 导出后用 gpg 或 openssl 加密，密钥单独管理。
铁律三：必须演练过恢复。 没验证过的备份等于没有备份。 每季度至少做一次完整恢复演练，在另一台机器上把备份拉下来还原，然后启动服务跑一遍业务。
数据库的备份命令与加密：
# 备份并压缩
mysqldump -u root -p --single-transaction --quick --routines --triggers \
yourdb | gzip > /tmp/dbdump.sql.gz
# 加密（密钥从别处取，不要留在本机）
gpg --batch --yes --passphrase-file /secure/path/passphrase \
-c /tmp/dbdump.sql.gz
# 上传到异地对象存储
aws s3 cp /tmp/dbdump.sql.gz.gpg s3://你的备份桶/db/$(date +%F)/
# 确认成功后清理本地临时文件
rm -f /tmp/dbdump.sql.gz /tmp/dbdump.sql.gz.gpg--single-transaction 这个参数很关键：它让 mysqldump 在 InnoDB 上不锁表，备份期间业务可以正常写。 不加这个参数，备份时数据表会被锁住，站点直接卡死——很多人在凌晨备份时发现网站打不开，就是这个原因。
文件目录的备份用 rsync：
rsync -avz --delete \
--exclude '.git' --exclude 'node_modules' \
/var/www/ user@备份机:/backups/www/$(date +%F)/关于云服务商快照，要说清楚它的边界。 快照和备份是互补的，不是替代关系： 快照恢复快（几分钟），但只能在原机器上恢复，而且如果攻击者已经拿到了 root 并且往系统里塞了后门，从被入侵时点的快照恢复等于把后门一起恢复回来。 所以快照的用途是「快速回滚配置错误」，不是「清理恶意代码」——清理后门靠的是重装系统和只从可信源恢复数据。
配置自动备份的定时任务：
# 编辑 crontab
crontab -e
# 每天 3:17 备份（刻意避开整点，避开和别的任务撞车）
17 3 * * * /usr/local/bin/backup-db.sh >> /var/log/backup.log 2>&1「刻意避开整点」这个细节有实际价值——很多服务器的定时任务都设在 0 点或整点，结果备份、监控、日志轮转全挤在一起，互相抢 IO，反而把磁盘打满。**
八、入侵迹象排查：怎么发现已经出事了
加固做得好也要有兜底：万一还是被进去了，得能发现。这一节给排查清单。
第一层：查账号。 被入侵最直接的痕迹是多出来的账号。
# 列出所有能登录的账号，重点看 UID 为 0 的
cat /etc/passwd | awk -F: '$3 == 0 {print}'
# 看最近新增的账号（按 passwd 文件修改时间）
ls -lt /etc/passwd /etc/shadow /etc/group
# 查空密码账号（极度危险）
awk -F: '($2==""){print $1}' /etc/shadow第二层：查登录记录。
# 最近的登录（成功和失败）
last -a | head -30
lastb | head -30
# 查某个可疑 IP 的登录历史
last -a | grep 可疑IP
# 查 auth.log 里的成功登录
grep "Accepted" /var/log/auth.log | tail -20
# 查可疑的公钥
grep "Accepted publickey" /var/log/auth.log | awk '{print $9}' | sort -u第三层：查计划任务。 这是挖矿木马和反弹 shell 最常见的藏身处。
# 系统级定时任务
crontab -l
ls -la /etc/cron.* /var/spool/cron/
# 逐个看内容
cat /etc/crontab
# systemd 定时器（很多恶意程序用这个躲过 crontab 检查）
systemctl list-timers --all
# 检查 systemd 服务里的可疑项
systemctl list-unit-files --type=service --state=enabled第四层：查进程与网络连接。
# 按 CPU 排序找挖矿进程（挖矿进程最明显的特征是常年 100% CPU）
ps aux --sort=-%cpu | head -15
# 找出不在标准目录里的进程可执行文件
ls -l /proc/*/exe 2>/dev/null | grep -v '/usr/bin\|/usr/sbin\|/bin\|/sbin'
# 当前网络连接，重点看 ESTABLISHED 到陌生地址的
ss -tunap | head -30
# 监听端口
ss -tulnp第五层：查文件改动和 Web 后门。
# 最近 7 天被修改过的 PHP 文件
find /var/www -name "*.php" -mtime -7 -exec ls -la {} \;
# 搜索 WebShell 常见特征
grep -rl "eval(\|base64_decode(\|shell_exec(\|passthru(\|assert(\|system(" /var/www --include="*.php"
# 检查 crontab 与启动目录
ls -la /etc/rc.local /etc/rc*.d/ /root/.bashrc /root/.ssh/authorized_keys第六层：查日志有没有被删过。 这是入侵者常做的动作，日志文件的时间戳会露馅。
# 日志文件最后修改时间
ls -la /var/log/auth.log /var/log/syslog /var/log/secure 2>/dev/null
# 查日志文件是否被截断（看行数是否异常少）
wc -l /var/log/auth.log
# 检查日志是否被清空过
journalctl --disk-usage第七层：查文件完整性。 一个简单有效的做法是用 tripwire 或 aide 建立基线，之后定期校验。
# Debian/Ubuntu
apt install -y aide
aideinit
# 之后定期跑校验
aide --check发现异常后的正确处理顺序，这里要说清楚，因为很多人做错： 第一步，保留证据——先做一份全盘快照或打包关键日志，不要立刻清理；第二步，切断外联——如果确认有正在进行的攻击，先断网再取证，否则攻击者还在持续写入；第三步，重装系统，不要试图「清理干净」——只要攻击者曾获得 root，就无法保证没有留下后门，重装是唯一可靠的办法；第四步，从可信来源恢复数据——数据库备份如果是在被入侵期间生成的，可能已经被污染，要核对时间戳；第五步，换密钥、换密码、查同账号下的其他机器——**如果攻击者拿到的是你的 SSH 私钥，其他用同一把密钥的机器全都要换。
最后一句提醒：如果走完这一圈发现是攻击者干的，保留证据并考虑向商家和警方报告——云服务商在某些情况下会配合处理，而放弃追查就意味着同一个漏洞还会被用第二次。**
九、常见误区与常见报错
这一节是给已经踩过坑的人查的。
误区一：以为改端口就是安全了。 端口扫描器靠握手特征识别服务，改端口挡得住脚本，挡不住有耐心的人。 真正的防线是密钥认证 + fail2ban 限速 + 白名单。
误区二：以为装了 fail2ban 就万事大吉。 fail2ban 只处理「撞门」，处理不了已经拿到合法凭据之后的入侵。
误区三：以为系统防火墙能挡住一切。 它只管端口，不管应用层漏洞——你的 CMS 有 SQL 注入，防火墙一点忙都帮不上。
误区四：以为备份就是拷一份文件。 备份在同机、同盘、同一账号下，等于没有备份。 必须异地 + 加密 + 演练恢复。
误区五：以为自动更新会解决所有安全问题。 自动更新管的是发行版仓库里的包。 你自己装的 Node.js、Python 依赖、WordPress 插件不受它管——这三样是个人站最常见的漏洞来源。
报错一：改完 sshd_config 后 SSH 连不上，报 Connection refused。 原因：新端口没被云服务商安全组放行，或者 sshd -t 有语法错误导致服务没起来。 用控制台 VNC 进去看 systemctl status sshd 和 sshd -t 的输出。
报错二：改了端口后本地能连、外面连不上。 99% 是安全组没放行新端口。 这层的排查入口在商家控制台，不在服务器里。
报错三：fail2ban 日志里报 ERROR Failed to start jail. There's no directory to log。 日志路径不对，Debian 系是 /var/log/auth.log，RHEL 系是 /var/log/secure。
报错四：fail2ban 启动了但封不了人，报 ERROR Unable to restore the jail。 多半是 banaction 指向的防火墙动作名不对——用 ufw 时应写 banaction = ufw，用 firewalld 时应写 banaction = firewallcmd-ipset。**
报错五：Nginx 改完配置 nginx -t 报 unknown directive "server_tokens"。 位置放错了，server_tokens 要写在 http 块里。
报错六：装完自动更新后站点莫名重启了几次。 自动重启时间没设成低峰期，或者 Automatic-Reboot 被设成了 true 但时间还是默认值。 改 Automatic-Reboot-Time 到凌晨 4 点，或改成手动重启。
报错七：mysqldump 备份时网站卡住。 没加 --single-transaction，InnoDB 表被锁了。
报错八：Nginx 日志里大量 upstream timed out（110），但数据库明明很快。 先看是不是 PHP-FPM 那边排队——查 /var/log/php-fpm.log 里的 pm.max_children 提示，或者看 Nginx 的 fastcgi_read_timeout 是不是设得太小。
报错九：磁盘空间突然被占满，机器变得很慢。 常见原因是日志没有轮转或者备份脚本把备份写在了本机同盘。 查 df -h 找出是哪个挂载点满了，再 du -sh /var/* | sort -h | tail -5 定位目录；确认后配 logrotate 并把备份改到异地。**
报错十：配置了密钥登录，但 ssh -v 显示还是走了密码认证。 多半是客户端的 ~/.ssh/config 里指定了 PreferredAuthentications password，或者服务器上的 PubkeyAuthentication 被设成了 no。 用 ssh -v 看服务器发的认证方法列表，里面有没有 publickey 一眼就能看出来。
报错十一：升级系统后 SSH 连不上了，报 Protocol major versions differ。 这是 OpenSSH 大版本变更导致的兼容性问题——旧版客户端连新版服务端（或反过来）会报这个。 解法是升级本地客户端到与服务器一致的版本，不要试图用降级服务器的方式绕过。
报错十二：chmod 600 ~/.ssh/authorized_keys 之后 key 仍然不被接受。 检查三个权限：家目录必须是 700 或 755、.ssh 必须是 700、authorized_keys 必须是 600；还有一个常被忽略的点——SELinux 开启的系统上，restorecon 一下上下文标签。
报错十三：fail2ban 把自己的 IP 封了，用 fail2ban-client 解封时提示 Couldn't find jail。 这是因为 jail 名字大小写或配置段落名对不上，用 fail2ban-client status 列出实际生效的 jail 名，再用那个名字执行 fail2ban-client set <jail名> unbanip <你的IP>。**
按你的情况，下一步该看哪家
上面讲的是判断标准，但多数人最后还是想问一句「那我该买谁」。按你的实际情况对照下面几条，直接去看对应的机型页比继续比价更快：
- 只想搭个站、预算优先：先看价格最低那档够不够用，别为用不上的配置付钱。看 数脉科技 当前机型与价格
价格与库存以商家页面当日显示为准，下单前建议先确认退款窗口与是否支持按月付费。
十、常见问题
问：香港 VPS 安全怎么加固？
答：按顺序做八件事：换 SSH 端口、装密钥、关密码登录、禁 root 直登、配系统防火墙默认拒绝入站、装 fail2ban、启用自动安全更新、备份到异地。 每一步都要「先开新路再关旧路」——改端口前先放行新端口，关密码前先确认密钥能登录。完整清单见第一到第八节。
问：只改 SSH 端口够不够？
答：不够，但值得做。 端口扫描器靠握手特征识别服务，改端口主要的作用是把无差别扫描的噪音降一个数量级。 真正挡住爆破的是密钥认证 + fail2ban 限速 + 来源 IP 白名单，三者叠加才有效。
问：fail2ban 怎么配才有效？
答：三个要点。 一是写 jail.local 而不是改 jail.conf（升级不会被覆盖）；二是日志路径要按发行系统对（Debian 系 /var/log/auth.log，RHEL 系 /var/log/secure）；三是 ignoreip 必须包含你自己的办公 IP，否则有概率把自己关在门外。 配置后用 fail2ban-client status sshd 确认 jail 生效。
问：自动安全更新会不会把网站更新挂了？
答：会，所以要控制重启时间。 把自动重启设在凌晨 4 点，并把内核更新改成「自动安装、手动重启」——生产机上这一步是必须明确做的取舍，不能让默认值替你决定。**
问：被入侵了怎么办？
答：按顺序做五步：先做快照保留证据 → 断开外联 → 重装系统（不要试图清理后门）→ 从可信来源恢复数据 → 换掉所有 SSH 密钥和密码，并检查使用同一把密钥的其他机器。 只要攻击者曾获得 root，就无法保证没有留下后门，重装是唯一可靠的办法。
问：怎么发现服务器已经被入侵了？
答：按第八节的七层清单查：多出来的账号（尤其 UID 0）、陌生 IP 的登录记录、/etc/crontab 与 systemd 定时器里的可疑项、CPU 常年 100% 的进程、陌生 IP 的 ESTABLISHED 连接、最近被改动的 PHP 文件、被截断或时间戳异常的日志。 最有效的两条是查 CPU 异常的进程和查公钥登录记录。
问：备份应该放在哪里？
答：机器之外、加密保存、密钥单独管理。 本地 /backup 目录不算备份——拿到 root 的攻击者第一个删的就是它。推荐传到另一家厂商的对象存储或另一台机器，并每季度做一次完整恢复演练。
最后再提醒一次价格口径：以上涉及机型配置与价格的内容来自渠道库快照（2026-11-11 16:30 抓取），各机型的实际报价、库存、续费价、IP 数量与退款政策请以官网当日显示和客服回复为准。
喜欢 
高兴
鬼脸
呵呵
无聊
伤心
