HTTP 502 Bad Gateway When Logging in to Ververica Platform behind Ingress-nginx

Issue

Users cannot log in to the Ververica Platform web console. The browser reaches the login page and completes authentication with the identity provider, but the final redirect back to the platform fails with:

Bad gateway Error code 502

The failure occurs on the OIDC callback URL only:

https://<platform-host>/authentication/callback?client_name=<client>&state=...&code=... 

Key characteristics that distinguish this issue from a backend outage:

• All platform pods are Running and ready.
• The api-gateway service has a ready endpoint.
• Unauthenticated paths respond normally. Requesting / returns HTTP 302 and /favicon.ico returns HTTP 200.
• The identity provider itself succeeds. The token exchange returns HTTP 200.
• Only the request to /authentication/callback returns 502.

The ingress controller log records the following error at the moment of the failed login:

[error] upstream sent too big header while reading response header from upstream, client: <client-ip>, server: <platform-host>, request: "GET /authentication/callback?client_name=<client>&state=...&code=...", upstream: "http://<pod-ip>:8080/authentication/callback?..." 

ENVIRONMENT

This issue is not specific to version 3.1.3. It applies to any Ververica Platform release exposed through ingress-nginx with OIDC single sign-on enabled, because the cause lies in the ingress buffer configuration rather than in the platform itself.

RESOLUTION

Increase the proxy buffer size on the ingress resource that fronts the api-gateway service.

OPTION 1: ANNOTATE THE INGRESS (RECOMMENDED)

Apply the annotations to the affected ingress only:

kubectl annotate ingress <ingress-name> -n <platform-namespace> \
   nginx.ingress.kubernetes.io/proxy-buffer-size=32k \
   nginx.ingress.kubernetes.io/proxy-buffers-number=4 \
   --overwrite 

The ingress controller reloads its configuration within a few seconds. No pod restart is required.

Verify the annotations were written:

kubectl get ingress <ingress-name> -n <platform-namespace> \
   -o jsonpath='{.metadata.annotations}' 

Then retry the login in a new private browser window. A stale or partial session cookie from the failed attempt can otherwise mask a successful fix.

If 32k is not sufficient, raise the value to 64k. Large group or role claims, or identity brokering that copies claims from an upstream provider, can produce larger session cookies.

OPTION 2: SET THE VALUE GLOBALLY

If several applications behind the same controller need the larger buffer, set it in the ingress-nginx ConfigMap instead:

data:   proxy-buffer-size: "32k" 

This applies to every ingress served by that controller. Prefer Option 1 when only the platform requires it, so that the blast radius stays small.

IMPORTANT: MAKE THE CHANGE PERSISTENT

Check whether the ingress resource is managed by Helm:

kubectl get ingress <ingress-name> -n <platform-namespace> \
    -o jsonpath='labels={.metadata.labels}{"\n"}ownerRefs={.metadata.ownerReferences}{"\n"}' 

• If the output shows app.kubernetes.io/managed-by: Helm or a meta.helm.sh annotation, add the annotations to your Helm values so that a later helm upgrade does not revert them.
• If the ingress is created outside Helm, by a separate manifest or infrastructure-as-code definition, add the annotations to that source. A kubectl annotate command alone survives upgrades but is lost whenever the environment is destroyed and rebuilt.

CAUSE

The root cause is the default response header buffer in nginx, not a fault in the Ververica Platform.

When single sign-on completes, the identity provider redirects the browser to /authentication/callback on the platform host. The api-gateway component handles that request, establishes the user session, and returns a response carrying a Set-Cookie header that holds the OIDC session material.

That header is large. Its size grows with:

• The number and length of claims requested through the OIDC scope, such as openid, profile, and email.
• Group or role claims, which expand with the number of groups a user belongs to.
• Identity brokering, where an upstream provider such as Google contributes additional claims that the broker copies into the session.

The ingress-nginx controller buffers the upstream response header before forwarding it to the client. The default proxy_buffer_size is 4k. When the response header exceeds that buffer, nginx cannot process the response, logs upstream sent too big header, discards the response, and returns HTTP 502 to the browser.

This explains each observed symptom:

• The backend is healthy, because the platform generates a valid response. The response is rejected in transit by the proxy.
• Only the callback fails, because it is the single response in the flow that carries the full session cookie. Other responses stay well below 4k.
• Authentication at the identity provider succeeds, because that exchange happens before the oversized response is produced.

Raising proxy-buffer-size gives nginx enough room to buffer the header and forward it intact.

RELATED INFORMATION

• ingress-nginx annotations reference, including proxy-buffer-size and proxy-buffers-number: https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/
• ingress-nginx ConfigMap reference, for setting the value globally: https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/
• nginx proxy_buffer_size directive documentation: https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_buffer_size
• Ververica documentation portal: https://docs.ververica.com

RELATED SYMPTOM, NOT A CAUSE OF THIS ISSUE

While investigating, the ingress controller may also log:

Error getting SSL certificate "<namespace>/<secret-name>": local SSL certificate <namespace>/<secret-name> was not found. Using default certificate 

This indicates that the ingress declares a TLS secret that does not exist, so the controller serves its default self-signed certificate. The result is a browser certificate warning, not an HTTP 502. Address it separately by creating the certificate, for example through a cert-manager issuer annotation, or by removing the unused tls section from the ingress.

DIAGNOSTIC COMMANDS

Confirm the backend is healthy before changing ingress settings:

# Pods and endpoints 
kubectl get pods -n <platform-namespace> 
kubectl get endpointslice -n <platform-namespace> \
   -l kubernetes.io/service-name=api-gateway  

# Reach the service directly, bypassing the ingress. HTTP 302 is expected. 
kubectl run curltest --rm -i --restart=Never --image=curlimages/curl -- \
   -s -o /dev/null -w "HTTP %{http_code}\n" \
   http://api-gateway.<platform-namespace>.svc:8080/  

# Look for the buffer error in the ingress controller log 
kubectl logs -n <ingress-namespace> <ingress-controller-pod> | grep "too big header" 

Written by Jun Qin · Published 23 September 2026