在我的设置中，我有2层透明代理。当一个客户端发出一个SSL请求时，我希望它所遇到的第一个代理只需将流量转发给另一个，而不用尝试与客户端握手。节点http代理SSL透明
该设置看起来很有趣，但在我的情况下是合理的 - 第二个代理只是偶尔注册自己到第一个（通过其他服务）。它告诉第一个：“我感兴趣的是一些类似于_ _ _”的流量。在大多数情况下，第一个代理人只是干这个工作。
httpProxy（在节点代理中）代理SSL请求可以吗？我必须使用httpsProxy（然后将与客户端握手）？
如果您愿意，您可以使用现有的httpsProxy完成所有这些工作。除非你想要将一个非节点代理或代理服务器用于不同的服务器，否则我看不到有两个服务器可以获得什么。
只需将所需的日志/签署逻辑添加到现有的httpsProxy。
通常，我在代理上使用https来限制开放端口的数量，并删除在所有运行的节点服务器上执行https的必要性。您也可以使用http-basic库添加基本身份验证。
见我的例子代码：https://github.com/TotallyInformation/node-proxy-https-example/blob/master/proxy.js
编辑2012-05-15：嗯，经过一番思考，我不知道如果你不应该看着像stunnel做你想要什么，而不是节点？
（仅供参考，我已经在my answer to your similar question on ServerFault取得了一定的这些点的。）
如果你是一个MITM代理后（也就是一个代理，可以看看SSL里面的内容通过使用它自己的证书，只要客户端被配置为信任它们就可以工作），它将不会完全透明，因为您至少必须配置其客户端来信任其证书。另外，除非您的所有客户端都使用服务器名称指示扩展名，否则代理服务器本身将无法可靠地确定要为其颁发其证书的主机（正常HTTPS代理通过查看可以知道的东西由客户发出的CONNECT请求）。
如果一个MITM代理后是不，那你还不如让经由路由器的初始连接。如果您想记录该流量，则您的路由器可能能够记录加密的数据包。
让您的路由器捕获SSL/TLS数据包以透明地将它们发送给代理，该代理最终只会将该数据流中继到目标服务器，这并没有多大意义。 （从本质上讲，透明代理意味着客户端没有配置知道它，所以它甚至不会发送它的方法，你可能已经获得了请求的主机和端口。在这里，你真的没有任何东西超过什么路由器可以做）
编辑：再次，你根本不会能够使用HTTP代理连接的内容透明分析。即使使用普通代理，HTTPS连接也会直接传递到目标服务器。SSL/TLS连接本身是在原始客户端和目标服务器之间建立的。使用SSL/TLS的目的是为了保护这种连接，并且在客户想要查看连接内容时通知客户端。
纯HTTP透明代理服务器工作，因为（a）可以看到流量（特别是，请求行和HTTP头是可见的，以便代理可以知道自己创建哪个请求）和（b）流量可以透明地更改，以便初始客户端不会注意到请求不是直接的，并且可以像以前一样工作。
这些条件都不符合HTTPS真。经过HTTP代理的HTTPS连接只是隧道，在客户端发出明确的请求之后，它发送了一条CONNECT命令并被配置为使用这样的代理。
做一些接近你以后，你需要接受的SSL/TLS连接并且解密了问题（可能像安全通道）HTTP代理之前，在SSL/TLS服务器。但是，这不会透明，因为它无法生成正确的证书。
谢谢 - 我没有在这种情况下MITM后。然而，第二个代理将在转发时充当MITM。否则，是的，我只是通过路由器进行中继。 你提到的是我想实现的，但是我似乎无法使用节点代理来实现它。 – badunk 2012-05-11 03:25:48
你是一个MITM代理后（这可能看起来* *里面的连接，提供了其客户端配置为信任它）或普通HTTPS代理的只是等同，只是透明？ – Bruno 2012-05-11 00:59:00