Suche nach einer Lösung für die Verwendung einer aktuellen Firefoxversion unter Ubuntu 24.04

Warum Firefox beim Zugriff auf die FRITZ!Box minutenlang hing, während Chromium und Brave problemlos funktionierten – und wie eine einzige Firefox-Einstellung das Problem löste.

Ausgangssituation: FRITZ!OS 8.50 und eine neue MyFRITZ!-Adresse

Nach der Aktualisierung meiner FRITZ!Box 7690 auf FRITZ!OS 8.50 wollte ich bei dieser Gelegenheit auch meine MyFRITZ!-Konfiguration überarbeiten. Mein Internetanschluss läuft über einen Anbiter der sowohl IPv4 als auch IPv6 anbietet. Außerdem verwende ich einen eigenen DynDNS-Zugang als Alternative zu dem MyFritz!-Zugang. Im Zuge des Updates wurde auch die MyFRITZ!-Adresse verändert (von mir). Statt der bisherigen Adresse sollte eine neue Wunschadresse mit der Endung .myfritz.link verwendet werden.

Was zunächst nach einer unkomplizierten Änderung aussah, entwickelte sich zu einer längeren Fehlersuche.

Dabei traten zwei unterschiedliche Probleme auf:

1. Die neue MyFRITZ!-Adresse wurde nicht richtig synchronisiert.
2. Firefox hatte massive Schwierigkeiten beim HTTPS-Zugriff auf die FRITZ!Box.

Das zweite Problem erwies sich schließlich als besonders interessant.

Problem 1: MyFRITZ!-Adresse konnte nicht ermittelt werden

Nach der Änderung der MyFRITZ!-Adresse erschien in der Benutzeroberfläche der FRITZ!Box unter

Internet → MyFRITZ!-Konto

folgende Meldung:

Ihre FRITZ!Box ist bei MyFRITZ! registriert. Ihre MyFRITZ!-Adresse konnte aber nicht ermittelt werden.

Status wird aktualisiert …

Das Merkwürdige daran: Im MyFRITZ!-Portal war die neue Adresse bereits eingetragen.

Auch unter

Internet → Freigaben → FRITZ!Box-Dienste

wurde die neue Adresse angezeigt.

Die FRITZ!Box kannte die Adresse also offenbar bereits, konnte den MyFRITZ!-Status aber nicht vollständig aktualisieren.

Erste Vermutung: Fehlende öffentliche IPv4-Adresse

Im MyFRITZ!-Portal erschien zusätzlich eine Warnung, dass sich die FRITZ!Box mit einer nicht öffentlich erreichbaren IPv4-Adresse registriert hätte.

Das passte allerdings nicht zu meiner Internetverbindung.

Im Online-Monitor der FRITZ!Box war eine öffentliche IPv4-Adresse aus dem Adressbereich der Telekom sichtbar.

Auch IPv6 funktionierte.

Damit war klar: Der Internetanschluss selbst war grundsätzlich in Ordnung.

DNS-Abfragen brachten Klarheit

Um die MyFRITZ!-Adresse zu überprüfen, verwendete ich Google Public DNS:

https://dns.google

Dort führte ich zwei Abfragen für die neue Wunschadresse durch:

• A-Record für IPv4
• AAAA-Record für IPv6

Beide Abfragen lieferten:

{
  "Status": 3
}

Das bedeutet:

NXDOMAIN – der abgefragte Domainname existiert aus Sicht des DNS-Resolvers nicht.

Die neue Adresse war also zwar in MyFRITZ!Net hinterlegt, aber noch nicht öffentlich auflösbar.

Wie lange dauert die Synchronisierung?

FRITZ! beziehungsweise AVM dokumentiert, dass es nach der Änderung einer MyFRITZ!-Wunschadresse bis zu 25 Stunden dauern kann, bis die neue Adresse in der FRITZ!Box angezeigt wird.

Quelle: FRITZ! – MyFRITZ!-Adresse der FRITZ!Box ändern. FRITZ!

In meinem Fall war das Problem allerdings auch nach rund 35 Stunden noch vorhanden. Schließlich legte ich die MyFRITZ!-Konfiguration neu an.

Danach funktionierte MyFRITZ! wieder.

Ob die Ursache eine fehlerhafte Registrierung oder ein Problem bei der DNS-Aktualisierung war, ließ sich nicht abschließend feststellen. Damit schien das eigentliche Problem zunächst erledigt.

Doch anschließend fiel mir ein weiteres Verhalten auf.

Problem 2: Firefox lädt die FRITZ!Box extrem langsam

Mit der neu eingerichteten MyFRITZ!-Adresse konnte ich meine FRITZ!Box wieder über das Internet erreichen. Allerdings gab es einen gravierenden Unterschied zwischen den Browsern.

