我们的网站通过内容交付网络 (AWS CloudFront) 提供静态内容，该网络配置为响应多个 CNAME，并针对这些主机名使用我们的 SSL 通配符证书。由于 CDN 可能从同一 IP 地址为许多不同的虚拟主机提供服务，因此客户端需要 SNI 支持。
我们很清楚某些操作系统/浏览器组合不支持 SNI，因此我们根据 User-Agent 标头实现了对 http 的回退。
然而，一些客户反馈称内容无法提供。似乎没有哪种浏览器或操作系统出现问题，例如，在现代 Windows 上运行现代 Chrome 会抛出ERR_CONNECTION_CLOSED。此外，整个办公室都会遇到同样的问题，因此有强烈的迹象表明问题源于网络设置，而不是单个客户端。当我们转向非 SNI 解决方案时，问题就消失了。
因此，我的问题是网络中的其他元素是否可以阻止 TLSv1 和/或 SNI？网关、路由器、代理、VPN 或网络设置中可能找到的其他任何东西是否有可能以某种方式阻止 TLSv1/SNI 工作？
答案1
另一种可能性是 HTTPS 支持的过滤代理（如 Squid）执行 SSL Bumping，并根据建立连接的 IP 地址错误地使用错误的（默认）证书。请参阅http://www.spinics.net/lists/squid/msg70666.html进行与您的问题描述非常相似的讨论。