mod_rewrite无法判断TLS版本，因其仅能访问HTTP层变量（如%{HTTPS}），不暴露TLSv1.2/TLSv1.3等传输层信息；应通过SSLProtocol和SSLCipherSuite在TLS握手阶段强制协议与密钥套件，实现安全可控的版本控制。
Apache 的 mod_rewrite 本身**不能直接读取或判断客户端使用的 TLS 协议版本**（如 TLSv1.2 或 TLSv1.3）。TLS 握手发生在 HTTP 协议之前，属于传输层安全协商，而 RewriteCond 只能访问 HTTP 层及服务器环境变量（如 %{HTTPS}、%{HTTP_USER_AGENT}、%{REMOTE_ADDR} 等），不暴露 TLS 版本信息。
为什么 RewriteCond 无法获取 TLS 版本
Apache 不将 TLS 协议版本作为标准环境变量导出给 mod_rewrite。即使启用了 HTTPS，%{HTTPS} 只返回 on 或 off，不区分 TLSv1.2/TLSv1.3；OpenSSL 或 mod_ssl 也未默认提供类似 %{TLS_VERSION} 的变量。
可行的替代方案：用 SSL/TLS 配置本身实现“按 TLS 版本分流”
真正安全且可控的做法，是**不在 rewrite 层做判断，而通过 TLS 协议和密钥套件的强制配置来达成目标**：
Apache Superset Dashboard and SQL Exploration Skill
下载
Apache Superset 是一个广泛采用的开源 BI 平台，用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时，此技能非常有用。
- 在虚拟主机中明确启用 TLSv1.3 并禁用旧协议：
SSLProtocol +TLSv1.2 +TLSv1.3（保留 1.2 兼容性）或仅+TLSv1.3（严格要求） - 搭配 TLS 1.3 专用密钥套件：
SSLCipherSuite TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256 - 配合
SSLHonorCipherOrder on，确保服务器优先选择高安全性组合 - 这样，不支持 TLSv1.3 的客户端（如旧版 Java 8 默认 JSSE、Android 4.4）会握手失败，自然无法访问 —— 效果等同于“拒绝低 TLS 版本请求”，但更可靠、更底层
若仍需在应用层感知 TLS 版本，可借助自定义响应头（需模块支持）
部分部署环境可通过以下方式间接传递 TLS 信息：
- 启用
mod_ssl的SSLUserName或自定义日志格式记录 TLS 信息（仅用于审计，不可用于 rewrite 条件） - 使用
mod_headers添加响应头（如Header always set X-TLS-Version "TLSv1.3"），但这只是静态声明，不反映实际协商结果 - 高级场景下，可编写 Apache 模块（C）或使用
mod_lua（若启用）读取 OpenSSL 的 SSL_get_version()，再设环境变量供RewriteCond使用 —— 但属非标、难维护、不推荐生产环境采用
总结：重写不是 TLS 版本控制的合适位置
试图用 RewriteCond 判断 TLS 版本属于错用机制。安全策略应前置到 TLS 握手阶段：靠 SSLProtocol 和 SSLCipherSuite 精确控制支持范围，既高效又符合协议分层原则。rewrite 更适合处理 URL 路径、参数、Referer 或 User-Agent 等 HTTP 层特征。
