我有一个Nginx服务器处理http请求并对上游的某些节点服务器进行代理传递,如果域名与其中一个启用的站点匹配,则所有数据包都被重定向到一个节点服务器,仅当该通道是SSL时,否则301到https版本:
server {
listen 80;
server_name something.com
return 301 https://$host$request_uri;
}
server {
listen 433;
server_name something.com;
ssl_certificate /etc/nginx/cert.crt;
ssl_certificate_key /etc/nginx/cert.key;
ssl on;
ssl_session_cache builtin:1000 shared:SSL:10m;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4;
ssl_prefer_server_ciphers on;
location / {
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_set_header X-NginX-Proxy true;
proxy_pass http://127.0.0.1:3000/;
proxy_redirect off;
}
}
一切正常,但证书管理,SSL握手等都是由Nginx制作的。我希望上游的每个节点服务器都能管理自己的SSL首选项,因此我不依赖Nginx来执行此操作。我的节点服务器已经支持https请求,但我不明白是否可以告诉Nginx:
听取433,不要担心SSL,只需代理将所有内容传递给localhost:3000
侦听端口3000的节点服务器处理SSL
答案 0 :(得分:1)
听433,不要担心SSL,只需代理将所有内容传递给localhost:3000
不,不是使用nginx,你必须使用端口转发。
nginx要么必须使用一些SSL密钥并且可能使用SSL将流量代理到某个Node应用程序,这将意味着Node和nginx都必须管理自己的SSL密钥(nginx用于client-nginx连接和Node适用于nginx-nodeApp连接的应用程序。)
或者nginx可以使用不带SSL的HTTP来代理对使用SSL的Node的请求,这意味着client-nginx连接将是不安全的,只有nginx-NodeApp连接才是安全的。这也意味着https://www.example.com/不起作用 - 尽管http://www.example.com:443/会。
如果您希望Node处理SSL密钥而不是反向代理(通常是这样),那么您必须使用TCP / IP级别的端口转发将流量传递给Node应用程序,而不使用反向代理(nginx)。
通常使用反向代理,以便应用程序不必处理用于客户端连接的SSL密钥(以及其他内容)。如果您希望Node应用程序使用SSL密钥而不是反向代理,那么您应该首先重新考虑使用反向代理。