Debian VPS Setup Guide

August 17, 2026

刚拿到一台 VPS 时，我不会急着安装软件或跑“一键优化”。最先做的几件事其实很无聊：确认救援控制台，记下机器刚交付时的状态，保留一个可用的 SSH 会话。但 SSH 或防火墙改错时，真正能救场的就是这些准备。

下面是我现在使用的初始化顺序：先留好退路并记录基线，接着处理登录安全，最后才碰性能参数。它适用于 Debian stable、Ubuntu Server 及大多数以 APT 管理软件包的云服务器。

本文中的命令默认在 root shell 中执行。普通用户可先运行 sudo -i，完成后用 exit 退出。

开始前：先守住三条底线

确认云服务商提供网页终端、VNC 或救援模式。
修改 SSH 和防火墙时，不要关闭当前已经连通的会话。
涉及登录方式的修改，必须用第二个终端验证成功后再继续。

另外，不要把密码、Token、私钥或完整公网 IP 粘贴进公开文章和测试报告。看到 curl ... | bash、wget ... && bash ... 之类的命令时，至少先阅读脚本内容和项目来源。

1. 给服务器拍一张“初始快照”

先记录系统实际交付情况，日后出现性能下降、磁盘异常或网络变化时，才有可比较的基线。

. /etc/os-release
printf 'OS: %s\n' "$PRETTY_NAME"
uname -r
hostnamectl
timedatectl
nproc
free -h
df -hT
ip -brief address
ip route
ss -lntup
systemctl --failed

重点核对以下信息：

项目	需要确认的内容
系统	发行版、版本、内核是否符合订单
资源	CPU 核数、内存、磁盘容量是否基本一致
网络	IPv4/IPv6、默认路由和机房位置是否合理
服务	当前有哪些端口正在监听
健康状态	是否已有失败的 systemd 服务

第三方“融合怪”或硬件测试脚本并非不能用，但它们通常会执行大量网络测试，甚至上传报告。对新手而言，先用系统自带工具完成核验更透明，也更容易定位问题。

2. 统一主机身份与时间

主机名最好能看出用途或地域，例如 web-sg-01、vpn-hk-01，不要保留一串难以辨认的随机字符。

hostnamectl set-hostname web-sg-01
timedatectl set-timezone UTC
timedatectl status
timedatectl timesync-status 2>/dev/null || true

服务器统一使用 UTC，通常更便于跨地区排查日志。如果所有维护者都在同一时区，也可以改为 Asia/Shanghai 等 IANA 时区名称。

时间同步异常要先处理。错误的系统时间会影响 TLS 证书校验、定时任务和日志关联。

3. 审阅软件源并更新系统

先看当前启用了哪些仓库：

grep -RhsE '^(deb |Types:|URIs:|Suites:|Components:)' \
  /etc/apt/sources.list /etc/apt/sources.list.d 2>/dev/null

