Chrome und Brave laden keine Websites in der macOS 27 Beta? So beheben Sie das Problem

Sie haben die macOS 27 „Golden Gate" Public Beta installiert, Chrome geöffnet, eine URL eingegeben – und nichts passiert. Der Tab dreht sich. Die Statusleiste zeigt Verbindung wird hergestellt… an und kommt einfach nicht weiter. Nach einer Weile erhalten Sie eine nackte Fehlermeldung – ERR_CONNECTION_TIMED_OUT, ERR_NAME_NOT_RESOLVED, oder Braves fröhliches Diese Seite ist nicht erreichbar. Also probieren Sie eine andere Website. Dasselbe. Jede Website. Dann, halb aus Gewohnheit, öffnen Sie Safari – und diese lädt sofort, beim ersten Versuch, ohne zu zögern. Das Internet funktioniert eindeutig einwandfrei. Ihr WLAN ist in Ordnung. Doch Chrome lädt keine Websites in der macOS 27 Beta, und das bestimmt inzwischen Ihren ganzen Nachmittag – und dasselbe passiert auch in Brave, Edge, Arc und Vivaldi.

Falls das auf Sie zutrifft, atmen Sie erst einmal durch: Weder Ihr Mac noch Ihr Netzwerk sind kaputt. Dies ist eine der am häufigsten gemeldeten Unebenheiten der aktuellen macOS 27 Beta – ein Muster, bei dem Chromium-basierte Browser überhaupt nichts erreichen, während Safari problemlos durchkommt. Es taucht in den Brave-Community-Foren, in Apple-Discussions-Threads und auf den MacRumors-Beta-Boards auf, und der rote Faden ist immer derselbe: Der WebKit-Browser funktioniert, die Chromium-Browser nicht. Diese Aufspaltung ist tatsächlich der größte Hinweis darauf, was schiefläuft, und der Grund, warum die meisten der folgenden Fixes schnell, reversibel sind und Sie nichts radikal zerlegen müssen.

Dieser Leitfaden macht zwei Dinge. Erstens erklärt er – ehrlich und mit der Zurückhaltung, die einer Beta gebührt – warum ausgerechnet die Nicht-Safari-Browser ausfallen. Zweitens erhalten Sie eine Fix-Leiter, die Sie der Reihe nach durchgehen können, vom Dreißig-Sekunden-Schalter, der das Problem für viele Nutzer löst, bis hin zu dem ehrlichen Rückfallplan, den niemand gerne laut ausspricht: Es ist eine Beta, und manchmal ist es die richtige Entscheidung, sich auf Safari zu verlassen oder zur stabilen Version Tahoe zurückzukehren, bis Apple einen neuen Build veröffentlicht. Bringen wir Ihre Browser wieder zum Laufen.

Die wichtigsten Erkenntnisse

• Dass Safari funktioniert, während Chrome, Brave, Edge, Arc und Vivaldi allesamt versagen, ist das Erkennungszeichen dieses Beta-Problems. Es deutet darauf hin, wie die aktuelle macOS 27 Beta den Netzwerkverkehr für Nicht-WebKit-Apps routet – DNS, Netzwerk-Erweiterungen und den App-spezifischen Netzwerkpfad – und nicht auf einen bestimmten Browser.
• Dies wird von Beta-Testern gemeldet, ist aber kein von Apple bestätigter Fehler. Threads in der Brave Community, bei Apple Discussions und auf MacRumors beschreiben es; Apple hat bislang keine offizielle Bestätigung veröffentlicht. Das Verhalten kann sich von einem Beta-Build zum nächsten ändern, testen Sie also nach jedem Update erneut.
• Die erfolgreichsten Fixes sind einfach und reversibel: Schalten Sie das sichere DNS / DNS-over-HTTPS des Browsers aus, deaktivieren Sie jede Netzwerkfilter- oder VPN-Systemerweiterung (Little Snitch, LuLu, Unternehmensfilter, manche Antivirenprogramme), stellen Sie IPv6 auf „Nur lokale Verbindung" und leeren Sie den DNS-Cache.
• Prüfen Sie frühzeitig Private Relay und VPN. iCloud Private Relay und halb verbundene VPN-Tunnel verhalten sich unter der Beta bei Safari anders als bei Chromium-Apps und sind ein häufiger Übeltäter.
• Der ehrliche Rückfallplan ist Safari oder ein Rückschritt. Bei einer Beta warten manche Probleme schlicht auf Apple. Wenn ein funktionierender Chromium-Browser für Sie unverzichtbar ist, erwägen Sie eine Rückkehr zur stabilen Version Tahoe, statt gegen den Build anzukämpfen.

Zuerst: Sind Sie wirklich auf der macOS 27 Beta?

Bevor Sie auch nur eine einzige Einstellung ändern, vergewissern Sie sich, dass Sie tatsächlich auf der Beta sind, um die es in diesem Artikel geht – denn die hier vorgestellten Fixes zielen ganz gezielt auf das Beta-Verhalten ab und können bei der stabilen Version Zeitverschwendung (oder sogar leicht kontraproduktiv) sein.

Prüfen Sie Ihre genaue Version

Öffnen Sie das Apple-Menü > Über diesen Mac und lesen Sie die Versionszeile. Klicken Sie dann auf Weitere Informationen > Softwareupdate (oder Systemeinstellungen > Allgemein > Softwareupdate), um zu sehen, ob Sie auf einer Beta-Version sind.

