快捷導(dǎo)航

golang反向代理設(shè)置host不生效的問題解決

更新時間：2023年05月27日 10:03:45 作者：鐵柱同學(xué)

在使用golang的httputil做反向代理的時候，發(fā)現(xiàn)一個奇怪的現(xiàn)象，上游網(wǎng)關(guān)必須要設(shè)置host才行，不設(shè)置host的話，golang服務(wù)反向代理請求下游會出現(xiàn)http 503錯誤，接下來通過本文給大家介紹golang反向代理設(shè)置host不生效問題，感興趣的朋友一起看看吧

一、背景

在使用golang的httputil做反向代理的時候，發(fā)現(xiàn)一個奇怪的現(xiàn)象，上游網(wǎng)關(guān)必須要設(shè)置host才行，不設(shè)置host的話，golang服務(wù)反向代理請求下游會出現(xiàn)http 503錯誤。服務(wù)調(diào)用順序如下：

在這里插入圖片描述

二、排查過程

1、打印req.header

差異字段主要是：Forwarded和GFS.scg.ip字段。

（1）GFS.scg.ip
Gfs.scg.ip 是 Spring Cloud Gateway 中的一個自定義請求頭部字段，用于在路由
中傳遞客戶端的 IP 地址信息。
（2）Forwarded
在 HTTP 請求中，F(xiàn)orwarded 是一種標(biāo)準(zhǔn)化的請求頭，用于識別原始客戶端和代理之間
的連接信息。該字段的值包括一系列鍵值對，每個鍵值對都表示一個不同的屬性。

此時為了排除網(wǎng)關(guān)設(shè)置header對請求的影響，在goproxy中清空header且重新嘗試，發(fā)現(xiàn)請求依然是503。

req.Header = http.Header{}
req.Header.Set("traceId", traceId)
req.Header.Set("host", "XXX")

2、tcpdump抓包分析

# 抓取請求本機8080端口的請求
sudo tcpdump -i wlo1 -A  port 8080
# 抓取本機發(fā)出的http請求
sudo tcpdump -i wlo1 -A dst host 下游域名

（1）先抓取8080端口的請求，查看header差異

host: xxx # 網(wǎng)關(guān)不設(shè)置header的時候，host是本機ip
host: localization.xx # 網(wǎng)關(guān)設(shè)置header的時候，host為目標(biāo)主機域名

如上所示，可以得到結(jié)論，host本來就代表目標(biāo)主機，網(wǎng)關(guān)那邊設(shè)置host的時候，golang服務(wù)進(jìn)行轉(zhuǎn)發(fā)，會把host帶到下游python服務(wù)，此時host是符合預(yù)期的，因此可以請求成功。

網(wǎng)關(guān)不帶host的時候，host地址為本機ip，此時發(fā)送http請求，對下游python服務(wù)來說，host是不符合預(yù)期的，因此請求失敗。

因此，當(dāng)網(wǎng)關(guān)不設(shè)置host的時候，golang服務(wù)必需要設(shè)置host才能訪問到算法服務(wù)。

（2）抓取目標(biāo)域名請求體

1）網(wǎng)關(guān)沒有配置header,且proxy清空header

# sudo tcpdump -i wlo1 -A dst host 下游python服務(wù)域名
......Pa.I.....P...(...POST /xxx?xxx=test HTTP/1.1
Host: 10.xx:8080
Content-Length: 3013
Traceid: f70cef79265d41be80002ab8ee10abf5
Traceparent: 00-f70cef79265d41be80002ab8ee10abf5-07f71cc5604c734a-00

2）網(wǎng)關(guān)配置header,且proxy清空header

# sudo tcpdump -i wlo1 -A dst host 下游python服務(wù)域名
......P!.....Q`P...(...POST /location?map_id=test HTTP/1.1
Host: 下游python服務(wù)域名
Content-Length: 3013
Traceid: 972e155927b3fcf665550ab0824acb87
Traceparent: 00-972e155927b3fcf665550ab0824acb87-627675466a61796b-7462733d667273

可以發(fā)現(xiàn)，差異主要就在host部分。也就說，網(wǎng)關(guān)設(shè)置了header之后，tcpdump抓包的host是符合預(yù)期的。
我們在golang服務(wù)中設(shè)置req.Header發(fā)現(xiàn)依然沒有效果，抓包結(jié)果顯示host不符合預(yù)期，預(yù)期是下游python服務(wù)域名才對。

3、go設(shè)置host方式

目前go中設(shè)置host一共有三種方式：

req.Host
	req.Host 是一個字符串類型的字段，表示了 HTTP 請求頭部中的 Host 信息。
	如果該字段為空，則默認(rèn)使用請求的目標(biāo)地址（即 req.URL.Host）作為 Host 信息。
req.Header.Set("host")  # 目前使用且設(shè)置host失效
	header中的host字段。
req.URL.HOST
	request.URL.Host 是一個字符串類型的字段，表示 HTTP 請求中目標(biāo)
	地址的 HOST信息,跟URL是對應(yīng)的。

代碼中使用的是req.Header.Set("host")的方式，但是沒有生效。

proxy.Director = func(req *http.Request) {
		originalDirector(req)
		modifyRequest(req)
		// 添加自定義標(biāo)頭
		req.Header.Set("traceId", traceId)
		req.Header.Set("host", "xxx")
		log.Infof("req.Header:(%#v)", req.Header)
	}
打印結(jié)果，沒有host!!!

（1）打印req.URL.HOST

打印req.URL，發(fā)現(xiàn)url中的host已經(jīng)被替換了。因為httputil包在使用反向代理的時候，會觸發(fā)一個rewrite方法，把target的host設(shè)置到req.URL.HOST

req.url:(\u0026url.URL{Scheme:\"http\", Opaque:\"\", User:(*url.Userinfo)(nil), 
Host:\"下游python服務(wù)域名\", 
Path:\"/xx\", RawPath:\"\", OmitHost:false, ForceQuery:false, 
RawQuery:\"map_id=test\", Fragment:\"\", RawFragment:\"\"}

# proxy源碼
func NewSingleHostReverseProxy(target *url.URL) *ReverseProxy {
	director := func(req *http.Request) {
		rewriteRequestURL(req, target)
	}
	return &ReverseProxy{Director: director}
}
func rewriteRequestURL(req *http.Request, target *url.URL) {
	targetQuery := target.RawQuery
	req.URL.Scheme = target.Scheme
	req.URL.Host = target.Host
	req.URL.Path, req.URL.RawPath = joinURLPath(target, req.URL)
	if targetQuery == "" || req.URL.RawQuery == "" {
		req.URL.RawQuery = targetQuery + req.URL.RawQuery
	} else {
		req.URL.RawQuery = targetQuery + "&" + req.URL.RawQuery
	}
}

（2）設(shè)置req.Host

設(shè)置之后進(jìn)行tcpdump抓包，發(fā)現(xiàn)host已經(jīng)被成功設(shè)置，http請求成功。

......P.H......P...(...POST /location?map_id=test HTTP/1.1
Host: 下游python服務(wù)域名
Content-Length: 3013
Traceid: 447e2cc680bed4f2fbfd3941bcda4a42
Traceparent: 00-447e2cc680bed4f2fbfd3941bcda4a42-fffc5c1b967b3f70-7462733d667273