Firefox Community Forum

when i enter a web address to enter a search address to find the finformation being sent to me thaty is located at this address; kdrive.informiak.combold textI get the message  ;

Hmm. We’re having trouble finding that site.

We can’t connect to the server at kdrive.informiak.com.

If you entered the right address, you can:

   Try again later
   Check your network connection
   Check that Firefox has permission to access the web (you might be connected but behind a firewall)

I just started up my new MacBook Pro, M5 pro machine and Firefox will not work. Tahoe 26.3 is OS.

Dale Howard Jonesboro, GA

PS--Safari and DuckDuck Go browsers are working normally.

I need help with a problem that has tortured me for weeks. I use debian 13 with plasmakde. I don't know why, but when I connect to a wifi after some time it doesn't work anymore ONLY with Firefox. I can perfectly use any other app which requires internet but firefox. Sometimes it gives me the error "The connection has timed out", sometimes the error "Unable to find the proxy server" (even if I selected no proxy in the network settings). I searched online but I couldn't find anything helpful, so I can only hope to find a solution in here. Thank you very much in advance!

A user I am servicing uses Firefox every day. They are on Windows 11. Every afternoon (sometimes at other times), Firefox stops working and loses its internet connection (everything else on their computer continues to be connected). When they close and restart Firefox to reconnect, it then tells me the user that they are using an old profile and need to create a new one. They're able to re-log into their Firefox account, which eventually resyncs all their data, but they then have to re-sign into everything, which is a major inconvenience. The only workaround the I have found is to reinstall Firefox, ever time this happens which then allows the user to use all their settings until they have to repeat the process the next day (i.e., everything remains signed in and/or logging back in is easier than described above).

Here's some additional information and trouble testing we've conducted:

Uninstall and Reinstall of Fire fox

Check for updates (Updated to new version and still suffered the same issue)

Cleared cache and cookies

No extensions

Please if anyone has any advice or recommendations it would be greatly appreciated.

I made my post originally on the 3/9/26 but no one has gotten back to me, so I am creating another post.

While browsing on my desktop , I am unable to open E Shram Card blog. it appears like there is an error in connection , but despite of good connection, cannot open it.

I open up firefox and the message appears - you must be signed into this network in order to access the internet. BUT i can use the internet. This is not a problem on a W10 machine which I also use.

After i installed firefox net jitter somehow appeared in my cs2. every time i play jitter is jumping randomly. Can yall somehow fix this i really enjoy using this browser but i just cant play with it running in the background((((

Hello everyone,

We are currently investigating an issue where browsers are sending HTTP requests with Connection: close in the header during integrated Windows authentication (NTLM authentication) via SAML Service Provider (SP), leading to premature termination of the TCP connection.

This behavior occurs in the middle of the authentication process, preventing the NTLM authentication from completing and subsequently prompting for re-authentication.

We have observed the following browser behaviors:

Chrome and Edge: These browsers function without issues, communicating with Connection: keep-alive. Safari (macOS): Older versions of macOS with Safari exhibit the Connection: close behavior, leading to authentication failure. Newer versions of macOS with Safari work correctly with Connection: keep-alive. Firefox (macOS): Even on the latest versions of macOS, Firefox continues to attach Connection: close, resulting in authentication failure. Upon reviewing logs, we've identified that various browsers attach the Connection: close header during the NTLMSSP_NEGOTIATE request in the NTLM authentication sequence. Although this happens in an environment with a load balancer, we have confirmed that the load balancer is not modifying the header; rather, the client (browser) is adding it.

We would appreciate your insights into the conditions under which Firefox attaches Connection: close to HTTP requests, especially considering the differences across macOS versions and other browsers, addressing the following points:

Are there any known conditions or past cases where Firefox outputs Connection: close in an NTLM authentication environment via SAML SP? Given that older Safari versions show similar behavior, we are also considering if there's a common factor depending on NTLM authentication and browser version. What are the general heuristics, logic, or triggers for a browser to decide to "close" a connection or to attach Connection: close? We are particularly interested in cases that occur mid-authentication process. Could specific configurations (e.g., the combination of SAML and NTLM authentication, or the presence of an intermediate proxy/load balancer) potentially influence Firefox's Connection: close behavior? Are there any additional logs or debugging information we should collect from the Firefox client side to further pinpoint this issue? Any guidance or suggestions you could provide to help us resolve this problem would be greatly appreciated.

Thank you.

There are times when i am using Firefox that my PC will randomly disconnect from the internet. Sometimes it will reconnect on its own after I close Firefox. Other times I either have to restart my PC or go into Network & Internet settings and connect to my network. I am still running Window 10, free updates. Does anyone know what is causing this? It does not happen with any other browsers.

Firefox 147.0.4 on macOS 26.3 does not work via SOCKS proxy.

Firefox 147.0.4 on Windows 11 x64 works fine via the same intranet SOCKS proxy, with exactly the same settings.

The advantage of Firefox is its flexibility. It supports its own SOCKS proxy settings, independent of systems-wide ones. Unfortunately, it seems this Firefox feature is broken on macOS (but Windows version works perfectly).

Safari 26.3 (21623.2.7.11.6) and DuckDuckGo 1.177.0 (625) web-browsers that use system-wide macOS SOCKS proxy settings also works fine with this intranet proxy server. So it seems SOCKS proxy server itself is OK, and the problem is confined to Firefox on macOS.

Has anyone seen Firefox 147 on macOS work via SOCKS proxy? Is there a principal difference between how Firefox handles SOCKS proxy on macOS vs. Windows? What might be the best way to address the problem on macOS?

Thanks!

I am using 140 ESR version on linux with Cloudflare's DNS over HTTPS and with DOH active for some reason resolving a domain like d3oklwo3y1bx83.cloudfront.net will resolve to local host IP 127.0.0.1.

I am using firefox about:networking#dnslookuptool to test resolution of the domain d3oklwo3y1bx83.cloudfront.net Both with DOH on and off the resolution remains local host. I tried another browser on the same workstation and I was able to receive a resolution of 13.225.193.203 13.225.193.133 13.225.193.64 13.225.193.58 Why is firefox ESR not able to resolve that domain? What are causes ?

Is is firefox dnslookuptool results.

On a dual-stack network, with Windows tcpip6 ‘disabledcomponents’ parameter set to prefer IPv6, Firefox ignores this setting whenever an endpoint resolves both an IPv4 and a NAT64 address.

While monitoring traffic captured while connecting to sites in Firefox, if the initial DNS request for the site comes back with an IPv6 address only, the connection attempts from client’s IPv6 address to destination IPv6. If DNS answers come back with IPv4 and IPv6, the connection attempts IPv6 to IPv6. If DNS answers come back with IPv4 and a NAT64 address, Firefox doesn’t even attempt to connect to the NAT64 address, it immediately defaults to IPv4. I’ve tried disabling the IPv4 fallback setting which doesn’t change the behavior.

We’re running version 140.8.0esr. Is this behavior intended for Firefox? Is there a way to configure Firefox so it doesn’t ignore NAT64 addresses in dual-stack environments? The only way I found to force this was to completely disable the IPv4 stack on the client system’s NIC.