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

Question

我有一个不寻常的情况。我制作了一个监听端口 3000 的节点应用程序，我从 443 反向代理，如果我在端口 80 上收到请求，我将恢复到 443。在线一切正常，但此应用程序设计为运行离线自己的服务器作为交钥匙系统。在线时在 443 上是有意义的，但离线时，当服务器未连接到互联网时，它只需要 iOS 客户端设备在线，这些设备只允许在 443 上连接（由于 Apple Transport图层，感谢 Apple）。否则，无论是80还是443对系统来说都没有关系。

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

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

我只是不知道我是否正在做一些危险的事情，监听两个端口并将它们都指向 3000。系统似乎工作正常，但我对这个设置了解不够，无法知道我是否我遇到了一个问题。我将不胜感激关于这是好是坏的任何建议。感谢您的任何建议。

Answer 1

完全没问题。

而且您不需要完全复制服务器块，您可以在同一个块上同时拥有 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/;
    }

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

Danger of reverse proxying with nginx 80 and 443 to a node process listening on port 3000?

windows

nginx

ssl-certificate

node.js