日常维护 jubt.net ,发现一个反向代理的网站失效了。
此网站在JavaScript脚本中会判断window.location.href是否为 官网地址,如果不是,则会通过在JavaScript脚本中设置 window.location.href 为官网地址,重定向到官网地址。(具体细节挺复杂,方案使用了挺有特色的编码方案,有机会再单写一篇文章讲解,此方案对反盗链、反镜像挺有借鉴意义。)。
在反向代理中使用了 Nginx反向代理使用的一些坑(续)–gzip/gunzip 与sub_filter的那些事 中描述的方案:
proxy_pass https://upstream.com/; gunzip on; sub_filter 'upstream.com' 'mydomain.com'; sub_filter_once off;
抓包查看页面跳转逻辑,发现sub_filter没起作用。
排查原因,发现反向代理服务器缺省没有设置 Accept-Encoding值, 网站返回的 Content-Encoding:br 。
因此怀疑可能是br压缩算法不支持导致的,因此在请求中增加Accept-Encoding “gzip,deflate”;
proxy_set_header Sec-Fetch-Mode "navigate"; proxy_set_header Sec-Fetch-Site "cross-site"; proxy_set_header Cache-Control "max-age=0"; proxy_set_header Accept-Encoding "gzip,deflate";
设置 Accept-Encoding “gzip,deflate” 后 sub_filter 生效了。
经过测试,发现此网站调整后会检测Accept-Encoding,如果客户端未设置Content-Encoding或设置为支持br压缩,则强制返回Content-Encoding:br。如果强制指定了只支持gzip,defalte,则Content-Encoding:gizp.defalter。
这里的br压缩算法指的是Brotli,维基百科的介绍
另外浏览器中常用的压缩算法还是:Accept-Encoding:gzip, deflate, sdch, br
常用HTTP 内容协商字段
请求头字段 | 说明 | 响应头字段 |
---|---|---|
Accept | 告知服务器发送何种媒体类型 | Content-Type |
Accept-Language | 告知服务器发送何种语言 | Content-Language |
Accept-Charset | 告知服务器发送何种字符集 | Content-Type |
Accept-Encoding | 告知服务器采用何种压缩方式 | Content-Encoding |
例如客户端发送以下请求头:
Accept-Encoding:gzip,deflate,br
浏览器的响应头可能是这样的:
Content-Encoding: br
转载请注明:虚拟号之家 » Nginx反向代理使用的一些坑(续)–gzip,br压缩算法 与sub_filter的那些事