Analizzare il traffico HTTP con tcpdump su un server Linux VPS SSD

Quando tcpdump serve davvero su un VPS Linux

Se un sito risponde male, non basta sapere che “la rete funziona”. Su un VPS Linux con SSD il punto è capire dove si rompe il flusso HTTP: DNS, handshake TCP, TLS, request dell’applicazione o risposta del backend. tcpdump è lo strumento giusto quando vuoi vedere i pacchetti sul filo, senza introdurre proxy o cambiare la configurazione del servizio. È grezzo, ma proprio per questo è affidabile.

La regola pratica è semplice: usa tcpdump quando ti serve un’evidenza di rete, non un’interpretazione di alto livello. Se il problema è una pagina bianca PHP, una latenza anomala o un 502 dietro Nginx, tcpdump ti dice se il traffico HTTP arriva, se l’origin risponde, se i segmenti TCP vengono ritrasmessi e se il client chiude la connessione troppo presto. Non ti risolve l’incidente da solo, ma ti evita diagnosi a intuito.

Che cosa osservare prima di catturare

Prima di lanciare una cattura, chiarisci il layer. In genere il percorso è: client → DNS → edge/CDN → VPS → web server → app → database. tcpdump vede bene il tratto di rete sul VPS, quindi le domande utili sono: la richiesta arriva al server? la risposta parte? ci sono ritrasmissioni? il traffico è HTTP in chiaro o HTTPS?

Su un VPS SSD non cambia il fatto che il collo di bottiglia possa essere CPU, disco o rete. Però un disco lento può riflettersi nel traffico con risposte tardive e connessioni lasciate aperte. Per questo conviene affiancare alla cattura almeno un controllo rapido dello stato del servizio e della saturazione:

systemctl status nginx --no-pager
journalctl -u nginx -n 50 --no-pager
ss -s
free -h

Se il sito è dietro HTTPS, tcpdump non leggerà il contenuto delle richieste senza chiavi o terminazione lato server. In quel caso l’obiettivo realistico è vedere porte, handshake, flussi, reset e ritrasmissioni. Per HTTP in chiaro, invece, puoi leggere anche il metodo e l’URL, ma è una condizione da usare solo in ambienti controllati o di test.

Filtro base: vedere solo il traffico HTTP utile

La prima abitudine da prendere è filtrare bene. Una cattura senza filtri su un VPS trafficato produce rumore, non diagnosi. Se il server espone HTTP sulla porta 80, parti così:

sudo tcpdump -i any -nn -s 0 -A port 80

Qui ci sono tre scelte importanti. -i any ascolta tutte le interfacce; -nn evita la risoluzione di nomi e servizi, così non perdi tempo; -s 0 cattura il pacchetto completo, non un frammento. L’opzione -A stampa il payload in ASCII, utile per leggere header e richieste HTTP in chiaro.

Se vuoi ridurre ulteriormente il rumore, limita l’host o la subnet. Per esempio, per vedere solo il traffico tra un client e il VPS:

sudo tcpdump -i any -nn -s 0 -A host 203.0.113.10 and port 80

Questo è il filtro più utile quando devi capire se la richiesta arriva davvero dal client atteso. Se non compare nulla, hai già un’indicazione: il problema è prima del web server, quindi DNS, routing, firewall o CDN.

Leggere una richiesta HTTP in chiaro senza farsi ingannare

Con traffico non cifrato, tcpdump mostra direttamente i primi byte del protocollo. Una richiesta tipica appare con GET, POST, Host, User-Agent e magari cookie o parametri. Il punto non è “leggere tutto”, ma verificare la forma della richiesta e il tempo di risposta.

Un esempio di output sintetico può mostrarti qualcosa del genere:

IP 198.51.100.24.53144 > 203.0.113.20.80: Flags [P.], seq 1:512, ack 1, win 502, length 511: HTTP: GET /index.php HTTP/1.1

