I manage a bunch of domains and this one is giving me issues.
As soon as I add the following HTTPS records on Route53, the domain no longer redirects from mypogobadges.com -> www.mypogobadges.com
1 mypogobadges.com alpn=“h2,h3” ipv4hint=72.9.154.32
1 www.mypogobadges.com alpn=“h2,h3” ipv4hint=72.9.154.32
Once I remove them, the 301 redirect works perfectly. I’m using FreeBSD 14.2 and Nginx 1.28
It seems like cURL is unaffected and the redirect works there regardless, but it will not 301 redirect in any web browser.
Any ideas what is going on?
Here is the conf file:
server {
listen 72.9.154.32:80;
server_name mypogobadges.com;
return 301 https://mypogobadges.com$request_uri;
}
server {
listen 72.9.154.32:443 ssl accept_filter=dataready reuseport;
server_name mypogobadges.com;
ssl_certificate /cert/mypogobadges.com/mypogobadges.crt;
ssl_certificate_key /cert/mypogobadges.com/mypogobadges.key;
return 301 https://www.mypogobadges.com$request_uri;
}
server {
listen 72.9.154.32:443 quic reuseport;
listen 72.9.154.32:443 ssl;
server_name www.mypogobadges.com;
ssl_certificate /cert/mypogobadges.com/mypogobadges.crt;
ssl_certificate_key /cert/mypogobadges.com/mypogobadges.key;
...
...
}
Hey @Mayhem30! I’ve got good news for you – the site seems to be working as intended (for the most part)! I’ve gone ahead and tested it through:
- Chrome and Edge → The redirect happens as expected
- Firefox → The redirect happens if I clear my cache and force a refresh
- Safari → This is the one where I can’t get the redirect to happen no matter if I clear my cache or not. I’ll look a bit more into it, but this could be Safari being Safari.
- curl → Like you mentioned, everything works as expected here.
In so far as potential suggestions for the code you shared, you can probably combine your first two server blocks since they both ultimately redirect to the same endpoint and you should be able to combine your two listen directives in the third server block 
Thank you, I think I finally figured it out.
To start with, I was not able to combine the 2 listen directive in the last block.
nginx: [emerg] "listen" directive "ssl" parameter is incompatible with "quic"
As for the fix, I had to remove h3 from alpn in the first HTTPS DNS entry. That second server block (mypogobadges.com) never supported H3, and was only there for 301 redirects.
So far that appears to have solved everything. If you could confirm that, that would great.
Also, my updated conf file looks like this:
listen 72.9.154.32:80;
listen 72.9.154.32:443 ssl accept_filter=dataready reuseport;
server_name mypogobadges.com;
ssl_certificate /cert/mypogobadges.com/mypogobadges_ecc.crt;
ssl_certificate_key /cert/mypogobadges.com/mypogobadges_ecc.key;
ssl_certificate /cert/mypogobadges.com/mypogobadges.crt;
ssl_certificate_key /cert/mypogobadges.com/mypogobadges.key;
return 301 https://www.mypogobadges.com$request_uri;
}
server {
listen 72.9.154.32:443 ssl;
listen 72.9.154.32:443 quic reuseport;
server_name www.mypogobadges.com;
ssl_certificate /cert/mypogobadges.com/mypogobadges_ecc.crt;
ssl_certificate_key /cert/mypogobadges.com/mypogobadges_ecc.key;
ssl_certificate /cert/mypogobadges.com/mypogobadges.crt;
ssl_certificate_key /cert/mypogobadges.com/mypogobadges.key;
...
...
}
I totally missed that H2 and H3 in this context meant HTTP2 and HTTP3! And sorry for the errored out suggestion, I double checked and indeed it requires two different directives since its using different methods of communication behind the scenes.
In so far as changes in practice – I cannot see any real changes in functionality on my end. Chrome/Edge/curl still work as expected. Firefox does if you clear the cache. Safari does not redirect no matter what. The config looks good and the fact that curl works as intended makes this seem like a Safari issue first and foremost.
That being said, I am surprised that you are seeing any changes when nothing seems to have changed on my end. Outside of curl, what browser where you using?
I’m using the latest versions of Edge, Chrome and Firefox. Before the changes, it wasn’t working for me in those browsers, but now it is.
The redirect is also working for me in Safari on the iPhone.
If you drill or dig HTTPS on mypogobadges.com, does it show this for you?
mypogobadges.com. 300 IN HTTPS 1 mypogobadges.com. alpn=h2 ipv4hint=72.9.154.32
The alpn should only show h2.
Yup, I am seeing the same thing! I am somewhat puzzled as to how things where working fine on my end before you made any changes, but then again web browsers are not famous for being very consistent in behaviour.
1 Like
Ok, after taking a break and getting back to it tonight, I noticed that my issue isn’t related to HTTPS records after all. I removed them, and still had the same issue.
Using the config below, it was not reliably 301 redirecting mypogobadges.com to www.mypogobadges.com (in a web browser) - If I entered in https://mypogobadges.com in the URL bar 3 times in a row, it would stop redirecting.
server {
listen 72.9.154.32:80;
server_name mypogobadges.com www.mypogobadges.com;
return 301 https://www.mypogobadges.com$request_uri;
}
server {
listen 72.9.154.32:443 ssl accept_filter=dataready reuseport;
server_name mypogobadges.com;
ssl_certificate /cert/mypogobadges.com/mypogobadges_ecc.crt;
ssl_certificate_key /cert/mypogobadges.com/mypogobadges_ecc.key;
ssl_certificate /cert/mypogobadges.com/mypogobadges.crt;
ssl_certificate_key /cert/mypogobadges.com/mypogobadges.key;
include allrequests.conf;
return 301 https://www.mypogobadges.com$request_uri;
}
server {
listen 72.9.154.32:443 quic reuseport;
listen 72.9.154.32:443 ssl;
server_name www.mypogobadges.com;
....
}
However, If I use this config below with a “if $host” statement, it redirects to www every time without failing.
server {
listen 72.9.154.32:80;
server_name mypogobadges.com www.mypogobadges.com;
return 301 https://www.mypogobadges.com$request_uri;
}
server {
listen 72.9.154.32:443 quic reuseport;
listen 72.9.154.32:443 ssl accept_filter=dataready reuseport;
server_name mypogobadges.com www.mypogobadges.com;
if ($host = "mypogobadges.com") {
return 301 https://www.mypogobadges.com$request_uri;
}
....
}
Any idea why that happens? My first config should work consistently, but it doesn’t. The second one never fails.
Is the if $host statement a bad thing to use in this case?
Are you totally sure your browser is not caching the url? If curl works as expected, the issue really seems to be a browser issue instead of something to do with your NGINX config. You really should be good to go by simply using a 301 redirect.
The second config you posted is rather unusual, and we don’t really recommend using if unless absolutely necessary. The way it’s processed is unique within NGINX itself and can lead to some issues – especially in the location context. You are using it in the server context here so you are likely fine, although it depends on the rest of your config (but it’s still better to avoid it if you can, which you really should be able to do for your use case).
I’m not sure what’s going on, but I do know that I can’t reproduce my issue on any other website. I’ve tried 20 websites like Google, Bing, Reddit, TMZ, Facebook, LinkedIn, etc) and the 301 redirects never fail for me in the web browser.
My top config fails (in the web browser after 2-3 retries), but using my last config, it never fails.
That tells me something isn’t right here.
You seem to be running into some weird edge case but I am pretty sure it’s not NGINX related at this point. There might be some AWS R53 shenanigans going on behind the scenes that for some reason get fixed by using if.
1 Like
I managed to solve the issue and have been running this configuration for 7 days without any problems. It works fine with HTTPS records as well.
If you’re using reuseport, make sure to enable it only on the final destination server block - otherwise, you may run into issues.
Also, make sure you have http2 on; in your main nginx.conf file.
I hope this saves someone the headaches it gave me.
server {
listen 72.9.154.32:80 default_server;
server_name mypogobadges.com www.mypogobadges.com;
return 301 https://www.mypogobadges.com$request_uri;
}
server {
listen 72.9.154.32:443 quic;
listen 72.9.154.32:443 ssl default_server;
server_name mypogobadges.com;
return 301 https://www.mypogobadges.com$request_uri;
}
server {
listen 72.9.154.32:443 quic reuseport;
listen 72.9.154.32:443 ssl reuseport;
server_name www.mypogobadges.com;
... rest of your config here ...
}