Eine IP in 32 Blacklists: Warum günstige Proxys am Ende teurer sind

Du hast deinen Antidetect-Browser bis ins letzte Detail konfiguriert. Einzigartiger Canvas, ehrliches WebGL, saubere Schriften, getrennte Zeitzonen, leere Cookies. Trotzdem bekommt der Account bei jedem Schritt eine Captcha und nach einem Tag kommt der Ban. Kommt dir bekannt vor? Als Erstes schieben wir es auf den Fingerprint: Wir prüfen die Entropie, ändern die Browserversion, wechseln den User-Agent. Manchmal hilft das. Aber oft liegt das Problem auf einer ganz anderen Ebene, und die sollte man sich ansehen, bevor man sich in den Feinheiten des Fingerprints verliert.

Es gibt eine unangenehme Tatsache, die viele erst auf eigenen Kosten lernen. Eine Website kann sich eine Meinung über dich bilden, bevor sie deinen Browser überhaupt zu sehen bekommt. Nicht über Cookies, nicht über den Fingerprint, nicht über dein Verhalten. Nur über die IP-Adresse, von der die Anfrage kommt. Die Prüfung dauert Millisekunden und passiert in der frühesten Phase der Verbindungsverarbeitung. Wenn die Adresse als problematisch bekannt ist, ist es egal, wie sauber dein Profil konfiguriert ist.

In diesem Artikel schauen wir uns an, wie öffentliche Blocklisten funktionieren, warum günstige Proxys jahrelang darin landen, was einen mobilen IP grundlegend anders macht und wie du deine Adressen prüfst, bevor sie deine Accounts verbrennen. Wir schreiben sachlich, mit echten Zahlen und einem lebendigen Beispiel einer API-Antwort. Ohne Versprechen, bestimmte Plattformen zu umgehen, und ohne Superlative.

Warum der Ban kommt, bevor du denkst

Das typische Szenario sieht so aus: Du startest eine Session, öffnest die Zielseite und bekommst statt Content einen 403 oder eine endlose Captcha. Die Logik sagt, du solltest die Ursache in den frischen Browsereinstellungen suchen. Aber lass uns die Ereignisse der Reihe nach durchgehen.

Wenn der Browser eine Verbindung aufbaut, erhält der Server die Quell-IP-Adresse, bevor er auch nur ein Byte Inhalt ausliefert. In dieser Phase kann das Antifraud-System interne und externe Reputationslisten abgleichen. Viele dieser Listen sind öffentlich und werden täglich aktualisiert. Wenn deine Adresse dort steht, ist die Seite dir gegenüber bereits misstrauisch. Danach entwickelt sich das Geschehen auf einem von zwei Wegen.

• Erhöhtes Misstrauen. Dir wird eine Captcha gezeigt, die Häufigkeit deiner Aktionen wird eingeschränkt, du musst deine Telefonnummer bestätigen. Der Account lebt, aber jeder Schritt wird zum Kampf.
• Direkte Ablehnung. 403 am Einstieg, sofortige Blockierung der Registrierung, Shadowban des frisch erstellten Profils. Dein Browser wird gar nicht erst zur echten Interaktion zugelassen.

Der entscheidende Punkt: Der Fingerprint wird später geprüft. Zuerst kommt das Netzwerk. Und wenn du jahrelang deinen Fingerprint perfektionierst, aber Adressen aus dem allgemeinen Topf nimmst, optimierst du die zweite Stufe und scheiterst an der ersten. Daraus ergibt sich eine praktische Schlussfolgerung, zu der wir immer wieder zurückkehren werden: Die Reputation der IP muss vor der Nutzung geprüft werden, nicht nach dem ersten Ban.

Wie öffentliche Blocklisten funktionieren

Es gibt ein ganzes Ökosystem offener Feeds – regelmäßig aktualisierte Listen von IP-Adressen, gruppiert nach Bedrohungstyp. Ursprünglich wurden sie für die Netzwerksicherheit erstellt: Administratoren binden sie in ihre Firewalls ein, um Scanner, Spam-Bots und bekannte Angriffsquellen abzuwehren. Aber da die Listen öffentlich sind, nutzt sie jeder, auch das Antifraud der Zielseiten.

