Quali specifiche di VPS mi servono per il web scraping?

Dipende dallo stack. Uno scraper HTTP semplice (httpx/requests che colpisce API o HTML statico) è leggero — un Nano da $3 con 1 GB basta e avanza. Nel momento in cui ti serve un vero browser per siti JavaScript-pesanti, Playwright con Chromium headless vuole 2–4 GB: un Micro da $5 per uno o due contesti browser, uno Small da $8 se ne fai girare diversi in parallelo. Chromium è il divoratore di RAM, non il tuo codice.

Posso fare scraping dall'IP del server, o mi servono proxy?

Per scraping a basso volume e ben educato di siti che lo permettono, l'IP del server va bene. Su scala, o contro siti che fanno rate-limit per IP, ti servirà un pool di proxy esterni — un solo IP (condiviso o dedicato) non può distribuire il carico, e martellare da un singolo indirizzo lo fa bloccare in fretta. Un IP dedicato ti dà una reputazione pulita che controlli; i proxy te ne danno molti.

cron o timer systemd per scraping pianificati?

Un timer systemd, in quasi ogni caso. A differenza di cron ti dà logging adeguato via journalctl, ordinamento delle dipendenze, recupero automatico se la macchina era spenta, e stato per-run che puoi ispezionare. cron funziona ancora per job semplicissimi, ma un timer è il default migliore su un server che mantieni davvero.

Il web scraping è permesso sul VPS?

Scraping legale e rispettoso — sì. Scraping aggressivo che ignora rate limit o robots.txt, o che equivale a martellare un bersaglio fino al denial of service, è una violazione della policy d'uso accettabile e porta alla terminazione del servizio. Fai scraping di ciò che ti è permesso, autolimitati, e non trasformare uno scraper in un attacco.

VPS per il web scraping: setup, dimensionamento e limiti onesti

Uno scraper sul tuo laptop va bene finché non lo chiudi a metà run, il tuo IP di casa viene rate-limitato, o vuoi che lo stesso job giri ogni ora che tu sia sveglio o no. Spostarlo su un VPS sistema tutti e tre: resta su 24/7, non brucia la reputazione del tuo IP di casa, e cron o un timer systemd lo esegue su pianificazione senza di te. Ecco come impostarlo, quanto server ti serve davvero, e le parti che la maggior parte delle guide salta silenziosamente.

Perché un VPS batte la tua macchina per questo

24/7 e pianificato. Uno scraper che gira ogni ora ha bisogno di un host sempre attivo. Un laptop non lo è.
Il tuo IP di casa resta pulito. Fare scraping da casa significa che il tuo IP residenziale prende i rate-limit e i blocchi. Fallo da un server e la tua connessione resta intatta.
Stabilità. Niente sospensione, niente cadute di wifi a metà crawl, una connessione datacenter stabile, e un posto dove accumulare risultati.

Lo stack, e cosa serve a ciascuna parte

Due classi di peso molto diverse, e scegliere il piano sbagliato spreca soldi o affama il job:

httpx / requests (Python) — per API, endpoint JSON e HTML statico. Questo è leggero: il processo sta in decine di megabyte, network-bound, non CPU-bound. Un Nano da $3 (1 vCPU / 1 GB) lo fa girare comodamente, anche con concorrenza via asyncio.
Playwright / Chromium headless — per siti renderizzati in JavaScript dove ti serve un vero browser. Questo è quello pesante. Chromium headless è grosso modo 300–400 MB per istanza di browser, più 100–200 MB per contesto/scheda aperto, più il tuo runtime. Prevedi:
- Micro da $5 (2 vCPU / 2 GB) — uno o due contesti browser alla volta.
- Small da $8 (4 vCPU / 4 GB) — diversi contesti paralleli, o pagine più pesanti.

La regola pratica: il tuo codice non è quasi mai il collo di bottiglia — Chromium lo è. Dimensiona per il browser, non per lo scraper.

Pianificazione: timer systemd al posto di cron

