I have a very interesting case here. I am running an unraid swag docker with nextcloud i.c.w. a duckdns subdomain.
When accessing the subdomain subdomain.duckdns.org with microsoft edge from a non local IP (e.g. laptop outside of my own home network) i can enforce it to use https://subdomain.duckdns.org . If I use mozilla as a browser on the same host, it automatically does https://www.subdomain.duckdns.org and of course this hits my revers proxy “this is a swag instance”. How can I enforce it to use https://subdomain.duckdns.org not matter what browser or host you are using? I have been searching for solutions for days but I can’t get any closer.
as long you only want to address the www. portion of the hostname (or maybe few more) you could instruct you reverse proxy to redirect requests from https://www.subdomain... to https://subdomain... it is also possible to do a “rewrite” of requests.
But keep in mind www.subdomain and subdomain are technically different hosts and you still have to maintain valid TLS certificates and configs for it. from the top of my head I don’t remember automatic addition of “www.” (for ages). I think it was common 10 or 20y ago but not the case anymore. Maybe firefox for some reason “doesn’t want” to connect with subdomain? e.g. because certificate errors (in the past) etc. try incognito/private mode and check if the issues occurs there as well.
I think this should be the solution. I have been looking for some instructions to be able to do so. But I cannot figure it out.
The reason is that I want to send the users on the nextcloud I created a link for them to sign in directly via their browsers. But if the www. is automatically created how can they access it from their browser without any issue. The fact www.subdomain and subdomain.com are different I get it…but its still strange that it goes to my reverseproxy right?
Also using firefox in the private window does not workout. I have tried to change settings in mozilla but that is not what I want to do for the other users.
this is likely the reason www. works from the TLS point of view without additional configuration.
I would expect there is no more “smart” guessing on the browser side if you provide the complete link with leading https:// . AFAIK the browser only adds URL parts in case the URL is incomplete (maybe unreachable?) see below articles related to “domain guessing”
