Come bypassare il rate limiting con i proxy: architettura, rotazione IP e esempi di codice per sviluppatori

Il rate limiting è una delle cause più comuni per cui gli scraper si bloccano, le integrazioni API falliscono e gli script automatizzati ricevono lo stato 429 Too Many Requests. Il server rileva troppe richieste da un unico IP e smette semplicemente di rispondere. In questo articolo vedremo come costruire correttamente un'infrastruttura basata su proxy per bypassare i limiti di richiesta senza ban e interruzioni — con esempi di codice reali in Python e Node.js.

Che cos'è il rate limiting e perché i normali ritardi non aiutano

Il rate limiting (limitazione della frequenza delle richieste) è un meccanismo di protezione del server che limita il numero di richieste da una singola fonte in un determinato intervallo di tempo. La fonte è spesso un indirizzo IP, ma i sistemi avanzati considerano anche i token di autorizzazione, User-Agent, cookie e persino modelli comportamentali.

Quando il tuo script supera il limite, il server restituisce una delle seguenti risposte:

• 429 Too Many Requests — stato HTTP standard per il rate limiting
• 503 Service Unavailable — a volte utilizzato al posto di 429
• 403 Forbidden — se l'IP è già stato inserito nella blacklist
• Risposta vuota o timeout — in caso di blocco aggressivo

La prima idea della maggior parte degli sviluppatori è aggiungere time.sleep(1) tra le richieste. Questo funziona solo con limiti molto blandi (ad esempio, 60 richieste al minuto). Ma gli scenari reali sono più complessi:

Se hai bisogno di raccogliere 100.000 schede di prodotti da un marketplace o monitorare i prezzi in tempo reale — i ritardi semplicemente non aiutano. È necessaria un'altra architettura. Ed è qui che i proxy diventano una necessità, non un'opzione.

È importante capire: il rate limiting è legato all'indirizzo IP. Se hai 100 IP diversi — hai effettivamente 100 "quote" indipendenti. Questo è il principio chiave per bypassare le limitazioni tramite proxy.

Come i proxy risolvono il problema delle limitazioni delle richieste

Il meccanismo è semplice: ogni richiesta al server di destinazione viene inviata da un indirizzo IP diverso. Dal punto di vista del server — sono utenti diversi. La quota di ciascuno di essi non viene praticamente consumata, quindi non si verifica il blocco.

Consideriamo la differenza tra lavorare senza proxy e con un pool di proxy in un esempio concreto. Supponiamo che il server consenta 10 richieste al minuto da un singolo IP:

Oltre a scalare la larghezza di banda, i proxy offrono anche diversi vantaggi quando si lavora con il rate limiting:

• Isolamento delle sessioni — se un IP viene bannato, gli altri continuano a funzionare
• Distribuzione geografica — le richieste provengono da diverse regioni, riducendo il sospetto
• Sessioni sticky — possibilità di "attaccarsi" a un IP per scenari multi-passaggio (autenticazione + azione)
• Controllo del carico — è possibile dosare con precisione le richieste per ogni IP, senza superare il limite

Quale tipo di proxy scegliere per il tuo compito

Non tutti i proxy sono ugualmente efficaci contro il rate limiting. La scelta del tipo dipende dal sito di destinazione, dal volume delle richieste e dal budget. Esaminiamo tre tipi principali:

Proxy residenziali

Questi sono indirizzi IP di utenti domestici reali. Appaiono come traffico internet normale e raramente vengono bloccati. I proxy residenziali sono la scelta ottimale per siti con protezione aggressiva: marketplace (Wildberries, Ozon), social network, risorse protette da Cloudflare. L'unico svantaggio è il costo più elevato rispetto ai proxy dei data center.

Proxy mobili

