nginx線上運(yùn)營tips總結(jié)

ZoomQuiet 發(fā)布于2019-07-25 13:28 / 2768人閱讀

摘要：前言業(yè)務(wù)野蠻生長時(shí)期，作為一枚，有運(yùn)營過比較長的一段時(shí)間。根據(jù)該是否和匹配絕對是否對前端返回。開發(fā)人力不足以重構(gòu)這個(gè)接口，為了不影響調(diào)用成功率，想都設(shè)置為返回成功之類的狀態(tài)碼記錄慢日志為提高接口的運(yùn)營質(zhì)量，同時(shí)也方便定位一些奇怪的問題。

前言

業(yè)務(wù)野蠻生長時(shí)期，作為一枚op，有運(yùn)營過nginx比較長的一段時(shí)間。期間遇到些小問題，這里簡單做個(gè)總結(jié)記錄,會不定時(shí)更新：

開始扯淡 proxy_set_header的作用域限制

還記得是個(gè)后臺鑒權(quán)server需要調(diào)用方提供一個(gè)QC_REAL_IP的http頭做校驗(yàn)，我在nginx里配置如下:

proxy_set_header QC_REAL_IP $http_host;                                                                              
location ^~/authorize/ {
    proxy_set_header Host  $http_host;
    proxy_pass   http://authorize_server;
    proxy_redirect off;
}

但是，卻發(fā)現(xiàn)鑒權(quán)不成功，一直是返回503。掏出tcpdump抓包

tcpdump -i eth1 -nn -Als0p "tcp and host author_server_ip and port author_server_port"

發(fā)現(xiàn)nginx發(fā)出的包頭里沒有QC_REAL_IP字段，遂翻閱nginx wiki，找到這行
proxy_set_header directives issued at higher levels are only inherited when no proxy_set_header directives have been issued at a given level.
原來proxy_set_header不完全是繼承關(guān)系！把QC_REAL_IP的配置copy一份到location里，終于生效了。

https業(yè)務(wù)proxy_pass的HOST頭設(shè)置

剛開始拿nginx做proxy，一般proxy_pass和upstream的名字一致，有多個(gè)proxy_pass就加數(shù)字.例如：

upstream xxoo.com {
     server 10.8.8.8:8080;
}
upstream xxoo.com_2 {
     server 10.8.8.8:8088;
}

server {
        listen 443;    
        server_name xxoo.com
        ... ...
        location /api/user/ {
            proxy_pass http://xxoo.com;
            proxy_redirect off;
        }
            location /api/pay/ {
            proxy_pass http://xxoo.com_2;
            proxy_redirect off;
        }
    }

重啟nginx后，訪問測試pay接口第一個(gè)https訪問是正常的，但由后端server返回的302跳轉(zhuǎn)全部變成了http請求。在nginx和后端機(jī)器tcpdump抓包分析，發(fā)現(xiàn)pay接口從nginx過去的請求頭Host是xxoo.com_2，而user接口是xxoo.com則302跳轉(zhuǎn)https正常!
所以nginx的proxy模塊請求backend的http header中Host字段指就是proxy_pass 指令的值。nginx根據(jù)該Host是否和server_name匹配絕對是否對前端返回https。

透傳客戶端ip

一般情況我在nginx接入側(cè)配置這條足以：

proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;

proxy_add_x_forwarded_for的值為: 客戶端穿過來的x_forwarded_for值+ remote_addr。如果客戶端傳來的x-forwarded-for值本事是非法、錯(cuò)誤的。那么后端應(yīng)用如果截取左起第一個(gè)字段獲取到的ip值也是錯(cuò)誤。
這個(gè)一般有2個(gè)辦法，首先，可以在nginx接入對很明顯非法的ip摘掉，強(qiáng)制把remote_addr值添到X-Forwarded-For字段：

set $my_proxy_add_x_forwarded_for $proxy_add_x_forwarded_for;
if ($proxy_add_x_forwarded_for ~* "127.0.0.1"){
   set $my_proxy_add_x_forwarded_for $remote_addr;
}
proxy_set_header   X-Forwarded-For $my_proxy_add_x_forwarded_for;

另外，如果是做ip頻率限制、校驗(yàn)的話，還不如直接取X-Forwarded-For值的最后一段。因?yàn)閭卧靫-forword-for值成本太低了。

404返回碼轉(zhuǎn)換

有個(gè)很老的接口拉取資料返回給客戶端，不時(shí)的出現(xiàn)404，但對業(yè)務(wù)沒影響。開發(fā)人力不足以重構(gòu)這個(gè)接口，為了不影響調(diào)用成功率，想都設(shè)置為返回成功:200,302之類的狀態(tài)碼

location / {   
    error_page 404 =302 /404.html;   
}

記錄慢日志

為提高api接口的運(yùn)營質(zhì)量，同時(shí)也方便定位一些奇怪的問題。需要記錄nginx的慢日志，有個(gè)簡單粗暴的辦法，利用nginx+lua直接打日志。

log_by_lua "
     if tonumber(ngx.var.upstream_response_time) > 3 then
        local status_code = ngx.var.upstream_status
        local time_ts= ngx.localtime()
        local upstream_res_time= ngx.var.upstream_response_time
        ngx.log(ngx.ERR, "[SLOW] upstream_responce_time:" .. upstream_res_time .. ", upstream_http_code:" .. status_code ..",");
     end    
 ";

跨域設(shè)置CORS

這個(gè)沒啥技巧，為方便前端開發(fā)，在接入層打開跨域資源共享。但從安全角度考慮，不能完全打開限制，所以對業(yè)務(wù)的幾個(gè)referer域名做了正則匹配。

if ($http_referer ~ http://(.*).(xx1|xx2|xx3).(com|cn)(/*.*)){
     add_header Access-Control-Allow-Credentials true;
     add_header Timing-Allow-Origin http://$1.$2.$3;
     add_header Access-Control-Allow-Origin http://$1.$2.$3;
 }