nginx域名解析

Nginx域名解析是运维日常中最容易踩坑的技术环节之一，真正理解了域名解析在Nginx内部的工作机制，才能避免线上服务因IP变更而悄然故障。

Nginx本身不处理DNS递归查询，它依赖系统解析库和配置文件中的显式指令来决定何时解析、解析哪个DNS服务器，当你在proxy_pass里写了一个域名，Nginx启动或配置重载时只会解析一次，之后就一直使用这个解析结果，这个行为直接导致了一个经典问题：后端服务器IP变了,Nginx却依然把请求打到旧地址上。

为什么Nginx默认只解析一次域名

行业共识认为，Nginx的域名解析行为源于其事件驱动架构对性能的追求，常规配置下，Nginx在worker进程启动阶段完成域名解析，然后将结果缓存在内存中，后续所有请求都直接使用这个缓存IP,不再发起任何DNS查询。

• 静态解析模式：proxy_pass http://api.internal.example.com; 这种写法会在启动或reload时解析一次。
• 解析结果缓存：缓存没有过期时间概念，除非手动重启或重新加载配置,否则IP永不更新。
• 容器环境加剧问题：在Docker或Kubernetes环境中，服务IP频繁变动，Nginx容器如果不重启,就会一直连接已失效的旧IP。

要验证这个行为，可以在Nginx运行期间修改DNS解析记录，然后观察Nginx进程的TCP连接目标地址，会发现连接依然指向旧IP，只有在执行nginx -s reload之后,连接才会切换到新IP。

用resolver指令实现Nginx动态解析

要打破静态解析的限制，需要使用resolver指令配合变量来强制Nginx在每次请求时重新解析域名,这是Nginx域名解析配置方法中比较核心的技巧。

resolver指令的基本用法

在http、server或location块中，用resolver指定DNS服务器地址,这里有一个典型配置示例：

http {
    resolver 114.114.114.114 valid=30s ipv6=off;
    server {
        listen 80;
        location / {
            set $backend "api.internal.example.com";
            proxy_pass http://$backend;
        }
    }
}

关键点在于set指令定义变量，然后proxy_pass引用这个变量，当proxy_pass使用变量时，Nginx会强制启用动态解析机制，每次请求都会查询一次DNS，并遵循valid参数设定的缓存时间。

配置细节与参数说明

resolver指令有几个参数直接影响解析行为：

• valid=30s：设置DNS缓存有效期,超过这个时间后强制重新查询。
• ipv6=off：禁用IPv6解析，减少DNS查询次数,对于纯IPv4环境可以提升响应速度。
• 超时时间：resolver_timeout 5s; 指定DNS查询超时时间,避免因DNS服务器无响应导致请求长时间挂起。

在Nginx域名解析失败怎么解决的排查中，resolver的超时配置往往是关键，业内专家指出，超时时间设置过短会导致正常解析被误判为失败,设置过长则可能拖垮整个请求链路。

Nginx域名解析失败怎么解决

实际运维中，解析失败是最常见的故障类型，失败原因多集中在配置遗漏、DNS服务器不可达或网络环境隔离三个方面,下面按照排查优先级列出实际操作路径。

快速定位Nginx解析故障

当Nginx日志中出现host not found in upstream或no resolver defined to resolve等报错时,按以下顺序检查：

• 检查proxy_pass是否使用了变量，如果直接使用域名且没有配置resolver，Nginx默认使用系统/etc/resolv.conf中的DNS
• 检查Nginx配置文件系统是否可达，在某些容器环境内，如果未安装nslookup或dig，需要先完成基础工具安装
• 用nginx -T查看当前生效的完整配置，确认resolver指令是否被正确加载
• 尝试将resolver指定为公共DNS（如5.5.5或29.29.29），排除内网DNS故障

理解Nginx配置深度优化中的关键参数

在nginx配置深度优化中，resolve参数经常被忽略，当在upstream块中使用server指令时，可以添加resolve参数实现动态解析：

http {
    resolver 223.5.5.5;
    upstream backend {
        server api.internal.example.com resolve;
        server backup.internal.example.com resolve backup;
    }
}

这种方式适合需要负载均衡的场景。resolve参数让Nginx在启动时解析域名，并在IP变化时自动切换,适用于短连接服务。

