是的。

这就是SslStrip起作用的原因。（好吧，原因之一。）

HTTP是明确的。所以301也很清楚。任何使用例如 Wireshark 收听的人都可以看到这一点。（在同一主机上自己尝试。这很容易。）

是的，在重定向到 HTTPS 是纯 HTTP 之前，ISP 可以将整个 URL 视为请求。

HTTP 严格传输安全 (HSTS)试图通过让服务器通知浏览器仅通过 HTTPS 连接来解决此问题。当然，对启用 HSTS 的站点的第一个请求仍然是未加密的，因为浏览器不知道该站点的 HSTS 策略。浏览器供应商正试图通过维护启用 HSTS 的站点列表来解决这个问题。

如果只是为了您自己的安全（而不是一般情况下），您还可以使用HTTPS Everywhere，这是一个适用于大多数浏览器的插件，其中包含已知正确支持 HTTPS 的站点列表，您可以并且应该添加尚未支持的站点在列表中但支持 HTTPS，因为这个项目是社区驱动的。

要添加到@StackzOfZtuff 的答案（我还不能评论，否则我会），在 HTTP 和 SSL/TLS 参与之前，你的 TCP 握手是可见的，引用了实际的主机和请求的性质。之后，您的客户端 HELO 到网络服务器是可见的，尽管 URL 本身没有显示。一旦您和服务器之间完成 SSL 密钥交换，您的数据（包括实际的 GET）就会被加密。到那时你已经有大约 9 个数据包进入序列了。

在 HTTP 重定向到 HTTPS 的情况下，服务器发出的 301 响应将您发送到相关的 HTTPS URL 直到您的浏览器以明文形式发送“GET /.txt”后才会发生。此外，带有 URL 的 301 响应是完全可见的，因为它也是通过未加密的 HTTP 发送的。

是的，您的 ISP 可以看到您的 HTTP 请求的 URL，因为 URL 是以明文形式发送的。

此外，如果网站使用 SNI ( https://en.wikipedia.org/wiki/Server_Name_Indication )，即使在您跳转到 HTTPS 之后，您的 ISP 也可能能够看到 URL 的主机名，这在野生。例如（https://aws.amazon.com/about-aws/whats-new/2014/03/05/amazon-cloudront-announces-sni-custom-ssl/）