Chromium und Brave öffneten die FRITZ!Box-Oberfläche praktisch sofort.

Firefox dagegen zeigte ein völlig anderes Verhalten:

• Der Verbindungsaufbau dauerte teilweise sehr lange.
• In der Statusanzeige erschien „TLS-Handshake wird durchgeführt“.
• Irgendwann wurde die Anmeldeseite angezeigt.
• Nach Eingabe der Zugangsdaten begann das lange Warten erneut.
• Teilweise endete der Vorgang mit einer vollständig weißen Seite.

Besonders irritierend war, dass dieses Verhalten nicht nur bei MyFRITZ!, sondern auch bei meiner eigenen DynDNS-Adresse auftrat. Es war also kein Problem, das ausschließlich den MyFRITZ!-Dienst betraf.

War TLS 1.2 die Ursache?

Meine erste Vermutung war ein Problem mit TLS.

Die FRITZ!Box stellt ihre Benutzeroberfläche über HTTPS bereit. Bei mir läuft dieser Zugriff über TCP-Port 444. Da Firefox beim Verbindungsaufbau ausdrücklich den TLS-Handshake anzeigte, lag die Vermutung nahe, dass Firefox und die FRITZ!Box Schwierigkeiten bei der TLS-Aushandlung hatten. Firefox unterstützt sowohl TLS 1.2 als auch TLS 1.3.

Die entsprechenden Einstellungen lassen sich über about:config überprüfen:

security.tls.version.min
security.tls.version.max

Die üblichen Werte lauten:

security.tls.version.min = 3
security.tls.version.max = 4

Dabei steht:

• 3 für TLS 1.2
• 4 für TLS 1.3

Eine Veränderung dieser Einstellungen erschien zunächst allerdings nicht sinnvoll. Denn Firefox konnte die Anmeldeseite zumindest gelegentlich aufrufen. Die verschlüsselte Verbindung funktionierte also grundsätzlich. Ein generelles TLS-Versionsproblem erschien deshalb zunehmend unwahrscheinlich.

Auch Let’s Encrypt war nicht das Problem

Ein weiterer Verdacht betraf das HTTPS-Zertifikat.

Für meinen eigenen DynDNS-Namen verwendete die FRITZ!Box ein selbst signiertes Zertifikat. Bei der eingerichteten MyFRITZ!-Adresse kommt dagegen ein Let’s-Encrypt-Zertifikat zum Einsatz. Trotzdem trat das Problem auch dort auf – eine interessante Erkenntnis:

Ein gültiges Let’s-Encrypt-Zertifikat garantiert noch nicht, dass sämtliche HTTPS-Anfragen zuverlässig und schnell verarbeitet werden.

Ein Zertifikat sorgt dafür, dass der Browser die Identität des Servers überprüfen und eine verschlüsselte Verbindung aufbauen kann. Die anschließende Übertragung der Webseitenbestandteile ist eine andere Angelegenheit. Damit rückte die Kommunikation zwischen Firefox und dem Webserver der FRITZ!Box stärker in den Mittelpunkt.

Weitere Tests: IPv6, DNS und Firefox-Erweiterungen

Im nächsten Schritt überprüfte ich mehrere mögliche Fehlerquellen.

IPv6 von Tunnel auf natives IPv6 umgestellt

Meine DSL-Verbindung verwendete zunächst IPv6 über einen Tunnel. Da Tunnelverbindungen unter bestimmten Umständen zu Problemen mit dem Verbindungsaufbau oder der Paketgröße führen können, stellte ich die Konfiguration auf natives IPv6 um. Anschließend standen sowohl IPv4 als auch IPv6 nativ zur Verfügung. Das grundsätzliche Firefox-Problem blieb jedoch bestehen.

Der IPv6-Tunnel war damit zumindest nicht die alleinige Ursache.

DNS-over-HTTPS als mögliche Ursache

Auch Firefox‘ DNS-over-HTTPS-Funktion kam als Ursache infrage. Firefox kann DNS-Abfragen über HTTPS abwickeln und dabei andere DNS-Resolver verwenden als das Betriebssystem. Eine fehlerhafte oder verzögerte DNS-Auflösung könnte erklären, warum sich verschiedene Browser unterschiedlich verhalten. Allerdings passte dieses Szenario nicht vollständig zum Fehlerbild: Firefox konnte die FRITZ!Box erreichen, scheiterte aber teilweise erst beim Nachladen einzelner Dateien. Die DNS-Konfiguration ließ sich deshalb nicht als Hauptursache belegen.

Firefox im Fehlerbehebungsmodus

Ein weiterer Verdacht waren installierte Browsererweiterungen. In der Firefox-Browserkonsole tauchten zahlreiche Meldungen einer Erweiterung auf. Das war zunächst nicht ungewöhnlich, machte Erweiterungen aber zu einem sinnvollen Untersuchungsgegenstand. Ich startete Firefox deshalb im Fehlerbehebungsmodus – der deaktiviert vorübergehend unter anderem alle Browsererweiterungen.