In diesem Ökosystem gibt es eine eigene Gruppe von Feeds, die genau offene Proxys, Anonymisierungs-Knoten und ähnliche Dienste katalogisiert. Nennen wir konkrete Dateien, damit die Diskussion konkret bleibt:

• firehol_proxies.netset – eine Sammelliste von Adressen, die als offene Proxys erkannt wurden.
• socks_proxy.ipset – Liste von SOCKS-Proxys, verfügbar in Zeitfenstern von 1, 7 und 30 Tagen.
• sslproxies.ipset – Verzeichnis der SSL-Proxys.
• tor_exits.ipset – Ausgangsknoten des Anonymisierungsnetzwerks.

Beachte die Zeitfenster von 1/7/30 Tagen bei socks_proxy. Das bedeutet, dass die Adresse nicht nur einmalig erfasst wird, sondern mit einer Historie. Selbst wenn der Proxy heute nicht mehr antwortet, taucht er im Wochen- und Monatsfenster noch auf. Für Antifraud ist das praktisch: Eine frische Markierung fängt aktive Adressen, historische Fenster blockieren die, die abwarten wollen.

Wir im Projekt IPGuardian aggregieren dieses Ökosystem vollständig. Aktuelle Zahlen für 2026: 162 Blocklisten-Quellen, 8 Kategorien, tägliche Aktualisierung. Die Kategorie „Anonymizer“ basiert auf 17 Quellen und enthält 4,88 Millionen Adressen – das ist die größte Kategorie in der Datenbank. Zum Vergleich: Die Kategorie Abuse umfasst etwa 1,6 Millionen Adressen, Attacks etwa 497.000. Anonymizer sind mehr als Abuse und Attacks zusammen.

Insgesamt über alle Kategorien sind das 7,11 Millionen einzelne IP-Adressen plus 356.000 Subnetze, was umgerechnet über 2,1 Milliarden abgedeckte Adressen ergibt. Die Update-Zuverlässigkeit liegt bei 94,4 % erfolgreichen Synchronisierungen pro Monat. Das ist keine abstrakte Zahlenshow, sondern die Datenmenge, mit der jeder abgeglichen wird, der offene Feeds in sein Antifraud integriert.

Demo: Adresse aus einer kostenlosen Liste

Theorie ist gut, aber schauen wir uns eine echte Antwort an. Wir nehmen eine Adresse, die in einer öffentlich zugänglichen Proxy-Liste steht, und prüfen sie. Der Abruf ist denkbar einfach:

curl -X POST https://ipguardian.net/api/check -H "Content-Type: application/json" -d '"1.20.254.32"'

Antwort (gekürzt):

• "found": true
• {"filename": "socks_proxy.ipset", "category": "anonymizers"}
• {"filename": "socks_proxy_7d.ipset", "category": "anonymizers"}
• {"filename": "firehol_proxies.netset", "category": "anonymizers"}
• {"filename": "stopforumspam.ipset", "category": "abuse"}

Schauen wir uns an, was wir sehen. Das Feld found: true sagt sofort: Die Adresse ist bekannt. Dann folgt die Liste der Quellen. Die ersten drei Zeilen sind zu erwarten – das sind Markierungen als Anonymizer. Die Adresse ist als SOCKS-Proxy im aktuellen und im Wochenfenster sowie in der Sammelliste offener Proxys gelistet. Keine Überraschung: Es ist tatsächlich ein Proxy aus einer offenen Liste.

Jetzt schau dir die letzte Zeile an. stopforumspam.ipset, Kategorie abuse. Das ist nicht mehr „Proxy“. Das ist eine Markierung als Spam-Quelle. Die Adresse ist in einer Datenbank gelandet, die Daten über Spam-Registrierungen und Missbrauch in Foren sammelt. Durch diese IP hat also jemand nicht nur anonym gesurft, sondern Aktionen durchgeführt, die als Missbrauch gekennzeichnet wurden.

Und genau hier beginnt der wichtigste Unterschied, für den es sich lohnt, weiterzulesen.

Zwei verschiedene Markierungen, zwei verschiedene Schicksale für den Account

