Prüfen Sie sofort Ihren NAT-Typ

Dies ist die während des Tests gemeldete öffentliche IPv4-Adresse. Ein Router oder Internetanbieter kann eine private Adresse übersetzen, bevor der Datenverkehr das Internet erreicht. Daher können mehrere Geräte oder Anschlüsse dieselbe öffentliche Adresse nutzen.

Eine Adresse allein bestätigt weder CGNAT noch Double NAT. Auch ein VPN kann die öffentliche Adresse ändern, die der Test sieht.

Wenn ein Port ermittelt werden konnte, steht die Zahl nach dem Doppelpunkt im IPv4-Ergebnis für einen UDP-Port, der bei diesem Browsertest beobachtet wurde. Beispielsweise zeigt 203.0.113.10:62000 eine Adresse und den gemeldeten Port 62000.

Das ist weder ein Spieleport noch eine Portweiterleitungsregel oder ein Nachweis, dass unter dieser Adresse ein Dienst erreichbar ist. Zuordnungen können sich zwischen Tests oder Zielen ändern, besonders bei Symmetrisches NAT.

Der NAT-Typ beschreibt das IPv4-UDP-Verhalten auf dem geprüften Verbindungsweg. NAT 1 steht für Full Cone NAT, NAT 2 für Restricted Cone NAT, NAT 3 für Port Restricted Cone NAT und NAT 4 für Symmetrisches NAT. Offenes Internet ist ein separates Ergebnis für einen Verbindungsweg, auf dem kein NAT beobachtet wurde.

Diese Bezeichnungen verwendet NAT Checker für die Kategorien aus RFC 3489. PlayStation, Xbox und andere Plattformen haben eigene Bezeichnungen und Tests. Der NAT-Typ misst weder die Downloadgeschwindigkeit noch garantiert er, dass jedes Spiel jeden anderen Teilnehmer erreichen kann. Unter „So klassifizieren wir NAT“ findest du die Entscheidungslogik.

Dies ist eine globale IPv6-Adresse, die dein Browser während der IPv6-Prüfung bereitgestellt hat. Rein lokale Adressen werden ausgeschlossen. Die IPv6-Erkennung läuft unabhängig vom IPv4-NAT-Test.

Eine Adresse allein belegt keine externe Konnektivität. „IPv6 nicht erkannt“ bedeutet, dass dieser Test keine globale IPv6-Adresse gefunden hat. Daraus folgt nicht, dass dein Internetanbieter oder Gerät IPv6 nicht unterstützen kann.

„Externe Konnektivität bestätigt“ bedeutet, dass unser IPv6-Testdienst eine erfolgreiche WebRTC/UDP-Verbindung auf diesem Verbindungsweg gemeldet hat. Eine gefundene IPv6-Adresse allein reicht für dieses Ergebnis nicht aus.

„Externe Konnektivität konnte nicht bestätigt werden“ bedeutet, dass dieser Verbindungsweg nicht erfolgreich aufgebaut wurde. Firewall-Regeln, ein VPN, Browsereinschränkungen oder Netzwerkbedingungen können den Test beeinflussen. Normales Surfen über IPv6 kann trotzdem funktionieren, da es andere Verbindungen und Protokolle verwendet. Ein Timeout oder Dienstfehler bedeutet, dass die Prüfung nicht abgeschlossen wurde.

Blockiert ist ein Ergebnis des NAT-Testservers, wenn dieser UDP-Verbindungsweg nicht aufgebaut werden kann. Es zeigt nicht, welches Gerät oder welche Einstellung die Ursache ist.

Timeout bedeutet, dass innerhalb des Testzeitraums keine abschließende Klassifizierung eingegangen ist. Ein Fehler oder die Meldung „Dienst vorübergehend nicht verfügbar“ bedeutet, dass der Test nicht abgeschlossen werden konnte. Das sind keine bestätigten NAT-1–4-Klassifizierungen. Wiederhole den Test und prüfe dann Browsereinschränkungen, VPNs und Firewall-Einstellungen, bevor du einen Fehler beim Router oder Internetanbieter annimmst.