• Wenn dort macOS 27.0 beta steht (oder das Entwickler-/Public-Beta-Banner angezeigt wird), sind Sie hier genau richtig. Die Public Beta erschien Mitte Juli 2026 – Public Beta 1 am 13. Juli, Public Beta 2 am 22. Juli – und der neueste Entwickler-Build zum Zeitpunkt der Erstellung dieses Artikels ist Beta 4, Build 26A5388g (20. Juli). Apple hat für die Public-Seeds keine festen Build-Strings veröffentlicht, verlassen Sie sich also nicht zu sehr auf eine bestimmte Nummer; „die macOS 27 Public Beta" ist die ehrlichste Beschreibung.
• Wenn dort macOS 26.5.2 (Build 25F84) oder Ähnliches steht, befinden Sie sich auf dem stabilen Tahoe, nicht auf der Beta. In diesem Fall ist ein kompletter Chromium-Ausfall nicht das bekannte Beta-Muster, und Sie sollten es als gewöhnliches Netzwerkproblem behandeln – beginnen Sie mit unserem vollständigen Leitfaden zur Behebung von WLAN-Abbrüchen und dem VPN-Fehlerbehebungsleitfaden anstelle der unten stehenden beta-spezifischen Schritte.

Ein Hinweis für Besitzer von Intel-Macs

macOS 27 „Golden Gate" ist ausschließlich für Apple Silicon – M1 oder neuer. Jeder Intel-Mac wurde in diesem Zyklus fallengelassen. Wenn Sie einen Intel-Rechner besitzen, können Sie die macOS 27 Beta gar nicht ausführen, ein Browserproblem dort hat also eine völlig andere Ursache. Dieser Leitfaden geht von einem Mac der M-Serie auf der Beta aus.

Denken Sie daran, was „Beta" hier bedeutet

Alles Nachfolgende basiert auf dem, was Beta-Tester berichten, zusammengetragen aus Community-Foren und Presseberichten. Nichts davon ist ein von Apple anerkannter Fehler mit einer offiziellen Lösung. Das ist aus zwei Gründen wichtig: Das Verhalten kann sich von Build zu Build ändern (ein Fix, der bei Public Beta 2 nötig war, könnte nach dem nächsten Seed überflüssig sein), und für manche Tester bestand die letztendliche Lösung schlicht darin, auf Apple zu warten. Stellen Sie Ihre Erwartungen entsprechend auf ein Vorabversion-Betriebssystem ein.

Warum nur Nicht-Safari-Browser in der macOS 27 Beta ausfallen

Die mit Abstand nützlichste diagnostische Tatsache, die Sie haben, ist die Aufspaltung zwischen Safari und Chromium. Wenn Sie verstehen, warum sich die beiden unterschiedlich verhalten, weist das direkt auf die passenden Fixes hin – gehen wir also den Mechanismus durch, mit dem Vorbehalt, dass es sich um eine fundierte Schlussfolgerung aus Community-Berichten handelt und nicht um eine durch Reverse-Engineering gesicherte Gewissheit.

Safari und Chromium nutzen unterschiedliche Netzwerkpfade

Safari basiert auf WebKit und ist eng in macOS eingewoben. Es stützt sich auf den nativen Netzwerk-Stack des Systems (NSURLSession, den System-Resolver, den System-Vertrauensspeicher) auf die Weise, die Apples eigene Frameworks erwarten, und erbt Annehmlichkeiten auf Systemebene – iCloud Private Relay, App-spezifische Netzwerkrichtlinien, den DNS-Resolver des Betriebssystems – als vollwertiger Bestandteil.

Chromium-Browser (Chrome, Brave, Edge, Arc und Vivaldi teilen sich alle die Chromium-Engine) erledigen einen Großteil dieser Arbeit selbst. Chromium bringt einen eigenen Netzwerkdienst mit, häufig einen eigenen DNS-over-HTTPS-Resolver, ein eigenes Connection-Pooling und eigene Vorstellungen davon, wie Sockets geöffnet werden. Diese Unabhängigkeit ist normalerweise eine Stärke. Bei einer Beta, in der Apple möglicherweise ändert, wie App-spezifisches Networking, DNS oder die Filterung durch Netzwerk-Erweiterungen funktioniert, wird sie zum Nachteil: Chromiums Annahmen und das neue Verhalten der Beta können auf eine Weise auseinanderlaufen, die Safari nie begegnet, weil Safari es standardmäßig auf Apples Art macht.

Der Blickwinkel Netzwerk-Erweiterung und DNS (die vorsichtige Version)

Modernes macOS leitet den App-Datenverkehr über ein Network-Extension-Framework. Inhaltsfilter, VPN-Clients, DNS-Proxys und Firewalls registrieren sich allesamt als System-Netzwerk-Erweiterungen und können den Datenverkehr pro App überprüfen, umleiten oder blockieren. Wenn Beta-Tester berichten, dass Safari funktioniert und jeder Chromium-Browser hängen bleibt, siedeln sich die beiden führenden Community-Theorien in diesem Bereich an:

1. Die DNS-Auflösung schlägt speziell für die Chromium-Apps fehl. Wenn Chrome und Brave ihr eigenes sicheres DNS (DNS-over-HTTPS) verwenden, während die Beta bei der DNS-Handhabung etwas Neues tut, können Namensauflösungen endlos hängen bleiben – genau das, wonach ein endloses Verbindung wird hergestellt… aussieht. Safari, das den System-Resolver nutzt, umgeht dieses Problem. Fehler wie ERR_NAME_NOT_RESOLVED passen genau zu dieser Theorie.
2. Ein Netzwerk-Erweiterungsfilter verwirft stillschweigend den Datenverkehr von Nicht-Safari-Apps. Tools, die sich als Netzwerk-Erweiterungen installieren – Little Snitch, LuLu, Unternehmens-Inhaltsfilter und manche Antivirensuiten – entscheiden pro App über die Konnektivität. Wenn die Beta geändert hat, wie Erweiterungen bewertet oder genehmigt werden, kann ein Filter am Ende Safari durchlassen, während er Chromium-Apps ins Leere laufen lässt. Das ist dieselbe Familie von Beta-Reibung, die wir bereits im Zusammenhang mit Netzwerk-Erweiterungs-Inhaltsfiltern in dem Fix für das Netzwerk-Erweiterungs-Herunterfahren bei macOS Tahoe 26.5.1 dokumentiert haben – anderes Symptom, dasselbe angespannte Subsystem.

