Proxy per il parsing delle offerte di lavoro da hh.ru, Superjob e LinkedIn: guida completa

Il parsing dei job board è uno degli scenari più richiesti per la raccolta dati nell'ambito dell'analisi HR, del monitoraggio del mercato del lavoro e dell'automazione del recruiting. Tuttavia, i siti di offerte di lavoro si proteggono attivamente dalla raccolta automatica dei dati: bloccano gli IP dopo 50-100 richieste, mostrano captcha e bannano account sospetti. In questo articolo analizzeremo come configurare correttamente i proxy per un parsing stabile di hh.ru, Superjob, LinkedIn e altre piattaforme senza blocchi.

Perché i job board bloccano il parsing e come funziona la protezione

I siti di offerte di lavoro perdono denaro a causa del parsing: i dati vengono venduti ai concorrenti, vengono creati aggregatori senza licenza, i datori di lavoro aggirano le pubblicazioni a pagamento. Per questo motivo tutte le grandi piattaforme hanno implementato una protezione multilivello contro la raccolta automatica dei dati.

Principali metodi di protezione dei job board:

• Rate limiting per IP — hh.ru blocca gli IP dopo 80-120 richieste all'ora, Superjob dopo 50-70 richieste. Il blocco può durare da 1 ora a un giorno.
• Fingerprinting del browser — i siti analizzano User-Agent, header HTTP, risoluzione dello schermo, font installati. Se i dati non corrispondono a un browser reale, la richiesta viene bloccata.
• Controlli JavaScript — molti siti utilizzano Cloudflare o script proprietari per verificare che la richiesta provenga da un browser reale e non da un bot.
• Trappole honeypot — link e campi nascosti visibili solo al parser. Se il bot ci accede, l'IP finisce nella lista nera.
• Captcha in caso di attività sospetta — appare dopo una serie di richieste rapide o quando si utilizzano IP di data center.

Senza proxy potrete fare il parsing di massimo 100-200 offerte di lavoro, dopodiché il vostro IP verrà bannato. Per una raccolta dati su larga scala (migliaia di offerte al giorno) i proxy diventano uno strumento obbligatorio.

Quale tipo di proxy scegliere per il parsing di offerte di lavoro

La scelta del tipo di proxy dipende dalla scala del parsing, dal budget e dai requisiti di velocità. Analizziamo tre opzioni principali con scenari di utilizzo specifici.

Proxy data center per il parsing

Questa è l'opzione più veloce ed economica, ma con limitazioni. Gli IP dei data center sono facilmente riconoscibili dai siti, quindi sono adatti solo per compiti semplici: parsing di elenchi di offerte senza autenticazione, raccolta di dati pubblici, test del parser prima del lancio su proxy residenziali.

Quando funzionano i proxy data center:

• Parsing di piccoli volumi di dati (fino a 500 offerte al giorno)
• Raccolta dati da siti senza protezione rigida (piccoli job board regionali)
• Utilizzo di API ufficiali con rotazione IP per aggirare i rate limit
• Parsing di feed RSS e file XML di offerte

Per hh.ru e Superjob i proxy data center funzioneranno in modo instabile: riceverete un captcha dopo 20-30 richieste, e molti IP sono già nelle liste nere di questi siti.

Proxy residenziali — la scelta ottimale per i job board

I proxy residenziali utilizzano indirizzi IP di utenti domestici reali, quindi i siti li percepiscono come visitatori normali. Questo è il miglior equilibrio tra prezzo e qualità per il parsing di offerte di lavoro.

Vantaggi per il parsing dei job board:

• Basso rischio di blocco — hh.ru e Superjob non possono distinguere un IP residenziale da un utente reale
• Grande pool di indirizzi IP — è possibile configurare la rotazione ad ogni richiesta o ogni 5-10 minuti
• Geolocalizzazione — è possibile fare il parsing di offerte da una città specifica utilizzando IP di quella regione
• Stabilità — un singolo IP residenziale può gestire 200-500 richieste senza blocco

Per il parsing su larga scala (oltre 1000 offerte al giorno) i proxy residenziali con rotazione IP sono la soluzione standard. Configurate il cambio IP ogni 5-10 minuti, aggiungete ritardi casuali tra le richieste (3-7 secondi) e otterrete una raccolta dati stabile senza blocchi.

Proxy mobili per LinkedIn e parsing con autenticazione

I proxy mobili utilizzano IP di operatori mobili. Il loro principale vantaggio è che un IP viene utilizzato contemporaneamente da centinaia di utenti reali, quindi i siti non possono bloccare tale indirizzo senza rischiare di bloccare migliaia di visitatori normali.

