是也不是。

服务器地址部分不加密，因为它是用来建立连接的。

这种情况可能会随着加密的SNI和DNS而改变，但截至2018年，这两种技术都不常用。

路径、查询字符串等都是加密的。

注意，对于GET请求，用户仍然可以从位置栏中剪切和粘贴URL，并且您可能不希望将机密信息放在那里，因为任何人都可以看到屏幕。

Marc Novakowski的回答很有帮助——URL存储在服务器的日志中(例如，在/etc/httpd/logs/ssl_access_log中)，所以如果你不想让服务器长期保存这些信息，就不要把它放在URL中。

正如其他答案已经指出的，https“url”确实是加密的。然而，解析域名时您的DNS请求/响应可能不是，当然，如果您使用浏览器，您的url也可能被记录。

链接到我对重复问题的回答。URL不仅在浏览器历史记录中可用，服务器端日志也可以作为HTTP Referer头发送，如果您使用第三方内容，则会将URL暴露给您控制之外的来源。

You can not always count on privacy of the full URL either. For instance, as is sometimes the case on enterprise networks, supplied devices like your company PC are configured with an extra "trusted" root certificate so that your browser can quietly trust a proxy (man-in-the-middle) inspection of https traffic. This means that the full URL is exposed for inspection. This is usually saved to a log. Furthermore, your passwords are also exposed and probably logged and this is another reason to use one time passwords or to change your passwords frequently. Finally, the request and response content is also exposed if not otherwise encrypted. One example of the inspection setup is described by Checkpoint here. An old style "internet café" using supplied PC's may also be set up this way.

我同意前面的答案:

明确地说:

使用TLS, URL的第一部分(https://www.example.com/)在构建连接时仍然可见。第二部分(/herearemygetparameters/1/2/3/4)由TLS保护。

然而，您不应该在GET请求中放置参数的原因有很多。

首先，正如其他人已经提到的: -通过浏览器地址栏泄露 -历史泄漏

除此之外，您还会通过http引用器泄漏URL:用户在TLS上看到站点A，然后单击到站点B的链接。如果两个站点都在TLS上，则对站点B的请求将在请求的引用器参数中包含来自站点A的完整URL。站点B的管理员可以从服务器B的日志文件中检索它。)