Multi-Homed VPS Routing (private-network default route)

Some VPS providers — most notably OVH and Hetzner Cloud with a private network enabled — give your server two network interfaces: a public one and a private one. On these boxes the private interface's DHCP server often hands out a default route at the same priority (metric) as the public one. That single misconfiguration silently breaks Docker container networking — and the panel with it.

Symptoms

The panel is unreachable in a browser on https://your-domain — the connection just times out (no error page, no certificate warning).
ssh to the box still works fine, and curl from the box works fine.
Containers can't reach the internet: Let's Encrypt fails, AI APIs are unreachable.
Nothing in the logs explains it.

That combination — host networking fine, container networking dead — is the tell.

Why it happens

Your box has two default routes at the same metric:

default via 51.77.17.1  dev ens3 ... metric 100   # public
default via 10.1.0.1    dev ens4 ... metric 100   # private (10.x / 192.168.x / 172.16-31.x)

Traffic the host sends picks the public interface (its public source IP lives there), so SSH and curl work. But when a Docker container replies to a visitor, that reply has the container's private source address, and Linux resolves it onto the private default route — sending the answer out the private NIC, where it goes nowhere. The visitor's request arrives, the panel answers, and the answer drives into a wall.

This is not a firewall problem. Your provider's firewall can be perfectly configured to allow 80/443 and you'll still see this. The fix is on the host's routing table, not the firewall.

The fix

Make the public interface the strict winner by giving the private interface's default route a worse (higher) metric. On Ubuntu/Debian (netplan):

sudo tee /etc/netplan/99-aap-route-fix.yaml >/dev/null <<'YAML'
network:
  version: 2
  ethernets:
    ens4:                       # <-- your PRIVATE interface (NOT the public one)
      dhcp4-overrides:
        route-metric: 4000
YAML
sudo chmod 600 /etc/netplan/99-aap-route-fix.yaml
sudo netplan apply

Replace ens4 with whichever interface carries the private (10.x / 192.168.x / 172.16–31.x) address. Afterwards:

default via 51.77.17.1 dev ens3 ... metric 100    # public — wins
default via 10.1.0.1   dev ens4 ... metric 4000   # private — fallback only

The panel becomes reachable immediately and containers regain internet egress. To revert, delete the file and run sudo netplan apply again.

Let the installer handle it

The installer detects this hazard during its pre-flight checks and prints a warning naming the offending interface. To have it fix the routing automatically (netplan hosts only), run the installer with AAP_FIX_ROUTING=1:

AAP_FIX_ROUTING=1 PANEL_DOMAIN="panel.example.com" ACME_EMAIL="[email protected]" \
  bash install.sh

It writes the same reversible /etc/netplan/99-aap-route-fix.yaml drop-in shown above — it only ever deprioritizes the private interface and never touches your public default route. On non-netplan systems (RHEL/Fedora/NetworkManager) it warns and prints the manual steps instead.