Warum Residential-IPs als Proxy oder Hosting gelten – IP-Audit

Anbieter von IP-Intelligence sehen nie das Gerät hinter einer Adresse. Sie klassifizieren die Adresse anhand von Registry-Einträgen, Routing-Daten, DNS-Namen und beobachtetem Verhalten. Eine „Residential“-IP wird als Proxy oder Hosting markiert, wenn eine dieser Ebenen auf ein Rechenzentrum hindeutet. Das kann das Netz sein, das sie announced, das konkrete /24, in dem sie liegt, die WHOIS-Organisation oder der Reverse-DNS-Eintrag, eine Abweichung zwischen Registrierungsland und Geolocation oder eine Vorgeschichte als Relay für Proxy-Traffic. Jede dieser Ebenen lässt sich mit kostenlosen Tools selbst prüfen, in etwa zehn Minuten pro IP. Dieser Leitfaden zeigt, wie.

Unser Erklärartikel zu IP-Reputation und Fraud Scoring beschreibt, wie ein Score wie der von IPQualityScore entsteht und wie Websites ihn nutzen. Dieser Artikel ist das praktische Gegenstück: welche Klassifizierungssignale das Urteil bestimmen, wie vier verbreitete Anbieter sie ausgeben und wie sich eine einzelne IP oder eine Stichprobe von Exit-IPs reproduzierbar prüfen lässt.

Warum eine IP als Proxy oder Hosting markiert wird

Die meisten „Hosting“- oder „Proxy“-Urteile über angeblich residentielle IPs gehen auf fünf Signale zurück. An erster Stelle stehen Netzbetreiber und Routing, dann Namen, dann die Konsistenz des Standorts, dann beobachtetes Verhalten. Die Anbieter kombinieren diese Signale unterschiedlich, deshalb widersprechen sie sich.

1. ASN-Typ: wer die Adresse announced

Jede geroutete IP wird per BGP von einem autonomen System (ASN) announced. Anbieter klassifizieren ASNs nach der Art der Organisation dahinter. Der ASN-type bei IPinfo ist einer von isp, hosting, business, education oder government. PeeringDB, wo Netze sich selbst beschreiben, hat ein Feld info_types. Die API liefert ["Cable/DSL/ISP"] für Comcast (AS7922) und ["Content"] für Cloudflare (AS13335):

curl -s "https://www.peeringdb.com/api/net?asn=7922" | jq '.data[0] | {name, info_types}'

Ist das announcende ASN ein Hosting-Unternehmen, stuft fast jeder Anbieter die IP als Hosting ein, egal auf wen die Adresse registriert ist. Das ist das am stärksten gewichtete Signal und das, gegen das man am wenigsten argumentieren kann.

2. Das announcte Präfix, nicht nur das ASN

Bei unseren Audits statischer „Residential“- oder ISP-IPs war die aussagekräftige Einheit oft das announcte Präfix, meist ein /24, und nicht das ASN. Ein einzelnes /24 in einem ansonsten sauberen ISP-Netz kann als Hosting gelten, während der Rest dieses ASN als residentiell gilt. Der wahrscheinliche Grund: Anbieter korrigieren ihre Daten auf Präfix-Ebene. Ein Block, der vermietet, umgeroutet oder mit Hosting-Servern gesehen wurde, wird für sich allein umgelabelt, der Rest des ASN behält sein Label. Ein /24 ist außerdem der kleinste IPv4-Block, der in der globalen Routing-Tabelle allgemein akzeptiert wird, und damit die natürliche Einheit für Vermietung und Re-Announcement. Wenn eine IP markiert ist, prüfen Sie also zuerst ihre Nachbarn im selben /24, bevor Sie den ganzen Provider oder den ganzen ISP verantwortlich machen.

3. WHOIS-Organisation und Reverse DNS

