NGINX无法提供5050端口HTTPS访问的故障排查

故障根因 #

• 你尝试访问https://x.x:5050/conf的请求路径本身不符合当前服务架构的设计逻辑：现有NGINX仅在443标准HTTPS端口加载了SSL证书、配置了反向代理规则，5050端口运行的是Node.js纯HTTP服务，该端口上未部署任何TLS加密服务。浏览器向5050端口发起HTTPS请求时会触发TLS握手流程，对面的HTTP服务无法响应对应流程，因此会抛出“无法提供安全连接”的提示。
• 按照现有配置设计，所有走HTTPS加密的请求都会从443端口进入NGINX，不需要手动在HTTPS地址中携带5050端口。对应服务的正确访问路径为https://x.x/conf：请求进入NGINX后会匹配location /conf规则，被反向代理转发到本地5050端口的Node服务。

现有配置的缺陷调整 #

1. 清理代理路径的冲突规则
   你在location /conf块中同时配置了proxy_pass和try_files，两个规则存在执行顺序冲突：NGINX收到请求后会先执行try_files逻辑，检查本地静态站点目录下是否存在对应路径的文件，找不到就直接返回404，根本不会执行后续的代理转发流程。需要删除location /conf块下的try_files $uri $uri/ =404;语句，这条规则是静态站点根路径的专属配置，不适用于反向代理场景。
   修正后的location /conf配置为：

   location /conf {
       proxy_pass http://localhost:5050;
   }
   

2. 优化端口访问安全策略
   如果你不希望外部用户直接通过http://x.x:5050访问未加密的Node服务，可以在服务器防火墙层面关闭5050端口的公网入站权限，所有Node服务的访问流量统一通过443端口经NGINX代理转发，既可以保障全链路HTTPS加密，也能避免后端服务直接暴露在公网带来的安全风险。

内容的提问来源于stack exchange，提问作者MPL