Si un sitio web local o un servidor de desarrollo funciona en 127.0.0.1 pero falla en localhost, o funciona en una familia de direcciones pero no en la otra, compruebe la dirección de escucha del servidor y pruebe cada ruta por separado. En un Mac, 127.0.0.1 es la dirección de bucle invertido (loopback) de IPv4 y ::1 es la dirección de bucle invertido de IPv6; ambas hacen referencia a su propio ordenador. Que una prueba sea satisfactoria en una no demuestra que el servicio esté escuchando en la otra.

1. Comprobar si el servicio está escuchando

Utilice el puerto en el que se supone que debe prestar servicio su aplicación. Los siguientes ejemplos utilizan el puerto 8000; sustitúyalo por el puerto real.

lsof -nP -iTCP:8000 -sTCP:LISTEN

lsof muestra los archivos abiertos, incluidos los sockets de red. Las opciones limitan los resultados a los listeners TCP en ese puerto y evitan la resolución de nombres. Si no hay salida, es posible que el servicio no se esté ejecutando, que use un puerto diferente o que no haya abierto un listener TCP. Compruebe los mensajes de inicio de la aplicación y el puerto configurado antes de cambiar los ajustes de red de macOS. (Manual de lsof)

Observe la dirección en la columna NAME. Un listener que aparece en 127.0.0.1:8000 está vinculado al loopback IPv4; uno que aparece en [::1]:8000 está vinculado al loopback IPv6. Una dirección comodín (wildcard) puede indicar que está escuchando en más interfaces aparte del loopback, dependiendo del servidor y del sistema operativo. El diagnóstico clave es si la dirección de vinculación (bind) real del servidor incluye la familia de direcciones que está probando. Esta interpretación se deduce de la dirección de socket notificada por lsof; la configuración de la aplicación determina qué dirección abre el servidor.

2. Probar IPv4 e IPv6 directamente

Haga una petición al mismo puerto y ruta a través de cada dirección de bucle invertido. curl le permite probar la conexión HTTP sin depender de la selección de direcciones que haga un navegador.

curl -v --connect-timeout 3 http://127.0.0.1:8000/
curl -g -v --connect-timeout 3 'http://[::1]:8000/'

Los corchetes son obligatorios alrededor de un literal IPv6 en una URL; -g le indica a curl que no los interprete como sintaxis de coincidencia de patrones (globbing) de URL. Las comillas simples conservan la URL de forma literal en las shells predeterminadas de macOS. Curl documenta estas reglas de URL y proporciona --ipv4 y --ipv6 para restringir la resolución del nombre de host. (Sintaxis de URL de curl, manual de curl)

Un rechazo de conexión generalmente significa que no hay ningún listener aceptando conexiones en esa dirección y puerto. Un tiempo de espera agotado (timeout) sugiere que la conexión no se completó dentro del límite. Si curl imprime una respuesta HTTP, incluso un estado de error como 404, la conexión TCP y HTTP llegó a un servidor; investigue la ruta o la respuesta de la aplicación en lugar de tratarlo como un fallo de conexión IPv4/IPv6.

3. Comparar localhost con cada dirección

Ahora pruebe el nombre de host utilizando las opciones de IPv4 e IPv6 de curl, y luego intente sin una restricción de familia:

curl -4 -v --connect-timeout 3 http://localhost:8000/
curl -6 -v --connect-timeout 3 http://localhost:8000/
curl -v --connect-timeout 3 http://localhost:8000/

Las opciones -4 y -6 de curl solicitan únicamente direcciones IPv4 o IPv6 para los nombres de host. Su documentación señala que macOS puede devolver direcciones mapeadas a IPv4 en una solicitud de resolución exclusiva de IPv6, por lo que debe tratar estas pruebas como intentos de conexión restringidos de curl, no como una auditoría completa del comportamiento del resolver de cada aplicación. (Manual de curl)

Utilice los resultados para acotar la causa. Si la prueba directa de IPv4 funciona y la prueba directa de IPv6 falla, mientras que lsof solo muestra un listener de IPv4, es probable que deba configurarse el servidor para que también escuche en IPv6 si se requiere acceso mediante este protocolo. Lo contrario se aplica cuando solo funciona el listener de IPv6. Si ambas pruebas directas funcionan pero localhost no, compare los resultados de curl forzando la familia e inspeccione la configuración de nombre de host, proxy o URL de la aplicación. Diferentes aplicaciones pueden resolver o conectarse a los nombres de manera distinta; Apple recomienda API de red independientes de la familia de direcciones para los desarrolladores que crean aplicaciones que necesitan gestionar IPv4 e IPv6. (Apple Developer: Compatibilidad con redes que solo utilizan IPv6)

4. Aplicar la solución donde apunten las pruebas

Cuando solo una dirección de loopback acepte conexiones, cambie la configuración de la dirección de vinculación (bind-address) del servidor local o utilice la familia de direcciones que realmente admite. No asuma que cambiar la configuración de IPv4 o IPv6 de la conexión Wi-Fi del Mac solucionará un listener de loopback: las peticiones de loopback se dirigen al propio Mac, mientras que esos ajustes de Red configuran la conexión de red de una interfaz. Los controles TCP/IP de Apple pueden configurar IPv4 e IPv6 para un servicio de red seleccionado, pero no configuran el socket de escucha de una aplicación individual. (Soporte técnico de Apple: Cambiar los ajustes de TCP/IP en el Mac)

Si ninguna de las direcciones directas funciona, verifique que el servidor se esté ejecutando, que el puerto sea el correcto y que el protocolo esperado sea HTTP o HTTPS. Si una dirección directa funciona pero las pruebas del nombre de host varían, utilice la dirección de lsof y la salida de curl conjuntamente para decidir si debe ajustar la dirección de vinculación del servidor o la URL del cliente. Esta secuencia distingue entre la falta de un listener y un problema de vinculación específico de una familia, sin asumir que cada fallo de localhost es un problema de DNS.

Fuentes