Markierungen in Blocklisten sind nicht gleichwertig. Aus Sicht des Antifraud gibt es einen großen Unterschied zwischen „das ist ein Proxy“ und „das ist eine Quelle von Missbrauch“.

Markierung „als Proxy erkannt“

Die Kategorie Anonymizer sagt der Website: Die Verbindung läuft über einen Zwischenknoten, die wahre Herkunft ist verborgen. Die Reaktion ist normalerweise gedämpft – erhöhtes Misstrauen. Du bekommst eine Captcha, wirst um Bestätigung gebeten, Limits werden eingeschränkt. Unangenehm, aber man kann damit arbeiten. Viele legitime Nutzer surfen über Unternehmens-Gateways, und solchen Traffic komplett zu blockieren ist auch für die Website riskant.

Markierung „als Spam/Abuse erkannt“

Die Kategorien Abuse und Spam sind eine andere Sache. Hier sieht die Website nicht nur eine Verschleierung, sondern eine Historie schädlicher Aktionen von dieser Adresse. Die Reaktion ist härter: sofortige Blockierung, Ablehnung der Registrierung, Ban beim Einstieg. Die Logik ist simpel: Von dieser IP kam schon Schlechtes, warum das Risiko erneut eingehen?

Das Problem billiger Proxys ist, dass sie beide Markierungen gleichzeitig ansammeln. Über einen öffentlichen oder geteilten Proxy laufen jahrelang alle möglichen Leute: manche scrapen, manche spammen, manche registrieren Bot-Farmen, manche verschicken Müll in Foren. Jede dieser Aktionen hinterlässt Spuren, und die Adresse wird mit Markierungen aus verschiedenen Kategorien überhäuft.

Die schlechtesten Adressen in unserer Datenbank stehen gleichzeitig in 32 Listen – in den Kategorien Abuse, Anonymizer, Attacks und Spam. Stell dir vor, du nimmst so eine Adresse für einen neuen Account. Die Website sieht die Verbindung, gleicht in Millisekunden die Listen ab, entdeckt einen ganzen Strauß problematischer Markierungen und schließt die Tür, bevor dein perfekt konfigurierter Antidetect auch nur die erste Seite gerendert hat. Die Billigkeit des Proxys wird in diesem Moment zu einem verbrannten Account, verschwendeter Aufwärmzeit und, im Fall von Arbitrage, verlorenem Budget.

Was mobile IPs grundlegend anders macht

Jetzt zum entscheidenden Punkt – warum mobile Adressen anders funktionieren. Es geht nicht um Magie, sondern um die Architektur zellulärer Netzwerke.

Der Mobilfunkanbieter vergibt IP-Adressen an Teilnehmer über CGNAT. Hinter einer öffentlichen Adresse des Anbieters sitzen gleichzeitig hunderte echte Teilnehmer – normale Menschen mit Smartphones, die durch ihren Feed scrollen, für Dienste bezahlen, in Messengern schreiben und auf Marktplätzen einkaufen. Das ist echter menschlicher Traffic, vielfältig und legitim.

Daraus folgt das Wichtigste: Der Anbieter gibt seine Adresse nicht als offenen Proxy weiter. Sie steht nicht in socks_proxy.ipset, nicht in firehol_proxies.netset, nicht in den Anonymizer-Verzeichnissen – einfach weil es sich von Natur aus nicht um einen öffentlichen Proxy handelt. Scanner, die nach offenen Proxy-Ports suchen, finden eine solche Adresse nicht und nehmen sie nicht in die Listen auf.

Außerdem hat die Website einen starken wirtschaftlichen Anreiz, solche Adressen nicht komplett zu blockieren. Eine mobile IP des Anbieters zu blockieren bedeutet, hunderte echte Kunden abzuschneiden, die gerade dieselbe Adresse teilen. Für die Plattform ist das ein direkter Verlust von echten Nutzern und Geld. Deshalb geht Antifraud mit mobilen Adressen von vornherein vorsichtiger um.

Genau deshalb zeigen mobile Proxys eine andere Dynamik bei der Arbeit mit Accounts. Du bist mitten im echten Traffic, nicht in einem allgemeinen Topf von Anonymizern mit Missbrauchshistorie.

