Dynamic forward proxy cluster configuration (proto)


[extensions.clusters.dynamic_forward_proxy.v3.ClusterConfig proto]

Configuration for the dynamic forward proxy cluster. See the architecture overview for more information.

This extension has the qualified name envoy.clusters.dynamic_forward_proxy


This extension is intended to be robust against untrusted downstream traffic. It assumes that the upstream is trusted.


This extension extends and can be used with the following extension category:

  "dns_cache_config": {...},
  "sub_clusters_config": {...},
  "allow_insecure_cluster_options": ...,
  "allow_coalesced_connections": ...

(extensions.common.dynamic_forward_proxy.v3.DnsCacheConfig) The DNS cache configuration that the cluster will attach to. Note this configuration must match that of associated dynamic forward proxy HTTP filter configuration.

Only one of dns_cache_config, sub_clusters_config may be set.


(extensions.clusters.dynamic_forward_proxy.v3.SubClustersConfig) Configuration for sub clusters, when this configuration is enabled, Envoy will create an independent sub cluster dynamically for each host:port. Most of the configuration of a sub cluster is inherited from the current cluster, i.e. health_checks, dns_resolvers and etc. And the load_assignment will be set to the only one endpoint, host:port.

Compared to the dns_cache_config, it has the following advantages:

  1. sub clusters will be created with the STRICT_DNS DiscoveryType, so that Envoy will use all of the IPs resolved from the host.

  2. each sub cluster is full featured cluster, with lb_policy and health check and etc enabled.

Only one of dns_cache_config, sub_clusters_config may be set.


(bool) If true allow the cluster configuration to disable the auto_sni and auto_san_validation options in the cluster’s upstream_http_protocol_options


(bool) If true allow HTTP/2 and HTTP/3 connections to be reused for requests to different origins than the connection was initially created for. This will only happen when the resolved address for the new connection matches the peer address of the connection and the TLS certificate is also valid for the new hostname. For example, if a connection has previously been established to foo.example.com at IP with a certificate that is valid for *.example.com, then this connection could be used for requests to bar.example.com if that also resolved to


By design, this feature will maximize reuse of connections. This means that instead opening a new connection when an existing connection reaches the maximum number of concurrent streams, requests will instead be sent to the existing connection.


The coalesced connections might be to upstreams that would not be otherwise selected by Envoy. See the section Connection Reuse in RFC 7540


[extensions.clusters.dynamic_forward_proxy.v3.SubClustersConfig proto]

Configuration for sub clusters. Hard code STRICT_DNS cluster type now.

  "lb_policy": ...,
  "max_sub_clusters": {...},
  "sub_cluster_ttl": {...},
  "preresolve_clusters": []

(config.cluster.v3.Cluster.LbPolicy) The load balancer type to use when picking a host in a sub cluster. Note that CLUSTER_PROVIDED is not allowed here.


(UInt32Value) The maximum number of sub clusters that the DFP cluster will hold. If not specified defaults to 1024.


(Duration) The TTL for sub clusters that are unused. Sub clusters that have not been used in the configured time interval will be purged. If not specified defaults to 5m.


(repeated config.core.v3.SocketAddress) Sub clusters that should be created & warmed upon creation. This might provide a performance improvement, in the form of cache hits, for sub clusters that are going to be warmed during steady state and are known at config load time.