Quando servono i proxy mobili:

• Parsing di LinkedIn — questa piattaforma ha la protezione più rigida contro i bot e blocca aggressivamente gli IP di data center e persino residenziali
• Lavoro con autenticazione — se dovete fare il parsing di offerte chiuse o dati di profili, gli IP mobili riducono il rischio di ban dell'account
• Parsing di job board esteri — Indeed, Glassdoor, Monster utilizzano sistemi di protezione avanzati dove gli IP mobili funzionano in modo più affidabile
• Bypass di blocchi rigidi — se i vostri proxy residenziali iniziano a ricevere captcha, passare ai mobili risolverà il problema

Lo svantaggio dei proxy mobili è il prezzo elevato e la velocità inferiore. Ma per compiti critici dove il blocco è inaccettabile, questa è la scelta migliore.

Caratteristiche del parsing di hh.ru: protezione e metodi di bypass

hh.ru è il più grande sito russo di offerte di lavoro con la protezione più avanzata contro il parsing tra i job board nazionali. Il sito utilizza una combinazione di rate limiting, fingerprinting e analisi comportamentale per identificare i bot.

Come funziona la protezione di hh.ru

1. Limiti per indirizzo IP: Dopo 80-120 richieste all'ora da un singolo IP, il sito inizia a mostrare captcha o restituisce HTTP 429 (Too Many Requests). Il blocco dura da 1 a 6 ore a seconda dell'aggressività del parsing.

2. Verifica User-Agent e header: hh.ru analizza gli header delle richieste HTTP. Se lo User-Agent non corrisponde a un browser reale o mancano header standard (Accept-Language, Accept-Encoding), la richiesta viene bloccata.

3. Controlli JavaScript: Alcune pagine di hh.ru richiedono l'esecuzione di JavaScript per caricare i dati. Un semplice parser HTTP senza browser headless non potrà ottenere il contenuto completo.

4. Link honeypot: Sulle pagine ci sono elementi nascosti visibili solo al parser. Se il vostro script accede a questi link, l'IP finisce nella lista nera per 24 ore.

Strategia di bypass della protezione di hh.ru con proxy

Per un parsing stabile di hh.ru senza blocchi utilizzate la seguente configurazione:

Esempio di sequenza sicura di azioni:

1. Vi connettete a un proxy residenziale con IP dalla regione necessaria (ad esempio, Mosca)
2. Fate la prima richiesta alla homepage di hh.ru, ricevete e salvate i cookie
3. Aspettate 5-7 secondi (simulazione della lettura della pagina)
4. Fate una richiesta alla pagina di ricerca offerte con i filtri necessari
5. Fate il parsing dell'elenco offerte (di solito 20-50 per pagina)
6. Per ogni offerta fate una richiesta alla pagina dettagliata con ritardo di 4-6 secondi
7. Dopo 60-70 richieste cambiate proxy e ripetete il ciclo

Con questa strategia potete fare il parsing di 1000-2000 offerte al giorno da un singolo thread senza alcun blocco. Se serve un volume maggiore, avviate più thread paralleli con proxy diversi.

Parsing di Superjob, LinkedIn e piattaforme estere

Superjob: caratteristiche della protezione

Superjob ha una protezione meno rigida rispetto a hh.ru, ma comunque combatte attivamente il parsing. Principali differenze:

• Rate limit più basso: Il blocco avviene dopo 50-70 richieste all'ora (contro 80-120 di hh.ru)
• Verifica header meno rigida: È possibile utilizzare un set semplificato di header
• Assenza di protezione JavaScript: La maggior parte dei dati è accessibile tramite semplice richiesta HTTP senza browser headless
• Blocco regionale: Alcune offerte sono accessibili solo con IP di una determinata regione

Per Superjob sono sufficienti proxy residenziali con rotazione ogni 10-15 minuti e ritardo tra richieste di 3-5 secondi. Questo permetterà di fare il parsing stabile di 500-1000 offerte al giorno.

LinkedIn: la protezione più rigida

LinkedIn è un caso a parte. La piattaforma utilizza algoritmi avanzati di machine learning per identificare i bot e ha uno dei sistemi di protezione più aggressivi tra tutti i social network e job board.

Caratteristiche della protezione di LinkedIn:

• Autenticazione obbligatoria: La maggior parte dei dati è accessibile solo agli utenti autenticati
• Analisi comportamentale: LinkedIn analizza i pattern di azioni: velocità di scrolling, movimenti del mouse, tempo sulla pagina
• Blocco degli account: In caso di attività sospetta viene bloccato non solo l'IP, ma anche l'account stesso
• Limitazioni sulla visualizzazione profili: Gli account gratuiti possono visualizzare un numero limitato di profili al mese
• Esecuzione JavaScript obbligatoria: Senza browser headless il parsing è impossibile

