¿Por qué un proxy inverso devuelve un error 502 después de reconstruir un contenedor?
Un proxy inverso devuelve un error 502 después de reconstruir un contenedor cuando ya no puede abrir una conexión válida con el servicio ascendente reconstruido.
La reconstrucción puede reemplazar el contenedor, asignar una dirección nueva, desconectar o cambiar el nombre de una red de Docker, modificar el puerto expuesto, restaurar una configuración incompleta o iniciar el proxy antes de que la aplicación esté lista. El diagnóstico correcto comienza con el registro de errores del proxy y sigue la dirección ascendente exacta desde el proxy hasta el contenedor, en lugar de reiniciar ambos servicios hasta que el error desaparezca temporalmente.
Confirma que el error 502 proviene de un fallo de conexión con el servicio ascendente
Solicita una vez el dominio afectado y registra la marca de tiempo, el estado del proxy, la dirección ascendente y el mensaje de error completo. Distingue entre conexión rechazada, host no encontrado, tiempo de espera agotado, conexión restablecida, fallo del protocolo de enlace TLS y respuesta no válida.
Un error 502 significa que el proxy no recibió una respuesta ascendente utilizable, pero el detalle del error determina si el destino estaba ausente, era inaccesible, no estaba escuchando o utilizaba el protocolo incorrecto. Una guía actual de resolución de problemas de NGINX señala que la reconstrucción de un contenedor puede hacer que el proxy siga utilizando una dirección de backend antigua hasta que se actualice la resolución de nombres o la configuración.
Prueba la aplicación directamente desde el host del proxy o desde el contenedor del proxy utilizando el nombre, la dirección, el puerto y el protocolo ascendentes registrados. Si esa solicitud directa falla de la misma manera, mantén la investigación entre el proxy y el contenedor en lugar de cambiar el DNS público o los certificados.
Compara el destino ascendente antes y después de la reconstrucción
Inspecciona el nombre del contenedor reconstruido, el nombre del servicio, la IP interna, el puerto expuesto, el puerto publicado, los alias de red y las redes conectadas. Compáralos con la configuración del proxy y con su último destino operativo.
Un problema de nginx-proxy describe una reconstrucción que cambió la IP del contenedor de la aplicación mientras el proxy seguía enviando solicitudes al servicio ascendente del contenedor inaccesible. El dominio público seguía siendo correcto y solo había cambiado la identidad ascendente privada.
Prefiere un nombre de servicio estable de Compose o un alias de red en lugar de una IP de contenedor. Si la IP está fijada intencionadamente, verifica que el servicio reconstruido la haya recibido realmente y que ningún otro contenedor posea ahora esa dirección.
Verifica que el proxy y la aplicación sigan compartiendo una red de Docker
Enumera las redes conectadas al proxy y a la aplicación y confirma que compartan al menos una red definida por el usuario. Un puerto publicado en el host no hace que el nombre del contenedor sea accesible automáticamente desde otra red de Docker aislada.
Un caso de redes de Docker descubrió que trasladar un servicio dependiente a la red adecuada eliminaba inmediatamente las respuestas 502 recurrentes, lo que demostraba cómo una ruta ascendente inaccesible puede producir errores incluso cuando todos los contenedores siguen ejecutándose.
Conecta los servicios mediante Compose en lugar de utilizar comandos aislados, para que la relación sobreviva a las reconstrucciones. Prueba la resolución DNS y el puerto ascendente desde dentro del contenedor del proxy después de recrear la pila.
Comprueba el puerto interno de escucha y la dirección de enlace
Confirma que la aplicación esté escuchando en el puerto que utiliza el proxy y en una dirección accesible desde la red de contenedores. No confundas un puerto publicado en el host con el puerto interno de escucha del contenedor.
Un proxy solo puede conectarse después de que la aplicación se vincule a una dirección más amplia que la de loopback. Un servicio que escucha en 127.0.0.1 dentro de su propio contenedor no está disponible para el proxy, aunque un comando de comprobación local se ejecute correctamente.
Inspecciona el registro de la aplicación, la lista de sockets y una solicitud directa desde el contenedor del proxy. Si el puerto rechaza las conexiones, corrige el escuchador o la configuración de la aplicación antes de añadir reintentos o aumentar los tiempos de espera del proxy.
Espera a que la aplicación esté lista en lugar de esperar solo al inicio del contenedor
Un contenedor reconstruido puede estar ejecutándose mientras las migraciones, la recuperación de la base de datos, la preparación de la caché o la generación de la configuración aún impiden que la aplicación acepte solicitudes. Compara la marca de tiempo del primer error 502 con los registros de estado y de inicio.
Una conversación sobre la resolución de problemas de Grist muestra cómo la arquitectura de Docker, la configuración del entorno y la disponibilidad del servicio ascendente pueden combinarse y provocar fallos 502 persistentes del lado del contenedor después de una reconstrucción.
Añade una comprobación de estado significativa y haz que el proxy o los servicios dependientes esperen a que esté disponible la operación que necesitan los clientes, no simplemente a que exista un proceso. Mantén los reintentos limitados para que una aplicación que ha fallado permanentemente no parezca estar iniciándose lentamente.
Actualiza la resolución del proxy y reconstruye la ruta estable
Recarga o recrea el proxy después de corregir el nombre del servicio, la red, el puerto y el estado de salud. Si el proxy solo resuelve los nombres al iniciarse, configura una resolución en tiempo de ejecución compatible o un orden de reinicio predecible.
El flujo de trabajo de ZimaSpace para aislar una dependencia de contenedor defectuosa ofrece el diagnóstico complementario cuando el servicio ascendente se cierra repetidamente en lugar de mantenerse en buen estado.
La reparación solo está completa cuando el proxy resuelve el nombre del servicio después de otra reconstrucción, alcanza el puerto interno previsto, espera durante el inicio y sirve el dominio sin editar manualmente las IP. Elimina los destinos temporales con IP directa y las conexiones de red no documentadas después de la validación.
Productos recomendados
Soporte y Consejos
Más para leer
¿Puede Plex compartir una GPU con otro contenedor de Docker?
Plex y otro contenedor suelen poder acceder a la misma GPU, pero debes probar la compatibilidad de los controladores, la asignación de dispositivos, la...
Cómo saber si un error de Plex proviene del cliente o del servidor
Reproduce el mismo elemento en otro cliente, compara la ruta de la sesión y recopila pruebas del servidor solo después de que el alcance...
Cómo configurar la caché de Plex y el almacenamiento temporal para la transcodificación
Protege el estado persistente de Plex mientras colocas los archivos temporales de transcodificación en un almacenamiento local adecuado; después, verifica la limpieza, el espacio...
