Veja se isso abaixo ajuda.
Este é muito provavelmente um conflito clássico entre o mecanismo de rede do Docker e o firewall do YunoHost (AFW) no Debian 12.
A causa raiz é que o YunoHost gerencia o firewall usando nftables (e anteriormente iptables), e quando recarrega ou aplica regras, frequentemente limpa as cadeias do iptables. O Docker cria suas próprias cadeias customizadas (como a cadeia DOCKER) para lidar com o roteamento de contêineres. Quando o YunoHost limpa essas cadeias, o Docker tenta adicionar regras a uma cadeia que não existe mais, resultando no erro: iptables: No chain/target/match by that name.
Porque as regras de rede estão quebradas, seu contêiner evolution_api não consegue “ver” o contêiner redis, mesmo que estejam no mesmo arquivo compose. Isso leva ao flood de redis disconnected.
Aqui está a solução passo a passo para corrigir ambos os problemas.
1. Corrija a Configuração (Evolution API)
A Evolution API espera uma URI de Conexão, não variáveis separadas de Host e Porta. Você está usando CACHE_REDIS_HOST, que a API provavelmente ignora em favor de CACHE_REDIS_URI.
Atualize sua seção de ambiente do docker-compose.yml: Remova CACHE_REDIS_HOST e CACHE_REDIS_PORT e substitua-os por CACHE_REDIS_URI.
# Mude isto:
- CACHE_REDIS_ENABLED=true
- CACHE_REDIS_HOST=redis
- CACHE_REDIS_PORT=6379
# Para isto:
- CACHE_REDIS_ENABLED=true
- CACHE_REDIS_URI=redis://redis:6379
(Nota: Se você estiver usando uma senha para o Redis, o formato é redis://:senha@redis:6379).
2. Resolva o Conflito de iptables / YunoHost
Para corrigir o erro Unable to enable ACCEPT OUTGOING rule e restaurar a conectividade entre contêineres, você deve garantir que o Docker recrie suas cadeias de rede depois que o YunoHost inicializar o firewall.
A Correção Imediata (Manual)
Execute esses comandos em ordem para limpar o conflito e forçar o Docker a reconstruir suas regras:
# 1. Recarregue o firewall do YunoHost primeiro
yunohost firewall reload
# 2. Reinicie o daemon do Docker para forçá-lo a reinjetar suas cadeias no iptables
sudo systemctl restart docker
# 3. Traga sua stack de volta
docker compose up -d
A Correção Permanente (Automação)
Como o YunoHost pode recarregar o firewall durante atualizações ou via WebUI, as regras do Docker quebrarão novamente. Para evitar isso, você pode criar uma simples substituição do systemd para garantir que o Docker reinicie sempre que o firewall mudar, ou mais simplesmente, adicionar um cron job/hook.
Porém, a forma mais estável no YunoHost é garantir que o Docker seja a última coisa a iniciar. Se você achar que isso está acontecendo frequentemente após reinicializações, execute:
sudo systemctl enable docker
E se você recarregar manualmente o firewall, sempre siga-o com sudo systemctl restart docker.
Respostas às suas questões específicas:
1. O Redis nativo do YunoHost ou o gerenciamento de iptables são conhecidos por entrar em conflito?
Sim. O gerenciamento de firewall do YunoHost é agressivo. Ele não “conhece” as cadeias customizadas do iptables do Docker. Quando o YunoHost recarrega suas regras, ele apaga a cadeia DOCKER. É por isso que você vê o erro “No chain/target/match”—o Docker está tentando se comunicar com uma cadeia que o YunoHost acabou de deletar.
2. Como posso garantir que o contêiner do Docker contorne o firewall do YunoHost?
A comunicação entre contêineres (Evolution API →→ Redis) acontece na Rede Bridge do Docker via a cadeia FORWARD. O firewall do YunoHost gerencia principalmente a cadeia INPUT (tráfego vindo do mundo exterior). Os contêineres não precisam “contornar” o firewall; eles apenas precisam que as regras gerenciadas pelo Docker existam. Reiniciar o daemon do Docker depois que o firewall está ativo é a única forma de restaurar essas regras.
3. Existem regras específicas da cadeia DOCKER-USER que devo injetar?
Não. A cadeia DOCKER-USER é para suas próprias regras customizadas (por exemplo, bloquear um IP específico de atingir sua API). O erro que você está vendo não é sobre uma regra de segurança faltando, mas uma cadeia de infraestrutura faltando. Injetar regras em DOCKER-USER não vai corrigir a falha de ACCEPT OUTGOING porque essa falha acontece no processo de configuração central do Docker.