Strategia di parsing di LinkedIn:

Il parsing di LinkedIn è il compito più complesso tra tutti i job board. Se avete bisogno di dati da questa piattaforma, considerate l'utilizzo dell'API ufficiale Sales Navigator o servizi di terze parti che forniscono dati legalmente.

Job board esteri: Indeed, Glassdoor, Monster

Le piattaforme estere hanno generalmente una protezione più rigida rispetto ai siti russi (eccetto hh.ru). Caratteristiche principali:

• Indeed — utilizza Cloudflare con controlli JavaScript. Serve un browser headless e proxy residenziali/mobili dal paese di cui fate il parsing delle offerte.
• Glassdoor — richiede autenticazione per visualizzare la maggior parte dei dati. Blocca attivamente gli IP di data center. Utilizzate proxy residenziali e velocità di parsing lenta (ritardo 8-12 secondi).
• Monster — ha un'API per i partner, ma per il parsing HTML servono proxy residenziali con geolocalizzazione nel paese necessario.

Per tutte le piattaforme estere è fondamentale la geolocalizzazione dei proxy. Se fate il parsing di offerte negli USA, utilizzate IP residenziali americani. Le richieste con IP da altri paesi possono destare sospetti e portare al blocco.

Configurazione della rotazione IP e dei ritardi tra le richieste

La corretta configurazione della rotazione dei proxy è la chiave per un parsing stabile senza blocchi. Analizziamo due strategie principali: rotazione ad ogni richiesta e rotazione temporale.

Rotazione ad ogni richiesta (Rotating Proxies)

Con questo approccio ogni richiesta HTTP viene effettuata da un nuovo indirizzo IP. Questo è il metodo più sicuro, ma ha limitazioni:

Vantaggi:

• Impossibile tracciare l'attività di un singolo IP
• È possibile fare più richieste per unità di tempo
• Non serve monitorare i limiti per ogni IP

Svantaggi:

• Impossibile mantenere la sessione (i cookie si perdono al cambio IP)
• Non adatto per il parsing con autenticazione
• Alcuni siti bloccano le richieste se l'IP cambia troppo frequentemente

La rotazione ad ogni richiesta è adatta per il parsing di pagine pubbliche di hh.ru e Superjob senza autenticazione. Si configura tramite parametro del provider proxy (di solito è un endpoint speciale con rotazione automatica).

Rotazione temporale (Sticky Sessions)

Con questo approccio un IP viene utilizzato per un determinato periodo (5-30 minuti), dopodiché avviene il cambio automatico. Questa è l'opzione ottimale per la maggior parte dei compiti di parsing dei job board.

Intervalli di rotazione raccomandati:

Configurazione dei ritardi casuali

Un ritardo fisso tra le richieste (ad esempio, esattamente 5 secondi) appare sospetto ai sistemi di protezione. Un utente reale non può agire con tale precisione. Utilizzate sempre ritardi casuali in un intervallo.

Esempi di implementazione di ritardi casuali:

// Python
import time
import random

# Ritardo da 4 a 8 secondi
delay = random.uniform(4, 8)
time.sleep(delay)

# Logica più complessa: a volte facciamo una pausa lunga
if random.random() < 0.1:  # 10% di probabilità
    time.sleep(random.uniform(15, 30))  # Simulazione distrazione utente
else:
    time.sleep(random.uniform(4, 8))

// JavaScript / Node.js
const sleep = (min, max) => {
  const delay = Math.random() * (max - min) + min;
  return new Promise(resolve => setTimeout(resolve, delay * 1000));
};

// Utilizzo
await sleep(4, 8);  // Ritardo 4-8 secondi

// Con probabilità di pausa lunga
if (Math.random() < 0.1) {
  await sleep(15, 30);  // 10% probabilità pausa lunga
} else {
  await sleep(4, 8);
}

L'aggiunta di pause lunghe casuali (15-30 secondi) con probabilità del 5-10% rende il comportamento del parser ancora più simile a un utente reale che può distrarsi per una telefonata o un altro compito.

Gestione dei captcha e altri blocchi

Anche con la corretta configurazione di proxy e ritardi potete incontrare captcha o altri tipi di blocchi. Analizziamo come reagire correttamente a queste situazioni.

Tipi di blocchi dei job board

1. HTTP 429 Too Many Requests — il tipo di blocco più frequente. Il sito comunica esplicitamente che avete superato il limite di richieste. Di solito nell'header della risposta c'è Retry-After che indica dopo quanti secondi potete riprovare.

