記一次nginx中proxy_pass的使用問題
最近排查一個web服務的問題，webserver使用的nginx，最終發(fā)現(xiàn)是踩了nginx中proxy_pass的一個坑，這里記錄下來。
踩坑經(jīng)過
一個線上的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個機房，現(xiàn)在我想調(diào)整解析，去掉C機房，僅留A、B兩個機房。
調(diào)整解析后，查看新的解析已經(jīng)生效，但觀察C機房的請求量，發(fā)現(xiàn)和之前一樣，沒有任何變化。
于是我觀察C機房的nginx的log，發(fā)現(xiàn)請求來源還是 ligang.gdemo.com 的機器，域名解析調(diào)整后nginx那邊依舊使用之前的IP。
于是我將 ligang.gdemo.com 的機器上的nginx全部reload后，C機房的請求終于沒有了。
問題說明
上面的問題，說明在nginx的proxy_pass中如果使用了域名，那么nginx會把解析的結果緩存下來，貌似不會更新，因為上面的例子中，我調(diào)整解析后是幾乎是隔了一天去看C機房的log發(fā)現(xiàn)流量沒有任何變化的。
這樣的話，如果你配置一個反向代理服務器，如果上游調(diào)整了域名，而你又沒有得到通知，那么你的代理服務相當于不可用了。
從代碼中看下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);
}
這里繼續(xù)追蹤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);
}
繼續(xù)追蹤ngx_parse_url方法（core/ngx_inet.c）：
ngx_int_t
ngx_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_t
ngx_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_t
ngx_inet_resolve_host(ngx_pool_t *pool, ngx_url_t *u)
{
......
h = gethostbyname((char *) host);
......
}
思考下如何解決這個問題
最簡單的解決方法，我想到如下幾種：
執(zhí)行 nginx reload
這種方法優(yōu)缺點都很明顯：
優(yōu)點：操作簡單。
缺點：屬于我們常說的后手，需要做好監(jiān)控。
配置resolver
可以通過在nginx中配置resolver來動態(tài)更新解析，大致做法如下：
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;
}
}
這個方法優(yōu)缺點如下：
優(yōu)點：解析地址每隔一段時間自動更新，無需人工做 nginx reload 。
缺點：需要指定DNS服務器地址，如果這個服務器掛了，或是地址變了，則需要修改nginx配置后reload。
結束語
上面這兩個方法是無須額外開發(fā)，直接簡單可用的，成本上比較低，但都有不完美的地方。
這里我想到是否可以自行開發(fā)一個nginx擴展，用來動態(tài)更新從DNS獲取的IP地址，這樣就能解決這個問題了，但有一定的開發(fā)成本，但個人覺得對提升技術能力又很有價值。
如果大家有什么好方法，也歡迎來一起討論。以上就是本文的全部內(nèi)容，希望對大家的學習有所幫助，也希望大家多多支持腳本之家。
相關文章
解決nginx啟動失敗(bind()?to?0.0.0.0:80?failed，An?attempt?was?
這篇文章主要介紹了解決nginx啟動失敗問題(bind()?to?0.0.0.0:80?failed,An?attempt?was?made?to?access?a?socket?in?...),具有很好的參考價值,希望對大家有所幫助,如有錯誤或未考慮完全的地方,望不吝賜教2024-05-05
Nginx日志中request_time和upstream_response_time區(qū)別
Nginx日志中的request_time和upstream_response_time是關鍵的性能指標,本文就來介紹一下Nginx日志中request_time和upstream_response_time區(qū)別,具有一定的參考價值,感興趣的可以了解一下2024-11-11
Mac環(huán)境Nginx配置和訪問本地靜態(tài)資源的實現(xiàn)
這篇文章主要介紹了Mac環(huán)境Nginx配置和訪問本地靜態(tài)資源的實現(xiàn)，文中通過示例代碼介紹的非常詳細，對大家的學習或者工作具有一定的參考學習價值，需要的朋友們下面隨著小編來一起學習學習吧2020-09-09
本篇文章主要介紹了Nginx之為已安裝nginx動態(tài)添加模塊的方法，小編覺得挺不錯的，現(xiàn)在分享給大家，也給大家做個參考。一起跟隨小編過來看看吧2018-04-04
Nginx之upstream被動式重試機制的實現(xiàn)
本文主要介紹了Nginx之upstream被動式重試機制的實現(xiàn),可以通過proxy_next_upstream來自定義配置,具有一定的參考價值,感興趣的可以了解一下2025-03-03
虛擬主機指的就是一個獨立的站點配置,是nginx默認支持的一個功能,本文主要介紹了Nginx虛擬主機的配置實現(xiàn),具有一定的參考價值,感興趣的可以了解一下2024-01-01
nginx不單可以作為強大的web服務器，也可以作為一個反向代理服務器，而且nginx還可以按照調(diào)度規(guī)則實現(xiàn)動態(tài)、靜態(tài)頁面的分離，可以按照輪詢、ip哈希、URL哈希、權重等多種方式對后端服務器做負載均衡，同時還支持后端服務器的健康檢查2016-09-09
本文詳細介紹了Nginx的緩存配置,包括緩存文件的存儲路徑、緩存的有效期、哪些請求走緩存、哪些請求不緩存,以及如何刪除緩存,同時,還提供了一個綜合案例來說明如何配置和使用Nginx緩存2025-03-03
在 Nginx 中設置了 keepalive_timeout、client_header_timeout 和 client_body_timeout 后仍然不起作用,所以本文給大家介紹了Nginx配置超時時間的排查步驟,并有相關的代碼示例供大家參考,需要的朋友可以參考下2024-11-11
這篇文章主要介紹了Nginx 配置過程的詳細介紹的相關資料,希望通過本文能幫助到大家，讓大家掌握如何配置Nginx，需要的朋友可以參考下2017-10-10