Roterende proxyer: Sådan virker IP-rotation, og hvornår den afbryder dit job

Et prisovervågningsscript tjekkede hundredvis af produktsider hver nat uden problemer i månedsvis. Så steg frekvensen, en ekstra butik kom til, og loggene blev fyldt med 429-svar og CAPTCHA’er. På fora anbefales en roterende proxy. Flere IP’er giver færre blokeringer, men det er kun halvt rigtigt.

En roterende proxy sender forespørgsler gennem skiftende IP’er bag en fast gateway. Det fordeler trafikken under en grænse pr. IP. Adressen kan dog skifte under login, hvilket en autentificeret session ofte ikke overlever. Rotation løser et problem og skaber et andet.

Den korte version

• En roterende proxy tilbyder én gateway med vært og port, videresender gennem IP’er fra en pulje og bruger en regel til at bestemme skiftet.
• Rotation pr. forespørgsel passer til tilstandsløse job som hentning af offentlige sider. Brug sticky session eller statisk proxy til login og kurve, især når siden tjekker IP-kontinuitet.
• En pulje kan rotere korrekt og stadig fejle: Andre kunder slider på delte IP’ers omdømme. Friske, mindre delte adresser siger mere om succes end puljens størrelse.
• Rotation hjælper ikke mod grænser pr. konto, token eller cookie. Ved små job skal du først sænke tempoet og følge Retry-After, som angiver ventetiden.

Hvad er en roterende proxy?

Gatewayen videresender hver forespørgsel gennem en pulje-IP. Reglen skifter pr. forespørgsel, efter tid eller pr. session. Vært og port er altid ens; gatewayen vælger adressen, målet ser.

Følg en forespørgsel gennem gatewayen:

1. Klienten sender altid til gatewayens samme vært og port.
2. Gatewayen anvender reglen og vælger en udgående IP.
3. Forespørgslen forlader denne IP og når målsiden.
4. Målet ser den udgående IP. Din egen adresse skjules, medmindre gatewayen sender den videre i en header som X-Forwarded-For.

Udbyderen håndterer pulje, helbredstjek og failover; dit script kender kun vært og port. Denne bekvemmelighed forklarer tjenesten. Egen proxy giver ikke gratis rotation: Den giver normalt én stabil udgående IP; det er driften af puljen, du ville betale for.

Udbydere kalder gateway plus pulje en backconnect-proxy. MDN’s guide til proxyservere bruger gateway som et andet, enklere navn for en forward-proxy. Om IP’erne er residential-, datacenter- eller mobiladresser, er uafhængigt af skiftefrekvensen.

Hvad bestemmer, hvornår proxyen skifter din IP?

Regel og udbyder bestemmer: pr. forespørgsel eller forbindelse, fast tidsvindue eller eksplicit kommando. Klient eller proxyadministrator kan også skifte før genforsøg. Tjek betydningen af »pr. forespørgsel«: Flere HTTPS-forespørgsler kan dele tunnel og IP. En gateway, der videresender krypteret HTTPS, kan normalt ikke læse målets statuskode og selv udløse rotation.

Tabellen viser en fordelingsbeslutning. Spredning holder hver IP under grænsen; kontinuitet gør én besøgende genkendelig. Rotation pr. forespørgsel satser alt på spredning. Rotation ved fejl virker som et modstandsdygtigt kompromis, men skjuler omkostningerne: Loggene viser vellykkede genforsøg, indtil intet lykkes. En sticky session vender kompromiset og holder én IP i et tidsvindue.

Hvordan adskiller sticky sessions sig fra rotation og statiske proxyer?

En sticky session låner midlertidigt en pulje-IP, så forespørgsler ligner én besøgende, og frigiver den bagefter. En statisk proxy holder en fast IP, så længe du beholder den. Rotation pr. forespørgsel reserverer intet. Vælg efter behovet for genkendelse mellem forespørgsler.

Rotation er normalt til tilstandsløse hentninger. Ved login er de to fastholdende valg relevante, og varigheden afgør valget. Sticky sessions låner og returnerer puljeadresser; statiske proxyer forbliver tildelt. Dagligt login fra samme adresse ligner en tilbagevendende bruger. Sammenlign udbyderens vindue med dit længste forløb. Tjek udfald: Nogle skifter før tid, mens strenge enkelt-IP-tilstande lader forespørgslen fejle. Et langt vindue alene garanterer ikke kontinuitet.

