这是「把自己部署到互联网上」系列的第 11 篇。
前面几篇，我把个人博客上线前最开始的一段路走完了：为什么要做个人博客，为什么要建设技术品牌，服务器怎么买，域名怎么选，备案怎么填，以及备案过程中容易遇到哪些问题。
到这里，博客入口已经有了轮廓：服务器有了，域名有了，备案也开始进入流程。按理说，下一步最让人兴奋的事，就是赶紧把博客部署上去。拉代码，装环境，启动服务，配端口，打开浏览器，看见页面能通过公网访问。
但我第一次连上服务器后，没有马上部署项目，而是先停下来想了一件事：这台机器以后会长期暴露在公网，不能一上来就把项目往上扔。
买完服务器后，云平台会给我们一个公网 IP。第一次买属于自己的服务器多少会有点冲动：终于有一台属于自己的机器了。它不是本地环境，不是公司的测试机，而是一台真实存在、可以登录、可以安装软件、可以运行服务，也可以被互联网访问，属于你自己一个人的机器。
我当时也很想马上开始。脑子里已经有了流程：装 Git，装 Docker，拉代码，写 Docker Compose，起数据库，跑迁移，配 Nginx，最后通过域名访问。
但准备动手时，我意识到一个前提：这不是本地电脑，而是一台有公网 IP 的服务器。从创建成功那一刻起，它就可能被扫描、被尝试登录、被自动化脚本探测。
本地开发环境有天然安全感。端口开错了，大多数时候影响有限；配置乱一点，也只是自己难受；数据库密码简单一点，也不一定立刻暴露在公网。但公网服务器不一样。它的 IP 可达，只要端口开放，就可能被访问；SSH 暴露，就可能被尝试爆破；数据库端口误开，就可能被扫描到；配置文件泄露敏感信息，也可能带来后续风险。
更准确地说，个人服务器不会因为它是个人项目就更安全。扫描脚本不会关心你是不是小博客，它们只看 IP、端口、服务指纹、弱口令、常见路径和已知漏洞。网站有没有访问量，和服务器会不会被扫，不是一回事。
服务器状态
所以部署项目之前，至少需要知道这台服务器现在处于什么状态。
- 要不要长期用 root 登录？很多云服务器默认允许 root 登录。root 很方便，权限最大，什么都能做。但方便背后是风险：日常操作一旦误删、误改，影响会很大；如果登录方式不安全，被爆破后的后果也更直接。
- SSH 要不要调整？默认配置能用，但能用不代表适合长期暴露。是否使用密钥登录，是否允许密码登录，是否限制 root 登录，是否调整端口，都需要结合实际情况考虑。
- 安全组和防火墙现在是什么状态？云平台安全组控制云平台入口流量，服务器内部防火墙控制系统层面的访问。它们不是一回事。如果分不清这两层，后面端口访问出问题时会很难排查。
- 哪些端口应该开放？个人博客上线通常需要 80 和 443，SSH 需要一个管理入口。但数据库端口、内部服务端口、后台服务端口，大多数情况下不应该直接暴露到公网。
- 有没有基本异常登录防护？比如是否需要 fail2ban，登录日志要不要看，异常尝试怎么发现。它们不复杂，但如果不先想，后面就容易为了方便先放开，等出问题再补。
以前很容易把安全当成后置任务：先把项目跑起来，先让页面能访问，先把功能调通，安全后面再补（我猜可能会有人和我一样的想法）。本地练习这样做问题不大，但公网服务器不适合。只要服务暴露出去，风险就已经开始了。
服务器安全不一定要一开始做到很完整，但至少要有底线：不长期使用 root 做日常操作，不随便开放数据库端口，不把所有端口都放行，不使用过于宽松的安全组规则，不把敏感配置直接暴露，不忽略 SSH 登录风险，定期查看日志。
这些不是高级安全实践，只是不让服务器裸奔。
如果这个博客只是一次性练手，我可能不会这么谨慎。跑起来，看一眼，写篇总结，然后释放服务器就结束了。但这次不一样。它后面会承载文章、Git 合集、部署日志、项目复盘、个人官网和作品站，也会慢慢成为个人成长与踩坑的长期内容入口。
长期项目不能只考虑能不能上线，还要考虑一个月后能不能稳定运行，三个月后能不能看懂配置，半年后新增项目会不会互相影响，服务器被扫描时能不能发现，出问题时能不能及时定位，数据和配置能不能迁移。
所以我决定，在部署博客之前，先做服务器安全初始化。
这一步看起来比较枯燥。没有页面、截图、上线瞬间，也没有“终于访问成功”的反馈。很多个人项目后面不想维护，并不一定是技术栈选错，而是前期太随意：目录乱，配置散，端口不知道谁开的，数据库不知道怎么连的，Nginx 不敢改，证书过期不知道在哪里续，服务器异常也不知道从哪查。
这些问题单独看不大，叠在一起就看起来，乱七八糟，一点都不想维护。基础结构初始化不是为了让项目马上看起来更好，而是为了让后面的维护、升级变得简单一点。
基础准备工作
在真正部署博客前，我准备先做几件基础工作。
- 确认服务器环境。先看系统版本、基础目录、默认用户、网络状态，知道自己服务器是什么环境。
- 创建普通用户。日常操作尽量不用 root，把高权限操作控制在需要的时候。
- 调整 SSH 登录策略。根据实际情况配置密钥登录、限制高风险登录方式，并确保自己不会把自己锁在服务器外面。
- 理解安全组和防火墙。安全组在云平台层面，防火墙在系统层面，后面端口是否能访问，很大程度取决于这两层是否都配置正确。
- 只开放必要端口。SSH 管理入口、HTTP、HTTPS 是后续会用到的。数据库和内部服务端口，尽量不要直接暴露公网。
- 准备基础防护和健康检查。比如 fail2ban、登录日志、磁盘、内存、服务状态，这些后面都要逐步纳入维护习惯。
这套动作表面看起来没啥实质性进展，但会让服务器从“裸机”，变成一个可以开始承载项目的环境。
服务器安全是系统基石，如果项目经常打不开，HTTPS 报错，数据库暴露，服务器异常，文章链接失效，那么内容再好也会被基础体验拖累。
所以服务器安全阶段虽然偏运维，但仍然是系统搭建至关重要的一部分。它解决的是：我的系统能不能长期、稳定、可靠地把内容放在互联网上。
下一篇开始进入具体操作：为什么不要一直用 root 登录服务器？这件事看起来很小，但它决定了后面日常操作和最高权限之间能不能保持边界。
本文由 楸木 原创，转载请注明出处。