使用Nginx 80和443向侦听端口3000的节点进程进行反向代理的危险？

如何解决使用Nginx 80和443向侦听端口3000的节点进程进行反向代理的危险？

我有一个不寻常的情况。我制作了一个节点应用程序，侦听了端口3000，该端口从443反向代理，如果在端口80上收到请求，我将还原为443。一切都可以在线正常运行，但是此应用程序设计为可以在自己的服务器上离线运行交钥匙系统。在线时，在443上是有意义的，但是在离线状态下，当服务器未连接到Internet时，对于iOS客户端设备，它只需要在线即可，而iOS客户端设备只能在443上进行连接（由于Apple Transport Layer，感谢Apple） ）。否则，对系统而言，无论是80还是443都没有关系。

现在，有趣的部分。在Windows上，当服务器处于脱机状态并且客户端通过https连接到服务器时，我收到有关Windows无法检查证书吊销列表的警告，显然是因为服务器未联机并且无法连接到证书颁发机构。如果我安装了证书，警告不会消失，并且它使系统搞砸了，因为它永远无法在脱机时检查任何吊销列表（因为它可以运行）。如果设备已连接到Internet，则可以验证证书是否已被吊销，但是要使客户端计算机位于Internet上具有授权权限，这是一个额外的步骤。我的客户相当精通技术，所以当他们只想连接时就很难解释这个要求。

我想我找到了一个部分解决方案-让nginx监听和443和80反向代理到端口3000（复制服务器块，只提供443监听的密钥）。这样，我可以告诉不想在连接端口80上进行连接之前进行联机检查的客户，并且可以告诉iOS客户在端口443上进行连接。

我只是不知道我在两个端口上进行监听并将它们都指向3000时是否都在做危险的事情。系统似乎运行正常，但是我对此设置的了解不足，无法知道我是否在行走陷入问题。我希望您能就此事的好坏提出任何建议。感谢您的任何建议。

解决方法

完全可以。

并且您不需要完全复制服务器块，您可以在同一块上同时具有80和443个侦听器，因此它们共享其余的服务器配置。唯一的区别是443侦听器在该点终止SSL。

类似的东西：

server {
    listen       80;
    listen       443 ssl;
    server_name  foo.example.com;

    ssl_certificate     /etc/pki/tls/certs/foo.example.com.bundle.crt;
    ssl_certificate_key /etc/pki/tls/private/foo.example.com.key;

    location / {
        proxy_pass http://127.0.0.1:3000/;
    }