记一次Nginx反向代理失效的排查：原来是被这个细节坑了

大家好，我是33blog的技术博主。今天想分享一个最近遇到的Nginx反向代理失效的案例，整个过程就像侦探破案一样，最终发现是一个很容易被忽略的配置细节导致的。如果你也遇到过类似问题，不妨看看这篇排查记录。

问题现象：反向代理突然失效

那天我正在给客户部署一个新的Web服务，按照常规操作配置了Nginx反向代理。这本来是个很简单的任务，我闭着眼睛都能完成——至少我是这么认为的。

配置完成后，访问代理地址时却直接返回502 Bad Gateway。更奇怪的是，直接访问后端服务是正常的，但通过Nginx代理就不行。

第一轮排查：检查基础配置

我首先检查了最基本的Nginx配置：

server {
    listen 80;
    server_name proxy.example.com;
    
    location / {
        proxy_pass http://backend-service:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

看起来一切正常，proxy_pass指向了正确的后端地址，header设置也没问题。我开始怀疑是不是网络连通性问题。

第二轮排查：网络连通性测试

我在Nginx服务器上执行了telnet测试：

telnet backend-service 8080

连接成功！这说明网络层面没有问题。那么问题可能出在Nginx和后端服务的交互上。

深入排查：查看Nginx错误日志

这时候我才想起来应该看看Nginx的错误日志（/var/log/nginx/error.log），果然发现了关键线索：

connect() failed (111: Connection refused) while connecting to upstream

这很奇怪，因为telnet明明能连通。我开始怀疑是不是DNS解析的问题。

关键发现：原来是这个细节在作怪

经过一番折腾，我终于发现问题所在：后端服务容器重启后IP变了，但Nginx没有重新解析DNS！

Nginx默认会缓存上游服务的DNS解析结果，直到重启或重载配置。这意味着当容器IP变化时，Nginx还在尝试连接旧的IP地址。

解决方案：配置DNS解析刷新

解决方法很简单，在proxy_pass配置中添加resolver并设置有效期：

server {
    listen 80;
    server_name proxy.example.com;
    
    resolver 8.8.8.8 valid=10s;
    
    location / {
        set $backend "http://backend-service:8080";
        proxy_pass $backend;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

这里的关键点：

• 使用变量$backend来存储代理地址
• 配置resolver并设置valid=10s，让Nginx每10秒重新解析DNS

经验总结

这次踩坑让我学到了：

1. Nginx默认会缓存DNS解析结果，这在容器环境中特别容易出问题
2. 排查问题时，日志永远是第一手资料
3. 看似简单的配置，往往藏着意想不到的陷阱

希望这篇记录能帮到遇到类似问题的朋友。如果你有更好的解决方案，欢迎在评论区交流！