Indirizzi IP di operatori mobili (3G/4G/5G). La loro caratteristica è che un IP può essere utilizzato da migliaia di abbonati reali contemporaneamente, quindi i siti non vogliono bloccare un tale indirizzo. I proxy mobili mostrano i migliori risultati dove i residenziali iniziano già a essere bloccati — ad esempio, nel parsing ad alta frequenza di Instagram o nel lavoro con API di piattaforme che analizzano il tipo di connessione.

Proxy dei data center

IP veloci e economici dai data center. Sono ideali per il parsing di siti senza protezione seria: API aperte, aggregatori di notizie, database pubblici. Per compiti con rate limiting, ne servono di più (poiché vengono più frequentemente inseriti nelle blacklist), ma con una corretta rotazione si comportano bene con grandi volumi di richieste. Maggiori dettagli sulla pagina proxy dei data center.

Strategie di rotazione IP: per richiesta, sessioni sticky, round-robin

Il semplice fatto di avere proxy non risolve il problema — è importante gestirli correttamente. Esistono diverse strategie di rotazione, ognuna delle quali è adatta a scenari specifici.

Rotazione per richiesta (nuovo IP per ogni richiesta)

Ogni richiesta HTTP viene inviata tramite un nuovo indirizzo IP. Questa è la strategia di bypass del rate limiting più aggressiva — il server non ha il tempo di accumulare un contatore per un singolo IP. È adatta per:

• Parsing di schede di prodotti (ogni scheda è una richiesta separata)
• Raccolta di dati dai motori di ricerca
• Qualsiasi richiesta stateless che non richiede sessione

Sessioni sticky (IP fisso per sessione)

Un IP viene utilizzato per tutta la durata della sessione (di solito 1–30 minuti). Criticamente importante per scenari in cui è necessaria l'autenticazione: accedere all'account, eseguire un'azione, uscire. Se l'IP cambia tra i passaggi — il server può bloccare la sessione come sospetta.

Round-robin con limite di richieste per IP

La strategia più precisa. Conosci il limite del server (ad esempio, 10 richieste al minuto) e distribuisci le richieste nel pool di proxy in modo che ogni IP non superi mai questa soglia. Richiede l'implementazione di una coda tenendo conto del tempo dell'ultima richiesta per ogni IP.

Esempi di codice in Python: requests, aiohttp, Scrapy

Passiamo alla pratica. Di seguito sono riportati modelli pronti per i tre strumenti Python più popolari.

1. requests + rotazione proxy manuale

La soluzione più semplice è un elenco di proxy e una scelta casuale per ogni richiesta:

import requests
import random
import time

PROXIES = [
    "http://user:[email protected]:8080",
    "http://user:[email protected]:8080",
    "http://user:[email protected]:8080",
    # ... aggiungi il numero necessario
]

def get_random_proxy():
    proxy = random.choice(PROXIES)
    return {"http": proxy, "https": proxy}

def fetch_with_retry(url, max_retries=3):
    for attempt in range(max_retries):
        proxy = get_random_proxy()
        try:
            response = requests.get(
                url,
                proxies=proxy,
                timeout=10,
                headers={"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36"}
            )
            if response.status_code == 429:
                print(f"Rate limited on {proxy}, switching...")
                time.sleep(1)
                continue
            return response
        except requests.RequestException as e:
            print(f"Attempt {attempt+1} failed: {e}")
            time.sleep(2)
    return None

# Utilizzo
urls = ["https://example.com/item/1", "https://example.com/item/2"]
for url in urls:
    result = fetch_with_retry(url)
    if result:
        print(f"OK: {url} — {len(result.text)} bytes")

2. Pool di proxy intelligente tenendo conto del rate limit

Una soluzione più avanzata è la classe ProxyPool, che tiene traccia del tempo dell'ultimo utilizzo di ogni IP e non supera il limite stabilito:

import requests
import time
from collections import defaultdict
from threading import Lock