Beide passen zu den Berichten, und ehrlich gesagt ist es wahrscheinlich keine einzige universelle Ursache – unterschiedliche Tester haben vermutlich unterschiedliche Auslöser, die auf demselben Fundament „Chromium geht seinen eigenen Netzwerkpfad" aufbauen. Das ist eine gute Nachricht für die Behebung: Sie müssen nicht wissen, welche davon bei Ihnen zutrifft. Sie arbeiten die Leiter einfach Schritt für Schritt durch, und meist fängt eine der Sprossen das Problem ab.

Die genaue Fehlermeldung entschlüsseln

Die Fehlermeldung, die Chrome Ihnen anzeigt, grenzt die Ursache erheblich ein – lesen Sie sie also, bevor Sie wild draufloslicken. Hier ein paar häufige Meldungen und was sie auf dieser Beta üblicherweise bedeuten:

• ERR_NAME_NOT_RESOLVED – ein reiner DNS-Fehler. Der Browser konnte die Domain überhaupt nicht in eine IP-Adresse umwandeln. Das deutet stark auf Fix 1 (sicheres DNS aus) und Fix 4 (Cache leeren) hin. Es ist das häufigste Erkennungszeichen des Beta-Musters.
• ERR_CONNECTION_TIMED_OUT – der Name wurde aufgelöst, aber die Verbindung selbst kam nie zustande. Das deutet eher auf einen Netzwerk-Erweiterungsfilter (Fix 2), ein IPv6-Wettrennen (Fix 3) oder ein halbtotes VPN (Fix 5) hin, das den Datenverkehr stillschweigend verschluckt.
• ERR_CONNECTION_REFUSED / ERR_CONNECTION_RESET – etwas hat die Verbindung aktiv geschlossen. Auf einem Mac mit Inhaltsfilter- oder Firewall-Erweiterung ist das Ihr Filter mitten im Urteil – gehen Sie direkt zu Fix 2.
• ERR_PROXY_CONNECTION_FAILED – ein Proxy ist konfiguriert (oft durch ein zurückgebliebenes Konfigurationsprofil oder eine VPN-App) und ist tot. Siehe die Profilprüfung in Fix 5.
• Ein Tab, der sich endlos dreht, ohne Fehlermeldung – meist eine DNS-Abfrage, die hängt, statt komplett zu scheitern, was wiederum zu Fix 1 und 4 führt.

Keine dieser Meldungen ist auf einer Beta absolut eindeutig, aber sie verraten Ihnen, welche Sprosse Sie zuerst ausprobieren sollten, statt sich durch alle durchzuarbeiten.

Was eine „Network Extension" eigentlich ist, einfach erklärt

Falls Ihnen der Begriff Network Extension nichts sagt, hier die Kurzversion – es ist wichtig, weil sich die Hälfte der folgenden Fixes darum dreht. Vor Jahren erledigten Apps, die Ihren Datenverkehr überprüfen oder filtern mussten (VPNs, Firewalls, Kindersicherungen, Antiviren-Webschutz), das mit Kernel-Erweiterungen, die mit weitreichenden Systemrechten liefen. Apple hat über mehrere Releases hinweg all das aus dem Kernel heraus in ein sandboxed Framework auf Nutzerebene namens Network Extensions verschoben. Wenn Sie heute Little Snitch, einen Unternehmensfilter oder ein VPN installieren, registriert sich eine System-Netzwerk-Erweiterung, durch die macOS Ihren Datenverkehr leitet, damit das Tool Verbindungen erlauben, blockieren oder umleiten kann – oft auf App-Basis.

Diese App-spezifische Fähigkeit ist der Knackpunkt. Eine Network Extension kann Safari und Chrome grundsätzlich unterschiedlich behandeln, und sie ist darauf angewiesen, dass das Betriebssystem ihr mitteilt, wie Verbindungen strukturiert sind. Wenn eine Beta die zugrunde liegende Verkabelung ändert – wie Erweiterungen genehmigt werden, wie App-spezifischer Datenverkehr markiert wird, wie die Erweiterung jede Verbindung übergeben bekommt –, kann eine Erweiterung, die für Safari einwandfrei funktioniert, am Ende Chromium-Datenverkehr verwerfen oder ins Stocken bringen, ohne dass das jemand beabsichtigt hat. Deshalb ist „Netzwerk-Erweiterung deaktivieren und erneut testen" hier ein so tragender Schritt, und deshalb ist es wichtig, Erweiterungen nach jedem Beta-Update erneut zu genehmigen.

Warum das eindeutig nach „Beta" schreit, nicht nach „Ihr Browser ist kaputt"

Wäre Chrome selbst kaputt, würde eine Neuinstallation das Problem beheben, und Brave/Edge/Arc/Vivaldi würden nicht alle im Gleichschritt ausfallen. Wäre Ihr Netzwerk kaputt, würde auch Safari ausfallen. Das Einzige, was sauber erklärt, dass „jeder Chromium-Browser tot ist, WebKit einwandfrei funktioniert, derselbe Rechner, dasselbe WLAN", ist etwas auf der Ebene des Betriebssystems und Netzwerks, das diese beiden App-Klassen unterschiedlich behandelt – genau die Art von Sache, bei der ein Vorabversion-Betriebssystem Fehler macht. Es lohnt sich, den Überblick über bekannte Probleme der Golden-Gate-Beta zu lesen, um einzuordnen, wie viele Unebenheiten in diesem Build stecken.

