IPv4 funciona, pero IPv6 falla: guía de diagnóstico

El navegador puede ocultar la ruta que falla

Los registros AAAA publican direcciones IPv6; no demuestran que el servicio web funcione en ellas. Los clientes con Happy Eyeballs pueden conectarse por otra familia de direcciones aunque falle la ruta IPv6. Pruebe IPv4 e IPv6 de forma explícita: una visita correcta en el navegador no confirma ambas.

Compare el mismo nombre de host y URL

Sustituya example.com por su sitio y ejecute ambos comandos desde un host con IPv6 operativo. En PowerShell use curl.exe. Estas solicitudes GET limitadas mantienen la verificación TLS por nombre de host y no siguen redirecciones. Compare el estado, la IP elegida y el contenido guardado; examine el destino de una redirección por separado.

curl -4 --silent --show-error --connect-timeout 5 --max-time 15 --output ipv4.html --write-out "HTTP %{http_code}; IP %{remote_ip}\n" https://example.com/
curl -6 --silent --show-error --connect-timeout 5 --max-time 15 --output ipv6.html --write-out "HTTP %{http_code}; IP %{remote_ip}\n" https://example.com/

Compruebe el nodo de prueba antes de culpar al sitio

La sección IPv6 de check.uk.app prueba la URL enviada desde su nodo. Si este no tiene una ruta IPv6, el resultado es no disponible, no un fallo del sitio. Un tiempo de espera agotado desde un solo lugar tampoco identifica por sí mismo la red responsable. Repita desde otra conexión IPv6 cuyo funcionamiento conozca.

Localice el fallo por capas

Compare las respuestas AAAA autoritativas y recursivas con las direcciones asignadas. Confirme que la dirección esté configurada, que funcione el enrutamiento y que el servidor web o proxy escuche en IPv6 en el puerto previsto. Revise las reglas del cortafuegos IPv6 independientemente de IPv4.

Si la conexión se establece pero falla TLS, compruebe la cobertura del nombre de host, la cadena de certificados y el host virtual seleccionado por el punto de escucha IPv6. Si cambia HTTP, compare los backends del proxy y el enrutamiento de la aplicación. Si las transferencias se detienen después de conectar, investigue la MTU de la ruta y el tratamiento necesario de ICMPv6; no desactive TLS para ocultar el fallo.

Verifique la recuperación sin perjudicar IPv4

Guarde los valores DNS, TTL y ajustes del servidor antes de cambiar nada. Modifique la capa identificada y repita ambas solicitudes y los recorridos importantes. Confirme que ambas familias devuelvan el sitio previsto con TLS válido. Las cachés DNS pueden seguir usando el antiguo AAAA hasta que caduque.

Las opciones de los comandos se han probado en puntos de escucha loopback IPv4 e IPv6 aislados, incluido un fallo por puerto cerrado. Esto valida el procedimiento de diagnóstico, no la accesibilidad IPv6 global. Publique AAAA después de configurar el servicio y superar una prueba externa, no antes.