2,081 25/03/2026 07/04/2026 2 min

Introduzione

Il problema non è quasi mai Nginx “rotto”. Il problema è Nginx che sembra sano, ma serve header sbagliati, non cachea dove dovrebbe, oppure aspetta troppo l’upstream sotto carico reale.

Questo articolo mostra un controllo ripetibile con systemd timer e curl. L’obiettivo è semplice: verificare ogni 15 minuti che alcuni endpoint critici rispondano con header attesi, che il TLS sia ancora corretto, e che i tempi verso l’upstream non stiano degradando.

Lo scenario è concreto. Hai un sito dietro Nginx 1.24, con PHP-FPM o un backend applicativo, e vuoi intercettare tre sintomi prima dell’incidente: Cache-Control incoerente, timeout upstream e header di sicurezza mancanti.

Note: il controllo non sostituisce il monitoraggio completo. Serve a creare una verifica veloce, locale, affidabile, e facile da agganciare a journald o a un alert esterno.

Prerequisiti

Servono pochi elementi, ma devono essere presenti tutti.

  • Una macchina Linux con systemd.
  • curl installato.
  • Accesso a uno o più endpoint HTTPS pubblici o interni.
  • Permessi per creare un servizio e un timer systemd.
  • Una policy chiara sugli header attesi, almeno per home, login e asset statici.

Warning: non usare questo controllo su endpoint che cambiano spesso contenuto, come pagine con timestamp o token casuali. Il test diventerebbe rumoroso e inutile.

Qui assumiamo tre URL di esempio:

  • https://www.example.com/ per la home cacheabile.
  • https://www.example.com/login per una pagina no-cache.
  • https://www.example.com/healthz per un check applicativo leggero.

Step 1 — Definisci cosa vuoi verificare e perché

Prima di automatizzare, scegli regole misurabili. Non controllare “se il sito va”. Controlla valori precisi. In carico reale, la differenza è enorme.

Per esempio:

  • La home deve restituire Cache-Control: public o un equivalente coerente con la tua CDN.
  • La login page deve restituire Cache-Control: no-store o private, no-cache.
  • L’header Strict-Transport-Security deve esistere su tutte le risposte HTTPS.
  • Il tempo totale della risposta deve restare sotto una soglia utile, per esempio 800 ms per l’health check.
  • Il TTFB non deve esplodere quando l’upstream rallenta.

La scelta più utile è separare i controlli per classe di URL. Una home lenta non è uguale a una login lenta. Un asset statico non ha la stessa funzione di una pagina dinamica.