Eine 60-Sekunden-Checkliste zur Diagnose

Bevor Sie die komplette Leiter durcharbeiten, führen Sie diese fünf schnellen Prüfungen durch. Sie kosten fast nichts und weisen häufig direkt auf den entscheidenden Fix hin.

1. Lädt Safari eine Website? Falls ja, bestätigt: Das ist das Chromium-spezifische Muster, und die untenstehende Leiter gilt für Sie. Falls Safari ebenfalls versagt, ist das nicht der Beta-Browser-Fehler, sondern ein allgemeines Konnektivitätsproblem; gehen Sie zum Leitfaden zu WLAN-Abbrüchen.
2. Läuft ein VPN oder Inhaltsfilter? Schauen Sie in der Menüleiste und unter Systemeinstellungen > Allgemein > Anmeldeobjekte & Erweiterungen > Network Extensions nach. Wenn dort etwas eingetragen ist, ist das Verdächtiger Nummer eins.
3. Ist iCloud Private Relay aktiviert? Systemeinstellungen > [Ihr Name] > iCloud > Private Relay. Notieren Sie, ob es aktiviert ist.
4. Funktionieren IP-Adressen, wenn Domainnamen nicht funktionieren? Versuchen Sie in Chrome, http://1.1.1.1 zu laden. Wenn eine reine IP-Adresse lädt, cloudflare.com aber nicht, liegt Ihr Problem bei DNS, und die Fixes 1 und 4 sind Ihr Ziel.
5. Verhält sich ein brandneues Browserprofil genauso? Öffnen Sie in Chrome ein neues Gastfenster. Wenn es ebenfalls fehlschlägt, liegt die Ursache systemweit und nicht an Ihrem Profil – springen Sie direkt zu den Netzwerk-Fixes.

Was auch immer diese fünf Prüfungen ergeben, Sie können trotzdem einfach bei Fix 1 anfangen und der Reihe nach vorgehen. Starten Sie Chrome zwischen den Fixes jeweils vollständig neu (Cmd+Q, nicht nur das Fenster schließen), damit jede Änderung tatsächlich wirksam wird.

Genau feststellen, wo es hakt (optional, aber wirkungsvoll)

Wenn Sie Gewissheit darüber haben möchten, welche Ebene versagt, bevor Sie Einstellungen ändern, verraten Ihnen das fünf sichere Terminal-Befehle. Keiner von ihnen verändert irgendetwas – sie lesen nur den Zustand aus –, sodass Sie alle risikofrei ausführen können. Der Zweck besteht darin, drei Fragen zu trennen: Ist das Netzwerk überhaupt erreichbar? Funktioniert DNS? Funktioniert der HTTP-Pfad auf Systemebene, obwohl der von Chrome nicht funktioniert?

1. Erreichen Sie das Internet über eine reine IP-Adresse? Das umgeht DNS vollständig.

ping -c 4 1.1.1.1

Wenn Sie Antworten erhalten, hat Ihr Mac eine funktionierende Verbindung, und das Problem liegt weiter oben (DNS oder App-spezifisch). Wenn auch dies fehlschlägt, würde auch Safari versagen, und Sie haben es mit einem allgemeinen Konnektivitätsproblem zu tun, nicht mit dem Beta-Browser-Muster.

2. Funktioniert die DNS-Auflösung?

ping -c 4 cloudflare.com

Wenn Schritt 1 funktioniert hat, dieser hier aber kann nicht auflösen meldet oder hängt, haben Sie ein DNS-Problem bestätigt – genau das, worauf die Fixes 1 und 4 abzielen.

3. Fragen Sie den Resolver direkt. dig und nslookup sind beide bei macOS dabei und zeigen Ihnen, was der System-Resolver zurückgibt:

dig cloudflare.com +short
nslookup cloudflare.com

Eine Antwort hier bedeutet, dass der System-Resolver einwandfrei funktioniert und Chromiums eigenes DNS-over-HTTPS das ist, was klemmt – ein starkes Signal, dass Fix 1 (das sichere DNS des Browsers ausschalten, damit er sich auf diesen funktionierenden System-Resolver verlässt) helfen wird.

4. Lädt der HTTP-Stack des Systems eine Seite, obwohl Chrome das nicht schafft? curl nutzt das eigene Networking von macOS, dieselbe Art von Pfad, die auch Safari verwendet:

curl -I https://www.cloudflare.com

Wenn curl Header zurückgibt (HTTP/2 200 und Ähnliches), während Chrome hängt, ist das die komplette Diagnose in einer Zeile: Der Pfad des Betriebssystems funktioniert, der von Chromium nicht. Das ist das bestätigte Beta-Muster, und es bedeutet, dass die untenstehenden systemweiten Fixes Ihre beste Chance sind.

5. Welches DNS verwendet das System tatsächlich?

scutil --dns | grep nameserver
networksetup -getdnsservers "Wi-Fi"

Das zeigt, ob ein VPN, ein Profil oder ein Filter Sie stillschweigend auf DNS-Server umgeleitet hat, die Sie nicht selbst gewählt haben. Wenn Sie unerwartete Adressen sehen, gehen Sie noch einmal die Profil- und VPN-Prüfungen aus Fix 5 durch.

Führen Sie diese fünf Befehle aus, und Sie wissen, bevor Sie eine Einstellung anfassen, ob Sie einem DNS-Problem, einem Filter oder einem App-spezifischen Pfadproblem nachjagen. Wenn Terminal nichts für Sie ist, überspringen Sie diesen Abschnitt komplett – die Fix-Leiter funktioniert auch ohne ihn einwandfrei.

Die Fix-Leiter

