EnvoyFilter Patch request_timeout doesn't work

Hi there

I’m using istio 1.17
I deployed to limit request_timeout with istio EnvoyFilter

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
  name: request-timeout
  namespace: istio-system # as defined in meshConfig resource.
  - applyTo: NETWORK_FILTER # http connection manager is a filter in Envoy
      # context omitted so that this applies to both sidecars and gateways
            name: "envoy.filters.network.http_connection_manager"
      operation: MERGE
        name: "envoy.filters.network.http_connection_manager"
          "@type": "type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager"
            idle_timeout: 3600s # 1 hour
#          http2_protocol_options:
#            max_concurrent_streams: 500
#            initial_stream_window_size: 65536 # 64 KiB
#            initial_connection_window_size: 1048576 # 1 MiB
          stream_idle_timeout: 300s # 5 mins, must be disabled for long-lived and streaming requests
          request_timeout: 1s # I set it to 1 second and tested it.

I’ve tested it with api that takes a long time (db data put, delete OR sleep) but request_timeout doesn’t occur
When I checked with stream_idle_timeout, timeout worked well.
(Because stream_idle_timeout worked, I understand that EnvoyFilter is well applied to my app)

Why is request_timeout not working?
Anyone knows why?

Does this answer your question?


The issue with request_timeout not triggering in your Istio EnvoyFilter configuration could be due to a misunderstanding of how request_timeout works or an issue with the filter’s scope or configuration. request_timeout in Envoy is meant to set a timeout for the entire request duration, not just the connection establishment.


The request_timeout setting in Envoy’s HTTP Connection Manager configuration defines the amount of time that Envoy will wait for the entire HTTP request from the client to be received. This is not the same as a connection timeout or a timeout for a response from the upstream server. It’s specifically for the time taken to receive the full request from the client.

Detailed Answer

  1. Understanding request_timeout:

    • request_timeout is effective when the client is slow to send the complete request. If the client sends the entire request quickly but the server takes a long time to respond, request_timeout will not trigger.
  2. Configuration Scope:

    • Ensure that the EnvoyFilter is correctly scoped to the workloads where you expect the timeout to apply. If it’s configured at the gateway level, it won’t affect internal service-to-service calls.
  3. Testing Methodology:

    • To test request_timeout, simulate a slow client that takes longer than the specified timeout to send the entire request. This is different from a slow server response.
  4. Alternatives for Server Response Timeout:

    • If you want to set a timeout for the server’s response time, consider using a VirtualService with a timeout field, which sets a timeout for the time taken by the upstream server to respond.

Example for Server Response Timeout Using VirtualService

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
  name: my-virtual-service
    - my-service
    - route:
      - destination:
          host: my-service
      timeout: 5s

Suggested Next Steps

  1. Review Timeout Purpose: Confirm whether you need a timeout for the client’s request time or the server’s response time.
  2. Adjust Configuration: If necessary, modify your configuration to use a VirtualService for server response timeouts.
  3. Test with Appropriate Method: Ensure your testing method aligns with the type of timeout you’re configuring.


By understanding the specific use case of request_timeout and ensuring your configuration aligns with your timeout requirements, you can effectively manage request and response timeouts in Istio.