Hvornår afbryder IP-rotation et job?

Skift under login, 2FA, kurve, betaling og flertrinsformularer kan afbryde forløbet. Cookies bliver ikke automatisk ugyldige ved IP-skift. Men IP-bundne sessioner og svindelkontrol af netværksskift kan udløse logout, ny kontrol eller markering.

Jeg ser det som siden, der gør sit arbejde, ikke som målretning mod proxyer. Cookien hævder at være samme browser som for et minut siden; IP’en giver kontrollerbart bevis. Netværksskift i en autentificeret session ligner genbrug af en stjålet cookie et andet sted, netop hvad svindelsystemer opdager. Logout og 2FA er rimelige svar.

OWASP’s vejledning om sessionsstyring beskriver kontrol af ændringer i IP og User-Agent. Afhængigt af sikkerheden kan uventede skift udløse alarm eller afslutte sessionen.

Skal siden huske dig mellem forespørgsler? Hold én IP gennem forløbet; ellers kan du rotere. Natlig kontrol af offentlige priser kræver det ikke. Login på et dashboard til rapporteksport kræver én IP fra start til slut.

Praktisk tip: Del blandede job: roterende pulje til tilstandsløse data og sticky eller statisk IP til login og autentificeret arbejde. Modsatte behov bør ikke dele regel.

Hvorfor stopper en roterende pulje efter få dage?

Selv korrekt rotation kan fejle: Den ændrer IP’en, ikke omdømmet. Delte adresser arver tidligere aktivitet; stærk genbrug mod samme mål kan føre til markeringer og lavere succes.

Puljen er en begrænset fælles ressource. Hver kunde bruger dens omdømme hos siderne. Bruger andre samme adresser mod dine mål, betaler du med CAPTCHA’er og blokeringer. I support har jeg set IP-omdømme fungere som et økosystem af sider og bloklister, der reagerer på observeret trafik.

Puljestørrelse er let at reklamere med, men forudsiger mindre end ventet. Succes afhænger af:

• Seneste brug mod samme mål: En adresse brugt af en anden kunde for en time siden er allerede talt med.
• Antal kunder: Flere job slider hurtigere på adressen.
• Netværksvariation: Adresser i få intervaller kan blokeres samlet.
• Eksisterende markeringer: Puljer, der beholder misbrugsmarkerede IP’er, uddeler dem stadig.

En stor, stærkt genbrugt pulje kan klare sig dårligere end en lille med friske adresser til dine mål. Sammenlign succes over tid; en vellykket første test beviser ikke varig ydelse.

Har du overhovedet brug for en roterende proxy?

Den kan fordele forespørgsler under IP-grænser, men erstatter ikke overholdelse af grænser og genforsøgsregler. Ifølge MDN’s 429-reference gælder grænser typisk IP’er, men ved autentificering eller cookies også brugere eller programmer. Kontogrænser ignorerer nye IP’er; små job skal først følge Retry-After.

Standarden er RFC 6585, som definerede statuskode 429. Den tillader Retry-After med ventetiden uden at fastlægge brugeridentifikation eller optælling. Eksemplet nævner loginoplysninger eller en tilstandsbevarende cookie.

Tre forkerte køb: Konto-, API-token- eller cookiegrænser, hvor alle IP’er bruger samme kvote og 429 fortsætter; små job, der gratis kan sprede hundredvis af natlige sider, vente på Retry-After og gentage med eksponentiel ventetid; autentificerede job, der kræver stabil identitet og fast IP.

Rotation passer ved IP-grænser, volumenafhængig værdi og uafhængige forespørgsler inden for tilladt brug. Sidens vilkår gælder stadig. Siden vurderer også klientidentifikation på forbindelsesniveau og tempoet. Rotation alene garanterer ikke adgang.

Læs dokumentation og svarheadere før køb. Får sammenlignelige autentificerede forespørgsler 429, mens anonyme fra samme adresse lykkes, tyder det på konto- eller autentificeringsgrænser, men beviser det ikke. Fejler begge, kan grænsen gælde IP, ressource eller hele serveren. Hold endpoint og tempo sammenlignelige og følg Retry-After før ny test.

Ofte stillede spørgsmål