Die vollständige Liste der IP-Datenfelder, die Sie kennen sollten

Fragt man „Welche Daten kann man aus einer IP-Adresse gewinnen?“, enden die meisten Antworten bei „einem ungefähren Standort“. Das ist der kleinste Teil des Gesamtbilds der IP-Intelligence. Dieselbe Adresse verrät Ihnen auch, welches Netzwerk sie besitzt, ob sie ein Heimanschluss oder ein gemieteter Server ist, ob sie ein VPN, ein Tor-Exit oder ein Privacy-Relay ist, ob sie auf einer Blocklist steht und ob sie ein verifizierter Crawler ist. Wie die Erkennungsfelder aufgebaut sind, lesen Sie in So funktioniert die VPN- und Proxy-Erkennung.

Diese Referenz hat sich seit unserer Version vom Juli stark verändert. Die API hat drei Felder hinzubekommen, zwei hatten unsere Tabellen übersehen, der Score eines Tor-Exits stieg von 79 auf 100, und mehrere Felder liefern Werte, die die Tabellen vom Juli falsch beschrieben hatten. Jedes Beispiel unten stammt aus GET api.geoiphub.com/v1/lookup/{ip} vom 22. Oktober 2026, und Sie können jedes davon mit dem kostenlosen IP-Lookup-Tool nachvollziehen.

Wir haben am 22. Oktober 2026 in sieben Live-Antworten 103 Felder gezählt

Wir haben am 22. Oktober 2026 zwischen 04:56 und 04:57 UTC sieben Antworten abgerufen und 103 Felder in 10 Gruppen gezählt. Fünf Felder sind seit Juli neu in dieser Liste, und 11 sind Platzhalter. Die sieben Adressen waren öffentliche Infrastruktur, ausgewählt, um unterschiedliche Gruppen zum Leuchten zu bringen:

Ein kleines Node-Skript hat jede Antwort durchlaufen und jedes Blattfeld aufgelistet, wobei geo.country_names als ein Feld zählte, weil es eine Zuordnung von Übersetzungen ist. Alle sieben Antworten hatten exakt dieselben 103 Schlüssel. So verteilen sie sich:

Fünf Felder sind neu in dieser Liste. Drei wurden im Oktober zur API hinzugefügt: detection.residential_proxy_status, residential_proxy_evidence und residential_proxy_last_seen. Sie stehen jetzt in der Feldreferenz der API, als reserviert gekennzeichnet. Die anderen beiden, threat.crawler.unverified und threat.spammer_last_seen, waren schon im Juli in der Antwort enthalten, und unsere alten Tabellen hatten sie schlicht übersehen. Kein Feld aus der Liste vom Juli wurde entfernt.

Elf Felder sind Platzhalter. Wir haben den Response-Builder der API geprüft: Zehn davon werden bei jeder Abfrage als konstanter leerer Wert ([], "none" oder 0) geschrieben, und hinter crawler.spoofed steht noch keine Datenquelle. Acht weitere Felder enthalten Daten, sind aber reserviert, und ihre Werte geben wir nicht wieder: blocklist_count, ptr_pattern in beiden Gruppen und die fünf Residential-Proxy-Felder. Die Tabellen unten kennzeichnen beide Arten.

Wie die 10 Gruppen in einer einzigen Tor-Exit-Abfrage zusammenspielen

Am leichtesten verstehen Sie die Gruppen, wenn Sie sie an einer einzigen Adresse verfolgen. Hier ist die echte Antwort für 185.220.101.1, einen Tor-Exit, gekürzt auf die Felder, die seine Geschichte erzählen:

Die Gruppen bestätigen sich gegenseitig. Die ASN sagt Hosting, detection.is_tor stammt aus der Exit-Liste des Tor Project, threat.dnsbl_sources zeigt einen Eintrag in Spamhaus ZEN, und die Scoring-Gruppe fasst all das zu block zusammen, mit den vier Methoden, die angeschlagen haben.