class ProxyPool:
    def __init__(self, proxies, rate_limit=10, window=60):
        """
        proxies: lista di stringhe del tipo 'http://user:pass@host:port'
        rate_limit: massimo richieste da un IP in window secondi
        window: finestra temporale in secondi
        """
        self.proxies = proxies
        self.rate_limit = rate_limit
        self.window = window
        self.usage = defaultdict(list)  # proxy -> [timestamps]
        self.lock = Lock()

    def get_available_proxy(self):
        now = time.time()
        with self.lock:
            for proxy in self.proxies:
                # Pulisci le etichette scadute
                self.usage[proxy] = [
                    t for t in self.usage[proxy]
                    if now - t < self.window
                ]
                if len(self.usage[proxy]) < self.rate_limit:
                    self.usage[proxy].append(now)
                    return {"http": proxy, "https": proxy}
        return None  # Tutti i proxy hanno esaurito il limite

    def fetch(self, url, **kwargs):
        proxy = self.get_available_proxy()
        if proxy is None:
            print("All proxies rate-limited, waiting...")
            time.sleep(5)
            return self.fetch(url, **kwargs)
        
        try:
            response = requests.get(url, proxies=proxy, timeout=10, **kwargs)
            return response
        except requests.RequestException as e:
            print(f"Request failed: {e}")
            return None

# Utilizzo
pool = ProxyPool(
    proxies=[
        "http://user:[email protected]:8080",
        "http://user:[email protected]:8080",
    ],
    rate_limit=10,  # 10 richieste al minuto per IP
    window=60
)

for i in range(100):
    r = pool.fetch(f"https://example.com/page/{i}")
    if r:
        print(f"Page {i}: {r.status_code}")

3. aiohttp per parsing asincrono

L'approccio asincrono consente di utilizzare decine di proxy in parallelo senza bloccare i thread:

import asyncio
import aiohttp
import itertools

PROXIES = [
    "http://user:[email protected]:8080",
    "http://user:[email protected]:8080",
    "http://user:[email protected]:8080",
]

proxy_cycle = itertools.cycle(PROXIES)

async def fetch(session, url, proxy):
    try:
        async with session.get(
            url,
            proxy=proxy,
            timeout=aiohttp.ClientTimeout(total=10)
        ) as response:
            if response.status == 429:
                await asyncio.sleep(2)
                return None
            return await response.text()
    except Exception as e:
        print(f"Error: {e}")
        return None

async def main(urls):
    connector = aiohttp.TCPConnector(limit=50)
    async with aiohttp.ClientSession(connector=connector) as session:
        tasks = [
            fetch(session, url, next(proxy_cycle))
            for url in urls
        ]
        results = await asyncio.gather(*tasks)
        return results

urls = [f"https://example.com/item/{i}" for i in range(200)]
results = asyncio.run(main(urls))
print(f"Collected: {sum(1 for r in results if r is not None)} pages")

4. Scrapy con rotazione tramite middleware

Per Scrapy esiste una soluzione pronta — scrapy-rotating-proxies. Ma è possibile scrivere un proprio middleware:

# middlewares.py
import random

class RotatingProxyMiddleware:
    def __init__(self, proxies):
        self.proxies = proxies

    @classmethod
    def from_crawler(cls, crawler):
        return cls(proxies=crawler.settings.getlist("PROXY_LIST"))

    def process_request(self, request, spider):
        proxy = random.choice(self.proxies)
        request.meta["proxy"] = proxy

    def process_response(self, request, response, spider):
        if response.status == 429:
            spider.logger.warning(f"Rate limited, proxy: {request.meta.get('proxy')}")
            # È possibile aggiungere logica per escludere il proxy problematico
        return response

# settings.py
PROXY_LIST = [
    "http://user:[email protected]:8080",
    "http://user:[email protected]:8080",
]
DOWNLOADER_MIDDLEWARES = {
    "myproject.middlewares.RotatingProxyMiddleware": 350,
}
AUTOTHROTTLE_ENABLED = True
AUTOTHROTTLE_TARGET_CONCURRENCY = 10

