Il portale è irraggiungibile ma il server è acceso: quando il problema è nel DNS e come diagnosticarlo in 10 minuti
Un e-commerce Laravel era irraggiungibile da 6 ore - il server Hetzner era online, Nginx rispondeva, MySQL funzionava. Il problema: il dominio era stato trasferito a un nuovo registrar la sera prima, e il record NS ancora puntava ai nameserver del vecchio provider che aveva già cancellato la zona DNS. Diagnosi in 10 minuti con dig e whois, fix con TTL basso e propagazione controllata, e le 5 misconfigurazioni DNS che trovo più spesso su VPS di PMI. Continua a leggere
Ultima modifica:
Un portale B2B Laravel su VPS OVH andava in 502 Bad Gateway ogni giorno tra le 10 e le 11 del mattino - l'ora di punta degli ordini. PHP-FPM veniva ucciso dall'OOM killer del kernel perché pm.max_children era impostato a 200 su un server con 8 GB di RAM e worker da 80 MB ciascuno. La matematica non tornava: 200 × 80 MB = 16 GB, il doppio della RAM disponibile. Diagnosi con dmesg, tuning di pm.max_children, auto-restart con systemd e prevenzione. 
Un VPS Hetzner con Redis 6 esposto su 0.0.0.0:6379 senza password. Un attaccante ha usato il motore Lua integrato per scrivere un crontab che scaricava un cryptominer Monero. CPU al 100%, Laravel a 12 secondi di response time, e nessuno sapeva perché. Il caso reale di un SaaS piemontese del luglio 2025, la diagnosi in 40 minuti, l'eradicazione e l'hardening di Redis per impedire che succeda di nuovo. 
Un CRM Laravel 9 per una PMI logistica veneta è stato compromesso perché un file .env con l'APP_KEY era stato committato su un repository GitHub pubblico due anni prima. L'attaccante ha sfruttato CVE-2018-15133 per ottenere esecuzione remota di codice tramite cookie deserializzato, ha piantato una backdoor in un comando Artisan e ha esfiltrato 4.200 record clienti. Cinque giorni di lavoro: contenimento senza distruzione delle prove, forensics applicativa, remediation e hardening permanente. 
Quando il sito entra in maintenance mode per un deploy finito male e nessuno lo sa riportare online, il business perde fatturato per mesi in silenzio. Il caso reale di un e-commerce B2B HoReCa bolognese del giugno 2025 su Contabo VPS L, Laravel 9.52 in manutenzione da dodici settimane, il deploy abortito a metà con migration orfane e code bloccate, e i quattro giorni di lavoro con cui ho ricostruito lo stato consistente senza rifare l'applicazione. 
Quando il team di sviluppo esterno chiude senza preavviso, il codice Laravel continua a girare ma i pezzi che non vedi - scheduler, Horizon, queue workers, notifiche transazionali - smettono di funzionare in silenzio. Il caso reale di un SaaS torinese di fleet management del giugno 2025, un Hetzner AX52 con Laravel 10 e Spatie Multi-Tenancy, 47 tenant attivi e 13.000 clienti finali, e i cinque giorni di lavoro con cui ho riportato l'applicazione a regime senza rifare nulla. 
Quando un sito PHP viene compromesso su un server Hetzner o OVH, il riflesso istintivo del cliente è "rimuovere i file infetti e ripartire". È sbagliato e fa danni. Il protocollo corretto è cinque fasi strutturate: contenimento immediato senza distruggere evidenze, raccolta forensics, eradicazione completa, ripristino da fonte fidata, hardening permanente. E sotto NIS2 va aggiunta una sesta fase giuridica: la notifica al Garante entro 72 ore. 
Un incidente IT mal gestito può bloccare la tua azienda e causare perdite irreparabili. Scopri perché adottare subito una strategia di Incident Management efficace è cruciale per garantire sicurezza, continuità operativa e competitività.