最近我给自己的服务器安装了 1Panel 面板。之前服务器上的服务基本都是靠命令行、Docker Compose、Nginx 配置文件来维护，虽然灵活，但时间久了以后，服务越来越多，配置也越来越分散。比如博客主站、Umami 访问统计、Uptime Kuma 状态监控、Notion Stories、一些子域名服务，全都需要自己记住目录、端口、反向代理规则和证书位置。
这次安装 1Panel，主要目的不是为了“偷懒”，而是希望把服务器管理这件事变得更直观、更统一，也方便后续迁移和维护。
1Panel 是什么？
1Panel 是一个开源的 Linux 服务器运维管理面板。简单理解，它就是给服务器加了一个可视化后台，让原本需要用命令行完成的操作，可以通过网页界面来管理。
对于个人站长来说，1Panel 最直接的价值是：它把服务器上的常见管理能力集中到了一起。
比如：
管理网站
管理反向代理
管理 SSL 证书
管理 Docker 容器
管理数据库
查看服务器状态
配置防火墙
管理计划任务
查看日志
以前如果要改一个网站反代配置，可能要登录服务器，找到 Nginx 配置文件，手动修改，然后执行 nginx -t 和 systemctl reload nginx。装了 1Panel 以后，这些操作可以尽量放到面板里统一完成。
当然，面板不是万能的。它本质上还是在帮我们管理服务器上的配置、容器和服务。真正重要的，还是要理解它背后改了什么。
为什么我需要一个面板？
我的服务器上不只是一个博客。
除了主站 lovexfan.com，我还部署了不少围绕个人网站使用的小服务，比如：
Halo：个人博客系统
Umami：网站访问统计
Uptime Kuma：网站在线状态监控
Notion Stories：展示 Notion 内容的轻量服务
OpenWebUI 等其它工具服务
一些通过子域名访问的小项目
服务一多以后，最大的问题不是“能不能跑起来”，而是“能不能长期稳定维护”。
比如我需要知道：
哪个服务跑在哪个端口？
哪个域名反代到哪个服务？
哪个证书快过期了？
哪些端口暴露在公网？
哪些服务是 Docker 容器？
以后迁移服务器时，哪些配置要一起带走？
这些东西如果全部靠脑子记，时间久了一定会乱。1Panel 的作用，就是把这些分散的信息尽量收拢到一个统一的管理入口里。
1Panel 的主要功能
我目前最关注的是几个功能。
第一个是网站管理。
1Panel 可以创建网站、配置反向代理、管理站点目录和日志。对于个人博客来说，这个功能很实用。比如我可以把 lovexfan.com 作为主站，把 umami.lovexfan.com、uptime.lovexfan.com、design.lovexfan.com 等子域名作为不同服务入口。
第二个是容器管理。
我的很多服务都是 Docker 部署的，比如 Halo、Umami、Uptime Kuma 等。1Panel 可以直接查看容器状态、启动、停止、重启，也可以看到容器占用情况。这样排查问题的时候会方便很多。
第三个是证书管理。
个人网站基本都需要 HTTPS。之前证书主要由 Certbot 管理，证书文件放在 /etc/letsencrypt 下面。接入 1Panel 后，可以在面板里看到证书信息，也方便后续统一管理证书过期时间。
第四个是防火墙和端口管理。
这点对服务器安全很重要。服务器被公网访问时，应该尽量只暴露必要端口，比如 80、443 和受限制的 SSH 端口。其它内部服务，比如 Umami、Uptime Kuma、Halo 的容器端口，都应该只监听本机地址，再通过反向代理访问。
把域名反代托管到 OpenResty
安装 1Panel 之后，我把原来 Nginx 承担的反向代理能力，迁移到了 1Panel 自带的 OpenResty 上。
OpenResty 可以理解成增强版 Nginx。它兼容 Nginx 的大部分配置，同时也支持 Lua 扩展能力。1Panel 的网站管理功能底层就是通过 OpenResty 来承载的。
我的最终目标是：
用户访问：
https://lovexfan.com实际由 OpenResty 转发到服务器内部的 Halo 服务：
http://127.0.0.1:8090访问：
https://umami.lovexfan.com则转发到：
http://127.0.0.1:3010访问：
https://uptime.lovexfan.com则转发到：
http://127.0.0.1:3011这样做的好处是，所有服务都不需要直接暴露公网端口。公网只需要访问 OpenResty 的 80 和 443，再由 OpenResty 根据域名转发到对应的内部服务。
这也是反向代理最核心的作用：统一入口，内部转发。
迁移过程中遇到的问题
这次迁移不是完全无感的。
一开始我发现 1Panel 面板里只显示我手动创建的 lovexfan.com，其它子域名虽然 OpenResty 已经能访问，但面板里看不到。
原因是：1Panel 的网站列表不是自动扫描 OpenResty 配置文件生成的，而是读取它自己的数据库记录。也就是说，直接手动写 OpenResty 配置，服务可以生效，但 1Panel 面板并不知道这些站点的存在。
后来我把这些子域名也同步进了 1Panel 的网站记录中，让它们可以在面板里显示和管理。
另一个问题是 HTTPS。
刚开始面板里这些站点显示的是 HTTP，但实际上公网 HTTPS 是能访问的。这是因为 OpenResty 配置里已经写了证书路径，但 1Panel 数据库里还没有绑定对应的证书记录。后来我把现有 Let’s Encrypt 证书导入到 1Panel 的证书记录里，再把站点协议同步成 HTTPS，面板显示才和实际访问状态一致。
现在的结构
目前我的访问链路大概是这样：
用户浏览器
↓
Cloudflare
↓
服务器 80 / 443
↓
1Panel OpenResty
↓
内部服务端口例如：
lovexfan.com -> Halo
umami.lovexfan.com -> Umami
uptime.lovexfan.com -> Uptime Kuma
design.lovexfan.com -> 静态项目
sub2api.lovexfan.com -> Sub2API服务器内部服务基本都绑定在 127.0.0.1，不直接暴露公网。这样即使服务本身没有很强的安全防护，也不会直接暴露在互联网上。
使用 1Panel 后的感受
整体来说，1Panel 更适合“服务多了以后”的服务器管理。
如果服务器上只有一个博客，其实纯 Docker Compose + Nginx 也够用。但当服务越来越多，域名越来越多，证书和端口也越来越复杂时，有一个统一面板会舒服很多。
不过，面板不是替代技术理解的工具。尤其是涉及 Nginx/OpenResty、证书、反向代理、Docker 网络、防火墙这些东西时，还是要知道背后发生了什么。否则一旦面板配置和实际配置不同步，就很容易出现“页面显示正常，但实际访问异常”或者“实际能访问，但面板状态不对”的情况。
这次折腾下来，我对服务器结构也重新梳理了一遍。以后再迁移服务器，至少知道哪些服务、哪些域名、哪些证书、哪些反代规则是必须带走的。
总结
这次给服务器安装 1Panel，主要完成了三件事：
第一，把服务器管理从纯命令行逐步迁移到可视化面板。
第二，把博客和多个子域名服务统一托管到 OpenResty 反向代理下。
第三，把 HTTPS 证书和站点记录同步到 1Panel，方便后续统一查看和维护。
对我这种个人博客来说，1Panel 最大的价值不是“自动化一切”，而是让服务器上的东西变得更清楚。服务在哪里，端口是什么，域名怎么转发，证书什么时候过期，这些信息都能有一个更直观的管理入口。
后续我可能还会继续把备份、证书续期同步、服务器迁移文档这些东西整理好。毕竟个人网站不是一次性搭完就结束的东西，它更像是一个长期维护的小系统。