排查Openresty獲取不到Host請求頭解決過程詳解
開篇
前幾天給客戶部署服務(wù),把服務(wù)都啟動(dòng)完成,準(zhǔn)備驗(yàn)證的時(shí)候,發(fā)現(xiàn)怎么都訪問不到服務(wù),但在服務(wù)器里面通過curl
來訪問接口發(fā)現(xiàn)服務(wù)是通的,于是展開了一場漫長的排查過程。
服務(wù)框架
先說一下我們服務(wù)的部署框架,用openresty
作為反向代理層、docker
部署具體的服務(wù)。簡化的架構(gòu)圖如下。
問題排查
瀏覽器訪問服務(wù),經(jīng)過openresty
轉(zhuǎn)發(fā)到具體的服務(wù)。我們服務(wù)有兩個(gè)域名,比如叫 a.example.com
和 b.example.com
。
在發(fā)現(xiàn)訪問不同時(shí),立刻查看了openresty
的日志,發(fā)現(xiàn)無論是a域名
還是b域名
的請求,日志顯示全部打到a域名
上去了。
再看日志的詳細(xì)信息發(fā)現(xiàn)openresty
的$host
值不是域名而是ip。發(fā)現(xiàn)這個(gè)后,打開瀏覽器調(diào)試工具,重新刷新頁面,發(fā)現(xiàn)瀏覽器的請求是有$host
值的。
那是哪一步把$host
丟了呢?在我們服務(wù)的openresty
上一層可能還存在其他的代理層?感覺有這個(gè)可能,之前客戶說過他們也有幾層代理。一般代理都是nginx
,難道nginx
轉(zhuǎn)發(fā)請求到openresty
會(huì)把host
丟了嗎?應(yīng)該不會(huì)啊。
找來客戶的運(yùn)維,問他我們服務(wù)的上一層有沒有代理,他們說有其他代理,然后說,他們用的是Apache
做的代理。
嗯?Apache
?不好意思,觸及到我的知識(shí)盲區(qū)了,只是聽說過,并沒有實(shí)際的用過。Apache
轉(zhuǎn)發(fā)請求到openresty
會(huì)把host
丟失嗎?這個(gè)我也不清楚。
然后問客戶運(yùn)維,還有沒有其他代理?他們說還有CDN
、F5
、Apache
,就這些了。
現(xiàn)在整體的架構(gòu)清楚了,架構(gòu)圖如下
好吧,代理還挺多,先聯(lián)系CDN
廠商,讓他們協(xié)助排查下,CDN
廠商還挺配合,給查了日志,發(fā)現(xiàn)從CDN
經(jīng)過的請求是有host
的。
然后,查看F5
的日志,經(jīng)過各種權(quán)限申請,終于看到了F5
的日志,發(fā)現(xiàn)F5
的日志也是有host
的。
那只剩下Apache
了,又經(jīng)過各種權(quán)限申請,查看到了Apache
的日志,嗯,找到罪魁禍?zhǔn)琢耍?code>Apache向后轉(zhuǎn)發(fā)的時(shí)候,并沒有把host
的值給帶過來。查到這里,我也松了口氣,還好不是我們服務(wù)的問題,要不然還要受一大頓批評。
既然找到原因了,就讓客戶運(yùn)維去排查為什么Apache
沒有把host
給帶過來。一個(gè)小時(shí)過去了,沒有任何回應(yīng)。。。
解決方案
此時(shí),已經(jīng)凌晨12點(diǎn)了,客戶運(yùn)維還沒有消息,咱也不能坐以待斃,想想有沒有其他辦法。
于是,在服務(wù)器上通過tcpdump
抓包,看看Apache
帶過來了什么東西。
通過抓包來看,Apache
確實(shí)沒有把host
帶過來,但是有個(gè)其他的請求頭引起了我的注意:X-Forwarded-Host
、X-Forwarded-Server
。這兩個(gè)請求頭居然有域名信息。
既然host
沒有域名信息,其他兩個(gè)頭存在,那么我是否可以做一個(gè)中轉(zhuǎn)把X-Forwarded-Host
的域名信息設(shè)置給host
呢。想了一下,是可以的,我可以再做一個(gè)中轉(zhuǎn)本機(jī)轉(zhuǎn)發(fā)到本機(jī),然后把X-Forwarded-Host
的值賦值給host
就好了,說干就干。
再添加一個(gè)default.conf文件放到openresty
的配置目錄,內(nèi)容如下:
server { listen 80; server_name _; location / { proxy_pass http://127.0.0.1:80; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header Host $http_x_forwarded_host; } access_log /data/nginx/logs/default.access.log main; }
配置好了,重啟openresty
試一下,果然可以了。大功告成!
此時(shí),已經(jīng)凌晨1點(diǎn)了,快睜不開眼了,想著終于可以睡覺了。
填坑
剛高興了沒10分鐘,客戶運(yùn)維突然我問,你們服務(wù)已經(jīng)對外提供服務(wù)了嗎,怎么會(huì)這么多日志,一會(huì)好幾個(gè)G了。瞬間不困了,趕緊查看原因,打開nginx日志,發(fā)現(xiàn)打印了好多127.0.0.1
,很不正常。
而且日志打印的很快,怎么看著有點(diǎn)像死循環(huán)?難道剛才加的openresty
配置有問題?重新看了看3個(gè)openresty
配置文件:examplea.conf
、exampleb.conf
、default.conf
,感覺沒啥問題呢,又仔細(xì)分析了下。
突然又想到,如果是一個(gè)C域名呢?
因?yàn)橹挥蠥域名和B域名的配置,沒有其他域名的配置,所以其他域名又會(huì)到default.conf
里,如此就產(chǎn)生了死循環(huán),既然找到了原因,那就好辦了繼續(xù)改吧。
最終方案
如果我加個(gè)if
判斷,只有A域名和B域名才做轉(zhuǎn)發(fā),其他域名明顯不是我的 服務(wù),直接返回200就好了。
server { listen 80; server_name _; location / { set $target_domain 0; if ($http_x_forwarded_host != 'a.example.com'){ set $target_domain "${target_domain}1"; } if ($http_x_forwarded_host != 'b.example.com'){ set $target_domain "${target_domain}2"; } if ($target_domain = "012"){ return 200; } proxy_pass http://127.0.0.1:80; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header Host $http_x_forwarded_host; } access_log /data/nginx/logs/default.access.log main; }
好了,到此問題終于解決了,更多關(guān)于Openresty獲取不到Host的資料請關(guān)注腳本之家其它相關(guān)文章!
相關(guān)文章
NGINX?權(quán)限控制文件預(yù)覽和下載的實(shí)現(xiàn)原理
我們知道,使用nginx作為文件下載服務(wù)器,可以極大地降低對后端Java服務(wù)器的負(fù)載沖擊,但是nginx本身并不提供授權(quán)控制,這下該如何操作呢,下面小編給大家?guī)砹薔GINX?權(quán)限控制文件預(yù)覽和下載的實(shí)現(xiàn)原理,感興趣的朋友跟隨小編一起看看吧2022-01-01Nginx 服務(wù)器開啟status頁面檢測服務(wù)狀態(tài)的方法
這篇文章主要介紹了Nginx 服務(wù)器開啟status頁面檢測服務(wù)狀態(tài)的方法,本文給大家介紹的非常詳細(xì),對大家的學(xué)習(xí)或工作具有一定的參考借鑒價(jià)值,需要的朋友參考下吧2024-01-01LNMPA遇到504 Gateway time-out錯(cuò)誤的解決方法
這篇文章主要介紹了LNMPA遇到504 Gateway time-out錯(cuò)誤的解決方法,需要的朋友可以參考下2017-07-07nginx tcp負(fù)載均衡的具體實(shí)現(xiàn)
Nginx是比較不錯(cuò)的開源Web服務(wù)器之一,它也可以用作TCP和UDP負(fù)載均衡器,本文主要介紹了nginx tcp負(fù)載均衡的具體實(shí)現(xiàn),具有一定的參考價(jià)值,感興趣的可以了解一下2024-05-05Nginx服務(wù)器的location指令匹配規(guī)則詳解
這篇文章主要介紹了Nginx服務(wù)器的location指令匹配規(guī)則,文中介紹了一種動(dòng)靜態(tài)地址分離的方法示例,需要的朋友可以參考下2015-12-12使用nginx部署前端項(xiàng)目的實(shí)現(xiàn)
前端項(xiàng)目的部署以前一直是把靜態(tài)資源放到后端工程中,隨后端部署一起部署,本文主要介紹了使用nginx部署前端項(xiàng)目的實(shí)現(xiàn),具有一定的參考價(jià)值,感興趣的可以了解一下2023-10-10