在不使用 Apache 或 Nginx 的情況下通過反向代理設置 https 節點伺服器的最佳實踐是什麼
我正在嘗試通過節點代理訪問節點 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 伺服器上設置哪些證書？
在嘗試任何這些可能性之前，我想知道：處理此要求的標準最佳實踐是什麼以及如何在 node.js 下實現它/它們。我不想僅僅為了處理這個問題而介紹 Nginx 或 Apache。我在這裡完全偏離軌道了嗎？
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)如果您在專用網路中並且只是通過必須執行加密/解密步驟來“過度使用”您的後端伺服器和前端代理，則這是不必要的。但是，在某些情況下可能需要它，而且現代電腦在進行加密/解密時不會像以前那樣窒息。但同樣，你是否會感覺到它取決於交通量。