Container läuft aber der Dienst antwortet nicht - systematische Diagnose

Container läuft aber der Dienst antwortet nicht - systematische Diagnose

docker ps zeigt „Up" aber die Anwendung antwortet nicht – hier ist die systematische Vorgehensweise um das Problem zu finden.

Schritt 1: Läuft der Container überhaupt?

docker ps
# STATUS zeigt: Up 5 minutes (healthy) oder Up 5 minutes

Status „Restarting" bedeutet: Container crasht in einer Schleife. docker ps -a zeigt auch gestoppte Container.

Schritt 2: Logs auf Startup-Fehler prüfen

docker logs mycontainer
docker logs mycontainer --tail 50

# Bei Compose
docker compose logs app
docker compose logs app --tail 50 -f

Häufige Fehler in den Logs: fehlende Umgebungsvariablen, DB-Verbindung nicht verfügbar, Port bereits belegt, fehlerhafte Config-Datei.

Schritt 3: Antwortet der Dienst intern?

Wenn die Anwendung intern antwortet, aber extern nicht, liegt das Problem am Netzwerk oder der Port-Weiterleitung.

docker exec mycontainer curl -s http://localhost:8080
# oder
docker exec mycontainer wget -qO- http://localhost:8080

Bekommt man eine Antwort → Problem liegt außerhalb des Containers. Keine Antwort → Dienst läuft nicht korrekt.

Schritt 4: Port-Mapping prüfen

docker port mycontainer
# 8080/tcp -> 0.0.0.0:80

# Oder per inspect
docker inspect mycontainer | grep -A 20 PortBindings

In Compose prüfen ob ports: korrekt konfiguriert ist:

ports:
  - "80:8080"  # host:container

Schritt 5: Lauscht der Dienst auf der richtigen Adresse?

Das ist der häufigste Fehler: Die Anwendung bindet sich an 127.0.0.1 (localhost im Container) statt an 0.0.0.0 (alle Interfaces).

docker exec mycontainer ss -tlnp
# oder
docker exec mycontainer netstat -tlnp

Ausgabe:

State   Recv-Q  Send-Q  Local Address:Port
LISTEN  0       128     127.0.0.1:8080      # Nur intern erreichbar!
LISTEN  0       128     0.0.0.0:8080        # Korrekt

Wenn der Dienst auf 127.0.0.1 lauscht, muss man die Anwendungskonfiguration anpassen – oft über eine Umgebungsvariable wie HOST=0.0.0.0 oder BIND_ADDRESS=0.0.0.0.

Schritt 6: Firewall und iptables

Docker manipuliert iptables automatisch. Trotzdem kann eine Host-Firewall (ufw, firewalld) den Traffic blockieren:

# ufw Status
ufw status

# Port temporär öffnen zum Testen
ufw allow 80/tcp

# iptables Regeln prüfen
iptables -L -n | grep 80

Schritt 7: Reverse Proxy prüfen

Wenn nginx oder Traefik vorgeschaltet ist:

# Nginx Konfiguration testen
docker exec nginx nginx -t

# Nginx Logs
docker logs nginx --tail 50

# Direkt auf den App-Container zugreifen (Port für Test öffnen)
docker run --rm --network myapp_network alpine wget -qO- http://app:8080

Schnell-Checkliste

| Problem | Ursache | Lösung |
|---|---|---|
| Container startet nicht | Fehler in Logs | docker logs lesen |
| Intern ok, extern nicht | Port-Mapping fehlt | ports: in Compose prüfen |
| Port-Mapping ok, trotzdem nein | Bind-Adresse | App auf 0.0.0.0 binden |
| Alles korrekt, trotzdem nein | Firewall | ufw/iptables prüfen |
| Gelegentliche Fehler | Healthcheck schlägt fehl | Restart-Policy und Healthcheck prüfen |