Die Architektur, auf die die meisten Scraping-Systeme zulaufen, sieht so aus: Container bei einem Cloud-Anbieter, skaliert nach Warteschlangentiefe, zustandslos und wegwerfbar. Das ist das richtige Design für die Rechenleistung. Es ist das denkbar schlechteste Design für den Egress, denn die Adressen, die diese Container erhalten, sind das Erste, was eine geschützte Website prüft.
Cloud-Provider-Bereiche sind veröffentlicht. Jeder kann sie auflisten, und die meisten Anti-Bot-Anbieter tun das auch. Traffic von dort wird nicht wegen dessen blockiert, was er getan hat, sondern nach seiner Herkunft bewertet, bevor der erste Request überhaupt abgeschlossen ist. Die Lösung sind nicht mehr Worker oder bessere Header. Es geht darum, zu trennen, wo der Code läuft, von dort, wo der Traffic austritt.
Die Egress-Schicht ist ein eigenes Thema
Das nützliche mentale Modell ist: Ihre Worker sind Rechenleistung, Ihre Adressen sind Identität, und diese sollten unabhängig voneinander skalieren.
Kurzlebige Worker sind gut: fünfzig starten, die Warteschlange abarbeiten, stoppen. Kurzlebige Identitäten sind meist schlecht: Jeder neue Worker, der von einer neuen Cloud-Adresse ankommt, ist ein Strom unbekannten Traffics. Was Sie wollen, ist ein stabiler Satz von Exit-Adressen, der über Worker-Generationen hinweg bestehen bleibt, sodass die Identität, die Ihre Ziele sehen, sich nicht jedes Mal ändert, wenn Ihr Autoscaler reagiert.
ISP-Proxys passen genau deshalb in diese Rolle, weil sie fest sind. Jede Adresse ist für die Laufzeit des Plans Ihrem Konto zugeordnet, bei einem echten ISP registriert statt in einem Cloud-Block, und rotiert nicht. Ihre Worker kommen und gehen; die Adressen bleiben.
Zwei Auth-Modi, und die Wahl ist architekturbedingt
Jede Adresse in einem Plan nutzt denselben Port (1337), mit zwei Möglichkeiten zur Authentifizierung. In einem Cloud-Deployment ist das keine Präferenz, sondern ergibt sich aus Ihrem Netzwerk.
Autorisierte Quell-IP. Sie tragen die öffentliche Adresse Ihrer Infrastruktur im Panel in die Whitelist ein und verbinden sich ohne Zugangsdaten:
185.199.108.153:1337Das funktioniert, wenn Ihr Egress vorhersehbar ist, was in der Praxis ein NAT-Gateway oder Ähnliches mit einer stabilen Adresse vor Ihren Workern bedeutet. Es ist die sauberere Option, wo sie anwendbar ist, weil überhaupt keine Zugangsdaten in Ihren Containern liegen.
Benutzername und Passwort. Funktioniert von überall, keine Whitelist nötig:
185.199.108.153:1337:USERNAME:PASSWORDDas ist die richtige Wahl, wenn Worker tatsächlich kurzlebig sind über wechselnde Adressen hinweg, oder über Regionen verteilt sind, oder in einer Umgebung laufen, in der Sie die ausgehende Adresse nicht kontrollieren. Serverless-Funktionen und Multi-Region-Deployments landen hier.
Die Falle besteht darin, sich für Quell-IP-Auth in einer Umgebung zu entscheiden, in der die Quelladresse tatsächlich nicht fest ist. Es funktioniert beim Testen von einem Subnetz aus und schlägt dann in der Produktion sporadisch fehl, sobald die Plattform anders zuweist. Wenn Sie Ihre Egress-Adresse nicht mit Sicherheit angeben können, verwenden Sie Zugangsdaten.
Verteilung der Adressen auf Worker
Sie haben N Adressen und eine variable Anzahl von Workern, also muss etwas die eine der anderen zuordnen.
Der Ansatz, der sich bewährt, besteht darin, die Adressliste als gemeinsame Ressource mit expliziten Leases zu behandeln, statt jeden Worker selbst wählen zu lassen. Ein Worker nimmt eine Adresse aus einer Koordinationsschicht, hält sie für die Dauer seines Jobs und gibt sie zurück. Zwei Eigenschaften sind wichtig: Keine zwei Worker nutzen gleichzeitig eine Adresse in einer Weise, die ihre scheinbare Request-Rate verdoppelt, und ein Worker-Absturz entfernt eine Adresse nicht dauerhaft aus dem Umlauf.
Die naive Alternative, das Hashen der Worker-Identität auf einen Index, bricht in dem Moment zusammen, in dem sich Ihre Worker-Anzahl ändert, was bei einem autoskalierten Deployment ständig geschieht. Sie bekommen Kollisionen beim Hochskalieren und ungenutzte Adressen beim Herunterskalieren.
Die Request-Rate pro Adresse ist hier das eigentliche Budget. Die Bandbreite bei ISP-Plänen ist unbegrenzt, die Beschränkung liegt also nicht in Gigabyte, sondern darin, wie viel Traffic eine feste Adresse plausibel erzeugen kann. Diese Zahl bestimmt, wie viele Adressen Ihr Deployment benötigt, und deshalb ist die Dimensionierung nach Durchsatz statt nach Datenvolumen die richtige Übung.
Health-Checks gehören in den Pool
Adressen fallen nicht gleichmäßig aus. Eine kann anfangen, von einem bestimmten Ziel Challenges zu erhalten, während alles andere in Ordnung ist, und ein Worker, der diese Adresse bekommt, produziert Müll, bis es jemandem auffällt.
Verfolgen Sie Ergebnisse pro Adresse statt aggregiert. Eine Erfolgsrate pro Adresse über ein rollierendes Fenster, pro Ziel, wenn Sie von mehreren sammeln, gibt Ihnen die Möglichkeit, eine einzelne Adresse unter Quarantäne zu stellen, ohne den gesamten Pool herauszuziehen. Aggregierte Metriken zeigen Ihnen einen Rückgang um fünf Prozent und verbergen die Tatsache, dass eine einzelne Adresse vollständig ausfällt.
Die Quarantäne sollte vorübergehend und automatisch sein, mit einer Prüfung, die die Adresse zurückgibt, sobald sie sich erholt hat. Die Methode, um überhaupt erst festzustellen, wie normal aussieht, findet sich unter Testen von Proxy-Geschwindigkeit, Erfolgsrate und Standortgenauigkeit.
Geografie vor dem Kauf planen
Ein Detail, das Cloud-Teams überrascht: Bei ISP-Plänen wählen Sie die Länderverteilung einmal, bevor die Adressen bereitgestellt werden, und sie kann danach nicht mehr geändert werden. Sieben Länder stehen zur Verfügung.
Das unterscheidet sich von fast allem anderen in einem Cloud-Deployment, wo Sie es gewohnt sind, Ihre Meinung günstig zu ändern. Entscheiden Sie die Aufteilung anhand der Ziele, von denen Sie tatsächlich sammeln, und wenn Sie sich zwischen zwei Märkten unsicher sind, kaufen Sie den Plan, bei dem Sie sich sicher sind, und ergänzen Sie, statt zu raten.
Wenn ISP das falsche Werkzeug ist
Statische Adressen sind kein allgemeiner Ersatz für Rotation, und Cloud-Infrastruktur macht es verlockend, das Gegenteil vorzugeben, weil das operative Modell so viel einfacher ist.
Wenn Ihre Arbeitslast eine hochvolumige Sammlung über viele Ziele hinweg ist, wird die Request-Rate pro Adresse lange bevor die Kosten es tun unplausibel, und das Symptom ist verschlechterte Daten statt Fehler. Diese Arbeit gehört auf rotierende Residential-Proxys, bei denen jeder Request per Design von einer anderen Adresse kommen kann. Der Kompromiss wird dargelegt in ISP-Proxys vs. Datacenter und Residential.
Die Arbeitslasten, bei denen eine feste Egress-Schicht wirklich richtig ist: langlebige Sessions, alles Authentifizierte, Ziele, die Ihre Adressen auf eine Allowlist setzen, Partner-APIs, die eine bekannte Quelle erwarten, und stetige Sammlung, bei der Konsistenz wichtiger ist als Volumen. Die gemischte Architektur ist üblich und richtig, mit ISP-Adressen für die dauerhafte Arbeit und einem rotierenden Gateway für das Massengeschäft.
Betriebliche Hinweise
Halten Sie die Adressliste in der Konfiguration, nicht in Images. Container neu zu bauen, um den Pool zu ändern, ist vermeidbar. Lesen Sie sie beim Start aus Ihrem Secret Store oder Config-Service.
Loggen Sie nicht die URL mit den Zugangsdaten. Das ist der mit Abstand häufigste Weg, wie Proxy-Zugangsdaten in einen Log-Aggregator gelangen, weil die naheliegende Debug-Zeile der gesamte Verbindungsstring ist.
Begrenzen Sie die Nebenläufigkeit pro Adresse, nicht nur global. Ein globales Limit, das ungleichmäßig auf einen kleinen Pool verteilt ist, konzentriert die Last auf die Adressen, die Ihre Zuweisungslogik bevorzugt. Die relevante Mechanik findet sich unter Rate Limiting und Request Throttling.
Testen Sie von innerhalb des Deployments. Ein Konnektivitätstest von einem Laptop aus beweist, dass Ihre Zugangsdaten funktionieren. Er beweist nichts darüber, ob Ihre Task-Definition die Umgebungsvariablen durchreicht, was in den meisten Fällen der tatsächliche Fehler ist.
FAQ
Kann ich ISP-Proxys von Serverless-Funktionen aus nutzen?
Ja, mit Credential-Auth. Whitelisting per Quell-IP ist dort unpraktisch, weil die ausgehende Adresse nicht von Ihnen festgelegt werden kann.
Wie viele Adressen benötigt ein autoskaliertes Deployment?
Dimensionieren Sie nach Peak-gleichzeitigen Jobs und einer konservativen Request-Rate pro Adresse, nicht nach Worker-Anzahl. Worker leerlaufen; die Adressen sollten nicht das sein, was bei Spitzenlast ausgeht.
Wird die Proxy-Schicht zum Flaschenhals?
ISP-Adressen laufen auf Datacenter-Infrastruktur mit Gigabit-Geschwindigkeiten, daher ist der Durchsatz pro Adresse selten die Grenze. Die Concurrency-Policy bindet meist zuerst.
Sollte jeder Service eigene Adressen bekommen?
Wenn sich ihre Traffic-Muster wesentlich unterscheiden, ja. Einen stetigen Service mit niedriger Rate mit einem stoßweisen auf derselben Adresse zu mischen, bedeutet, dass der stoßweise bestimmt, wie beide behandelt werden.
Fazit
Cloud-Scraping-Infrastruktur wird aus einem Grund blockiert, der nichts mit der Qualität des Codes zu tun hat: Die Adressen sind als Cloud-Adressen veröffentlicht. Eine feste ISP-Egress-Schicht vor kurzlebige Worker zu setzen, trennt Identität von Rechenleistung, was ohnehin die Trennung war, die die Architektur brauchte.
Leasen Sie Adressen explizit, verfolgen Sie den Zustand pro Adresse, dimensionieren Sie nach Request-Rate statt Bandbreite, und entscheiden Sie die Geografie vor dem Kauf, denn diese Wahl ist dauerhaft. Pläne finden sich auf der Preisseite für ISP-Proxys.