Se dopo la richiesta vedi subito un ACK e poi una risposta con HTTP/1.1 200 OK, il percorso base funziona. Se invece la richiesta parte ma non arriva alcuna risposta, la diagnosi si sposta su web server, applicazione o backend. Se il client ritrasmette più volte lo stesso segmento, il problema è spesso latenza, perdita di pacchetti o path degradato.

Attenzione a non confondere assenza di payload con assenza di traffico. Con connessioni keep-alive, HTTP/2 o risposta compressa, quello che vedi può essere meno intuitivo. tcpdump ti dà indizi di trasporto; per il contenuto applicativo servono anche log del server e metriche dell’app.

Quando il sito usa HTTPS: cosa puoi vedere davvero

Con HTTPS il contenuto HTTP è cifrato. Non è un limite dello strumento, è il comportamento corretto del protocollo. tcpdump resta comunque utile per verificare la parte visibile del flusso: SYN, SYN/ACK, ACK, handshake TLS, dimensione dei pacchetti, reset, chiusure anomale e ritrasmissioni.

Per un sito dietro TLS, il primo test è capire se la sessione si apre correttamente sulla porta 443:

sudo tcpdump -i any -nn -s 0 port 443

Se vuoi un segnale più leggibile, puoi limitarti ai pacchetti TCP e osservare solo il comportamento del trasporto. In pratica cerchi cose come:

• molti retransmissions, segno di perdita o congestione;
• RST dal server, spesso app o proxy che chiude bruscamente;
• connessioni aperte ma senza dati, tipiche di backend bloccato o timeout interni;
• handshake TLS incompleto, utile per distinguere un problema di certificato da uno di rete.

Se hai bisogno di contenuto applicativo su HTTPS, non forzare scorciatoie improvvisate. La via corretta è usare i log dell’origin, eventualmente una cattura lato backend in un ambiente di test o strumenti dedicati a livello applicativo. tcpdump resta il primo passo, non l’ultimo.

Capire se il problema è nel web server o nell’applicazione

Un caso tipico su VPS Linux è questo: il sito risponde lentamente o restituisce 502/504. tcpdump aiuta a capire se Nginx o Apache sta parlando con il backend e con che tempi. Se il traffico arriva al proxy ma non vedi risposta dal servizio upstream, il collo di bottiglia può essere PHP-FPM, Node.js, Python, un database lento o un socket non raggiungibile.

Per separare il livello web dal backend, osserva la connessione locale tra proxy e servizio applicativo. Per esempio, se il backend ascolta su una porta locale:

sudo tcpdump -i lo -nn -s 0 port 9000

Se non compare traffico sul loopback mentre il web server prova a servire una pagina dinamica, il problema è nella configurazione del proxy o nel routing interno. Se invece il traffico c’è ma la risposta tarda, guarda log e metriche del backend. In altre parole: tcpdump ti dice se il proxy tenta la connessione; i log ti dicono perché fallisce.

Un dettaglio utile è il tempo. Se una richiesta parte subito ma la risposta arriva dopo parecchi secondi, il problema non è “internet lento” in senso generico. Di solito c’è un ritardo nel server o nel backend. Se invece la richiesta non esce proprio, sospetta socket saturati, limiti di file descriptor o coda di accettazione piena.

Filtri più pratici per l’uso quotidiano

Nella pratica non usi sempre la cattura “totale”. Conviene avere alcuni filtri pronti, da adattare al servizio. Questi sono quelli che tornano più spesso su un VPS:

# Traffico HTTP verso il server
sudo tcpdump -i any -nn -s 0 host 203.0.113.20 and port 80

# Traffico HTTPS verso il server
sudo tcpdump -i any -nn -s 0 host 203.0.113.20 and port 443

# Solo client specifico
sudo tcpdump -i any -nn -s 0 src 198.51.100.24 and port 443

# Solo pacchetti TCP con flag RST
sudo tcpdump -i any -nn -s 0 'tcp[tcpflags] & tcp-rst != 0'

