Trace Route: diagnostica della connessione pubblica

Distingui la connessione del browser da una richiesta HTTP esterna. Esamina tempi e reindirizzamenti senza inventare passaggi tra router.

Come usarlo

Distingui la connessione del browser da una richiesta HTTP esterna. Esamina tempi e reindirizzamenti senza inventare passaggi tra router.

Passaggio 1

Scegli una destinazione autorizzata

Esempio illustrativo, non un risultato in tempo realehttps://clocktools.app/

Inserisci un URL HTTP o HTTPS pubblico senza credenziali o porta personalizzata.

Passaggio 2

Separa le osservazioni

Esempio illustrativo, non un risultato in tempo realeBrowser → servizio → destinazione

Il percorso dal browser al servizio e quello dal servizio alla destinazione sono diversi.

Passaggio 3

Confronta il rapporto

Esempio illustrativo, non un risultato in tempo realeJSON

Esporta il risultato datato e confrontalo con una prova locale nel browser o nel terminale.

Usi pratici

Delimitare un problema locale

Il computer non apre un sito, ma il controllo esterno riceve risposta. Mantieni schema, host e percorso quando provi altro browser o rete. Confronta prima accesso anonimo, poi DNS, VPN, estensioni e regole una per volta. Il risultato restringe l’indagine, senza garantire disponibilità per tutti.

Leggere un reindirizzamento

Dopo uno spostamento, verifica vecchio URL e prima risposta con Location. Un redirect può spiegare l’indirizzo del browser, ma qui non viene seguito. Controlla il target separatamente se autorizzato. Conserva entrambe le osservazioni; un redirect non è una pagina finale già verificata.

Informare il supporto

Per incidenti intermittenti esporta JSON con URL, ora, codice, durata e contesto browser-servizio. Aggiungi errore locale e rete. Se il supporto chiede hop o perdita ripetuta, fornisci misure terminal autorizzate separate. Le fasi qui non le sostituiscono.

Contesto e funzionamento

Diagnostica HTTP HEAD di clocktools.app, senza salti tra router
La verifica di clocktools.app mostra i dettagli della risposta HTTP e il contesto della connessione tra browser e servizio. Questa richiesta HEAD non è un traceroute da router a router.

Perché traceroute richiede altre sonde

I router IPv4 riducono il TTL durante l’inoltro. Quando si esaurisce, un messaggio ICMP di tempo scaduto può identificare il router che risponde. Il traceroute nel terminale varia i limiti delle sonde e raccoglie risposte.

Questa pagina non invia sonde con TTL variabile. Il tempo HTTP comprende richiesta esterna e lavoro del servizio. Il RTT TCP del client, se disponibile, descrive un’altra connessione. Nessuno è un numero di passaggi o un ping puro verso la destinazione. Specifica ICMP.

Il percorso non è una linea permanente

I requisiti dei router descrivono TTL e inoltro, ma percorsi e risposte possono cambiare. Anche una traccia da terminale può avere lacune per filtri o limiti delle risposte; non provano perdita di pacchetti nell’applicazione.

HTTP 403 o 500 è comunque una risposta osservata. Un timeout indica solo che nessuna risposta utile è arrivata entro il limite. Confronta URL, metodo e ora: il GET del browser può differire dall’HEAD usato qui. Requisiti dei router IPv4.

Esempio: 403 dall’esterno e navigazione locale riuscita

Supponi che un HEAD esterno riceva 403 in 240 ms, mentre il browser autenticato apre la pagina. È una differenza di accesso, non necessariamente un router guasto. Il controllo non invia cookie; confronta accesso anonimo e regole del firewall.

Risposta esterna
403 · 240 ms
Browser locale
GET autenticato riuscito
Passo successivo
Confrontare accesso e metodo

Preparare condizioni confrontabili

Inserisci l’effettivo URL pubblico HTTP o HTTPS. Schema e percorso contano: HTTP può reindirizzare, HTTPS rispondere; homepage funziona mentre una rotta no. Non è port scanner. Credenziali, target privati e porte personalizzate sono rifiutati. Usa indirizzi normali senza segreti, non reset account o download firmati.

