← Problem Library
K8s L5 K8S 1183 · 24 min

Ingress NGINX returns 400 on WebSocket path because upgrade headers stop at one proxy hop

Normal HTTP requests work, but WebSocket traffic fails because one proxy tier in front of ingress-nginx drops the upgrade semantics.

K8sPlatform ReliabilityLevel 5Pro24 min
Scenario

A public ingress-nginx snippet was copied into production. Browser requests work until the WebSocket path crosses an extra proxy boundary.

What to check first
  • Identify the primary failure signal in the Ingress Protocol Debug scenario.
  • Separate visible symptoms from the underlying technical dependency.
  • Describe the safest recovery path and the follow-up prevention work.
Checking checklist
  1. Summarize the current impact and the last known change.
  2. Collect direct evidence from logs, runtime state, and configuration before changing anything.
  3. Separate immediate recovery from permanent prevention work.
Recovery and prevention

Trace Upgrade and Connection handling hop by hop before changing backend code.

Questions worth viewing together
What should you verify first when Ingress NGINX returns 400 on WebSocket path appears?

Ingress WebSocket troubleshooting scenario based on Stack Overflow and Reddit reports where 400 errors came from dropped upgrade headers. Compare a working HTTP request with a failing WebSocket request at each proxy boundary.

What usually causes Ingress NGINX returns 400 on WebSocket path in production?

Teams often blame the application when the upgrade headers never reach it.

What should you document after resolving Ingress NGINX returns 400 on WebSocket path?

One missing proxy_set_header can break the entire WebSocket chain through NGINX.