2068787 - Firefox 155: HTTPS connections to local network (*.internal) extremely slow, HTTP works fine

Status: RESOLVED DUPLICATE of bug 2066852

(Core :: Networking, defect)

Description

[Hans-Stefan Müller]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:155.0) Gecko/20100101 Firefox/155.0

Steps to reproduce:

Since updating to Firefox 155, HTTPS connections to local network sites (*.internal domain) are extremely slow (50+ seconds total load time). HTTP connections to the same servers work instantly. The issue does not affect public internet sites.

Environment:

Windows 11
Firefox 155.0
Local DNS server: Bind9 on Debian
Internal domains: *.internal

Certificates: Self-signed via own CA (openSSL), no OCSP, no CRL

1. Open any local HTTPS site (*.internal) in Firefox 155
2. Observe extremely slow loading (50+ seconds)
3. Open the same site in HTTP → loads instantly
4. Open the same site in Chrome with HTTPS → loads instantly

Workaround:
Downgrading to Firefox ESR resolves the issue completely – same sites load instantly.

Additional info:
network.http.happy_eyeballs_enabled = false → no effect
network.lna.enabled = false → no effect
network.dns.disableIPv6 = true → no effect
security.OCSP.enabled = 0 → no effect
Fresh Firefox 155 installation → no effect
Servers have both A and AAAA (fd00::) records in DNS

Actual results:

Network tab timings (F12):

Blocked: ~2,69s
DNS: ~2,27s
TLS: negligible
Waiting: negligible

Expected results:

loading instantly

Comment 1

[Valentin Gosu [:valentin]]

Thank you for the report.
Could you capture a profile with logs using the instructions at https://firefox-source-docs.mozilla.org/networking/http/logging.html#using-about-logging
Make sure to click Share on the profiler page, and upload the profile to give us the link.
Ideally use a fresh profile, so that you don't include any private information.

Cheers!

Comment 2

[Hans-Stefan Müller]

Attachment: Firefoxlog.txt-main.24712.moz_log

This is the Firefox HTTP-Logging file

Comment 3

[Valentin Gosu [:valentin]]

Thanks!

Could you check if flipping network.dns.use_https_rr_as_altsvc fixes the problem?
One odd thing I see in the log is:

2026-09-03 13:34:10.382000 UTC - [Parent 24712: Main Thread]: D/nsHostResolver OnResolveHostComplete: energie-m.internal
2026-09-03 13:34:10.382000 UTC - [Parent 24712: Socket Thread]: V/nsHttp SpeculativeTransaction::OnHTTPSRRAvailable [this=209438e98a0]
2026-09-03 13:34:10.382000 UTC - [Parent 24712: Cache2 I/O]: D/cache2 CacheIndex::WriteRecords()
2026-09-03 13:34:10.382000 UTC - [Parent 24712: Socket Thread]: V/nsHttp HTTPSSVC: use new routed host (internal) and new npnToken (None)

It would seem the HTTPS record for the internal domain might be a cname to internal ?!
Could you go to about:networking#dnslookuptool and lookup energie-m.internal ?

if it does seem to have an HTTPS RR could you either capture a wireshark dump of the DNS requests while loading the page?
Otherwise, you might be able to use https://mozilla.github.io/mozregression/quickstart.html to figure out what change in Firefox introduced the problem.

Thanks!

Comment 4

[Hans-Stefan Müller]

flipping network.dns.use_https_rr_as_altsvc solves the problem. Strangely enough, the problem does not occur on another computer on the same network. about:networking#dnslookuptool gets the correct IPs (IPv4 and IPv6). HTTPS-RRs gets: 0 internal ()
That’s right: energie-m.internal is a CNAME for internal. Did you need any output of wireshark dump or mozregression, then I’d need a quick guide on what to do with the tools.

Thanks a lot for this excellent help!

Comment 5

[Valentin Gosu [:valentin]]

That’s right: energie-m.internal is a CNAME for internal. Did you need any output of wireshark dump or mozregression, then I’d need a quick guide on what to do with the tools.

Ah, I see. I think that this might have been fixed by bug 2066852.
Could you check again with the latest nightly build? https://nightly.mozilla.org/

Thanks!

Comment 6

[Hans-Stefan Müller]

I’ve tried it with the Nightly version (cool design). It works with security.enterprise_roots.enabled = true | false. However, the default setting is now true, as in my workaround.

Thanks a lot!

Comment 7

[Hans-Stefan Müller]

(In reply to Hans-Stefan Müller from comment #6)
It also works with network.dns.use_https_rr_as_altsvc = true|false!

Comment 8

[Valentin Gosu [:valentin]]

Thanks!