nginx配置刷新域名

问题诊断

很多网站在使用 Nginx 作为反向代理时，都遇到过这样的场景：后端域名（如 `api.example.com`）解析到的服务器 IP 发生了变化，但 Nginx 仍然将请求转发到旧的 IP，导致服务异常。这是因为 Nginx 在启动时或 reload 后会解析配置中的域名，并将解析结果缓存到自身进程内。默认情况下，它不会感知到上游域名的 DNS 记录变化。 要解决这个问题，本质上需要让 Nginx能够动态刷新域名解析结果，或者强制其重新解析。下面提供三种经过生产环境验证的可行方案，您可以根据自身业务场景选择。

推荐方案：使用 `resolver` + 变量实现动态解析

这是目前最推荐的做法。核心思路是让 Nginx 在每一次请求时，都通过指定的 DNS 服务器重新解析域名，从而绕过进程内的长期缓存。 nginx http { resolver 8.8.8.8 valid=10s; # 指定DNS，缓存有效期10秒 server { listen 80; server_name _; location /proxy { set $upstream_addr http://api.example.com:8080; proxy_pass $upstream_addr; # 使用变量，触发运行时解析 proxy_set_header Host $host; } } } 配置说明：

1. 必须在 `http` 或 `server` 块内定义 `resolver`，例如 `resolver 8.8.8.8;`，也可以使用自建 DNS。
2. 在 `location` 中使用 `set` 定义变量，再将变量传给 `proxy_pass`。这种方式会让 Nginx 在每个请求时调用 `resolver` 进行一次域名解析。
3. 通过 `valid=10s` 可以设置解析结果的缓存时间。实际生效的最长刷新延迟不会超过该值，推荐设置为 10-60 秒。

此方案尤其适合后端域名动态变化的场景，例如 Kubernetes 服务、第三方 API 网关等。它的额外开销是一次操作系统级的 DNS 查询，对性能影响极小。

备选方案一：修改 `hosts` 文件并刷新系统缓存

如果后端域名解析结果由于外部原因暂时无法收敛，且您希望快速指定一个目标 IP，可以直接修改服务器的本地 hosts 文件，并刷新系统 DNS 缓存。 bash

编辑 /etc/hosts（Linux）或 C:\Windows\System32\drivers\etc\hosts（Windows）

echo "203.0.113.5 api.example.com" >> /etc/hosts 然后刷新系统级 DNS 缓存： bash

CentOS / RHEL

systemctl restart nscd

Ubuntu / Debian

systemctl restart systemd-resolved

或者使用 nscd 无缓存环境时

最后重载 Nginx 配置： bash nginx -s reload 需要注意的是，修改 hosts 文件是应急手段，且会覆盖 `resolver` 的解析结果。当临时维护结束后，请及时删除对应行。

备选方案二：重载 Nginx 配置

如果您的 Nginx 配置中未使用变量，且域名解析结果不会频繁变化，可以通过重载配置强制重新解析。重载不会中断现有连接，是日常运维中最安全的操作。 bash

测试配置语法

nginx -t

平滑重载

nginx -s reload 重载后，Nginx 会重新读取所有配置文件，并重新解析所有静态写在配置里的域名。但请注意：如果运营商 DNS 或系统默认解析存在缓存，重载后仍可能拿到旧的 IP。因此，在执行 Nginx 重载前，建议先刷新操作系统的 DNS 缓存（方法同上）。如果发现重载后依然访问旧 IP，请先确认本地 DNS 解析结果。

验证方法

无论您采用了哪种方案，都需要确认 Nginx 是否已经解析到新的 IP 地址。可以通过以下几个步骤完成验证：

1. 检查 DNS 解析是否正确：

bash dig api.example.com @8.8.8.8 +short

1. 确认 Nginx 当前使用的解析缓存值： 可以使用 `strace` 跟踪 Nginx 的 `getaddrinfo()` 调用，但这对普通运维人员不够友好。更简单的方式是查看后端服务器的访问日志，确认请求是否到达了新 IP。
2. 生产环境快速验证： 在客户端执行：

bash curl -v https://你的域名/proxy -H 'Host: api.example.com' --resolve api.example.com:8080:预期新IP 若返回结果正常，说明后端连通性没问题，再结合日志确认 Nginx 的转发目标即可。

1. 最终确认配置已正确加载：

bash nginx -T | grep upstream_addr

注意事项

• 使用变量 + `resolver` 时，请务必在 `proxy_pass` 中保留变量或协议前缀，例如 `proxy_pass $upstream_addr;`。如果写成 `proxy_pass http://$upstream_addr;`，也可能正常，但必须保证变量完整，否则会出现“host not found”错误。
• 不要将 `resolver` 设置为公网 DNS 而自身服务器位于内网防火墙之后，否则会导致解析超时。建议使用可靠的内部 DNS 或阿里云/腾讯云 DNS 服务。
• `resolver` 的 `valid` 参数并非精确的到期时间，实际落地需结合 nginx 内部的 TTL 机制。如果您的域名 TTL 较短，请将 `valid` 设置得比 TTL 稍大，以避免域名供应商的 TTL 过长导致刷新延迟。
• 修改 hosts 文件后，如果 Nginx 以 `nginx` 用户运行且开启了 daemon 模式，部分系统可能需要重启 Nginx 才能完全清除 libc 中的解析缓存，此时请使用：

bash nginx -t && systemctl restart nginx # 注意：重启会短暂中断连接 该操作属于影响系统运行的行为，请提早规划或在业务低谷进行。

• 如果您使用的是第三方插件或 njs 模块，请在修改配置前确认模块版本兼容性，并先在预发布环境进行回归测试。

当域名切换完成后，建议持续观察一段时间日志，确保没有大量 502/