在证书更改后，公司SSL代理会导致ERR_TUNNEL_CONNECTION_FAILED？

首先，由于您（或更正确的说是代理）在检索页面之前还没有完成TLS握手，所以不能涉及caching。

接下来，检查你的服务器日志，虽然很有可能你不会find任何东西，除非你已经启用了debugging。 这是因为当客户端发生故障时尚未完成握手，所以没有HTTP请求触发您的服务器。

接下来，你可以自己重现这个问题吗？ 如果这样排除故障更容易。 如果没有重现问题的可能性，我已经成功地留下了tcpdump一段时间的连接，然后打开生成的pcap并检查握手故障

在黑暗中拍摄，确保您的服务器名称/别名在您的HTTPS虚拟主机上正确configuration，而我们在这个时候可以发布输出：

 apachectl -S 

在你的问题？

这是我可以build议根据您的详细信息。

背景：一些评论表明，与常规代理的行为混淆，而不是SSL检查代理： MITM（中间人）代理是执行TLS / SSL拦截和检查的代理。 他们接受客户端对目标HTTPS站点的请求，并从受信任的根证书颁发机构（由pipe理员select/创build，并由客户端信任）提供（伪造）证书。 然后可以读取明文 – 客户端和目标站点之间的任何通信。

SSL检查往往由不同的供应商以不同的方式实施：这不是一个标准，因此MITM代理的工作方式不同。 常见的是，一旦代理终止了与自身的连接，它就会使用自己的SSL库和技术与目标站点build立新的连接。 该“最终”出站连接是要确定远程站点的行为的连接。

原始答案： TLS 服务器名称指示 （SNI）尚未被所有代理支持，特别是较旧的代理。 代理服务器在停止支持后往往会徘徊不前，因为它们是关键的基础设施，而且它们正在工作，所以…

我猜想，在启用SNI时，您可能已经阻止具有不太安全的连接configuration文件的较早的SSL检查启用的代理允许连接。 如果可以解决这个问题，那么这是修复它的最佳途径 – 例如，在IIS上，如果SNI找不到匹配项，则会有一个“默认”SSL证书的概念，用作后备。 如果没有为您configuration，或者如果这是可能的，那可能是最好的。 道歉它不符合你的架构。

当你通过一个不理解对方所做的事情的代理，或者甚至像代理不能正确parsing客户端使用的名字那样简单的代理，将其添加到已经半滑稽的SSL检查时（不同的DNS透明的SSL检查;没有客户端提示服务器名称）…是的，我可以想象，这可能是一个问题。

我不确定如何通过与pipe理员沟通，除了通过在您的服务器端获取SSL会话设置的networking跟踪，将它们压缩到只是失败，然后尝试“足迹”呼叫者在发生明显故障的情况下（在源上进行反向IP查询，分析VIA报头线索的非SSLstream量或类似情况）。