Switching to http3 wrong redirect

[ahmedskh]

I am experiencing an issue where my site fails to load specifically when switching from HTTP/2 to HTTP/3. The initial request over HTTP2 works perfectly, but once the browser switches to HTTP3, Nginx returns a 301 redirect to a malformed URI: "https:///"
this only happens on main page only "adding any path works fine".

Access logs:

"GET / HTTP/3.0" 301 0 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/143.0.0.0 Safari/537.36"

adding fastcgi_param HTTP_HOST $host; works just fine, is this the correct way of fixing it as i have no prior knowledge on this.

[jeayalar]

Hey @ahmedskh,

adding fastcgi_param HTTP_HOST $host; works just fine, is this the correct way of fixing it as i have no prior knowledge on this.

Adding fastcgi_param HTTP_HOST $host; to the configuration overrides the HTTP_HOST header passed to your PHP application with $host, where $host is:

$host
in this order of precedence: host name from the request line, or host name from the “Host” request header field, or the server name matching a request

If overriding the header fixes the issue for you, then I have to imagine the 301 redirect is also coming from PHP itself, not Nginx.

Out of curiosity, are you hosting WordPress or some other PHP application?

[ahmedskh]

Hey @jeayalar , thanks for your respond. i host only wordpress through nginx using the same tutorial at https://spinupwp.com/hosting-wordpress-setup-secure-virtual-server/, i installed wordpress using wp-cli as instructed in the tutotial, redis for object caching and used the nginx config from this repo "single site without caching" and added wp rocket config from SatelliteWP/rocket-nginx repo didn't do any other custom config. even disabling wp rocket doesn't affect this behaviour so i don't think it originate from it.

[jeayalar]

Any chance you could share your nginx configuration? Feel free to replace your domain name with a placeholder, if you don't feel like sharing it.

[kdevnel]

Hi @jeayalar - I have the same issue so I thought I'd tag onto an existing issue rather than start a new one. Let me know if you'd prefer me to create a new one and reference this instead.

[23/Feb/2026:14:56:07 +0200] "GET / HTTP/3.0" 301 0 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/144.0.0.0 Safari/537.36"

I recommissioned my server in case I'd messed anything up but still the same issue. My configs are directly copied from the sample configs.

Here is the full config:

# Define path to cache and memory zone. The memory zone should be unique.
# keys_zone=redacted.site:100m creates the memory zone and sets the maximum size in MBs.
# inactive=60m will remove cached items that haven't been accessed for 60 minutes or more.
fastcgi_cache_path /sites/redacted.site/cache levels=1:2 keys_zone=redacted.site:100m inactive=60m;

server {
	# Ports to listen on
	listen 443 ssl;
	listen [::]:443 ssl;
	listen 443 quic;
	listen [::]:443 quic;
	http2 on;

	# Server name to listen for
	server_name redacted.site;

	# Path to document root
	root /sites/redacted.site/public;

	# Paths to certificate files.
	ssl_certificate /etc/letsencrypt/live/redacted.site/fullchain.pem;
	ssl_certificate_key /etc/letsencrypt/live/redacted.site/privkey.pem;
	#ssl_certificate /sites/fullchain.pem;
	#ssl_certificate_key /sites/privkey.pem;

	# File to be used as index
	index index.html index.php;

	# Overrides logs defined in nginx.conf, allows per site logs.
	access_log /sites/redacted.site/logs/access.log;
	error_log /sites/redacted.site/logs/error.log;

	# Default server block rules
	include global/server/defaults.conf;

	# Fastcgi cache rules
	include global/server/fastcgi-cache.conf;

	# SSL rules
	include global/server/ssl.conf;

	# Advertises support for HTTP/3
	add_header Alt-Svc 'h3=":443"; ma=86400' always;

	location / {
		try_files $uri $uri/ /index.php$is_args$args;
	}

	location ~ \.php$ {
		try_files $uri =404;
		include global/fastcgi-params.conf;

		# Use the php pool defined in the upstream variable.
		# See global/php-pool.conf for definition.
		fastcgi_pass   $upstream;

		# Skip cache based on rules in global/server/fastcgi-cache.conf.
		fastcgi_cache_bypass $skip_cache;
		fastcgi_no_cache $skip_cache;

		# Define memory zone for caching. Should match key_zone in fastcgi_cache_path above.
		fastcgi_cache redacted.site;

		# Define caching time.
		fastcgi_cache_valid 200 301 60m;
	}
}