确认没有混用 Debian stable/testing、不同 Ubuntu 版本的软件源，或无法解释来源的第三方仓库。较新的 Debian 默认可能使用 /etc/apt/sources.list.d/*.sources 的 deb822 格式，这是正常现象。

然后更新软件包索引，先审阅升级列表，再执行升级：

apt update
apt list --upgradable
apt upgrade

检查系统是否建议重启：

test -f /var/run/reboot-required && cat /var/run/reboot-required

如果需要清理旧依赖，先模拟，不要直接删除：

apt -s autoremove

确认列表中没有业务组件后，再自行决定是否运行 apt autoremove。

4. 只安装真正会用到的工具

一台轻量服务器不需要预装“全家桶”。下面这组工具足以覆盖下载、编辑、会话保持、状态观察与基础排障：

apt install ca-certificates curl git vim tmux htop unzip rsync sudo

常用工具的角色很简单：

tmux：SSH 中断后，任务仍可继续运行；
htop：快速查看 CPU、内存和进程；
rsync：文件同步和增量备份；
curl：下载前也能先查看响应和脚本内容；
git：对自己的配置文件进行版本管理。

5. 建立日常管理账号

长期直接使用 root 登录，会放大误操作的后果。可以创建一个普通管理账号，下面以 ops 为例：

adduser ops
usermod -aG sudo ops
id ops

为它准备 SSH 公钥目录：

install -d -m 700 -o ops -g ops /home/ops/.ssh
install -m 600 -o ops -g ops /dev/null /home/ops/.ssh/authorized_keys
vim /home/ops/.ssh/authorized_keys

将你自己的公钥粘贴到 authorized_keys，每把钥匙占一行。公钥通常以 ssh-ed25519 或 ssh-rsa 开头；私钥绝不能上传到服务器或公开分享。

先从另一个终端验证：

ssh ops@服务器IP
sudo -i

只有当普通账号、公钥和 sudo 都正常时，才能进入下一步。

6. 加固 SSH，但别把自己锁在门外

使用独立的 drop-in 文件，避免直接改动系统主配置：

install -d /etc/ssh/sshd_config.d
vim /etc/ssh/sshd_config.d/00-local-hardening.conf

写入：

PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no

先检查语法，再平滑重载：

sshd -t
systemctl reload ssh
sshd -T | grep -Ei 'pubkeyauthentication|passwordauthentication|kbdinteractiveauthentication|permitrootlogin'

保持旧会话在线，再次从新终端登录 ops。如果失败，立刻在旧会话中检查配置；必要时将 00-local-hardening.conf 移出该目录并重新加载 SSH。

如果你有自动化任务仍依赖 root 或密码登录，应先完成迁移，不要机械套用上述配置。

7. 启用防火墙，只开放确实需要的端口

安装 UFW，并先读取 SSH 实际监听端口：

apt install ufw
SSH_PORT="$(sshd -T | awk '$1 == "port" {print $2; exit}')"
printf 'SSH port: %s\n' "$SSH_PORT"

确认端口输出正确后，再设置规则：

ufw default deny incoming
ufw default allow outgoing
ufw allow "${SSH_PORT}/tcp"
ufw enable
ufw status verbose

部署网站时再开放 HTTP/HTTPS：

ufw allow 80/tcp
ufw allow 443/tcp
ufw status numbered

不要提前开放“以后可能会用”的端口。防火墙规则应与 ss -lntup 的实际监听结果互相印证。

如果启用后 SSH 新连接失败，保持当前会话不退出，并通过当前会话或云控制台运行 ufw disable，修正规则后再启用。

8. 限制暴力登录尝试

当 SSH 暴露在公网时，可以用 Fail2ban 降低自动化撞库和反复尝试带来的噪声：

apt install fail2ban
vim /etc/fail2ban/jail.d/sshd.local

写入一个容易理解的起始配置：

[sshd]
enabled = true
backend = systemd
maxretry = 5
findtime = 10m
bantime = 1h

检查并启动：

fail2ban-client -t
systemctl enable --now fail2ban
fail2ban-client status sshd

Fail2ban 是补充措施，不是公钥认证和防火墙的替代品。如果你经常更换出口 IP，要避免设置过度激进的长期封禁规则。

9. 让日志有用，但别挤满小磁盘

先查看 journald 当前占用：

journalctl --disk-usage

对磁盘较小的 VPS，可以设置明确上限。下面只是一个适合轻量服务器的起点：

install -d /etc/systemd/journald.conf.d
vim /etc/systemd/journald.conf.d/10-storage-limits.conf

[Journal]
Storage=persistent
SystemMaxUse=500M
RuntimeMaxUse=100M
MaxRetentionSec=30day

应用并复查：

systemctl restart systemd-journald
journalctl --disk-usage

日志上限要结合磁盘容量和审计需要调整。生产环境不能只考虑“省空间”，还要确保事故发生后有足够的回溯窗口。

10. 按实际压力决定 Swap

Swap 是内存不足时的缓冲区，不是廉价内存。它可以降低突发内存压力直接触发 OOM 的概率，但持续大量使用 Swap 往往意味着应用需要限额、优化或增加内存。

先检查现状和根文件系统类型：

free -h
swapon --show
findmnt -no FSTYPE /

可以把下面的经验当作起点，而不是固定公式：

场景	建议思路
1 GB 内存的轻量服务	可评估 1～2 GB Swap 作为缓冲
2～4 GB 内存的普通小站	可从 1 GB Swap 开始观察
8 GB 以上且负载可控	根据峰值和应用特性决定，不必为了“标准答案”创建
长时间大量换入换出	优先限制应用、查内存泄漏或升级配置

对于常见的 ext4/XFS 文件系统，如果当前没有 Swap，可按选定容量创建交换文件。以下示例为 1 GB：

fallocate -l 1G /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile
grep -q '^/swapfile ' /etc/fstab || echo '/swapfile none swap sw 0 0' >> /etc/fstab
swapon --show
free -h

Btrfs 等文件系统对交换文件有额外要求，不要直接照搬上面的做法。vm.swappiness 也没有适合所有工作负载的神奇数值，先使用发行版默认值并观察：

sysctl vm.swappiness
vmstat 1

zswap 要不要开？

zswap 会在 RAM 中压缩待换出的页面，以 CPU 开销换取更少的 Swap I/O；它仍需要后端 Swap。先查看当前状态：

cat /sys/module/zswap/parameters/enabled 2>/dev/null || echo 'zswap unavailable'

是否启用、如何写入启动参数与系统的内核和引导方式有关。除非已经确认瓶颈来自 Swap I/O，否则不必把 zswap 当作新机必做项。

11. 把 BBR 当作可选实验

先查看内核提供的拥塞控制算法和当前设置：

modprobe tcp_bbr 2>/dev/null || true
sysctl net.ipv4.tcp_available_congestion_control
sysctl net.ipv4.tcp_congestion_control
sysctl net.core.default_qdisc

只有当可用列表中出现 bbr，并且你准备使用同一地点、同一时间段、同一工具做前后对比时，才值得继续配置：

vim /etc/sysctl.d/90-bbr.conf

net.core.default_qdisc=fq
net.ipv4.tcp_congestion_control=bbr

sysctl --system
sysctl net.core.default_qdisc net.ipv4.tcp_congestion_control

BBR 不会突破服务商带宽上限，也不保证所有线路都更快。不要为了一个“已开启”的截图运行来源不明的内核替换脚本。

12. 做完验收，再决定是否重启

把关键状态一次检查完：

hostnamectl
timedatectl
ip -brief address
ip route
getent hosts deb.debian.org
systemctl --failed
ss -lntup
ufw status verbose
fail2ban-client status sshd
swapon --show
df -hT
journalctl -b -p warning

最终验收清单：

[ ] 普通管理账号可通过公钥登录并使用 sudo；
[ ] root 登录和密码登录策略符合预期；
[ ] 防火墙规则与实际监听端口一致；
[ ] DNS、时间同步和 APT 更新正常；
[ ] 没有无法解释的失败服务；
[ ] 磁盘、日志与 Swap 占用合理；
[ ] 云控制台或救援模式仍然可用；
[ ] 重要数据已有异机备份。

只有在内核或关键组件更新、系统明确提示，或者你需要验证服务能否随系统启动时，才有必要重启：

reboot

重启后重新登录并检查：

uname -r
systemctl --failed
ss -lntup
swapon --show
journalctl -b -p warning

从另一台机器实际测试 SSH、HTTP/HTTPS 和业务端口。服务器“能启动”不等于服务“能从公网访问”。

后续维护比开荒更重要

新机初始化只是第一天。真正决定可靠性的，是之后能否持续完成以下几件事：

定期安装安全更新，并在升级前阅读变更；
为网站、数据库和配置建立异机备份，定期做恢复演练；
监控磁盘空间、内存、负载、证书到期时间和服务存活；
定期审阅用户、公钥、开放端口和第三方软件源；
把每次修改记录下来，确保知道如何验证和回退。

一台配置朴素但边界清楚、可恢复、有人维护的服务器，通常比装满“优化脚本”的服务器更可靠。

参考与致谢

本文围绕 Debian 系新服务器初始化主题重新组织和撰写，参考了以下文章与官方资料：

与渡劫：《Debian 系新机开荒手册》
Debian Reference：Debian package management
Debian Manpages：sshd_config(5)
Ubuntu Server Documentation：Firewall / UFW
systemd：journald.conf
Linux Kernel Documentation：zswap

说明：本文不是对参考文章的转载或逐段改写，而是基于相同主题独立整理的操作清单。命令执行前请结合自己的系统版本、云服务商控制台和现有业务进行核对。