Die Antwort zeigt auch eine Lücke. ptr_record ist "none", daher schlug no_ptr_datacenter an, dabei lieferte ein live ausgeführtes dig -x 185.220.101.1 am selben Morgen einen tor-exit-Hostnamen. Das gespeicherte Reverse DNS der API hinkt bei manchen Adressen dem Live-Eintrag hinterher. Diese Lücke ist auch der Grund, warum rdns_tor, das in der Juli-Version dieses Beitrags zu sehen war, nicht mehr anschlägt. Genau dieser Abgleich zwischen den Gruppen ist der Grund, so viele Felder mitzuführen. Nun jede Gruppe der Reihe nach.

1. Die IP selbst (ip)

Das Feld ip gibt die exakte Adresse, die die API aufgelöst hat, als String zurück. Nutzen Sie es, um zu bestätigen, dass Sie das abgefragt haben, was Sie wollten, besonders nach dem Parsen eines X-Forwarded-For-Headers, wo die Wahl des falschen Hops ein klassischer Bug ist. Es ist auch der natürliche Schlüssel für Ihren eigenen Cache.

Sowohl IPv4 als auch IPv6 werden akzeptiert. Wenn Sie nicht sicher sind, wie Ihre eigene öffentliche Adresse lautet, zeigt das What-is-my-IP-Tool sie an, zusammen mit allem, was eine Website daraus ableiten kann.

2. Netzwerk- und ASN-Daten (asn)

Die Gruppe asn sagt Ihnen, welches Netzwerk die Adresse ankündigt, und sie gehört zu den zuverlässigsten IP-Daten, die Sie bekommen können. Jede routbare IP gehört zu einem Autonomous System, und diese Zuordnung stammt aus der globalen Routingtabelle, nicht aus einer Schätzung.

Die Werte ändern sich mit der Adresse. 1.1.1.1 kam mit asn_type: "cdn" und user_type: "content_delivery_network" zurück, Googlebot mit user_type: "search_engine_spider". Der Private-Relay-Egress lieferte asn_type: "unknown", connection_type: "unknown" und user_type: "consumer_privacy_network". Eine Sache hat sich seit Juli geändert: 8.8.8.8 liefert jetzt rpki: "valid", während unser Beispiel in der Dokumentation noch "invalid" zeigt.

Das Feld, auf das Sie achten sollten, ist connection_type. Eine Rechenzentrumsadresse bei einem Endkunden-Login verdient einen zweiten Blick. Hosting allein ist aber kein Betrug: 45.33.32.156 ist reines Hosting und erhielt 10, allow. Sie können jede Adresse mit der kostenlosen Rechenzentrums-IP-Prüfung testen, und die Seite zur API für IP-Geolokalisierung erläutert das ASN-Modell.

3. Geolokalisierungsdaten (geo)

Die Gruppe geo verortet die Adresse auf einer Karte, und ihr wird am häufigsten zu viel vertraut. Alle 15 Felder enthielten bei jeder unserer Abfragen Daten.

Das Land ist verlässlich, die Stadt ist ungefähr. Eine begutachtete Studie zur Geolokalisierung per Reverse DNS mit Daten von 2018 maß für zwei kommerzielle Datenbanken mittlere Abweichungen (Median) von 11,1 km und 16,7 km. Weitere Belege finden Sie in Wie genau ist IP-Geolokalisierung?. Behandeln Sie die Stadt als Radius, niemals als Stecknadel, und verwenden Sie eine IP niemals, um eine Person zu orten.

Lesen Sie geo_confidence zusammen mit detection.is_anycast. 1.1.1.1 lieferte 0,8 für Sydney, ist aber auch is_anycast: true, weil dieselbe Adresse gleichzeitig von vielen Orten aus angekündigt wird. Bei einer Anycast-Adresse ist die Stadt ein plausibler Standort unter mehreren.

Zwei weitere Lücken zeigten sich. timezone kam für alle drei US-Adressen, die wir abgefragt haben (8.8.8.8, Googlebots 66.249.66.1 und 45.33.32.156), als "none" zurück, obwohl die Stadt ausgefüllt war, leiten Sie die Zone also selbst ab, wenn Sie sie brauchen. Und der Private-Relay-Egress 104.28.46.99 wurde in Luanda, Angola, verortet, während Apples eigene Egress-Liste diesen Bereich in Lusaka, Sambia, verortet. Bei Relays übernehmen Sie den Standort aus Apples Zeile, wie wir im Beitrag zum Abgleich von Relay-IPs mit Apples Egress-Liste erklären.

