这是「把自己部署到互联网上」系列的第 24 篇。
上一篇我确定了 Nginx 方案：
Nginx 统一管理多个项目的公网入口Docker Compose 管理应用、数据库和数据卷这一篇开始落到操作层面。目标是先把全局 Nginx 容器跑起来，确认它具备接入多个项目的基础能力：能占用 80 和 443，配置文件在宿主机可维护，加入公共 Docker 网络，日志能查看，配置能检查，也能安全 reload。
开始前，-服务器已经...
这是「把自己部署到互联网上」系列的第 23 篇。
前两篇连续讨论了 Nginx：第 21 篇讲 Nginx 应该装在系统里，还是放进 Docker 容器；第 22 篇讲为什么我没有给每个项目都起一个 Nginx 容器。到这里，思路已经明确。
我的个人服务器后面不只跑博客，还可能跑个人官网、作品站、小工具和实验项目。如果每个项目都各自暴露端口、处理 HTTPS、维护 Nginx 配置，后面会越来越难管理。
所以我的最终方案是：全局 Nginx 统一管理多个项目的公网入口。
这篇不是最终配置文件，而是后续部署博客和官网时遵循的整体架构。下一篇再进入公共网络、配置文件和启动检查。
这是「把自己部署到互联网上」系列的第 22 篇。
上一篇讨论了 Nginx 的部署方式：系统安装，还是放进 Docker 容器。
我的结论是:
如果只是单项目、传统部署，系统 Nginx很好；如果像我这样准备在一台服务器上跑多个 Docker 项目，并希望统一入口、减少公网端口暴露、提升迁移清晰度，容器化 Nginx更适合。
比如博客一个 Nginx，官网一个 Nginx，作品站一个 Nginx，后台服务一个 Nginx。每个项目都自带入口，看起来独立，也符合“项目自包含”的直觉。
我一开始也考虑过这个方案，之前也确实这么干过，一个应用配套一个 Nginx, 但最后没有这么做。
单看一个...
这是「把自己部署到互联网上」系列的第 21 篇。
上一篇讲了 Docker 和 Docker Compose 的分工。Docker 负责单个服务的打包、运行和隔离，Compose 负责一组服务的启动、连接和管理。到这里，我的博客部署方向已经明确：
项目尽量用 Docker 管理，多服务用 Compose 编排，数据库不直接暴露公网，外部入口集中在 80 和 443。
那么问题就来了：
这是个很好的...
这是「把自己部署到互联网上」系列的第 20 篇。
前两篇我围绕部署方案做了选择：生产环境到底该用 Conda 还是 Docker，以及为什么最终放弃 Conda 部署。到这里，方向已经确定：这台服务器后面会以 Docker 作为主要部署方式。
但在真正写 Dockerfile、compose.yml、启动容器之前，需要先把两个概念讲清楚：Docker 和 Docker Compose 到底分别解决什么问题？
很多教程会写：安装 Docker，写 Compose 文件，然后执行：
docker compose up -d
照着做可能能跑起来，但如果不理解它们的分工，后面排查问题会很困难...
这是「把自己部署到互联网上」系列的第 19 篇。
上一篇，我把 Conda 和 Docker 放在个人博客生产部署场景里做了一次对比。结论不是 Conda 不好，也不是 Docker 永远更高级，而是：如果只是本地开发、数据分析、短期实验，Conda 很舒服；但如果是长期运行、多服务组合、多项目共存，并且后续要迁移和维护的个人博客，Docker 更适合我的目标。
这一篇不再泛泛对比，而是从自己的过程出发，复盘为什么我最终放弃了 Conda 部署。
一开始，我确实想用 Conda。长期写 Python 的人，很容易把 Conda 当成自然选择。本地开发时，它管理 Python 版本和依赖很...
这是「把自己部署到互联网上」系列的第 18 篇。
前面一段时间，我花了几篇文章处理服务器安全：普通用户、root 登录、SSH、安全组、防火墙、数据库端口、扫描日志和基础安全清单。安全边界处理完后，终于要进入部署阶段。
但在真正部署博客之前，遇到了一个实际选择：生产环境到底该用 Conda 还是 Docker？
这个问题和我的项目直接相关。个人博客会涉及 Python 环境、依赖安装、数据库、服务启动、后续迁移和长期维护。如果只是本地开发，Conda 很方便；但如果要放到长期运行的云服务器上，还要考虑 Nginx、HTTPS、多项目共存、数据库和未来个人官网，选择就不只是“哪个工具熟”这...
这是「把自己部署到互联网上」系列的第 17 篇。
从第 11 篇到第 16 篇，我一直在写服务器安全。这几篇没有部署成功截图，没有博客页面上线，也没有复杂架构图，讲的都是普通用户、root 登录、SSH、安全组、防火墙、数据库端口、服务器扫描、fail2ban、日志和健康检查。
这些内容不算新颖，但写完这一段后，我更确定了一件事：对一台准备长期暴露在公网的服务器来说，部署项目之前，必须先把基础安全边界建好。
这篇是服务器安全阶段的复盘，不包含太多操作，只是把前面几篇串起来，看看我为什么从“赶紧部署博客”，变成了“先把服务器边界理清楚”。
第 10 篇之前，我主要解决的是动机问题：为...
这是「把自己部署到互联网上」系列的第 16 篇。
前几篇围绕服务器安全展开：不要急着部署项目，不要长期用 root 登录，分清安全组和防火墙，不要随便开放数据库端口，也记录了服务器4小时被扫 500 多次后的判断。到这里，需要把这些内容收束成一份清单。
这不是企业级安全方案，也不是完整加固手册。它只是我给个人服务器设定的最低安全标准：在部署博客、Nginx、Docker、数据库和 HTTPS 之前，先把基础风险过一遍。
为什么需要清单？因为感觉是个小项目，心理上容易跳过基础安全。
买完服务器想马上部署，装完 Docker 想马上跑项目，域名解析好了想马上访问页面。
...这是「把自己部署到互联网上」系列的第 15 篇。
前几篇一直在写服务器安全：不要急着部署项目，不要长期用 root 登录，分清安全组和防火墙，也不要随便开放数据库端口。这些看起来感觉有点水文章的嫌疑:dog:
直到我真的去看服务器日志，看到陌生 IP、异常请求和登录尝试，才有了更直接的感受：公网服务器不是等你部署项目的安静机器。只要它有公网 IP，就已经进入了一个会被扫描、探测和尝试访问的环境。
在看日志之前，我也有过一种侥幸：我这只是个人博客，没有访问量，也没有什么值钱业务，肯定没人专门盯上。我们平时说安全、后门等，一想到就是大公司、核心业务、支付接口和用户数据。个人项目听起...