You just introduced a new "HTTPS-Only Mode" -- as of the last version or two, it no longer allows access to an "http://" site. All such sites are blocked only by Firefox. Is there a fix?

The https:// only mode has been there for a couple of years from what I recall or even longer, when did you last update?

and see image

As of a couple of days ago, I was at Firefox 154.0.1. My settings are as you show in the image -- to "Don't Enable" the block. Yesterday I updated to 155.0.1. The HTTPS-Only setting is the same, but now it ALWAYS blocks any http:// call.

Here's an example you can run:

http://www.ancestXXX.com.launch/default.asp?fn=Hannah&ln=Stones&by=1794

Firefox 155.0.1 now converts this to:

https://www.ancestXXX.com.launch/default.asp?fn=Hannah&ln=Stones&by=1794

Which always fails, whereas prior to version 155, this always succeeded.

I create a genealogy software, that allows users to do online research. They initiate such calls to the Internet via our software. Starting a couple of days ago, we started getting a lot of calls asking why their calls to initiate research are always failing, and we have traced it to Firefox 155. We are now encouraging them to use a different default browser so that the calls to "http://" will function properly.

I expect that this is a bug in Firefox 155.0.1, which they would like to get fixed, but it is currently causing havoc with my customers.

I have a similar issue with an http:// page I go to every day. Starting from 155.0.1 (or possibly 155.0) the page redirects to https:// which brings up an error page from the hosting company. I did a full uninstall and folder cleanup followed by a clean reinstall of Firefox. I made all the settings step by step checking the http:// website after each change and it worked fine UNTIL I enabled DNS over HTTPS (DOH). The problem is there when using Cloudflare, Quad9 or Google. If I turn DOH off the site works OK. I tried on a different machine (laptop) with the same setup and exactly the same results.

I hope this will be fixed soon.

Thanks

P.S I'm using Windows 11 Pro 25H2 fully up to date. The second machine / laptop runs Windows 10 Pro 22H2 with Extended Security Updates. I also tried the http:// site using Brave Browser (latest version) with DOH enabled and everything works OK there, so this seems to be specific to Firefox.

Tony - Thanks. This work-around actually works. I did an altered version, where rather than completely disable DNS over HTTPS, I added our domain (ancestXXX.com) to the list of exclusions. Both methods solved this for me. I would mark your answer as the Solution, except that until Firefox fixes the root problem, we will have a significant number of customers who we can't reach to alert them to the resolve, and many or most of them would be hesitant to make changes to their Firefox. The only true resolve is for Mozilla to fix this.

Glad it helped . Yes, please keep the thread open until we get a fix. I will also try to set an exception for sites that need it on my side.

I just observed one more piece of information. I first turn DOH off to see if that would work, and it did. Then I set it back to the 'Default' setting and established an exception. That seemed to work also, but then I noticed that the DOH settings page told me that DOH was OFF, even though the radio selection was for Default. So apparently, they have another bug, where once you turn DOH off, you can't turn it back on.

Yes, you're right. I set some exceptions. all worked OK, but when I go back to the the settings again DOH is now turned off! When I enable it again the exceptions are gone.

I found that while most settings in Firefox seem to get permanently set just by clicking on an option, in this case I had to exit Firefox (FF) then restart. So after setting the DOH to the "Default" setting, but it still working as if it were Off, I then exited Firefox and restarted. Now it was actually back on and the request for the "http://" site no longer worked.

This time, I left the DOH setting to "Default" and added my domain as an exception. Then exited FF and restarted. This time, the setting stuck, and the "http://" request works.

attached are my settings. I set Cloudflare as my DOH provider rather than using the default option. Indeed, after restarting Firefox the http:// site exceptions I set before are visible again but they are ignored and the behaviour is the same as before i.e force redirecting to https://

Can you reproduce in a clean profile, and can you provide a URL to reproduce?

Seems working as expected with default settings, tested just with and explicit DoH provider as shown below:

I am trying to post a reply but links seem not allowed ?

well, I wrote some answers here. when I finally managed to add link to it, it has vanished.

please refer to all of the details both I and the question owner have provided. I did a full uninstall and clean new install of Firefox 155.0.1 with a new profile, only importing my bookmarks from a backup afterwards. Also same issue on a different machine with a different user profile.

You can test on these http:// sites dk0wcy<dot>de and www<dot>dk0wcy<dot>de

With DOH enabled using Cloudflare, Quad9 or Google the site is redirected to https:// which gets an error from the hosting company. It only works correctly with DOH turned off.

I use the site daily and can say for sure that the issue occurred only with version 155.0.1 or possibly 155.0 (they were only a few days apart).

Thanks Tony J

I referred to all the details, and the only URL available was bogus. Also sites.dk0wcy.de does not exist (no A/AAAA/CNAME records). I do however see the upgrade on http://www.dk0wcy.de (no matter the DoH provider) where the invalid wildcard cert from the hosting provider should make it fall through back to the HTTP, unless there's some preload set — I'll see if I can find anything suspicious.

Interestingly if you open just dk0wcy.de (no www.) it seems to work just fine.

please see screenshot below, this is using Brave Browser with DOH enabled.

The site is functional and also works in Firefox when DOH is turned off.

Yes, I see it for the non–apex domain: Narrowed nightly regression window from [2026-08-04, 2026-08-06] (2 days) to [2026-08-04, 2026-08-05] (1 days) (~0 steps left)

11:37.95 INFO: Got as far as we can go bisecting nightlies...
11:37.95 INFO: Last good revision: 2cf8eec95457451adbd67d223a7af8ed65461fcd (2026-08-04)
11:37.95 INFO: First bad revision: bb3ac5a217ffe1d7fc66eb86f4af7f6e113d9054 (2026-08-05)
11:37.95 INFO: Pushlog:

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=2cf8eec95457451adbd67d223a7af8ed65461fcd&tochange=bb3ac5a217ffe1d7fc66eb86f4af7f6e113d9054

Before trying to bisect to the actual change, I see one potential patch there bugzilla.mozilla.org/2056195 which refers this regression: bugzilla.mozilla.org/2066852 — sounds good to me.

I can confirm the above URL works again in 156.0 Beta 4 so this should be fixed in a release next week. Thanks for the report!

Thanks jbr

I rechecked and see that the http:// dk0wcy de (no www) is working OK now in Firefox 155.0.1 so something has changed somewhere since yesterday. very strange. still redirects to https:// when adding www

Glad to hear that the 156.0 release should fix the issues fully.

Thanks Tony J

The long read is in the standard support timeline bugzilla.mozilla.org/1869075 for the service records in DNS content to speed things up — the potential workaround/preference to skip that spec is mentioned in bugzil.la/2066852#c5 but for anyone willing to download the separate Beta or Nightly firefox.com/channel that'd be the best validation any private or specific hosts work as expected for you.