一台服务器托管多个网站：Caddy 反向代理与配置验证

多站点的关键是共享入口，不共享故障

一台服务器可以托管多个低流量网站，Caddy 根据 Host 把请求转到不同上游。真正风险是所有域名共享同一个代理配置：改新站时出现语法错误，旧站也可能受影响。因此每次变更都要经历备份、格式化、验证、重载和逐站检查。 开始前确认每个应用已经由 systemd 或容器稳定运行，且监听不同的本地端口。反向代理不能修复上游进程反复退出的问题。

DNS 和端口先满足证书签发条件

每个域名的 A/AAAA 记录应指向当前服务器，80/443 在云安全组和系统防火墙同时放行。若发布了 AAAA 记录，IPv6 也必须真正到达这台服务器；错误 AAAA 会造成部分用户和证书验证失败。 用 dig 或权威 DNS 面板核对，不要只看自己电脑的缓存。新记录仍在传播时可以先准备配置，但不要用频繁重启 Caddy 的方式催促证书。

一个域名对应一个清楚的站点块

www.example.com {
    encode zstd gzip
    reverse_proxy 127.0.0.1:3000
}

admin.example.com {
    encode zstd gzip
    reverse_proxy 127.0.0.1:3001
}

上游通常写主机与端口，不把 /api 之类路径塞进地址。需要按路径分流时使用 handle 或 handle_path，并明确是否移除前缀。应用本身应知道真实外部协议和主机，涉及登录回调时尤其要检查受信任代理与 forwarded headers 设置。

配置拆分以可验证为前提

站点多时可以用 import 拆成 /etc/caddy/sites/*.caddy，但要确保只有预期文件被加载，并让备份包含主文件与被引入文件。文件名写域名，避免 new、final、final2 这种无法判断是否生效的副本。 共享片段适合统一安全响应头或压缩规则，但不要过早抽象。不同站点的上传大小、缓存、WebSocket 和超时可能不同，强行共用会让局部需求影响全局。

每次修改都先验证再 reload

sudo cp /etc/caddy/Caddyfile /etc/caddy/Caddyfile.backup
sudo caddy fmt --overwrite /etc/caddy/Caddyfile
sudo caddy validate --config /etc/caddy/Caddyfile
sudo systemctl reload caddy
sudo systemctl status caddy --no-pager

validate 失败就停，不要 reload。日常配置更新使用 reload，而不是 stop 再 start；重载能让 Caddy 以新配置替换旧配置，减少连接中断。若拆分了文件，备份和验证范围也要覆盖它们。

逐站验证不能只看首页 200

为每个域名检查 HTTP 是否正确跳 HTTPS、证书主机名、首页、健康端点、静态资源、登录或表单接口。还要确认 A 站请求不会落到 B 站，未知 Host 不会意外展示管理后台。

curl -I http://www.example.com
curl -I https://www.example.com
curl -fsS https://www.example.com/api/health
journalctl -u caddy --since '10 minutes ago' --no-pager

502 时先直接 curl 本地上游，再看 Caddy 日志；TLS 错误则检查 DNS、80/443 和证书日志。已有的 Caddy 部署第一站 与 HTTPS 排错 可作为基础补充。

完成标准

每个域名只到达自己的本地端口，应用端口不对公网开放，配置可验证且使用 reload，上线后逐站通过 HTTPS、健康和关键功能检查。下一篇把同样的边界带入 Docker Compose 生产部署检查。