Gateway-Pools: Fehlerbehebung

Troubleshooting

Failover hat nicht stattgefunden

# 1. Ist Peer wirklich als down erkannt?
sqlite3 /data/gatecontrol.db "SELECT peer_id, alive, datetime(last_seen_at/1000,'unixepoch') FROM gateway_meta;"

# 2. Wenn alive=1 aber Peer offensichtlich offline:
#    Watchdog läuft alle 30s. Threshold ist default 90s.
#    90+30 = max ~120s warten.

# 3. Routes-Tabelle prüfen — sollten Routen pivotet sein?
sqlite3 /data/gatecontrol.db "SELECT id, domain, target_peer_id, original_peer_id FROM routes WHERE target_kind='gateway' AND enabled=1;"

# 4. Activity-Log
sqlite3 /data/gatecontrol.db "SELECT datetime(created_at/1000,'unixepoch'), event_type, message FROM activity_log WHERE event_type LIKE '%failover%' ORDER BY created_at DESC LIMIT 10;"

Routen sind pivotet aber 502/504 vom Frontend

Mögliche Ursachen:

Caddy-Reload schlug fehl — docker logs gatecontrol | grep -i caddy.*error
WG-Tunnel zum Failover-Member down — docker exec gatecontrol wg show und Handshake-Alter prüfen

Failover-Companion kennt die Route nicht — Hash-Mismatch:

# Server-erwarteter Hash für Peer 84:
docker exec gatecontrol node -e "console.log(require('/app/src/services/gateways').computeConfigHash(84))"
# Companion-reportierter Hash:
sqlite3 /data/gatecontrol.db "SELECT last_config_hash FROM gateway_meta WHERE peer_id=84;"
# Manuell triggern wenn Mismatch:
docker exec gatecontrol node -e "require('/app/src/services/gateways').notifyConfigChanged(84)"

Backend-Host vom Failover-Member nicht erreichbar — von DS918 aus: curl -v http://192.168.1.5:5001

LB-Pool aber alle Requests gehen an einen Member

mode = 'load_balancing'? (nicht failover)
lb_policy gesetzt? (nicht NULL)
Sind beide Member in gateway_meta.alive=1?
Bei ip_hash mit CDN davor: trusted_proxies greift nur wenn die CDN-IP in den konfigurierten Ranges liegt. CDN außerhalb RFC1918? Eigene Ranges via Code-Patch in src/services/caddyConfig.js ergänzen.
Caddy-Live-Config: docker exec gatecontrol curl -s http://127.0.0.1:2019/config/apps/http/servers/srv0/routes — prüfen ob upstreams mehrere Einträge hat.

Pool kann nicht gespeichert werden — "members_array_required" / "duplicate_peer"

Frontend-Bug oder Race. Browser-Cache leeren (Ctrl+Shift+R). DevTools-Network: PUT-Request-Body inspizieren — sollte [{peer_id: <int>, priority: <int>}, …] sein. Doppelte peer_ids passieren nicht im normalen UI-Flow (Dropdown filtert raus).

Modal zeigt "Noch keine Mitglieder" obwohl DB welche hat