Arbeiten Sie von oben nach unten. Testen Sie nach jedem Schritt erneut; hören Sie auf, sobald Ihre Websites wieder funktionieren. Jeder Schritt hier ist reversibel.

Fix 1: Sicheres DNS / DNS-over-HTTPS im Browser deaktivieren

Das ist mit Abstand der ertragreichste Fix für dieses Beta-Muster, denn Chromiums integriertes verschlüsseltes DNS ist genau die Art von selbstverwaltetem Networking, die mit einem Beta-Betriebssystem aus dem Takt geraten kann. Sie weisen den Browser an, Namen nicht mehr selbst aufzulösen, sondern sich auf das System zu verlassen.

In Chrome, Brave, Edge und Vivaldi:

1. Öffnen Sie Einstellungen > Datenschutz und Sicherheit > Sicherheit.
2. Scrollen Sie zu Sicheres DNS verwenden und schalten Sie es komplett aus. (Wechseln Sie nicht nur den Anbieter – schalten Sie es aus, damit der Browser den Resolver des Betriebssystems nutzt.)
3. Beenden Sie den Browser vollständig (Cmd+Q) und öffnen Sie ihn erneut.

In Arc: Öffnen Sie Arc > Settings, suchen Sie den Datenschutz-/Sicherheitsbereich und deaktivieren Sie sicheres DNS auf dieselbe Weise; Arc zeigt Chromiums Einstellung unter eigenen Menüs an.

Wenn in Ihrer Diagnoseprüfung eine reine IP-Adresse geladen hat, Domains aber nicht, behebt allein dieser Schritt das Problem sehr häufig.

Fix 2: Netzwerkfilter-, VPN- und Inhaltsfilter-Erweiterungen deaktivieren oder entfernen

Wenn Sie Little Snitch, LuLu, einen Unternehmens-Inhaltsfilter, eine DNS-Filter-App oder eine Antivirensuite mit Webschutz nutzen, hat sich diese fast sicher als System-Netzwerk-Erweiterung installiert – und das ist der Hauptverdächtige dafür, dass unter dieser Beta Safari durchgelassen und Chromium blockiert wird.

1. Gehen Sie zu Systemeinstellungen > Allgemein > Anmeldeobjekte & Erweiterungen und klicken Sie dann auf das (i) neben Network Extensions (älterer Pfad: Network Extensions oder Inhalt & Datenschutz, je nach Build).
2. Schalten Sie jede Drittanbieter-Netzwerkfilter-/VPN-/Firewall-Erweiterung nacheinander aus.
3. Beenden Sie Chrome nach jedem Umschalten vollständig, öffnen Sie es erneut und testen Sie erneut.

Wenn das Deaktivieren einer Erweiterung Chrome wieder zum Laufen bringt, haben Sie Ihren Übeltäter gefunden. Von dort aus können Sie sie ausgeschaltet lassen, bis Apple einen fehlerbereinigten Build liefert, das Tool auf die neueste Version aktualisieren (Hersteller patchen bei Betas schnell) oder die Hinweise des Herstellers zur Beta-Kompatibilität prüfen. Wenn Sie einen verwalteten/dienstlichen Mac nutzen, können Sie einen Unternehmensfilter möglicherweise nicht selbst deaktivieren – das ist ein Fall für Ihr IT-Team, und ein legitimer Grund, mit der Beta noch zu warten. Unser Beitrag zu Netzwerk-Erweiterungs-Inhaltsfiltern geht ausführlicher darauf ein, wie sich diese Erweiterungen verhalten, wenn sich das Betriebssystem darunter verändert.

Fix 3: IPv6 für den aktiven Netzwerkdienst auf „Nur lokale Verbindung" setzen

Mehrere Tester berichten, dass das Dual-Stack-Verbindungswettrennen (IPv4 + IPv6) von Chromium unter der Beta hängen bleibt, wenn IPv6 sich nicht richtig verhält, während Safari das toleriert. Wenn Sie den Netzwerkdienst zwingen, vollständiges IPv6 abzuschalten, wird der Datenverkehr auf den funktionierenden IPv4-Pfad gedrängt.

Über die Systemeinstellungen (empfohlen, schonend):

1. Systemeinstellungen > Netzwerk, wählen Sie Ihren aktiven Dienst (Wi-Fi oder Ethernet) aus und klicken Sie auf Details….
2. Gehen Sie zum Tab TCP/IP.
3. Setzen Sie IPv6 konfigurieren auf Nur lokale Verbindung.
4. Klicken Sie auf OK, beenden Sie Chrome dann vollständig und öffnen Sie es erneut.

Über das Terminal (gleichwertig, falls Sie die Kommandozeile bevorzugen): Listen Sie zunächst Ihre Dienstnamen auf und schalten Sie dann IPv6 für den von Ihnen genutzten Dienst aus. Beachten Sie, dass -setv6off IPv6 vollständiger deaktiviert als „Nur lokale Verbindung" in der grafischen Oberfläche, aber zum Eingrenzen dieses Problems funktionieren beide Varianten.

# See the exact network service names
networksetup -listallnetworkservices

# Turn IPv6 off for Wi-Fi (use your exact service name)
sudo networksetup -setv6off "Wi-Fi"

Um IPv6 später wieder auf normal zu setzen:

sudo networksetup -setv6automatic "Wi-Fi"

Fix 4: Den DNS-Cache leeren

Wenn DNS das Problem ist (und auf dieser Beta ist es das oft), kann ein veralteter oder beschädigter Resolver-Cache fehlschlagende Abfragen selbst dann noch festhalten, nachdem Sie eine Einstellung geändert haben. Leeren Sie ihn. Das ist ein gängiges, sicheres macOS-Befehlspaar – es leert den Cache und startet den Multicast-DNS-Responder neu:

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

