blue globe icon with arrowswhatsmyip
ENESFRDE

WHATSMYIP · DE

Wie IP-Geolokalisierung funktioniert

Die IP-Geolokalisierung ordnet einer Adresse oder einem Netzwerkpräfix ein wahrscheinliches Land, eine Region, Stadt oder ein größeres Gebiet zu. Sie liefert hilfreichen Netzwerkkontext, ist aber weder eine eingebaute GPS-Funktion noch ein Beweis für den physischen Standort einer Person.

Eine IP-Adresse enthält keine Straßenadresse

Eine IP-Adresse leitet Datenverkehr zu einem Netzwerk; sie enthält weder eine Wohnadresse noch einen Ort oder eine GPS-Koordinate. Ein Geolokalisierungsdienst schätzt hilfreichen Netzwerkkontext anhand von Informationen, die außerhalb des IP-Protokolls erhoben werden.

Bei einem privaten Anschluss kann sie das Gebiet des Netzabschlusses beim Internetanbieter annähern, bei einem Server ein Rechenzentrum. Mobilfunknetze, Carrier-Grade NAT, Unternehmens-Gateways, VPNs, Proxys und Satellitendienste zeigen häufig einen gemeinsam genutzten Ausgangspunkt statt der Person, die die Verbindung nutzt. Das Land ist meist verlässlicher als die Stadt. Ein Kartenpunkt ist eine Schätzung für IP-Adressraum, niemals für ein Gerät oder eine Straßenadresse.

Was tun, wenn meine Geolokalisierung falsch wirkt?

Vergleichen Sie aktuelle Quellen, bestimmen Sie die genaue IP-Adresse oder das CIDR-Präfix und prüfen Sie, ob ein VPN, Proxy, Mobilfunknetz, Unternehmens-Gateway oder Hosting-Anbieter beteiligt ist. Private Nutzer können eine dynamische oder weitgehend gemeinsam genutzte Adresse in der Regel nicht dauerhaft korrigieren; der Internetanbieter oder Netzbetreiber ist die maßgebliche Stelle. Betreiber sollten den kleinsten genauen Bereich einreichen, den sie kontrollieren, und für wiederkehrende Änderungen einen Geofeed nach RFC 8805 pflegen.

Anbieter können Nachweise verlangen, eine nur scheinbar genaue Angabe ablehnen oder eine akzeptierte Korrektur erst in einer späteren Datenversion übernehmen. Die folgenden Stellen nehmen Korrekturen für Quellen dieser Website oder für die Datenbasis von GeoJS entgegen.

Die Signale hinter einem Geolokalisierungsergebnis

Anbieter kombinieren Registrierungs- und RDAP-Daten — diese bezeichnen die Zuständigkeit, nicht unbedingt den Nutzungsort —, BGP, Reverse DNS, Netzwerknamen, Hosting-Informationen und Korrekturen. Die Quellenauswahl hält diese Perspektiven getrennt: Vergleichen Sie Land, Region, Stadt, ASN und Verbindungstyp, statt Koordinaten zu mitteln.

Manche Anbieter messen außerdem von bekannten Standorten aus und vergleichen Latenzzeiten und Wege. Ein einzelner Ping kann eine Adresse nicht lokalisieren — Warteschlangen, Tunnel, Firewalls und asymmetrisches Routing wirken ein —, aber viele Beobachtungspunkte können eine plausible Region von einer unplausiblen Behauptung unterscheiden.

Kein Signal ist für sich allein ausschlaggebend. Registrierungsland kann ein Verwaltungsland sein, Hostnamen können übernommen oder generisch sein, und BGP beschreibt Erreichbarkeit, nicht ein physisches Gebäude. Ein brauchbares Ergebnis wird durch mehrere aktuelle, zueinander passende Signale gestützt.

Von Betreibern veröffentlichte Geofeeds: RFC 8805

Ein Betreiber kann einen IP-Geofeed veröffentlichen. RFC 8805 definiert UTF-8-CSV-Zeilen mit einer IPv4- oder IPv6-Adresse oder einem CIDR-Präfix, gefolgt von optionalen Feldern für Land, ISO-Untereinheit, Stadt und Postleitzahl. Das Präfix ist erforderlich; jedes Standortfeld ist optional. Ein Betreiber kann daher begründet nur Daten auf Länderebene veröffentlichen.

Ein Geofeed ist eine Aussage, keine Anweisung, der jede Datenbank folgen muss. Er wird über HTTPS bereitgestellt. Verbraucher der Daten sollten die Berechtigung des Herausgebers, die Präfixabdeckung und die Genauigkeit prüfen. Grobe, gepflegte Daten sind nützlicher als ein präzise wirkender, aber veralteter oder irreführender Eintrag.