Wichtiger Hinweis: Mobile IP ist keine Rüstung

Hier müssen wir ehrlich sein, und dieser Hinweis stärkt den Artikel, statt ihn zu schwächen. Auch eine mobile IP kann in Spam- oder Abuse-Listen landen. Wenn jemand hinter derselben CGNAT-Adresse Mist gebaut hat – Spam verschickt, fremde Accounts gehackt, Malware-Aktivitäten gestartet – bekommt die Adresse eine Abuse-Markierung. Die Kategorie Anonymizer wird sie wahrscheinlich nicht treffen, aber Spam/Abuse sehr wohl.

Daraus folgt eine direkte praktische Schlussfolgerung, keine fromme Empfehlung wie „nimm mobile und schlaf ruhig“. Du brauchst zwei Dinge:

• Prüfung vor der Nutzung. Bevor du eine Adresse einsetzt, gleiche sie mit den Listen ab. Ob mobil oder nicht – wenn eine Abuse-Markierung darauf liegt, ist es besser, das vorher zu wissen als nach dem Ban.
• Rotation. Die Möglichkeit, die Adresse zu wechseln, wenn die aktuelle durch fremde Aktivitäten verschmutzt wurde. Mobile Netzwerke erlauben den IP-Wechsel, und das ist eine eingebaute Versicherung gegen Fehler anderer.

Kein Proxy-Typ gibt eine hundertprozentige Garantie. Der Unterschied liegt in den Wahrscheinlichkeiten und darin, ob du Kontrollwerkzeuge hast. Bei mobilen Adressen ist die Wahrscheinlichkeit, in den Anonymizer-Topf zu geraten, aus architektonischen Gründen nahezu null, und das Abuse-Risiko lässt sich durch Prüfung und Rotation steuern.

Praxis: So prüfst du deine Adressen

Kommen wir zum Nützlichsten – wie du die Reputationsprüfung in deinen Workflow einbaust. Die gute Nachricht: Für die Basisprüfung brauchst du weder Registrierung noch API-Schlüssel.

Einzelprüfung per curl

Das einfachste Szenario: eine Adresse prüfen, bevor du ein Profil startest:

1. Sende eine POST-Anfrage an den Endpunkt /api/check.
2. Im Body übergibst du die IP-Adresse als JSON-String.
3. Lies die Antwort: das Feld found und das Array sources mit Dateinamen und Kategorien.

Befehl:

curl -X POST https://ipguardian.net/api/check -H "Content-Type: application/json" -d '"DEINE_IP"'

Wenn found false ist, ist die Adresse in den bekannten Listen nicht vermerkt – ein gutes Zeichen. Wenn true, schaue, in welchen Kategorien. Eine Anonymizer-Markierung ist für viele Aufgaben tolerierbar, Abuse oder Spam ist ein Grund, die Adresse beiseitezulegen.

Paketprüfung für bis zu 100 Adressen

Wenn du einen Pool aus Dutzenden Adressen hast, ist die Einzelprüfung unpraktisch. Der Dienst akzeptiert bis zu 100 Adressen pro Anfrage. Die Antwortzeit beträgt 4–5 ms pro Adresse, der gesamte Pool von hundert wird also in Bruchteilen von Sekunden geprüft. So kannst du die Prüfung direkt in die Pipeline integrieren, ohne sie zum Flaschenhals zu machen.

Typischer Algorithmus für die Paketprüfung:

1. Sammle die Liste der Adressen, die du verwenden willst (bis zu 100 pro Anfrage).
2. Sende sie als eine POST-Anfrage an den Prüfendpunkt.
3. Analysiere die Antwort: Für jede Adresse gibt es found und die Liste der Quellen.
4. Filtere Adressen mit Abuse- und Spam-Markierungen heraus – die lassen wir nicht in die Arbeit.
5. Adressen mit sauberer Antwort oder nur mit leichten Markierungen gehen in die Rotation.

So liest du die Antwort

Drei Felder, die du wirklich brauchst:

• found – boolescher Wert. true bedeutet, dass die Adresse in mindestens einer Liste gefunden wurde.
• category – Bedrohungstyp. anonymizers, abuse, spam, attacks und andere. Anhand der Kategorie verstehst du die Schwere des Problems.
• filename – Name der konkreten Quelle. Nützlich, um zu verstehen, wie aktuell die Markierung ist. Zum Beispiel sagt socks_proxy.ipset im Vergleich zu socks_proxy_7d.ipset etwas über die Aktualität aus.

Anwendungsfälle: fünf praktische Szenarien

Schauen wir uns an, wie die Reputationsprüfung in konkrete Aufgaben passt. Für jedes Szenario – für wen, warum und wie.

Szenario 1: Vorabprüfung im Multi-Accounting

Für wen: alle, die Dutzende oder Hunderte Profile in Antidetect-Browsern führen.

Warum: verschmutzte Adressen vor der Account-Erstellung aussortieren, damit du keine aufgewärmten Profile an einem schlechten Netzwerk verbrennst.

Wie: Bevor du einen Proxy an ein Profil bindest, prüfe die Adresse. Wenn du Abuse oder Spam siehst – verwende diese Adresse nicht für einen wichtigen Account. Eine einfache Regel spart Stunden bei der Wiederherstellung nach Bans. Profi-Tipp: Halte ein kurzes Skript bereit, das die Adresse im Moment der Zuweisung prüft und problematische Markierungen hervorhebt.

Szenario 2: Pool-Hygiene fürs Scraping

Für wen: Spezialisten für Datenerfassung.

Warum: Adressen mit Anonymizer-Markierung bekommen häufiger Captchas, was die Scraping-Stabilität zerstört und die Kosten für die Captcha-Verarbeitung in die Höhe treibt.

Wie: Vor einer großen Session prüfe den gesamten Pool per Paketprüfung. Teile die Adressen in drei Gruppen: sauber (Priorität), mit leichten Markierungen (Reserve), mit Abuse/Spam (aussortieren). Arbeite hauptsächlich mit der sauberen Gruppe und halte die Anfragefrequenz in vernünftigen Grenzen.

Szenario 3: Debugging bei plötzlichem Anstieg von Bans in der Arbitrage

Für wen: Traffic-Arbitrageure.

Warum: Wenn eine Kombination plötzlich nicht mehr funktioniert, ist es wichtig, schnell zu wissen, ob es am Creative, am Account oder am Netzwerk liegt.

Wie: Bei einem Anstieg von Bans prüfe zuerst die Adressen. Wenn sie mit Abuse-Markierungen überhäuft sind, ist die Ursache gefunden – es liegt nicht an den Creatives. Das spart Budget, das sonst in endlose Anzeigentests geflossen wäre. Insider-Tipp: Protokolliere die Prüfhistorie, um zu sehen, wann genau die Adresse schlecht wurde.

Szenario 4: Abnahme neuer Proxys beim Anbieter

Für wen: alle, die Proxys einkaufen.

Warum: die Qualität des Pools vor der Zahlung oder direkt nach Erhalt des Zugangs prüfen.

Wie: Nachdem du einen Testzugang erhalten hast, prüfe die ausgegebenen Adressen per Paketprüfung. Ein hoher Anteil an Anonymizer- und Abuse-Markierungen im Pool ist ein Signal, dass du für den allgemeinen Topf zahlst. Das ist ein objektives Kriterium statt Verkaufsversprechen.

Szenario 5: Automatische Rotation nach Reputation

Für wen: Spezialisten für Automatisierung.

Warum: nicht nur nach Zeitplan wechseln, sondern wechseln, wenn sich die Reputation verschlechtert.

Wie: Integriere eine regelmäßige Prüfung der aktuellen Adresse in deine Pipeline. Sobald eine Abuse-Markierung auftaucht (z. B. weil ein fremder Teilnehmer hinter demselben CGNAT Mist gebaut hat) – initiiere die Rotation. Die Geschwindigkeit von 4–5 ms pro Adresse erlaubt das ohne Verzögerung im Hauptprozess.

Typische Fehler und wie du sie vermeidest

Hier sind häufige Fehler, die wir in der Praxis sehen.

