Un usuario carga contra BunkerWeb por su fiabilidad como proxy inverso

Un usuario de r/selfhosted ha publicado un análisis poco amable sobre BunkerWeb, el proxy inverso con WAF, antiautomatización y integración con CrowdSec que se despliega como contenedor Docker. Su tesis: para dos o tres servicios personales puede pasar, pero no lo metería en una empresa. El texto no se queda en la impresión general y baja al detalle de configuración y logs.

El caso que describe es concreto. Monta un proxy inverso hacia una instancia de FreshRSS alojada en otra DMZ. Desde dentro del contenedor de BunkerWeb, el backend responde correctamente con un 302. La configuración generada contiene la directiva proxy_pass http://10.0.0.6:80;. Y aun así BunkerWeb devuelve HTTP/2 403, incluso lanzando la petición en local con la cabecera Host correcta. Ninguna petición llega a FreshRSS. El problema se resuelve reiniciando el contenedor entero, no tocando la configuración.

Reiniciar como procedimiento operativo

Ese es el punto que más le molesta: que el reinicio deje de ser una excepción y se convierta en parte de la rutina. Si la configuración es válida debería funcionar, y si es inválida el proxy debería fallar con un error accionable en lugar de quedarse en un estado roto que solo se arregla levantando el servicio de nuevo. Con eso, dice, no se puede montar un proceso serio de gestión de cambios.

Al modelo de configuración le pone otra pega. La separación entre ajustes globales, ajustes por servicio y overrides no le queda clara, y los globales no siempre se propagan a los servicios que ya existen, así que acaba configurando todo a mano. Los ajustes personalizados desaparecen o se sobrescriben al regenerar la configuración. Con diez o quince servicios, cualquier cambio es una posible regresión. El manejo de certificados TLS, añade, es más frágil de lo que debería ser una función básica de cualquier proxy.

Las funciones de seguridad no le parecen malas ideas: Bad Behavior le resulta útil, CAPJS es razonablemente fácil de desplegar y la integración con CrowdSec la valora. El problema es la administración. Cuando una petición se bloquea, no se sabe si la ha cortado Bad Behavior, ModSecurity, el sistema antibot, CAPJS, una IP baneada, una whitelist, un ajuste global o una recarga fallida. Y quitar un baneo no siempre funciona, algo que en producción no se sostiene.

El núcleo inestable y la versión Pro

El autor también apunta al modelo comercial. Prometheus, las defensas anti-DDoS avanzadas y las herramientas de migración están detrás de la versión Pro, y el proyecto los promociona por correo con cierta insistencia. No discute que exista una edición de pago, pero sí el orden de prioridades: primero un núcleo estable, y después lo demás.

Su lista de lo que falta es corta y sensata: generación de configuración determinista, recargas fiables, rollback, herencia de ajustes clara, ajustes personalizados que persistan y logs que digan qué ha pasado. Mientras eso no llegue, dice que prefiere un Nginx o un HAProxy configurados a mano. Menos dashboard y menos seguridad integrada, pero cuando algo se rompe se puede leer la configuración, reproducir el fallo y arreglarlo. En el texto no aparece ninguna respuesta del equipo del proyecto.