为什么sub_filter与proxy_pass结合使用时似乎不起作用?

为什么sub_filter与proxy_pass结合使用时似乎不起作用?

假设 nginx 的配置如下:

server {
    listen  80;
    server_name apilocal;
    sub_filter  "apiupstream/api" "apilocal";
    sub_filter_once off;
    location /people/ {
            proxy_pass  http://apiupstream/api/people/;
            proxy_set_header Accept-Encoding "";
    }
}

Sub_filter 无法正确响应部分响应。一旦我从配置中删除 proxy_pass,它就可以正常工作。许多遇到此问题的人最终都从上游服务器获得了 gzip 压缩。我已经验证了我的上游服务器没有为其响应启用 gzip 编码。但为了以防万一,我还使用了上面的 proxy_set_header 来不接受 gzip。

我是否还遗漏了其他什么东西?

答案1

sub_filter_types您的回应可能具有默认定义以外的其他内容类型。

参考:http://nginx.org/r/sub_filter_types

答案2

James T Snell 在评论中回答了这个问题:

我没有 proxy_set_header Accept-Encoding“”;您需要它来告诉后端响应中不允许压缩。

答案3

它是否需要位于位置块内?此外,匹配参数上可能没有引号?

http://wiki.nginx.org/HttpSubModule

location / {   sub_filter      
      </head>   
      '</head><script
      language="javascript" src="$script"></script>';   
      sub_filter_once on;
}

答案4

在 kubernetes 上使用 ingress 控制器,这是我修复它的方法:

    nginx.ingress.kubernetes.io/configuration-snippet: |
      proxy_set_header Accept-Encoding "";
      sub_filter_once off;
      sub_filter_types *;
      sub_filter 'http:' 'https:';

但我将其限制为需要替换的 PATH:

spec:
  rules:
  - host: xyz.company.local
    http:
      paths:
      - pathType: Exact
        path: /my-exact-path
        backend:
          # ...

相关内容