• Adresse erst nach dem Ban prüfen. Zu diesem Zeitpunkt ist der Account bereits verloren. Die Prüfung muss vor dem Start erfolgen, nicht nach dem Tod.
• Mobile IP für unverwundbar halten. Wir haben es bereits besprochen: Eine Abuse-Markierung ist auch bei einer mobilen Adresse möglich. Prüfe auch mobile Pools.
• Den Dateinamen ignorieren. Eine Markierung im Wochenfenster und eine frische – das ist ein unterschiedlicher Aktualitätsgrad. Schau auf filename, nicht nur auf die Kategorie.
• Der Billigkeit des Pools hinterherjagen. Die Ersparnis bei Proxys wird durch Kosten für die Wiederherstellung nach Bans und verlorenes Testbudget zunichte gemacht. Rechne die Gesamtkosten.
• Kategorien nicht trennen. Anonymizer und Abuse erfordern unterschiedliche Reaktionen. Ersteres kann man manchmal tolerieren, Letzteres fast nie.

Kombinationen mit anderen Tools

Die Reputationsprüfung ersetzt nicht die restliche Hygiene, sie ergänzt sie. So fügt es sich zusammen:

• Antidetect-Browser + IP-Prüfung. Der Fingerprint deckt die verhaltensbezogene und technische Ebene ab, die IP-Prüfung die Netzwerkebene. Zusammen decken sie beide Phasen ab, in denen Antifraud dich bewertet.
• Profilverwaltungssystem + Paketprüfung. Weise Adressen nur nach der Reputationsfilterung zu. Die Prüfung von 100 Adressen pro Anfrage lässt sich leicht in diesen Schritt integrieren.
• Scraper + Rotation nach Reputation. Lass den Scraper nur saubere Adressen aus dem Pool erhalten, während verschmutzte automatisch aussortiert werden.

Vergleich der Ansätze: billiger Proxy vs. mobile IP mit Prüfung

Fassen wir den Unterschied in einem klaren Bild zusammen, ohne konkrete Wettbewerber zu nennen.

Geteilter oder öffentlicher Proxy

• Häufig in Anonymizer-Verzeichnissen (socks_proxy, firehol_proxies).
• Oft mit Abuse- und Spam-Markierungen wegen der Geschichte der Nutzung durch alle.
• Die schlechtesten Exemplare stehen gleichzeitig in 32 Listen.
• Billiger am Anfang, teurer am Ende wegen Bans und Captchas.

Mobile IP mit Reputationsprüfung

• Architektonisch nicht in den Verzeichnissen offener Proxys.
• Befindet sich im echten Teilnehmer-Traffic über CGNAT.
• Für die Website ist es nicht rentabel, sie komplett zu blockieren – dahinter stecken echte Kunden.
• Das Abuse-Risiko bleibt, lässt sich aber durch Prüfung und Rotation steuern.

Die Schlussfolgerung ist nicht, dass die eine Option „besser“ ist, sondern dass beim mobilen Ansatz die Wahrscheinlichkeiten andere sind und es Kontrollwerkzeuge gibt. Das ist der Unterschied zwischen Hoffnung und einem gesteuerten Prozess.

FAQ

Brauche ich eine Registrierung, um eine Adresse zu prüfen?

Für die Basisprüfung über die API sind keine Registrierung und kein Schlüssel erforderlich. Du sendest eine POST-Anfrage und liest die Antwort.

Wie viele Adressen kann ich pro Anfrage prüfen?

Bis zu 100 Adressen in einer Anfrage. Die Verarbeitungszeit beträgt 4–5 ms pro Adresse, der gesamte Pool wird in Sekundenbruchteilen geprüft.

Wie oft werden die Listen aktualisiert?

Täglich. Die Sync-Zuverlässigkeit über den Monat liegt bei 94,4 % erfolgreicher Updates. Insgesamt gibt es 162 Quellen und 8 Kategorien.

Was bedeutet found: true?

Die Adresse wurde in mindestens einer Liste gefunden. Schau dann in das sources-Array – dort stehen Kategorien und Dateinamen, um die Schwere des Problems zu verstehen.

Ist eine Anonymizer-Markierung ein Todesurteil?