Esempi di codice in Node.js: axios, got, Puppeteer

Node.js è una scelta popolare per l'automazione dei browser e il lavoro con le API. Ecco modelli pronti per lavorare con i proxy.

1. axios con rotazione proxy

const axios = require('axios');
const { HttpsProxyAgent } = require('https-proxy-agent');

const proxies = [
  'http://user:[email protected]:8080',
  'http://user:[email protected]:8080',
  'http://user:[email protected]:8080',
];

let proxyIndex = 0;

function getNextProxy() {
  const proxy = proxies[proxyIndex % proxies.length];
  proxyIndex++;
  return proxy;
}

async function fetchWithProxy(url, retries = 3) {
  for (let i = 0; i < retries; i++) {
    const proxyUrl = getNextProxy();
    const agent = new HttpsProxyAgent(proxyUrl);
    
    try {
      const response = await axios.get(url, {
        httpsAgent: agent,
        httpAgent: agent,
        timeout: 10000,
        headers: {
          'User-Agent': 'Mozilla/5.0 (Windows NT 10.0; Win64; x64)',
        },
      });
      return response.data;
    } catch (error) {
      if (error.response?.status === 429) {
        console.log(`Rate limited, switching proxy...`);
        await new Promise(r => setTimeout(r, 1000));
        continue;
      }
      console.error(`Attempt ${i + 1} failed:`, error.message);
    }
  }
  return null;
}

// Utilizzo
(async () => {
  const urls = Array.from({length: 50}, (_, i) => `https://example.com/item/${i}`);
  
  const results = await Promise.allSettled(
    urls.map(url => fetchWithProxy(url))
  );
  
  const successful = results.filter(r => r.status === 'fulfilled' && r.value).length;
  console.log(`Success: ${successful}/${urls.length}`);
})();

2. Puppeteer con proxy e bypass del rate limiting

Per i siti con rendering JavaScript e protezione Cloudflare è necessario un browser headless:

const puppeteer = require('puppeteer');

const proxies = [
  'proxy1.example.com:8080',
  'proxy2.example.com:8080',
];

async function scrapeWithProxy(url, proxyHost) {
  const browser = await puppeteer.launch({
    args: [
      `--proxy-server=${proxyHost}`,
      '--no-sandbox',
      '--disable-setuid-sandbox',
    ],
    headless: true,
  });

  const page = await browser.newPage();
  
  // Autenticazione del proxy
  await page.authenticate({
    username: 'user',
    password: 'pass',
  });

  // Imposta un User-Agent realistico
  await page.setUserAgent(
    'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36'
  );

  try {
    await page.goto(url, { waitUntil: 'networkidle2', timeout: 30000 });
    
    // Controlla il rate limit
    const status = await page.evaluate(() => document.title);
    if (status.includes('429') || status.includes('Too Many')) {
      console.log('Rate limited, need to switch proxy');
      return null;
    }
    
    const data = await page.evaluate(() => {
      return document.querySelector('.price')?.textContent || null;
    });
    
    return data;
  } finally {
    await browser.close();
  }
}

// Rotazione per compiti
(async () => {
  const urls = ['https://example.com/product/1', 'https://example.com/product/2'];
  
  for (let i = 0; i < urls.length; i++) {
    const proxy = proxies[i % proxies.length];
    const result = await scrapeWithProxy(urls[i], proxy);
    console.log(`${urls[i]}: ${result}`);
    await new Promise(r => setTimeout(r, 500)); // breve ritardo
  }
})();

Tecniche avanzate: intestazioni, fingerprint, bypass di Cloudflare

Cambiare IP è una condizione necessaria, ma non sempre sufficiente. I moderni sistemi di protezione analizzano decine di parametri della richiesta. Vediamo cosa altro è necessario considerare.

Intestazioni HTTP: insieme minimo obbligatorio

