为什么新 VPS 开机后不能直接部署业务
拿到一台新 VPS（Virtual Private Server，虚拟专用服务器）的 root 密码，很多人第一反应是立刻装面板、跑业务，但这个顺序恰恰是最危险的。公网上针对 SSH 22 端口的爆破扫描从 IP 分配那一刻就开始了，有公开 honeypot（蜜罐）项目的统计显示，一台新开公网 IP 的 Linux 服务器在几分钟内就会收到第一批登录尝试，弱密码在数小时内就可能被撞破。解决这个问题的方法并不复杂：按照一份固定顺序的初始化清单，把安全基线和性能参数在部署业务前一次性配好。本文这份清单按”账号安全 → 网络防护 → 系统基线 → 性能调优 → 验证”的顺序组织，全部操作在主流 Linux 发行版的默认软件源内即可完成，一台新机器大约 30 分钟能走完全部步骤。
清单的价值在于顺序和完整性。零散的设置容易漏项，而漏掉的往往是最关键的一项——例如改了 SSH 端口却忘了在防火墙放行新端口，结果把自己锁在门外；或者创建了新用户却没验证 sudo 可用就禁用了 root 登录。下面每一节都遵循”先确认替代方案可用，再关闭旧通道”的原则，可以按行执行、逐项打勾。
第一步：账号与 SSH 登录安全
登录安全是整个清单中优先级最高的部分，核心思路是用密钥替代密码、用普通用户替代 root 直连：
- 在本地电脑生成密钥对：
ssh-keygen -t ed25519，然后把公钥写入服务器：ssh-copy-id user@服务器IP - 创建日常运维用户并加入 sudo 组：
adduser deploy && usermod -aG sudo deploy（Debian/Ubuntu），CentOS 系使用wheel组 - 用新用户开一个新终端测试密钥登录和 sudo 执行，确认无误后再进行下一步
- 编辑
/etc/ssh/sshd_config：设置PasswordAuthentication no、PermitRootLogin no，可顺手把 Port 改为高位端口 - 重载服务：
sudo systemctl reload sshd，保持当前会话不断开，另开终端验证新配置能登录
一个容易踩的坑：改 Port 后如果系统启用了 SELinux（CentOS 默认），还需执行 semanage port -a -t ssh_port_t -p tcp 新端口，否则 sshd 无法绑定端口导致重启失败。所有 SSH 配置变更都必须遵循”旧会话保底、新会话验证”的双通道操作，配置错误时至少还有一条路可以进去修复。SSH 免密登录的图文细节可参考站内的技术教程分类。
第二步：防火墙与网络暴露面收敛
新 VPS 通常默认所有端口开放，初始化阶段应只放行业务必需的端口。以 UFW（Ubuntu 默认防火墙工具）为例：
sudo ufw allow 新SSH端口/tcp—— 先放行 SSH，避免启用防火墙后断连sudo ufw allow 80,443/tcp—— 按业务需要放行 Web 端口，未用到的端口一律不开sudo ufw enable—— 启用规则，之后用sudo ufw status verbose复核
相比逐个封禁，”默认拒绝、按需放行”（deny by default）的模型能把暴露面压缩到最小。一个实用的自检方法是从外部扫描自己的端口，比对开放结果与业务清单是否一一对应：未设密码的 Redis 端口暴露在公网是勒索脚本最常利用的入口之一。云平台安全组与本机防火墙是两层独立防护，建议都配置并保持规则一致。
第三步：系统基线：更新、时间同步与自动安全补丁
完成网络收敛后，接下来处理系统本身的基线状态。这三项设置一次配好，长期受益：
- 更新软件源并升级全部补丁：Debian/Ubuntu 执行
sudo apt update && sudo apt upgrade -y，CentOS 系执行sudo dnf upgrade -y。新镜像从制作到交付往往间隔数周，这期间积累的安全补丁必须先打上 - 启用时间同步：
sudo timedatectl set-ntp true并用timedatectl status确认 NTP（Network Time Protocol，网络时间协议）已同步。时间漂移会让 HTTPS 证书校验失败、数据库主从延迟计算错乱、日志排查失去时间基准 - 开启自动安全更新：Ubuntu 安装
unattended-upgrades并确认20auto-upgrades中两项均为 “1”；CentOS 系启用dnf-automatic并只订阅 security 仓库，让高危补丁无需人工介入即可落地
主流发行版每月发布的安全补丁通常在 10-30 个之间，人工跟进的遗漏率会随时间上升，而自动安全更新只安装安全类补丁、不自动重启，运维风险很低。配置完成后执行 sudo reboot 做一次重启验证，提前暴露”重启后服务起不来”的问题。
第四步：性能基础：Swap、文件句柄与内核参数
性能调优不需要一上来就改几百行内核参数，新机器优先做三件收益最确定的事：
- 配置 Swap：小内存机型（1-2 GB）建议创建与内存等量的 Swap 文件：
sudo fallocate -l 2G /swapfile && sudo chmod 600 /swapfile && sudo mkswap /swapfile && sudo swapon /swapfile，并写入/etc/fstab持久化；同时把vm.swappiness设为 10，让系统只在内存真正吃紧时才使用 Swap - 提高文件句柄上限：在
/etc/security/limits.conf中为运维用户设置nofile 65535，避免高并发业务跑一段时间后报 “Too many open files” - 开启 BBR 拥塞控制：内核 4.9 以上执行
sudo sysctl -w net.ipv4.tcp_congestion_control=bbr并写入/etc/sysctl.conf，对跨境链路的 TCP 吞吐提升明显，这是少数”零成本、纯收益”的网络参数
这三项配置覆盖了新 VPS 最常见的性能瓶颈来源：内存耗尽、句柄耗尽和 TCP 传输效率。至于数据库缓存、Web 服务器 worker 数量这类业务层调优，建议等业务跑起来、有了真实监控数据再动手，凭感觉调参往往适得其反。不同机房线路对实际体验的影响同样不小，选型阶段可以参考站内的影响美国VPS服务器速度的核心因素与优化指南，把线路因素和系统调优分开评估。
验证与监控：确认清单真正生效
所有配置完成后，用一组可复核的命令逐项验证，而不是凭记忆认为”应该配好了”：
sudo sshd -T | grep -E 'passwordauthentication|permitrootlogin'—— 确认输出均为 nosudo ufw status numbered或sudo firewall-cmd --list-all—— 核对端口与业务清单一致timedatectl—— NTP synchronized 为 yesfree -h && swapon --show—— Swap 容量与开机自动挂载正常sysctl net.ipv4.tcp_congestion_control—— 返回 bbr
验证通过后，建议补上轻量监控：安装 htop、vnstat（流量统计）建立日常检查习惯，或接入云平台免费告警，把 CPU、内存、磁盘阈值设到 85%。初始化清单解决的是”起点正确”，持续监控解决的才是”长期稳定”，两者缺一不可。对于接下来要部署网站业务的读者，宝塔面板一键部署 WordPress 全攻略提供了初始化完成后的下一阶段操作路径。
总结与行动建议
回顾整份清单的执行顺序：先用密钥和新用户锁死登录通道，再收敛防火墙暴露面，然后打好系统基线（补丁、时间、自动更新），接着做收益确定的性能配置（Swap、句柄、BBR），最后用命令逐项验证并接入监控。整个流程可以整理成一份可复用的脚本，每开一台新机器跑一遍，30 分钟内即可完成从裸机到生产可用的准备。
如果你需要把这套流程进一步固化，推荐从两个方向入手：一是把上述命令按顺序写进 shell 脚本，配合 set -e 保证失败即停；二是维护一份属于自己的 checklist 文档，每次新机器交付时逐项记录执行时间和结果。市场上不同价位的 VPS 在初始镜像质量上差异不小，Hostease 等主流服务商的镜像更新频率与预装组件各有差异，选购阶段可以参考站内的美国VPS vs 香港VPS：价格、速度、合规、带宽（单位时间内可传输的数据量）、稳定性全方位对比指南；机器到手后按本清单完成初始化，才能让后续业务在一个干净、安全的基线上运行。总结：建议把本文清单固化为脚本，如果你需要进一步精简流程，可以考虑从 Ansible 模板起步。
