我正在向 NGINX 提供的面向公众的遗留 jQuery/HTML/CSS 应用程序添加一个新功能。
该应用程序从 Tomcat 请求 REST 资源，由 NGINX 指导。Tomcat 服务器位于 VPN 中，该 VPN 包括物理上的远程 Linux 实例，作为新功能的一部分，该实例可能已连接 IP 摄像机。Tomcat 服务器只能通过 Linux 实例的 SSH 转发访问 IP 摄像机的 HTTP Web 服务器端口。
新功能的一部分包括在旧版应用程序中向公众提供已由供应商安装在 IP 摄像机 HTTP Web 服务器根目录上的新应用程序。
我当前的实现需要一个（iframe），它指向 Tomcat 上的一个新端点；此端点的 Java 代码：
- 在 TCP/IP 层创建基于 Netty 的反向代理，当响应对摄像机视频源的 GET 请求（唯一标识感兴趣的远程 Linux 实例）时 -动态创建的代理从Tomcat 服务器到 VPN 中的 Linux 实例 --- 注意：我不想动态操作我的 NGINX 配置，而不是按需生成反向代理。
- 使用动态分配的 Tomcat 服务器端口，例如http://example.com:65555，通过重定向到相机应用程序的根 URL 来响应所述 GET
第一个实现工作正常，例如从 AXIS 摄像头加载 React 应用程序，该摄像头通过 HTTP 提供 JS/HTML/CSS 资产，并使用 RTSP over WS 将视频流传输到旧版应用程序的 iframe。
也就是说，当通过 HTTP 提供旧版应用程序时，它在本地和我的开发环境中都可以正常工作。相机应用程序仅通过 HTTP提供服务，我想将其视为黑盒 - 我想要/已经对相机应用程序的 Web 服务器进行的唯一调整是通过返回适当的标头来允许 CORS。
但是，当通过 HTTPS 为旧版应用程序提供服务时，重定向到反向代理需要 HTTPS 方案（否则，浏览器 [例如 Chrome] 会抱怨）；当然，相机上的 HTTP 服务器不处理 HTTPS 请求 - FAIL。
通过 HTTPS为旧版应用程序提供服务时，我是否只需要向我的反向代理添加一个 SOCKS 代理层？或者，也许是 TLS 层？
动态生成的反向代理基于此处的 Netty 示例：https ://github.com/netty/netty/tree/4.1/example/src/main/java/io/netty/example/proxy