DPTCloud
Back to articles
Technology Insight

Configuring Envoy Proxy as an API Gateway for gRPC and HTTP/3 Traffic Routing in Microservices Architecture

June 1, 2026

Introduction to Modern Traffic Management

In the era of distributed systems, managing internal and external communication efficiently is paramount. As microservices scale, the architectural demands on the edge proxy become increasingly complex. Modern cloud-native applications no longer rely solely on traditional HTTP/1.1 REST APIs. Instead, they require a hybrid approach combining the low latency of gRPC for internal service-to-service communication and the speed of HTTP/3 (QUIC) for optimal client-to-edge connectivity.

Choosing the right tool to act as the unified entry point for these diverse protocols determines the resilience, performance, and scalability of your entire backend system. This is where Envoy Proxy shines. Originally developed by Lyft, Envoy is a high-performance, open-source L7 proxy designed specifically for cloud-native applications. This technical guide explores how to configure Envoy Proxy as an enterprise-grade API Gateway capable of intelligent traffic routing for both gRPC and HTTP/3 traffic streams.

The Evolution of the API Gateway: Why Envoy Proxy?

Traditional API Gateways often struggle under the weight of multiplexed connections, dynamic service discovery, and advanced protocol translation. Envoy Proxy addresses these limitations fundamentally through its extensible, non-blocking asynchronous architecture. When positioned at the edge of your microservices network, Envoy serves multiple critical functions:

  • Protocol Agnosticism: Envoy natively understands and optimizes HTTP/1.1, HTTP/2, HTTP/3, and gRPC traffic.
  • Advanced Load Balancing: It supports sophisticated algorithms including zone-aware routing, least request, and random load balancing with panic thresholds.
  • Dynamic Configuration: Through its xDS APIs, Envoy can update its routing tables, clusters, and TLS certificates on the fly without restarts or dropping active connections.
  • Observability: Out-of-the-box generation of comprehensive metrics, distributed tracing integration, and access logging.
Choosing an edge architecture that integrates HTTP/3 and gRPC ensures your infrastructure remains future-proof, reducing latency overhead to the absolute theoretical minimum.

Deconstructing the Protocols: gRPC and HTTP/3

Before diving into the configuration mechanics, it is essential to understand why routing both gRPC and HTTP/3 through a single gateway is so powerful.

gRPC in Microservices

gRPC utilizes Protocol Buffers (Protobuf) as its Interface Definition Language (IDL) and runs exclusively over HTTP/2. By leveraging HTTP/2 features like bidirectional streaming and binary framing, gRPC drastically reduces payload size and CPU utilization compared to JSON over HTTP/1.1. However, because gRPC relies on long-lived HTTP/2 TCP connections, traditional L4 load balancers fail; they cannot distribute requests evenly because they balance connections, not individual requests. Envoy operates at L7, allowing it to parse gRPC headers and load-balance requests perfectly across downstream microservices.

HTTP/3 and the QUIC Protocol

While gRPC optimizes internal communication, HTTP/3 revolutionizes client-to-gateway communication over the internet. Built on top of the UDP-based QUIC protocol, HTTP/3 eliminates the head-of-line blocking problem inherent in TCP. If a packet is lost in an HTTP/3 stream, only that specific stream is paused while others continue uninterrupted. Additionally, QUIC features connection migration, meaning a mobile client shifting from Wi-Fi to a cellular network experiences zero connection drops. Envoy acts as the critical bridge, terminating incoming HTTP/3 connections from external clients and translating them to HTTP/2 or gRPC for internal microservices.

Architectural Overview: The Envoy Edge Layer

In our implementation blueprint, Envoy Proxy sits at the perimeter of the cloud infrastructure. It exposes two primary listeners: one for UDP (handling HTTP/3 traffic) and one for TCP (acting as a fallback for HTTP/2 and HTTP/1.1 traffic, as well as handling direct external gRPC requests). Behind Envoy sit two distinct microservice clusters:

  1. Order Service: A collection of high-performance internal microservices communicating via gRPC.
  2. Catalog Service: A client-facing RESTful API cluster optimized for HTTP/3 web asset delivery and data fetching.

