1979683 - cloudflare-quic.com - Firefox uses HTTP/2 instead of HTTP/3 on Cloudflare-hosted sites

Status: NEW

(Core :: Networking: HTTP, defect, P2)

Description

[Raul Bucata]

Environment:
Operating system: Mac OS X 10.15.7
Firefox version: Firefox 141.0

Steps to reproduce:

1. Navigate to: https://cloudflare-quic.com/
2. Observe the message displayed

Expected Behavior:
Firefox uses HTTP/3

Actual Behavior:
Firefox uses HTTP/2.

Notes:

• Reproduces regardless of the status of ETP
• Reproduces in firefox-nightly, and firefox-release
• Does not reproduce in chrome

Created from https://github.com/webcompat/web-bugs/issues/168913

Comment 1

[BugBot [:suhaib / :marco]]

The severity field is not set for this bug.
:denschub, could you have a look please?

For more information, please visit BugBot documentation.

Comment 2

[Sky Schubert [:skyschub]]

Per our definition, nothing is broken, so this is not a site report.

Comment 3

[Max Inden]

Raul since you wrote that you can reproduce, can you provide an HTTP log?

https://firefox-source-docs.mozilla.org/networking/http/logging.html

Also could you check whether you have IPv6 connectivity?

https://ipv6test.google.com/

Our current best guess:

• Firefox will attempt HTTP/3 QUIC via IPv6.
• IPv6 connectivity fails.
• Firefox falls back to both IPv4 and TCP.

The above would be fixed by Bug 1953459.

Comment 4

[Dennis Jackson]

I can reproduce.

Google reports:

You don’t have IPv6, but you shouldn’t have problems on websites that add IPv6 support.

https://test-ipv6.com/ reports:

No IPv6 address detected. You will not be able to reach IPv6-only sites.

Enabling a VPN with IPv6 support fixes the issue and shows https://cloudflare-quic.com/ loading over HTTP/3.

Comment 5

[Raul Bucata]

It works for Windows now, I have IPv6. Both Chrome and Firefox need a refresh to show that is loading over HTTP/3

Comment 7

[Velocifyer]

I can reproduce that I get HTTP2 on IPv4 only networks and HTTP3 on IPv6+IPv4 networks. Unfortunetly I currently don't have my own server with IPv6 to see if this is cloudflare only.

Comment 8

[Andrew Larsson]

Attachment: Firefox HTTP/3 IPv6 failure and IPv4 success - selected log excerpts

Comment 9

[Andrew Larsson]

(In reply to Max Inden from comment #3)

can you provide an HTTP log?

Firefox falls back to both IPv4 and TCP.

I have Firefox 158.0 logs and controlled comparisons that suggest HTTP/3 fallback to IPv4 from an unreachable IPv6 destination is failing. The user-visible effect is that Google Search requires a CAPTCHA in all new private windows; disabling IPv6 in Firefox eliminates that requirement.

Environment at capture time: Windows 10 Pro 22H2 (19045.7725), with no internet-usable IPv6 address or IPv6 default route. The Firefox log includes DNS-over-HTTPS requests to Cloudflare. Search URL: https://www.google.com/search?q=test

Controlled comparisons:

1. Firefox HARs showed Google's initial JavaScript check page returning HTTP/2 200, the subsequent search request redirecting to /sorry/index with HTTP/2 302, and the CAPTCHA page returning HTTP/2 429.

2. Ungoogled Chromium used HTTP/3 in a fresh Incognito session and did not require a CAPTCHA. With QUIC disabled, a fresh Incognito search used HTTP/2 and required a CAPTCHA. With QUIC restored, a fresh Incognito search did not require a CAPTCHA.

3. A fresh Firefox test profile was configured with:

   network.http.http3.alt-svc-mapping-for-testing = "www.google.com;h3=:443"
   network.http.http3.force-use-alt-svc-mapping-for-testing = true
   

   With network.dns.disableIPv6=false, even with these preferences configured, Google search requests still used HTTP/2 and required a CAPTCHA.

4. Keeping both http3 diagnostic preferences configured, setting network.dns.disableIPv6=true produced HTTP/3 over IPv4 and HTTP 200 for the initial check and subsequent search request; Google did not require a CAPTCHA.

5. After resetting both http3 diagnostic preferences to defaults but keeping network.dns.disableIPv6=true, Google did not require a CAPTCHA in new private windows.

Connection-log evidence:

• IPv6 HTTP/3 attempts to www.gstatic.com and fonts.gstatic.com fail with Windows error 1231 (network location cannot be reached).
• The connections close with NS_ERROR_NET_RESET (804b0014), log allowToRetryWithDifferentIPFamily=0, and exclude the affected hosts from HTTP/3.

The logs in attachment 9660861 [details] point to an HTTP/3 fallback problem when IPv6 is unavailable: IPv6 connection failures are followed by host exclusion without an alternate-address-family retry. Setting network.dns.disableIPv6=true eliminated the CAPTCHA requirement.

These observations appear consistent with the IPv6 failure and fallback behavior described in comment 3. Would these logs help confirm that diagnosis and validate the work tracked in bug 1953459?