156 30/03/2026 07/04/2026 6 min

Diagnosi probabile

Quando un server Linux non esce in rete, le cause più frequenti sono poche e quasi sempre verificabili in pochi minuti: gateway mancante o errato, route predefinita assente, DNS non funzionante, firewall o policy di rete che bloccano l’uscita, interfaccia non davvero su, oppure un problema lato provider/VPS con rete virtuale o MAC/IP non allineati.

La distinzione importante è questa: il server può non avere Internet, ma avere comunque connettività locale o viceversa. Per questo conviene separare il problema in tre livelli: link di rete, instradamento, risoluzione nomi. Se uno di questi salta, il sintomo può essere diverso: ping verso IP esterni fallito, siti raggiungibili via IP ma non via nome, aggiornamenti package che non partono, servizi che non raggiungono API esterne.

Se il problema è comparso dopo una modifica, la causa più probabile è una configurazione recente su netplan, NetworkManager, ifcfg, firewall o DNS. Se invece è un VPS appena creato, spesso il punto debole è la route di default o un DNS iniziale non corretto.

Verifiche immediate

Prima di cambiare qualcosa, conviene fare tre controlli essenziali e confrontare l’esito atteso con quello reale.

  1. Verifica che la scheda di rete sia su e che abbia un indirizzo valido.

    ip a

    Esito atteso: l’interfaccia principale deve risultare UP e avere un indirizzo IPv4 o IPv6 coerente con la tua rete.

  2. Verifica che esista una route predefinita.

    ip route

    Esito atteso: deve comparire una riga con default via e l’indirizzo del gateway corretto. Se manca, il server non sa dove inoltrare il traffico verso Internet.

  3. Se l’IP risponde ma i nomi no, controlla il DNS.

    resolvectl status

    Su sistemi senza systemd-resolved puoi controllare anche cat /etc/resolv.conf. Esito atteso: almeno un nameserver raggiungibile e coerente con la rete usata.

  4. Testa la connettività verso un IP pubblico noto, senza passare dai DNS.

    ping -c 3 1.1.1.1

    Esito atteso: risposta ICMP regolare. Se fallisce qui, il problema non è il DNS ma il routing o il blocco in uscita.

  5. Testa la risoluzione dei nomi solo se il ping verso IP funziona.

    ping -c 3 google.com

    Esito atteso: risoluzione e risposta. Se il ping verso IP funziona ma questo no, il problema è quasi certamente DNS.

  6. Controlla se il firewall locale sta filtrando l’uscita.

    sudo nft list ruleset

    Oppure, se usi iptables legacy:

    sudo iptables -S

    Esito atteso: nessuna policy che blocchi l’output in modo inatteso. Se la policy di default è DROP, serve una regola esplicita per l’uscita o una correzione del profilo firewall.

Soluzione consigliata passo-passo

