X-Request-id issues

Hey everyone,
I had a question regarding the X-Request-ID header behaviour in NGINX.
Our setup is: ALB → NGINX → service pods.
We recently noticed that NGINX can automatically generate a X-Request-ID, which we’re using as the request ID (rid) in our backend.
However, we ran into an issue:
If a service takes more than 60 seconds to respond, the ALB (which has a 60-second timeout) returns a 504. At that point, NGINX assumes the client has disconnected and logs a 499 response. But right after that, a new request is sent to the server with the same rid, even though the backend was still processing the original request.
So the backend ends up handling both requests — even though the client only expects one — and since the client has already timed out, the response never reaches it.
Additionally, we’ve observed that sometimes NGINX generates the X-Request-ID, and other times it doesn’t. This inconsistent behaviour is confusing.
So, I have two questions:

  1. Under what conditions (if any) can NGINX retry a request using the same X-Request-ID?
  2. Why does NGINX show random behaviour when generating X-Request-ID — is it based on certain conditions, or config?

Would really appreciate any insights or suggestions on how to handle this better!

1 Like

Can you share a bit more about your setup? Are you using the NGINX Ingress Controller? If yes, which version, Plus or OSS?

yes NGINX Ingress Controller and that too OSS version

@Vaibhav_Badhani can you try using:
proxy_set_header X-Request-ID $request_id;
proxy_next_upstream error timeout ;
proxy_next_upstream_tries ;

in your config? I you’re using Nginx Ingress Controller then server-snippets will be the best way to insert raw nginx configuration

1 Like