RFC 3489 unterscheidet NAT-Typen, indem öffentliche IP- und Portzuordnungen verglichen und die Antwortquellen geprüft werden, die denselben lokalen UDP-Socket erreichen können. Das Ändern der Antwortquelle und das Ändern des Anfrageziels prüfen unterschiedliche Verhaltensweisen.

1. Test I: Sende eine normale STUN-Binding-Anfrage. Die Antwort enthält MAPPED-ADDRESS, also die öffentliche IP-Adresse und den UDP-Port, die der Server beobachtet hat. Vergleiche beides mit der Adresse und dem Port des lokalen Sockets, um festzustellen, ob eine Übersetzung stattgefunden hat.
2. Test II: Fordere eine Antwort von einer anderen IP-Adresse und einem anderen Port des Servers an. Kommt sie an, kann ein externer Absender, den der Client noch nicht kontaktiert hat, die Zuordnung erreichen.
3. Test I mit alternativem Ziel: Sende vom selben lokalen Socket eine normale Anfrage an den alternativen Serverendpunkt aus CHANGED-ADDRESS. Vergleiche die neue öffentliche IP-Adresse und den Port mit der ersten Zuordnung, um eine zielabhängige Zuordnung zu erkennen.
4. Test III: Fordere eine Antwort von der ursprünglichen Server-IP-Adresse, aber einem anderen Port an. Damit lässt sich ein eingehender Filter, der nur die IP-Adresse prüft, von einem Filter unterscheiden, der sowohl IP-Adresse als auch Port abgleicht.

Das sind die Klassifizierungsprüfungen des RFC. Unser Browsertest ermittelt die öffentliche Zuordnung mit STUN und verwendet servergestützte WebRTC-Verbindungstests, um die entsprechende Verhaltenskategorie zurückzugeben.

1. Test I erhält eine Antwort, und die zugeordnete öffentliche IP-Adresse oder der Port unterscheidet sich vom lokalen Socket-Endpunkt. Es ist also NAT vorhanden.
2. Test II erhält eine Antwort von einer anderen Server-IP-Adresse und einem anderen Port, obwohl der Client keinen Datenverkehr an diese Antwortquelle gesendet hat.
3. Im Entscheidungsbaum von RFC 3489 ist das Full Cone NAT, das wir NAT 1 nennen.

Sobald eine UDP-Zuordnung besteht, können andere externe Absender sie ohne vorherigen Kontakt erreichen. Das erleichtert meist direkte Verbindungen zu anderen Teilnehmern. Es bedeutet nicht, dass jeder Port offen ist.

1. NAT ist vorhanden, aber Test II erhält keine Antwort von der geänderten IP-Adresse und dem geänderten Port.
2. Ein neuer Test I zum alternativen Ziel meldet dieselbe öffentliche IP-Adresse und denselben Port wie die erste Anfrage. Bei diesem Ziel ändert sich die Zuordnung nicht.
3. Test III erhält eine Antwort von der ursprünglichen Server-IP-Adresse über einen anderen Port. Vorheriger Kontakt mit dieser IP-Adresse reicht aus; Kontakt mit dem genauen Antwortport ist nicht erforderlich.

Das ist Restricted Cone NAT, unser NAT 2. Eingehender UDP-Datenverkehr ist von externen IP-Adressen erlaubt, die der Client bereits kontaktiert hat.

1. NAT ist vorhanden, und Test II erhält keine Antwort von der geänderten IP-Adresse und dem geänderten Port.
2. Test I zum alternativen Ziel meldet dieselbe öffentliche IP-Adresse und denselben Port. Eine zielabhängige Zuordnung wird damit in diesem Vergleich ausgeschlossen.
3. Auch Test III erhält keine Antwort, wenn nur der Quellport des Servers geändert wird. Im RFC-Modell muss eingehender Datenverkehr zu einer IP-Adresse und einem Port passen, die der Client bereits kontaktiert hat.