Sie werden nach Ihrem Administratorpasswort gefragt. Bei Erfolg gibt es keine sichtbare Ausgabe – das ist normal. Beenden Sie Chrome danach, öffnen Sie es erneut und probieren Sie eine Website. Kombinieren Sie das mit Fix 1 (sicheres DNS aus) für die besten Erfolgschancen; die beiden zusammen beheben den für diese Beta am häufigsten gemeldeten DNS-Fehlermodus.

Fix 5: Private Relay, VPN und Konfigurationsprofile prüfen

iCloud Private Relay und VPNs verändern beide, wie der Datenverkehr Ihren Mac verlässt, und beide werden bei Safari anders behandelt als bei Chromium-Apps – was sie zu klassischen Verdächtigen für asymmetrisches Versagen macht.

• iCloud Private Relay: Systemeinstellungen > [Ihr Name] > iCloud > Private Relay. Schalten Sie es vorübergehend aus und testen Sie Chrome erneut. Private Relay leitet nur Safari und einen Teil des Systemverkehrs, aber das Umschalten kann einen Netzwerkzustand zurücksetzen, in dem Chromium hängengeblieben ist.
• VPN: Falls ein VPN verbunden ist, trennen Sie es vollständig (minimieren Sie nicht nur die App) und testen Sie erneut. Halb verbundene oder beta-inkompatible Tunnel sind eine sehr häufige Ursache dafür, dass der „Browser endlos hängt". Falls sich das VPN als Ihr Problem herausstellt, arbeiten Sie unseren macOS-VPN-Fehlerbehebungsleitfaden durch – die meisten VPN-Clients benötigen ein beta-taugliches Update.
• Konfigurationsprofile: Entfernen Sie unter Systemeinstellungen > Allgemein > Geräteverwaltung (oder Datenschutz & Sicherheit > Profile) jedes alte DNS- oder Proxy-Profil, das Sie nicht erkennen oder nicht benötigen. Zurückgebliebene Profile können fehlerhafte DNS-Server festhalten.

Fix 6: Der FaceTime-/„Anrufe auf anderen Geräten erlauben"-Schalter, auf den manche Tester schwören

Dieser hier ist merkwürdig, unbestätigt und dennoch dreißig Sekunden wert, denn eine ganze Reihe von Forumsposts berichtet, dass er ihre Chromium-Browser wieder zum Leben erweckt hat. Die Theorie besagt, dass das Umschalten dieser Continuity-Funktion den Netzwerk-Stack dazu anstößt, die App-spezifischen Pfade neu zu initialisieren, die die Beta in einem schlechten Zustand zurückgelassen hat.

1. Öffnen Sie FaceTime > Settings (Menüleiste: FaceTime > Settings).
2. Suchen Sie Calls From iPhone / Allow Calls on Other Devices und schalten Sie es aus und wieder ein.
3. Alternativ auf dem iPhone: Einstellungen > Telefon > Anrufe auf anderen Geräten, schalten Sie Ihren Mac aus und wieder ein.
4. Testen Sie Chrome erneut.

Betrachten Sie das als Folklore, die bei manchen Leuten zufällig funktioniert, nicht als garantierten Fix. Er kostet nichts und lässt sich sofort rückgängig machen, weshalb er sich seine Sprosse auf der Leiter verdient.

Fix 7: Die Netzwerkeinstellungen des Browsers zurücksetzen oder ein neues Profil starten

Wenn die systemweiten Fixes nicht geholfen haben, grenzen Sie ein, ob Ihr spezifisches Browserprofil einen beschädigten Netzwerkzustand festhält.

• Chrome/Brave/Edge: Öffnen Sie Einstellungen > Einstellungen zurücksetzen > Einstellungen auf ihre ursprünglichen Standardwerte zurücksetzen. Das löscht benutzerdefinierte DNS-, Proxy- und Start-Anpassungen, ohne Ihre Lesezeichen oder Passwörter anzurühren.
• Test mit neuem Profil: Erstellen Sie ein neues Profil (Profilsymbol > Hinzufügen) oder öffnen Sie ein Gastfenster und probieren Sie eine Website. Wenn das neue Profil funktioniert, lag das Problem am Profil selbst – setzen Sie das alte zurück oder wechseln Sie zum neuen.
• Socket-/Host-Cache leeren: Rufen Sie in Chrome chrome://net-internals/#sockets auf und klicken Sie auf Flush socket pools, dann chrome://net-internals/#dns und Clear host cache. (Brave und Edge bieten dieselben Seiten unter ihrem eigenen Schema an, z. B. brave://net-internals.)

Fix 8: Den Browser sauber neu installieren

Wenn nach den Netzwerk-Fixes nur ein bestimmter Browser übrig bleibt, der nicht funktioniert, installieren Sie ihn neu. Da sich Chrome, Brave, Edge, Arc und Vivaldi alle dieselbe Engine teilen, tun Sie das nur, wenn ein einzelner Browser den anderen hinterherhinkt – eine systemweite Ursache lässt sich durch Neuinstallation nicht beheben.

1. Beenden Sie den Browser (Cmd+Q).
2. Ziehen Sie ihn aus Programme in den Papierkorb.
3. Laden Sie den neuesten Build direkt vom Hersteller herunter – Beta-Kompatibilitätsfixes landen laufend in Browser-Updates, sodass ein aktueller Build die Beta möglicherweise bereits besser handhabt.
4. Installieren Sie neu und testen Sie erneut. Ihre synchronisierten Daten (Lesezeichen, Passwörter) kehren zurück, sobald Sie sich wieder anmelden.

Fix 9 (der Rückfallplan für die Beta-Realität): Safari nutzen oder zu Tahoe zurückkehren

