我一直认为，如果我有 SSL 连接，就不会有 MITM 攻击。现在看来这不是真的（请参阅此问题中的评论从安全角度来看是否可以在受信任的网络中读取外部（不受信任的）cookie？）
我仍然不确定它是如何工作的，以及每个浏览器是否需要安装证书，但听起来你的 LAN 连接上的代理要么重定向域（我可能误解了）要么使用替代证书（证书不需要匹配域？我还是很困惑）。
是否可以检查我是否连接到真实站点？如果您能解释代理如何为它没有真正证书/密钥的域创建有效证书，那也会很有帮助。（我知道这是两个问题，但都可以用一个答案来解释。）
要验证您是否直接与所需的远程服务器通信，需要两点：
远程服务器的构成取决于服务提供商。您在这里混淆了多种代理服务器。
有可用于 HTTPS 连接的普通 HTTP 代理服务器。这是使用 HTTPCONNECT动词完成的，浏览器和目标服务器之间的整个 SSL/TLS 流量仅由代理服务器中继。就 SSL/TLS 连接而言，这大致相当于 IP 路由：代理不会看到任何东西。
有 HTTP 反向代理服务器。这就是您链接到的问题中所讨论的内容。但是，然后在内部处理请求取决于服务提供商。
与数据库连接一样，如果请求由 HTTP 工作节点提供服务，则服务提供者使用 SSL/TLS 保护其内部 HTTP 流量可能很有用。在这种情况下，负载平衡器/反向代理的头节点将是那些内部 Web 服务器的客户端。
就您而言，“真实站点”是头节点/反向代理。https://www.google.com/当然有不止一个盒子来处理它收到的请求。就你而言，它背后的整个集群就是（大）机器。
MITM 代理服务器。一些 HTTP 代理服务器将能够查看 HTTP 流量（例如Squid + SSL Bump）。为此，他们将使用自己的证书颁发机构即时重新生成证书。除非您的计算机已明确配置为信任此本地 CA，否则此类证书将无法在您的浏览器中验证（上述步骤 1）。
如果您使用的是 SSL 代理，则必须专门配置为信任该代理。代理使用通配符证书，因此您的浏览器将接受任何站点的证书。显然，使用您不完全信任的 SSL 代理是一个非常糟糕的主意。
普通的 HTTP 代理可以代理 SSL，但它们只是复制数据，不能更改或解码。您仍然可以看到该站点的正常证书。
如果您担心网站方面的安全性较差，则您无能为力。他们有权解密您选择发送给他们的所有数据。如果他们不保护它，那么您对此无能为力。如果他们在内部使用代理作为 SSL 端点，则他们有责任确保解密数据在其内部网络上的安全。如果他们破坏数据，您将无能为力。他们应该能够随心所欲地处理解密的数据。
SSL 仅保护两个 SSL 端点之间的数据。
代理可以充当中间人的唯一方法（假设客户端和服务器正确地实现了 SSL/TLS 协议的完整版本，并且证书颁发机构正确地完成了他们的工作）是您的浏览器信任代理。这是因为在连接开始时，客户端会验证另一个端点是否具有由公认的证书颁发机构生成的有效证书。
客户端和服务器之间可能存在代理。这在企业网络中很常见，例如，内部主机和 Internet 之间通常没有直接连接。但是代理只能来回交换字节。它无法知道，更不用说修改内容。它可以知道您连接到哪个 IP 地址，但不知道您正在浏览哪个 URL。
那么会出什么问题呢？如果您的浏览器识别出愿意签署的 CA 是proxy.example.com客户端尝试连接的服务器，则proxy.example.com可以自己连接到服务器，并且客户端的连接可能会被明显或透明地重定向到代理。那么代理就是中间人。
一些企业网络将所有客户端配置为信任企业自己的证书颁发机构，并强制使用重写所有 SSL 连接的代理。然后，客户端会看到每个站点都具有由企业 CA 签名的证书。由于所有证书都具有有效签名，因此您在日常使用中不会注意到这一点。找出是否发生这种情况的方法（假设浏览器本身没有被篡改，只有它的证书列表）是检查谁签署了特定的证书，或者浏览受信任的证书颁发机构列表。