Si el inicio de sesión de Plex falla únicamente después de reiniciar el proxy inverso, comprueba primero el acceso local directo a Plex; una sesión directa funcional traslada el problema al proxy, al DNS o a la ruta TLS.
El error más común es restablecer las credenciales de Plex cuando el servidor sigue funcionando correctamente. Los proxies inversos añaden una dirección ascendente, un nombre de host, un certificado, encabezados de solicitud y, en ocasiones, una red de Docker entre el navegador y Plex. Comprueba esas capas en orden. El objetivo de la recuperación no es simplemente volver a mostrar la página de inicio de sesión una vez, sino conseguir que la misma ruta del proxy siga funcionando después de un reinicio controlado del proxy sin cambiar la identidad del servidor Plex.
Comprueba si Plex sigue siendo accesible
Abre Plex directamente en la LAN usando la dirección y el puerto del servidor que normalmente utilizas para la administración local. Si la misma cuenta inicia sesión y el servidor se carga, no modifiques la autenticación ni los datos del servidor Plex. Ya has aislado el problema a la ruta añadida por el proxy.
Plex ofrece URL de acceso personalizadas al servidor para configuraciones de red inusuales, como proxies inversos y VPN. Si la URL que publica Plex ya no coincide con el nombre de host o el esquema que utiliza el cliente, el descubrimiento y el comportamiento de la conexión segura pueden volverse inconsistentes aunque el acceso local directo siga funcionando.
Si el acceso local directo también falla, deja de considerar el reinicio del proxy como la causa. Comprueba primero el estado del contenedor de Plex, los registros del servidor y el montaje de datos. La regla de decisión es estricta: si el acceso directo funciona, el problema está en la ruta del proxy; si falla, está en la ruta del servidor o del contenedor.
Comprueba el destino ascendente del proxy después del reinicio
Inspecciona el destino del proxy y confirma que se resuelve en el servicio Plex actual. Un proxy configurado con una IP temporal del contenedor puede fallar después de recrear un contenedor o una red. Prefiere una dirección de host estable o el nombre del servicio de Docker en una red definida por el usuario y compartida, en lugar de copiar una IP efímera en la configuración del proxy.
El comportamiento de las redes puente definidas por el usuario de Docker permite que los contenedores de la misma red se comuniquen mediante nombres y ofrece un aislamiento explícito. Por eso, el nombre de un servicio es un destino ascendente más duradero que una dirección de contenedor que puede cambiar durante eventos del ciclo de vida.
Después de corregir el destino ascendente, recarga únicamente el proxy y vuelve a probar la URL de Plex a través del proxy. Si el proxy ya llega a Plex pero el inicio de sesión sigue entrando en un bucle, la siguiente rama es el nombre de host público, TLS o la URL de acceso publicada, no la ruta del contenedor.
Verifica la ruta de nombre de host y TLS sin debilitar la seguridad
Confirma que el navegador utiliza el nombre de host HTTPS previsto y que el proxy presenta un certificado válido para ese nombre. No resuelvas una discrepancia de certificado o de nombre de host desactivando globalmente las conexiones seguras. Si cambiaste el dominio o la ruta del proxy, actualiza la URL de acceso personalizada de Plex para que el descubrimiento del servidor dirija a los clientes hacia la ruta que realmente mantienes.
Para un diseño más amplio del acceso remoto, la guía de acceso remoto a nubes privadas de ZimaSpace destaca las puertas de enlace controladas, los túneles y los límites explícitos en lugar de abrir servicios sin control. La misma regla se aplica aquí: repara la ruta de entrada prevista en lugar de eludirla mediante una exposición temporal insegura.
Borra la sesión del navegador solo después de superar las comprobaciones de enrutamiento y TLS. Una cookie obsoleta puede complicar las pruebas, pero borrar el estado antes de reparar la ruta de red puede ocultar el fallo real. Usa una ventana privada del navegador como prueba limpia sin eliminar el estado funcional de los clientes en todas partes.
Reinicia de nuevo el proxy y repite la prueba de inicio de sesión original
Cuando el inicio de sesión funcione, reinicia de nuevo el proxy inverso deliberadamente. Espera a que vuelva a estar operativo y utiliza exactamente el mismo nombre de host y el mismo cliente que fallaron originalmente. Una solución correcta implica que el destino ascendente se resuelva, TLS sea válido, Plex se descubra en la URL prevista y la cuenta pueda iniciar sesión sin ediciones manuales después del reinicio.
Si el segundo reinicio vuelve a romper la ruta, inspecciona el orden de inicio y la resolución de nombres entre el proxy y Plex. El problema no está resuelto si una persona debe editar una IP después de cada evento del ciclo de vida. Haz explícita la dependencia en la red de Docker o en la configuración del proxy.
Escala el problema a la autenticación de Plex únicamente cuando tanto el enrutamiento directo como el realizado mediante el proxy funcionen correctamente y el fallo de inicio de sesión persista en varios clientes. En ese momento, recopila los registros de Plex con marcas de tiempo y los datos de la cuenta y del servidor, en lugar de seguir cambiando la configuración del proxy que ya has verificado.
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...

