1 12/04/2026 10 min

Verificare davvero la velocità di Internet da Ubuntu

Se vuoi capire quanto va la tua connessione da terminale in Ubuntu, la domanda giusta non è solo “quanti Mbps ho”, ma che cosa stai misurando. Banda nominale, latenza, jitter, perdita pacchetti e saturazione del link sono cose diverse. Un test fatto male ti dice poco: magari il server di test è lontano, il DNS è lento, il Wi‑Fi sta degradando o stai misurando mentre un backup occupa tutta la linea.

La regola pratica è semplice: prima osservi lo stato della rete locale, poi misuri la connettività verso l’esterno, infine fai un test di throughput vero e proprio. In questo modo separi il problema di accesso a Internet da quello del tuo host, del router, del provider o del server remoto.

Classificare il test prima di lanciare comandi

Per una verifica sensata conviene distinguere tre casi. Il primo è il troubleshooting: la rete sembra lenta o instabile e vuoi capire dove si rompe. Il secondo è un change controllato: hai cambiato router, DNS, scheda Wi‑Fi, MTU o piano ISP e vuoi confrontare prima e dopo. Il terzo è un controllo periodico di performance: ti interessa una metrica ripetibile, non un numero isolato.

Stato atteso vs osservato: ti aspetti una latenza coerente, nessuna perdita pacchetti verso il gateway e una velocità in download/upload compatibile con il profilo della linea. Se invece vedi timeout, throughput molto sotto soglia o picchi di latenza sotto carico, il collo di bottiglia non è “Internet” in astratto: è un layer preciso da identificare.

Prima verifica il layer locale: link, IP, gateway e DNS

La maggior parte dei test sbagliati nasce da qui. Se la scheda è su Wi‑Fi debole, se il gateway non risponde bene o se il DNS introduce ritardi, il test di velocità diventa rumore. Su Ubuntu parti da comandi semplici e leggibili.

1. Verifica l’interfaccia attiva e lo stato del link:

ip -br link
ip -br addr

Atteso: l’interfaccia usata per uscire in Internet risulta UP, ha un indirizzo IPv4 o IPv6 coerente e non mostra stati anomali. Se vedi DOWN, UNKNOWN o nessun indirizzo, il problema è locale e il test di banda non ha ancora senso.

2. Controlla il gateway e la rotta predefinita:

ip route
ip route get 1.1.1.1

Atteso: una default route valida e un next hop coerente. Se il traffico esce da un’interfaccia diversa da quella attesa, stai misurando un percorso non voluto, spesso con VPN, policy routing o multi-homing di mezzo.

3. Misura la latenza verso il gateway e verso un host esterno affidabile:

ping -c 5 192.168.1.1
ping -c 5 1.1.1.1

Il primo ping ti dice se il problema è già nel segmento LAN o Wi‑Fi. Il secondo ti dice se il problema è oltre il router. Se il gateway risponde male, non ha senso dare la colpa al provider.

4. Verifica che il DNS non stia falsando la percezione di lentezza:

resolvectl status
systemd-resolve --statistics 2>/dev/null || true

Se la risoluzione è lenta, i siti sembrano “lenti” anche quando la banda è buona. Un DNS che impiega centinaia di millisecondi o secondi non abbassa i Mbps, ma peggiora il tempo percepito di apertura delle pagine.

Il test più semplice: speedtest-cli o Ookla Speedtest

Per una misura sintetica della velocità di Internet, il riferimento più pratico su Ubuntu è Speedtest CLI. Esistono due strade: il client ufficiale Ookla oppure il vecchio pacchetto Python speedtest-cli. Se devi fare misure ripetibili, preferisci il client ufficiale: è più allineato ai server e al comportamento del servizio web di riferimento.

Installazione del client ufficiale su Ubuntu recente:

sudo apt update
sudo apt install curl gnupg -y
curl -s https://packagecloud.io/install/repositories/ookla/speedtest-cli/script.deb.sh | sudo bash
sudo apt install speedtest -y

Se preferisci il pacchetto nei repository standard, puoi usare:

sudo apt update
sudo apt install speedtest-cli -y

Il test base si lancia così:

speedtest

Output tipico: download, upload, latenza, server selezionato e indirizzo IP pubblico. Il valore utile non è solo il numero finale, ma anche il server scelto. Se il server è lontano o saturo, il risultato può sottostimare la tua linea.