Il filtro sui reset è prezioso. Un RST non è sempre un errore, ma se compare durante una transazione web può indicare chiusura brutale da parte di proxy, firewall o applicazione. Se il reset parte dal client, può essere timeout lato browser o bilanciatore. Se parte dal server, vai a cercare errori applicativi o limiti di risorse.

Salvare una cattura senza riempire il disco

Su un VPS SSD il rischio non è teorico: una cattura lunga può occupare spazio in fretta. Se devi analizzare con calma, salva in file pcap e imposta una rotazione o una durata limitata. Esempio:

sudo tcpdump -i any -nn -s 0 -w /tmp/http-debug.pcap port 80

Quando hai finito, analizza il file con un secondo passaggio. Questo evita di tenere aperta una sessione live troppo a lungo e riduce il rumore operativo. Se lavori su un server sotto carico, è una scelta più pulita rispetto alla stampa continua a schermo.

Se vuoi tenere sotto controllo il blast radius, usa una directory temporanea con spazio noto e verifica prima la capienza:

df -h /tmp
ls -lh /tmp/http-debug.pcap

Il rollback qui è semplice: interrompi la cattura con Ctrl+C e rimuovi il file quando non serve più. Nessun servizio viene toccato, quindi il rischio operativo è basso, ma il rischio di disco pieno va sempre considerato.

Errori di lettura comuni che fanno perdere tempo

Il primo errore è credere che tcpdump debba “dire la verità completa”. In realtà mostra solo ciò che attraversa l’interfaccia osservata. Se guardi l’interfaccia sbagliata, o il traffico passa da una namespace diversa, non vedrai nulla e concluderai male. Su VPS con container, bridge o reverse proxy multipli, questo è un classico.

Il secondo errore è ignorare la direzione del traffico. Vedere una richiesta uscire non significa che il server abbia risposto bene. Per questo conviene controllare sia entrata sia uscita, soprattutto quando cerchi 5xx, timeout o ritardi. Se vuoi un quadro più completo, osserva anche le statistiche TCP con ss o i contatori del web server.

Il terzo errore è fermarsi al pacchetto singolo. Un pacchetto isolato non basta: servono sequenza, ritrasmissioni, tempi e, quando possibile, confronto con i log applicativi. La diagnosi buona nasce dall’incrocio tra rete e servizio, non da una sola riga di output.

Workflow rapido per un incidente reale

Quando un utente segnala “il sito non carica”, il flusso operativo dovrebbe essere lineare. Prima controlli il layer visibile, poi catturi il traffico, poi confronti con i log. Un ordine pratico è questo:

1. Verifica che il servizio risponda localmente con curl -I http://127.0.0.1 o curl -kI https://127.0.0.1, in base al setup.
2. Avvia tcpdump con filtro stretto sulla porta interessata e sul client o host sospetto.
3. Osserva se la richiesta entra, se la risposta esce e se compaiono reset o ritrasmissioni.
4. Controlla i log del web server in /var/log/nginx/ o /var/log/apache2/, più i log dell’applicazione.
5. Se il traffico c’è ma la risposta manca, sposta l’analisi su backend, database o limiti di risorse.

Questo workflow evita due trappole: cambiare configurazioni a caso e inseguire sintomi senza evidenza. tcpdump è più utile quando lo usi per falsificare ipotesi, non per “guardare se succede qualcosa”.

Conclusione operativa: cosa ti lascia tcpdump in mano

Su un server Linux VPS SSD, tcpdump è lo strumento che ti permette di trasformare un sospetto generico in una prova concreta. Se il traffico HTTP non arriva, hai un problema prima dell’applicazione. Se arriva ma non torna indietro, il punto è nel server o nel backend. Se torna con reset, ritardi o ritrasmissioni, hai un indizio forte su saturazione, chiusure anomale o degrado di rete.

La parte più utile non è la cattura in sé, ma la disciplina con cui la leggi: filtro stretto, confronto con i log, attenzione al layer giusto e niente conclusioni affrettate. Su un VPS ben gestito, questa abitudine fa risparmiare tempo più di qualsiasi ottimizzazione “a sensazione”.