1) proxy_pass
转发下?感觉事情没那么简单。
location / {
...
proxy_pass https://example.com;
proxy_set_header Host example.com;
proxy_set_header Referer https://example.com;
...
}
2) 尝试修改绝对 URL,将对方域名变成我方域名,避免打开非业务域名。
location / {
...
proxy_set_header Accept-Encoding '';
sub_filter_types *;
sub_filter_once off;
sub_filter 'example.com' 'yourdomain.com';
...
}
3) 有些网站无视 Accept-Encoding: ''
,不管三七二十一,统统返回压过的。sub_filter
又只能处理未经压缩的内容,所以替换失败。
先来看人家怎么办到的。第一个 location /
是对方 frontend 端的配置,向 upstream 请求压缩过的资料;第二个 location /
则是对方 backend 端的配置,开启 Gzip,并允许在 HTTP/1.0 压缩。
location / {
...
proxy_set_header Accept-Encoding 'gzip';
...
}
Nginx 默认以 HTTP/1.0 连接上游,偏偏
gzip_http_version
缺省值是 1.1,表现为对后端不启用 Gzip,所以…
location / {
...
gzip on;
gzip_http_version 1.0;
...
}
4) 思路清晰了有没有?先解压、再替换就好了呗。
做两次 proxy_pass
,先反代源站 gzip 过的内容,再反代一次即可获得未压缩的内容。这里假设第一次的 location 在 forward 目录,第二次的在根目录。
⚠️ 上面的 gunzip on
和下面的 proxy_set_header Accept-Encoding ''
互为替代。
location /forward {
...
proxy_pass https://example.com;
# proxy_set_header Accept-Encoding 'gzip';
# gunzip on;
...
}
location / {
...
proxy_pass https://yourdomain.com/forward;
proxy_set_header Accept-Encoding '';
sub_filter_types *;
sub_filter_once off;
sub_filter 'example.com' 'yourdomain.com';
...
}
⚠️ 即使您在 Step 2 透过禁用压缩的方式顺利替换,也可以试看看 Step 4。这种需求很能吃出站流量,带宽嘛,总是省一点算一点。
© 版权声明
文章版权归作者所有,未经允许请勿转载。
THE END
暂无评论内容