TLS 1.3 不支持动态按需请求客户端证书，因协议规定 CertificateRequest 必须在初始握手阶段固定发出；替代方案包括降级 TLS 1.2 分路径配置或应用层透传证书信息鉴权。
在 Nginx 中，TLS 1.3 下**不支持动态按需请求客户端证书**（即无法像 TLS 1.2 那样在握手过程中根据路径、Header 或后端响应临时触发证书验证）。这是由 TLS 1.3 协议本身的设计决定的，不是 Nginx 的配置限制。
TLS 1.3 协议层已移除“延迟证书请求”能力
TLS 1.3 将证书请求（CertificateRequest）消息**固定在 ServerHello 之后、密钥交换完成前**发送，且必须在初始握手阶段就明确决定是否要求客户端证书。这意味着：
- 服务器必须在握手开始时就确定是否启用客户端认证，无法根据 request_uri、$args 或 upstream 响应等运行时条件动态决策；
- 没有类似 TLS 1.2 中的 “post-handshake auth”（PHHA）机制供 Nginx 利用（RFC 8446 明确不支持 PHHA）；
- ssl_verify_client optional_no_ca 或 on 等指令的作用范围是整个 server 或 location 块的静态策略，不是运行时逻辑分支。
可行的替代方案：用 TLS 1.2 兼容通道 + 条件路由实现“类按需”效果
若业务强依赖“仅对特定 API 路径验客户端证书”，可采用混合协议策略：
- 为需要双向认证的路径（如
/api/v1/admin）单独配置一个监听 443 的server块或location，并强制使用 TLS 1.2（通过ssl_protocols TLSv1.2）； - 在该块中启用
ssl_verify_client on和ssl_client_certificate； - 主站仍使用
TLSv1.2 TLSv1.3提供高性能单向 HTTPS，仅管理接口走 TLS 1.2 双向通道； - 注意：浏览器对 TLS 1.2 + client cert 的兼容性更好（如 Safari/iOS 支持稳定），而 TLS 1.3 下 client cert 实际部署案例极少，主流客户端（Chrome/Firefox）虽支持但行为未完全标准化。
进阶思路：应用层代理 + 外部鉴权服务
更现代的做法是剥离 TLS 层的认证职责：
- Nginx 终止 TLS（支持 TLS 1.3），不处理 client cert；
- 将客户端证书信息通过
ssl_client_cert和ssl_client_fingerprint透传给后端（如用proxy_set_header X-Client-Cert $ssl_client_cert;）； - 由后端服务（如 Go/Python 微服务）根据业务逻辑判断是否需要校验证书，并执行 OCSP 检查、白名单比对等；
- 这样既保留 TLS 1.3 的性能与安全性，又获得完全动态的鉴权控制能力。
特别提醒：不要尝试伪造“动态”行为
以下常见误区会导致失败或安全隐患：
- 在同一个
server块内混用ssl_verify_client optional和if ($request_uri ~ ^/admin) { ... ssl_verify_client on; }—— Nginx 不允许在 if 中修改 SSL 握手参数，语法会报错或静默忽略； - 试图用
auth_request模块拦截后再触发证书请求 —— TLS 握手早已完成，此时再要证书已无意义； - 依赖 OpenSSL 3.x 的某些实验性 post-handshake 扩展 —— Nginx 当前（截至 1.25.x）未提供对应配置接口，且 RFC 已明确不纳入标准。
本质上，TLS 1.3 的简洁性牺牲了部分灵活性。真正需要细粒度客户端证书控制时，推荐把认证逻辑下沉到应用层，让 Nginx 专注做好高性能、安全的 TLS 终止。
