HTTP/3 listener downgrade behavior when upstream lacks HTTP/3 support

Short answer

Envoy does not "downgrade" in the sense of negotiating with the upstream over QUIC and falling back. It terminates HTTP/3 at the listener and opens a separate connection to the upstream whose protocol is decided entirely by the cluster configuration — not by anything the downstream client sent. If the cluster has http2_protocol_options (or an explicit HTTP/2 upstream protocol config), the upstream leg is HTTP/2; otherwise it is HTTP/1.1. There is no dedicated downgrade warning because, from Envoy's perspective, this is normal protocol translation, not an error condition.

What's confirmed vs. inferred

Confirmed behavior (well-established):

• The downstream connection and upstream connection are independent. A client speaking HTTP/3 over QUIC talks only to Envoy; Envoy then originates a new TCP connection to the cluster.
• Upstream protocol selection is driven by the cluster's protocol options. Without HTTP/2 configured on the cluster, the upstream leg is HTTP/1.1.
• The downstream client never learns which protocol was used upstream.

Likely explanation (not documented, treat as inference): the question's premise that Envoy inspects an upstream's "advertised protocol list" and picks accordingly is probably a misreading. For cleartext HTTP/1.1 vs HTTP/2 there is no advertisement step — Envoy simply speaks what the cluster is configured to speak. Over TLS, ALPN can negotiate HTTP/2, but only if the cluster is configured to offer it. So there is no runtime decision logic to expose; the "decision" was made in your bootstrap config. If your deployment shows inconsistent handshakes or drops, the more likely causes are QUIC/TLS listener misconfiguration or upstream connection pool exhaustion, not a silent downgrade path.

How to verify a downgrade actually happened

Don't rely on log messages. Use two independent signals:

1. Access logs. Add the upstream protocol to your access log format, e.g. %UPSTREAM_TRANSPORT_FAILURE_REASON% for failures and, more directly, log the negotiated protocol. A practical check is to include response flags and compare against a request you know was HTTP/3 downstream (look for HTTP3 in %PROTOCOL%) while confirming the upstream leg separately.
2. Packet capture on the upstream interface. This is unambiguous: QUIC is UDP, HTTP/1.1 and HTTP/2 are TCP.

# On the Envoy host, watch traffic toward the upstream
sudo tcpdump -i eth0 'host 10.0.0.25 and (udp port 443 or tcp port 80)' -nn

If you see TCP SYNs to the upstream while clients connect over QUIC, translation is happening as designed.

Controlling which protocol you downgrade to

If you want HTTP/3 downstream to map to HTTP/2 upstream rather than HTTP/1.1, configure it explicitly on the cluster:

clusters:
- name: backend
  typed_extension_protocol_options:
    envoy.extensions.upstreams.http.v3.HttpProtocolOptions:
      "@type": type.googleapis.com/envoy.extensions.upstreams.http.v3.HttpProtocolOptions
      explicit_http_config:
        http2_protocol_options: {}
      upstream_http_protocol_options:
        auto_sni: true

Be aware of what translation costs you: QPACK header compression and QUIC's stream multiplexing over UDP are replaced by TCP semantics at the proxy boundary, and HTTP/1.1 upstreams lose multiplexing entirely (one in-flight request per connection, so watch connection pool sizing).

One caveat

Exact access-log format specifiers and the stability of the HTTP/3 listener have shifted between Envoy releases; the above assumes the 1.26+ era where HTTP/3 is still marked experimental. Verify the log format strings against your deployed version's docs before scripting around them. If you can share whether your upstream leg is TLS or cleartext, that determines whether ALPN plays any role at all — but in neither case is there a hidden downgrade log to enable.