我同意前面的答案:

明确地说:

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

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

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

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

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

是也不是。

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

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

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

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

虽然你已经有了很好的答案，但我真的很喜欢这个网站上的解释:https://https.cio.gov/faq/#what-information-does-https-protect

简而言之:使用HTTPS隐藏:

HTTP方法 查询参数 POST正文(如有) 请求头(包括cookie) 状态码

此外，如果您正在构建一个ReSTful API，浏览器泄漏和http引用程序问题将在很大程度上得到缓解，因为客户端可能不是浏览器，您可能没有人点击链接。

如果是这种情况，我建议登录oAuth2以获得一个不记名令牌。在这种情况下，唯一的敏感数据将是初始凭证……无论如何，这应该在post请求中

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.