Mira si esto te ayuda.
Esto es muy probablemente un conflicto clásico entre el motor de networking de Docker y el firewall de YunoHost (AFW) en Debian 12.
La causa raíz es que YunoHost gestiona el firewall usando nftables (y anteriormente iptables), y cuando recarga o aplica reglas, a menudo vacía las cadenas de iptables. Docker crea sus propias cadenas personalizadas (como la cadena DOCKER) para manejar el enrutamiento de contenedores. Cuando YunoHost las vacía, Docker intenta agregar reglas a una cadena que ya no existe, resultando en el error: iptables: No chain/target/match by that name.
Como las reglas de networking están rotas, tu contenedor evolution_api no puede “ver” el contenedor redis, aunque estén en el mismo archivo compose. Esto lleva a la inundación de redis disconnected.
Aquí te presento la solución paso a paso para solucionar ambos problemas.
1. Corregir la Configuración (Evolution API)
La API de Evolution espera una URI de Conexión, no variables separadas de Host y Puerto. Estás usando CACHE_REDIS_HOST, que la API probablemente ignora en favor de CACHE_REDIS_URI.
Actualiza tu sección de entorno en docker-compose.yml: Elimina CACHE_REDIS_HOST y CACHE_REDIS_PORT y reemplázalos con CACHE_REDIS_URI.
# Cambia esto:
- CACHE_REDIS_ENABLED=true
- CACHE_REDIS_HOST=redis
- CACHE_REDIS_PORT=6379
# A esto:
- CACHE_REDIS_ENABLED=true
- CACHE_REDIS_URI=redis://redis:6379
(Nota: Si estás usando una contraseña para Redis, el formato es redis://:contraseña@redis:6379).
2. Resolver el Conflicto entre iptables y YunoHost
Para corregir el error Unable to enable ACCEPT OUTGOING rule y restaurar la conectividad entre contenedores, debes asegurar que Docker recree sus cadenas de networking después de que YunoHost haya inicializado el firewall.
La Solución Inmediata (Manual)
Ejecutar estos comandos en orden para limpiar el conflicto y forzar que Docker reconstruya sus reglas:
# 1. Recarga el firewall de YunoHost primero
yunohost firewall reload
# 2. Reinicia el demonio de Docker para forzar que reinecte sus cadenas en iptables
sudo systemctl restart docker
# 3. Levanta tu stack nuevamente
docker compose up -d
La Solución Permanente (Automatización)
Como YunoHost puede recargar el firewall durante actualizaciones o a través de la WebUI, las reglas de Docker se romperán nuevamente. Para prevenir esto, puedes crear un override de systemd simple para asegurar que Docker se reinicie cada vez que el firewall cambie, o más simplemente, agregar un trabajo cron/hook.
Sin embargo, la forma más estable en YunoHost es asegurar que Docker sea lo último que se inicie. Si encuentras que esto sucede frecuentemente después de reinicios, ejecuta:
sudo systemctl enable docker
Y si recargas manualmente el firewall, siempre seguido por sudo systemctl restart docker.
Respuestas a tus preguntas específicas:
1. ¿Se sabe que la gestión nativa de Redis o iptables de YunoHost entra en conflicto?
Sí. La gestión del firewall de YunoHost es agresiva. No “conoce” las cadenas de iptables personalizadas de Docker. Cuando YunoHost recarga sus reglas, borra la cadena DOCKER. Por eso ves el error “No chain/target/match”—Docker está intentando comunicarse con una cadena que YunoHost acaba de eliminar.
2. ¿Cómo puedo asegurar que el contenedor de Docker omita el firewall de YunoHost?
La comunicación entre contenedores (Evolution API →→ Redis) ocurre en la Red Bridge de Docker a través de la cadena FORWARD. El firewall de YunoHost gestiona principalmente la cadena INPUT (tráfico que viene del mundo exterior). Los contenedores no necesitan “omitir” el firewall; simplemente necesitan que existan las reglas gestionadas por Docker. Reiniciar el demonio de Docker después de que el firewall esté activo es la única manera de restaurar esas reglas.
3. ¿Hay reglas específicas de la cadena DOCKER-USER que deba inyectar?
No. La cadena DOCKER-USER es para tus reglas personalizadas (por ejemplo, bloquear una IP específica de acceder a tu API). El error que estás viendo no es sobre una regla de seguridad faltante, sino sobre una cadena de infraestructura faltante. Inyectar reglas en DOCKER-USER no solucionará el fallo ACCEPT OUTGOING porque ese fallo ocurre en el proceso de configuración principal de Docker.
