Kurzantwort
Nach dem Update auf iOS 27 zeigt dein iPhone womöglich wieder Werbung, obwohl in deinem Netz ein Pi-hole oder AdGuard Home DNS-Anfragen filtert. Die wahrscheinlichste Ursache ist eine neue Funktion namens Connectivity Assist. Sie nutzt Mobilfunkdaten zusätzlich zum WLAN und fragt damit auch die DNS-Server deines Mobilfunkanbieters ab, parallel zum DNS-Server deines Routers. Ein Teil deiner DNS-Anfragen landet dann nie bei deinem Pi-hole: blockierte Domains lösen auf, Werbung erscheint, und im Query-Log fehlt die Anfrage 3.
Die Lösung ist ein Schalter: Einstellungen > WLAN > Connectivity Assist ausschalten. Daneben existiert pro Netzwerk ein zweiter Schalter, der unabhängig davon greift 1, 3. Anschließend prüfst du mit dnscheck.tools, ob dein Gerät noch Carrier-DNS nutzt 3. Wer danach weiterhin Werbung sieht, sollte zusätzlich Limit IP Address Tracking – die netzbezogene Einstellung für iCloud Private Relay – für sein Heimnetz ausschalten 2.
Worum es konkret geht
Die Leseraufgabe ist konkret: Du betreibst einen lokalen DNS-Filter und möchtest, dass er wieder greift, ohne dass einzelne Anfragen am Filter vorbei ins Mobilfunknetz laufen. Dafür musst du zwei Dinge trennen, die in Forenbeiträgen oft vermischt werden.
Zum einen gibt es Connectivity Assist, die in iOS 27 neu eingeführte Funktion. Sie ist der Grund, warum nach dem Update plötzlich Werbung durchkommt, obwohl sich an deinem Pi-hole nichts geändert hat. Zum anderen gibt es Limit IP Address Tracking, eine deutlich ältere Einstellung, die an das iCloud Private Relay gekoppelt ist und Anfragen über Apple-Server umleitet, statt sie an deinen Router zu schicken 2.
Beide Funktionen bewirken auf unterschiedlichem Weg dasselbe: DNS-Anfragen erreichen deinen lokalen Filter nicht. Deshalb reicht es nicht immer, nur einen Schalter zu finden. Der folgende Leitfaden führt beide Prüfungen durch und gibt dir eine Verifikation an die Hand, mit der du sicherstellst, dass dein Gerät wieder ausschließlich den von dir gewählten Resolver nutzt.
Was Connectivity Assist ist
Apple beschreibt die Funktion in einem Support-Dokument vom 14. September 2026 so: Connectivity Assist nutze Mobilfunkdaten “in addition to Wi-Fi” – also zusätzlich zum WLAN – “for a more reliable internet connection”, für eine zuverlässigere Internetverbindung 1. Die Funktion erscheint in den WLAN-Einstellungen und ersetzt das frühere Wi-Fi Assist, das zuvor unter Mobile Daten zu finden war 1, 4.
Der entscheidende Unterschied zum Vorgänger liegt im Verhalten. Wi-Fi Assist schaltete erst dann auf Mobilfunk um, wenn das WLAN schwach oder unbrauchbar wurde. Connectivity Assist dagegen nutzt Mobilfunk parallel zum WLAN: Dein iPhone spricht während der WLAN-Verbindung gleichzeitig mit den DNS-Servern deines Mobilfunkanbieters und mit dem DNS-Server, den dein Router per DHCP verteilt 3.
Apple nennt dafür Alltagsszenarien: Stellen im eigenen Garten oder in der Einfahrt, Cafés, Flughäfen oder Stadien, wo WLAN langsam oder unbrauchbar ist 1. Die Funktion soll verhindern, dass eine Seite oder ein Anruf abbricht, sobald die WLAN-Abdeckung schwankt. Für ein Heimnetz mit eigenem DNS-Filter hat genau dieses Parallelverhalten jedoch eine Nebenwirkung, die Apple im selben Dokument selbst einräumt.
Vom Wi-Fi Assist zum parallelen Mobilfunk
Die Umbenennung spiegelt eine Verhaltensänderung wider. Wi-Fi Assist gibt es seit vielen Jahren; es schaltete das Gerät auf Mobilfunk um, wenn die WLAN-Verbindung schwach war, und lag entsprechend unter Mobile Daten 4.
In iOS 27 wurde die Funktion zu Connectivity Assist umbenannt und in die WLAN-Einstellungen verschoben 4. Während der Beta berichtete MacRumors im Juni 2026 noch, es sei unklar, ob sich über den Namen hinaus etwas geändert habe; einige Beta-Tester vermuteten bereits, dass die Funktion WLAN und Mobilfunk kombinieren könnte 4. Apple spricht im Rahmen von iOS 27 außerdem von weicheren Netzübergängen: Das Gerät wählt selbstständig die jeweils beste WLAN- oder Mobilfunkverbindung 4.
Auf der finalen Version ist das kombinierte Verhalten bestätigt. Der Unterschied ist für den Pi-hole-Fall entscheidend: Ein reiner Fallback, der nur bei schwachem WLAN greift, würde deinen Filter in einem stabilen Heimnetz kaum berühren. Das parallele Nutzen von Mobilfunk tut es, weil dabei dauerhaft ein zweiter DNS-Weg offensteht.
Warum der Pi-hole-Filter dadurch leerläuft
Apple schreibt in dem Support-Dokument, man könne Connectivity Assist für ein einzelnes Netzwerk ausschalten, wenn man “always stay on Wi-Fi” bleiben wolle – etwa “for your ad blocker”, also für deinen Werbeblocker 1. Apple benennt den Anwendungsfall damit selbst. Der Mechanismus dahinter ist in einem GitHub-Thread des DNS-Blocklisten-Maintainers hagezi dokumentiert, der das Verhalten auf der finalen Version iOS 27.0 getestet hat 3.
Konkret passiert Folgendes: Mit aktivem Connectivity Assist sendet das iPhone einen Teil seiner DNS-Anfragen über Mobilfunk direkt an den DNS-Server des Mobilfunkanbieters, statt an den Router. Die Anfragen, die über Mobilfunk laufen, erreichen deinen lokalen Resolver nie. Blockierte Domains werden deshalb beim Carrier aufgelöst, Werbung erscheint wieder, und in deinem Pi-hole-Query-Log findest du zu diesen Anfragen nichts, weil sie dort gar nicht angekommen sind 3.
Das ist kein Fehler in deiner Pi-hole-Konfiguration und auch keine Blockliste, die versagt. hagezi stellt das ausdrücklich fest: Blocklisten können das Problem nicht lösen 3. Es ist ein Routing-Verhalten des Betriebssystems, das deinen Filter umgeht, ohne ihn zu berühren.
Der zweite Schalter: Limit IP Address Tracking
Neben Connectivity Assist gibt es eine zweite, ältere Einstellung, die denselben Effekt haben kann: Limit IP Address Tracking. Sie ist die netzbezogene Schaltfläche für iCloud Private Relay 2.
Private Relay leitet den Web-Traffic über getrennte Apple-Relays und verbirgt dadurch die IP-Adresse des Geräts gegenüber Websites. Für einen lokalen DNS-Filter hat das dieselbe Konsequenz wie Connectivity Assist, nur über einen anderen Weg: Die DNS-Anfragen laufen verschlüsselt über Apples Infrastruktur, nicht über den DNS-Server deines Routers. Dein Pi-hole sieht sie ebenfalls nicht.
Apple führt in seiner Dokumentation zu Private Relay ausdrücklich Netze auf, die “network-based filtering” – netzbasierte Filterung – durchführen, etwa Firmen- oder Bildungsnetze, und für die Private Relay deshalb angepasst oder deaktiviert werden muss 2. Ein Pi-hole oder AdGuard Home ist genau so ein netzbasierter Filter. Wenn Limit IP Address Tracking für dein Heimnetz aktiv ist, umgeht es deinen Filter, ohne dass Connectivity Assist überhaupt beteiligt ist.
Wichtig ist die Trennung der beiden Ursachen, weil sie getrennte Schalter haben. Ein Bericht auf Reddit, der den Anstoß zu diesem Thema gab, beschreibt, dass nach dem Update beide Funktionen für das Heimnetz aktiv waren. Unabhängig davon, ob bei dir beide, eine oder keine aktiv ist, lohnt sich die Prüfung beider Stellen, weil jede für sich den Filter aushebeln kann.
Schritt für Schritt: Connectivity Assist ausschalten
Es gibt zwei Schalter für Connectivity Assist, und beide beenden das DNS-Umgehen. Nach den Tests von hagezi tritt das Leck nur auf, wenn beide aktiv sind; ein Schalter auf “aus” genügt 3. Empfohlen wird, den globalen Schalter auszuschalten.
Der globale Schalter:
- Öffne die App Einstellungen.
- Tippe auf WLAN und stelle sicher, dass WLAN eingeschaltet ist.
- Scrolle nach unten und schalte Connectivity Assist aus 1.
Der netzbezogene Schalter:
- Öffne Einstellungen > WLAN.
- Tippe auf das Info-Symbol neben deinem Heimnetz.
- Suche den Eintrag Use Connectivity Assist und schalte ihn für dieses Netzwerk aus 3.
Apple beschreibt denselben netzbezogenen Weg mit dem Hinweis auf den Werbeblocker: Wenn du für eine bestimmte Router-Konfiguration – etwa deinen Werbeblocker – immer im WLAN bleiben willst, schalte Connectivity Assist für genau dieses Netzwerk aus 1. Wer nur zu Hause einen DNS-Filter betreibt und unterwegs die Ausfallsicherung behalten möchte, kann sich auf den netzbezogenen Schalter beschränken.
Schritt für Schritt: Limit IP Address Tracking ausschalten
Falls nach dem Abschalten von Connectivity Assist weiterhin Werbung auftaucht, prüfe die Private-Relay-Einstellung für dein Heimnetz:
- Öffne Einstellungen > WLAN.
- Tippe auf das Info-Symbol neben deinem WLAN-Netzwerk.
- Scrolle nach unten und schalte Limit IP Address Tracking aus 2.
Dieselbe Einstellung gibt es getrennt für das Mobilfunknetz unter Einstellungen > Mobile Daten, wo du unter deiner SIM den Punkt Limit IP Address Tracking findest 2. Für den Pi-hole-Fall ist der WLAN-Schalter der relevante, weil dein Heimnetz-Filter nur dort greifen kann.
Apple weist darauf hin, dass die netzbezogene Einstellung für alle deine Geräte gilt, auf denen Private Relay aktiviert ist, und dass sie bei mehreren Netzkonfigurationen – etwa Dual-SIM oder WLAN und Ethernet – pro Netzwerk einzeln gesetzt werden muss 2. Das erklärt, warum eine einzelne Änderung am iPhone nicht unbedingt alle Geräte im Haushalt abdeckt.
So prüfst du dein Gerät
Der einfachste Test ist unabhängig vom Betriebssystem deines Filters. Öffne auf dem iPhone, solange es im WLAN verbunden ist, die Seite dnscheck.tools. Die Seite zeigt an, welche DNS-Resolver dein Gerät tatsächlich verwendet. Wenn dort neben deinem lokalen Resolver auch Server deines Mobilfunkanbieters erscheinen, bist du betroffen. Schalte Connectivity Assist aus, lade die Seite neu und vergleiche 3.
Der zweite Test läuft über deinen Filter selbst: Rufe auf dem iPhone absichtlich eine Domain auf, die deine Blockliste abdeckt, und sieh nach, ob die Anfrage im Query-Log des Pi-hole oder AdGuard Home erscheint. Fehlt sie, lief sie am Filter vorbei. Nach dem Abschalten sollte sie wieder im Log auftauchen und die Domain blockiert werden.
Ein dritter Hinweis ist das Datenvolumen: Mit aktivem Connectivity Assist kann der Mobilfunkverbrauch steigen, weil Daten zusätzlich zum WLAN über Mobilfunk laufen 1. Ein unerwarteter Anstieg des Datenverbrauchs nach dem Update kann also ein Indiz dafür sein, dass die Funktion aktiv war.
Das Umgehen hat neben der Werbung eine zweite Konsequenz: DNS-Anfragen verraten, welche Domains ein Gerät auflöst. Laufen sie über Mobilfunk, sieht dein Mobilfunkanbieter diese Namen mit; laut hagezi gehen die betroffenen Anfragen direkt über Mobilfunk zum Carrier, statt an deinen Router 3. Wer einen lokalen Filter nicht nur wegen der Werbung, sondern auch aus Datenschutzgründen betreibt, sollte Connectivity Assist für das Heimnetz deshalb unabhängig davon ausschalten, ob gerade sichtbar Werbung durchkommt.
Was nicht hilft – und was tatsächlich hilft
Die Tests von hagezi auf der finalen Version fassen die Situation in einer klaren Matrix zusammen 3:
| Konfiguration | Ergebnis |
|---|---|
| Connectivity Assist an, kein DNS-Profil | Carrier-DNS zusätzlich zum lokalen DNS: Leck |
| Connectivity Assist an, verschlüsseltes DNS nur für Mobilfunk | Carrier-DNS weiterhin im WLAN aktiv: Leck |
| Connectivity Assist an, always-on-DNS-Profil | Kein Leck, aber der lokale Resolver wird übersprungen |
| Connectivity Assist an, VPN nur für DNS (Split-Tunnel) | Leck, auch mit WireGuard und Tailscale |
| Connectivity Assist an, VPN-Volltunnel | Kein Leck, lokaler DNS funktioniert |
| Connectivity Assist aus | Lokaler DNS funktioniert normal |
Der naheliegendste Workaround, nur den DNS-Verkehr per VPN nach Hause zu tunneln, greift nicht. Die Anfragen, die über Mobilfunk laufen, betreten den Tunnel gar nicht erst; eine Regel, die nur DNS innerhalb des Tunnels abfängt, sieht sie nie. Das gilt laut hagezi für WireGuard ebenso wie für Tailscale 3. Nur ein vollständiger Tunnel, der den gesamten Verkehr über das Heimnetz führt, fängt auch die Mobilfunk-Anfragen ab – dann funktioniert der lokale Filter wieder 3.
Auch ein “always-on”-DNS-Profil mit verschlüsseltem DNS ist keine echte Lösung für Pi-hole-Nutzer. Es stoppt zwar das Leck, aber auf Kosten deines lokalen Resolvers: Es wird dann ausschließlich der Resolver aus dem Profil verwendet, dein Pi-hole wird komplett übersprungen 3. Du hättest damit ein Leck gegen ein anderes getauscht. Der einzige Weg, deinen lokalen Filter wieder vollständig einzubeziehen, ist das Abschalten von Connectivity Assist.
Wer den Filter zwingend auf allen Geräten und Netzen durchsetzen will, braucht einen Volltunnel-VPN ins Heimnetz. Das ist eine bewusste Infrastruktur-Entscheidung mit eigenem Aufwand und eigenen Fehlerquellen, keine schnelle Einstellung.
Wann du Connectivity Assist anlassen kannst
Nicht jedes Netz braucht die Funktion ausgeschaltet. Unterwegs in fremden WLANs – Café, Flughafen, Bahn – ist die automatische Ausfallsicherung sinnvoll, und dort gibt es in der Regel ohnehin keinen eigenen DNS-Filter. Für dieses Szenario reicht der netzbezogene Schalter: Connectivity Assist global anlassen, aber für dein Heimnetz ausschalten 1, 3.
Genau diese Granularität ist der praktische Mehrwert der zwei Schalter. Der globale Schalter entscheidet, ob die Funktion grundsätzlich zur Verfügung steht; der netzbezogene Schalter entscheidet, ob sie in einem bestimmten WLAN greift. Wer Pi-hole nur zu Hause betreibt, kann beides haben: die Ausfallsicherung unterwegs und den funktionierenden Filter daheim.
Eine verbleibende Unsicherheit sollte man offen benennen: Die genauen Aktivierungsbedingungen, wann Connectivity Assist konkret auf Mobilfunk zugreift, sind nicht vollständig dokumentiert. Apple nennt Einschränkungen – die Funktion greift nicht bei internationalem Roaming, nicht im Low-Data-Modus für Mobilfunk und nicht bei bestimmten Drittanbieter-Apps für Audio- und Video-Streaming 1. Die exakten Schwellen, ab denen das System parallelen Mobilfunkverkehr zulässt, sind damit nicht öffentlich festgelegt. Wer auf Nummer sicher gehen will, dass keine einzige Anfrage den Heimfilter umgeht, schaltet die Funktion für das Heimnetz aus, statt sich auf die Einschränkungen zu verlassen.
Häufige Fragen
Ist das ein Bug oder Absicht?
Apple dokumentiert das Verhalten als Feature und benennt den Werbeblocker-Anwendungsfall in seiner Anleitung ausdrücklich 1. Es ist also kein versehentlicher Fehler, sondern ein dokumentiertes Verhalten mit einer dokumentierten Abschaltmöglichkeit. Für Pi-hole-Nutzer ist die Folge trotzdem ein unerwünschtes Umgehen des Filters.
Muss ich mein Pi-hole neu konfigurieren?
Nein. Das Problem liegt nicht in der Pi-hole-Konfiguration oder der Blockliste, sondern im Routing des iPhones 3. Eine Änderung am Pi-hole behebt das Umgehen nicht.
Gilt das auch für AdGuard Home?
Ja. Die Beschreibung betrifft jede Form lokaler DNS-Filterung, ausdrücklich auch AdGuard Home und jeden Resolver, der per DHCP verteilt wird 3.
Betrifft es auch iPads und andere Geräte?
Die Funktion ist unter iPadOS 27 in gleicher Form vorhanden 4. Geräte, die noch auf iOS 26 laufen, nutzen weiter das alte Wi-Fi Assist, das nur bei schwachem WLAN auf Mobilfunk wechselt.
Weiterführende Artikel
- Home Assistant Einstieg: smarte Leuchtmittel oder erst der Koordinator?
- Datenschutz-Praxis: Standort-Tracking auf dem Handy reduzieren
- KI-Tools in der Praxis: Voice PE Realtime — Sprachsteuerung, die endlich funktioniert
- Pi-hole Blocklisten 2026: DNS-Filter, Ad-Blocking und Privatsphäre im Heimnetz
- Microsoft Store Apps: Icons auf dem Desktop verschwunden – Windows 11 – technische Ursachen und Lösung
Transparenzhinweis
Dieser Beitrag wurde mit Unterstützung künstlicher Intelligenz erstellt und automatisiert auf Quellen, Fakten und Qualitätskriterien geprüft. Die technischen Zusammenhänge stützen sich auf die Apple-Supportdokumentation und die Tests des DNS-Blocklisten-Maintainers hagezi auf der finalen Version iOS 27.0.
Passende Produktrecherchen
Wenn du die praktische Seite vertiefen möchtest, findest du hier passende Suchpfade zum Vergleichen. Keine Kaufpflicht, keine Rangliste, sondern thematisch passende Produktrecherchen:
- GL.iNet Router für Testnetze und Reise-VPNs ansehen
- Managed Switches für Netzwerksegmentierung recherchieren
- USB-C-Ladegeräte und Kabel für Android-Smartphones ansehen
- Mini-PCs für Homelab und Security-Lab vergleichen
- USB-C-Sticks für lokale Smartphone-Backups recherchieren
- Starlink-Verfügbarkeit und Konditionen prüfen
Hinweis: Als Amazon-Partner verdient kalika.de an qualifizierten Verkäufen. Für dich ändert sich der Preis nicht.
Hinweis: Dieser Link ist ein Starlink-Empfehlungslink. Wenn du darüber bestellst, können für dich und kalika.de Vorteile nach den jeweils geltenden Starlink-Bedingungen entstehen.
Entscheidungshilfe: Wann ist das sinnvoll?
Eher sinnvoll, wenn du ki tools praxis nicht nur als Nachricht lesen willst, sondern eine praktische Einordnung brauchst: Was ändert sich, wen betrifft es und welche nächsten Schritte sind realistisch?
Eher abwarten, wenn die Quellenlage noch dünn ist, wichtige technische Details fehlen oder der Nutzen nur aus Hersteller- oder Projektversprechen besteht. Dann ist Beobachten besser als vorschnelles Umstellen.
Worauf du achten solltest: konkrete Verfügbarkeit, nachvollziehbare Kosten, offene Einschränkungen, Sicherheits- oder Datenschutzfolgen und belastbare Quellen statt bloßer Ankündigungen.
Grenzen der Einordnung
Die zitierten Daten beschreiben eine Erhebung beziehungsweise einen allgemeinen Markt- oder Regelungsstand. Sie ersetzen weder eine technische Prüfung noch eine individuelle Kostenrechnung. Änderungen bei Preisen, Förderung, Netzentgelten oder Vorgaben können das Ergebnis beeinflussen; daher sollten Leserinnen und Leser die Primärquellen vor einer konkreten Entscheidung erneut prüfen.
Quellen
[1] About Connectivity Assist – Apple Support
[2] Manage iCloud Private Relay for specific websites, networks, or system settings – Apple Support
[3] iOS 27 / iPadOS 27: “Connectivity Assist” bypasses your local DNS – hagezi/dns-blocklists, GitHub Discussion #11473
[4] iOS 27’s Wi-Fi Settings Include Rebranded ‘Connectivity Assist’ Feature – MacRumors