Non ci sono impostazioni per hop, pacchetti, quantità di probe o metodo. La richiesta esterna usa HEAD senza seguire redirect. Chiede header, non scarica una pagina. La semantica dei metodi HTTP distingue HEAD e GET: il browser riceve contenuti e altre risorse che questo controllo non richiede.

Esegui, attendi ed esporta prima di cambiare condizioni. Annulla o reimposta al cambio target per non far sostituire la vista da una risposta vecchia. Condividere prepara una nuova prova deliberata, non invia misure. Un nuovo risultato può variare legittimamente per rete, tempo o destinazione.

Non mescolare connessioni diverse

La prima osservazione riguarda browser e ClockTools. Protocollo HTTP, TLS e RTT TCP client, se presente, appartengono a quella connessione. La seconda è una richiesta anonima separata dal servizio al target. Le fasi organizzano osservazioni, non mappano i router dal tuo computer al sito.

La durata target include DNS pubblico e operazione esterna fino alla risposta. Non è sola elaborazione server, banda, caricamento o RTT ICMP. Non sottrarre RTT browser, non sommare in ping totale né dividere per fasi per inventare latenze. Endpoint e confini di misura differiscono.

Nell’esempio fisso, 18 ms al servizio e 240 ms al target non identificano un link lento. DNS, connessione, accesso e risposta contribuiscono alla seconda cifra. Un campo mancante resta ignoto. Il luogo del servizio non dimostra percorso fisico, posizione precisa del client o origine dietro proxy.

Un errore HTTP resta una risposta

Fase completata significa risposta ricevuta, non pagina funzionante. Leggi il codice. 200 riguarda questa richiesta HTTP, non rendering, login o acquisto. 403 e 500 sono comunque risposte e indirizzano a accesso o applicazione, non alla conclusione che nessun server fosse raggiungibile.

301 o 302 mostrano solo il primo redirect. Location può essere relativo e va letto con l’URL verificato. Non conferma sicurezza, disponibilità o assenza di loop successivi. Conserva la risposta e controlla separatamente la destinazione pubblica prevista se autorizzato.

Il server può trattare HEAD diversamente da GET malgrado la relazione prevista. Con 405 o 501 e browser funzionante chiedi supporto o blocco del metodo. Una prova anonima può ricevere challenge mentre la sessione vede contenuti. Sono differenze da confrontare, non ragioni per eludere controlli.

Interpretare le prime risposte comuni
EsitoOsservazionePasso utile
200Risposta riuscita a HEADControllare pagina e interazioni a parte.
301 / 302Redirect inizialeLeggere Location e verificare il target separato.
401 / 403Autenticazione o accesso negatoConfrontare accesso anonimo e proprie regole.
404Questo percorso non trovatoControllare scrittura e percorso pubblico noto.
405 / 501Metodo rifiutato o non supportatoConfrontare GET autorizzato e gestione del metodo.
429 / 5xxLimite o risposta serverSospendere tentativi e consultare log pertinenti.

Restringere il problema livello per livello

Senza HTTP utilizzabile parti dall’errore, non dal tempo. DNS non trovato suggerisce un errore di scrittura o risoluzione. DNS indisponibile è meno preciso: il controllo del resolver non ha stabilito risposte pubbliche utilizzabili. Nessuno testa scadenza. Sul tuo dominio confronta A, AAAA e delega con gli strumenti abituali.

L’operazione esterna ha circa 6,5 secondi totali, DNS incluso. Timeout dice che questo tentativo non ha ricevuto risposta utilizzabile entro il limite. Non identifica un router guasto, né dimostra un arresto del server di origine, né misura né diagnostica una perdita di pacchetti. Connessione e TLS possono fallire senza HTTP. Log target e prova indipendente autorizzata aiutano a stabilire la causa.

Se locale ed esterno differiscono, conserva URL e ora. Prova finestra anonima e altra rete disponibile. Cambia una variabile alla volta: rete, VPN, browser o metodo. Se entrambi falliscono, porta i fatti al supporto senza dichiarare guasto globale. Un punto esterno non è monitoraggio multiregione.

Quando servono misure dei salti tra router

Traceroute convenzionale invia probe con limiti di vita crescenti e associa risposte. La specifica ICMP descrive Time Exceeded; IPv6 usa Hop Limit nell’header base. Questo meccanismo differisce dagli header HTTP. ClockTools non invia probe di quel tipo né ricostruisce liste di router.

