VPNSmith
self-host-vpnHOWTO

WireGuard DNS-Lecks: erkennen, diagnostizieren, beseitigen (2026)

WireGuard blockiert DNS-Lecks standardmäßig nicht. Produktionsleitfaden: wie Lecks entstehen, Erkennungstools, Linux/Windows/macOS/iOS/Android-Lösungen 2026.

Von Eric Gerard · Fondateur · VPNSmith — Spécialiste self-host VPN & VPS GDPR11 Min. LesezeitPhoto via Unsplash

Affiliate-Hinweis — Dieser Beitrag enthält Contabo-Affiliate-Links. Wenn Sie über diese Links einen VPS erwerben, erhalten wir eine Provision ohne zusätzliche Kosten für Sie. Jeder untenstehende Befehl und jede Konfiguration ist aus offiziellen Quellen dokumentiert und so geschrieben, dass sie auf Ihrem eigenen VPS reproduzierbar sind.

Dies ist der versteckte Mangel von WireGuard, vor dem niemand warnt: Sie richten Ihren Tunnel ein, Ihr gesamter IP-Verkehr läuft über Contabo, Sie fühlen sich sicher — außer Ihre DNS-Anfragen gehen immer noch an Ihren ISP, den Hotelrouter oder den Resolver Ihres Unternehmensnetzwerks. Ein DNS-Leck zerstört die Datenschutzgarantie eines jeden VPNs: Selbst wenn Ihre Daten verschlüsselt sind, weiß Ihr ISP, dass Sie github.com, your-bank.com oder andere Seiten besuchen, weil er die Namen für Sie auflöst.

Das Problem ist strukturell bei WireGuard. Im Gegensatz zu OpenVPN nimmt das Protokoll keine Stellung zu DNS — es ist ein reiner IP-Tunnel. Die DNS = ...-Anweisung in Ihrer .conf ist nur ein Hinweis für wg-quick und variiert je nach Betriebssystem. Dieser Leitfaden erklärt, warum das so ist, wie man es erkennt und die funktionierenden Lösungen pro Plattform — basierend auf einem Jahr Debugging echter Lecks in unseren eigenen Contabo + WireGuard-Setups.

Wie ein DNS-Leck wirklich entsteht

Drei verschiedene Mechanismen erzeugen ein DNS-Leck auf einem WireGuard-Client:

1. Das Betriebssystem hält seine ursprünglichen Resolver aktiv. Auf Linux ohne resolvectl wird /etc/resolv.conf bei jedem Ereignis (DHCP-Erneuerung, Aufwachen, Netzwerkänderung) von NetworkManager, dhclient oder systemd-resolved überschrieben. Der DNS, den Sie über wg-quick gepusht haben, wird überschrieben. Die Anwendung stellt eine Anfrage → das System fragt den ursprünglichen DNS → dieser DNS sieht Ihre Anfragen außerhalb des Tunnels.

2. DNS über HTTPS / DNS über TLS-Browser umgehen das Betriebssystem. Firefox und Chrome haben in vielen Regionen DoH standardmäßig aktiviert. Wenn der Browser eine DoH-Verbindung zu mozilla.cloudflare-dns.com öffnet, wird diese Verbindung durch den WireGuard-Tunnel geleitet (soweit so gut), aber der Browser umgeht den lokalen Resolver vollständig. Wenn ein DoH-Anbieter Protokolle führt, sind Ihre Anfragen dort sichtbar, auf eine andere Weise.

3. Apps mit fest codierten Resolvern. Einige Apps (Spotify, bestimmte Microsoft-Apps, einige Spiele) haben 8.8.8.8 oder ihre eigenen Server fest codiert. Sie stellen eine UDP/53-Anfrage direkt an 8.8.8.8 — und wenn Ihre Firewall das außerhalb des Tunnels nicht blockiert, geht die Anfrage nach draußen.

