博客和密码库都使用 HTTPS，也都位于同一台 VPS。浏览器连到同一个公网 IP 的 443 端口，却能进入不同的应用，靠的是 NGINX 按请求主机名分流。DNS 告诉客户端去哪里，反向代理再把请求交给对应服务。

一层入口，多个应用

浏览器 → HTTPS / NGINX
                   ├─ blog.example.com  → Halo → 独立 PostgreSQL
                   └─ vault.example.com → Bitwarden → 独立 PostgreSQL

本项目的 NGINX 本身是 Docker 容器。因此，Halo 的上游地址使用前端网络里的服务名 halo:8090。如果在这个 NGINX 容器里写 127.0.0.1:8090，通常指向的是 NGINX 容器自身，并非另一台应用容器，也不是宿主机。

前端网络连接 NGINX 和应用；内部数据库网络只连接对应的应用与数据库。两个应用不共享数据库容器，NGINX 也不需要数据库访问权限。

反代要传递哪些信息

下面是配置中值得理解的部分，不是一份包含证书路径、监听端口和完整安全规则的可直接部署文件：

location / {
    proxy_pass http://halo:8090;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_http_version 1.1;
    proxy_buffering off;
    proxy_request_buffering off;
}

Host 保留访客访问的域名，X-Forwarded-Proto 告诉应用外部使用 HTTP 还是 HTTPS。应用还需要配置正确的外部 URL，避免生成错误链接或登录跳转。

WebSocket 另行配置 Upgrade 和 Connection，通常通过 map 按请求决定是否升级。对于 SSE 或长连接，还要结合应用需要设置读取超时；超时值过短，页面可能能打开，但连接稍后被入口切断。

上传大小与缓冲也属于入口配置

博客入口的上传上限设为 100 MB，同时关闭请求与响应代理缓冲。这与本项目 NGINX 容器临时目录较小有关：大文件不应无意间把有限的临时空间占满。

这个取舍也意味着慢客户端会更长时间占用上游连接。个人站点流量较小时可以接受；如果将来访问量增长，应结合应用、缓存和磁盘条件重新评估，而不是把“关闭缓冲”当成所有网站的通用优化。

两类证书服务于不同路线

直连的博客与密码库分别使用 Let's Encrypt 证书，浏览器直接验证源站证书链。经过 Cloudflare 的面板使用另一条路线：浏览器验证边缘证书，Cloudflare 再验证源站证书。

Cloudflare 的“完全（严格）”在加密之外，还检查源站证书的有效期、信任关系和主机名。Origin CA 适合 Cloudflare 到源站这一段，通常不能直接拿来替代浏览器信任的公共证书。若把这样的站点切为仅 DNS，浏览器可能出现证书错误。

证书续期之后，应用要真正用上它

证书文件更新不等于正在运行的 NGINX 已经加载新证书。这次续期流程包含证书域名、有效期和密钥匹配检查，随后切换证书目录，执行配置检查，再平滑重载。失败时保留或恢复原入口。

docker exec nginx nginx -t
docker exec nginx nginx -s reload

上述容器名是示例。部署新站点时，先保存现有入口，再做修改；普通规则调整优先重载，只有网络或挂载发生变化时才重建入口容器。最后同时检查旧主页、面板、密码库和博客，不能只证明新站点能打开。

参考资料

• NGINX：HTTP 反向代理模块
• NGINX：WebSocket 代理
• Cloudflare：完全（严格）模式

记录于 2026 年 9 月。封面为 AI 生成的概念插图，不是服务器现场或产品界面截图；文中部署示例已脱敏。

系列导读：个人服务器搭建系列：从哪里开始读，按准备、部署、排错和恢复选择下一篇。