Come gestire: Cambiare immediatamente proxy e aggiungere l'IP corrente alla lista nera per il tempo indicato in Retry-After (di solito 1-6 ore). Se Retry-After è assente, aggiungete l'IP alla lista nera per 2 ore.

2. HTTP 403 Forbidden — IP bloccato a livello server. Questo è un blocco più serio che può durare da diverse ore a un giorno.

Come gestire: Cambiare proxy e aggiungere l'IP alla lista nera a lungo termine (24 ore). Analizzare i log: forse state facendo il parsing troppo aggressivamente o utilizzate IP di data center dove servono residenziali.

3. Captcha (CAPTCHA) — il sito mostra la verifica "non sono un robot". Questo significa che il vostro comportamento è sembrato sospetto, ma l'IP non è ancora completamente bloccato.

Come gestire: Ci sono tre opzioni:

• Cambio proxy — il modo più semplice. L'IP corrente viene aggiunto alla lista nera per 6-12 ore.
• Risoluzione automatica captcha — utilizzo di servizi come 2Captcha, Anti-Captcha, CapSolver. Costano $1-3 per 1000 risoluzioni.
• Risoluzione manuale — se il parsing non è critico in termini di tempo, potete inviare il captcha per risoluzione manuale a un operatore.

4. Cloudflare Challenge — verifica JavaScript che richiede l'esecuzione di codice nel browser. Una normale libreria HTTP non supererà questa verifica.

Come gestire: Utilizzare un browser headless (Puppeteer, Playwright, Selenium) con configurazione di fingerprint reale. Librerie come puppeteer-extra-plugin-stealth aiutano a bypassare il rilevamento della modalità headless.

Integrazione servizi di risoluzione captcha

Se decidete di risolvere automaticamente i captcha, ecco un esempio di integrazione con il popolare servizio 2Captcha:

// Python con libreria 2captcha-python
from twocaptcha import TwoCaptcha
import requests

solver = TwoCaptcha('YOUR_API_KEY')

try:
    # Risoluzione reCAPTCHA v2
    result = solver.recaptcha(
        sitekey='6Le-wvkSAAAAAPBMRTvw0Q4Muexq9bi0DJwx_mJ-',
        url='https://hh.ru/search/vacancy',
        proxy={
            'type': 'HTTPS',
            'uri': 'login:password@ip:port'
        }
    )
    
    # Otteniamo il token della soluzione
    captcha_token = result['code']
    
    # Inviamo la richiesta con il token
    response = requests.post(
        'https://hh.ru/search/vacancy',
        data={
            'g-recaptcha-response': captcha_token,
            # altri parametri del form
        },
        proxies={
            'http': 'http://login:password@ip:port',
            'https': 'http://login:password@ip:port'
        }
    )
    
except Exception as e:
    print(f'Errore risoluzione captcha: {e}')

La risoluzione di un captcha richiede 10-30 secondi e costa circa $0.001-0.003. Per il parsing su larga scala può essere costoso, quindi è meglio configurare il parsing in modo che il captcha appaia il meno possibile.

Sistema di monitoraggio e alert

Per un funzionamento stabile del parser è importante configurare il monitoraggio dei blocchi e gli alert automatici:

Configurate l'invio di notifiche (Telegram, email, Slack) se la percentuale di richieste riuscite scende sotto il valore soglia. Questo permetterà di reagire rapidamente ai problemi e non perdere tempo di parsing.

Configurazione dei proxy negli strumenti di parsing più popolari

Analizziamo come configurare i proxy negli strumenti più popolari per il parsing dei job board: Python (requests, Scrapy), Node.js (axios, Puppeteer) e soluzioni pronte.

Python: requests e Scrapy

Python è il linguaggio più popolare per il parsing grazie alle librerie requests, BeautifulSoup e Scrapy.

Esempio con la libreria requests:

import requests
import random
import time

# Lista proxy (ottenuta dal provider)
PROXIES = [
    'http://user:[email protected]:8080',
    'http://user:[email protected]:8080',
    'http://user:[email protected]:8080'
]

# Lista User-Agent per rotazione
USER_AGENTS = [
    'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36',
    'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36',
    'Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36'
]