Das Fazit ist brutal: Ein DNS-Leck ist kein WireGuard-Fehler, es ist ein struktureller Zustand der Betriebssysteme. Sie müssen aktiv Maßnahmen ergreifen, um es zu verhindern.

Zuverlässige Erkennung — die richtigen Werkzeuge

Vergessen Sie kosmetische Lecktests für einen Moment. Hier sind die drei Tests, die wir jedes Mal durchführen, wenn wir ein Leck vermuten:

Test 1: dnsleaktest.com (erweitert) + ipleak.net

Beide Seiten machen dasselbe: Sie laden eine Seite, die DNS-Anfragen an einzigartige, zufällig generierte Subdomains stellt, und schauen dann auf der Serverseite, welche Resolver diese Subdomains angefordert haben. Wenn Sie Resolver in Ihrem Heimatland sehen (Ihr ISP, Ihr Unternehmens-WLAN), ist es ein Leck. Wenn Sie nur Resolver aus Ihrer VPS-Region sehen (Cloudflare DE, Hetzner DE), sind Sie sauber.

Schnellster erster Check: unser eigener IP- & DNS-Lecktest — läuft vollständig in Ihrem Browser, nichts wird protokolliert. Dann gegenprüfen mit dnsleaktest.com/extended-test | ipleak.net

Test 2: Serverseitiges tcpdump (der zuverlässigste)

Dies ist der tatsächlich luftdichte Test. Auf Ihrem VPS, der WireGuard hostet:

tcpdump -i wg0 -n udp port 53

Lassen Sie es laufen. Auf Ihrem Client (Laptop, Telefon), der mit dem Tunnel verbunden ist, geben Sie curl https://example.com ein. Sie müssen eine DNS-Anfrage im tcpdump auf wg0 sehen. Wenn Sie nichts sehen, hat Ihr Client DNS ohne den Tunnel aufgelöst = Leck.

Alternative auf der Client-Seite selbst, noch sauberer:

sudo tcpdump -i any -n udp port 53 and not net 10.66.0.0/16

Wo 10.66.0.0/16 Ihr WireGuard-Tunnel-Subnetz ist. Wenn hier etwas erscheint, ist es ein Leck — DNS-Verkehr, der außerhalb des Tunnels fließt.

Test 3: resolvectl status (nur Linux)

resolvectl status

Für jede Schnittstelle sehen Sie die verwendeten DNS-Server. Die wg0-Schnittstelle sollte Ihren Tunnel-DNS auflisten, und idealerweise sollte die eth0-Schnittstelle keine DNS-Server haben (oder ignoriert werden). Wenn eth0 die Resolver Ihres ISPs aktiv hält, werden Anwendungen sie verwenden, wenn die DNS-Auflösung auf wg0 fehlschlägt (Fallback-Verhalten).

Funktionierende Lösungen pro Plattform

Linux-Desktop — die robusteste Lösung

Empfehlung: systemd-resolved + DNS pro Schnittstelle + nftables-Sperre.

In Ihrer WireGuard .conf, im [Interface]-Block:

[Interface]
PrivateKey = ...
Address = 10.66.0.2/24
DNS = 10.66.0.1
PostUp = resolvectl dns %i 10.66.0.1; resolvectl domain %i '~.'
PreDown = resolvectl revert %i

Die ~.-Domain sagt systemd-resolved "alle DNS-Anfragen gehen über diese Schnittstelle". Das PreDown setzt beim Trennen zurück.

Dann nftables-Firewall-Sperre — blockieren Sie jeglichen DNS-Verkehr, der NICHT zu Ihrem VPS geht:

nft add table inet vpn_lock
nft add chain inet vpn_lock output { type filter hook output priority 0 \; }
nft add rule inet vpn_lock output udp dport 53 ip daddr != 10.66.0.1 drop
nft add rule inet vpn_lock output tcp dport 53 ip daddr != 10.66.0.1 drop

