ping indica se una richiesta echo ICMP ha ricevuto risposta. Non apre la porta HTTP o SOCKS indicata in una lista di proxy e non chiede al proxy di raggiungere un sito.

La distinzione conta quando una voce risponde a ping ma rifiuta la connessione proxy. ICMP e il servizio TCP del proxy seguono percorsi diversi nel software e nelle regole di accesso dell’host. Un indirizzo raggiungibile può non avere alcun proxy in ascolto sulla porta scelta.

Tre risultati facili da interpretare male

  • Ping risponde, il proxy fallisce: indaga porta del servizio, protocollo, autenticazione e risposta del proxy. La risposta echo non li ha verificati.
  • Ping fallisce, il proxy funziona: rete o host possono filtrare ICMP consentendo la connessione proxy. Non scartare un test applicativo riuscito perché una richiesta echo non ha ricevuto risposta.
  • Ping è veloce, le richieste sono lente: l’andata e ritorno dell’echo esclude negoziazione del proxy, percorso dal proxy alla destinazione, TLS e tempo di risposta della destinazione.

Usa l’operazione reale del client

Per un endpoint HTTP, esegui attraverso di esso una richiesta HTTP con limiti definiti. Se serve HTTPS, conferma anche creazione del tunnel e risposta TLS della destinazione. Per SOCKS usa la modalità SOCKS supportata dall’applicazione. Un controllo della porta TCP è un’utile osservazione intermedia, ma si ferma prima di questi passaggi del protocollo.

Conserva ping come informazione di rete complementare nella diagnosi di un percorso noto. Riporta il suo risultato separatamente da quello applicativo. «L’IP risponde alle richieste echo» e «il proxy ha completato questa richiesta HTTPS» sono affermazioni diverse; solo la seconda verifica l’operazione che volevi eseguire.

Articoli correlati