apache中sni本身不导致重定向死循环，问题根源在于多域名https配置不当：必须为每个域名独立配置块，避免共用重写规则；规则须加守门条件（如%{https} off）和[l]终止符；禁用proxypassreverse误改location头；通过loglevel warn rewrite:trace3日志定位循环点。
apache 中 sni 本身不直接导致重定向死循环，但多域名 https 配置不当（尤其是证书、虚拟主机和重写规则混用时）极易引发循环跳转。关键不在 sni 协议，而在配置逻辑是否隔离清晰。
每个域名必须独占 <virtualhost></virtualhost> 块
SNI 要求 Apache 为不同域名加载不同证书，而重定向行为由各虚拟主机内部规则独立控制。若把多个域名塞进同一个 <virtualhost></virtualhost> 并靠 ServerAlias 区分，所有域名共用一套重写规则，极易互相触发：
- 错误写法：一个块里配
ServerName old.com+ServerAlias new.com，再加一条RewriteRule ^(.*)$ https://new.com$1 [R=301,L]→ old.com 会跳 new.com，但 new.com 自身请求又匹配该规则，形成循环 - 正确做法：old.com 和 new.com 各自独立的
<virtualhost></virtualhost>块，old 块内只写跳转规则，new 块内不写任何跳转或明确排除自身
重定向规则必须守门，避免自匹配
即使分开了虚拟主机，规则本身若没加条件限制，仍可能在目标域名下重复生效。例如强制 HTTPS 的规则若未排除已为 HTTPS 的请求，就会在 443 端口上反复跳转：
Apache Superset Dashboard and SQL Exploration Skill
下载
Apache Superset 是一个广泛采用的开源 BI 平台，用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时，此技能非常有用。
- 删掉这类危险规则：
RewriteCond %{SERVER_PORT} 80单独判断端口 → 它无法识别当前请求是否已走 443 且 Host 正确 - 改用更精准的守门条件：
RewriteCond %{HTTPS} off [OR]RewriteCond %{HTTP_HOST} !^new\.com$ [NC]RewriteRule ^(.*)$ https://new.com$1 [R=301,L] - 对新域名的虚拟主机，加一条“终止性排除”：
RewriteCond %{HTTP_HOST} ^new\.com$ [NC]RewriteRule ^ - [L]，确保不进入后续重写链
检查 ProxyPassReverse 是否干扰 SNI 域名跳转
如果用了反向代理（比如旧域名代理到新域名后端），ProxyPassReverse 可能意外改写 Location 头，把 https://new.com/path 又替回 https://old.com/path，尤其当两个域名共用同一台后端或 DNS 解析指向相同 IP 时：
- 确认
ProxyPassReverse的第二个参数严格对应后端真实返回的 URL 协议+主机+端口，不能模糊写成https://new.com如果后端实际返回的是https://localhost:8080 - 禁用内网域名与对外域名同名：old.com 和 new.com 绝不能都解析到同一台 Apache 服务器，否则重定向响应可能被 Apache 自己再次捕获，触发二次处理
- 用
curl -I https://old.com和curl -I https://new.com分别抓响应头，确认 Location 字段没有来回替换痕迹
启用重写日志快速定位循环点
死循环发生时，仅看浏览器报错不够，要让 Apache 说出每一步做了什么：
- 临时在对应虚拟主机中加入：
LogLevel warn rewrite:trace3 - 重启 Apache，复现一次跳转请求
- 查
error_log，搜索该请求的 trace 日志，找连续出现的 “applying pattern → rewrite → go to next rule” 链条，特别注意 INPUT URI 和 REWRITE URI 是否在 old.com ↔ new.com 之间来回切换 - 找到哪条
RewriteCond没拦住、哪条RewriteRule缺了[L]，立刻修正