Speichern Sie dies in /etc/nftables.conf für den Neustart. Diese Regel blockiert jedes UDP/TCP 53-Paket, das nicht an Ihren VPS-Resolver gerichtet ist. Brutal, aber effektiv — jedes Leck wird physisch blockiert.

Windows 10/11

Der native WireGuard-Client beachtet DNS = ... korrekt über den Wintun-Treiber. Das Problem: Split-DNS ist standardmäßig nicht optimal, und DoH in Edge/Chrome kann es umgehen.

Schritte:

  1. In Ihrer .conf, DNS = 10.66.0.1 (Ihr VPS-Resolver).
  2. Browser-DoH deaktivieren: in Chrome chrome://settings/security → "Sicheren DNS verwenden" deaktivieren; in Edge dieselbe Einstellung.
  3. Firewall-Härtung: Windows Defender Firewall mit erweiterter Sicherheit → ausgehende Regel, die UDP/53 außer zu Ihrer VPS-IP blockiert. Der PowerShell-Befehl:
New-NetFirewallRule -DisplayName "Block DNS Leak" `
  -Direction Outbound -Protocol UDP -LocalPort 53 `
  -RemoteAddress "!10.66.0.1" -Action Block

Die führende !-Syntax bedeutet "alles außer". Passen Sie 10.66.0.1 an die IP Ihres VPS-Resolvers an.

macOS Sonoma/Sequoia

Der macOS WireGuard-Client (App Store) beachtet DNS korrekt. Aber der mDNSResponder-Cache und die Nähe zu .local können Überraschungen verursachen.

Schritte:

  1. WireGuard-Konfiguration: DNS = 10.66.0.1.
  2. Nach dem Verbinden den DNS-Cache leeren: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder.
  3. Browser-DoH deaktivieren (wie bei Windows).
  4. Überprüfen Sie mit scutil --dns, dass nur Ihr Tunnel-DNS im "resolver #1"-Block erscheint.

iOS — der WireGuard-Client ist ehrlich

Der offizielle iOS WireGuard-Client beachtet DNS = ... sauber. Normalerweise müssen Sie nichts weiter tun. Achten Sie jedoch darauf:

  • Safari kann iCloud Private Relay verwenden, wenn es aktiv ist, was eine zusätzliche Schicht (Cloudflare/Akamai) hinzufügt — kein Leck, aber es ändert das Routing.
  • Apps, die nicht standardmäßige Ports verwenden (einige VoIP), können umgehen — selten, aber es existiert.

Realitätsnaher Test: Aktivieren Sie den Tunnel, gehen Sie zu dnsleaktest.com in Safari, Sie sollten nur Resolver aus Ihrer VPS-Region sehen.

Android — der kniffligste Fall

Der offizielle Android WireGuard-Client behandelt DNS teilweise. Das klassische Problem: Android getprop net.dns1 hält den ursprünglichen DNS aktiv, und einige Android-Apps fragen diesen Prop direkt ab, umgehen den Tunnel.

Abhilfen in der Reihenfolge der Präferenz:

  1. NetGuard oder AFWall+ in Verbindung mit WireGuard: NetGuard erstellt ein lokales VPN, das den gesamten DNS-Verkehr auf Ihren Tunnel sperrt. Kostenlos, Open-Source auf F-Droid.
  2. Private DNS Android (Einstellungen → Netzwerk → Privates DNS) mit einem DoT-Server, dem Sie vertrauen: dns.adguard.com oder Ihr eigener Server mit Unbound + DoT-Unterstützung. DoT funktioniert auch ohne VPN, daher ist es eine Basisschicht des Schutzes.
  3. AdGuard Home oder NextDNS als Private DNS-Anbieter: gleiche Einrichtung, aber Sie kontrollieren den Resolver vollständig.

Ehrliches Urteil: Android WireGuard + Private DNS, das auf Ihren eigenen VPS zeigt, ist eine der robustesten verfügbaren Konfigurationen. So konfiguriert, bleibt die DNS-Auflösung auf Mobilgeräten zuverlässig im Tunnel.