Per evitare selezioni casuali, elenca i server e scegli quello più vicino o quello del tuo ISP:

speedtest -L
speedtest -s <server_id>

Questo rende il confronto più stabile nel tempo. Se misuri ogni settimana, usa sempre lo stesso server o una piccola rosa di server fissi.

Misurare download e upload senza tool dedicati

Se non vuoi installare client specifici, puoi fare una verifica grezza ma utile con curl o wget. Non sostituiscono un test di throughput completo, però ti danno un’indicazione rapida sulla capacità di scaricare da un endpoint noto.

Con curl puoi misurare il tempo di trasferimento e il volume scaricato:

curl -o /dev/null -s -w '
DNS: %{time_namelookup}s
Connect: %{time_connect}s
TLS: %{time_appconnect}s
StartTransfer: %{time_starttransfer}s
Total: %{time_total}s
Speed: %{speed_download} B/s
' https://speed.hetzner.de/100MB.bin

Qui stai leggendo sia le fasi di connessione sia la velocità media di download. È utile per capire se il collo di bottiglia è nel DNS, nel TLS, nel primo byte o nel throughput puro. Se il file di test è raggiungibile ma il numero è molto basso, il problema è reale; se il server remoto è congestionato, il test perde significato.

Con wget ottieni un feedback simile:

wget -O /dev/null https://speed.hetzner.de/100MB.bin

Questo comando mostra la velocità media di download. È meno dettagliato di curl, ma spesso basta per capire se la linea è in linea con le aspettative.

Il test migliore per la rete locale: iperf3

Se vuoi sapere quanto va davvero la tua rete, iperf3 è spesso più utile di un test verso Internet. Non misura la tua uscita sul provider, ma misura il trasferimento tra due host controllati. Per questo è lo strumento giusto quando devi capire se il problema è il Wi‑Fi, il cavo, lo switch, il router o la CPU del client.

Installa il pacchetto:

sudo apt update
sudo apt install iperf3 -y

Su un server remoto o su un secondo host della tua rete avvia il listener:

iperf3 -s

Dal client esegui il test in download dal server verso il client:

iperf3 -c 192.0.2.10

Per testare l’upload verso il server:

iperf3 -c 192.0.2.10 -R

Se il risultato è molto più basso del previsto, controlla se il client è su Wi‑Fi, se la CPU sta saturando o se il percorso passa da una VPN. Con iperf3 puoi anche fare test paralleli:

iperf3 -c 192.0.2.10 -P 4

Questa opzione è utile perché alcune connessioni non saturano bene con un solo flusso TCP. Un singolo stream può sottostimare la banda disponibile, soprattutto con latenze alte o window scaling non ottimale.

Capire se il collo di bottiglia è il Wi‑Fi

Su Ubuntu, il Wi‑Fi è spesso il primo sospettato quando la velocità cala. Non basta vedere “connesso”: serve controllare qualità del segnale, bitrate negoziato e eventuali ritrasmissioni. Con nmcli e iw puoi fare un controllo rapido.

Stato della connessione:

nmcli dev status
nmcli -f IN-USE,SSID,SIGNAL,CHAN,RATE,SECURITY dev wifi list

Per il dettaglio dell’interfaccia wireless:

iw dev
iw dev wlan0 link

Atteso: segnale decente, bitrate coerente con la banda e nessuna disconnessione frequente. Se il link negozia a velocità bassa, il test di Internet riflette il problema del mezzo radio, non del provider.

Un esempio concreto: una linea FTTH da 1 Gbps può sembrare “lenta” su un portatile che naviga in 2.4 GHz con segnale mediocre. In quel caso il test di speedtest conferma il sintomo, ma la causa è il Wi‑Fi locale. La soluzione non è cambiare ISP: è spostarsi su 5 GHz, migliorare il posizionamento del router o usare cavo Ethernet.

Misurare latenza, jitter e perdita pacchetti

La velocità pura non basta. Se la latenza sale o c’è perdita pacchetti, la navigazione diventa comunque pessima anche con una banda teorica elevata. Per una diagnosi rapida usa ping e, se serve, mtr.

Ping verso gateway e host esterno:

ping -c 20 192.168.1.1
ping -c 20 1.1.1.1

Se vuoi un quadro più ricco del percorso:

sudo apt install mtr -y
mtr -rw 1.1.1.1

