nginx的DNS缓存

原文：https://blog.csdn.net/amdkings1/article/details/79092937 

nginx 配置中有1个upstream配置是指向一个域名Y的，而这个域名Y解析对应IP其实是会动态变化的。

最近生产环境发现一个奇怪现象，上面的配置正常运行了至少半年以上，突然报告404.打开nginx的error日志后，发现nginx解析Y的结果竟然和ping解析的不同。于是查了nignx的资料，发现nginx本身有dns缓存机制，配置文件中 resolver 配置了dns的valid时间是10天。

这样问题就清楚了。nginx -s reload 就能解决上面的问题。

为了搞明白上面的问题，特地查了操作系统级别的dns缓存和nginx 的dns缓存机制。对于操作系统级别的dns缓存，无论是widnows还是ubuntu都有缓存项目的“生存时间”，生存时间到了才会刷新缓存。

对于nginx 的 dns 缓存来说，nginx会在首次proxy_pass到upsteam时并且upstream是域名配置的，nginx就会解析域名，并缓存直到valid时间后，再重新重新解析dns的结果。

这样来看的话，如果我们想要把域名Y后面对应的服务器S退出的话，比较合理的做法应该是让已经退休的S运行一段时间，在开一台新的服务器S2，把域名Y解析到S2上。但是至少要保证原来的S能够正常运行足够久的时间T。这样所有的客户端，才可以正常访问服务。通过在windows上查看 ipconfig /displaydns 发现“生存时间”一般的不会大于24小时，linux上的配置需要看使用何种dns缓存软件，无论使用何种软件，“生存时间”一般不适宜设置的过大。如果设置的过大，超出了时间T，就会出现不强制刷新dns缓存，就不能访问服务的问题。像我这次遇到的问题，其实本质上也是把nginx的“生存时间” valid配置的过大有关系。顺带说一下，过小也不可取。其实，我的生产环境中，Y对应的server在改变后，原来的服务器S是运行了一段时间的，但是我配置的valid太大了，所以出问题了。