Registry-Einträge und PTR-Namen sind billige Signale, und Anbieter nutzen sie als Entscheidungshilfe bei Grenzfällen. Ein Netname oder eine Org mit Wörtern wie „hosting“, „cloud“, „server“ oder „VPS“ oder ein PTR wie vps-123.example-host.net zieht Richtung Hosting. Residentielle Bereiche haben meist ISP-typische PTRs, die die Zugangstechnik kodieren oder „dynamic“ bzw. „pool“ enthalten. Ein fehlender PTR beweist weder das eine noch das andere. Viele ISPs pflegen keinen Reverse DNS, viele Hoster schon.

4. Registry-Land vs. Geolocation-Land

Eine Abweichung zwischen dem Registrierungsland der IP (laut Regional Internet Registry, RIR) und dem Land, in dem Geolocation-Anbieter sie verorten, ist einer der häufigsten Gründe, die wir für ein „Hosting“- oder „Proxy“-Urteil über eine statische IP gesehen haben. Echter Heim-Breitbandanschluss wandert selten: Die Kunden eines deutschen ISP sitzen in Deutschland. Vermietete und neu announcte Blöcke wandern dagegen oft, wobei die Registrierung beim ursprünglichen Inhaber bleibt, während die Adressen anderswo genutzt werden. Betreiber können per selbst veröffentlichtem Geofeed (RFC 8805), über WHOIS auffindbar nach RFC 9632, angeben, wo ein Präfix tatsächlich genutzt wird. Das verschiebt die Geolocation, aber die Registry-Abweichung bleibt für jeden sichtbar, der nachsieht.

Ein reales Beispiel, das sich zu entschlüsseln lohnt: 1.1.1.1. Der IP-to-ASN-Whois-Dienst von Team Cymru (abgefragt am 03.10.2026) zeigt drei verschiedene Fakten in einer Zeile:

$ whois -h whois.cymru.com " -v 1.1.1.1"
AS      | IP               | BGP Prefix          | CC | Registry | Allocated  | AS Name
13335   | 1.1.1.1          | 1.1.1.0/24          | AU | apnic    | 2011-08-11 | CLOUDFLARENET - Cloudflare, Inc., US

Der Block ist über APNIC in Australien registriert (er gehört APNIC Labs). Announced wird er als /24 vom ASN von Cloudflare, das in den USA registriert ist, und ip-api verortet ihn in AU mit hosting: true. Für einen Resolver, den APNIC und Cloudflare gemeinsam betreiben, ist das alles erwartbar. Bei einer IP, die Ihnen als „Residential US“ verkauft wurde, würde dieselbe dreifache Abweichung jedes Hosting-Urteil erklären.

5. Beobachtetes Verhalten

Die letzte Ebene ist das, was Anbieter die IP haben tun sehen: Honeypots ansteuern, in Abuse-Feeds auftauchen, VPN- oder Proxy-Software betreiben oder als Exit eines bekannten Residential-Proxy-Netzes erscheinen. Das ist die einzige Ebene, die eine echte Heim-IP bei einem echten ISP markieren kann. Die Residential-Proxy-API von IPinfo liefert den service, in dem eine IP gesehen wurde, mit last_seen und percent_days_seen über ein 7-Tage-Fenster. MaxMind definiert is_residential_proxy als IP, die „sich in einem mutmaßlichen Anonymisierungsnetz befindet und zu einem residentiellen ISP gehört“, wobei Peer-to-Peer-Proxy-IPs ausdrücklich ausgenommen sind. Die Anbieter ziehen diese Grenze an unterschiedlichen Stellen, aber der Kern bleibt: Ein sauberes ASN schützt keine IP, die tatsächlich als Proxy genutzt wird.

Wie vier Anbieter ihr Urteil ausgeben

Jeder Anbieter beantwortet eine leicht andere Frage. Zwei „widersprüchliche“ Ergebnisse sind oft beide richtig. Die Feldnamen unten stammen aus der aktuellen Dokumentation des jeweiligen Anbieters.

AbuseIPDB ergänzt ein weiteres Label, das Ihnen oft begegnen wird: usageType, mit Werten wie „Data Center/Web Hosting/Transit“ (Dokumentation).

