背景
我正在尝试弄清楚我在网上找到的代理服务器实现中发生了什么这里但我很困惑。我能够成功运行代理，但我无法理解幕后发生了什么。我稍后会解释我到底对什么感到困惑。
我目前所做的
我能够启动代理服务器这个班并将我的 HTTP 流量重定向到那里。我能够通过代理成功在浏览器中加载页面。
我困惑的地方
代理服务器接收到连接时打开的套接字类型为HTTP代理套接字在这个套接字内，数据被传递到远程服务器，当读回数据时，使用 HTTPStreamScanner（第 127 行）来扫描响应数据。
但我能够看到 HTTP 和 HTTPS 标头数据，这确实让我感到困惑。
问题
- 似乎正在使用 HTTP Connect。经过一番挖掘，似乎 CONNECT 用于初始化隧道。真的，我对此感到困惑。隧道与套接字有何关系？我为什么要首先创建隧道？
- 这在网络模型的哪一层起作用？或者这个问题根本就没有意义？
答案1
无论 HTTPS 连接如何加密，代理至少需要知道：
- 服务器地址（通常是 IP 地址，但许多浏览器会发送完整的主机名 - 以防代理可能有不同的 DNS 设置），
- 要连接的 TCP 端口（对于 HTTPS 通常为 443）。
根据您的评论，这是您看到的唯一信息，因此这是正常的。浏览器不会发送特定于 HTTP 的参数（原始请求方法、路径、查询字符串、HTTP 标头），直到它通过您的代理建立与服务器的 TLS 连接。
真的，我对此感到困惑。隧道与套接字有何关系？我为什么要首先创建隧道？[...] 这在网络模型的哪一层运行？或者这个问题根本就没有意义？
（这是一个一般性的描述，而不是针对NEKit的描述。）
在网络中，隧道是一种假装处于比实际更低层的东西，并且能够在其内部承载同一层甚至更低层的协议。
例如，常规 HTTP 是应用层协议，但 HTTP CONNECT 允许它承载其他内部的应用层协议——对于 Web 浏览器来说，它的行为就像传输协议，您可以在其周围构建 connect()/send()/recv() 函数。
再举一个例子，大多数 VPN 是一种在 UDP 内部传输 IP 的隧道，即 L4 上的 L3。（如果包括 VPN 所做的加密/压缩/身份验证，甚至可能是 L7 上的 L3。）
（TLS 本身非常相似。如果从传输层的角度来看，TLS 是一个应用层协议，但如果从应用程序的角度来看，TLS 很可能是传输层的上半部分。）
那么你为什么要创建隧道呢？打破分层，字面意思就是这样。你最初的问题是，“为什么代理似乎破坏了 HTTPS 加密”。这正是使用 HTTP CONNECT 的原因——浏览器使用它在高层协议 (HTTP) 内承载较低层协议 (TLS)，以便保留加密。