Hier kommt der ehrliche Teil. Dies ist eine Beta, der Browser-Ausfall ist von Beta-Testern gemeldet und nicht von Apple bestätigt, und manche Tester haben festgestellt, dass nichts aus der obigen Leiter dauerhaft hilft, bis Apple einen neuen Build liefert. Wenn Sie die Leiter komplett durchgearbeitet haben und Chromium immer noch tot ist, haben Sie zwei vernünftige Optionen:

• Setzen Sie vorerst auf Safari. Es funktioniert, ist schnell und importiert Ihre Lesezeichen. Ihr tägliches Surfen für ein paar Wochen in Safari zu erledigen, während die Beta reift, ist eine völlig vernünftige Übergangslösung, und Sie können Chrome nach jedem neuen Seed weiter testen (das Verhalten ändert sich tatsächlich von Build zu Build).
• Kehren Sie zum stabilen Tahoe zurück. Wenn ein funktionierender Chromium-Browser unverzichtbar ist – für die Arbeit, für Erweiterungen, für einen Workflow, den Sie nicht verlagern können –, ist der sauberste Fix, die Beta zu verlassen. Folgen Sie unserem Schritt-für-Schritt-Leitfaden zum Downgrade der macOS 27 Beta zurück auf Tahoe ohne Datenverlust. Und wenn Sie die Beta erst in Erwägung ziehen, ist dieses gesamte Problem ein starkes Argument dafür, sie beim nächsten Mal sicher auf einem separaten Volume zu installieren, damit Ihr Arbeitssystem nie das ist, was ausfällt.

Keine dieser Optionen ist etwas, wofür Sie sich schämen müssten. Eine Beta ist eine Vorschau, die Sie freiwillig testen, keine Verpflichtung, sich durch einen kaputten Browser zu quälen.

Fehlerbehebung bei häufigen Problemen

Problem: Chrome lädt manche Websites, hängt aber bei anderen unter der Beta

Lösung: Teilweises Laden bedeutet fast immer DNS, nicht eine komplette Sperre. Manche Namen werden aus dem Cache aufgelöst, während neue Abfragen hängen bleiben. Führen Sie Fix 1 (sicheres DNS ausschalten) und Fix 4 (DNS-Cache leeren) zusammen durch, beenden Sie Chrome dann vollständig und versuchen Sie es erneut. Wenn das Problem bestehen bleibt, stellen Sie Ihr System-DNS auf einen einfachen Resolver um – Systemeinstellungen > Netzwerk > Details > DNS und fügen Sie 1.1.1.1 und 8.8.8.8 hinzu –, damit sich das Betriebssystem nicht auf einen Resolver verlässt, den die Beta falsch handhabt.

Problem: Alles hat funktioniert, ist dann aber nach einem Beta-Update erneut ausgefallen

Lösung: Rechnen Sie damit. Jeder neue Seed kann Genehmigungen für Netzwerk-Erweiterungen zurücksetzen und Verhaltensweisen umschalten. Genehmigen Sie nach jedem macOS 27 Beta-Update Ihre Netzwerk-Erweiterungen unter Systemeinstellungen > Allgemein > Anmeldeobjekte & Erweiterungen > Network Extensions erneut und führen Sie dann Fix 1 und Fix 4 erneut aus. Da es sich um unbestätigtes Beta-Verhalten handelt, behandeln Sie jeden Build als neue Diagnose, statt anzunehmen, dass Ihr vorheriger Fix weiterhin gilt.

Problem: Ein dienstlicher oder schulischer Mac blockiert die Fixes, die ich brauche

Lösung: Verwaltete Macs erzwingen Unternehmens-Inhaltsfilter und Konfigurationsprofile, die Sie nicht selbst deaktivieren können, und diese Filter sind der Hauptverdächtige für die Aufspaltung „Safari funktioniert / Chromium versagt". Kämpfen Sie nicht gegen das MDM an. Wenden Sie sich an Ihr IT-Team, teilen Sie mit, dass der Browser nur bei Chromium-Apps auf der macOS 27 Beta versagt, und fragen Sie, ob der Filterhersteller einen beta-kompatiblen Build hat. Falls nicht, ist das ein klares Signal, dass ein produktiver/verwalteter Mac noch nicht auf der Beta sein sollte.

Problem: Das Deaktivieren meiner Netzwerk-Erweiterung hat Chrome behoben, aber ich brauche dieses Tool

Lösung: Sie haben den Übeltäter bestätigt – stellen Sie den Schutz nun auf die richtige Weise wieder her. Aktualisieren Sie das Tool (Little Snitch, LuLu, Ihr Antivirenprogramm) auf die neueste Version, da Hersteller schnell Beta-Kompatibilitätspatches ausliefern. Prüfen Sie die Release Notes oder das Forum des Herstellers auf einen Hinweis zu macOS 27. Falls es noch keinen kompatiblen Build gibt, müssen Sie sich auf dieser Beta zwischen dem Tool und Chromium entscheiden – ein echter Grund, eine Rückkehr zu Tahoe in Erwägung zu ziehen, bis der Hersteller nachzieht.

FAQ

Warum funktioniert Safari, aber nicht Chrome und Brave auf der macOS 27 Beta?

Safari nutzt das native Networking und DNS von macOS und erbt daher alles, was die Beta geändert hat. Chromium-Browser verwalten ihr eigenes DNS, ihre eigenen Sockets und ihre eigene Verbindungslogik, was mit der neuen App-spezifischen Netzwerkbehandlung der Beta aus dem Takt geraten kann. Derselbe Rechner, dasselbe WLAN, aber ein anderer Netzwerkpfad – deshalb funktioniert der eine und die anderen hängen.

Ist das ein offizieller Apple-Fehler, für den ein Fix kommt?

