ping visar om en ICMP-ekobegäran fick svar. Det öppnar inte HTTP- eller SOCKS-porten i en proxylista och ber inte proxyn att nå en webbplats.

Skillnaden spelar roll när en post svarar på ping men vägrar en proxyanslutning. ICMP och proxyns TCP-tjänst följer olika vägar genom värdens programvara och åtkomstregler. En nåbar adress kan sakna en proxy som lyssnar på den valda porten.

Tre resultat som lätt misstolkas

  • Ping svarar, proxyn misslyckas: undersök tjänsteport, protokoll, autentisering och proxysvar. Ekosvaret har inte testat dessa.
  • Ping misslyckas, proxyn fungerar: nätverket eller värden kan filtrera ICMP men tillåta proxyanslutningen. Kasta inte bort ett lyckat applikationstest på grund av en obesvarad ekobegäran.
  • Ping är snabbt, begäranden är långsamma: ekots tur och retur utesluter proxyförhandling, vägen från proxy till destination, TLS och destinationens svarstid.

Använd den verkliga klientoperationen

För en HTTP-ändpunkt, gör en avgränsad HTTP-begäran genom den. Behöver du HTTPS, bekräfta även att tunneln upprättas och att destinationen ger ett TLS-svar. För SOCKS använder du applikationens stödda SOCKS-läge. En TCP-portkontroll är en användbar mellanobservation men stannar före dessa protokollsteg.

Behåll ping som kompletterande nätverksinformation vid felsökning av en känd väg. Rapportera resultatet separat från applikationsresultatet. ”IP-adressen besvarar ekobegäranden” och ”proxyn slutförde denna HTTPS-begäran” är olika påståenden; bara det senare testar den avsedda operationen.

Relaterade artiklar