SnippetsFilter is applied to Nginx config but not working

[rr-krupesh-savaliya]

Describe the bug
I applied large_client_header_buffers via SnippetsFilter but it's not taking affect.

To Reproduce
Steps to reproduce the behavior:

1. Deploy below SnippetsFilter and Update HTTPRoute

apiVersion: gateway.nginx.org/v1alpha1
kind: SnippetsFilter
metadata:
  name: nginx-custom-config-snippet
  namespace: nginx-gateway
spec:
  snippets:
    - context: http.server
      value: |
        large_client_header_buffers 4 16k;
        client_header_buffer_size 16k;

3. Connect the gateway nginx pod and see the nginx config
4. You will see include /etc/nginx/includes/SnippetsFilter_http_nginx-gateway_nginx-custom-config-snippet.conf at it contains the custom configs
5. But when you pass header size more than 8k length then we are getting 400 instead of 200 status code.

Your environment

• NGINX Gateway Fabric - 2.3.0
• Version of Kubernetes - v1.33
• Kubernetes platform - EKS
• Details on how you expose the NGINX Gateway Fabric Pod - LoadBalancer and Port-forward (Also tried)
• nginx -T - Valid

Testing

Worked if <8K -> 200 OK

curl -I -H "X-Custom-Header: $(python3 -c 'print("b"*8000)')" http://test.com

Not Working if >8K and <16K -> 400 Bad Request ( but it should be work till 16k header size )

curl -I -H "X-Custom-Header: $(python3 -c 'print("b"*15000)')" http://test.com

[nginx-bot]

Hi @rr-krupesh-savaliya! Welcome to the project! 🎉

Thanks for opening this issue!
Be sure to check out our Contributing Guidelines and the Issue Lifecycle while you wait for someone on the team to take a look at this.

[rr-krupesh-savaliya]

@shaun-nx could you please help here.

[shaun-nx]

Hi @rr-krupesh-savaliya thanks for reporting this! Looking into this now. I'll get back to you asap 😃

[rr-krupesh-savaliya]

@shaun-nx @dhurley @ciarams87 Could someone please take a look at this issue?

[sjberman]

@rr-krupesh-savaliya This is being looked into, as mentioned in Shaun's comment.

Also, you are tagging people who no longer work on this team. I'm going to remove tags from your comment so we hopefully don't spam people who don't need to see this.

[ciarams87]

Hi @rr-krupesh-savaliya

The problem you're experiencing is due to how NGINX processes request headers and applies buffer configurations during virtual server selection.

NGINX must read and parse request headers before it can determine which virtual server to route the request to (based on the Host header). Because of this, NGINX uses the default server's buffer settings during the initial header parsing phase, regardless of which server block ultimately handles the request.

When you set large_client_header_buffers at the http.server context using SnippetsFilter, this configuration is applied to your named virtual server (e.g., server_name test.com), but not to the default/catch-all server that NGINX Gateway Fabric creates. Since buffer allocation happens during initial header parsing, only the default server's buffer settings are consulted.

See NGINX Virtual Server Selection for more information

Solution

You need to set the buffer directives at the http context level instead of http.server:

apiVersion: gateway.nginx.org/v1alpha1
kind: SnippetsFilter
metadata:
  name: nginx-custom-config-snippet
  namespace: nginx-gateway
spec:
  snippets:
    - context: http
      value: |
        large_client_header_buffers 4 16k;
        client_header_buffer_size 16k;

This should apply the buffer settings globally to all servers, including the default server that handles initial request processing.

Hope this helps!

[rr-krupesh-savaliya]

@ciarams87 I tried that as well but it's not working.

apiVersion: gateway.nginx.org/v1alpha1
kind: SnippetsFilter
metadata:
  name: nginx-custom-config-snippet
  namespace: nginx-gateway
spec:
  snippets:
    - context: http
      value: |
        client_header_buffer_size 16k;
        large_client_header_buffers 4 16k;
    - context: http.server.location
      value: |
        add_header X-Snippet-Works yes always;

Curl Output:

curl -I -H "X-Custom-Header: $(python3 -c 'print("b"*9000)')" https://test.com
HTTP/1.1 400 Bad Request
Server: nginx
Date: Tue, 27 Jan 2026 14:06:42 GMT
Content-Type: text/html
Content-Length: 233
Connection: keep-alive
X-Snippet-Works: yes

[rr-krupesh-savaliya]

@ciarams87 I tried with context http and http.server as well as both together but no any scenario working as expected.

[ciarams87]

@rr-krupesh-savaliya I believe the issue might not be with NGINX Gateway Fabric but with your backend service. Can you confirm your backend server is configured to accept large headers?

In my local testing, the NGF dataplane is correctly accepting and forwarding large headers with the client header buffer directives at the http context level, but I saw 400 errors when I used the default nginx-hello images we use in our examples. When I changed my test backend application to run a basic python server with no header size restrictions, my request was successful. If your backend is also running NGINX (or has its own header size limits), you need to configure buffer settings there as well.

To confirm if this is a proxy or a backend problem, you can check the gateway-nginx logs. If you do not see something like

2026/01/28 12:01:03 [info] 1057#1057: *434 client sent too long header line: "X-Custom-Header: bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb..." while reading client request headers, client: 127.0.0.1, server: cafe.example.com, request: "GET /tea HTTP/1.1", host: "cafe.example.com:8080"

the issue is most likely from the backend server.

[rr-krupesh-savaliya]

@ciarams87 Yeah, I tried with different image and it worked. Thanks

Issue with demo application image.