Step-by-Step Envoy Configuration

Let us look at a robust, production-ready envoy.yaml configuration file designed to handle this exact dual-protocol routing scenario. Pay close attention to how listeners and clusters are defined.

1. Core Configuration Boilerplate and Static Resources

We begin by defining the static resources for Envoy, starting with the administrative interface and the listeners block.

admin:
  address:
    socket_address: { address: 0.0.0.0, port_value: 9901 }

static_resources:
  listeners:

2. Configuring the HTTP/3 (UDP) and HTTP/2 (TCP) Dual Listeners

To support HTTP/3, Envoy requires both a UDP listener to handle QUIC and a matching TCP listener. This ensures that clients lacking UDP or HTTP/3 support can cleanly fall back to standard TLS connections.

  - name: http3_udp_listener
    address:
      socket_address: { address: 0.0.0.0, port_value: 443 }
    udp_listener_config:
      quic_options: {}
    filter_chains:
    - filters:
      - name: envoy.filters.network.http_connection_manager
        typed_config:
          "@type": [type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager](https://type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager)
          stat_prefix: ingress_http3
          codec_type: HTTP3
          route_config:
            name: local_route
            virtual_hosts:
            - name: api_gateway
              domains: ["*"]
              routes:
              - match: { prefix: "/orders." }
                route: { cluster: grpc_order_service }
              - match: { prefix: "/catalog" }
                route: { cluster: http3_catalog_service }
          http_filters:
          - name: envoy.filters.http.router
            typed_config:
              "@type": [type.googleapis.com/envoy.extensions.filters.http.router.v3.Router](https://type.googleapis.com/envoy.extensions.filters.http.router.v3.Router)
      transport_socket:
        name: envoy.transport_sockets.quic
        typed_config:
          "@type": [type.googleapis.com/envoy.extensions.transport_sockets.quic.v3.QuicDownstreamTransport](https://type.googleapis.com/envoy.extensions.transport_sockets.quic.v3.QuicDownstreamTransport)
          downstream_tls_context:
            common_tls_context:
              tls_certificates:
              - certificate_chain: { filename: "/etc/envoy/certs/cert.pem" }
                private_key: { filename: "/etc/envoy/certs/key.pem" }
              alpn_protocols: ["h3"]

Next, we construct the TCP listener. Crucially, we append the alt-svc header to responses sent via TCP. This informs the client's browser that an HTTP/3 endpoint is available on port 443 over UDP, prompting subsequent requests to upgrade automatically.

  - name: http2_tcp_listener
    address:
      socket_address: { address: 0.0.0.0, port_value: 443 }
    filter_chains:
    - filters:
      - name: envoy.filters.network.http_connection_manager
        typed_config:
          "@type": [type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager](https://type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager)
          stat_prefix: ingress_tcp
          codec_type: AUTO
          route_config:
            name: local_route
            virtual_hosts:
            - name: api_gateway
              domains: ["*"]
              routes:
              - match: { prefix: "/orders." }
                route: { cluster: grpc_order_service }
              - match: { prefix: "/catalog" }
                route: { cluster: http3_catalog_service }
          response_headers_to_add:
          - header: { key: "alt-svc", value: 'h3=":443"; ma=86400' }
          http_filters:
          - name: envoy.filters.http.router
            typed_config:
              "@type": [type.googleapis.com/envoy.extensions.filters.http.router.v3.Router](https://type.googleapis.com/envoy.extensions.filters.http.router.v3.Router)
      transport_socket:
        name: envoy.transport_sockets.tls
        typed_config:
          "@type": [type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.DownstreamTlsContext](https://type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.DownstreamTlsContext)
          common_tls_context:
            tls_certificates:
            - certificate_chain: { filename: "/etc/envoy/certs/cert.pem" }
              private_key: { filename: "/etc/envoy/certs/key.pem" }
            alpn_protocols: ["h2", "http/1.1"]

3. Upstream Cluster Definitions

With listeners capturing traffic, we define our backend target groups. The grpc_order_service requires explicit enforcement of HTTP/2 protocol options to maintain persistent, multiplexed streams to our internal gRPC instances.

  clusters:
  - name: grpc_order_service
    connect_timeout: 0.50s
    type: STRICT_DNS
    lb_policy: LEAST_REQUEST
    typed_extension_protocol_options:
      envoy.extensions.upstreams.http.v3.HttpProtocolOptions:
        "@type": [type.googleapis.com/envoy.extensions.upstreams.http.v3.HttpProtocolOptions](https://type.googleapis.com/envoy.extensions.upstreams.http.v3.HttpProtocolOptions)
        explicit_http_config:
          http2_protocol_options: {}
    load_assignment:
      cluster_name: grpc_order_service
      endpoints:
      - lb_endpoints:
        - endpoint:
            address:
              socket_address: { address: order-service.internal, port_value: 50051 }

  - name: http3_catalog_service
    connect_timeout: 0.25s
    type: STRICT_DNS
    lb_policy: ROUND_ROBIN
    load_assignment:
      cluster_name: http3_catalog_service
      endpoints:
      - lb_endpoints:
        - endpoint:
            address:
              socket_address: { address: catalog-service.internal, port_value: 8080 }

Crucial Production Optimization Tuning

Running Envoy with high-performance protocols like gRPC and HTTP/3 requires tuning settings beyond the defaults to handle massive concurrent traffic spikes effectively.

Handling gRPC Keepalives

Because gRPC routes requests over static TCP connections, network firewalls or load balancers might silently drop idle TCP sockets. Implement aggressive HTTP/2 keepalive settings inside Envoy's upstream protocol options to detect and heal dead connections early:

  • max_connection_duration: Safely cycle older connections without disrupting downstream flows.
  • keepalive: Keep connections hot by validating payload transport integrity at fixed intervals (e.g., every 30 seconds).

UDP Buffer Optimization for HTTP/3

Unlike TCP, which is highly optimized directly within the Linux kernel network stack, UDP processing requires intensive context switching at scale. To mitigate dropped packets under high load, increase your system's socket read and write buffer sizes via sysctl, and ensure Envoy's listener explicitly leverages SO_REUSEPORT to bind multiple worker threads evenly across the incoming UDP port.

Validation and Testing

Once your configuration files are deployed, verifying correct protocol negotiation ensures your setup is working as intended.

Testing gRPC Routing

Use a command-line tool like grpcurl to ensure Envoy balances L7 streams correctly:

grpcurl -insecure -authority order-service.domain.com gateway.internal:443 orders.OrderService/GetOrderDetails

Testing HTTP/3 with cURL

Modern versions of curl compiled with HTTP/3 support can verify your UDP route execution paths directly:

curl --http3 -v [https://gateway.internal/catalog/products](https://gateway.internal/catalog/products)

Confirm the response headers include the verified HTTP/3 execution identifier and match your defined alt-svc rules.

Conclusion

Configuring Envoy Proxy as your API Gateway unifies fragmented, multi-protocol communication networks into a structured, highly performant architecture. By deploying dynamic dual-listeners, you satisfy the need for low-latency internal gRPC streaming while offering cutting-edge, resilient HTTP/3 access paths directly to external users. Incorporating Envoy into your microservices architecture establishes a flexible, secure foundation prepared to tackle high-throughput data demands elegantly.

Configuring Envoy Proxy as an API Gateway for gRPC and HTTP/3 Traffic Routing in Microservices Architecture | DPTCloud