# Redirect http to https
server {
	listen 80;
	listen [::]:80;
	server_name redacted.site www.redacted.site;

	return 301 https://redacted.site$request_uri;
}

# Redirect www to non-www
server {
	listen 443 ssl;
	listen [::]:443 ssl;
	listen 443 quic;
	listen [::]:443 quic;
	http2 on;

	server_name www.redacted.site;

	# Advertises support for HTTP/3
	add_header Alt-Svc 'h3=":443"; ma=86400';

	return 301 https://redacted.site$request_uri;
}

[kdevnel]

Could it be that for the www -> non-www redirect we should be providing SSL certificates since we're listening on those ports? Again, not sure this is the true cause since I'm a little uncertain how to troubleshoot this further.

# Redirect www to non-www
server {
	listen 443 ssl;
	listen [::]:443 ssl;
	listen 443 quic;
	listen [::]:443 quic;
	http2 on;

	server_name www.redacted.site;

+	# Paths to certificate files.
+	ssl_certificate /etc/letsencrypt/live/redacted.site/fullchain.pem;
+	ssl_certificate_key /etc/letsencrypt/live/redacted.site/privkey.pem;


	# Advertises support for HTTP/3
	add_header Alt-Svc 'h3=":443"; ma=86400';

	return 301 https://redacted.site$request_uri;
}

[kdevnel]

I ran a further test with curl -I --http3 https://redacted.site/ -v 2>&1 | head -50 and found that WordPress was definitely getting the request since the x-redirect-by: WordPress header was set.

A lot of digging and it seems that by adding fastcgi_param HTTP_HOST $host; to the /global/fastcgi-params.conf file seems to work. PR #40 opened

This post details why this is necessary: https://pieterbakker.com/nginx-http3-missing-http-host-php-fpm-fix/

[jeayalar]

@kdevnel First off, thank you so much for bringing up the SSL bit on the redirect, it was quite an oversight on my part. I have gone ahead and added your corrections to the repo now.

As for the redirect issue, I was testing your configuration yesterday and I couldn't replicate the reported behavior (as I previously tried with @ahmedskh), I was honestly scratching my head. The post you linked (thank you by the way), although it explains why this happens and offers a solution, it also explains why the issue didn't occur for me. As it turns out, this issue is a bug in Nginx's HTTP/3 implementation, which I suspect they fixed in version 1.28.1 (see: https://nginx.org/en/CHANGES-1.28). Which also turns out to be the version my server is currently running:

root@example:~# nginx -v
nginx version: nginx/1.28.1

As such, I'm somewhat hesitant to add fastcgi_param HTTP_HOST $host; to the param list, as we'd be fixing a bug which Nginx already fixed. I think we'd be more comfortable asking people to either update their Nginx version to 1.28.1, or manually adding that parameter to the list if they are unable to update Nginx.

[kdevnel]

First off, thank you so much for bringing up the SSL bit on the redirect, it was quite an oversight on my part. I have gone ahead and added your corrections to the repo now.

It's my pleasure! I wasn't too sure if there was some specific reason that would be needed but happy to help!

As such, I'm somewhat hesitant to add fastcgi_param HTTP_HOST $host; to the param list, as we'd be fixing a bug which Nginx already fixed. I think we'd be more comfortable asking people to either update their Nginx version to 1.28.1, or manually adding that parameter to the list if they are unable to update Nginx.

Yeah, that's fair enough! I'm not sure setting the header makes too much of a difference regardless of the version of nginx you're on, but I respect the choice not to add any debt to the setup.

Interesting note, I've just checked and my nginx version is also 1.28.1 (not surprising since I commissioned a new server last week just to test I hadn't broken something on my existing server! I still had the issue even so. Very strange.

Either way, I appreciate you taking the time to look into this with me!

[jeayalar]

Interesting note, I've just checked and my nginx version is also 1.28.1 (not surprising since I commissioned a new server last week just to test I hadn't broken something on my existing server! I still had the issue even so. Very strange.

