我们更改了 Apache HTTP 服务器上的一些 SSL 设置，即添加了 SNI 支持。进行此更改后，似乎一些使用企业 SSL 代理（MITM 盒）的用户会收到模糊错误，例如ERR_TUNNEL_CONNECTION_FAILED。我们使用的证书没有改变，在非 SNI 浏览器的情况下从 IP 地址提供的默认证书也没有改变。证书链的提供方式与以前一样，因为 Qualys SSL 测试给出的评级为“A”。
代理是否缓存了某些内容？什么可能导致这些错误？我们可以做什么？不幸的是，我不知道他们运行的是什么软件，所以这只是猜测。
答案1
首先，无法涉及缓存，因为您（或更准确地说是代理）在检索页面之前尚未完成 TLS 握手。
接下来，检查服务器日志，尽管除非启用了调试，否则您很可能找不到任何内容。这是因为当客户端发生故障时握手尚未完成，因此没有 HTTP 请求到达您的服务器。
接下来，您能自己重现问题吗？如果可以，故障排除会变得更容易。在没有重现问题的可能性的情况下，我成功地让 tcpdump 收集了一段时间的连接，然后打开生成的 pcap 并检查握手失败
然后在黑暗中尝试一下，确保您的 ServerName / Alias 在 HTTPS Vhosts 上正确配置，同时您可以发布以下输出：
apachectl -S
在你的问题中？
根据您的详细信息，这就是我能提出的全部建议。
答案2
背景：一些评论表明对常规代理（而不是 SSL 检查代理）的行为感到困惑：MITM（中间人）代理是执行TLS/SSL 拦截和检查。它们接受客户端对目标 HTTPS 站点的请求，并提供来自受信任的根认证机构（由管理员选择/创建，并受到客户端信任）的（伪造的）证书。然后可以以明文形式读取客户端和目标站点之间的任何通信。
SSL 检查往往由不同的供应商以不同的方式实现：它不是标准，因此 MITM 代理的工作方式也不同。常见的情况是，一旦代理终止与自身的连接，它就会使用自己的 SSL 库和技术与目标站点建立新连接。该“最终”出站连接是将决定远程站点行为的连接。
原始答案： TLS服务器名称指示(SNI) 尚未得到所有代理的支持，尤其是较旧的代理。代理在停止支持后往往会持续很长时间，因为它们是关键的基础设施，而且它们仍在运行，因此...
我猜想在启用 SNI 时，您可能阻止了较旧的启用了 SSL 检查的代理（这些代理具有不太安全的连接配置文件）允许连接。如果可以解决这个问题，那么这就是您解决问题的最佳途径 - 例如，在 IIS 上，存在“默认”SSL 证书的概念，如果 SNI 未找到匹配项，则将其用作后备。如果您没有配置该证书，或者存在这种可能性，那么这可能是最好的选择。抱歉，它与您的架构不匹配。
当您将其添加到已经半不稳定的 SSL 检查中时，代理无法理解另一端正在做什么，或者甚至像代理无法正确解析客户端使用的名称（用于透明 SSL 检查的不同 DNS；没有客户端提示服务器名称）......是的，我可以想象这可能是一个问题。
我不知道您除了通过与管理员联系外如何追踪该问题...除非通过在服务器端获取 SSL 会话设置的网络跟踪，将其精简为故障，然后在出现明显故障时尝试“追踪”调用者（在源上进行反向 IP 查找、分析非 SSL 流量以获取 VIA 标头线索或类似线索）。