DPTCloud
Back to articles
Technology Insight

Optimizing Microservices: Configuring Envoy Proxy as an API Gateway for gRPC and HTTP/3 Traffic on Cloud VPS

June 2, 2026

Introduction: The Evolution of Edge Routing in Microservices

In modern distributed architectures, the efficiency of the API Gateway dictates the overall performance, scalability, and reliability of the entire system. As organizations migrate from monolithic frameworks to cloud-native microservices, traditional reverse proxies often struggle under the demands of mixed-protocol traffic, real-time streaming, and dynamic service discovery. This is where Envoy Proxy excels.

Originally developed by Lyft, Envoy is an open-service edge and service proxy designed for large-scale microservice architectures. Operating as an L7 proxy and communication bus, Envoy provides advanced traffic management features with unparalleled performance. This technical guide explores how to configure Envoy Proxy as a centralized API Gateway deployed on an affordable yet high-performing Cloud VPS, specifically optimized to handle both high-speed inter-service gRPC communication and modern, low-latency HTTP/3 (QUIC) client connections.

---

Why Envoy Proxy for Cloud VPS Deployments?

When hosting microservices on a Cloud VPS environment, resource efficiency and raw throughput are critical. Unlike heavy enterprise API gateways that consume substantial CPU and memory, Envoy is written in C++ and optimized for minimal resource overhead. Implementing Envoy as your edge proxy yields several structural advantages:

  • Protocol Agility: Seamlessly bridges client-side HTTP/3 traffic with back-end HTTP/1.1, HTTP/2, and gRPC services.
  • Advanced Load Balancing: Supports sophisticated routing mechanisms including zone-aware routing, retries, circuit breaking, and rate limiting.
  • Dynamic Configuration: Utilizes a set of layered discovery services (xDS APIs) allowing you to update routing rules, upstream clusters, and TLS certificates without restarting the proxy.
  • Deep Observability: Emits comprehensive stats, logs, and distributed tracing metadata compatible with Prometheus, Grafana, and Jaeger.
---

Architectural Overview: gRPC and HTTP/3 Coexistence

Before diving into configuration syntax, it is vital to understand the structural flow of traffic through our Cloud VPS gateway. Our architecture utilizes a dual-protocol edge interface:

The ingress edge terminates user connections over HTTP/3 via UDP port 443, while simultaneously accepting legacy HTTP/2 or HTTP/1.1 connections over TCP port 443. Once traffic enters the Envoy pipeline, routing rules evaluate the headers and path to forward the request to the appropriate microservice cluster via high-efficiency gRPC or standard HTTP.

Because HTTP/3 operates over the QUIC transport protocol (which uses UDP), configuring your Cloud VPS firewall to allow both TCP and UDP traffic on port 443 is a prerequisite for this setup.

---

Step-by-Step Envoy Configuration

Below is a production-ready, structured representation of an envoy.yaml configuration file. This file specifies the listeners for HTTP/3 and TCP, along with the routing definitions for gRPC internal services and general web workloads.

1. Static Resources and Listener Setup

First, we define the static_resources block containing our network listeners. To support HTTP/3, Envoy requires both a traditional TCP listener (for fallback) and a UDP listener configured with the QUIC transport socket.

static_resources:
  listeners:
  # TCP Listener for HTTP/1.1, HTTP/2, and TLS downstream connections
  - name: ingress_tcp
    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_http
          codec_type: AUTO
          route_config: &shared_route_config
            name: local_route
            virtual_hosts:
            - name: api_vhost
              domains: ["api.yourdomain.com"]
              routes:
              # Routing gRPC Traffic
              - match:
                  prefix: "/com.enterprise.internal."
                route:
                  cluster: grpc_backend_cluster
                  timeout: 0s
                  max_stream_duration:
                    grpc_timeout_header_max: 0s
              # Routing Standard HTTP Traffic
              - match:
                  prefix: "/api/v1/"
                route:
                  cluster: http_backend_cluster
          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)
          # Adding Alt-Svc header to advertise HTTP/3 availability
          response_headers_to_add:
          - header:
              key: "alt-svc"
              value: 'h3=":443"; ma=86400'
      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/fullchain.pem" }
              private_key: { filename: "/etc/envoy/certs/privkey.pem" }

  # UDP Listener for HTTP/3 (QUIC)
  - name: ingress_udp
    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: *shared_route_config
          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.DownstreamQuicContext](https://type.googleapis.com/envoy.extensions.transport_sockets.quic.v3.DownstreamQuicContext)
          common_tls_context:
            tls_certificates:
            - certificate_chain: { filename: "/etc/envoy/certs/fullchain.pem" }
              private_key: { filename: "/etc/envoy/certs/privkey.pem" }

2. Backend Clusters and Protocol Switching

Next, we declare our upstream clusters within the same static_resources block. The key configuration element here is enforcing HTTP/2 explicitly for our internal backend microservices to natively route high-speed gRPC requests.

  clusters:
  # gRPC Microservices Cluster
  - name: grpc_backend_cluster
    connect_timeout: 0.50s
    type: STRICT_DNS
    lb_policy: ROUND_ROBIN
    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_backend_cluster
      endpoints:
      - lb_endpoints:
        - endpoint:
            address:
              socket_address:
                address: 127.0.0.1
                port_value: 50051

  # Standard HTTP/REST Microservices Cluster
  - name: http_backend_cluster
    connect_timeout: 0.50s
    type: STRICT_DNS
    lb_policy: ROUND_ROBIN
    load_assignment:
      cluster_name: http_backend_cluster
      endpoints:
      - lb_endpoints:
        - endpoint:
            address:
              socket_address:
                address: 127.0.0.1
                port_value: 8080
---

Optimizing Envoy on Cloud VPS for Production

Running Envoy efficiently on a standalone Cloud VPS instance requires tuning the host operating system and Envoy configurations for high concurrency. Implement the following optimizations for maximum throughput:

  1. Kernel UDP Buffer Sizes: HTTP/3 processes significantly more UDP packets than typical workloads. Increase Linux kernel UDP receive/send buffers by editing /etc/sysctl.conf:
    net.core.rmem_max = 16777216
    net.core.wmem_max = 16777216
  2. Concurrency Tuning: Match Envoy's worker thread count to the dedicated CPU core allocation of your Cloud VPS using the --concurrency command-line flag during execution.
  3. Circuit Breaking: Define circuit_breakers policies in your upstream configurations to prevent cascading microservice failures during high traffic surges.
---

Conclusion

By deploying Envoy Proxy as an API Gateway on your Cloud VPS, you unlock modern architecture patterns without relying on expensive infrastructure overhead. Through unified routing of low-latency gRPC internally and cutting-edge HTTP/3 (QUIC) externally, your application achieves faster data delivery, robust resilience, and an optimized footprint ready for seamless scaling.

Optimizing Microservices: Configuring Envoy Proxy as an API Gateway for gRPC and HTTP/3 Traffic on Cloud VPS | DPTCloud