def parse_vacancy(url):
    proxy = random.choice(PROXIES)
    user_agent = random.choice(USER_AGENTS)
    
    headers = {
        'User-Agent': user_agent,
        'Accept': 'text/html,application/xhtml+xml',
        'Accept-Language': 'it-IT,it;q=0.9,en;q=0.8',
        'Accept-Encoding': 'gzip, deflate, br',
        'Connection': 'keep-alive'
    }
    
    proxies = {
        'http': proxy,
        'https': proxy
    }
    
    try:
        response = requests.get(
            url,
            headers=headers,
            proxies=proxies,
            timeout=30
        )
        
        if response.status_code == 200:
            return response.text
        elif response.status_code == 429:
            print(f'Rate limit per {proxy}, cambio proxy')
            # Rimuoviamo temporaneamente il proxy dalla lista
            return None
        else:
            print(f'Errore {response.status_code}')
            return None
            
    except Exception as e:
        print(f'Errore richiesta: {e}')
        return None

# Utilizzo
for i in range(100):
    html = parse_vacancy('https://hh.ru/vacancy/123456')
    if html:
        # Elaborazione dati
        pass
    
    # Ritardo casuale
    time.sleep(random.uniform(4, 8))

Esempio configurazione Scrapy:

# settings.py

# Abilitiamo il supporto proxy
DOWNLOADER_MIDDLEWARES = {
    'scrapy.downloadermiddlewares.httpproxy.HttpProxyMiddleware': 110,
    'scrapy_rotating_proxies.middlewares.RotatingProxyMiddleware': 610,
    'scrapy_rotating_proxies.middlewares.BanDetectionMiddleware': 620,
}

# Lista proxy
ROTATING_PROXY_LIST = [
    'http://user:[email protected]:8080',
    'http://user:[email protected]:8080',
    'http://user:[email protected]:8080'
]

# Rilevamento automatico ban
ROTATING_PROXY_BAN_POLICY = 'scrapy_rotating_proxies.policy.BanDetectionPolicy'

# Ritardo tra richieste
DOWNLOAD_DELAY = 5
RANDOMIZE_DOWNLOAD_DELAY = True  # Ritardo casuale ±50%

# Rotazione User-Agent
DOWNLOADER_MIDDLEWARES.update({
    'scrapy.downloadermiddlewares.useragent.UserAgentMiddleware': None,
    'scrapy_user_agents.middlewares.RandomUserAgentMiddleware': 400,
})

# Massimo richieste simultanee
CONCURRENT_REQUESTS = 4
CONCURRENT_REQUESTS_PER_DOMAIN = 1

Node.js: Puppeteer con proxy

Per il parsing di siti con JavaScript (LinkedIn, Indeed) serve un browser headless. Puppeteer è la soluzione più popolare per Node.js.

const puppeteer = require('puppeteer-extra');
const StealthPlugin = require('puppeteer-extra-plugin-stealth');

// Plugin per bypassare il rilevamento browser headless
puppeteer.use(StealthPlugin());

async function parseWithProxy() {
  const proxy = 'http://user:[email protected]:8080';
  
  const browser = await puppeteer.launch({
    headless: true,
    args: [
      `--proxy-server=${proxy}`,
      '--no-sandbox',
      '--disable-setuid-sandbox',
      '--disable-dev-shm-usage',
      '--disable-blink-features=AutomationControlled'
    ]
  });
  
  const page = await browser.newPage();
  
  // Impostiamo User-Agent reale
  await page.setUserAgent(
    'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36'
  );
  
  // Impostiamo viewport
  await page.setViewport({ width: 1920, height: 1080 });
  
  try {
    await page.goto('https://hh.ru/search/vacancy', {
      waitUntil: 'networkidle2',
      timeout: 30000
    });
    
    // Elaborazione pagina
    const content = await page.content();
    
    // Chiudiamo browser
    await browser.close();
    
    return content;
    
  } catch (error) {
    console.error('Errore parsing:', error);
    await browser.close();
    return null;
  }
}

// Utilizzo con ritardi casuali
async function main() {
  for (let i = 0; i < 100; i++) {
    const html = await parseWithProxy();
    
    if (html) {
      // Elaborazione dati
    }
    
    // Ritardo casuale 4-8 secondi
    const delay = Math.random() * 4000 + 4000;
    await new Promise(resolve => setTimeout(resolve, delay));
  }
}

main();

Conclusioni e raccomandazioni

Il parsing dei job board richiede un approccio attento alla scelta e configurazione dei proxy. Riassumiamo i punti chiave:

La scelta corretta dei proxy e la loro configurazione permettono di costruire un sistema stabile di raccolta dati dai job board che funzionerà per anni senza blocchi. Iniziate con piccoli volumi, testate diverse configurazioni e aumentate gradualmente la scala del parsing.

Se avete bisogno di proxy affidabili per il parsing dei job board, ProxyCove offre proxy residenziali e mobili con geolocalizzazione in oltre 195 paesi, rotazione automatica e supporto tecnico 24/7.