14 KiB
MaiBot WebUI TLS/SSL 配置指南
本文档基于当前仓库实现整理,目标是让 WebUI 通过 HTTPS 提供访问能力,并保持登录、Cookie、WebSocket 和 Let's Encrypt 续期正常工作。
1. 先说结论
MaiBot 当前最合适的 TLS/SSL 方案是让反向代理终止 HTTPS,然后把请求转发到 WebUI 的 HTTP 服务。
推荐顺序如下:
- Caddy 反向代理 + Let's Encrypt 自动签发与续期
- 宝塔面板反向代理 + Let's Encrypt
- 1Panel 反向代理 + Let's Encrypt
- 不建议直接让 WebUI 自己监听 HTTPS,当前仓库没有现成的 WebUI 原生 TLS 配置入口
2. 当前项目的部署特征
当前仓库里,WebUI 的前后端是同源部署思路:
- 后端是独立的 FastAPI WebUI 服务,默认监听 127.0.0.1:8001
- 前端构建产物由这个 FastAPI 服务直接托管
- 浏览器生产模式下默认按同源访问 API
- 页面如果通过 HTTPS 打开,前端会自动把 WebSocket 协议切到 WSS
这意味着最稳妥的方式是:
- MaiBot WebUI 继续在本机或容器内网跑 HTTP
- 让 Caddy、宝塔 Nginx 或 1Panel OpenResty 对外暴露 443
- 由代理把所有请求和 WebSocket 都转发到 WebUI
3. 配置前的准备工作
正式启用 HTTPS 之前,先确认下面几项:
- 已准备一个已经解析到服务器公网 IP 的域名,例如 maibot.example.com
- 80 和 443 端口可以从公网访问
- 服务器没有其他程序占用 80 和 443
- WebUI 可以在本机正常打开,例如 http://127.0.0.1:8001
如果采用 Docker Compose 部署,还要确认:
- 容器已经能正常启动
- 根目录的 docker-compose.yml 当前可以正常运行
- HTTPS 入口将统一由反向代理接管
4. WebUI 自身配置
无论采用 Caddy、宝塔还是 1Panel,都建议先把 WebUI 配成生产模式。
修改 config/bot_config.toml 里的 webui 配置段,建议值如下:
[webui]
enabled = true
mode = "production"
anti_crawler_mode = "loose"
allowed_ips = "127.0.0.1"
trusted_proxies = "127.0.0.1"
trust_xff = true
secure_cookie = true
enable_paragraph_content = false
各项的意义:
- mode = "production" 让 WebUI 按生产环境运行,并倾向启用更严格的安全行为。
- secure_cookie = true 让登录 Cookie 仅在 HTTPS 下传输。
- trust_xff = true 允许从反向代理传入的 X-Forwarded-For 获取真实来源 IP。
- trusted_proxies = "127.0.0.1" 表示只有来自本机反向代理的 X-Forwarded-For 才被信任。
注意:
- 如果使用 Docker 内部的反向代理,trusted_proxies 不应固定写 127.0.0.1,而应填写反向代理容器到 MaiBot 的实际来源地址或所在网段。
- 如果尚未切换到 HTTPS,不要提前开启 secure_cookie = true,否则可能出现登录 Cookie 不生效或握手异常的问题。
5. 直接部署方式如何配置 TLS/SSL
这里的“直接部署”指的是:
- MaiBot 直接跑在宿主机上
- WebUI 监听本机 127.0.0.1:8001
- 宿主机安装 Caddy
- 由 Caddy 负责申请证书和 HTTPS 反代
5.1 推荐的网络结构
浏览器
-> https://maibot.example.com
-> Caddy :443
-> 127.0.0.1:8001
-> MaiBot WebUI
5.2 宿主机直装 Caddy
以 Debian 或 Ubuntu 为例,参考步骤如下:
sudo apt update
sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https curl
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo apt update
sudo apt install -y caddy
macOS Homebrew 参考:
brew install caddy
5.3 Caddyfile 示例
仓库已提供两份可复制的示例文件,请按部署方式选择:
- 非 Docker 宿主机部署:dashboard/docs/Caddyfile.host.example
- Docker Compose 部署:dashboard/docs/Caddyfile.docker.example
宿主机直连部署可使用以下最简配置:
maibot.example.com {
reverse_proxy 127.0.0.1:8001
}
如需显式添加安全头,可以使用增强版:
maibot.example.com {
encode zstd gzip
header {
Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
X-Content-Type-Options "nosniff"
X-Frame-Options "SAMEORIGIN"
Referrer-Policy "strict-origin-when-cross-origin"
}
reverse_proxy 127.0.0.1:8001
}
非 Docker 直接部署建议直接从 dashboard/docs/Caddyfile.host.example 开始修改域名并投入使用。
5.4 HSTS 是否启用
可以启用,而且当前推荐由反向代理统一下发 HSTS 响应头,而不是让 WebUI 自己在 FastAPI 层单独处理。
当前仓库提供的两份 Caddy 示例都已经带了 HSTS:
- dashboard/docs/Caddyfile.host.example
- dashboard/docs/Caddyfile.docker.example
示例配置中的这一行就是 HSTS:
Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
这行配置的含义如下:
- max-age=31536000 浏览器在 1 年内记住该站点只能使用 HTTPS。
- includeSubDomains 所有子域名也必须强制使用 HTTPS。
- preload 表示该域名计划提交到浏览器内置的 HSTS preload 列表。
HSTS 建议按下面的节奏启用:
- 初次上线 HTTPS 时,可以先使用不带 preload 的版本。
- 确认主域名和所有相关子域名都长期稳定支持 HTTPS 后,再考虑是否加入 preload。
- 如果无法确认所有子域名都支持 HTTPS,不要轻易保留 includeSubDomains。
更稳妥的起步版本如下:
Strict-Transport-Security "max-age=31536000"
如果所有子域名都已经稳定支持 HTTPS,可以使用:
Strict-Transport-Security "max-age=31536000; includeSubDomains"
只有在满足下面条件时,才建议使用 preload:
- 主域名始终可通过 HTTPS 访问。
- 所有子域名都始终可通过 HTTPS 访问。
- 已明确理解 preload 是长期约束,而不是临时开关。
HSTS 的风险点主要有这些:
- 一旦浏览器记住该域名只能用 HTTPS,后续临时切回 HTTP 会直接失败。
- 如果开启 includeSubDomains,而某个子域名并没有部署 HTTPS,该子域名会被浏览器直接拦截。
- 如果开启 preload 并提交到浏览器列表,撤销成本会比较高,生效和移除都不是即时的。
因此,本文档里的 Caddy 示例更适合作为“完整增强版示例”参考。首次部署时,建议先按实际域名情况,将 HSTS 调整成更合适的版本后再正式上线。
5.5 启动与验证
sudo caddy validate --config /etc/caddy/Caddyfile
sudo systemctl restart caddy
sudo systemctl status caddy
检查项:
- 浏览器访问 https://maibot.example.com 能正常打开登录页
- 登录后 Cookie 正常写入
- 日志页和聊天页的 WebSocket 可以正常连接
- 证书是 Let's Encrypt 或所选颁发机构签发的有效证书
5.6 直接部署方式的 Let's Encrypt 申请与续期
Caddy 默认会自动处理证书签发和续期,前提如下:
- 域名已正确解析到服务器
- 80 和 443 可从公网访问
- 没有 CDN、WAF 或安全组拦截 ACME 验证请求
Caddy 的自动续期通常无需手工干预,只需确保:
- 保持 Caddy 常驻运行
- 不要阻断 80 和 443
- 定期关注 Caddy 日志是否存在 ACME 失败记录
常用检查命令:
sudo journalctl -u caddy -n 200 --no-pager
sudo journalctl -u caddy -f
如果续期失败,优先检查:
- 域名是否仍然解析到当前服务器
- 80 和 443 是否被防火墙、面板或云安全组拦截
- 是否存在另一个程序抢占了 80 或 443
6. 宝塔面板如何配置 SSL
宝塔适合已经习惯图形化管理 Nginx 站点的部署方式。思路仍然是:由宝塔的站点反向代理到 MaiBot WebUI。
6.1 推荐网络结构
浏览器
-> 宝塔站点 HTTPS
-> 宝塔 Nginx/OpenResty 反向代理
-> 127.0.0.1:8001
-> MaiBot WebUI
6.2 宝塔站点创建步骤
- 登录宝塔面板。
- 进入网站。
- 添加站点。
- 域名填写实际使用的 WebUI 域名,例如 maibot.example.com。
- PHP 版本可以选纯静态或关闭运行环境,重点是站点存在即可。
6.3 反向代理配置步骤
- 进入对应站点。
- 打开反向代理。
- 新增反向代理。
- 目标 URL 填写 http://127.0.0.1:8001。
- 发送域名通常保持目标域或原域名即可。
如果使用的是宝塔站点配置文件,也可以手动补这一段:
location / {
proxy_pass http://127.0.0.1:8001;
proxy_http_version 1.1;
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_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
}
如果宝塔环境没有现成的 connection_upgrade 变量,可以改成:
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
6.4 宝塔中申请 Let's Encrypt 证书
- 进入站点设置。
- 打开 SSL。
- 选择 Let's Encrypt。
- 勾选对应域名。
- 申请证书。
- 开启强制 HTTPS。
6.5 宝塔中续期证书
宝塔一般会自动续期,但仍然需要检查:
- 面板计划任务是否正常运行
- 80 端口是否在验证时可达
- 域名解析是否未被改动
建议定期查看:
- 宝塔站点 SSL 到期时间
- 宝塔计划任务执行日志
- 站点错误日志和 Nginx 错误日志
6.6 宝塔模式下 WebUI 配置建议
建议保持:
[webui]
mode = "production"
secure_cookie = true
trust_xff = true
trusted_proxies = "127.0.0.1"
如果宝塔和 MaiBot 不在同一台机器上,trusted_proxies 需要换成宝塔所在服务器到 MaiBot 的来源地址。
7. 1Panel 如何配置 SSL
1Panel 的逻辑和宝塔类似,本质上也是由面板管理的网关或站点反向代理到 MaiBot WebUI。
7.1 推荐网络结构
浏览器
-> 1Panel 网站/反向代理 HTTPS
-> OpenResty/Nginx 反向代理
-> 127.0.0.1:8001 或 core:8001
-> MaiBot WebUI
7.2 1Panel 配置步骤
- 登录 1Panel。
- 打开网站或反向代理管理。
- 新建网站,域名填 maibot.example.com。
- 添加反向代理规则,目标地址指向 http://127.0.0.1:8001。
- 开启 WebSocket 支持。
- 保存并重载站点配置。
如果是在 Docker 环境里通过 1Panel 管理容器,目标地址也可以填写容器服务名,例如 http://core:8001,但前提是 1Panel 管理的网关容器与 MaiBot 在同一个 Docker 网络内。
7.3 在 1Panel 申请 Let's Encrypt 证书
- 打开证书管理。
- 选择 Let's Encrypt。
- 绑定域名。
- 选择 HTTP-01 或面板默认验证方式。
- 完成签发后,把证书绑定到对应网站。
- 启用 HTTPS。
7.4 1Panel 中续期证书
1Panel 通常会自动续期,但需要确认:
- 自动续期开关处于启用状态
- 面板的任务调度正常
- 80 和 443 端口验证时不被拦截
- 域名始终指向正确服务器
7.5 1Panel 模式下的反代头
请确认面板生成的配置会向后端传递:
- Host
- X-Real-IP
- X-Forwarded-For
- X-Forwarded-Proto
- Upgrade
- Connection
缺少 X-Forwarded-Proto 时,WebUI 可能误判为 HTTP,进而影响 secure cookie 与登录行为。
8. Docker Compose 下如何配置 TLS/SSL
根目录 docker-compose.yml 已补充默认注释的 Caddy 示例块,用于容器化部署时启用 HTTPS。
Docker 模式下请使用:dashboard/docs/Caddyfile.docker.example
非 Docker 宿主机模式下请使用:dashboard/docs/Caddyfile.host.example
详细步骤请看另一份专项文档:dashboard/docs/webui-tls-ssl-compose.md
这里只先给结论:
- 启用 Caddy 反向代理时,不应再把 core 的 8001 直接映射到公网
- 应由 Caddy 容器暴露 80 和 443
- Caddy 通过容器网络访问 core:8001
9. 常见问题
9.1 开了 HTTPS 后无法登录
优先检查:
- webui.secure_cookie 是否在 HTTPS 环境下开启
- 代理是否正确传递 X-Forwarded-Proto
- 浏览器访问的是否确实是 https:// 域名而不是 http:// IP
- Cookie 是否被浏览器策略、扩展或跨站配置拦截
9.2 页面能打开,但日志页或聊天页 WebSocket 失败
优先检查:
- 代理是否支持 WebSocket Upgrade
- 是否使用了 HTTPS 页面去连接 ws:// 明文地址
- Caddy、Nginx、宝塔、1Panel 是否有单独的 WebSocket 开关或升级头配置
9.3 Let's Encrypt 申请失败
优先检查:
- 域名解析是否正确
- 80 端口是否可访问
- 是否开启了 CDN 代理但没有正确放通验证流量
- 面板或防火墙是否拦截 ACME 请求
9.4 是否能直接用 IP 申请 Let's Encrypt
不能。Let's Encrypt 只为域名签发公开可信证书,不为裸 IP 签发。
9.5 内网环境如何测试 HTTPS
可以使用 Caddy 的 tls internal 进行测试,但客户端必须手工信任内部 CA 根证书。正式对外服务仍建议使用有效公网域名和 Let's Encrypt。
10. 推荐实践
普通 Linux 服务器部署的推荐顺序如下:
- 宿主机直装 Caddy
- WebUI 绑定 127.0.0.1:8001
- 域名指向服务器
- 用 Caddy 反代并自动管理 Let's Encrypt
如果已经使用面板管理服务器,则:
- 宝塔用户直接用宝塔反向代理和 Let's Encrypt
- 1Panel 用户直接用 1Panel 网站或网关反代和证书管理
如果采用 Docker Compose 部署,则:
- 使用根目录 compose 中提供的默认注释 Caddy 示例块
- 注释掉 core 服务里直接暴露 WebUI 的端口映射
- 由 Caddy 统一对外暴露 80 和 443