MyIPScan

Medición HTTP orientativa · desde el edge de Cloudflare

Prueba de latencia HTTP: cuánto tarda en responder un servidor

Mide cuánto tarda una petición HEAD acotada en ir desde el entorno serverless de MyIPScan hasta una URL pública HTTP o HTTPS y obtener respuesta. Es latencia HTTP, no un ping ICMP, y se mide desde el edge de Cloudflare, no desde tu dispositivo.

Medir el tiempo de respuesta

Introduce una URL pública para empezar.
Detalles técnicos de la respuesta (opcional)

        

Respuesta directa

Prueba de latencia HTTP: la respuesta corta

La latencia HTTP es lo que tarda un servidor en responder a una petición. Esta prueba hace varias peticiones HEAD a la URL desde el edge de Cloudflare de MyIPScan e informa de la mediana, el mínimo y el máximo. Mide ese camino del servidor, no tu propia conexión, y no es un ping ICMP.

Qué mide la prueba de latencia HTTP

El tiempo de los pasos HTTP: seguir un número pequeño de redirecciones y recibir la respuesta HEAD del destino final. MyIPScan comprueba antes el nombre de host público, pero ese paso no entra en el tiempo. La petición se repite varias veces en la misma comprobación y de esos intentos salen la mediana, el mínimo y el máximo.

Si el servidor rechaza HEAD, la petición se repite como GET, pero sin leer el cuerpo de la respuesta.

Limitaciones

  • Las peticiones salen del edge, no de tu dispositivo: no mide la latencia que notas tú ni la sobrecarga de tu VPN.
  • Los resultados cambian con la región de Cloudflare que atendió la petición, la carga del servidor de destino, las redirecciones y el estado de la caché.
  • Algunos servidores tratan HEAD y GET de forma distinta, así que el tiempo puede diferir de una carga real de la página.
  • Solo se comprueba un endpoint público HTTP o HTTPS por petición.

Leer el resultado

Qué muestra el resultado

Arriba aparece la mediana en milisegundos: el tiempo HEAD mediano medido desde el servidor de MyIPScan. Debajo están la URL final tras las redirecciones, el código de estado, cuántas redirecciones hubo, cuántos intentos se completaron, el mínimo, la mediana y el máximo, desde dónde se midió y la hora de la comprobación.

Una tabla recoge cada intento por separado, con su tiempo total, su estado, sus redirecciones y su URL final, y otra muestra la cadena de redirecciones con el tiempo de cada paso y su destino. Así se ve si el tiempo se va en el servidor final o en los saltos previos.

Cuando la respuesta no es la página

Si la respuesta final es un error 4xx o 5xx, el resultado indica que midió esa respuesta de error, no una página que funciona. Si el sitio bloquea al comprobador, lo que se cronometró es la página de bloqueo, y el resultado lo advierte.

Causas

Qué hace subir la latencia HTTP

Una petición HTTPS a un servidor encadena varios pasos, y cada uno suma tiempo:

  • Distancia física. Cuanto más lejos está el servidor del punto de partida de la petición, más tarda cada viaje de ida y vuelta.
  • Resolución DNS. Antes de conectar hay que traducir el nombre de host a una dirección IP.
  • Handshake TCP. Abrir la conexión cuesta un viaje de ida y vuelta.
  • Handshake TLS. Uno o dos viajes de ida y vuelta con TLS 1.2, uno con TLS 1.3.
  • Procesamiento en el servidor. El tiempo que tarda la aplicación en preparar la respuesta.
  • Redirecciones. Cada salto es una petición más; la tabla de redirecciones muestra cuánto cuesta cada uno.

Una CDN reduce la latencia sirviendo el contenido desde servidores cercanos geográficamente. Una latencia alta suele deberse a una gran distancia, a un DNS lento o a retrasos de procesamiento en el servidor, no a la falta de ancho de banda.

Qué no es

Por qué no es un ping ni la velocidad de tu conexión

Un ping usa ICMP: envía un paquete de eco y mide cuánto tarda en volver. Esta prueba habla HTTP: pide las cabeceras de una URL con una petición HEAD y mide cuánto tarda la respuesta, redirecciones incluidas.

Las peticiones salen del entorno serverless de MyIPScan en el edge de Cloudflare, no de tu dispositivo. Por eso el número no es la latencia que notas tú al navegar ni sirve para medir lo que añade tu VPN.

Tampoco es el TTFB (tiempo hasta el primer byte) que ve tu navegador al cargar la página: la petición es HEAD, sale de otra red y no descarga el cuerpo, las imágenes ni los scripts.

Qué comprueba, qué no puede comprobar y cómo leerlo

Qué comprueba

El tiempo de respuesta HTTP de una URL pública: varias peticiones HEAD, su mediana, su mínimo y su máximo, el código de estado y la cadena de redirecciones con el tiempo de cada paso.

