Sintesi

Il 24 agosto 2026, kulinaryos.com e www.kulinaryos.com hanno temporaneamente restituito 502 Bad Gateway. Il DNS è rimasto corretto e autoritativo durante tutto l'incidente. Applicazione, ERP, sito Operations e posta elettronica non sono stati interessati.

Ci scusiamo per l'interruzione e per l'impatto sull'accesso al sito istituzionale.

Cosa è successo

L'edge RBX non riusciva più a stabilire connessioni HTTP o HTTPS con l'origine WordPress legacy. I test da reti indipendenti continuavano a raggiungere l'origine, mentre l'indirizzo di ingresso RBX—e successivamente l'indirizzo di un primo relay—ricevevano rifiuti di connessione specifici per la sorgente.

Le evidenze sono compatibili con una regola firewall, Fail2ban, del pannello di hosting o del provider sull'origine o davanti ad essa. Il componente esatto non è ancora confermato perché RBX non dispone attualmente dell'accesso amministrativo ai log e ai controlli di sicurezza dell'origine.

Non si è trattato di un errore DNS né di una carenza di risorse nell'infrastruttura RBX.

Ripristino

Il servizio è stato ripristinato con questo percorso temporaneo e controllato:

Internet → edge Traefik RBX → relay Nginx interno RBX → origine WordPress legacy

Traefik rimane l'edge pubblico, il punto TLS e il router. Nginx viene usato soltanto come relay di uscita interno. Il suo controllo di salute è locale e le connessioni upstream vengono riutilizzate, evitando sonde attive non necessarie verso l'origine legacy.

Dopo il ripristino sono stati validati con successo DNS autoritativo, resolver pubblici, TLS ed endpoint web principali.

Piano di prevenzione

  • Ottenere accesso amministrativo autorizzato all'origine e verificare i log di Plesk, firewall, Fail2ban e provider.
  • Inserire nella allow-list gli indirizzi documentati di ingresso e relay RBX e verificare che le regole automatiche non possano bloccare nessuno dei due percorsi.
  • Aggiungere controlli e avvisi di raggiungibilità sensibili alla sorgente, senza sonde aggressive verso l'origine.
  • Conservare un relay di emergenza collaudato e un runbook documentato di ripristino e rollback.
  • Preparare una migrazione controllata o una replica dell'installazione WordPress istituzionale in un'infrastruttura di proprietà Kulinaryos o gestita da RBX, riducendo la dipendenza da un'origine legacy non trasparente.
  • Completare la revisione post-incidente e registrare la causa confermata quando saranno disponibili le evidenze dell'origine.

Monitoraggio

La finestra di monitoraggio post-incidente è stata estesa a 72 ore dal ripristino del servizio. Delegazione DNS, record autoritativi, resolver pubblici, HTTPS, relay e servizi applicativi non interessati resteranno sotto osservazione. Ogni regressione sarà comunicata qui.