SSLProxyVerify require 必须搭配 SSLProxyCACertificateFile 才生效，仅设前者无效；它只校验证书链有效性，主机名匹配由 SSLProxyCheckPeerName on 负责，按 RFC 6125 优先校验 SAN。
SSLProxyVerify require 不是开关，而是一条信任链启动指令——漏掉 CA 证书或路径权限不对，它就直接报 500 或 Connection reset，日志里几乎不提示缺啥。
SSLProxyVerify require 必须搭配 SSLProxyCACertificateFile 才生效
只写 SSLProxyVerify require 没用。Apache 不会自动读系统 CA 信任库（比如 /etc/ssl/certs/ca-certificates.crt），必须显式告诉它“信谁”：
-
SSLProxyCACertificateFile指向一个 PEM 文件，里面是后端服务所用 CA 的根证书（不是你自己的服务器证书！） - 若后端用私有 CA（如企业内部 PKI），这个文件必须包含该 CA 的证书；否则握手失败
- 路径需对 Apache 进程用户（如
www-data或apache）可读：ls -l /path/to/ca-bundle.pem看权限，SELinux 上下文也要检查（RHEL/CentOS 常见坑）
SSLProxyCheckPeerName on 是主机名校验的实际执行者
SSLProxyVerify require 只管证书链是否有效（签名、有效期、吊销），不管证书是不是发给目标域名的。真正做“后端身份匹配”的是 SSLProxyCheckPeerName on：
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
- 它按 RFC 6125 规则优先检查证书的
Subject Alternative Name (SAN)，不是 CN 字段 - 例如
ProxyPass /api https://svc.internal/，后端证书 SAN 中必须有DNS:svc.internal，仅CN=svc.internal无效 -
SSLProxyCheckPeerCN在 Apache 2.4.12+ 已彻底移除，写它会导致启动报错：Invalid command 'SSLProxyCheckPeerCN'
调试时别猜，用 openssl s_client 模拟 Apache 握手
遇到 SSL handshake failed 或 Peer certificate does not match hostname，直接复现验证链：
- 运行：
openssl s_client -connect svc.internal:443 -CAfile /path/to/your/ca-bundle.pem - 看输出里
Verify return code是否为 0；如果不是，错误码对应具体问题（如 2 = unable to get issuer certificate） - 同时检查
subject和X509v3 Subject Alternative Name内容是否匹配 ProxyPass 目标域名 - 时间偏差也会导致失败：
SSLProxyCheckPeerExpire on（默认开启）要求后端系统时间误差 ≤5 分钟
最容易被忽略的是：CA 证书文件路径正确但 Apache 进程无权读取，或者后端证书 SAN 缺失且运维误以为 CN 足够——这两点占实际生产环境失败案例的八成以上。