ISP-Proxys: warum sie eine Grauzone sind

„ISP“- oder „Static Residential“-Proxys sind Adressen, die auf einen ISP registriert, aber zu Servern in einem Rechenzentrum geroutet sind. Sie sind eine Grauzone, weil die Registry-Ebene „residentiell“ sagt, die Routing- und Verhaltensebene aber womöglich nicht. Ob eine bestimmte IP durchgeht, hängt davon ab, welcher Ebene ein Anbieter für dieses Präfix am meisten vertraut.

Die gute Variante: Ein ISP announced seinen eigenen Block aus seinem eigenen ASN, die Server stehen in seinem Netz. Dann stimmen ASN-Typ, WHOIS und Geolocation überein. Die schwächere Variante: Ein auf einen ISP registrierter Block wird vom ASN eines Hosting-Unternehmens announced, oft nach einer Vermietung. Die Registry sagt weiterhin „ISP“, aber das announcende ASN ist Hosting, also das schwerste Signal, und das Registry-Land passt womöglich nicht zur Geolocation. Die Anbieter holen bei solchen Blöcken Präfix für Präfix auf, deshalb kann ein /24 eines Providers sauber und das nächste markiert sein. Unser Erklärartikel zu ISP-Proxys behandelt die Produktseite. Mit dem Audit unten finden Sie heraus, welche Variante Ihnen verkauft wurde.

Eine IP selbst prüfen, Schritt für Schritt

Führen Sie für jede IP dieselben fünf Schritte aus: Exit-IP ermitteln, Registrierung abfragen, Routing abfragen, DNS prüfen, dann zwei oder drei Anbieter befragen. Verglichen wird auf /24-Ebene. Alles unten funktioniert mit kostenlosen Endpunkten.

Schritt 1: die tatsächliche Exit-IP ermitteln

Prüfen Sie, welche Adresse das Ziel wirklich sieht. Verlassen Sie sich nicht auf ein Dashboard. Für einen Proxy:

curl -s -x "http://USERNAME:PASSWORD@gate.proxyhat.com:8080" https://api.ipify.org

Unser Proxy-Checker erledigt das im Browser, falls Sie es nicht skripten möchten.

Schritt 2: Registrierung (RDAP, Team Cymru)

IP=1.1.1.1
# RDAP über den rdap.org-Redirector: registrierter Bereich, Inhaber, Registry-Land
curl -sL "https://rdap.org/ip/$IP" | jq '{name, handle, country, type, startAddress, endAddress}'
# Einzeilige Übersicht: ASN, BGP-Präfix, Registry-CC, Registry, AS-Name
whois -h whois.cymru.com " -v $IP"

Notieren Sie country und den Inhaber unter name. Für 1.1.1.1 liefert RDAP "name": "APNIC-LABS", "country": "AU".

Schritt 3: Routing (RIPEstat, bgp.he.net)

Die RIPEstat Data API ist kostenlos, braucht keinen Schlüssel und deckt den Adressraum aller RIRs ab, nicht nur den von RIPE.

# Announcendes ASN und das exakte announcte Präfix
curl -s "https://stat.ripe.net/data/network-info/data.json?resource=$IP" | jq '.data'
# Wem das ASN gehört und ob das Präfix überhaupt announced wird
curl -s "https://stat.ripe.net/data/prefix-overview/data.json?resource=$IP" | jq '.data | {resource, announced, asns}'
# Land laut RIR-Delegationsstatistik
curl -s "https://stat.ripe.net/data/rir-stats-country/data.json?resource=$IP" | jq '.data.located_resources'
# Alle Präfixe, die das ASN announced, um zu sehen, ob dieses /24 ein Ausreißer ist
curl -s "https://stat.ripe.net/data/announced-prefixes/data.json?resource=AS13335" | jq '.data.prefixes | length'