4. WHOIS- und Registrierungsdaten (whois)

Die Gruppe whois sagt, wer den Block registriert hat und wann, abgerufen per RDAP bei den fünf Regional Internet Registries. Sie fügt eine Eigentümerebene hinzu, die der Geolokalisierung fehlt.

Die Abdeckung unterscheidet sich je nach Registry. 8.8.8.8 und 45.33.32.156 lieferten "none" für org, netname, status und last_changed, nur country und registered waren ausgefüllt. Der Eintrag des Mullvad-Servers war umfangreich: netname: "NET-31173-185-213-155-0-24", registriert am 19.07.2017, zuletzt geändert am 11.11.2025.

Die Schlüsselwort-Flags sind unterstützende Belege, niemals ein alleiniger Grund für eine Markierung. Beide waren für alle sieben Adressen false, auch für den Mullvad-Server, dessen Registry-org „31173 Services AB infrastructure in Frankfurt, DE.“ lautet, ohne Erwähnung eines VPN. Deshalb sind die Anbieterlisten in den nächsten Abschnitten wichtiger.

5. Netzwerkbelege (network)

Die Gruppe network enthält Reverse DNS und den Abuse-Kontakt aus der Registry. Drei ihrer sieben Felder sind derzeit Platzhalter.

abuse_contact ist das Feld, zu dem Sie greifen, wenn Sie Aktivitäten melden müssen, und es war bei fünf unserer sieben Adressen ausgefüllt. fcrdns_valid ist kein einfaches Boolean: Für den Tor-Exit, den Mullvad-Server und das Relay, für die kein PTR gespeichert ist, lieferte es den String "none". Code, der auf === false prüft, übersieht diesen Fall.

Vertrauen Sie einem gespeicherten PTR nicht ungeprüft. Für Googlebot 66.249.66.1 gehört der gespeicherte ptr_record zu einer Nachbaradresse, während ein live ausgeführtes dig -x den Wert crawl-66-249-66-1.googlebot.com liefert. Den Wert für 8.8.8.8 (dns.google) und den für 1.1.1.1 (one.one.one.one) haben wir am selben Morgen mit dig -x bestätigt.

open_ports ist leer, selbst wenn ein Probe geantwortet hat. Das Feld wird bei jeder Abfrage als [] geschrieben. Beachten Sie, dass wireguard_open beim Mullvad-Server kein Probe-Ergebnis ist: Es bedeutet, dass Mullvads Serverliste diesen Server als WireGuard kennzeichnet. Lesen Sie Probe-Ergebnisse wie openvpn_open aus scoring.detection_methods, bis das Feld angebunden ist.

6. Erkennung von VPN, Proxy, Tor und Relay (detection)

Die Gruppe detection beantwortet, ob die Adresse ihren Nutzer anonymisiert und wie. Mit 23 Feldern ist sie die größte Gruppe, und drei davon sind seit Juli neu.

vpn_provider ist das Feld, das Sie sich markieren sollten. Die meisten APIs können sagen, dass eine IP „ein VPN“ ist; den Betreiber zu benennen erfordert eine Anbieterliste. Wir benennen ein VPN anhand der eigenen Serverlisten von neun Anbietern, einer öffentlichen Liste eines Drittanbieters oder einer kurzen Tabelle bekannter VPN-Netzwerke, und vpn_confidence zeigt, welcher Pfad gegriffen hat: 95 bedeutet hier Mullvads eigene Liste. Steht eine Adresse auf keiner Liste, liefert vpn_provider den Wert "none", selbst wenn ein Handshake beweist, dass es ein VPN ist. Die Pfade verfolgen wir in Wie ein VPN anhand seiner eigenen Serverliste benannt wird, und Sie können jede Adresse mit dem VPN-Erkennungstest prüfen.

