问题描述
最近碰到了一个 Nginx 做为反向代理设置上的坑。起因是将 Nginx 做为反向代理服务器,来统一处理内网服务的转发。使用了类似如下的配置:
upstream blog { server xxx.xxxx.com:8800; } server { listen 80; server_name xxx.xxx.net; location / { proxy_pass http://blog; } }
刚开始的时候, proxy_pass
里使用的 ip 地址,Nginx 工作正常。近期由于内网服务升级,每个内网服务前面,都新增了一个 AWS internal load balancer,用来作为负载。而 AWS 的 lb 提供的访问方式,是一个内网 DNS 地址,而不直接提供 ip 地址。于是最初我便把 nginx 的 proxy_pass
里的 ip 地址改为了 AWS 提供的负载均衡的内网域名,测试后没有问题。但是在第二天一早到公司后,发现昨天配置的内网服务无法连通了。尝试执行命令 nginx -s reload
后,服务又恢复正常后,便没有过多追究,去忙别的事情了。但是一直感觉到这里的问题应该不简单,在详细查看 log 与文档后,发现了 Nginx 一个设置上的细节。
原因
在这个文档 Nginx 文档 Using DNS for Service Discovery with NGINX and NGINX Plus 中,解释了发生这个问题的原因。如果在 Nginx 的设置 proxy_pass
里使用域名而不是 IP 地址,Nginx 只会在每次启动和重载设置时,使用 DNS 将域名解析为 IP 地址缓存下来,并在之后一直使用这个 IP,并不会按照 DNS 的 TTL 刷新 IP 地址。如果在这个解析过程中发生错误,则会导致 Nginx 启动失败。由于在 AWS 中负载均衡的内网域名对应的 IP 并不是一直不变的,这才导致了上面的问题。文档中同样指出,使用 Nginx 的 upstream 配置也会有这个问题。
处理办法
既然知道了问题的原因所在,那么针对这个问题,根据上面文档中给出了一个解决方法,将配置文件修改为如下的形式:
server { listen 443 ssl; server_name xxx.xxxx.com; server_name_in_redirect off; ssl_certificate "/etc/nginx/conf.d/https.pem"; ssl_certificate_key "/etc/nginx/conf.d/https.key"; resolver 8.8.8.8 223.5.5.5 valid=3600s; resolver_timeout 3s; set $ddnsblog xxx.xxxx.comn=:8800; location / { proxy_pass https://ddnsblog; proxy_pass_request_headers on; proxy_pass_header WWW-Authenticate; proxy_set_header Hosthost; proxy_set_header X-Real-IP remote_addr; proxy_set_header X-Forwarded-Forproxy_add_x_forwarded_for; } } location / { proxy_pass https://ddnsblog; proxy_pass_request_headers on; proxy_pass_header WWW-Authenticate; proxy_set_header Hosthost; proxy_set_header X-Real-IP remote_addr; proxy_set_header X-Forwarded-Forproxy_add_x_forwarded_for; } }
在这个配置中,resolver
是 DNS 服务器地址, valid
设定 DNS 刷新频率。需要特别注意的一点是 set
语句不能写到 location 里面,否则不会生效。
评论抢沙发