Solide VPS-seitige Einrichtung — Unbound auf Contabo

Quellcode in einem Terminal-Editor
Quellcode in einem Terminal-Editor

Die andere Hälfte der Gleichung ist was auf Ihrem VPS DNS beantwortet. Standardmäßig, wenn Ihr WireGuard-Client auf 10.66.0.1 zeigt, ist das Ihr VPS — und der VPS selbst benötigt einen echten Resolver. Zwei brauchbare Optionen:

Option A: Unbound (puristisch, vollständig rekursiv)

Unbound fragt die DNS-Wurzeln direkt ab. Null Drittanbieterprotokoll. Die sauberste Datenschutzkonfiguration. Installation auf einem Contabo VPS S (Debian 12):

apt install unbound unbound-anchor

Minimale Konfiguration in /etc/unbound/unbound.conf.d/vpn.conf:

server:
  interface: 10.66.0.1
  access-control: 10.66.0.0/24 allow
  hide-identity: yes
  hide-version: yes
  qname-minimisation: yes
  use-caps-for-id: yes
  prefetch: yes
  cache-min-ttl: 300
  cache-max-ttl: 86400
  num-threads: 2
  msg-cache-size: 50m
  rrset-cache-size: 100m

Neustart: systemctl restart unbound. Test von einem Client: dig @10.66.0.1 example.com — Sie sollten eine Antwort mit ANSWER SECTION erhalten.

Option B: AdGuard Home (Filterung + UI)

Wenn Sie DNS-basierte Werbe-/Tracker-Blockierung wünschen, ist AdGuard Home die einfache Wahl. Web-UI, Filterlisten (EasyList, EasyPrivacy, OISD, …), Statistiken pro Client. Installation:

curl -s -S -L https://raw.githubusercontent.com/AdguardTeam/AdGuardHome/master/scripts/install.sh | sh -s -- -v

Web-Einrichtung auf Port 3000 → Hören auf 10.66.0.1:53 einstellen. Upstream: Standard-DoT/DoH-Stack belassen (oder an Unbound auf 127.0.0.1 für den vollständigen Puristenmodus anschließen).

Wir betreiben AdGuard Home → Unbound auf unserem eigenen Contabo. Das Beste aus beiden Welten: Filterung + null Protokoll.

Die Einrichtung einer der beiden Optionen dauert 15 Minuten auf einem frisch bereitgestellten Contabo VPS S für 4,99 €/Monat (vollständige Einrichtung: Contabo Schritt-für-Schritt-Anleitung). Die Gesamtkosten bleiben bei 60 €/Jahr für einen VPS, der WireGuard + Ihren DNS-Resolver in einem erledigt.

VPS-seitige DNS-Leck-Härtung

Drei zusätzliche Anpassungen auf der WireGuard-Hub-Seite, die DNS-Lecks erheblich erschweren:

1. Erzwingen Sie Tunnel-DNS über iptables/nftables. Auf dem VPS, fangen Sie jeden UDP/53-Verkehr ab, der vom WireGuard-Subnetz stammt, und leiten Sie ihn an Ihren lokalen Resolver um:

nft add rule ip nat prerouting iif wg0 udp dport 53 dnat to 10.66.0.1

Selbst wenn ein Client versucht, 8.8.8.8 direkt abzufragen, fängt der VPS ab und antwortet über Unbound. Brutal, aber kugelsicher.

2. Blockieren Sie IPv6-Lecks serverseitig. Wenn Ihr VPS IPv6 auf der wg0-Schnittstelle nicht deaktiviert, werden einige Clients DNS über IPv6 außerhalb des Tunnels lecken. Entweder deaktivieren Sie IPv6 vollständig auf dem VPS (net.ipv6.conf.all.disable_ipv6=1 in /etc/sysctl.conf), oder Sie pushen eine ::/0 IPv6-Route durch wg0 in den Client AllowedIPs.

