VPS（Virtual Private Server，虚拟专用服务器）可以承载博客、自动化工具、监控、开发环境和小型数据库。买一台机器并让页面打开，只完成了最容易的一步；真正的 VPS 自托管，是在系统更新、证书到期、磁盘写满、容器损坏或云账号异常后，仍知道怎样恢复。
这篇教程不推荐某个促销套餐，也不假设免费实例会一直存在。目标是给你一套供应商无关的流程：先定义用途，再选配置；先限制暴露面，再部署应用；先写恢复步骤，再把服务交给长期运行。
截至 2026 年 7 月 31 日，为了更新这套流程，我做了 14 次历史案例核对，覆盖低价 VPS、云实例、域名解析、Docker、持续运行、面板和网络故障。我的判断是：选型表比促销榜更有长期价值，因为价格和库存会变，资源、暴露面和恢复责任不会消失。
先看结论
- 不要按“便宜”和“核心数”买 VPS，先写清业务、数据量、峰值和可接受停机时间。
- 首次登录先完成密钥、管理用户、更新和防火墙，再安装面板或应用。
- Docker 让部署更一致，但不会自动提供安全、备份和高可用。
- 域名、反向代理和 HTTPS 是三件事；应用端口尽量不要直接暴露公网。
- 备份成功不等于能恢复，必须在另一台临时机器做恢复演练。
- 如果你不愿持续更新、监控和处理告警，托管服务通常比自托管更合适。
买 VPS 前，先写一张业务卡
先回答下面七个问题，再比较套餐：
| 问题 | 要记录的答案 | 为什么重要 |
|---|---|---|
| 跑什么 | 静态站、Ghost、数据库、机器人、转码或开发环境 | 决定 CPU、内存、磁盘与架构 |
| 谁访问 | 自己、团队、国内用户或全球用户 | 决定地区、延迟与网络线路 |
| 数据多大 | 当前容量、每天增长量、日志增长量 | 决定磁盘、备份空间和保留周期 |
| 峰值多高 | 并发、内存峰值、CPU 峰值 | 避免平时正常、流量一来就崩 |
| 能停多久 | 分钟、小时还是一天 | 决定是否需要热备与自动切换 |
| 丢多少数据可接受 | 零、几分钟、一天 | 决定备份频率 |
| 怎样迁走 | 数据导出、域名切换、恢复步骤 | 避免被某个面板或供应商锁住 |
可以把最后两项理解成两个目标：
- RTO（恢复时间目标）：服务故障后，多久必须恢复。
- RPO（恢复点目标）：最多能接受丢失多长时间的数据。
一个个人博客可能接受数小时停机和一天的数据损失；支付、会员或实时交易系统通常不能照搬这个标准。
CPU、内存、磁盘和带宽怎样选
配置不是越高越好，而是不能出现明显短板。
| 资源 | 重点看什么 | 容易踩的坑 |
|---|---|---|
| CPU | 架构、单核性能、是否共享、长期负载限制 | 只看 vCPU 数量 |
| 内存 | 常态、峰值、数据库缓存、容器总量 | 忽略 OOM 后进程会被杀死 |
| 磁盘 | 类型、容量、IOPS、写入耐久、快照能力 | 只看 GB，不看随机读写 |
| 带宽 | 端口速率、持续吞吐、线路质量 | 把 1 Gbps 端口当成始终能跑满 |
| 流量 | 月度额度、出站计费、超额处理 | 忽略备份和媒体下载也消耗流量 |
| 地区 | 用户延迟、数据规则、服务可访问性 | 只按最低价格选机房 |
| IP | IPv4 是否独享、IPv6、端口和信誉 | 默认所有服务都支持纯 IPv6 |
第一次部署可以从“满足最低需求且容易升级”的配置开始。服务上线后，用一周的 CPU、内存、磁盘 I/O、网络和容器重启记录决定是否升级，而不是凭感觉一次买满多年。
⚠️ 特别注意：年付低价会降低账面月成本，也会增加退款困难、线路变化和迁移成本。长期付款前先确认退款、续费、备份导出、IP 更换和账号验证规则。
常见的部署误区，是把短时间跑满带宽当成线路长期稳定，或把一次安装成功当成服务已经可维护。明确结论是：没有监控周期、备份恢复和迁移出口的数据，只够支持一次演示，不能支持长期选型。
第一次登录服务器，按什么顺序操作
以常见 Linux VPS 为例，顺序比“装哪些工具”更重要：
- 保存云平台控制台、救援模式和重装入口。
- 在本机生成这台服务器独立使用的 SSH 密钥。
- 首次登录后创建日常管理用户，确认
sudo权限。 - 更新系统，确认发行版仍在安全支持周期。
- 新开一个终端验证密钥登录，旧会话暂时不要关闭。
- 检查 SSH 配置语法，再逐项收紧密码登录、root 登录和转发能力。
- 配置防火墙，只开放当前确实需要的端口。
- 记录时区、主机名、磁盘布局、软件源和自动更新策略。
本机生成密钥的示例：
ssh-keygen -t ed25519 -a 64 -f ~/.ssh/my-service-ed25519
ssh-copy-id -i ~/.ssh/my-service-ed25519.pub [email protected]
密钥文件名只是示例。私钥只留在受保护的管理设备和备份中，不要上传到服务器、代码仓库或聊天工具。
OpenSSH 的 sshd_config 手册列出了配置项及默认值。修改后先运行配置检查，再保持旧连接的同时测试新连接：
sudo sshd -t
sudo systemctl reload ssh
不同发行版的服务名可能是 ssh 或 sshd。如果不能确认，不要直接关闭旧会话。
防火墙怎样配，才不会把自己锁在门外
先列端口，再写规则。典型公开网站只需要：
- SSH：仅管理地址或可信网络可访问；
- HTTP 80：用于跳转和部分证书验证；
- HTTPS 443：公开业务；
- 数据库、缓存、管理面板：优先只监听本机或私有网络。
Ubuntu 的 UFW 示例：
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow from 203.0.113.10 to any port 22 proto tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose
203.0.113.10 是文档示例地址，必须换成自己的固定管理出口；如果出口会变化，应先设计 VPN、云防火墙或救援入口。启用规则前保持现有 SSH 会话，并从新终端验证。
防火墙不是一次性任务。应用更新、Docker 端口映射、面板安装和云平台安全组都可能改变实际暴露面。每次部署后都要从外部重新检查开放端口。
Docker 部署为什么仍要做安全设计
Docker Engine 安全文档明确说明了守护进程权限、Linux 内核能力和容器隔离边界。容器共享宿主机内核；把应用放进容器，不等于它获得了虚拟机级别的隔离。
最小安全线包括：
- 只用可信来源镜像，固定可追踪版本，不长期依赖
latest； - 不把数据库端口直接映射到公网；
- 不挂载 Docker socket，除非明确理解它接近宿主机管理权限；
- 只挂载应用真正需要的目录，敏感目录尽量只读；
- 不把密码和 API Key 写进镜像或提交到 Compose 文件；
- 删除不需要的 Linux capabilities，避免
privileged: true； - 为容器设置健康检查、日志上限和资源边界；
- 升级前备份持久数据，保留可回滚的镜像版本。
每个服务至少保存一张部署卡：
域名与对外端口：
镜像、版本与来源：
持久数据目录：
环境变量与密钥来源：
反向代理配置：
健康检查地址：
备份方式与保留周期：
恢复命令与验证标准：
升级步骤与回滚版本：
这张卡的价值，是让三个月后的你或另一位维护者，不需要重新猜数据和配置在哪里。
域名、反向代理和 HTTPS 怎样接起来
这条链路可以拆成四层：
域名 DNS → 服务器 80/443 → 反向代理 → 本机应用端口
DNS 的 A 记录指向 IPv4，AAAA 记录指向 IPv6；使用 Cloudflare 时还要明确记录是仅 DNS 解析，还是由 Cloudflare 代理。Cloudflare 的官方 DNS 记录文档也要求在创建记录时分别决定 Proxy status 和 TTL。
反向代理负责按域名把请求转给正确应用。应用可以只监听 127.0.0.1:3000 或容器内部网络，避免直接暴露管理端口。
Caddy 的最小反向代理配置可以很短：
app.example.com {
reverse_proxy 127.0.0.1:3000
}
根据 Caddy Automatic HTTPS 文档，公共域名要正确指向服务器，80/443 能从外部访问，Caddy 能绑定端口，并且数据目录可写且持久，才能自动申请和续期证书。证书自动续期不代表配置永远不会出错，所以仍要监控 HTTPS 可访问性和证书到期时间。
💡 通俗讲：DNS 像地址簿，反向代理像前台，HTTPS 证书像访客检查的身份证。三者缺一，用户看到的故障现象可能都只是“网站打不开”。
备份怎样做，才不只是得到一个文件
先画出数据清单：
| 数据 | 常见位置 | 正确备份方式 |
|---|---|---|
| 数据库 | PostgreSQL、MySQL、SQLite 数据目录 | 使用数据库一致性导出、在线备份或安全停机快照 |
| 用户上传 | Docker volume 或宿主目录 | 文件级增量备份并保留权限信息 |
| 配置 | Compose、反向代理、systemd、环境变量引用 | 版本化非敏感配置，密钥单独加密 |
| 证书状态 | 反向代理数据目录 | 按工具要求持久化；同时保留可重新签发能力 |
| 运行说明 | 部署卡、版本和恢复步骤 | 与备份一起保存，但不明文夹带密钥 |
建议保留至少一份离开原服务器、原磁盘和原云账号的加密备份。云快照适合快速整机回滚，但不能证明数据库一致，也无法覆盖同一账号被锁、快照被误删或区域不可用。
使用 restic 一类工具时，备份、保留策略、清理和完整性检查是不同动作。restic 官方文档说明，清理旧快照需要 forget 与 prune，并建议在清理后执行 check。无论使用什么工具，验收标准都应是：
- 在一台临时机器准备干净环境。
- 只依赖备份和部署卡恢复。
- 启动数据库与应用。
- 检查登录、关键页面、上传文件和数据时间点。
- 记录恢复耗时是否满足 RTO，数据时间点是否满足 RPO。
我反对把“定时任务返回 0”当成备份完成。能在另一台机器还原并通过业务检查，才算恢复证据。
监控和告警最少看哪些信号
一个小型自托管服务不需要先搭复杂平台，但需要覆盖四层：
| 层级 | 最小监控 | 对应动作 |
|---|---|---|
| 外部访问 | DNS、HTTPS、状态码、响应时间 | 确认是域名、证书、代理还是应用故障 |
| 主机资源 | CPU、内存、磁盘、inode、I/O、流量 | 扩容、清日志、定位异常进程 |
| 应用运行 | 进程、容器退出码、重启次数、健康检查 | 查应用日志并回滚 |
| 数据保护 | 最近备份时间、备份大小、恢复抽查 | 停止清理旧备份并修复任务 |
另外记录登录失败、权限变化、系统更新失败、证书到期和账单异常。告警必须送到你会看到的渠道，并附一条可执行的处理入口；没有人处理的红色仪表盘不算可用监控。
升级、回滚和迁移应该怎样安排
每次升级按同一顺序：
- 阅读目标版本变更和兼容要求。
- 记录当前镜像、软件版本和配置哈希。
- 完成应用级备份，并确认最近一次恢复演练有效。
- 在测试环境或临时副本验证升级。
- 安排维护窗口，升级后跑健康检查与核心业务检查。
- 指标异常时按预先写好的回滚条件恢复旧版本和数据。
迁移则把新旧服务器并行一段时间：先在新机恢复，使用临时域名或本机 hosts 检查；再降低 DNS TTL、冻结或增量同步旧数据、切换 DNS、观察日志；最后保留旧机作为限时回滚点。确认备份、证书、定时任务和监控都转移后，才进入旧机下线流程。
哪些场景不适合自托管
下面几种情况优先考虑成熟托管服务：
- 无人愿意负责系统更新、夜间告警和恢复演练；
- 业务需要跨区域高可用，但预算只覆盖一台 VPS；
- 处理支付、身份、医疗或其他强合规敏感数据；
- 邮件送达率、风控、审计和客服比服务器控制权更重要；
- 数据能导入却没有可靠导出路径；
- 省下的订阅费小于每月维护时间和事故成本。
虚拟机的控制权会同时带来责任。自托管不是自动更私密，也不是自动更便宜；它只是把供应商承担的一部分工作转移给你。
常见问题
第一次自托管应该买多大配置？
先按服务的最低需求和峰值内存选择可升级的小配置，不要只看核心数。轻量网页与单个小服务可以从低配验证，数据库、转码和多个容器需要按实测资源升级。
Docker 部署后是不是不用维护？
不是。Docker 解决的是打包和运行环境，不会替你完成镜像来源核验、权限收敛、安全更新、数据备份、日志监控和故障恢复。
云平台快照能代替备份吗？
不能直接等同。快照适合快速回滚整机，但可能与同一云账号、区域或误操作一起失效；关键数据还要有独立位置的应用级备份，并实际验证恢复。
管理面板能代替命令行吗？
面板能降低操作门槛，但它本身也是需要更新、备份和限制权限的互联网应用。至少要知道真实端口、服务进程、配置目录、数据目录和恢复入口。
只开放 443 就绝对安全吗？
不是。端口最小化只能缩小网络暴露面，应用漏洞、弱凭据、供应链、密钥泄露和错误授权仍然存在。
VPS 自托管上线检查清单
- [ ] 已记录用途、峰值、RTO、RPO 和迁移路径
- [ ] SSH 密钥登录已从第二个会话验证
- [ ] 系统处于安全支持周期，更新策略已明确
- [ ] 云防火墙和系统防火墙只开放必要端口
- [ ] 数据库与管理端口未直接暴露公网
- [ ] 镜像版本、持久目录和密钥来源已记录
- [ ] DNS、反向代理、HTTPS 和外部健康检查已通过
- [ ] 应用级备份已离开原服务器与原账号
- [ ] 已在临时机器完成一次恢复演练
- [ ] 监控、告警、升级和回滚入口有人负责
一台 VPS 能连续运行，不代表它可维护。先用部署卡把位置写清，用备份把数据带走，用恢复演练证明它能重建，再把服务交给长期运行。