Nicht offiziell. Das Problem wird von Beta-Testern in der Brave Community, bei Apple Discussions und auf MacRumors gemeldet und von der Presse aufgegriffen, aber Apple hat keine offizielle Bestätigung veröffentlicht. Da es sich um einen Vorabversion-Build handelt, kann sich das Verhalten mit jedem neuen Seed ändern, testen Sie also nach jedem macOS 27 Beta-Update erneut.

Macht das Ausschalten von sicherem DNS mein Surfen weniger privat?

Ein wenig, und nur vorübergehend. Das Deaktivieren des DNS-over-HTTPS des Browsers bedeutet, dass Namensauflösungen Ihren System-Resolver statt eines verschlüsselten nutzen. Für einen Workaround auf einer Beta ist das ein guter Kompromiss, und Sie können sicheres DNS wieder aktivieren, sobald Apple einen Build liefert, der gut mit Chromium zusammenspielt. Ihr HTTPS-Seitenverkehr bleibt so oder so verschlüsselt.

Ich bin auf macOS 26.5.2, nicht auf der Beta. Gelten diese Fixes trotzdem?

Wahrscheinlich nicht. Ein kompletter Chromium-Ausfall ist das Beta-Muster. Auf dem stabilen Tahoe 26.5.2 (Build 25F84) ist es wahrscheinlicher, dass ein Browser, der keine Websites lädt, an gewöhnlicher Konnektivität, einem VPN oder einem Filter liegt. Beginnen Sie mit den oben verlinkten WLAN- und VPN-Leitfäden statt mit den hier beschriebenen beta-spezifischen Schritten.

Könnte eine Neuinstallation von Chrome das Problem von allein beheben?

Bei diesem Problem selten. Wenn Brave, Edge, Arc und Vivaldi zusammen mit Chrome allesamt versagen, liegt die Ursache auf Systemebene, und die Neuinstallation eines einzigen Browsers hilft nicht. Installieren Sie nur dann neu, wenn ein einzelner Chromium-Browser den anderen hinterherhinkt – und holen Sie sich immer den neuesten Build, da Browser-Updates häufig Beta-Kompatibilität hinzufügen.

Sollte ich deswegen einfach zu Tahoe zurückkehren?

Wenn ein funktionierender Chromium-Browser für Ihren Alltag unverzichtbar ist und die Fix-Leiter nicht geholfen hat, ja – das ist eine vernünftige Entscheidung. Folgen Sie dem oben verlinkten Downgrade-Leitfaden, um ohne Datenverlust zurückzukehren. Wenn Sie ein paar Wochen mit Safari leben können, ist es der Weg mit weniger Aufwand, auf der Beta zu bleiben und jeden neuen Seed erneut zu testen.

Fazit

Wenn Chrome auf der macOS 27 Beta keine Websites lädt, Safari aber einwandfrei funktioniert, haben Sie es nicht mit einem kaputten Mac oder einem kaputten Browser zu tun – Sie haben es mit einem Vorabversion-Betriebssystem zu tun, das Chromiums unabhängigen Netzwerkpfad anders behandelt als WebKit. Genau diese Erkenntnis erklärt, warum die Fixes meist schnelle Schalter sind: das sichere DNS des Browsers ausschalten, eine Netzwerkfilter-Erweiterung deaktivieren, IPv6 auf „Nur lokale Verbindung" setzen, den DNS-Cache leeren und Private Relay sowie VPN prüfen. Eine dieser Sprossen fängt das Problem bei den meisten Testern ab, und jede einzelne lässt sich in Sekunden rückgängig machen.

Behalten Sie aber den ehrlichen Rahmen im Blick: Dies ist von Beta-Testern gemeldetes Verhalten, kein von Apple bestätigter Fehler, und bei einer Beta ist der letztendliche Fix manchmal Geduld. Das Verhalten verschiebt sich von Build zu Build, testen Sie also nach jedem neuen Seed erneut – und wenn Sie auf einen funktionierenden Chromium-Browser nicht verzichten können, müssen Sie sich nicht schämen, auf Safari zu setzen oder zum stabilen Tahoe zurückzukehren, bis Apple das Problem behoben hat. Sie haben sich freiwillig gemeldet, um eine Vorschau zu testen; einen kaputten Browser als „warten auf den nächsten Build" zu behandeln, ist genau der richtige Instinkt.

Eine letzte praktische Gewohnheit: Behalten Sie den Beta-Rhythmus im Auge. Apple hat ungefähr alle ein bis zwei Wochen einen neuen Seed veröffentlicht – Public Beta 1 erschien am 13. Juli, Public Beta 2 am 22. Juli, mit Entwickler-Beta 4 (Build 26A5388g) am 20. Juli – und das Netzwerkverhalten hat sich zwischen den Seeds tatsächlich verändert. Die kluge Routine besteht deshalb darin, Ihren funktionierenden Fix beizubehalten, sich zu notieren, welche Sprosse das Problem gelöst hat, und nach jedem neuen Build diesen Workaround kurz zu deaktivieren und Chrome erneut zu testen. Wenn ein Seed das zugrunde liegende Problem stillschweigend behebt, sollten Sie sicheres DNS und IPv6 wieder auf ihre normalen Einstellungen zurücksetzen, statt sie für immer geändert zu lassen. Betas verändern sich; Ihre Workarounds sollten das nicht dauerhaft tun.

Arbeiten Sie die Leiter von oben nach unten durch, hören Sie bei der ersten Sprosse auf, die Ihre Websites zurückbringt, und wenn Sie überlegen, ob Sie überhaupt auf Golden Gate bleiben sollten, helfen Ihnen der Leitfaden zu bekannten Problemen und die Anleitung zur sicheren Installation, das mit klarem Blick zu entscheiden.