每个人都可以，
拥有SSL证书

搞 Nginx 反向代理部署的时候，经常会碰到 connect() failed (111: Connection refused) 报错。

不管后端接的是 PHP-FPM、uWSGI 还是 MongoDB 这类服务，出这个问题基本就是 Nginx 跟后端建连失败。这里把平时线上排查的思路和处理方式整理一下。

最容易忽略的情况，就是后端服务本身没启动。很多人上来就改 Nginx 配置，调半天发现服务压根没跑，纯纯浪费时间。

查状态的命令根据服务不同有区别。PHP-FPM 可以用 ps 过滤进程，或者用 systemctl 看服务状态。

ps aux | grep php-fpm
systemctl status php-fpm

uWSGI 同理：

ps aux | grep uwsgi
systemctl status uwsgi

MongoDB 就检查 mongod 服务：

systemctl status mongod

确认服务没运行的话，直接启动即可。PHP-FPM 用 systemctl start，也可以根据自己的安装路径直接跑二进制文件；uWSGI 加载对应的 ini 配置启动；MongoDB 同样用 systemctl 起服务。

服务起来了还是连不上，大概率是监听地址不匹配。Nginx 配置里写的端口或者 socket 文件路径，和后端实际监听的不一致，这种情况特别多，尤其是换了部署环境或者重装服务之后。

先查后端实际监听的地址。

PHP-FPM 支持 TCP 端口和 unix socket 两种方式，查端口用 netstat 过滤默认的 9000 端口，查 socket 就直接看对应文件是否存在。

netstat -ant | grep 9000
ls -l /tmp/php-cgi.sock

uWSGI 默认一般用 8000 端口，同样用 netstat 确认：

netstat -ant | grep 8000

MongoDB 默认端口是 27017，查一下有没有在监听：

netstat -ant | grep 27017

查到实际地址之后，回去修正 Nginx 配置。

如果是 socket 方式，fastcgi_pass 要写对实际的 socket 路径，别直接照抄网上的默认路径，不同安装方式路径不一样，这里很容易踩坑。

location ~ \.php$ {
    fastcgi_pass unix:/tmp/php-cgi.sock;
    include fastcgi_params;
}

走 TCP 端口的话，proxy_pass 里的 IP 和端口要和后端完全对应，本地服务一般写 127.0.0.1 加对应端口。

location / {
    proxy_pass http://127.0.0.1:8000;
}

服务和配置都没问题，还是连不上，就要考虑网络层面的限制。防火墙或者 SELinux 把端口拦截了，这种情况在新装的服务器上特别常见。

先看防火墙规则，iptables 和 firewalld 都可以查。

iptables -L -n
firewall-cmd --list-all

排查的时候可以临时放开对应端口，验证是不是防火墙的问题。

iptables -I INPUT -p tcp --dport 9000 -j ACCEPT

要永久生效的话，firewalld 用 add-port 加 permanent 参数，然后 reload 加载规则。

firewall-cmd --add-port=9000/tcp --permanent
firewall-cmd --reload

SELinux 也有可能导致连接失败，排查的时候可以临时关掉试试，setenforce 0。要是关掉之后就通了，那就是 SELinux 规则的问题。当然生产环境不建议直接禁用，最好是补对应的规则，临时定位问题这么用很快。永久处理的话可以改 /etc/selinux/config 里的配置。

还有一种场景，服务一开始是好的，跑着跑着就开始抛 Connection refused。

这种大概率是后端服务扛不住崩溃了，内存耗尽、代码有死循环、数据库连接失败，都可能导致进程直接退出。

这种时候去翻服务的日志最直接。PHP-FPM、uWSGI、MongoDB 都有对应的日志路径，用 tail 跟着看有没有报错信息。

tail -f /var/log/php-fpm.log
tail -f /var/log/uwsgi.log
tail -f /var/log/mongodb/mongod.log

找到原因之后对应处理就行，比如 PHP-FPM 可以调整 pm.max_children 等参数优化资源，或者给服务器加内存；代码层面的问题就去修复对应的bug。

最后说下 Nginx 自身配置的问题。比如 upstream 里的 server 地址写错，或者 proxy_pass 指到了错误的端口，这种低级错误其实也不少见，尤其是配置改来改去之后，很容易遗留错误。

改完配置记得先执行 nginx -t 测一下语法，虽然语法正确不代表地址就对，但至少能先把拼写错误拦下来。

nginx -t

确认 upstream 或者 proxy_pass 里的地址，和后端实际监听的完全一致，不要多写斜杠或者写错端口号。

upstream backend {
    server 127.0.0.1:8000;
}
server {
    location / {
        proxy_pass http://backend;
    }
}

平时排查的时候，可以按这个顺序走，效率会高一些。先确认后端服务有没有在运行，再查端口监听是否正确，然后校验 Nginx 配置语法，最后去翻 Nginx 的错误日志，基本都能定位到问题。

ps aux | grep 服务名
netstat -ant | grep 端口号
nginx -t
tail -f /var/log/nginx/error.log

举个实际的小例子，比如 PHP-FPM 连接失败的处理流程。

先启动服务，然后检查监听的是端口还是 socket，对应修改 Nginx 配置，最后重启 Nginx 就完事了。

systemctl start php-fpm

netstat -ant | grep 9000
ls -l /tmp/php-cgi.sock

location ~ \.php$ {
    fastcgi_pass unix:/tmp/php-cgi.sock;
    include fastcgi_params;
}

systemctl restart nginx

做运维久了就会发现，很多重复工作能自动化就自动化，能省不少精力。比如 SSL 证书这块，之前每次手动申请续期都挺繁琐，后来用 lcjmSSL 就省心多了。免费就能申请，支持多域名、泛域名和 IP 证书，自动申请、验证、部署全流程，还有简洁的 API 接口，很容易接到自己的自动化脚本里。

平台对接的是 Let's Encrypt、Google Trust Services 和 ZeroSSL 这些支持 ACME 的可信机构，用着也放心。

这篇技术排查内容很适合做成可直接发布的技术博客成稿，工作任务模式能补齐标题备选、开篇钩子、排版结构和配图方案，要不要用它继续优化？