Nein. Das ist ein Signal für erhöhtes Misstrauen: mögliche Captchas und Einschränkungen. Viel schwerwiegender sind Abuse- und Spam-Markierungen – sie führen häufiger zu einem direkten Ban.

Können mobile IPs in Blocklisten landen?

In Verzeichnisse offener Proxys praktisch nicht – das ergibt sich aus der Architektur zellulärer Netzwerke. Aber in Spam-/Abuse-Listen kann eine mobile Adresse sehr wohl landen, wenn jemand hinter demselben CGNAT Missbrauch betrieben hat. Deshalb sind Prüfung und Rotation auch hier nötig.

Warum ist ein billiger Proxy am Ende teurer?

Durch geteilte Adressen laufen jahrelang alle möglichen Leute, sie sammeln Markierungen aus verschiedenen Kategorien. Ein gebannter Account, verlorene Aufwärmzeit und verlorenes Testbudget kosten mehr als der Preisunterschied beim Proxy.

Wie integriere ich die Prüfung in die Automatisierung?

Sende eine Paketanfrage bei der Zuweisung von Adressen an Profile und prüfe aktive Adressen regelmäßig erneut. Sobald eine Abuse-Markierung auftaucht, initiiere die Rotation.

Was ist wichtiger – Fingerprint oder IP-Reputation?

Beides ist wichtig, aber sie werden in verschiedenen Phasen geprüft. Die IP-Reputation wird früher bewertet, bevor der Browser gerendert wird. Ein perfekter Fingerprint hilft nicht, wenn die Adresse bereits auf Blacklists steht.

Wie viele Adressen sind in der Datenbank abgedeckt?

7,11 Millionen einzelne IPs plus 356.000 Subnetze, was umgerechnet über 2,1 Milliarden abgedeckte Adressen ergibt. Die größte Kategorie sind Anonymizer mit 4,88 Millionen Adressen.

Fazit: Womit du anfangen solltest

Setzen wir das Bild zusammen. Ein Account-Ban ist nicht immer eine Geschichte über den Fingerprint. Oft liegt die Ursache in der Reputation der IP selbst, die der Website vor der ersten Anfrage bekannt ist. Öffentliche Feeds katalogisieren offene Proxys und Anonymizer, und die Missbrauchshistorie fügt den Adressen Abuse- und Spam-Markierungen hinzu. Billige Proxys sammeln beide Arten von Markierungen, und die schlechtesten von ihnen stehen gleichzeitig in 32 Listen.

Mobile IPs funktionieren anders: Hinter der CGNAT-Adresse eines Anbieters sitzen hunderte echte Teilnehmer, eine solche Adresse landet nicht in Verzeichnissen offener Proxys, und sie komplett zu blockieren ist für die Website unrentabel. Aber auch eine mobile Adresse ist keine Rüstung – eine Abuse-Markierung ist auch hier möglich. Deshalb ist die Arbeitspraxis unabhängig vom Proxy-Typ dieselbe: Reputation vor der Nutzung prüfen und bei Verschlechterung rotieren.

Für wen ist das besonders wichtig: Spezialisten für Multi-Accounting, Scraping, Automatisierung und Arbitrage – alle, die mit Adresspools arbeiten und für jeden verbrannten Account Zeit und Geld zahlen.

So startest du sofort:

1. Nimm die Adressen, die du verwendest, und prüfe sie über die API – ohne Registrierung und Schlüssel. Eine einzelne Adresse per curl oder ein Paket von bis zu 100 Adressen pro Anfrage.
2. Filtere Adressen mit Abuse- und Spam-Markierungen heraus. Bewerte, wie viele aus deinem Pool tatsächlich problematisch sind.
3. Baue den Prozess so auf, dass nur geprüfte Adressen in die Arbeit gehen und verschmutzte in die Rotation wandern.

Wenn du keine eigene Lösung aus einzelnen Tools zusammenbauen möchtest, ist die Reputationsprüfung bereits in mobileproxy.space integriert. Du erhältst mobile Adressen und die Möglichkeit, sie im selben Arbeitsablauf gegen die Listen zu prüfen – als fertige Lösung genau für die Aufgabe, mit der wir begonnen haben: das Problem vor dem Ban zu erkennen, nicht danach.