Feeds können sich ändern, wenn ein Netzwerk umzieht; Datenkonsumenten aktualisieren sie normalerweise regelmäßig. Betreiber sollten nicht nur ein geändertes Fragment veröffentlichen: Ein vollständiger, in sich stimmiger Feed erleichtert es, alte Daten zu ersetzen, ohne erraten zu müssen, welche Präfixe fehlen.

Wie RFC 9632 einen Feed mit einem Adressbereich verbindet

Die RFC 9632 beschreibt die Auffindung über Registrierungsdaten. Ein inetnum- oder inet6num-Eintrag kann ein einzelnes HTTPS-Feld geofeed: URL enthalten; ist dieses Feld nicht verfügbar, lautet die kompatible Form remarks: Geofeed https://…. Datenkonsumenten verwenden das spezifischste Registrierungsobjekt, und ein Feed kann darin kleinere Präfixe beschreiben.

Als die RFC 9632 veröffentlicht wurde, hatten RIPE NCC und APNIC das spezielle Feld bereits umgesetzt; die NetRange- und Comment-Felder von ARIN erfüllen eine entsprechende Funktion. Andere Registeroberflächen unterscheiden sich. Optionale RPKI-Signaturen können nachweisen, dass der Unterzeichner den abgedeckten Adressraum kontrolliert, während HTTPS nur die Auslieferung der Datei schützt. RFC 9877 definiert außerdem einen optionalen RDAP-Geofeed-Link.

Die RDAP-Erweiterung erlaubt einem Register, in einer IP-Netzantwort einen ausdrücklichen Link zu einem Geofeed bereitzustellen, doch nicht jedes Register oder jeder Eintrag verwendet sie. Sie ist für eine normale Registrierungsabfrage konzipiert; große Datenkonsumenten sollten die passenden Bulk-Daten des Registers nutzen, statt RDAP wiederholt in Echtzeit abzufragen.

Warum Anbieter einem Feed nicht blind vertrauen

Die RFC 8805 überlässt die Prüfung und Schwellenwerte für Abweichungen dem Datenkonsumenten. BGP kann bestätigen, dass ein Feed-Präfix von einer ASN angekündigt wird, die der Herausgeber betreibt; Messungen können einen Standort aufdecken, der aus mehreren unabhängigen Beobachtungspunkten nicht plausibel ist. IPinfo beschreibt öffentlich sondengestützte Prüfungen von Geofeeds und Korrekturen.

Google ist als Nutzer von Geofeeds dokumentiert, veröffentlicht aber keine Regeln, die eine bestimmte Latenz, einen BGP-Pfad oder ein Anycast-Muster mit Annahme oder Unterdrückung verknüpfen. Die belastbare Schlussfolgerung lautet: Ein Feed ist eine Eingabe, die ein Anbieter prüfen, gewichten oder ablehnen kann.

Auch die Prüfung hat Grenzen. Eine schnelle Antwort kann von einem nahen Cache, einem Tunnelendpunkt oder einem Anycast-Knoten stammen; eine langsame Antwort kann durch Überlastung entstehen. Messungen sind am aussagekräftigsten, wenn sie über Zeit mit Routing- und Betreiberinformationen übereinstimmen.

Anycast, Mobilfunknetze und andere schwierige Fälle

Anycast leitet unterschiedliche Beobachter zu unterschiedlichen Servern, die eine Adresse gemeinsam nutzen. Daher gibt es keine einzige ehrliche Stadtangabe. Ein Anbieter kann ein Land, einen repräsentativen Standort, einen großen Radius oder keine genaue Stadt zurückgeben.

Mobilfunknetze, CGNAT, Unternehmens-Gateways, kürzliche Neuzuweisungen, Cloud-Workloads und CDNs schaffen ähnliche Mehrdeutigkeit. Koordinaten können daher bei einem Gateway, einer Niederlassung des Internetanbieters oder einem Ballungszentrum landen. Sie stellen eine Schätzung dar, nicht einen Haushalt, eine Person oder eine Straßenadresse.

Ergibt dieselbe Adresse aus unterschiedlichen Netzen oder zu unterschiedlichen Zeitpunkten verschiedene Standorte, kann das bei diesen Architekturen normal sein und muss kein Datenbankfehler sein.

Einen IP-Standort verantwortungsvoll nutzen

Verwenden Sie das ungenaueste Ergebnis, das das Problem noch löst, und treffen Sie keine folgenschwere Entscheidung allein auf Grundlage einer Abfrage auf Stadtebene. Betreiber sollten Routing, Registrierung, Reverse DNS und Geofeeds konsistent halten und nach einem Aktualisierungszeitraum mehr als einen Anbieter prüfen.

Weiterführende Informationen

Die folgenden Quellen stützen diesen Leitfaden. Sie umfassen die Geofeed-Spezifikationen und Anbieterunterlagen zu Prüfung und Genauigkeit.

Zurück zur IP-Abfrage