可在 nginx 反向代理后面的端口 3000 上访问 nodejs 应用程序

Mac*_*acs 6 ssl proxy nginx node.js

我正在运行一个带有 nodejs 应用程序的 nodejs 应用程序,一个服务器侦听端口 3000。我使用 nginx 作为反向代理,它也处理 ssl。下面列出了配置(在阅读了几个教程和论坛帖子后,我认为它非常标准)。一切都按预期工作,除了我仍然能够在“ http://example.com:3000 ”下访问该应用程序。这是否意味着我需要添加另一个服务器侦听端口 3000 以重定向到 https?这可能意味着我到目前为止阅读的教程有些不完整,或者我忽略了一些基本的东西。谁能帮我弄清楚它是什么?

 # app server upstream

upstream app {
    server 127.0.0.1:3000;
}

# default http server. Redirect to https server

server {
    listen 80;
    server_name www.example.com example.com;
    return 301 https://example.com$request_uri;  
}

# https server

server {
    listen 443;
    server_name www.example.com example.com;

    ssl on;
    ssl_certificate ssl.crt;
    ssl_certificate_key ssl.key;

    ssl_session_timeout 5m;

    ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers "HIGH:!aNULL:!MD5 or HIGH:!aNULL:!MD5:!3DES";
    ssl_prefer_server_ciphers on;

    location / {
        proxy_pass http://app;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;   
    }
}   
Run Code Online (Sandbox Code Playgroud)

yei*_*iel 2

如果您可以从计算机外部访问端口 3000,则意味着您以 HTTP 服务器侦听所有接口的方式对 Node.js 应用程序进行编程。这本身并不坏,默认情况下您应该以这种方式对应用程序进行编程,因为您无法预测最终部署拓扑的未来变化。按照 Oxi 的建议,将向外界隐藏端口的责任留给防火墙(这里想到了 iptables)。

这样,您将来无需更改代码即可使其适应不同的部署拓扑。

比如我就有一个类似的案例。我使用 Haproxy 作为负载均衡器和 SSL 终止。但就我而言,出于性能考虑,Haproxy 实例在不同的主机上运行。如果在开发阶段我限制我的应用程序仅侦听本地连接,那么我将不得不在开发时更新我的​​代码以适应新的拓扑。

我希望这可以帮助你。