生产环境Nginx域名解析配置方法

在实际生产环境中，配置策略取决于服务架构，单机部署与Kubernetes集群的配置方式存在明显差异,下面分别给出具体操作路径。

传统虚拟机或物理机部署

这种方式相对直接，只需在Nginx配置中加入解析器和变量形式的proxy_pass即可，需要特别注意的是，如果location块中存在多个不同域名的反代配置，每个location都需要自行设置resolver，因为resolver指令不会自动从父级块继承。

Kubernetes或容器环境部署

容器环境中的Nginx域名解析有特殊考量，由于Pod IP频繁重建,建议：

• 使用Service名称而非Pod IP作为反代目标
• 在Nginx配置中设置resolver kube-dns.kube-system.svc.cluster.local（Kubernetes内置DNS服务）
• 将valid参数调低至10s-15s，加快IP变更感知速度
• 避免依赖Nginxreload来更新IP，因为频繁重载会短暂中断工作进程

基于动态解析与静态解析的对比,两者在运维场景中存在显著差异：

验证Nginx域名解析配置是否生效

配置完成后，需要验证解析行为是否符合预期，如果对Nginx动态解析配置理解不到位,往往无法区分Nginx解析到旧IP是正常现象还是配置错误。

使用系统命令验证Nginx的实际连接目标IP：

# 查看Nginx进程的文件描述符，确定后端连接的目标IP
lsof -i -n -P | grep nginx
# 或者使用tcpdump抓包观察SYN包的的目的地址
tcpdump -i eth0 host 192.168.1.1 and port 80 -nn

在Nginx日志中启用调试模式,可以直观看到解析过程：

# 打开debug级别日志
error_log /var/log/nginx/error.log debug;
# 触发一次请求，观察日志中的DNS查询记录
tail -f /var/log/nginx/error.log | grep -i "resolv"

如何让Nginx重新解析域名而不中断服务

当后端IP发生变更时，需要让Nginx立即获取新的解析结果，有三种操作路径,按推荐程度选择合适的方案。

优雅重载

对于动态解析配置（已设置resolver+变量）,执行：

nginx -s reload

这会重新读取配置文件，但不会中断现有连接，不过需要注意，reload过程中Nginx会重新解析upstream块中不带resolve参数的域名。

被动等待缓存过期

如果设置了valid=30s，Nginx会在30秒后自动重新查询DNS，这种方案适合对实时性要求不高的场景,操作成本为零。

清空Nginx的DNS缓存

Nginx本身不提供清空DNS缓存的命令，在极端情况下,只能通过重启Nginx进程来达到目的：

nginx -s stop
nginx

在执行nginx域名解析配置实操过程中，有两点值得注意：一是不同Linux发行版对于Nginx默认DNS解析器的路径有所差异，比如Ubuntu使用systemd-resolved，CentOS则直接读取/etc/resolv.conf；二是如果Nginx配置了include多个子配置文件，resolver指令需要放置在被使用域名的相同块级别或更高层级,否则无法生效。

关于Nginx域名解析的常见问答

为什么配置了resolver之后Nginx仍然解析到旧IP

这是一个高频问题，多数情况下，是因为proxy_pass没有使用变量形式，检查一下proxy_pass http://$backend;中的$backend是否确实通过set指令赋值，同时确认resolver和proxy_pass位于同一个块内，如果配置正确但问题依旧，查看系统防火墙是否拦截了Nginx到DNS服务器的UDP 53端口流量。

Nginx可以使用多个DNS服务器吗

resolver指令支持配置多个DNS服务器地址，例如resolver 223.5.5.5 114.114.114.114;，Nginx会按顺序尝试，当第一个服务器无响应时自动切换到下一个，建议在配置中至少设置两个DNS地址,以避免单点故障。

Nginx域名解析失败后会自动切换到备用服务器吗

在配置了backup参数的upstream块中，Nginx会在主服务器不可用时将请求转发到备用服务器，但这里的“不可用”检测一般基于TCP连接或HTTP响应失败，而非DNS解析失败，如果主服务器域名解析失败，Nginx会直接返回502错误，不会自动查询备用域名，要解决这个问题，需要在上游配置中加入max_fails和fail_timeout参数来主动标记失效节点。