Das Ergebnis: Keine Verbesserung – Damit wurden Erweiterungen als Ursache ausgeschlossen.

Dann: Firefox-Netzwerkanalyse mit F12

Der entscheidende Hinweis kam schließlich aus den Firefox-Entwicklerwerkzeugen. Diese lassen sich mit F12 öffnen. Unter dem Reiter Netzwerkanalyse kann Firefox sämtliche HTTP-Anfragen einer Webseite protokollieren.

Dazu gehören beispielsweise:

• HTML-Dateien
• JavaScript-Dateien
• CSS-Dateien
• Bilder
• Hintergrundanfragen

Ich öffnete die MyFRITZ!-Adresse erneut und beobachtete die geladenen Dateien. Dabei zeigte sich etwas Auffälliges.

Einige Dateien wurden geladen – andere liefen in einen Timeout

Viele JavaScript-Dateien wurden erfolgreich übertragen:

transition.js      200 OK
caps-lock.js       200 OK
dialog.js          200 OK
wizard.js          200 OK

Andere Anfragen scheiterten dagegen:

MainButtons.js     NS_ERROR_NET_TIMEOUT
PageTabs.js        NS_ERROR_NET_TIMEOUT
InfoBox.js         NS_ERROR_NET_TIMEOUT
datahandler.js     NS_ERROR_NET_TIMEOUT
ajax.js            NS_ERROR_NET_TIMEOUT

Das war der erste wirklich konkrete technische Hinweis.

Firefox konnte die Verbindung zur FRITZ!Box aufbauen und zahlreiche Dateien erfolgreich abrufen.

Einzelne HTTP-Anfragen liefen jedoch in einen Netzwerk-Timeout.

Damit ließ sich auch die weiße Seite erklären. Wenn wichtige JavaScript-Dateien fehlen, kann die FRITZ!Box-Oberfläche unter Umständen nicht vollständig initialisiert werden.

Auffällige Ladezeiten

Die Netzwerkanalyse zeigte unter anderem:

Das war bemerkenswert. Die HTML-Grundstruktur war schnell geladen. Erst beim vollständigen Nachladen der Ressourcen entstanden massive Verzögerungen. Besonders interessant war dabei, dass die Netzwerkanalyse HTTP/1.1 anzeigte. Denn bei HTTP/1.1 spielt die Anzahl paralleler Verbindungen zu einem Server eine wichtige Rolle.

Die eigentliche Ursache: Eine ungewöhnliche Firefox-Einstellung

Nach den bisherigen Beobachtungen rückte eine Firefox-Einstellung in den Mittelpunkt:

network.http.max-persistent-connections-per-server

Diese Einstellung bestimmt, wie viele persistente HTTP/1.1-Verbindungen Firefox gleichzeitig zu einem Server verwenden darf.

Sie lässt sich über folgende Adresse aufrufen:

about:config

Anschließend sucht man nach:

network.http.max-persistent-connections-per-server

Bei mir stand dort der Wert 37!

Das überraschte mich etwas – offenbar hatte ich den Wert irgendwann verändert zur Optimierung von Verbindungen.

Jedenfalls stand dort:

network.http.max-persistent-connections-per-server = 37

Das ist deutlich mehr als der Firefox-Standardwert den Mozilla mit 6 gleichzeitigen HTTP-Verbindungen pro Server angibt. Die Mozilla-Dokumentation erklärt außerdem, dass weitere Anfragen warten müssen, wenn bereits sämtliche verfügbaren Verbindungen belegt sind. Damit war eine plausible Erklärung für das beobachtete Verhalten gefunden. Wenn Firefox bis zu 37 gleichzeitige Verbindungen aufbauen darf, kann das den Webserver eines Routers möglicherweise stärker beanspruchen als eine kleinere Zahl paralleler Verbindungen. Ob tatsächlich die FRITZ!Box selbst, die Netzwerkverbindung oder eine Wechselwirkung mit Firefox für die Timeouts verantwortlich war, lässt sich daraus allein nicht belegen. Aber die Einstellung war ein sehr guter Ansatzpunkt für einen gezielten Test.

Der entscheidende Test: Von 37 auf 2

Ich änderte den Wert testweise auf:

network.http.max-persistent-connections-per-server = 2