is_relay und relay_provider funktionieren als Paar. 104.28.46.99 lieferte is_relay: true, relay_provider: "iCloud Private Relay", einen Score von 9 und allow. Die API liefert außerdem "Cloudflare WARP" für Cloudflares veröffentlichte WARP-Verbindungsbereiche, also die Adressen, mit denen sich die WARP-App verbindet, und ein undokumentiertes "Cloudflare" für anderen Privacy-Egress von Cloudflare, den Apples Liste nicht abdeckt.

is_anonymous umfasst keine Relays. /docs beschreibt das Feld als true für jeden Anonymisierer einschließlich Relays, doch der Relay-Egress lieferte is_anonymous: false mit anonymity_level: "medium". Das Flag erfasst nur VPN, Proxy und Tor, lesen Sie is_relay also separat.

Die drei neuen Residential-Proxy-Felder sind reserviert. Sie kamen mit einer Backend-Änderung im Oktober hinzu und sind noch nicht dokumentiert. Die Erkennung von Residential Proxys ist derzeit keine Fähigkeit, die wir anbieten, behandeln Sie also alle fünf Residential-Proxy-Felder als reserviert und bauen Sie keine Regeln darauf. Wenn Ihnen dieser Traffic Sorgen macht, erklären wir hier, was eine IP-Abfrage sehen kann und was nicht.

7. Bedrohungs- und Bot-Intelligence (threat)

Die Gruppe threat fragt, ob die Adresse als missbräuchlich bekannt ist oder als freundlicher Bot. Sie hat 25 Felder, und sieben davon sind Platzhalter.

Der Tor-Exit füllt die andere Hälfte dieser Tabelle: is_spammer: true, threat_types: ["spammer", "tor"] und dnsbl_sources: ["zen.spamhaus.org"]. Der Mullvad-Server lieferte threat_types: ["vpn"], das Array spiegelt also auch Anonymisierer-Flags wider.

Im Objekt crawler fallen die Bot-Entscheidungen. Für 66.249.66.1 lieferte die API verified: true, name: "Googlebot", operator: "Google" und verification_method: "ip_range_list", abgeglichen mit 19 offiziellen Crawler-Bereichs-Feeds von 10 Betreibern. Die Kategorien, die wir in Abfragen im Oktober gesehen haben, sind search_engine, ai und fetcher. Namen verlieren ihre Bindestriche, Googles von Nutzern ausgelöster Fetcher kommt also als GoogleUserTriggeredFetcher zurück.

Die Erkennung von Fälschungen findet in Ihrem Code statt. Die API sieht nur die IP, nie den User-Agent. Eine Anfrage, die sich als Googlebot ausgibt, aber crawler.verified: false liefert, ist nicht verifiziert, und diesen Abgleich müssen Sie selbst vornehmen. Wir zeigen das in Bot-Erkennung per IP und im Beitrag zum Verifizieren von KI-Crawlern per IP, rDNS und CIDR.

is_cgnat sollte eine Entscheidung abmildern, nicht verschärfen. Eine CGNAT-Adresse wird von vielen Teilnehmern geteilt, deshalb ist der Score dort gedeckelt, und ein einzelner Übeltäter sollte nicht einen ganzen Mobilfunkanbieter blockieren. Die Feeds hinter dieser Gruppe finden Sie in der Übersicht zur Threat Intelligence.

8. Reverse DNS (dns)

Die Gruppe dns wiederholt drei Reverse-DNS-Felder aus network, damit Code, der nur rDNS braucht, ein einziges kleines Objekt lesen kann. In jeder abgerufenen Antwort waren die Werte identisch mit den Kopien in network.

fcrdns_valid ist das Feld, dem Sie vertrauen können. Ein PTR, der per Forward-Abfrage wieder auf dieselbe IP auflöst, ist ein viel stärkerer Beleg als ein PTR-String allein, den jeder setzen kann, der die Reverse-Zone kontrolliert. Es gilt dieselbe Vorsicht wie in Abschnitt 5: Vergleichen Sie einen gespeicherten PTR mit einem live ausgeführten dig -x, bevor Sie ihn zitieren.

9. Risikobewertung (scoring)

Die Gruppe scoring macht aus den Belegen eine Entscheidung. Sie besteht aus vier Feldern, und detection_methods ist dasjenige, das den Score nachprüfbar macht.