Una richiesta senza intestazioni normali appare come un bot anche con il cambio di IP. Aggiungi sempre:

headers = {
    "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36",
    "Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8",
    "Accept-Language": "ru-RU,ru;q=0.9,en-US;q=0.8,en;q=0.7",
    "Accept-Encoding": "gzip, deflate, br",
    "Connection": "keep-alive",
    "Upgrade-Insecure-Requests": "1",
    "Sec-Fetch-Dest": "document",
    "Sec-Fetch-Mode": "navigate",
    "Sec-Fetch-Site": "none",
    "Cache-Control": "max-age=0",
}

Gestione dell'intestazione Retry-After

Quando si riceve una risposta 429, il server spesso indica quanto tempo bisogna attendere. Gestire correttamente questa intestazione consente di non sprecare richieste:

def handle_rate_limit(response):
    if response.status_code == 429:
        retry_after = response.headers.get("Retry-After")
        if retry_after:
            wait_time = int(retry_after)
            print(f"Rate limited. Waiting {wait_time} seconds...")
            time.sleep(wait_time + 1)  # +1 secondo di buffer
        else:
            # Ritardo esponenziale se non c'è intestazione
            time.sleep(min(2 ** attempt, 60))
        return True
    return False

Fingerprinting TLS e come bypassarlo

I sistemi avanzati (Cloudflare, Akamai, PerimeterX) analizzano il fingerprint TLS — un "impronta" unica della tua connessione TLS. La libreria standard requests ha un fingerprint facilmente riconoscibile. Soluzioni:

• curl_cffi (Python) — emula il fingerprint di Chrome/Firefox a livello TLS
• tls-client (Go/Python) — strumento simile con supporto per diversi profili browser
• Playwright/Puppeteer — browser reale, fingerprint ideale per impostazione predefinita

# pip install curl-cffi
from curl_cffi import requests as cffi_requests

response = cffi_requests.get(
    "https://cloudflare-protected-site.com/api/data",
    impersonate="chrome120",  # Emuliamo Chrome 120
    proxies={"https": "http://user:[email protected]:8080"}
)
print(response.json())

Gestione di cookie e sessioni

Se il sito utilizza cookie per tracciare le sessioni, cambiare IP senza cambiare i cookie è inutile. Quando si cambiano i proxy, crea sempre una nuova sessione:

import requests

def create_fresh_session(proxy_url):
    """Crea una nuova sessione con cookie puliti per ogni proxy"""
    session = requests.Session()
    session.proxies = {"http": proxy_url, "https": proxy_url}
    session.headers.update({
        "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64)...",
    })
    # I cookie non vengono trasferiti dalla sessione precedente
    return session

# Per ogni nuovo IP — nuova sessione
for proxy in proxies:
    session = create_fresh_session(proxy)
    response = session.get("https://example.com/protected-page")
    # Gestisci la risposta...

Errori comuni nell'uso di proxy e rate limiting

Anche con proxy configurati correttamente, gli sviluppatori commettono regolarmente gli stessi errori. Ecco gli errori più frequenti e come evitarli.

Errore 1: Utilizzo di proxy "morti"

Controlla sempre i proxy prima di aggiungerli al pool e periodicamente durante il lavoro. Un proxy non funzionante nel ciclo significa richieste perse e timeout:

def check_proxy(proxy_url, test_url="https://httpbin.org/ip", timeout=5):
    try:
        r = requests.get(
            test_url,
            proxies={"http": proxy_url, "https": proxy_url},
            timeout=timeout
        )
        return r.status_code == 200
    except:
        return False

# Filtriamo i proxy funzionanti prima dell'avvio
working_proxies = [p for p in PROXIES if check_proxy(p)]
print(f"Working proxies: {len(working_proxies)}/{len(PROXIES)}")

Errore 2: Ignorare il tipo di protocollo