Procedi dal controllo più sicuro al fix più probabile, evitando modifiche multiple insieme. Se l’ambiente è in produzione, cambia una cosa alla volta e verifica subito dopo.

  1. Correggi la route di default se manca o punta al gateway sbagliato.

    Su Ubuntu/Debian con netplan, il file è spesso in /etc/netplan/*.yaml. Prima fai un backup:

    sudo cp /etc/netplan/01-netcfg.yaml /etc/netplan/01-netcfg.yaml.bak

    Poi verifica la configurazione e il gateway. Un esempio tipico:

    network:
  version: 2
  ethernets:
    eth0:
      dhcp4: no
      addresses:
        - 192.0.2.10/24
      gateway4: 192.0.2.1
      nameservers:
        addresses:
          - 1.1.1.1
          - 8.8.8.8

    Applica con cautela:

    sudo netplan try

    Esito atteso: la rete resta raggiungibile e la configurazione viene confermata. Se tutto funziona, salva con sudo netplan apply.

  2. Se usi NetworkManager, controlla che il profilo abbia gateway e DNS corretti.

    nmcli con show

    Identifica la connessione attiva e poi verifica i parametri:

    nmcli con show "NOME_CONN" | egrep 'ipv4.addresses|ipv4.gateway|ipv4.dns|ipv4.method'

    Esito atteso: metodo coerente con la tua rete, gateway presente, DNS impostati. Se manca il gateway, il traffico non esce.

  3. Se il ping verso IP esterni fallisce, verifica che il provider o la virtualizzazione non abbiano un vincolo di rete.

    Nei VPS può capitare che l’IP sia assegnato ma il gateway non sia raggiungibile perché il MAC non è registrato, la NIC virtuale è cambiata, oppure manca una route specifica sul pannello del provider. In questo caso controlla il pannello del VPS per:

    • IP assegnato correttamente
    • gateway indicato dal provider
    • eventuali regole anti-spoofing o MAC binding
    • stato della rete virtuale o della scheda

    Esito atteso: il gateway del provider deve essere quello effettivamente configurato sul server. Se non coincide, correggilo prima di insistere lato sistema operativo.

  4. Se il ping verso IP funziona ma i nomi non si risolvono, ripristina il DNS.

    Su sistemi con systemd-resolved, controlla che i resolver siano attivi:

    resolvectl status

    Se i nameserver sono errati o vuoti, puoi impostare temporaneamente DNS pubblici per verificare il problema. Su molte distribuzioni il file /etc/resolv.conf è gestito automaticamente, quindi la modifica manuale potrebbe non essere persistente. In quel caso conviene correggere la configurazione del gestore di rete, non il file finale.

    Esito atteso: dopo la correzione, ping google.com deve risolvere il nome e rispondere.

  5. Controlla il firewall in uscita solo se le verifiche sopra non bastano.

    Con nftables, cerca regole che filtrano l’output:

    sudo nft list ruleset

    Con ufw:

    sudo ufw status verbose

    Con firewalld:

    sudo firewall-cmd --state

    Esito atteso: l’uscita verso Internet non deve essere bloccata da una policy non voluta. Se trovi una policy restrittiva, aggiungi prima una regola mirata invece di disattivare tutto.

  6. Verifica eventuali problemi di MTU o frammentazione se la rete “sembra” su ma alcuni siti non aprono.

    Questo capita spesso su VPN, tunnel o alcuni provider. Un test rapido è:

    ping -M do -s 1472 1.1.1.1

    Esito atteso: se fallisce ma ping piccoli funzionano, potrebbe esserci un MTU troppo alto. In quel caso va ridotto il valore sulla interfaccia o sul tunnel interessato.

Controlli finali / rollback

  1. Rifai i tre test base dopo ogni correzione: ip route, ping -c 3 1.1.1.1, ping -c 3 google.com. Il risultato corretto è: route presente, IP raggiungibile, nomi risolti.

  2. Se hai modificato netplan o un profilo di rete, tieni pronto il backup per il rollback. Su netplan, ripristina il file salvato e rilancia sudo netplan apply solo se la nuova configurazione crea un disservizio.

  3. Se il fix non è persistente dopo il reboot, il problema non è solo funzionale ma anche di persistenza della configurazione. In quel caso verifica dove il sistema salva davvero la rete: netplan, NetworkManager, ifcfg, cloud-init o pannello del provider.

  4. Se dopo i controlli il server continua a non uscire ma il gateway e il DNS sono corretti, raccogli questi dati prima di andare oltre: output di ip a, ip route, resolvectl status e l’eventuale firewall attivo. Sono i quattro elementi che più spesso sbloccano la diagnosi reale.

Assunzione operativa: i comandi proposti sono pensati per un server Linux con accesso SSH o console e una configurazione di rete standard; se usi una rete molto custom, la logica resta la stessa ma il punto di modifica può cambiare.

Checklist rapida

  • Interfaccia su e con IP corretto
  • Route di default presente
  • Ping verso IP pubblico funzionante
  • DNS funzionante solo dopo il test IP
  • Firewall e policy provider verificati

Se vuoi, posso trasformare questo articolo in una versione più orientata a Ubuntu/Debian, Alma/Rocky o VPS con pannello di controllo.