Ho creato Gitae perché continuavo a incontrare la stessa domanda pratica: il sito è davvero offline oppure il problema è solo dalla mia parte?
Una singola scheda del browser è uno strumento di diagnosi piuttosto debole. Una pagina può non caricarsi perché l’origin server è giù, ma anche per DNS, un problema del certificato HTTPS, routing, una regola firewall, una porta chiusa o filtrata, l’ISP, un percorso VPN, lo stato del browser o una cache locale. Il sintomo visibile è lo stesso; la soluzione corretta no.
È questo che volevo risolvere con Gitae: non mostrare semplicemente un indicatore verde o rosso, ma aiutarmi a restringere il problema al layer che ha senso indagare dopo.
Il problema reale dietro “il sito è down”
Molti website checker semplici rispondono a una domanda ristretta: questo URL ha risposto da un certo punto in un certo momento? È utile, ma non è ancora diagnosi di un outage.
Se il DNS è sbagliato, riavviare l’applicazione non serve. Se HTTPS fallisce per il certificato, cambiare il contenuto è irrilevante. Se una porta TCP non è raggiungibile, il server può comunque essere attivo. Se il sito funziona da un server esterno ma non dalla mia connessione, il problema può trovarsi lungo il percorso tra la mia rete e la destinazione invece che sull’application server.
Per questo ho impostato Gitae su un modello più utile: un sito è una catena di dipendenze e ogni controllo fornisce evidenza solo su una parte di quella catena.
Un punto di vista esterno, non un oracolo
I controlli di Gitae partono dai miei VDS server a Mosca e Helsinki. Mi danno quindi punti di osservazione esterni al computer e alla rete in cui ho notato il problema.
Se il sito non funziona localmente ma risponde da entrambi i VDS, è un segnale utile: l’origin almeno non è irraggiungibile ovunque. In quel caso guardo più attentamente DNS locale, route dell’ISP, VPN, browser, firewall o altri problemi dipendenti dal percorso. Se fallisce anche dalle sonde remote, aumenta il motivo per indagare server, DNS, certificato, routing o un problema di rete più ampio.
Ma un check remoto non è automaticamente “più affidabile” di quello locale. Due località non rappresentano tutto Internet. Un sito può funzionare da Mosca e Helsinki e fallire da un altro paese, ISP, CDN edge o rete. Per me il risultato remoto è un punto di osservazione aggiuntivo, non un verdetto globale.
Cosa controlla Gitae oggi
- Website check — verifica se un URL risponde da un server esterno.
- SSL check — controlla lo stato del certificato HTTPS/TLS e problemi legati al certificato.
- DNS check, nslookup e dig — aiutano a capire come viene risolto un dominio e quali record DNS vengono restituiti.
- Reverse DNS e IP check — mostrano dati IP e PTR/reverse-DNS.
- Domain info e domain age — forniscono metadati di base sul dominio.
- Port check — testa la raggiungibilità di una porta dal punto di controllo.
- Find your IP — mostra l’IP pubblico visto dal servizio.
- Ping e traceroute — forniscono segnali di rete su latenza, perdita di pacchetti e percorso.
- Hosting check e CMS detection — mostrano segnali di infrastruttura e tecnologia utili all’identificazione.
Tratto volutamente questi risultati come segnali. Un record PTR non dimostra chi possiede un server. La CMS detection basata su fingerprint pubblici non prova lo stack esatto. Una porta irraggiungibile da una sonda può essere filtrata lungo il percorso invece che chiusa per tutti.
Come interpreto i risultati
Il valore arriva dalla combinazione dei controlli, non da uno solo.
Se DNS restituisce l’indirizzo atteso, il certificato HTTPS è valido e il sito risponde da entrambi i VDS, ma localmente continua a non aprirsi, indagherei prima il percorso locale invece di modificare subito il server. Se DNS è incoerente o fallisce anche il check remoto, ci sono più motivi per guardare l’infrastruttura.
Anche ping e traceroute richiedono cautela. ICMP può essere filtrato o rate-limited. Un hop mancante in traceroute non significa automaticamente che quel nodo sia rotto, e un host che non risponde al ping può comunque servire HTTPS normalmente. Questi tool aggiungono contesto; non danno un verdetto definitivo.
La regola principale per me è: un singolo check riuscito non prova che tutto il sistema sia sano, e un singolo check fallito non spiega da solo la causa.
Disponibilità e SEO sono concetti diversi
La disponibilità conta anche per SEO, ma un outage tecnico non è la stessa cosa di un problema di ranking. Crawling non è indexing, e indexing non è traffic.
Se un crawler non raggiunge il sito per errori DNS, di rete o server, in quel momento non può recuperare correttamente il contenuto interessato. Google documenta che gli errori di rete e DNS durante il crawling vengono trattati in modo simile agli errori server 5xx e che un’indisponibilità prolungata può influire sul crawl e su URL già indicizzati. Questo non significa che ogni breve outage causi automaticamente una perdita SEO, né che uno strumento diagnostico possa provare che una successiva variazione di traffico sia stata causata proprio da quell’evento.
Per gli utenti la logica è più semplice: se non possono raggiungere il sito, non possono usarlo. A seconda del progetto ciò può significare sessioni, lead, conversioni o ricavi persi, ma il check tecnico non misura quell’impatto economico.
Un ordine pratico per indagare un sito “down”
- Confermare il sintomo da un’altra rete. Non assumere che il browser locale rappresenti tutto Internet.
- Controllare DNS. Verificare risoluzione e record attesi.
- Controllare HTTPS/TLS. Esaminare certificato ed errori di connessione.
- Controllare la porta necessaria. Testarne la raggiungibilità dalla sonda.
- Confrontare i segnali di rete. Usare ping e traceroute come supporto.
- Guardare IP, reverse DNS, hosting e CMS. Possono aiutare a confermare che si stia raggiungendo l’infrastruttura prevista.
- Solo allora restringere l’indagine. Decidere se l’evidenza punta più verso applicazione, server, DNS, percorso di rete o ambiente locale.
Non è un protocollo universale di incident response. È un modo per evitare l’errore che volevo eliminare: cambiare il layer sbagliato solo perché l’unica informazione iniziale è “il sito non si apre”.
Prima l’utilità reale, poi la monetizzazione
Gitae per ora non è monetizzato. L’ho costruito prima per me, perché volevo controllare rapidamente un sito dall’esterno del mio computer e passare subito a DNS, certificato, porte e rete senza saltare tra strumenti separati.
Il mio obiettivo attuale è rendere la diagnosi più utile e vedere se il progetto può ottenere traffico organico tramite SEO e domanda reale. Se raggiungerà anche un traffico moderato, voglio aggiungere monitoring automatico con notifiche istantanee nei messenger. Sarebbe un’estensione della stessa idea: rilevare che qualcosa non è più disponibile e fornire al proprietario abbastanza informazioni per iniziare subito a indagare.
Il principio centrale resta semplice
“Up” e “down” sono sintomi, non spiegazioni.
DNS, HTTPS/TLS, routing, porte, hosting, applicazione e rete dell’utente possono produrre lo stesso apparente problema di disponibilità. Gitae non identifica magicamente ogni root cause e quei punti VDS esterni non mostrano ciò che vede tutto Internet. Può però raccogliere più segnali indipendenti nello stesso posto.
È questo il tool che volevo per me: passare da “il sito non si apre” a una domanda molto più utile: “quale layer devo investigare adesso?”