博客能够打开，并不代表部署已经完成。整理自己的 Halo 博客时，我遇到了几个容易被忽略的问题：应用端口仍可从公网直连，部分页面链接指向 localhost，小内存服务器也需要为运行压力留出余量。

这篇文章记录基础部署的整理过程，重点解释每项配置解决什么问题，以及修改后应该怎样验证。分类导航、双域名跳转和备份安排放在第二篇中。

一、先理清访问链路

我使用 Ubuntu 云服务器，通过 1Panel 管理应用。Halo 和 MySQL 运行在 Docker 容器中，OpenResty 负责接收网站请求，并将请求转发给 Halo。

组件 在这套部署中的作用
Halo 管理文章、页面、主题和插件
MySQL 保存博客的数据库内容
OpenResty 提供 HTTPS 入口，并反向代理到 Halo
1Panel 管理应用、网站、容器和备份任务

一次访问的大致过程是：

读者的浏览器 → HTTPS 域名 → OpenResty → Halo → MySQL

在我的配置里，OpenResty 转发到服务器本机的 http://127.0.0.1:8091，再通过 Docker 端口映射连接 Halo 容器内的 8090 端口。

这里的 8091 是本次部署选择的宿主机端口。读者使用其他端口也可以，关键是反向代理目标与应用实际监听地址一致。公网连接使用 HTTPS；这一套部署中的内部转发使用本机 HTTP。

二、关闭应用端口的公网直连

最初，云防火墙允许公网访问 Halo 的应用端口。即使域名已经启用 HTTPS，访问者仍可能通过“服务器 IP + 应用端口”直接打开博客，绕过预期的网站入口。

为让博客统一从 OpenResty 进入，我做了两项调整：

  1. 删除云防火墙中允许公网访问 Halo 应用端口的规则。
  2. 将 Docker 发布端口的绑定地址改为 127.0.0.1，只允许服务器本机连接。

本次调整后的映射可以表示为：

宿主机 127.0.0.1:8091 → Halo 容器 8090

调整时要考虑反向代理所在的位置。本例中的 OpenResty 可以访问宿主机回环地址；如果反向代理位于另一个普通容器里，容器中的 127.0.0.1 指向它自身，需要根据容器网络重新确定连接方式。

保存配置后，我检查了三个入口：

检查位置 本次验证结果
外部设备访问服务器 IP 的应用端口 无法建立连接
服务器本机访问 Halo 正常
浏览器通过 HTTPS 域名访问博客 正常

这组检查同时确认了“公网入口已收紧”和“反向代理仍能工作”。涉及 Docker 发布端口时，也需要一起检查云防火墙与容器绑定地址，不能只依赖某一处面板状态。

三、修正 Halo 的外部访问地址

另一个问题是 Halo 的外部访问地址还设置为 http://localhost:8091。

localhost 表示发起访问的设备自身。读者在电脑或手机上打开这样的链接时，请求会指向自己的设备，无法代表部署在云服务器上的博客。

外部访问地址用于告诉 Halo：生成绝对链接时，应使用哪个网站地址。配置错误可能影响文章规范链接、RSS、站点地图等内容，首页能打开也不能证明这些链接正确。

我先修改了 1Panel 中 Halo 应用的外部访问地址参数，随后又检查 Halo 后台保存的设置。在这次安装中，只修改应用参数后，部分公开链接仍没有更新，因此还通过 Halo 后台“外部访问地址”的编辑入口进行了修正。

对于其他部署，建议检查这两处配置，并以实际页面生成的链接为准。外部地址应填写自己使用的 HTTPS 主域名，例如：

https://www.example.com

本文中的 example.com 仅用于演示，操作时需要替换为自己的域名。

修改后，我核对了：

  • 文章页面的规范链接。
  • RSS 中的站点和文章链接。
  • 站点地图中的网址。
  • robots.txt 中声明的站点地图地址。

这些链接都应使用正确的主域名，不再指向 localhost 或旧地址。需要注意，填写外部访问地址不会自动申请证书，也不会替代反向代理配置。

四、给小内存服务器留出缓冲

这次使用的是 2 核、标称 4 GB 内存的云服务器，系统可见内存约 3.3 GiB。除了博客，还计划试运行 RAG 项目，因此我给服务器增加了 2 GiB 的 Swap，并配置开机自动启用。

Swap 使用磁盘空间，在部分内存压力场景下可以提供缓冲，但速度明显低于内存。它不能替代足够的物理内存，也不能保证所有内存不足的情况都不会导致进程终止。

判断服务器是否需要升级时，我更关注持续运行的表现：

  • 可用内存是否长期偏低。
  • Swap 是否持续频繁换入换出。
  • 网站响应时间是否明显增加。
  • 是否出现进程退出或请求失败。

少量、偶尔使用 Swap，不必立即得出“服务器不够用”的结论；持续的内存压力则需要检查进程占用、降低负载或增加资源。后续压测也应逐步提高并发，同时观察 CPU、内存、响应时间和错误率。

五、替换默认内容

技术配置之外，博客还需要告诉读者“这里主要写什么”。我替换了默认欢迎文章和关于页，补充个人介绍、学习方向与项目入口，并检查电脑和手机上的阅读效果。

目前主要关注 Agent 后端开发与 RAG 应用实践。相关实践放在扫地机器人智能客服项目中，博客则用于记录部署、学习和问题排查过程。

六、基础部署的验收清单

完成以上调整后，我用下面几项检查确认结果：

  • HTTPS 域名访问正常。
  • Halo 的应用端口仅供服务器本机访问，公网直连已关闭。
  • 文章规范链接、RSS 和站点地图使用正确的主域名。
  • Swap 已启用，并设置为开机自动启用。
  • 默认内容已替换，电脑和手机端页面能够正常阅读。

后续又完成了分类导航、双域名 HTTPS、域名跳转，以及服务器和电脑两端的备份安排。这些内容在《博客搭建记录（二）：导航整理、双域名 HTTPS 与备份》中继续说明。

写在最后

这次整理让我对应用端口、反向代理、HTTPS 和链接生成之间的关系有了更清楚的理解。每次改完配置，我都尽量从实际访问结果确认它是否生效。

把配置背后的原因和验证方式一起记录下来，后续维护时会更容易判断问题出在哪里，也方便使用相似部署方式的读者参考。