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