Qué no puede comprobar

No mide tu propia conexión ni tu VPN, no hace ping ICMP y no carga la página completa. Solo acepta URL públicas: no comprueba hosts privados ni redes internas.

Cómo usar el resultado

Trata el resultado como una señal que revisar para un objetivo público. Mide la misma URL varias veces, cambia una sola cosa y vuelve a medir; para compartirlo, usa la copia segura o notas que eviten datos técnicos en bruto.

Sigue con las comprobaciones más cercanas

  • Consulta DNS: los registros públicos del dominio, consultados con DNS sobre HTTPS.
  • DNS inverso (PTR): el nombre asociado a la dirección IP del servidor.
  • Metodología: cómo etiqueta MyIPScan las señales, los límites y la copia segura.

El comprobador de cabeceras HTTP, el comprobador de redirecciones, el escáner de exposición de sitios web y el informe de inteligencia de dominios están por ahora solo en inglés.

Referencia rápida: qué hace esta herramienta

Mide el tiempo de peticiones HTTP HEAD limitadas a una URL pública.

Cómo usarla

  1. Introduce una URL pública HTTP o HTTPS.
  2. Lee primero la mediana; el mínimo y el máximo muestran cuánto varió el camino.
  3. Mide la misma URL varias veces antes de sacar conclusiones de un solo número.

Qué significa el resultado

El tiempo procede de la ruta /api/http-latency de MyIPScan, que hace varias peticiones HEAD desde el entorno serverless de MyIPScan hasta el destino e informa de la mediana, el mínimo y el máximo. Mide ese camino, del edge de Cloudflare al destino. No es una medición de tu propia conexión ni un ping ICMP.

Limitaciones conocidas

  • Como las peticiones parten del edge y no de tu dispositivo, no mide la latencia que experimentas tú ni la sobrecarga de tu VPN.
  • Los resultados cambian con la región de Cloudflare que atendió la petición, la carga del destino, las redirecciones y el estado de la caché.
  • Algunos servidores tratan HEAD y GET de forma distinta, así que estos tiempos pueden diferir de una carga real de la página.

Preguntas frecuentes sobre la latencia HTTP

¿Qué causa una latencia HTTP alta?

Influyen sobre todo la distancia física hasta el servidor, el tiempo de resolución DNS, el handshake TCP (un viaje de ida y vuelta), el handshake TLS (uno o dos viajes de ida y vuelta con TLS 1.2, uno con TLS 1.3) y el tiempo de procesamiento del servidor. Una CDN reduce la latencia sirviendo el contenido desde servidores cercanos geográficamente. Una latencia alta suele deberse a una gran distancia, a un DNS lento o a retrasos de procesamiento en el servidor, no a la falta de ancho de banda.

¿Esta prueba es lo mismo que un ping?

No. Un ping usa ICMP; esta prueba envía peticiones HTTP HEAD a una URL pública y mide cuánto tarda la respuesta, incluidas las redirecciones que haya que seguir. Es latencia HTTP, no ICMP.

¿Sirve para medir mi conexión o mi VPN?

No. Las peticiones salen del entorno serverless de MyIPScan en el edge de Cloudflare, no de tu dispositivo, así que el resultado no mide la latencia que experimentas tú ni la sobrecarga de tu VPN. Mide el camino entre el edge de Cloudflare y el servidor de destino.

¿Qué significan la mediana, el mínimo y el máximo?

Cada comprobación hace varias peticiones HEAD a la misma URL. La mediana es el valor central y conviene leerla primero; el mínimo y el máximo muestran cuánto varió el camino entre intentos.

¿Por qué cambian los resultados de una medición a otra?

Dependen de la región de Cloudflare que atendió la petición, de la ruta de red, de la carga del servidor de destino, de las redirecciones y del estado de la caché. Por eso conviene medir la misma URL varias veces antes de sacar conclusiones de un solo número.

¿Por qué el resultado no coincide con lo que tarda en cargar la página?

Porque la prueba usa peticiones HEAD, que solo piden las cabeceras, y algunos servidores tratan HEAD y GET de forma distinta. Si un servidor rechaza HEAD, la petición se repite como GET, pero sin leer el cuerpo. No se descargan imágenes ni scripts, así que el tiempo no equivale a la carga real de una página.

¿Cómo debo usar los resultados de la prueba de latencia HTTP?

Lee primero la mediana y usa el mínimo y el máximo para ver cuánto varía. Mide la misma URL varias veces, haz un solo cambio cada vez y vuelve a medir para comparar.

¿Qué no demuestra la prueba de latencia HTTP?

No mide la latencia que experimentas tú ni la sobrecarga de tu VPN, porque las peticiones salen del edge de MyIPScan y no de tu dispositivo. Tampoco demuestra que la página cargue rápido en un navegador. Solo cronometra los pasos HTTP desde ese edge hasta la URL, en ese momento.