Out of curiosity, have you cleared the page cache on the server? I'm still willing to test your configuration further if the issue persist for you, but I just want to double check the redirect is not being made by the page cache.

[kdevnel]

have you cleared the page cache on the server?

So I did some additional testing to confirm and this does still happen even with the page cache disabled/cleared. Important note - the primary domain on the server doesn't seem to exhibit this issue. Only additional sites on other domains - I'm not convinced I'm seeing a false-positive there though.

These are the testing steps I tried:

• Disabled the parameter in global/fastcgi-params.conf
• Reload Nginx
• Flush the Nginx cache (also tested with the Nginx cache plugin disabled)
• Run curl -I --http3 https://redacted.domain/ - Note: I had to update my curl on MacOS to one that supported HTTP/3
• See the following:

• Enable the parameter
• Reload Nginx
• See the result:

[kdevnel]

One other note I have - I also was having a separate cache conflict with Redis due to not realising that with the Redis Object Cache plugin, you need to set some parameters in wp-config.php for each site so they use a separate Redis database and avoid cache conflicts. That's also resolved, but the same testing steps still show the homepage location breaking.

[jeayalar]

@kdevnel Thanks for sharing the headers, you had already mentioned it, but seeing the x-redirect-by: WordPress on your headers already tells us the problem isn't coming from Nginx. So I'm reluctant to add fastcgi_param HTTP_HOST $host; to the configuration.

Could you run the following query on your server? I'd be curious to see what the result is:

SELECT option_name, option_value 
FROM wp_options 
WHERE option_name IN ('siteurl','home');

The above assumes you're using the default table prefix of wp_.

Additionally, do you have any of the following constants setup in your wp-config.php?

define('WP_HOME', 'https://redacted.domain');
define('WP_SITEURL', 'https://redacted.domain');

Lastly, I don't think this is the case, but it doesn't hurt to ask. Is your server behind any other reverse proxy or is your server currently publicly accessible through the Internet as is?

[PDowney]

I wanted to jump in here and point at that adding $host to the config could cause unforeseen issues as a result, such as how it could strip port numbers and force lowercasing. Edge cases for sure.

However, one issue that sounds somewhat like the behavior described in the discussion:

Fallback to server_name
If a request is sent without any Host header (or a malformed one), $host falls back to the primary name defined in your server_name directive.

In a multi-site or shared environment, if a bot or malicious actor sends a headerless request, $host will provide the first domain in your config. $http_host would simply be empty. Depending on your security logic, you might prefer the application to fail or error out rather than defaulting to the primary domain.

[kdevnel]

So I'm reluctant to add fastcgi_param HTTP_HOST $host; to the configuration.

Agreed on this point. Hopefully I can at least figure out my edge-case and deal with it.

Could you run the following query on your server? I'd be curious to see what the result is:

SELECT option_name, option_value 
FROM wp_options 
WHERE option_name IN ('siteurl','home');

In most cases it just returns https://redacted.domain for both. One of the sites returned https://redacted.domain/ (note the leading slash) for siteurl only. I updated that value so it's without trailing slash in all cases. That said, the issue happened on a site where this was, and another where this wasn't the case so not sure that's actually the issue. Maybe it is though, I'll do some more testing.

Additionally, do you have any of the following constants setup in your wp-config.php?

define('WP_HOME', 'https://redacted.domain');
define('WP_SITEURL', 'https://redacted.domain');

No, I don't set this in any of the config files.

Lastly, I don't think this is the case, but it doesn't hurt to ask. Is your server behind any other reverse proxy or is your server currently publicly accessible through the Internet as is?

Good thought. This server is provisioned exactly according to your blog instructions so no additional reverse proxy.

@PDowney Thanks for that additional info! That makes a lot of sense and appreciate you weighing in with your insight and expertise. That's an interesting concern and I suspect, proper erroring out is a better situation. I guess finding the real root cause of this is probably worth resolving.

I'm just at a loss as to how to work out if this is my applications and some weird issue there, the server, or a combination of the two.

Next time, I should probably also do a proper plugin/theme troubleshooting step in case something in my WordPress applications is the culprit.