Für eine grafische Ansicht zeigt bgp.he.net dasselbe ASN und Präfix samt Upstreams und Peers. Ein kleines ASN mit ein oder zwei Transit-Providern, die Hosting-Unternehmen sind, sagt viel aus.

Schritt 4: Reverse DNS

dig +short -x $IP

Schritt 5: zwei oder drei Anbieter, nebeneinander dokumentiert

# ip-api: kostenlos, ohne Schlüssel, nur HTTP
curl -s "http://ip-api.com/json/$IP?fields=status,countryCode,isp,org,as,reverse,mobile,proxy,hosting"
# IPinfo Lite: kostenlos mit Token, Land + ASN
curl -s "https://api.ipinfo.io/lite/$IP?token=$IPINFO_TOKEN"
# AbuseIPDB: kostenloser Schlüssel, 1.000 Abfragen/Tag
curl -sG https://api.abuseipdb.com/api/v2/check --data-urlencode "ipAddress=$IP" \
  -H "Key: $ABUSEIPDB_KEY" -H "Accept: application/json" | jq '.data | {usageType, isp, abuseConfidenceScore}'

Eine Stichprobe von Exit-IPs nach Präfix prüfen

Bei einem Pool statt einer einzelnen IP gruppieren Sie die Ergebnisse nach announctem Präfix. Dieses Skript liest eine Datei mit IPs, nutzt den Batch-Endpunkt von ip-api (bis zu 100 IPs pro POST, 15 Anfragen pro Minute im kostenlosen Tarif) und RIPEstat und gibt eine Zeile pro Präfix aus:

import json, sys, time, urllib.request
from collections import defaultdict

def get(url, data=None):
    req = urllib.request.Request(url, data=data, headers={
        "User-Agent": "ip-audit/1.0", "Content-Type": "application/json"})
    with urllib.request.urlopen(req, timeout=20) as r:
        return json.load(r)

def ripestat(call, resource):
    return get(f"https://stat.ripe.net/data/{call}/data.json?resource={resource}")["data"]

ips = [l.strip() for l in open(sys.argv[1]) if l.strip()]

geo = {}
fields = "query,countryCode,isp,org,as,proxy,hosting,mobile"
for i in range(0, len(ips), 100):
    chunk = ips[i:i + 100]
    for row in get(f"http://ip-api.com/batch?fields={fields}", json.dumps(chunk).encode()):
        geo[row["query"]] = row
    time.sleep(4)  # unter 15 Batch-Anfragen/Minute bleiben

by_prefix = defaultdict(list)
for ip in ips:
    net = ripestat("network-info", ip)
    reg = ripestat("rir-stats-country", ip)["located_resources"]
    reg_cc = reg[0]["location"] if reg else "?"
    by_prefix[(net["prefix"], ",".join(net["asns"]))].append((ip, reg_cc, geo.get(ip, {})))

for (prefix, asns), rows in sorted(by_prefix.items()):
    hosting = sum(1 for _, _, g in rows if g.get("hosting"))
    proxy = sum(1 for _, _, g in rows if g.get("proxy"))
    mismatch = sum(1 for _, cc, g in rows if g.get("countryCode") and cc != g["countryCode"])
    print(f"{prefix:<20} AS{asns:<8} n={len(rows):<3} hosting={hosting} proxy={proxy} "
          f"reg!=geo={mismatch}  isp={rows[0][2].get('isp', '?')}")

Aufruf: python3 audit.py exits.txt. Bei einer großen Stichprobe fügen Sie zwischen den RIPEstat-Aufrufen eine kurze Pause ein. Die Ausgabe spricht meist sofort für sich. Häufen sich die markierten IPs in ein oder zwei Präfixen, haben Sie ein Präfix-Problem. Verteilen sie sich gleichmäßig über ein ASN, ist das ASN das Problem. Sind sie über viele saubere Präfixe verstreut, liegt es am Verhalten: Diese IPs sind bekannte Proxy-Exits.

Wie man Widersprüche zwischen Anbietern liest

