Caddy Docker Proxy 中同一域名多服务路由与客户端证书认证实践

在基于 Docker Swarm 的微服务架构中，使用 Caddy 作为反向代理时，开发者常会遇到两个典型场景：如何为同一域名下的不同路径配置多个后端服务，以及如何实现细粒度的 TLS 客户端证书认证。本文将深入探讨这些技术要点的实现方案与限制。

一、多路径服务路由方案

当需要在 example.com 域名下通过不同路径（如 /api、/ide）路由到不同服务时，可通过以下两种方式实现：

1. 服务独立标签配置

# Web服务配置（处理根路径）
labels:
  caddy: "example.com"
  caddy.reverse_proxy: "{{upstreams 80}}"

# API服务配置
labels:
  caddy: "example.com"
  caddy.route: "/api/*"
  caddy.route.1_uri: "strip_prefix /api"
  caddy.route.1_reverse_proxy: "{{upstreams 8080}}"

2. 替代 upstream 语法

Caddy Docker Proxy 支持直接使用服务名称进行路由：

caddy.reverse_proxy: "api-service:8080"

常见问题排查：

• 路由循环通常因未正确处理路径前缀导致，建议使用 strip_prefix 中间件
• 路径匹配优先级需注意，更具体的路径应配置在前

二、TLS 客户端证书认证限制

需要特别注意：客户端证书认证发生在 TLS 握手阶段，早于 HTTP 路由处理。这意味着：

1. 无法针对特定路径启用客户端证书认证
2. 全局启用后会影响所有子路径服务

变通方案

可采用以下两种方式实现近似效果：

1. 为需要认证的服务使用独立子域名（推荐方案）
2. 配置 verify_if_given 模式，配合表达式匹配器动态检查证书

三、最佳实践建议

1. 域名规划：对安全性要求不同的服务使用不同子域名
2. 配置简化：优先使用服务名称而非 upstream 占位符
3. 路径处理：始终为子路径服务配置 strip_prefix 中间件
4. 认证分离：将需要客户端证书的服务部署为独立 stack

通过合理规划服务路由和认证策略，可以构建既安全又易于维护的容器化应用架构。在实际部署时，建议先进行非生产环境测试，确保路由和认证行为符合预期。