最近排查一個web服務的問題，webserver使用的nginx，最終發現是踩了nginx中proxy_pass的一個坑，這里記錄下來。
踩坑經過
一個線上的http服務，示例nginx關鍵配置如下：
server { listen 80; server_name ligang.gdemo.com; server_tokens off; keepalive_timeout 5; charset utf-8; include /home/ligang/devspace/gobox-demo/conf/http/general/gzip.conf; access_log logs/ligang.gdemo.com.log combinedio buffer=1k; error_log logs/ligang.gdemo.com.log.err; location / { include /home/ligang/devspace/gobox-demo/conf/http/general/http_proxy.conf; proxy_intercept_errors on; proxy_pass http://ligang.proxy.gdemo.com; }} 這里可以看到，請求 ligang.gdemo.com 時，nginx把請求反向代理到 ligang.proxy.gdemo.com 去做處理。
ligang.proxy.gdemo.com 這個服務在線上部署并解析到了A、B、C這3個機房，現在我想調整解析，去掉C機房，僅留A、B兩個機房。
調整解析后，查看新的解析已經生效，但觀察C機房的請求量，發現和之前一樣，沒有任何變化。
于是我觀察C機房的nginx的log，發現請求來源還是 ligang.gdemo.com 的機器，域名解析調整后nginx那邊依舊使用之前的IP。
于是我將 ligang.gdemo.com 的機器上的nginx全部reload后，C機房的請求終于沒有了。
問題說明
上面的問題，說明在nginx的proxy_pass中如果使用了域名，那么nginx會把解析的結果緩存下來，貌似不會更新，因為上面的例子中，我調整解析后是幾乎是隔了一天去看C機房的log發現流量沒有任何變化的。
這樣的話，如果你配置一個反向代理服務器，如果上游調整了域名，而你又沒有得到通知，那么你的代理服務相當于不可用了。
從代碼中看下nginx是如何解析主機ip的
有點好奇nginx是如何解析主機ip的，所以追蹤下代碼：
proxy_pass指令定義的地方（http/modules/ngx_http_proxy_module.c）：
{ ngx_string("proxy_pass"), NGX_HTTP_LOC_CONF|NGX_HTTP_LIF_CONF|NGX_HTTP_LMT_CONF|NGX_CONF_TAKE1, ngx_http_proxy_pass, //處理方法 NGX_HTTP_LOC_CONF_OFFSET, 0, NULL },ngx_http_proxy_pass方法（http/modules/ngx_http_proxy_module.c）：
static char *ngx_http_proxy_pass(ngx_conf_t *cf, ngx_command_t *cmd, void *conf){ ngx_http_proxy_loc_conf_t *plcf = conf; size_t add; u_short port; ngx_str_t *value, *url; ngx_url_t u; ngx_uint_t n; ngx_http_core_loc_conf_t *clcf; ngx_http_script_compile_t sc; ...... url = &value[1]; ...... ngx_memzero(&u, sizeof(ngx_url_t)); u.url.len = url->len - add; u.url.data = url->data + add; u.default_port = port; u.uri_part = 1; u.no_resolve = 1; plcf->upstream.upstream = ngx_http_upstream_add(cf, &u, 0);}這里繼續追蹤ngx_http_upstream_add方法（http/ngx_http_upstream.c）：
ngx_http_upstream_srv_conf_t *ngx_http_upstream_add(ngx_conf_t *cf, ngx_url_t *u, ngx_uint_t flags){ ngx_uint_t i; ngx_http_upstream_server_t *us; ngx_http_upstream_srv_conf_t *uscf, **uscfp; ngx_http_upstream_main_conf_t *umcf; if (!(flags & NGX_HTTP_UPSTREAM_CREATE)) { if (ngx_parse_url(cf->pool, u) != NGX_OK) { if (u->err) { ngx_conf_log_error(NGX_LOG_EMERG, cf, 0, "%s in upstream /"%V/"", u->err, &u->url); }繼續追蹤ngx_parse_url方法（core/ngx_inet.c）：
ngx_int_tngx_parse_url(ngx_pool_t *pool, ngx_url_t *u){ u_char *p; p = u->url.data; if (ngx_strncasecmp(p, (u_char *) "unix:", 5) == 0) { return ngx_parse_unix_domain_url(pool, u); } if (p[0] == '[') { return ngx_parse_inet6_url(pool, u); } return ngx_parse_inet_url(pool, u);}然后是ngx_parse_inet_url方法（core/ngx_inet.c）：
static ngx_int_tngx_parse_inet_url(ngx_pool_t *pool, ngx_url_t *u){...... if (ngx_inet_resolve_host(pool, u) != NGX_OK) { return NGX_ERROR; }......}然后是ngx_inet_resolve_host方法（core/ngx_inet.c）：
#if (NGX_HAVE_GETADDRINFO && NGX_HAVE_INET6) ngx_int_t ngx_inet_resolve_host(ngx_pool_t *pool, ngx_url_t *u) {...... if (getaddrinfo((char *) host, NULL, &hints, &res) != 0) { u->err = "host not found"; ngx_free(host); return NGX_ERROR; }......}#else /* !NGX_HAVE_GETADDRINFO || !NGX_HAVE_INET6 */ngx_int_tngx_inet_resolve_host(ngx_pool_t *pool, ngx_url_t *u){...... h = gethostbyname((char *) host);......}思考下如何解決這個問題
最簡單的解決方法，我想到如下幾種：
執行 nginx reload
這種方法優缺點都很明顯：
優點：操作簡單。
缺點：屬于我們常說的后手，需要做好監控。
配置resolver
可以通過在nginx中配置resolver來動態更新解析，大致做法如下：
server { listen 80; server_name ligang.gdemo.com; resolver 8.8.8.8 valid=60s; resolver_timeout 3s; set $gproxy "ligang.proxy.gdemo.com"; location / { proxy_pass http://$gproxy; } }這個方法優缺點如下：
優點：解析地址每隔一段時間自動更新，無需人工做 nginx reload 。
缺點：需要指定DNS服務器地址，如果這個服務器掛了，或是地址變了，則需要修改nginx配置后reload。
結束語
上面這兩個方法是無須額外開發，直接簡單可用的，成本上比較低，但都有不完美的地方。
這里我想到是否可以自行開發一個nginx擴展，用來動態更新從DNS獲取的IP地址，這樣就能解決這個問題了，但有一定的開發成本，但個人覺得對提升技術能力又很有價值。
如果大家有什么好方法，也歡迎來一起討論。以上就是本文的全部內容，希望對大家的學習有所幫助，也希望大家多多支持VEVB武林網。
新聞熱點
疑難解答