Con mtr osservi perdita e latenza hop per hop. Tieni presente che alcuni router limitano o deprioritizzano ICMP: una perdita sugli hop intermedi non è automaticamente un problema, mentre la perdita sull’ultimo hop è molto più significativa.

Interpretare i numeri senza farsi ingannare

Un test di velocità da terminale va letto con criterio. Se il download è alto ma l’upload è basso, puoi avere un problema sul ramo upstream, nel router o nella configurazione del Wi‑Fi. Se la latenza è bassa ma il throughput è scarso, potresti avere una limitazione del server di test, una congestione locale o un’interfaccia che negozia male.

Tre falsi positivi tipici:

  1. server di test lontano o saturo;
  2. altra attività di rete in corso, come backup cloud o aggiornamenti;
  3. misura fatta su Wi‑Fi instabile invece che su cavo.

Tre falsi negativi tipici:

  1. test su un solo flusso TCP che non satura la linea;
  2. browser o applicazioni che mantengono cache e fanno sembrare tutto più veloce di quanto sia;
  3. DNS lento confuso con banda bassa.

Se vuoi un confronto serio, ripeti il test almeno tre volte, a distanza di pochi minuti, e annota orario, server, interfaccia e tipo di collegamento. Una singola misura non fa statistica.

Un metodo pratico e ripetibile

Se devi standardizzare la verifica su Ubuntu, usa questa sequenza. È semplice, ripetibile e ti evita di confondere il problema di rete con quello del terminale.

  1. Controlla interfaccia, IP e rotta con ip -br addr e ip route.
  2. Misura latenza verso gateway e host esterno con ping.
  3. Fai un test sintetico con speedtest scegliendo un server stabile.
  4. Conferma con curl o wget su un file di dimensioni note.
  5. Se devi separare rete locale e Internet, usa iperf3 tra due host controllati.

Questa sequenza ti dà una lettura gerarchica: prima escludi il locale, poi confermi l’uscita, poi misuri la capacità effettiva. È molto più affidabile che lanciare un singolo comando e fidarsi del numero finale.

Automatizzare il controllo con uno script minimale

Se vuoi salvare i risultati nel tempo, puoi creare uno script che raccoglie i dati principali. Non serve complicare: basta produrre un file con data, gateway, latenza e velocità. L’obiettivo è confrontare i test, non costruire un benchmark scientifico.

#!/usr/bin/env bash
set -euo pipefail

TS=$(date -Iseconds)
GW=$(ip route | awk '/default/ {print $3; exit}')
PING=$(ping -c 3 -q 1.1.1.1 | awk -F'/' '/rtt/ {print $5}')
DL=$(speedtest --accept-license --accept-gdpr 2>/dev/null | awk -F': ' '/Download/ {print $2; exit}')

printf '%s gateway=%s ping_ms=%s download=%s\n' "$TS" "$GW" "$PING" "$DL"

Questo esempio è intenzionalmente semplice. In un contesto reale puoi salvare l’output su file, inviarlo a syslog o collezionarlo in un sistema di monitoring. L’importante è mantenere costante il metodo di misura.

Quando il test non basta e serve guardare altrove

Se i risultati sono incoerenti, non insistere solo sul test di velocità. Controlla dmesg per errori di rete, journalctl -u NetworkManager per problemi di associazione o DHCP, e i log del router se disponibili. Se la macchina è un laptop, verifica anche risparmio energetico aggressivo sulla scheda wireless.

dmesg -T | grep -iE 'net|wlan|wifi|firmware|link'
journalctl -u NetworkManager -b --no-pager | tail -n 100

Se il problema compare solo in certe fasce orarie, è facile che sia congestione di rete o saturazione dell’ISP. Se compare solo su una macchina, è più probabile un collo di bottiglia locale. Se compare solo su Wi‑Fi e non su cavo, la diagnosi è praticamente fatta.

Conclusione operativa: usa la misura giusta per la domanda giusta

Verificare la velocità di Internet da terminale in Ubuntu non significa affidarsi a un solo comando. Significa costruire una catena di controllo: stato del link, latenza, DNS, throughput sintetico e, quando serve, test punto‑punto con iperf3. Solo così il numero che ottieni ha un significato tecnico.

Se vuoi una risposta rapida, speedtest basta. Se vuoi capire il perché di un rallentamento, devi guardare anche il layer locale. In pratica: prima osserva, poi misura, poi confronta. È il modo più pulito per evitare diagnosi sbagliate e interventi inutili.