Cómo reiniciar un proxy inverso sin reiniciar los servicios que mantienen el estado de las sesiones
El mantenimiento planificado del proxy es más seguro cuando el proxy inverso puede recargarse o reiniciarse de forma independiente de los servicios de autenticación y gestión del estado de sesión que se encuentran detrás de él.
Por lo general, un proceso de proxy no necesita ser propietario del estado de inicio de sesión que reenvía. Antes del mantenimiento, identifica qué componente firma las cookies, almacena las sesiones del lado del servidor, termina la autenticación y drena las conexiones HTTP activas. Mantén en ejecución esos componentes con estado, prioriza las recargas progresivas del proxy cuando solo cambie la configuración y verifica que un reemplazo completo del proxy vuelva a conectarse a la misma puerta de enlace de autenticación y al mismo almacén de sesiones, con los secretos sin cambios.
Separa el ciclo de vida del proxy del ciclo de vida del servicio de autenticación
Revisa las dependencias de Compose, las políticas de reinicio, los scripts compartidos y las acciones del administrador de la pila para asegurarte de que reiniciar el proxy no vuelva a crear automáticamente la puerta de enlace de autenticación, la aplicación, Redis o la base de datos.
Un ejemplo de arquitectura de sesiones utiliza Redis fuera del ciclo de vida del proxy para que varias instancias de autenticación y sus reinicios puedan compartir el mismo backend de sesiones.
No agrupes todos los servicios periféricos en un único comando de reinicio indiscriminado. Si un cambio de certificado o de ruta solo afecta al proxy, deja intactos los servicios que validan el estado de inicio de sesión existente.
Recarga la configuración en lugar de reiniciar cuando sea posible
Para cambios de rutas, certificados o encabezados, utiliza el método de recarga progresiva compatible con el proxy en lugar de detener el servicio. Valida la configuración antes de aplicarla para que un error de sintaxis no convierta el mantenimiento planificado en una interrupción del servicio.
La guía de API7 sobre NGINX explica cómo los trabajadores antiguos drenan las conexiones mientras los nuevos aceptan solicitudes con la configuración actualizada.
Una recarga conserva la familia de procesos del proxy, pero no protege un servicio de autenticación independiente si tu script de implementación también reinicia ese servicio. Mantén independientes esas dos cuestiones del ciclo de vida.
Conserva el almacenamiento externo de sesiones al reemplazar el proxy
Si una puerta de enlace de autenticación almacena los datos de sesión fuera de las cookies, mantén persistente y sin cambios su backend de sesiones Redis u otro durante la operación del proxy. Registra la dirección del backend y el secreto utilizados por cada instancia de autenticación.
OAuth2 Proxy admite Redis como almacenamiento compartido de sesiones cuando las sesiones deben compartirse entre varias instancias.
No confundas una caché desechable con el estado de inicio de sesión autorizado. Si el backend de sesiones es necesario para validar a los usuarios actuales, reinícialo o vacíalo únicamente mediante su propio procedimiento de mantenimiento probado.
Mantén estables los secretos de las cookies y de firma
Registra el secreto de cifrado o firma de cookies utilizado por la puerta de enlace de autenticación y asegúrate de que la pila de reemplazo del proxy monte la misma fuente de secretos. Generar un valor nuevo durante el redespliegue invalidará las cookies del navegador que, por lo demás, funcionan correctamente.
Una guía sobre sesiones mediante proxy inverso señala que una política de sesiones estable sobrevive a los reinicios, en lugar de depender de la duración de una única conexión TCP.
Rota los secretos de firma como un cambio de seguridad independiente, con una expectativa explícita de cierre de sesión o una estrategia de solapamiento. No combines la rotación de secretos con una recarga planificada normal del proxy, a menos que la invalidación de sesiones sea intencionada.
Drena las conexiones durante un reinicio completo del proxy
Cuando sea necesario reemplazar el binario o el contenedor del proxy, utiliza su mecanismo de reinicio progresivo o sin interrupciones, si está disponible, para que las solicitudes establecidas no se corten a mitad de la respuesta. Establece un tiempo de espera de mantenimiento para las conexiones de larga duración.
La guía de recarga de HAProxy muestra cómo las recargas sin interrupciones conservan las conexiones en lugar de finalizar inmediatamente el proceso antiguo.
La continuidad de las conexiones y la continuidad del inicio de sesión son diferentes. Aunque un WebSocket vuelva a conectarse, la sesión debe seguir siendo válida porque el proxy de reemplazo llega a los mismos servicios de autenticación y de estado.
Prueba una sesión antes y después del mantenimiento planificado
Utiliza un navegador con una sesión iniciada y otra sesión privada nueva. Registra la cookie de sesión, la ruta del proxy, el servicio de autenticación y el backend antes del mantenimiento; después, recarga o reemplaza únicamente el proxy y repite la misma solicitud protegida.
Una guía operativa de Caddy recomienda recargar en lugar de reiniciar por completo para las actualizaciones de configuración planificadas.
El diseño de mantenimiento funciona cuando las sesiones iniciadas existentes sobreviven, los nuevos inicios de sesión siguen funcionando y ninguna dependencia con estado recibió un reinicio involuntario. El artículo relacionado de ZimaSpace sobre la pérdida de sesiones tras reiniciar el proxy sigue siendo la vía de recuperación adecuada si los usuarios continúan desconectados.
Preguntas frecuentes
¿Una recarga progresiva del proxy garantiza que los usuarios mantengan la sesión iniciada?
No. Protege las conexiones del proxy, pero los usuarios pueden cerrar su sesión si el servicio de autenticación, el almacén de sesiones o el secreto de firma de cookies cambia al mismo tiempo.
¿Redis siempre debe sobrevivir al reinicio del proxy?
Solo cuando Redis almacena el estado de sesión u otra dependencia persistente de la autenticación. Una instancia de Redis que solo funciona como caché tiene un límite de recuperación diferente.
¿Basta con mantener el mismo nombre de cookie?
No. El secreto de firma o cifrado y el estado de sesión del backend también deben seguir siendo compatibles con la cookie que ya tiene el navegador.
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...
