Troubleshooting HTTP/3 in http.sys

HTTP/3 is a major change to HTTP. It switches away from using TCP as a transport and separately to using QUIC as a transport which has 1.3 or higher built in. These changes mean that migrating from HTTP/2 to HTTP/3 can uncover unexpected issues due to previously non-problematic configurations. Here are some configurations to check if HTTP/3 is not working on Windows and above.

Checking the basics

First things first: is HTTP/3 properly enabled? This blog post walks through the process of enabling HTTP/3 for http.sys on Windows . Earlier versions of Windows Server do not support HTTP/3 in http.sys.

HTTP/3 requires QUIC and by extension 1.3. Check the IIS configuration for the site binding and ensure TLS 1.3 and QUIC are not disabled. Here is an example of an HTTP/3 friendly site binding:


The above steps will turn on HTTP/3 advertising over HTTP/3 ALTSVC frames. If the HTTP/3 clients also expect an alt-svc header to advertise support, check that the service is providing one. Here is an example of the most basic alt-svc header that advertises HTTP/3 support in the IIS “HTTP Response Header” UI:


Narrowing down the issue

If HTTP/3, its dependencies, and its advertisements are properly enabled and it is still not working, try comparing a fresh Windows Server installation against the server under investigation. Be sure to not apply any custom configuration such as GPOs or initialization for this comparison. The intention is to compare the existing server with out-of-the-box Windows Server.

If the fresh install of Windows Server can use HTTP/3 as expected, it is likely that the issue is being caused by non-default Windows TLS configuration. Proceed to the “TLS 1.3 Configuration” section to learn more.

If the fresh installation of Windows Server also cannot use HTTP/3, check the networking environment. HTTP/3 uses QUIC, which requires port 443 UDP to be open on the host and firewalls. Proxies that perform TLS interception (also known as SSL termination) may also be causing issues.

TLS 1.3 Configuration

TLS 1.3 is supported and enabled by default on Windows 11 and Windows and later operating systems. Check whether TLS 1.3 has been disabled on a supported machine using Transport Layer Security (TLS) registry settings | Microsoft Docs.

HTTP/3 may not be working because the server was previously configured to disable cipher suites that TLS 1.3 requires. Schannel supports only three cipher suites for TLS 1.3:

TLS_AES_256_GCM_SHA384 Enabled by default
TLS_AES_128_GCM_SHA256 Enabled by default
TLS_CHACHA20_POLY1305_SHA256 Disabled by default

TLS 1.3 Cipher Suite Configuration:

  1. To see what TLS cipher suites are currently enabled on a machine, use the PowerShell cmdlet Get-TlsCipherSuites.
  2. Check that the enabled list output contains at least one supported TLS 1.3 cipher suite listed above.
  3. Ensure TLS 1.3 cipher suites have not been disabled by Group Policy  by checking the following registry key value: “HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftCryptographyConfigurationSSL”
  4. If no TLS 1.3 supporting cipher suites are enabled, manually enable one or more by using the PowerShell cmdlet Enable-TlsCipherSuite. They should be added to the top of the priority list using the Position flag, where the highest priority value is 0.

Additional troubleshooting resources

The msquic GitHub repo has several useful documents with additional context specific to QUIC:


This article was originally published by Microsoft's PowerShell Community. You can find the original article here.