Roterende proxy’s uitgelegd: hoe IP-rotatie werkt en wanneer je taak vastloopt

Een prijscontrolescript bezocht maandenlang probleemloos elke nacht enkele honderden productpagina’s. Toen ging de frequentie omhoog, kwam er een tweede winkel bij en verschenen 429-antwoorden en CAPTCHA’s in de logs. Forums adviseren meestal een roterende proxy. Meer IP-adressen, minder blokkades: dat klopt maar half.

Een roterende proxy verstuurt verzoeken via wisselende IP’s achter een vaste gateway. Zo blijft het verkeer per IP onder een limiet. Maar het adres kan ook tijdens aanmelden wisselen, wat een aangemelde sessie vaak niet overleeft. Rotatie lost een probleem op en veroorzaakt een ander.

De korte versie

• Een roterende proxy biedt één gateway met host en poort en stuurt verzoeken via IP’s uit een pool. Een regel bepaalt wanneer het uitgaande IP wisselt.
• Rotatie per verzoek past bij toestandloze taken zoals openbare pagina’s ophalen. Gebruik voor aanmelden en winkelwagens liever sticky sessions of een statische proxy, zeker bij controle op IP-continuïteit.
• Een correct roterende pool kan alsnog falen doordat andere klanten de reputatie van gedeelde IP’s aantasten. Verse, weinig gedeelde adressen zeggen meer over succes dan poolgrootte.
• Rotatie helpt niet tegen limieten per account, token of cookie. Vertraag kleine taken eerst en respecteer Retry-After, dat de wachttijd aangeeft.

Wat is een roterende proxy?

De gateway stuurt elk verzoek via een gekozen pool-IP. De regel wisselt per verzoek, op tijd of per sessie. Host en poort blijven gelijk; de gateway bepaalt welk adres het doel ziet.

Volg een verzoek door de gateway:

1. De client verstuurt altijd naar dezelfde host en poort van de gateway.
2. De gateway past de regel toe en kiest een uitgaand IP.
3. Het verzoek vertrekt vanaf dat IP en bereikt de doelwebsite.
4. Het doel ziet het uitgaande IP. Je eigen adres blijft verborgen, tenzij de gateway het doorgeeft via een header zoals X-Forwarded-For.

De aanbieder beheert pool, gezondheidscontroles en failover; je script kent alleen host en poort. Dat gemak verklaart de dienst. Zelf een proxy draaien levert geen gratis rotatie op: meestal krijg je één stabiel uitgaand IP. Voor het onderhouden van de pool zou je iemand betalen.

Aanbieders noemen gateway plus pool een backconnectproxy. MDN’s handleiding voor proxyservers noemt gateway als andere, eenvoudigere naam voor een forwardproxy. Of de IP’s residentieel, uit datacenters of mobiel zijn, staat los van hun wisselfrequentie.

Wat bepaalt wanneer een roterende proxy je IP wisselt?

De regel en aanbieder bepalen dit: per verzoek of verbinding, binnen een tijdvenster of na een expliciet commando. Client of proxybeheerder kan ook vóór een nieuwe poging wisselen. Controleer ‘per verzoek’: meerdere HTTPS-verzoeken kunnen dezelfde tunnel en IP delen. Een gateway die versleuteld HTTPS doorstuurt kan normaal de antwoordcode niet lezen om zelf rotatie te activeren.

Dit is een verdelingskeuze. Spreiding houdt elk IP onder de grens; continuïteit laat het doel één bezoeker herkennen. Rotatie per verzoek kiest geheel voor spreiding. Wisselen bij fouten lijkt een veerkrachtig compromis, maar verbergt kosten: logs tonen geslaagde herhalingen totdat niets meer lukt. Een sticky session keert de afweging om door één IP tijdelijk vast te houden.

Hoe verschilt een sticky session van rotatie of een statische proxy?

Een sticky session leent tijdelijk een pool-IP zodat verzoeken op één bezoeker lijken, en geeft het daarna vrij. Een statische proxy houdt een vast IP zolang je hem behoudt. Rotatie per verzoek reserveert niets. Kies op basis van de behoefte aan herkenning tussen verzoeken.

Rotatie per verzoek is gebruikelijk voor toestandloze taken. Voor aanmelden blijven de twee vasthoudende opties; duur bepaalt de keuze. Sticky sessions lenen en retourneren een pooladres; statische proxy’s blijven toegewezen. Dagelijks hetzelfde aanmeldadres lijkt op een terugkerende gebruiker. Vergelijk het aanbiedersvenster met je langste proces. Controleer uitval: sommige aanbieders wisselen voortijdig, strikte enkel-IP-modi laten het verzoek falen. Een lang venster garandeert geen continuïteit.

