我正在尝试通过节点代理访问 Node https 服务器。
我购买了证书，并获得了一个运行良好的独立 https 服务器。最初由于一个文件中有多个证书而出现了一些问题，但这篇文章有所帮助：
http://stackoverflow.com/questions/16224064/running-ssl-node-js-server-with-godaddy-gd-bundle-crt.
之前，我所有的连接都是通过基于节点的反向代理 nodejitsu 的 http-proxy 模块进行的，该模块可以有效地代理 http -> http。
现在，正如预期的那样，将目标服务器更改为 https 后，代理无法工作，基本上如下：
client -> http-proxy(public IP) -> https connection(local IP)
这实际上就是中间人攻击的场景，而这正是 https 试图消除的。
此外，我从 https 服务器收到以下错误：
Error: Hostname/IP doesn't match certificate's altnames
证书很好，因为 https 无需中间代理即可正常工作。通过阅读一些帖子，我意识到以下内容应该有效：
client -> https-proxy (Public IP) -> http connection (local IP)
实际的本地服务器正在运行 http 和公共 https。这是基于 http-proxy 文档中的解释：
https://github.com/nodejitsu/node-http-proxy
在这篇文章中：
https://nadeesha.silvrback.com/creating-a-https-proxy-in-node-js
在 http-proxy 模块文档中，似乎有对客户端 -> https（公共 IP 上的代理）-> https（本地 IP 上的代理）的解释。如果是这样，我需要在目标 https 服务器上设置哪些证书？
在尝试任何这些可能性之前，我想知道：满足这一要求的标准最佳实践是什么以及如何在节点下实现它/它们。我不想仅仅为了处理这个问题而引入 Nginx 或 Apache。我在这里完全偏离了主题吗？
答案1
client -> https-proxy (Public IP) -> http connection (local IP)
这是一个完全有效的安装，只要它https-proxy (Public IP) -> http connection (local IP)是通过安全的网络进行的 - 即您的后端服务器不会暴露在公共网络中。
client -> https-proxy (Public IP) -> httpS connection (local IP)
如果您处于私有网络中，并且只需执行加密/解密步骤即可使后端服务器和前端代理“过度工作”，则无需执行此操作。但是，在某些情况下可能需要执行此操作，而且现代计算机在执行加密/解密时不会像以前那样卡住。但同样，您是否会感觉到它取决于流量的大小。