Healthchecks项目多域名分离配置实践

背景介绍

在Healthchecks监控系统中，通常需要同时处理两种类型的网络请求：管理界面的Web访问和监控节点的ping请求。许多用户最初会使用单一域名同时承载这两种流量，但随着业务发展，往往需要将两者分离到不同域名。

需求场景

某用户原使用old.domain.tld同时作为Web管理界面和ping请求的入口，现希望进行如下调整：

• 新域名new.domain.tld专用于Web管理界面
• 旧域名old.domain.tld继续处理ping请求（保持向后兼容）

配置方案

环境变量配置

在.env.production文件中设置关键参数：

ALLOWED_HOSTS=new.domain.tld,old.domain.tld
SITE_ROOT=https://new.domain.tld
PING_ENDPOINT=https://old.domain.tld/ping/

Caddy服务器配置

初始配置尝试：

old.domain.tld {
  reverse_proxy /ping/* healthchecks_web:8000
  redir https://new.domain.tld{uri}
}

new.domain.tld {
  reverse_proxy healthchecks_web:8000
}

问题分析

上述配置会导致ping请求失效，原因是Caddy服务器的指令执行顺序规则：

1. Caddy内部有预定义的指令优先级
2. redir指令会先于reverse_proxy执行
3. 导致所有请求（包括ping）都被重定向

解决方案

通过条件匹配实现精确路由：

old.domain.tld {
  @notPings not path /ping/*
  redir @notPings https://new.domain.tld{uri}
  reverse_proxy healthchecks_web:8000
}

技术要点

1. 条件匹配：使用@notPings定义非ping请求的匹配规则
2. 精确重定向：仅对非ping路径的请求执行重定向
3. 代理保留：保持对/ping/路径的代理转发

最佳实践建议

1. 域名分离时考虑HTTPS证书的覆盖范围
2. 保留旧域名时要确保DNS记录的TTL设置合理
3. 监控日志确认流量分流是否正常
4. 对于大规模部署，建议逐步迁移而非一次性切换

总结

通过理解Caddy服务器的指令处理机制，我们可以实现Healthchecks系统的多域名精细化管理。这种配置方式既保持了现有监控脚本的兼容性，又为管理界面提供了独立的访问入口，是系统架构演进时的有效过渡方案。