Anschließend rief ich die FRITZ!Box erneut über MyFRITZ! auf. Und tatsächlich: Die Situation verbesserte sich deutlich! Firefox konnte die Oberfläche nun wesentlich zuverlässiger laden. Das war der erste Test, der eine klar erkennbare Verbesserung brachte. Die Vermutung, dass die hohe Anzahl erlaubter paralleler HTTP-Verbindungen zum Problem bei trug, wurde damit erheblich gestützt. Allerdings wollte ich Firefox nicht dauerhaft unnötig auf zwei Verbindungen pro Server begrenzen. Deshalb folgte ein weiterer Test, bei dem ich Firefox zurück auf seinen Standardwert eingestellt habe. In about:config lässt sich eine individuell veränderte Einstellung über das Zurücksetzen-Symbol auf ihren Standardwert zurückstellen.

Firefox setzte die Einstellung automatisch zurück auf:

network.http.max-persistent-connections-per-server = 6

Damit war auch bestätigt, dass die 37 nicht dem Standard meiner Firefox-Version entsprachen. Anschließend testete ich den Zugriff auf die FRITZ!Box erneut und auch mit dem Standardwert 6 funktionierte alles problemlos! Die langen Ladezeiten waren verschwunden. Die FRITZ!Box-Anmeldeseite wurde zuverlässig geöffnet. Auch nach dem Login ließ sich die Benutzeroberfläche wieder normal verwenden. Die Änderung von 37 auf 6 hatte das Problem in meiner Konfiguration offenbar gelöst.

Warum funktionierten Chromium und Brave problemlos?

Das ist eine besonders interessante Frage. Chromium-basierte Browser und Firefox verwenden unterschiedliche Netzwerkimplementierungen.

Sie können sich unter anderem darin unterscheiden, wie sie:

• Verbindungen zu einem Server wiederverwenden
• Gleichzeitige HTTP-Anfragen verwalten
• Timeouts behandeln
• Zwischen IPv4 und IPv6 auswählen
• HTTP-Verbindungen aufbauen und wiederherstellen

In meinem Fall kam hinzu, dass Firefox mit dem ungewöhnlich hohen Wert 37 konfiguriert war. Chromium und Brave verwendeten ihre eigenen Verbindungseinstellungen, während Firefox offenbar mit einer älteren, individuellen Konfiguration arbeitete. Nach dem Zurücksetzen auf den Standardwert verhielt sich auch Firefox wieder normal.

Nicht immer sind TLS, IPv6 oder Zertifikate schuld

Diese Fehlersuche hat mich einige Zeit gekostet. Zunächst sah alles nach einem Problem mit MyFRITZ!, IPv6, TLS oder Let’s Encrypt aus.

Die Symptome passten durchaus zu solchen Ursachen:

• Langsamer TLS-Handshake
• Extrem verzögerter Seitenaufbau
• Weiße Seite nach dem Login
• Funktionierender Zugriff mit Chromium und Brave
• Fehler ausschließlich in Firefox

Die entscheidende Erkenntnis kam jedoch erst durch die Netzwerkanalyse im Browser. Dort zeigte sich, dass Firefox zahlreiche Dateien erfolgreich laden konnte, während andere Anfragen mit NS_ERROR_NET_TIMEOUT scheiterten. Das führte zur Überprüfung der maximalen Anzahl persistenter HTTP-Verbindungen pro Server. Und genau dort lag die entscheidende Auffälligkeit:

Firefox war auf 37 Verbindungen pro Server eingestellt – statt auf den Standardwert 6.

Nach dem Zurücksetzen funktionierte die FRITZ!Box-Oberfläche wieder zuverlässig.

Wichtige Erkenntnisse

1. Eine weiße Seite muss kein JavaScript-Fehler sein. Fehlende JavaScript-Dateien können auch durch Netzwerk-Timeouts verursacht werden.
2. Die Anzeige „TLS-Handshake“ beweist kein TLS-Problem. Sie ist zunächst nur ein Hinweis darauf, in welcher Phase der Browser gerade zu hängen scheint.
3. Ein gültiges Let’s-Encrypt-Zertifikat garantiert keinen störungsfreien Webseitenaufbau. Zertifikatsprüfung und Ressourcenübertragung sind unterschiedliche Vorgänge.
4. Die Firefox-Netzwerkanalyse ist bei solchen Problemen extrem hilfreich. Sie zeigt, welche Dateien erfolgreich geladen werden und welche Anfragen tatsächlich scheitern.
5. Alte Browseroptimierungen können später Probleme verursachen. Gerade veränderte Netzwerkeinstellungen sollte man bei unerklärlichem Browserverhalten überprüfen.
6. Der Standardwert ist vielleicht doch die bessere Wahl. In meinem Fall war nicht eine neue Optimierung, sondern das Rückgängigmachen einer alten Änderung die Lösung.

Weitere Informationen

• Mozilla: Network Request Details – Firefox Source Docs
• FRITZ!: MyFRITZ!-Adresse der FRITZ!Box ändern
• FRITZ!: E-Mail-Adresse des MyFRITZ!-Kontos ändern
• Mozilla Support: Anzahl gleichzeitiger Verbindungen in Firefox