3. Überwachung ausgehender ungewöhnlicher DNS. Richten Sie einen täglichen Cron auf dem VPS ein, der Unbound-Protokolle auf Anfragen von externen IPs (nicht 10.66.0.0/24) überprüft. Wenn Anfragen von außen eintreffen, ist Ihr Tunnel undicht oder offen. Siehe unser WireGuard VPS-Monitoring mit Prometheus + Grafana für eine dashboard-fertige Einrichtung.

Häufige Fehlalarme — keine Panik

Zwei Situationen sehen aus wie Lecks, sind es aber nicht:

1. iCloud Private Relay (macOS/iOS). Wenn Sie Private Relay aktiv haben, werden DNS-Anfragen doppelt über Apple + Cloudflare/Akamai weitergeleitet. dnsleaktest.com zeigt manchmal "Cloudflare US" anstelle Ihres Tunnel-DNS — das ist erwartetes Verhalten, kein Leck. Deaktivieren Sie Private Relay, wenn Sie nur Ihr Tunnel-DNS sehen möchten.

2. Browser-DoH (Firefox, Chrome). Mit aktiviertem DoH umgeht Ihr Browser den OS-Resolver und fragt einen DoH-Server ab (cloudflare-dns.com standardmäßig in Firefox). Es ist technisch kein Leck — die Verbindung geht durch den WireGuard-Tunnel — aber es bedeutet, dass ein Dritter (Cloudflare) Ihre Anfragen sieht. Deaktivieren Sie Browser-DoH, wenn Sie möchten, dass alle Anfragen über Ihren VPS-Resolver gehen.

Endgültiges Urteil — die 5-Minuten-Leckschutz-Checkliste

In der Reihenfolge der Priorität, was zu tun ist, um DNS-Lecks bei einem selbst gehosteten WireGuard zu beseitigen:

  1. DNS = 10.66.0.1 in Ihrer .conf + PostUp = resolvectl dns %i 10.66.0.1; resolvectl domain %i '~.' auf Linux.
  2. nftables/iptables-Firewall, die UDP/TCP 53 außerhalb des Tunnels auf dem Client blockiert.
  3. VPS-seitiger Resolver: Unbound oder AdGuard Home auf 10.66.0.1.
  4. VPS-seitiges DNAT für UDP/53 von wg0 zu 10.66.0.1.
  5. Browser-DoH deaktivieren (oder akzeptieren, dass Cloudflare Ihre Anfragen sieht).
  6. Überprüfen Sie mit tcpdump -i any -n udp port 53 auf dem Client — null Verkehr außerhalb von wg0 ist das Ziel.

Ein sauberes WireGuard-Setup auf Contabo mit diesem Stack: keine DNS-Lecks, sobald es korrekt gesperrt ist. Kein Zauber — das Protokoll ist solide, die Betriebssysteme sind knifflig, und die Sperre ist strukturell, nicht optional.

Weiterführende Informationen

Quellen und Referenzen:

Veröffentlicht am 2026-06-05. Tests und Lösungen validiert auf Debian 12, Ubuntu 24.04, Windows 11 23H2, macOS Sonoma 14.5, iOS 17.5, Android 14 — mit einem Contabo VPS S Nürnberg, der WireGuard 1.0.20210914 + AdGuard Home + Unbound ausführt. Verhalten kann auf anderen Distributionen oder OS-Versionen abweichen — überprüfen Sie immer Ihre eigene Einrichtung mit tcpdump, bevor Sie sie als leckdicht betrachten.

Erinnerung: WireGuard und das Selbsthosting von DNS-Resolvern sind in der EU, den USA, Kanada und den meisten demokratischen Ländern vollkommen legal. VPNSmith veröffentlicht diesen Inhalt zu Bildungszwecken.

★ Nürnberger DSGVO-Rechenzentrum · ✓ Dedizierte IPv4 inklusive · 200+ Mbps garantiert

Self-host your VPN on your own VPS → ContaboFull root access · public IPv4 · pick your region→
Verwandte Artikel

Als nächstes lesen