Usa strumento terminal locale e target autorizzato per gli hop rispondenti. Annota rete fonte e tipo di probe; un’altra macchina non fornisce necessariamente il tuo percorso. Tieni l’output distinto dal JSON per separare osservazioni sui pacchetti e sull’applicazione.

Anche il terminale richiede interpretazione. Un dispositivo può ignorare probe ma inoltrare traffico normale; percorsi e risposte variano. Un hop intermedio silenzioso non prova da solo perdita applicativa lì. Parti dal problema visibile, confronta destinazione e ripeti misure autorizzate quando serve. Le fasi qui non rivelano router, distanze o fornitori responsabili.

Metodologia

Il rapporto separa contesto browser-servizio, DNS pubblico recente e HEAD anonimo al target. Conserva prima risposta, header selezionati e durata approssimativa senza seguire redirect. Campi assenti restano ignoti. JSON mantiene l’ora; annullamento e reset impediscono risultati tardivi sulla nuova vista.

Limiti

Non misura i salti tra router, la latenza di ciascun salto o la perdita di pacchetti end-to-end e non equivale a un traceroute eseguito dal terminale. Una sola osservazione esterna non è una verifica globale, un benchmark di caricamento o un monitoraggio continuo. Sono accettati solo indirizzi pubblici. Gli errori vanno interpretati insieme a URL, metodo e ora; da soli non identificano il livello in cui si trova il guasto.

Correzioni

Segnala un problema riproducibile tramite la pagina dei contatti, indicando l’URL dello strumento, un input non riservato, l’ora del controllo, il risultato atteso e le prove della fonte. Allega se possibile la risposta pubblica, senza dati dell’account né link segreti. Una fonte cambiata non implica necessariamente un errore di calcolo. Confronta prima lo stesso nome, pagina e momento.

MetodologiaCorrezioni

Domande frequenti

È un traceroute hop per hop?

No. Separa connessione a ClockTools e controllo HTTP esterno. Le fasi non sono router. Per hop rispondenti usa traceroute o tracert autorizzato dalla rete pertinente e conserva quelle prove separatamente.

Perché la fase è completa con 403 o 500?

Completa significa risposta HTTP ricevuta. Rifiuto ed errore sono ancora risposte, non mancanza di connettività. Leggi codice, regole e log. Non viene confermata la pagina o il flusso utente previsto.

I redirect vengono seguiti?

No. Vedi la prima risposta e l’intestazione Location, se presente; la destinazione del reindirizzamento non viene verificata. Se il valore è relativo, ricava l’indirizzo completo usando l’URL originale come base. Controlla poi separatamente la destinazione pubblica prima di concludere che l’intero percorso abbia avuto esito positivo.

Perché il browser funziona e il controllo fallisce?

Può usare GET, cookie, cache o altra rete, invece di HEAD anonimo esterno. Confronta la stessa URL senza login e gestione di metodo e accesso. 405 o challenge può spiegare la differenza senza guasto di instradamento.

La durata è il ping del sito?

No. Include DNS e HTTP esterno. RTT TCP browser riguarda un’altra connessione. Nessuno è ping ICMP del target; sommare o sottrarre non crea una misura valida end-to-end.

Cosa dimostra un timeout?

Solo che questo tentativo non ha avuto risposta utilizzabile nei circa 6,5 secondi. DNS, connessione, accesso e target possono contribuire. Conserva errore e ora, confronta test indipendente autorizzato e non attribuirlo a un router specifico.

Posso testare intranet o altre porte?

No. HTTP e HTTPS pubblici su porte standard sono ammessi. Privati, credenziali e porte proprie sono rifiutati. Usa strumenti locali autorizzati dell’organizzazione per l’interno senza aggirare il limite con altro hostname.

Un risultato dimostra guasto regionale o mondiale?

No. È un’osservazione puntuale. Reti e politiche diverse possono ricevere risposte diverse. Confronta reti indipendenti e monitoraggio dell’operatore prima di dichiarazioni ampie e inserisci condizioni nel ticket.

Condividere conserva l’esito o monitora l’URL?

No. Prepara una nuova verifica deliberata. Copia o scarica JSON per quella precedente. Condivisione e pagina aperta non pianificano controlli; altro contesto e ora possono produrre risultato diverso.