Der fraud_score kombiniert 36 gewichtete Gründe, und manche Gründe ziehen ab. Googlebot zeigt das: datacenter_ip und verified_crawler schlugen beide an, und der Score landete bei 0. Ein Relay kann block nie erreichen, weil Relay-Scores bei 60 gedeckelt sind. recommended_action bildet den Score auf Bereiche ab:

Geben Sie confidence als Zahl aus, nicht als String: Der Wert kommt mit vollem Gleitkomma-Rauschen an. Wir erklären das Modell im Leitfaden zum IP-Betrugsscore und im Beitrag dazu, wie jeder Grund den Score und seine Konfidenz bestimmt, und wo Sie Schwellenwerte setzen, in Den Schwellenwert des IP-Betrugsscores für Login, Registrierung und Checkout wählen. Sie können jede Adresse mit der IP-Betrugsscore-Prüfung bewerten.

10. Metadaten (meta)

Die Gruppe meta datiert die Antwort und identifiziert die Anfrage. Zwei ihrer fünf Felder bedeuten etwas anderes, als ihre Namen vermuten lassen.

last_classified_at ist der Antwortzeitpunkt, nicht der Klassifizierungszeitpunkt. In allen sieben Abfragen lag der Wert innerhalb von etwa einer Sekunde nach dem Absenden der Anfrage. Beurteilen Sie die Aktualität stattdessen anhand von last_scanned. Dieses Feld hatte in jeder Antwort denselben Wert wie detection.last_seen, und alle sieben waren auf den 20. Oktober datiert.

Veraltete IP-Daten sind falsche IP-Daten, denn Bereiche wechseln den Besitzer. Die request_id nennen Sie, wenn Sie eine Klassifizierung für falsch halten. Die serverseitige Latenz lag bei den sieben Abfragen zwischen 0 und 3 ms.

Wie andere Anbieter dieselben Felder benennen

Andere Anbieter von IP-Daten decken sich überschneidende Bereiche mit anderen Feldnamen ab, und manche stellen die umfangreicheren Felder nur in höheren Tarifen bereit. Wir haben am 22. Oktober 2026 die öffentliche Dokumentation von drei Anbietern gelesen und nur übernommen, was diese Seiten angeben.

Quellen: MaxMind GeoIP web services responses, IPinfo privacy detection data, IPinfo ASN data und IPQualityScore proxy detection response parameters.

Daraus folgen zwei praktische Punkte. Die Skala eines Scores bedeutet nur etwas im Zusammenhang mit ihren dokumentierten Schwellenwerten: Bei IPQualityScore ist 75 „verdächtig“, bei uns ist 76 bereits block. Und ein Feld mit gleichem Namen kann Unterschiedliches bedeuten, ordnen Sie Felder also nach ihrer dokumentierten Bedeutung zu, nicht nach dem Namen. Unsere Checkliste für die Auswahl eines IP-Datenanbieters macht daraus einen kurzen Test, den Sie mit jeder API durchführen können.

Welche IP-Datenfelder für welche Entscheidung zählen

Sie brauchen selten alle 103 Felder auf einmal. Wählen Sie die Felder passend zur Entscheidung und lassen Sie die Platzhalter weg:

Bei einer Untersuchung ist die Reihenfolge, in der Sie die Gruppen lesen, ebenso wichtig wie die Felder. Unsere Schritt-für-Schritt-Anleitung zur Untersuchung einer IP-Adresse führt drei echte IPs durch zwölf passive Prüfungen, die diese Gruppen nacheinander nutzen.

Prüfen Sie die Felder selbst, bevor Sie darauf aufbauen

Die Feldliste verändert sich, daher ist es am sichersten, sie selbst zu zählen. Führen Sie eine Abfrage aus und listen Sie die Blattschlüssel auf:

Der Filter zählt jedes Array als ein Feld, überspringt Array-Elemente und zählt country_names als ein Feld wieder hinzu. Für alle sieben unserer gespeicherten Antworten gab er 103 aus. Weicht Ihre Zahl ab, vergleichen Sie die Schlüssel mit der API-Referenz und diesem Beitrag. Wenn Sie ohne Schlüssel testen, takten Sie Ihre Aufrufe: Bereits die 30. Anfrage ohne Schlüssel innerhalb einer Minute liefert 429 und sperrt Ihre IP für zwei Stunden.

