{"id":34318,"date":"2026-07-20T21:18:25","date_gmt":"2026-07-20T21:18:25","guid":{"rendered":"https:\/\/www.dotcom-monitor.com\/blog\/ipv6-monitoring\/"},"modified":"2026-07-24T21:32:18","modified_gmt":"2026-07-24T21:32:18","slug":"ipv6-monitoring","status":"publish","type":"post","link":"https:\/\/www.dotcom-monitor.com\/blog\/es\/ipv6-monitoring\/","title":{"rendered":"Monitoreo de IPv6 con Dotcom-Monitor: Encuentra puntos ciegos de IPv6"},"content":{"rendered":"
\"Diagrama
Una verificaci\u00f3n IPv4 puede pasar mientras que la ruta IPv6 al mismo sitio est\u00e1 ca\u00edda.<\/figcaption><\/figure>\n

La mayor\u00eda de los sitios ahora funcionan con doble pila. El mismo servidor, API o p\u00e1gina de pago responde tanto sobre IPv4 como IPv6 al mismo tiempo. Esta configuraci\u00f3n te mantiene accesible a medida que las direcciones IPv4 se vuelven escasas, pero tambi\u00e9n divide tu tr\u00e1fico en dos redes que fallan de manera independiente.<\/p>\n

Aqu\u00ed est\u00e1 el problema que crea. Si tu monitoreo solo prueba sobre IPv4, reporta verde mientras que los usuarios nativos de IPv6 se encuentran con un gateway muerto, un registro DNS faltante o una regla de firewall que nunca se actualiz\u00f3. El panel muestra un 100 % de tiempo activo. Una porci\u00f3n creciente de tu audiencia dice que el sitio est\u00e1 roto.<\/p>\n

Este art\u00edculo explica c\u00f3mo Dotcom-Monitor prueba la ruta IPv6 en sus propios t\u00e9rminos: nodos nativos solo IPv6 sin t\u00faneles, scripts de navegador que cargan cada recurso de terceros sobre IPv6, y verificaciones de protocolo que a\u00edslan una falla IPv6 mientras la ruta IPv4 permanece limpia.<\/p>\n

\u00bfQu\u00e9 es el monitoreo IPv6?<\/h2>\n

El monitoreo IPv6 es la pr\u00e1ctica de verificar si tu sitio web, API y servicios responden correctamente sobre IPv6, desde el punto de vista de un usuario real de IPv6. Ejecuta las mismas verificaciones de disponibilidad y rendimiento que ya usas sobre IPv4\u2014resoluci\u00f3n DNS, carga de p\u00e1ginas, transacciones y respuestas de protocolo\u2014pero sobre la ruta IPv6, que tiene sus propios registros DNS, rutas y reglas de firewall.<\/p>\n

En un sitio de doble pila que sirva ambos protocolos, el monitoreo IPv6 es la \u00fanica forma de confirmar que la mitad IPv6 funciona. Una verificaci\u00f3n IPv4 pasa sin importar si IPv6 est\u00e9 saludable, por lo que sin una prueba de monitoreo dedicada a IPv6, una ca\u00edda que afecte solo a usuarios IPv6 permanece invisible. Las secciones a continuaci\u00f3n muestran c\u00f3mo Dotcom-Monitor ejecuta esa prueba desde nodos nativos solo IPv6, cubriendo tiempo activo, transacciones, DNS y verificaciones de protocolo en ambos planos.<\/p>\n

Por qu\u00e9 las redes de doble pila crean un punto ciego en el monitoreo<\/h2>\n

Un servicio de doble pila responde en dos protocolos, pero IPv4 e IPv6 no comparten una ruta. Son dos planos de enrutamiento. El tr\u00e1fico se resuelve mediante diferentes registros DNS, cruza distintas reglas de firewall y viaja por proveedores de tr\u00e1nsito diferentes antes de alcanzar el mismo origen.<\/p>\n

Por lo tanto, una solicitud puede tener \u00e9xito en un plano y fallar en el otro. El cliente IPv4 resuelve tu registro A, pasa un firewall IPv4 que tu equipo ha afinado por a\u00f1os, y carga la p\u00e1gina. El cliente IPv6 resuelve tu registro AAAA, toca un gateway que nunca fue configurado completamente y expira. Ambos usuarios escribieron la misma URL. Uno de ellos piensa que tu sitio est\u00e1 ca\u00eddo.<\/p>\n

Los dos planos tambi\u00e9n difieren internamente. IPv6 usa un encabezado base fijo de 40 bytes, un campo de clase de tr\u00e1fico de 8 bits y una etiqueta de flujo de 20 bits, por lo que los routers de tr\u00e1nsito manejan paquetes IPv6 de manera diferente al modelo IPv4 de mejor esfuerzo que han usado durante d\u00e9cadas. Y una sola subred IPv6 contiene muchas m\u00e1s direcciones que toda la Internet IPv4 heredada, lo cual cambia c\u00f3mo se propagan las rutas y c\u00f3mo se aplican los filtros. El punto para el monitoreo es simple: un resultado IPv4 no te dice nada confiable sobre la ruta IPv6. Debes probar cada una donde reside.<\/p>\n

C\u00f3mo Dotcom-Monitor ejecuta monitoreo nativo solo IPv6<\/h2>\n

Dotcom-Monitor ejecuta sus verificaciones desde una red global de monitoreo<\/a> de nodos en redes troncales reales IPv4 e IPv6. Algunos de esos nodos son de doble pila y pueden alcanzar un objetivo sobre cualquiera de los dos protocolos. Otros son solo IPv6.<\/p>\n

Las ubicaciones solo IPv6 son la parte que importa aqu\u00ed, por lo que se niegan a hacer. Gran parte del equipo de red que habla IPv6 tambi\u00e9n puede traducir el tr\u00e1fico de regreso a IPv4 mediante mecanismos de transici\u00f3n como t\u00faneles 6to4 o NAT64. Esa traducci\u00f3n es conveniente en producci\u00f3n y enga\u00f1osa en una prueba. Un agente de doble pila puede reportar un resultado limpio mientras silenciosamente recurre a IPv4, lo cual oculta la falla exacta que est\u00e1s tratando de encontrar.<\/p>\n

Un nodo solo IPv6 no usa traducci\u00f3n. Env\u00eda y recibe solo IPv6. Cuando una verificaci\u00f3n pasa desde ese nodo, el objetivo respondi\u00f3 genuinamente sobre IPv6 nativo. Cuando falla, has atrapado una falla real en IPv6 en lugar de una ca\u00edda cubierta con un respaldo.<\/p>\n

Ejecutar la misma verificaci\u00f3n desde un nodo nativo IPv4 y uno nativo solo IPv6 te da una comparaci\u00f3n clara para cada plano. Cualquier diferencia entre los dos resultados es un problema espec\u00edfico de IPv6, no ruido de medici\u00f3n.<\/p><\/blockquote>\n

Esa l\u00ednea base dividida se ejecuta en todos los tipos de dispositivos de la plataforma. El monitoreo de Aplicaciones Web conduce un navegador real a trav\u00e9s de una transacci\u00f3n con guion. El monitoreo de P\u00e1ginas Web carga una sola p\u00e1gina de la misma forma. El monitoreo de Infraestructura de Internet ejecuta verificaciones de protocolo contra tus servidores. Y el monitoreo de Servicios Web valida tus API. Cada uno puede asignarse a ubicaciones solo IPv6, y los dos dispositivos de navegador graban con la herramienta de secuencias EveryStep<\/a>, para que captures una ruta una vez y la reproduzcas desde cualquier nodo.<\/p>\n

Capturando fantasmas AAAA de terceros con monitoreo en navegador real<\/h2>\n

Tu origen puede soportar IPv6 perfectamente y tus p\u00e1ginas a\u00fan pueden fallar para usuarios IPv6. La raz\u00f3n es todo lo que no alojas. Una p\u00e1gina moderna incorpora un CDN, fuentes web, una etiqueta de anal\u00edticas, un widget de chat y un procesador de pagos. Cuando un usuario solo IPv6 carga esa p\u00e1gina, el navegador intenta obtener cada uno de esos recursos tambi\u00e9n sobre IPv6.<\/p>\n

Si un tercero nunca public\u00f3 un registro AAAA o descarta paquetes IPv6, el navegador se queda colgado en ese recurso. Espera a que la conexi\u00f3n expire y puede detener el resto del renderizado mientras espera. El resultado visible es una p\u00e1gina a medio cargar: navegaci\u00f3n faltante, marcos de recursos vac\u00edos, un bot\u00f3n de pago que nunca funciona. Tu panel interno de salud se mantiene verde todo el tiempo, porque tu origen est\u00e1 bien. La falla est\u00e1 en la red de otro.<\/p>\n

\"Comparaci\u00f3n
La misma p\u00e1gina, dos planos: en solo IPv6, los recursos terceros sin registros AAAA agotan el tiempo.<\/figcaption><\/figure>\n

El monitoreo de Aplicaciones Web<\/a> detecta esto cargando la p\u00e1gina completa en un navegador real desde un nodo solo IPv6 y grabando cada solicitud en la cascada. Para una sola p\u00e1gina en lugar de una transacci\u00f3n completa, el monitoreo de P\u00e1ginas Web<\/a> funciona igual. En lugar de un resultado pasa\/falla, ves cu\u00e1l recurso espec\u00edfico se resolvi\u00f3, cu\u00e1l agot\u00f3 el tiempo y d\u00f3nde se estanc\u00f3 el render. La tabla a continuaci\u00f3n muestra el patr\u00f3n que aparece.<\/p>\n

\n\n\n\n\n\n\n
Perfil de prueba<\/th>\nHTML principal<\/th>\nCDN y recursos multimedia<\/th>\nScripts de terceros<\/th>\nLo que ve el usuario<\/th>\n<\/tr>\n<\/thead>\n
Monitoreo IPv4<\/td>\nSe resuelve (registro A)<\/td>\nSe resuelve<\/td>\nSe resuelve<\/td>\nLa p\u00e1gina completa se renderiza normalmente.<\/td>\n<\/tr>\n
Monitoreo solo IPv6<\/td>\nSe resuelve (registro AAAA)<\/td>\nNo logra resolverse<\/td>\nAgota el tiempo<\/td>\nCarga parcial: dise\u00f1o roto, marcos vac\u00edos, pago detenido.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

Tomemos un flujo de compra como ejemplo. Un script de Aplicaciones Web inicia sesi\u00f3n, a\u00f1ade un art\u00edculo y llega al paso de pago. Sobre IPv4 toda la ruta pasa. Desde el nodo solo IPv6, el script del procesador de pagos no tiene registro AAAA, por lo que el navegador se detiene antes de que el formulario sea usable. El script falla en ese paso y te dice cu\u00e1l recurso lo caus\u00f3. Un ping de disponibilidad en tu propio dominio nunca habr\u00eda marcado el pago. Escribir la transacci\u00f3n con monitoreo sint\u00e9tico<\/a> transforma “el sitio est\u00e1 activo” en “los clientes realmente pueden pagar.”<\/p>\n

C\u00f3mo el monitoreo de infraestructura de Internet a\u00edsla fallas de protocolo IPv6<\/h2>\n

Las verificaciones en navegador capturan lo que ven los usuarios. Tambi\u00e9n necesitas la capa inferior. El monitoreo de Infraestructura de Internet<\/a> ejecuta verificaciones a nivel de protocolo contra tus servidores, tan a menudo como una vez por minuto, y las ejecuta desde ubicaciones solo IPv6 igual que hacen los dispositivos navegador.<\/p>\n

Esa frecuencia y ese aislamiento son la parte \u00fatil. Si tu endpoint HTTP\/S o DNS responde sobre IPv4 pero falla sobre IPv6, el monitoreo de Infraestructura Internet reporta el error de protocolo IPv6 por s\u00ed solo en lugar de promediarlo con el resultado saludable de IPv4. El monitoreo de Servicios Web<\/a> hace lo mismo para tus endpoints de API. Obtienes una alerta que nombra el protocolo y la ruta, no un vago “el tiempo de respuesta subi\u00f3.”<\/p>\n

El DNS merece una verificaci\u00f3n dedicada. Un sitio de doble pila necesita que ambos, registros A y AAAA, se resuelvan globalmente a igual velocidad, y un registro AAAA obsoleto o ausente es una de las fallas IPv6 m\u00e1s comunes. El monitoreo DNS<\/a> confirma que ambos registros responden en todas partes y vigila los valores TTL para que un cambio de ruta durante una migraci\u00f3n no deje a usuarios IPv6 anclados a una entrada muerta. Cuando se dispara una alerta, un traceroute IPv6<\/a> autom\u00e1tico muestra si la ca\u00edda ocurri\u00f3 en tu origen o dentro de la tabla de enrutamiento de un proveedor de tr\u00e1nsito upstream.<\/p>\n

C\u00f3mo Dotcom-Monitor expone la latencia de Happy Eyeballs<\/h2>\n

Algunos problemas de IPv6 nunca se muestran como una ca\u00edda. Se muestran como un sitio que se siente lento por razones que nadie puede identificar. La causa suele ser Happy Eyeballs.<\/p>\n

Happy Eyeballs (RFC 8305) es un fallback de navegador. El navegador empieza su conexi\u00f3n IPv6 primero, espera un intervalo corto (el retraso del intento de conexi\u00f3n, aproximadamente 250 milisegundos por defecto) antes de correr tambi\u00e9n en carrera la IPv4. Si la ruta IPv6 est\u00e1 rota o lenta, el intento IPv4 gana y lleva la solicitud. La conexi\u00f3n a\u00fan tiene \u00e9xito, por lo que el usuario rara vez ve un error.<\/p>\n

Eso es bueno para el usuario y malo para tu visibilidad. La espera antes de que el navegador abandone IPv6 y se incline hacia IPv4 se suma al Tiempo Real hasta el Primer Byte y a la Mayor Pintura de Contenido. Cada usuario IPv6 paga un impuesto de latencia en una conexi\u00f3n que finalmente funciona sobre IPv4. Las herramientas pasivas y los an\u00e1lisis de usuarios reales registran una carga exitosa y siguen adelante, por lo que la falla estructural permanece invisible mientras la experiencia se degrada silenciosamente.<\/p>\n

El monitoreo nativo solo IPv6 mide el impuesto directamente, porque el fallback no est\u00e1 disponible para ocultarse detr\u00e1s. La ruta IPv6 o tiene buen desempe\u00f1o o no, y ese n\u00famero aparece en el informe. Los informes comparativos de cascada<\/a> ponen los tiempos IPv4 e IPv6 uno junto al otro, de modo que una diferencia de 250 milisegundos que los usuarios sienten pero no pueden describir se convierte en una l\u00ednea en la que puedes se\u00f1alar. Si quieres un repaso sobre c\u00f3mo leer esos gr\u00e1ficos, consulta nuestra gu\u00eda para gr\u00e1ficos de cascada<\/a>.<\/p>\n

C\u00f3mo configurar el monitoreo de doble pila en Dotcom-Monitor<\/h2>\n

Aqu\u00ed est\u00e1 la configuraci\u00f3n que te da ambos planos sin duplicar tu trabajo de mantenimiento.<\/p>\n

    \n
  1. Paso 1: Construye la verificaci\u00f3n una vez en EveryStep.<\/strong> Graba tu camino cr\u00edtico o verificaci\u00f3n de protocolo una sola vez. El mismo script EveryStep se ejecuta en cada ubicaci\u00f3n, as\u00ed que no mantienes versiones separadas para IPv4 e IPv6.<\/li>\n
  2. Paso 2: Asigna ubicaciones nativas IPv4 y solo IPv6.<\/strong> A\u00f1ade la verificaci\u00f3n a un nodo nativo IPv4 y a un nodo solo IPv6. Evita ubicaciones 6to4 y NAT64 para la l\u00ednea base IPv6 para que no haya traducci\u00f3n entre el nodo y tu objetivo.<\/li>\n
  3. Paso 3: Ajusta la frecuencia de la verificaci\u00f3n.<\/strong> Ejecuta verificaciones de protocolo de Infraestructura de Internet tan a menudo como una vez por minuto. Programa verificaciones de navegador de Aplicaciones Web en el intervalo que tu SLA requiera.<\/li>\n
  4. Paso 4: Agrega verificaciones DNS para registros A y AAAA.<\/strong> Confirma que ambos registros se resuelvan globalmente a igual velocidad y vigila los valores TTL para que una migraci\u00f3n no deje a usuarios IPv6 atrapados en una ruta obsoleta.<\/li>\n
  5. Paso 5: Dispara un traceroute IPv6 ante desviaciones.<\/strong> Configura alertas para ejecutar un traceroute en el momento en que la disponibilidad o el tiempo de respuesta baje, para que puedas distinguir r\u00e1pidamente una falla de origen de una falla en tr\u00e1nsito upstream.<\/li>\n
  6. Paso 6: Compara las dos cascadas.<\/strong> Revisa los informes IPv4 e IPv6 lado a lado. Cualquier recurso, salto o protocolo que difiera entre ellos es tu problema espec\u00edfico de IPv6.<\/li>\n<\/ol>\n

    Conclusi\u00f3n<\/h2>\n

    Doble pila significa que cada solicitud tiene dos maneras de llegarte y dos maneras de fallar. El monitoreo solo IPv4 vigila una de ellas y reporta sobre ambas, que es c\u00f3mo un sitio obtiene un r\u00e9cord perfecto de tiempo activo mientras que los usuarios IPv6 experimentan tiempos de espera, p\u00e1ginas a medio cargar y una penalizaci\u00f3n de latencia que nadie puede rastrear.<\/p>\n

    Dotcom-Monitor cierra esa brecha probando la ruta IPv6 en sus propios t\u00e9rminos. Nodos nativos solo IPv6 sin t\u00faneles, scripts de navegador de Aplicaciones Web que cargan cada recurso de terceros sobre IPv6, verificaciones de protocolo de Infraestructura de Internet hasta una vez por minuto, y cascadas lado a lado que separan una falla de origen de una de upstream. Dejas de adivinar sobre la mitad de tu tr\u00e1fico que las verificaciones IPv4 nunca tocaron.<\/p>\n

    \n

    Prueba tu ruta IPv6 antes que tus usuarios<\/h2>\n

    Despliega nodos de monitoreo nativos solo IPv6 y ve exactamente lo que experimentan tus usuarios de doble pila, hasta el recurso de terceros. Comienza una prueba gratuita de 30 d\u00edas con Dotcom-Monitor.<\/p>\n

    Empieza tu prueba gratuita<\/a><\/p>\n<\/div>\n","protected":false},"excerpt":{"rendered":"

    Las verificaciones del protocolo IPv6 se ejecutan una vez por minuto desde nodos nativos, aislando fallas que su monitoreo IPv4 nunca detectar\u00e1. As\u00ed es como Dotcom-Monitor lo hace.<\/p>\n","protected":false},"author":39,"featured_media":34304,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-34318","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/es\/wp-json\/wp\/v2\/posts\/34318","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/es\/wp-json\/wp\/v2\/users\/39"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/es\/wp-json\/wp\/v2\/comments?post=34318"}],"version-history":[{"count":0,"href":"https:\/\/www.dotcom-monitor.com\/blog\/es\/wp-json\/wp\/v2\/posts\/34318\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/es\/wp-json\/wp\/v2\/media\/34304"}],"wp:attachment":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/es\/wp-json\/wp\/v2\/media?parent=34318"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/es\/wp-json\/wp\/v2\/categories?post=34318"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/es\/wp-json\/wp\/v2\/tags?post=34318"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}