cron funziona, ma un timer systemd è il default migliore su un server che mantieni: log tramite journalctl, recupero se la macchina era spenta, e stato per-run ispezionabile. Un setup minimale:

# /etc/systemd/system/scrape.service
[Unit]
Description=Run scraper
[Service]
Type=oneshot
User=scraper
WorkingDirectory=/home/scraper/job
ExecStart=/home/scraper/job/venv/bin/python scrape.py

# /etc/systemd/system/scrape.timer
[Unit]
Description=Hourly scrape
[Timer]
OnCalendar=hourly
Persistent=true
[Install]
WantedBy=timers.target

sudo systemctl enable --now scrape.timer
journalctl -u scrape.service -f   # guarda i run

Persistent=true è la cosa che cron non può fare: se il server era spento all'ora di run, il job scatta una volta al boot invece di saltare silenziosamente.

Dove vanno i risultati

Tienilo semplice e abbinalo al volume: SQLite per dati strutturati che interrogherai (un file, zero setup), CSV per dump tabulari veloci, o un object store compatibile S3 quando i risultati superano la macchina o li vuoi fuori dal server. Ruota i tuoi log (logrotate o limiti di journald) così uno scraper loquace non riempie lentamente il disco.

La parte onesta: IP di egress e reputazione

È il dettaglio che decide se il tuo scraper funziona per una settimana o viene bloccato il primo giorno.

Su un piano NAT, il traffico in uscita condivide un IP di egress con altri clienti. La reputazione di quell'IP è condivisa — un vicino che fa scraping dello stesso bersaglio può far rate-limitare l'indirizzo prima che tu mandi una singola richiesta. Va bene per scraping leggero e occasionale; una passività su scala.

Un IP dedicato ti dà la tua reputazione di egress — il comportamento di nessun altro la influenza. Ma taglia in entrambi i sensi: lo scraping aggressivo brucia il tuo stesso IP pulito, e una volta che un bersaglio lo blocca, è bloccato. Un IP dedicato è controllo, non immunità.

Su scala reale, ti servono pool di proxy esterni. Nessun singolo IP — condiviso o dedicato — può distribuire il carico su molti indirizzi, che è ciò che lo scraping serio contro bersagli con rate-limit per IP richiede. I proxy sono uno strato generico di terze parti che aggiungi sopra; il VPS fa girare lo scraper, il pool di proxy fornisce gli indirizzi. Non aspettarti che un IP di un server faccia il lavoro di un pool di proxy.

Etica e la AUP — non opzionale

Lo scraping vive in una zona grigia legale ed etica, quindi sii lucido:

Rispetta rate limit e robots.txt. Autolimita le tue richieste. Uno scraper educato sembra traffico; uno maleducato sembra un attacco.
Non fare DoS del tuo bersaglio. Martellare un sito finché non crolla non è scraping, è un denial-of-service — ed è una violazione della policy d'uso accettabile qui che porta alla terminazione del servizio.
Fai scraping solo di ciò che ti è permesso. La raccolta dati legale e permessa è la linea. Attraversala ed è colpa tua.

In conclusione

Un VPS è la casa giusta per uno scraper: sempre attivo, pianificato, e fuori dal tuo IP di casa. Abbina il piano allo stack — Nano da $3 per httpx, da Micro $5 a Small $8 per Playwright — pianifica con un timer systemd, e sii onesto sugli IP: l'egress condiviso condivide reputazione, un IP dedicato è tuo da costruire o bruciare, e la scala reale significa pool di proxy. Blinda prima la macchina con la checklist di sicurezza per un nuovo VPS, dimensionala bene usando la guida al dimensionamento VPS, e se la privacy del pagare-senza-carta conta, l'analisi del VPS anonimo è la versione onesta. Fai scraping responsabilmente — la AUP è reale.

Pronto a fare scraping? Un piano Micro è un solido inizio; i grandi crawl concorrenti vanno meglio su Small.