See if below helps.
This is most likely a classic conflict between Docker’s networking engine and YunoHost’s firewall (AFW) on Debian 12.
The root cause is that YunoHost manages the firewall using nftables (and previously iptables), and when it reloads or applies rules, it often flushes the iptables chains. Docker creates its own custom chains (like the DOCKER chain) to handle container routing. When YunoHost flushes these, Docker tries to add rules to a chain that no longer exists, resulting in the error: iptables: No chain/target/match by that name.
Because the networking rules are broken, your evolution_api container cannot “see” the redis container, even though they are in the same compose file. This leads to the redis disconnected flood.
Here is the step-by-step solution to fix both issues.
1. Fix the Configuration (Evolution API)
The Evolution API expects a Connection URI, not separate Host and Port variables. You are using CACHE_REDIS_HOST, which the API likely ignores in favor of CACHE_REDIS_URI.
Update your docker-compose.yml environment section: Remove CACHE_REDIS_HOST and CACHE_REDIS_PORT and replace them with CACHE_REDIS_URI.
# Change this:
- CACHE_REDIS_ENABLED=true
- CACHE_REDIS_HOST=redis
- CACHE_REDIS_PORT=6379
# To this:
- CACHE_REDIS_ENABLED=true
- CACHE_REDIS_URI=redis://redis:6379
(Note: If you are using a password for Redis, the format is redis://:password@redis:6379).
2. Solve the iptables / YunoHost Conflict
To fix the Unable to enable ACCEPT OUTGOING rule error and restore connectivity between containers, you must ensure Docker re-creates its networking chains after YunoHost has initialized the firewall.
The Immediate Fix (Manual)
Run these commands in order to clear the conflict and force Docker to rebuild its rules:
# 1. Reload YunoHost firewall first
yunohost firewall reload
# 2. Restart the Docker daemon to force it to re-inject its chains into iptables
sudo systemctl restart docker
# 3. Bring your stack back up
docker compose up -d
The Permanent Fix (Automation)
Since YunoHost may reload the firewall during updates or via the WebUI, Docker’s rules will break again. To prevent this, you can create a simple systemd override to ensure Docker restarts whenever the firewall changes, or more simply, add a cron job/hook.
However, the most stable way on YunoHost is to ensure Docker is the last thing to start. If you find this happening frequently after reboots, run:
sudo systemctl enable docker
And if you manually reload the firewall, always follow it with sudo systemctl restart docker.
Answers to your specific questions:
1. Is YunoHost’s native Redis or iptables management known to conflict?
Yes. YunoHost’s firewall management is aggressive. It doesn’t “know” about Docker’s custom iptables chains. When YunoHost reloads its rules, it wipes the DOCKER chain. This is why you see the “No chain/target/match” error—Docker is trying to talk to a chain that YunoHost just deleted.
2. How can I ensure the Docker container bypasses YunoHost’s firewall?
Inter-container communication (Evolution API →→ Redis) happens on the Docker Bridge Network via the FORWARD chain. YunoHost’s firewall primarily manages the INPUT chain (traffic coming from the outside world). The containers don’t need to “bypass” the firewall; they just need the Docker-managed rules to exist. Restarting the Docker daemon after the firewall is active is the only way to restore those rules.
3. Are there specific DOCKER-USER chain rules I should inject?
No. The DOCKER-USER chain is for your custom rules (e.g., blocking a specific IP from hitting your API). The error you are seeing is not about a missing security rule, but a missing infrastructure chain. Injecting rules into DOCKER-USER won’t fix the ACCEPT OUTGOING failure because that failure happens in the core Docker setup process.
