sslproxycheckpeercn 已彻底失效，应删除并改用 sslproxycheckpeername on 配合 sslproxyverify require 等配置，以基于 san 严格校验主机名并验证证书链。
SSLProxyCheckPeerCN 已彻底失效，不能用于防止中间人攻击，删掉它。
为什么 SSLProxyCheckPeerCN 不起作用
这个指令在 Apache 2.4.12+ 中默认禁用，2.4.26+ 彻底移除。如果你的配置里还留着 SSLProxyCheckPeerCN，Apache 启动会直接报错：Invalid command 'SSLProxyCheckPeerCN', perhaps misspelled or defined by a module not included in the server configuration。
根本原因不是“配置没写对”，而是它本身已被淘汰：仅校验 CN 字段既不安全（忽略 SAN、不支持通配符精确匹配），也不符合 RFC 6125 要求。现代 TLS 实践必须基于 Subject Alternative Name（SAN）验证主机名。
- 它无法识别证书里的
subjectAltName条目，而绝大多数正规 CA 签发的证书都只填 SAN，不填 CN - 即使 CN 匹配，只要 SAN 缺失或不匹配，实际连接仍会被
SSLProxyCheckPeerName拒绝 - 试图用
LoadModule回滚旧模块来“恢复”该指令，只会导致模块冲突或启动失败
真正有效的替代方案：SSLProxyCheckPeerName
从 Apache 2.4.8 开始，SSLProxyCheckPeerName on 是唯一受支持的主机名校验机制，它严格按 RFC 6125 执行：优先检查证书中的 subjectAltName（DNS 类型），无 SAN 时才回退到 CN（且不推荐依赖此行为）。
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
启用它必须配合其他必要配置，否则形同虚设：
-
SSLProxyEngine on—— 必须开启，否则连 HTTPS 连接都建不起来 -
SSLProxyCheckPeerName on—— 显式开启，**默认是 off**，不写就等于跳过校验 -
SSLProxyVerify require—— 强制验证证书链有效性（签名、有效期、吊销状态），和主机名校验是两件事，缺一不可 -
SSLProxyCACertificateFile /path/to/ca-bundle.crt—— 若后端用自签名或私有 CA 证书，必须指定可信根证书，否则SSLProxyVerify require会失败
示例片段：
SSLProxyEngine on SSLProxyCheckPeerName on SSLProxyVerify require SSLProxyVerifyDepth 2 SSLProxyCACertificateFile /etc/ssl/certs/internal-ca.pem
常见错误：“Peer certificate does not match hostname” 怎么排查
这个错误不是配置漏了，而是后端服务返回的证书确实不满足校验条件。典型原因包括：
- 后端证书的
subjectAltName里没有你ProxyPass目标中写的域名（比如 ProxyPass https://api.internal/，但证书 SAN 只有www.api.internal） - 后端服务器系统时间偏差超过 5 分钟，导致证书被判定为“未生效”或“已过期”
-
SSLProxyCACertificateFile指定路径错误，或 Apache 进程用户（如www-data）无读取权限，SELinux 上下文也可能拦截 - 调试建议：用
openssl s_client -connect api.internal:443 -CAfile /etc/ssl/certs/internal-ca.pem模拟 Apache 握手过程，看是否能成功建立连接并输出Verify return code: 0 (ok)
真正关键的是：主机名校验和证书链校验是两个独立开关，SSLProxyCheckPeerName on 控制前者，SSLProxyVerify require 控制后者，漏掉任何一个，中间人攻击风险都真实存在。别再找 SSLProxyCheckPeerCN 的替代写法——它没有替代写法，只有正确写法。