Häufig gestellte Fragen

Welche Daten kann man aus einer IP-Adresse gewinnen?

Weit mehr als einen Standort. Eine Live-Abfrage bei GeoIPHub am 22. Oktober 2026 lieferte 103 Felder in 10 Gruppen: die IP selbst, das Netzwerk (ASN, ISP, Verbindungstyp, RPKI), eine ungefähre Geolokalisierung, WHOIS-Registrierungsdaten, Netzwerkbelege und Reverse DNS, die Erkennung von VPN, Proxy, Tor und Relay mit Nennung des Anbieters, wenn er auf einer Liste steht, Bedrohungssignale und verifizierte Crawler, einen erklärbaren Risikoscore von 0 bis 100 sowie Metadaten zur Anfrage. Elf dieser Felder sind Platzhalter, die derzeit einen festen leeren Wert liefern.

Kann eine IP-Adresse meine genaue Wohnadresse verraten?

Nein. IP-Geolokalisierung schätzt einen ungefähren Bereich (bestenfalls eine Stadt oder Region), niemals eine Straßenadresse oder eine bestimmte Person. Ergebnisse auf Stadtebene sind ungenau, und Mobilfunk-, CGNAT- und VPN-Verbindungen schwächen sie weiter. Wer allein aus einer IP adressgenaue Treffer verspricht, übertreibt.

Was ist eine ASN in IP-Daten?

Eine Autonomous System Number identifiziert das Netzwerk, das eine IP-Adresse im Internet ankündigt. Beispielsweise liefert 8.8.8.8 AS15169, GOOGLE - Google LLC. ASN und zugehörige Organisation stammen aus der globalen Routingtabelle und gehören daher zu den zuverlässigsten IP-Datenfeldern, anders als eine Schätzung des physischen Standorts.

Was ist ein IP-Betrugsscore und wie wird er berechnet?

Ein IP-Betrugsscore ist eine einzelne Zahl von 0 bis 100, die zusammenfasst, wie riskant eine Adresse wirkt. GeoIPHub kombiniert 36 gewichtete Gründe, zieht entlastende wie einen verifizierten Crawler ab und liefert die genauen Methoden, die angeschlagen haben, sowie eine empfohlene Aktion: allow bis 25, review bis 50, step_up bis 75, block über 75. Ein Tor-Exit, den wir am 22. Oktober 2026 abgefragt haben, erhielt 100, mit vier aufgeführten Methoden.

Was ist der Unterschied zwischen einer Privatkunden-IP und einer Rechenzentrums-IP?

Eine Privatkunden-IP (residential) wird von einem Endkunden-ISP einem Heimanschluss zugewiesen; eine Rechenzentrums-IP (Hosting) gehört einem Cloud- oder Server-Anbieter. Die Unterscheidung steckt in den Feldern asn.connection_type und asn.asn_type. In unseren sieben Abfragen im Oktober kamen der Mullvad-VPN-Server, der Tor-Exit und Googlebot alle mit connection_type datacenter zurück.

Liefern alle IP-API-Anbieter in jedem Tarif dieselben Felder?

Nein. Laut der Dokumentation von IPinfo enthält der Core-Tarif nur die Privacy-Flags is_anonymous und is_hosting, ausführlichere Privacy-Felder gibt es in Plus, Max und individuellen APIs. GeoIPHub liefert jedes Feld in jedem Tarif, auch im kostenlosen Tarif mit 1.500 Abfragen pro Tag.

Was bedeutet ein Genauigkeitsradius bei der IP-Geolokalisierung?

Ein Genauigkeitsradius ist die Entfernung in Kilometern um die gelieferten Koordinaten, innerhalb derer der tatsächliche Standort wahrscheinlich liegt. MaxMind dokumentiert ihn als location.accuracy_radius. GeoIPHub liefert keinen Radius, sondern geo.geo_confidence, einen Wert von 0 bis 1, der 0 ist, wenn die Belege für eine Stadt nicht ausreichen.