Das ist Port Restricted Cone NAT, unser NAT 3. Die Zuordnung bleibt im Vergleich gleich, aber der eingehende Filter ist strenger als bei NAT 2.

1. NAT ist vorhanden, und Test II erhält keine Antwort von der geänderten IP-Adresse und dem geänderten Port.
2. Wiederhole Test I vom selben lokalen UDP-Socket zum alternativen Serverendpunkt.
3. Unterscheidet sich die zugeordnete öffentliche IP-Adresse oder der Port von der ersten Zuordnung, erkennt der RFC-Entscheidungsbaum symmetrisches NAT (Symmetric), unser NAT 4.

Beispielsweise könnte ein Ziel 203.0.113.10:62000 sehen und ein anderes 203.0.113.10:62001. Eine Portänderung reicht aus; die öffentliche IP-Adresse muss sich nicht ebenfalls ändern. Ein über einen Server ermittelter Endpunkt kann deshalb für einen anderen Teilnehmer ungeeignet sein, und manche Anwendungen benötigen möglicherweise einen Relayserver.

Erhält Test I keine Antwort, meldet der Erkennungsablauf von RFC 3489 UDP Blocked. Bei einem Browsertest können auch Browsereinstellungen, VPNs, Firewalls, die Verfügbarkeit des Dienstes oder Paketverlust einen fehlgeschlagenen oder unvollständigen UDP-Verbindungsweg verursachen. Das Ergebnis allein zeigt die Ursache nicht.

Ist Test I erfolgreich und stimmen die zugeordnete IP-Adresse und der Port beide mit dem lokalen Socket-Endpunkt überein, wird kein NAT beobachtet. Ist danach Test II erfolgreich, lautet die Klassifizierung Offenes Internet (Open Internet). Schlägt Test II auf diesem Verbindungsweg ohne NAT fehl, nennt der RFC das Symmetric UDP Firewall. Das ist eine Filterbedingung ohne Adressübersetzung, kein symmetrisches NAT, und darf nicht mit NAT 4 verwechselt werden.

Unsere Ergebnisbezeichnungen enthalten keine separate Kategorie für Symmetric UDP Firewall. Auch ein unvollständiger Test oder Dienstfehler ist von einer bestätigten NAT-Kategorie zu unterscheiden.

STUN, beschrieben in RFC 8489, ermöglicht dem Browser, eine öffentliche Adresse und einen UDP-Port zu ermitteln, die außerhalb des lokalen Netzwerks beobachtet werden. ICE, beschrieben in RFC 8445, verwendet Verbindungsprüfungen, um einen Verbindungsweg zwischen Endpunkten aufzubauen.

RFC 3489 definiert die Kategorien Full Cone NAT, Restricted Cone NAT, Port Restricted Cone NAT und Symmetrisches NAT sowie die Zuordnungs- und Antworttests, die sie unterscheiden. Wir verwenden diese Klassifizierungslogik mit unserem Browser und unseren Testservern. IPv6-Adresserkennung und externe Konnektivität werden separat geprüft.

Das Ergebnis beschreibt den geprüften UDP-Verbindungsweg dieses Browsers. VPNs, Firewalls und Browsereinschränkungen können es beeinflussen. Ein reales Netzwerk kann Zuordnungs- und Filterverhalten kombinieren, das historische NAT-Bezeichnungen nicht vollständig beschreiben.

Der Test bestätigt weder CGNAT noch Double NAT, prüft nicht jeden Anwendungsport und garantiert weder die NAT-Bezeichnung einer Konsole noch jede Verbindung zu anderen Teilnehmern. Eine öffentliche IPv6-Adresse belegt keine externe UDP-Konnektivität.

RFC 3489 weist außerdem darauf hin, dass eine erneute Erkennung mit demselben lokalen Socket frühere NAT-Zuordnungen wiederverwenden und das Ergebnis verfälschen kann. Eine neue Erkennung verwendet einen neuen lokalen Endpunkt oder wartet, bis alte Zuordnungen abgelaufen sind. Ergebnisse beschreiben das Netzwerk zum Zeitpunkt der jeweiligen Prüfung.