带 tls 块的集群改用 TLS 1.3 拨号端点，而不是明文。它与监听用的是同一个键，只是立场不同：这里发起，那里终结。

"clusters": {
    "api": {
        "endpoints": ["10.0.0.1:8443"],
        "tls": {
            "server_name": "api.internal.example",
            "ca_file": "/etc/zgix/origin-ca.pem",
            "client_cert": "/etc/zgix/zgix.pem",
            "client_key": "/etc/zgix/zgix.key"
        }
    }
}

字段	必填	含义
`server_name`	是	发给源站的 SNI 名字，也是其证书必须匹配的名字。绝不从端点推断：`10.0.0.1:8443` 是地址，不是身份。
`ca_file`	`verify` 为真时	信任锚的 PEM 束。
`client_cert`	与 `client_key` 成对	PEM 客户端证书链，叶子在前，源站要求客户端证书（mTLS）时出示。
`client_key`	与 `client_cert` 成对	客户端证书链的 PEM 私钥。
`verify`	否；默认 `true`	对照 `ca_file` 校验源站证书链，并按 `server_name` 校验叶子（RFC 9525）。

信任锚恰好是 ca_file；没有系统 CA 存储。想用宿主机的 CA 束就显式点名它。

verify: false 仍然加密，但不做任何认证 —— 能截获 TCP 流的任何对端都会被接受，ca_file 即使存在也被忽略。只应在另一条层完成源站认证的受控网络上使用；它在公网链路上永远不等于”什么都不验”。 server_name 依然必填，依然作为 SNI 发送。

文件与重载

这个块点名的文件在启动时读取一次：文件缺失或不可用会让进程带着点名路径的错误退出、发生在占用端口之前，而不是在流量下失败。 SIGHUP 不会重读它们 —— 它只轮转监听证书 —— 因此改集群的 CA 或客户端证书对需要重启。客户端私钥遵循监听侧的规矩（ECDSA P-256/ P-384），因为两个方向共用一套凭据加载器，且握手跑在事件循环上。

这条腿的行为

TLS 上游连接与明文一样停驻和复用，复用时免握手。闲置时被源站悄悄关掉的会话在首次使用时被发现，这种早期失败消耗那次免费重放：请求头在新会话的密钥下重新加密。一旦泵过任何正文块，这次尝试就不再可重建，失败送达客户端。
TLS 集群上的 http 健康检查完成自己的握手并加密探测；tcp 检查仍是普通 connect —— 它只要 SYN/ACK。
Upgrade 可以跨越这一跳：隧道转发两端各自独立加解密，半关闭在写半关闭之前以 close_notify 通告。隧道池的后果见 WebSocket。
请求正文在通常的上限和帧规则下转发：声明的超限正文仍是 413， chunked 正文流过与明文源站相同的转发纪律。

什么到不了 TLS 集群

l4 监听路由到 tls 集群在加载时被拒绝：转发是透明的、永远不发起 TLS，源站会收到客户端字节而前面没有握手。这个拒绝发生在加载时而不是尽力而为 —— 一份不可能言如其意的配置会带着点名规则的错误停下。