不能直接用 RewriteCond 判断客户端 TLS 版本，因其运行在 HTTP 层，无法访问 TLS 握手信息；%{SSL_PROTOCOL} 仅反映协商结果，不可靠；应通过 mod_ssl 硬性约束协议、日志分析弱协议使用情况来保障安全。
不能直接用 RewriteCond 判断客户端使用的 TLS 协议版本（如 TLSv1.2 或 TLSv1.3），因为 mod_rewrite 无法访问 TLS 握手层的协议信息。Apache 的重写引擎运行在 HTTP 层，而 TLS 协商发生在更底层（SSL/TLS 层），其协议版本不会作为标准环境变量暴露给 RewriteCond。
为什么 %{SSL_PROTOCOL} 不是可靠判断依据
虽然 Apache 的 mod_ssl 提供了 %{SSL_PROTOCOL} 变量（例如在 RewriteCond %{SSL_PROTOCOL} =TLSv1.3 中使用），但它反映的是当前连接实际协商成功的 TLS 版本，而非客户端“支持”或“安全性能力”。这个变量可用于日志记录或条件响应，但存在明显限制：
- 它只在 HTTPS 请求中可用，HTTP 请求中为空或未定义；
- 它不表示客户端是否“仅支持弱协议”，而是最终协商结果——可能受服务器配置（如
SSLProtocol）强制降级影响； - 无法区分“客户端支持 TLSv1.3 但因兼容性回退到 TLSv1.2”这类场景。
更合理且可行的安全控制方式
与其试图在 rewrite 阶段做 TLS 版本判断，不如通过以下分层策略真正提升安全性：
Apache Superset Dashboard and SQL Exploration Skill
下载
Apache Superset 是一个广泛采用的开源 BI 平台，用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时，此技能非常有用。
-
在 mod_ssl 层硬性约束协议范围：在
ssl.conf或虚拟主机中明确启用强协议、禁用旧协议，例如：SSLProtocol +TLSv1.2 +TLSv1.3
这样所有连接都会被服务器强制协商为 TLSv1.2 或更高，无需 rewrite 干预。 -
结合 SSL 环境变量做内容/行为差异化：若确需按 TLS 版本提供不同响应（如对 TLSv1.3 连接返回更精简的 JS/CSS），可使用：
RewriteCond %{SSL_PROTOCOL} =TLSv1.3RewriteRule ^/app\.js$ /app.tls13.js [L]
注意：这属于“响应适配”，不是“安全拦截”。 -
用 ErrorDocument 或自定义 Header 标识协议强度：例如在 TLSv1.2 连接中返回
Warning: Legacy TLS in use头，辅助审计，而非阻断。
替代方案：用日志和监控识别弱连接
真正需要关注“谁还在用 TLSv1.0/1.1”时，应依赖日志分析而非运行时重写：
- 在
LogFormat中加入%{SSL_PROTOCOL}x和%{SSL_CIPHER}x； - 定期用脚本或 ELK 分析访问日志，统计低版本 TLS 使用占比；
- 发现集中来源后，再针对性调整服务器策略（如升级 OpenSSL、更新客户端库）。
总之，mod_rewrite 不适合承担 TLS 安全性判断职责。把协议控制交给 mod_ssl，把可观测性交给日志，才是稳定、可维护的做法。
