Ubuntu Caddy 反向代理教程：自动 HTTPS、部署与排错
从官方软件源安装 Caddy，在 Ubuntu VPS 上配置反向代理和自动 HTTPS，覆盖 DNS、端口、防火墙、配置校验、平滑重载、日志与常见故障排查。
Ubuntu Caddy 反向代理教程
Caddy 适合在 Ubuntu VPS 上承担网站入口：它可以把公网请求转发给运行在本机端口的 Node.js、Go、Python 或容器应用，并在满足条件时自动申请和续期 HTTPS 证书。与手工组合 Web 服务器和证书定时任务相比，Caddyfile 配置较短，但自动化并不意味着无需理解 DNS、端口、防火墙和后端监听地址。
这篇 Ubuntu Caddy 反向代理教程依据 Caddy 官方安装、反向代理和 Automatic HTTPS 文档编写。示例假设域名为 app.example.com，后端服务监听 127.0.0.1:3000。操作前请把示例域名替换成自己的域名，并保留一条可用的 SSH 会话，避免防火墙变更后失去连接。
部署前准备
首先确认域名的 A 或 AAAA 记录指向 VPS 公网地址。公网证书通常要求 80 和 443 端口能够从互联网到达 Caddy，云平台安全组与 Ubuntu 本机防火墙都要允许这两个端口。后端应用应先在本机正常运行：
curl -I http://127.0.0.1:3000
ss -lntp | grep ':3000'如果 curl 无法访问，先修复应用，不要把问题交给反向代理。生产应用建议只监听 127.0.0.1 或 Unix socket，避免绕过 Caddy 直接暴露业务端口。服务器基础安全可参考 Ubuntu VPS 自动安全更新教程，先配置补丁、备份和最小权限。
使用官方软件源安装 Caddy
官方文档为 Debian、Ubuntu 和 Raspbian 提供稳定软件源。先安装密钥和 HTTPS 仓库所需组件，再添加官方源：
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 chmod o+r /usr/share/keyrings/caddy-stable-archive-keyring.gpg
sudo apt update
sudo apt install caddy该软件包会安装 systemd 服务。用 systemctl status caddy 查看状态，用 caddy version 确认命令可用。不要从陌生的一键脚本复制二进制，也不要在没有备份的情况下覆盖 /etc/caddy/Caddyfile。
编写最小反向代理配置
编辑 /etc/caddy/Caddyfile：
app.example.com {
reverse_proxy 127.0.0.1:3000
}当站点地址是合格的公网域名、DNS 已指向服务器且 80/443 可达时，Caddy 默认启用自动 HTTPS：申请证书、续期证书并把 HTTP 重定向到 HTTPS。无需额外写证书路径，也不要同时启动另一个占用相同端口的 Web 服务。
先格式化并校验配置，再平滑重载：
sudo caddy fmt --overwrite /etc/caddy/Caddyfile
sudo caddy validate --config /etc/caddy/Caddyfile
sudo systemctl reload caddy校验失败时不要重启服务。reload 会让运行中的 Caddy 接收新配置，适合减少配置更新造成的中断。部署多个站点时，为每个域名增加独立站点块，而不是复制多个 Caddy 进程。
传递真实客户端信息
Caddy 的反向代理会处理常见转发头。应用框架若需要识别真实来源和 HTTPS 状态，还应正确设置“可信代理”，只信任来自本机 Caddy 的转发信息。不要让应用无条件信任互联网客户端自行提交的 X-Forwarded-For，否则访问控制和日志可能被伪造。
后端如果使用 HTTPS 地址，证书必须被 Caddy 所在系统信任。官方文档还说明，对于 HTTPS upstream，Host 与 TLS ServerName 的关系需要正确处理；较新版本会自动处理常见情形，但旧版本或特殊代理目标仍应核对当前文档。普通单机部署优先使用 Caddy 到本机应用的 HTTP 连接，并限制它只在回环地址监听。
防火墙和权限设置
使用 UFW 时，可以先确认 SSH 规则存在，再开放 Web 端口：
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw status verbose不要开放应用的 3000 端口。若云厂商还有安全组，需要在控制台同步放行 80/443。Caddy 软件包以专用用户运行，静态文件目录必须允许该用户读取，但不应为了图省事把整个站点设置为全局可写。Linux 权限和服务管理的基础概念可继续阅读 Linux 运维入门教程。
验证 HTTPS 与代理链路
在 DNS 生效后，从外部网络执行：
curl -I https://app.example.com再查看服务日志：
sudo journalctl -u caddy --since '15 minutes ago' --no-pager浏览器返回 502 通常表示 Caddy 已接到请求，但无法访问后端。此时检查后端进程、监听地址和端口。证书申请失败则重点检查 DNS 是否正确、80/443 是否被拦截、域名是否经过不兼容的代理，以及系统时间是否准确。反复重启不会修复错误的 DNS。
增加压缩与请求限制时的边界
可以在站点块中加入 encode zstd gzip 提供响应压缩，但限流、身份验证和 WebSocket 策略应根据应用需求单独设计。Caddy 支持 WebSocket 代理，通常不需要手写 Upgrade 头。上传大文件时，应同时检查应用、反向代理和上游存储的限制，避免只修改一层。
配置完成后，应把 Caddyfile、应用配置和恢复步骤纳入版本化备份，但不要提交证书私钥或环境变量。上线前测试首页、登录、上传、长连接和错误页；上线后监控 Caddy 与应用两个服务，而不是只检查域名能否打开。
运维检查清单
每次修改都先执行 caddy validate，通过后再 reload；定期查看 systemd 状态和证书相关日志；确认 DNS 变更有记录；升级 Caddy 后复核官方发行说明；把应用健康检查与外部监控分开配置。Caddy 能自动处理证书生命周期，但域名续费、DNS 正确性、端口可达和应用本身仍由管理员负责。
完成这些步骤后，Ubuntu VPS 就拥有了清晰的入口层：公网只访问 Caddy，业务应用留在本机端口，HTTPS 证书由 Caddy 自动管理。这个结构容易审计，也便于日后把后端迁移到容器或另一台服务器。
