Tengo un servidor grpc-go ejecutándose en un contenedor docker, escuchando en 0.0.0.0:8080 . Descubrí que esto funciona después de tener fallas al escuchar en localhost o 127.0.0.1 en un contenedor acoplable, y solo falló al ejecutarse en un contenedor acoplable, no si lo ejecuto en la misma máquina.
También un servidor web simple funcionó escuchando en localhost o 127.0.0.1.
Descubrí que 0.0.0.0 está escuchando en cualquier adaptador de red, pero no encontré otras explicaciones.
Bueno, problema resuelto, pero estoy buscando una explicación, ¿sabes?
Networking es uno de los espacios de nombres en docker, similar a los espacios de nombres pid y filesystem. Si mata pid 1 dentro de un contenedor, eso mata el proceso dentro del contenedor y no systemd/init en el host (siempre que no anule el espacio de nombres). Y si rm -rf /bin dentro de un contenedor, eso elimina los archivos de ese contenedor, no del host (siempre y cuando no tenga un montaje de volumen). De manera similar, la red de loopback (localhost o 127.0 0.1) en un espacio de nombres se refiere solo a ese espacio de nombres, no al host.
Pensándolo desde un nivel superior, solo se puede acceder al bucle invertido en el host desde ese host, no puede acceder desde otro host o un balanceador de carga externo. Las redes con espacio de nombres funcionan de manera muy similar. El loopback dentro del contenedor puede ser alcanzado por otros procesos dentro del mismo espacio de nombres de red, pero no por contenedores en otros espacios de nombres, y no desde el host con reenvío de puertos, ya que reenvía a la interfaz de red virtual, de forma similar a cómo un balanceador de carga externo reenvía al interfaz de red del anfitrión.
¡Esto puede deberse al caché del navegador!
En mi caso, tuve algunos errores al configurar el archivo .htaccess que hace redireccionamientos 301. Debido a que probé con localhost y 127.0.0.1 , ya no funcionan. Cuando los probé con curl , descubrí que es solo un caché del navegador.