Wanneer breekt IP-rotatie een taak?

Wisselen tijdens aanmelden, 2FA, winkelwagen, afrekenen of meerstapsformulieren kan het proces breken. Cookies worden niet vanzelf ongeldig door een IP-wissel. Maar IP-gebonden sessies of fraudedetectie bij netwerkwissels kunnen afmelden, opnieuw uitdagen of markeren.

Ik zie dit als de website die haar werk doet, niet als het viseren van proxy’s. Het cookie beweert dezelfde browser te zijn als een minuut geleden; de IP is controleerbaar bewijs. Een netwerkwissel binnen een aangemelde sessie lijkt op een elders hergebruikt gestolen cookie, precies wat fraudedetectie zoekt. Afmelden en 2FA zijn evenredige reacties.

OWASP’s richtlijnen voor sessiebeheer beschrijven controle op veranderende clienteigenschappen zoals IP en User-Agent. Afhankelijk van de controles kan een onverwachte wissel een waarschuwing of sessiebeëindiging veroorzaken.

Moet het doel je tussen verzoeken onthouden? Houd dan één IP vast; anders kun je roteren. Nachtelijke controles van openbare prijzen vereisen dat niet. Aanmelden bij een dashboard voor rapportexport wel, van begin tot eind.

Praktijktip: Splits gemengde taken: een roterende pool voor toestandloze data, een sticky of statisch IP voor aanmelden en aangemelde acties. Tegengestelde behoeften horen niet onder één regel.

Waarom stopt een roterende pool na enkele dagen?

Ook correcte rotatie kan falen: ze verandert de IP, niet de reputatie. Gedeelde adressen erven eerder gebruik; veel hergebruik bij dezelfde doelen kan markeringen en lagere slagingspercentages opleveren.

Een gedeelde pool is een beperkte gemeenschappelijke hulpbron. Elke klant verbruikt reputatie bij websites. Gebruiken anderen dezelfde adressen bij jouw doelen, dan betaal jij met CAPTCHA’s en blokkades. In support zag ik IP-reputatie als een ecosysteem van sites en blokkeerlijsten die op waargenomen verkeer reageren.

Poolgrootte is makkelijk te adverteren maar voorspelt minder dan verwacht. Succes hangt af van:

• Recent gebruik bij hetzelfde doel: een adres dat een andere klant een uur geleden gebruikte, is al meegeteld.
• Aantal gebruikers: meer taken per adres zorgen voor sneller slijten.
• Netwerkdiversiteit: adressen in enkele bereiken kunnen samen worden geblokkeerd.
• Bestaande markeringen: een pool die misbruikadressen behoudt, blijft ze uitdelen.

Een grote, sterk hergebruikte pool kan slechter presteren dan een kleine met verse adressen voor jouw doelen. Vergelijk succes over langere tijd; een eerste geslaagde test bewijst geen blijvende prestatie.

Heb je wel een roterende proxy nodig?

Hij kan verkeer onder IP-limieten verdelen maar vervangt het naleven van limieten en herhaalregels niet. Volgens MDN’s 429-referentie gelden limieten meestal per IP, maar bij authenticatie of cookies ook per gebruiker of toepassing. Accountlimieten negeren nieuwe IP’s; kleine taken moeten eerst Retry-After volgen.

De standaard is RFC 6585, die statuscode 429 definieerde. Een 429 mag Retry-After met de wachttijd bevatten; gebruikersherkenning en tellen blijven vrij. Als voorbeeld noemt hij authenticatiegegevens of een toestandhoudend cookie.

Drie verkeerde aankopen: een account-, API-token- of cookielimiet, waarbij alle IP’s hetzelfde quotum verbruiken en 429 blijft; een kleine taak die honderden nachtelijke pagina’s kan spreiden, Retry-After afwachten en gratis opnieuw proberen met exponentiële back-off; en aangemelde taken die een stabiele identiteit en vast IP nodig hebben.

Rotatie past bij IP-limieten, volumewaarde en onafhankelijke verzoeken binnen toegestaan gebruik. De gebruiksvoorwaarden blijven gelden. Sites beoordelen ook de clientidentificatie op verbindingsniveau en het verzoektempo: rotatie alleen garandeert geen toegang.

Lees vóór betaling de documentatie en antwoordheaders. Krijgen vergelijkbare aangemelde verzoeken 429 terwijl anonieme vanaf hetzelfde adres slagen, dan suggereert dat een account- of authenticatielimiet, zonder bewijs. Falen beide, dan kan de grens per IP, bron of hele server gelden. Houd endpoint en frequentie vergelijkbaar en volg Retry-After voordat je opnieuw test.

Veelgestelde vragen