Wenn Anbieter sich widersprechen, klären Sie zuerst, welche Ebene jeder liest, bevor Sie entscheiden, wer „recht“ hat. Meist liest einer die Registrierung und ein anderer das Routing oder das Verhalten.

• „ISP“ beim einen, „Hosting“ beim anderen. Registry gegen Routing. Prüfen Sie das announcende ASN. Ist es ein Hosting-Unternehmen, ist das Hosting-Urteil dasjenige, nach dem Websites handeln.
• Residentieller Verbindungstyp plus Proxy-Flag. Eine echte ISP-Adresse mit beobachteter Proxy-Aktivität. Am Routing lässt sich da nichts reparieren. Es ist ein Problem der Vorgeschichte.
• Überall sauber außer im Fraud Score eines Anbieters. Meist jüngste Abuse-Historie oder die Strictness-Einstellung. Prüfen Sie die Abuse-Felder des Anbieters, bevor Sie die IP abschreiben.
• Unterschiedliche Länder. Vergleichen Sie RIR-Land, Geofeed und die Geolocation der Anbieter. Die Anbieter aktualisieren unterschiedlich schnell, daher kann ein kürzlich umgezogener Block eine Weile widersprüchlich erscheinen.

Entscheidend ist, welchen Anbieter die Website nutzt, auf die es Ihnen ankommt, und das wissen Sie in der Regel nicht. Deshalb reicht das „sauber“ eines einzelnen Anbieters als Beleg nicht aus.

Die Signale im Überblick

Die Anbieter veröffentlichen ihre Gewichtungen nicht. Die Spalte „Gewichtung“ ist unsere Lesart ihrer Dokumentation und der Art, wie sich Urteile bei Audits verschieben. Verstehen Sie sie als Orientierung, nicht als Spezifikation.

Statisch vs. rotierend residentiell vs. mobil: was das Audit für Ihre Wahl bedeutet

Welches Produkt Sie kaufen, hängt davon ab, ob Sie dieselbe IP lange brauchen, und das entscheidet, wie wichtig ein Audit ist.

• Statische / ISP-IPs. Sie behalten jede IP wochenlang, also prüfen Sie vor der Zusage. Lassen Sie das Präfix-Skript über die angebotenen IPs laufen, lehnen Sie markierte /24s und Abweichungen zwischen Registry und Geo ab und fragen Sie, welches ASN sie announced. Hier zahlt sich das Audit am meisten aus.
• Rotierend residentiell. Einzelne IPs kommen und gehen, das Audit eines einzelnen Exits sagt also wenig. Nehmen Sie eine Stichprobe von 100+ Exits und sehen Sie sich die Verteilung der ASN-Typen und Hosting-Flags an. Ein „Residential“-Pool, in dem viele Exits aus Hosting-ASNs announced werden, ist nicht residentiell.
• Mobil. Mobilfunk-ASNs und CGNAT machen diese IPs am schwersten als Hosting markierbar, aber die Abuse-Historie teilen sie mit jedem echten Nutzer hinter derselben Adresse. Unser Leitfaden zu mobilen Proxys behandelt die Abwägungen, und Residential vs. Datacenter vs. Mobile vergleicht die drei.

Was dieses Audit nicht beantworten kann

Das Audit erklärt, warum ein Anbieter eine IP so einstuft, wie er es tut. Es sagt nicht vorher, ob eine bestimmte Website Sie blockiert. Websites kombinieren IP-Reputation mit TLS-, HTTP/2- und Browser-Fingerprints sowie mit Verhalten. Eine saubere residentielle IP hinter einem TLS-Fingerprint, der nach Rechenzentrum aussieht, wird trotzdem gechallengt. Das Audit sieht auch nicht die privaten Daten eines Anbieters, nur die öffentlichen Ebenen, auf denen diese Daten aufbauen. Nutzen Sie es, um schlechte IPs auszusortieren und Providern präzise Fragen zu stellen. Werten Sie ein sauberes Ergebnis nicht als Garantie.