这个Connection refused（错误码111）本质上是Nginx无法和上游服务器202.3.208.203:55000建立TCP连接，咱们按优先级从易到难排查：

1. 先在Nginx服务器上直接测试网络连通性 #

先跳过Nginx，直接在部署Nginx的机器上用工具验证能不能连到上游端口：

• 用telnet测试：telnet 202.3.208.203 55000
• 或者用curl看详细输出：curl -v http://202.3.208.203:55000/cp/submitSM.jsp

如果这一步就失败，说明是网络层面的问题，和Nginx配置无关，直接往下看后续网络相关排查；如果能成功，那再回头检查Nginx的配置细节。

2. 检查上游服务器的服务状态 #

确认上游服务器202.3.208.203上的目标服务是否正常运行，并且在55000端口监听：

• 在上游机器上执行：ss -tulpn | grep 55000（旧系统可以用netstat -tulpn | grep 55000）
• 输出里应该能看到对应进程在监听0.0.0.0:55000或者指定IP的55000端口，如果没有输出，说明服务没启动，或者没绑定到正确的端口。

3. 排查防火墙/安全组规则 #

不管是Nginx所在服务器，还是上游服务器，都要检查是否有防火墙规则拦截了55000端口的流量：

• Nginx服务器侧：检查iptables/firewalld是否放行对202.3.208.203:55000的出站请求
  • 比如firewalld：firewall-cmd --list-all查看现有规则；临时添加测试规则：firewall-cmd --add-rich-rule='rule family="ipv4" destination address="202.3.208.203" port port="55000" protocol="tcp" accept'
• 上游服务器侧：检查是否允许来自Nginx服务器IP的55000端口入站请求
  • 同样用firewalld/iptables检查，或者云服务商的安全组（如AWS Security Groups、阿里云安全组），确保入站规则里开放了55000端口给Nginx的IP。

4. 检查Nginx proxy_pass配置细节 #

如果前面网络测试都正常，再看你的proxy_pass配置：

proxy_pass http://202.3.208.203:55000/cp/submitSM.jsp;

这里要注意：当proxy_pass后面带具体路径时，Nginx会把location /v1/submit匹配到的路径部分替换成proxy_pass里的路径。比如客户端请求/v1/submit?param=1，Nginx会转发到http://202.3.208.203:55000/cp/submitSM.jsp?param=1，这个路径是否符合上游服务的预期？不过这个是路径匹配问题，不会直接导致连接拒绝，但如果前面都没问题，可以顺便确认下。

另外，你配置里的proxy_ssl_server_name on;其实是多余的——因为你用的是http://而不是https://，这个参数只对HTTPS上游生效，可以去掉避免混淆。

5. 开启Nginx debug日志定位细节 #

如果还是找不到问题，可以开启更详细的Nginx日志，在http块里添加：

log_format upstream_debug '$remote_addr - $remote_user [$time_local] "$request" '
                         '$status $body_bytes_sent "$http_referer" '
                         '"$http_user_agent" "$upstream_addr" "$upstream_status" '
                         '"$upstream_response_time" "$upstream_connect_time"';

然后在你的server块里指定用这个日志格式：

access_log /var/log/nginx/upstream_access.log upstream_debug;

重新加载Nginx配置：nginx -s reload，然后触发请求，查看日志里的$upstream_connect_time和$upstream_status字段，能得到更精准的连接失败信息。

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