I proxy HTTP non possono proxyare direttamente il traffico HTTPS (solo tramite CONNECT). I proxy SOCKS5 funzionano a livello di trasporto e supportano qualsiasi protocollo. Per la maggior parte dei siti moderni, utilizza SOCKS5 o proxy HTTPS:

# Proxy SOCKS5 in requests (richiede pip install requests[socks])
proxies = {
    "http": "socks5://user:[email protected]:1080",
    "https": "socks5://user:[email protected]:1080",
}

# Proxy HTTPS
proxies = {
    "http": "https://user:[email protected]:8080",
    "https": "https://user:[email protected]:8080",
}

Errore 3: Mancanza di backoff esponenziale

Se dopo un 429 ripeti immediatamente la richiesta — stai solo aggravando la situazione. La strategia corretta è un ritardo esponenziale con jitter (deviazione casuale):

import random

def exponential_backoff(attempt, base=1, max_wait=60):
    """
    attempt: numero del tentativo (a partire da 0)
    base: ritardo base in secondi
    max_wait: ritardo massimo
    """
    wait = min(base * (2 ** attempt), max_wait)
    # Jitter ±25% per prevenire il thundering herd
    jitter = wait * 0.25 * random.uniform(-1, 1)
    return wait + jitter

# Utilizzo nella logica di retry
for attempt in range(5):
    response = requests.get(url, proxies=proxy)
    if response.status_code == 429:
        wait = exponential_backoff(attempt)
        print(f"Rate limited. Waiting {wait:.1f}s (attempt {attempt+1})")
        time.sleep(wait)
    else:
        break

Errore 4: Un solo thread per tutti i proxy

Se hai 50 proxy, ma un solo thread di esecuzione — stai utilizzando al massimo 1 proxy alla volta. Utilizza ThreadPoolExecutor o un approccio asincrono per utilizzare in parallelo l'intero pool:

from concurrent.futures import ThreadPoolExecutor, as_completed

def fetch_url(args):
    url, proxy = args
    try:
        r = requests.get(url, proxies={"https": proxy}, timeout=10)
        return url, r.status_code, len(r.text)
    except Exception as e:
        return url, None, str(e)

# Utilizziamo in parallelo tutti i proxy
tasks = [(url, proxies[i % len(proxies)]) for i, url in enumerate(urls)]

with ThreadPoolExecutor(max_workers=len(proxies)) as executor:
    futures = {executor.submit(fetch_url, task): task for task in tasks}
    for future in as_completed(futures):
        url, status, size = future.result()
        print(f"{url}: {status} ({size})")

Conclusione e raccomandazioni

Il rate limiting è un problema risolvibile, se affrontato in modo sistematico. Ecco le conclusioni chiave di questa guida:

• Pool di proxy, non un solo proxy — l'unità minima per un lavoro serio. Il numero di proxy è determinato dalla formula: velocità target ÷ limite del server per IP.
• La strategia di rotazione è importante — per richiesta per richieste stateless, sessioni sticky per scenari autorizzati.
• L'IP non è l'unico parametro — intestazioni, cookie, fingerprint TLS e modelli comportamentali vengono anch'essi analizzati dai sistemi di protezione.
• Gestisci correttamente il 429 — backoff esponenziale, intestazione Retry-After, cambio proxy in caso di blocco.
• Il tipo di proxy dipende dall'obiettivo — proxy dei data center per API aperte, residenziali per marketplace, mobili per la massima protezione.

Se lavori con il parsing di marketplace (Wildberries, Ozon), raccolta di dati da API protette o automazione ad alte velocità — ti consigliamo di iniziare con proxy residenziali: offrono un equilibrio ottimale tra anonimato e velocità, e i loro indirizzi IP vengono raramente inseriti nelle blacklist. Per compiti in cui è necessaria la massima resilienza ai blocchi con alta frequenza di richieste, considera i proxy mobili — i loro IP sono condivisi da migliaia di utenti reali, rendendo il blocco estremamente indesiderato per qualsiasi sito.