Envoy returning HTTP 301 locally before upstream routing (attempts=0) (Envoy-Version 1.33.0)

[sy-ibm]

Hi Envoy Community,

We're investigating an issue where Envoy returns an HTTP 301 response for a POST request before any upstream routing attempt is made.

Environment

• Open-source Envoy
• Listener configured with downstream TLS on port 17600
• Requests arrive through NGINX and are forwarded to Envoy
• Routing is performed using cluster_header

Relevant configuration:

{
  "route": {
    "cluster_header": "v4-deployment-id",
    "timeout": "180s"
  }
}

Virtual host:

{
  "name": "service",
  "domains": ["*"],
  "require_tls": "all"
}

Envoy Logs

HTTP/1.1" 301 0 0 x-request-id="cac27d81-9302-4cfd-9532-013695d0bf11" x-global-transaction-id="230c3135a01d2e18f01a65e94508ad85" "watsonxgovernance-dev-ind.ey.com" "-" "-" rt="0" uct="-" attempts="0"

Observations

• Envoy receives the request and generates a 301 response.
• attempts=0
• uct=-
• No upstream host is selected.
• No backend service receives the request.
• The response contains a Location header pointing back to the same URL.
• Postman subsequently follows the redirect and converts the POST into GET requests, resulting in repeated 301 responses.

Additional Information

When calling the Envoy service directly from the nginx pod, Envoy successfully processes the request and routes it upstream, which suggests that routing and cluster resolution are generally functioning.

Questions

• Under what conditions does Envoy generate a local 301 response before any upstream routing attempt (attempts=0)?
• Can require_tls: all generate a redirect even when the original client request is HTTPS?
• Are there specific headers (x-forwarded-proto, :scheme, etc.) that influence this behavior?
• Which admin endpoint or debug logging category would identify the exact Envoy component that generated the redirect?

Any guidance would be appreciated.

[sy-ibm]

Closing this discussion as I was able to resolve the Issue

[dlanov]

The root cause is require_tls: all on the virtual host combined with NGINX not forwarding the correct scheme header to Envoy.

What require_tls: all does

When a virtual host has require_tls: all, Envoy checks the :scheme pseudo-header (HTTP/2) or x-forwarded-proto header (HTTP/1.1) on the incoming request to determine whether the downstream connection is TLS. If it sees http (or the header is absent), it immediately generates a local 301 redirect to the HTTPS equivalent — before any cluster selection, hence attempts=0 and uct=-.

This happens even if the physical connection between NGINX and Envoy is over TLS. Envoy doesn't inspect the socket's TLS state for this decision — it trusts the headers.

Why it works when called directly from the NGINX pod

When you call Envoy directly from inside the cluster, the request arrives with a proper TLS handshake and Envoy's downstream TLS listener sets :scheme: https internally. No NGINX is involved, so no header stripping occurs.

When NGINX proxies the request, it may:

• Set x-forwarded-proto: http if the original client-to-NGINX leg was HTTP
• Omit x-forwarded-proto entirely, causing Envoy to default to http
• Not pass :scheme: https if using HTTP/1.1 to talk to Envoy

The fix

Tell NGINX to forward the correct proto header:

  proxy_set_header X-Forwarded-Proto https;
  # or, to reflect what the original client used:
  proxy_set_header X-Forwarded-Proto $scheme;

Envoy will then see x-forwarded-proto: https, satisfy the require_tls: all check, and route normally.

Alternatively, if you don't need the redirect enforcement and just want mutual TLS between NGINX and Envoy, remove require_tls: all from the virtual host — the downstream TLS listener already enforces the TLS handshake.

Confirming the exact trigger

Use Envoy's access log %RESPONSE_FLAGS% field — a local 301 from require_tls will show the flag RL (redirect local). Add it to your access log format:

  access_log:
    - name: envoy.access_loggers.stdout
      typed_config:
        "@type": type.googleapis.com/envoy.extensions.access_loggers.stream.v3.StdoutAccessLog
        log_format:
          text_format: "%REQ(:METHOD)% %REQ(X-FORWARDED-PROTO)% %RESPONSE_FLAGS% %RESPONSE_CODE%\n"

If %RESPONSE_FLAGS% shows RL and %REQ(X-FORWARDED-PROTO)% shows http or -, the diagnosis above is confirmed.