Website Down, aber der Server ist erreichbar? Fehler von DNS bis zur App nachverfolgen?

„SSH funktioniert, die Website nicht” — Beginnen Sie mit der richtigen Frage

Die Warnungen beginnen zu blinken, Benutzer sagen, dass die Website tot ist, und Ihr erster Test gibt Ihnen eine seltsame Art von Erleichterung: SSH lässt Sie immer noch rein. Dieser Moment fühlt sich beruhigend an, weil der Server nicht weg ist. Aber hier beginnt auch viel schlechte Fehlerbehebung, denn „Ich kann mich immer noch anmelden” ist nicht dasselbe wie „die Website sollte funktionieren.”

Die nützliche Frage ist nicht „was kann ich zuerst neu starten?” Sie lautet „welche Schicht ist zuerst ausgefallen?” Eine funktionierende SSH-Sitzung beweist, dass die Maschine auf Port 22 erreichbar ist. Sie beweist nicht, dass die Domain korrekt aufgelöst wird. Sie beweist nicht:

• dass die Ports 80 und 443 erreichbar sind
• dass HTTPS fehlerfrei ist
• dass die Anwendung hinter dem Webserver antwortet

Diese Anleitung basiert auf dieser Unterscheidung und konzentriert sich auf die Diagnose, anstatt zu versuchen, ein vollständiges nginx-, DNS-, TLS-, Docker- oder Datenbankhandbuch zu werden.

⚠️ Warnung: Das blinde Neustarten von nginx, Docker, PHP-FPM oder des gesamten VPS in den ersten Minuten eines Vorfalls kann die Hinweise löschen, die Sie benötigen. Sammeln Sie zunächst eine Runde Beweise, ändern Sie dann nur die Schicht, die tatsächlich ausgefallen ist.

Die Ein-Minuten-Triage-Karte

Bevor du tiefer gehst, orientiere dich. Die Form des Fehlers sagt dir oft, welche Schicht zuerst Aufmerksamkeit verdient, auch wenn du die Grundursache noch nicht kennst.

Behandle die folgende Tabelle als Triage-Abkürzung, nicht als endgültiges Urteil.

Wichtig ist die erste fehlerhafte Stufe. Wenn DNS fehlschlägt, sind spätere Schichten Rauschen. Wenn 443 antwortet, aber TLS bricht zusammen, ist die App noch nicht deine erste Frage. Das mentale Modell unten ist das, was diese Abfolge logisch statt zufällig wirken lässt.

Warum SSH nicht beweist, dass die Website funktioniert

SSH und Web-Traffic sind unterschiedliche Pfade mit unterschiedlichen Aufgaben. SSH auf Port 22 beweist, dass Sie die Maschine durch ihre Remote-Management-Tür erreichen können. Eine Website hängt von den Ports 80 und 443 sowie den Schichten dahinter ab. Das sind separate Tests, daher sind “Server erreichbar” und “Website erreichbar” keine austauschbaren Aussagen.

Die einfachste Vorstellung ist ein Bürogebäude. DNS hilft einem Besucher, die Gebäudeadresse zu finden. Die Ports 80 und 443 sind der Empfang für öffentliche Besucher. Der Web-Server ist der Rezeptionist, der die Anfrage akzeptiert und entscheidet, wohin sie als nächstes geht. Die Anwendung ist das Büro, das die eigentliche Arbeit verrichtet. Eine Datenbank oder eine andere Abhängigkeit kann sich weiter im Gebäude befinden. SSH ist ein völlig anderer Eingang. Er ist für Personal nützlich, beweist aber nicht, dass der Empfang offen ist oder dass die Büroübergabe funktioniert.

Browser
  ↓
DNS lookup
  ↓
IP address
  ↓
Port 80 / 443
  ↓
Web server
  ↓
App / upstream
  ↓
Database / dependency

Wenn Menschen sagen, dass ein Service “abhört”, meinen sie, dass er tatsächlich Verbindungen auf dem erwarteten Endpunkt akzeptiert. Das ist die Unterscheidung, die einen vagen “der Server läuft”-Moment in einen nachverfolgbaren Request-Pfad umwandelt.

Das ist wichtig, weil HTTPS fehlschlagen kann, bevor die App antwortet, und Proxy- oder Anwendungsfehler können auftreten, nachdem das Frontend bereits erreichbar ist. Der nächste Schritt ist also immer derselbe: von außen schauen und die letzte erfolgreiche Phase der Anfrage finden.

Schritt 1: Fehler von außerhalb des Servers reproduzieren

Beginnen Sie von der Clientseite, nicht von innerhalb des VPS. Testen Sie wenn möglich zunächst von einem anderen Netzwerk oder Gerät, um einen lokalen DNS-Cache, einen alten /etc/hosts-Eintrag oder ein lokales Firewall-/VPN-Problem nicht mit einem echten Serverausfall zu verwechseln.

Verwenden Sie eine ausführliche externe Anfrage, damit Sie sehen können, wie weit die Anfrage kommt, bevor sie fehlschlägt:

curl -v --connect-timeout 5 --max-time 15 https://example.com/

curl -v ist hier kein Werkzeug nur für Experten. Lesen Sie es als Fortschrittsablauf. Wenn es den Namen nie auflöst, befinden Sie sich im DNS-Zweig. Wenn es sich verbindet und dann Connection refused sagt, hat der Host geantwortet, aber nichts Nützliches akzeptiert dort Traffic. Wenn es bis zum Timeout hängt, denken Sie an Filterung, Routing oder ein tieferes Hängen später im Anfragepfad. Wenn Sie eine HTTP-Antwort erhalten, auch eine Fehlerseite, haben Sie bereits die Verbindungsschicht überschritten und sind in einen höheren Zweig übergegangen.

💡 Tipp: Vergleichen Sie IPv4 und IPv6 frühzeitig. Ein vergessener AAAA-Datensatz kann den Ausfall inkonsistent aussehen lassen, da einige Clients IPv6 zuerst bevorzugen und andere nicht.

Führen Sie denselben Test einmal pro Protokollfamilie durch, wenn Dual Stack im Spiel ist:

curl -4 -v --connect-timeout 5 --max-time 15 https://example.com/
curl -6 -v --connect-timeout 5 --max-time 15 https://example.com/

Wenn IPv4 funktioniert und IPv6 fehlschlägt, oder umgekehrt, haben Sie den Vorfall bereits schneller eingegrenzt, als ein Neustart des Dienstes es je könnte. Wenn der Fehler bei der Namensauflösung oder Zielwahl beginnt, ist DNS der nächste saubere Zweig zum Überprüfen.

Schritt 2: DNS überprüfen und das richtige Ziel bestätigen

Bevor Sie nginx debuggen, bestätigen Sie, dass die Domain Besucher tatsächlich zu dem Server sendet, von dem Sie denken, dass er es ist. Das ist besonders wichtig nach Migrationen, IP-Änderungen, CDN-Anpassungen oder teilweisen Record-Bearbeitungen.

Überprüfen Sie zunächst die öffentlichen Records:

dig +short A example.com
dig +short AAAA example.com

Diese zwei Zeilen beantworten eine sehr praktische Frage: Wo glaubt das Internet, dass example.com sich gerade befindet? Eine häufige Fehlerform ist, dass SSH über IP den neuen VPS erreicht, aber die Domain immer noch auf die alte Adresse zeigt. Eine andere ist, dass der A Record aktualisiert wurde, aber der AAAA Record immer noch auf etwas Veraltetes zeigt. In diesem Fall schlägt nur ein Teil Ihres Traffics fehl.

📝 Hinweis: curl --resolve ist sicherer als das Ändern von öffentlichem DNS während eines Incidents. Es ermöglicht Ihnen, den Origin zu testen, den Sie verwenden möchten, während der Hostname und SNI intakt bleiben.

Verwenden Sie curl --resolve, um einen Test gegen die IP zu erzwingen, die Sie erwarten, ohne öffentliche Records zu ändern:

curl --resolve example.com:443:203.0.113.10 https://example.com/

Wenn das funktioniert, während die öffentliche Domain immer noch fehlschlägt, kann der Server in Ordnung sein und DNS kann immer noch die fehlerhafte Schicht sein. Eine begrenzte CDN-Notiz ist hier erwähnenswert. Wenn Ihr Origin so gesperrt ist, dass er nur Traffic von CDN IP-Bereichen akzeptiert, kann ein Direct-Origin-Test einfach fehlschlagen, weil der Origin Edge-Traffic erwartet, nicht beliebige öffentliche Anfragen. Sobald das Ziel bestätigt ist, ist die nächste Frage, ob etwas Nützliches auf 80 oder 443 dort antwortet.

Schritt 3: Überprüfen Sie, was auf 80/443 abhört

Wechseln Sie nun zum Server und stellen Sie eine präzise Frage: Akzeptiert tatsächlich etwas Web-Verbindungen auf den erwarteten Ports? Der Computer kann aktiv sein, SSH kann funktionieren und nginx kann sogar installiert sein. Dennoch können die öffentlichen Web-Ports immer noch keinen nützlichen Listener haben.

Überprüfen Sie zunächst die Listener:

sudo ss -ltnp

Leere Ausgabe für :80 oder :443 bedeutet, dass nichts Nützliches dort abhört. Ein Listener auf 127.0.0.1 bedeutet, dass der Service nur Verbindungen vom lokalen Computer akzeptiert. Ein Listener auf 0.0.0.0 bedeutet, dass er auf IPv4-Schnittstellen gebunden ist. [::] bedeutet normalerweise IPv6-Schnittstellen. Gehen Sie nicht davon aus, dass IPv6-Bindung automatisch den IPv4-Pfad garantiert, den Sie benötigen.

Verwenden Sie dann ein kleines nginx-Health-Bundle, bevor Sie etwas ändern:

sudo systemctl status nginx --no-pager -l
sudo nginx -t
sudo journalctl -u nginx --since '-30 minutes' --no-pager

• Wenn systemctl active (running) anzeigt, beweist das nur, dass der Service-Prozess existiert
• nginx -t teilt Ihnen mit, ob die Konfiguration gültig ist
• journalctl zeigt, ob ein kürzliches Reload fehlgeschlagen ist, eine Zertifikatsdatei fehlte oder ein vhost beim Start unterbrochen ist.

Für Apache-Leser ist die entsprechende Syntax-Überprüfung apachectl configtest. Sobald Sie wissen, dass etwas abhört, ist der nächste Beweis spezifischer: antwortet die richtige Website lokal, wenn Sie das externe Netzwerk aus der Gleichung entfernen?

💡 Tipp: Testen Sie zuerst die Konfiguration, dann bevorzugen Sie reload gegenüber einem blinden Neustart, wenn angemessen. Ein Reload validiert die neue Konfiguration und behält die alten Worker bei, wenn die neue Konfiguration fehlerhaft ist; ein blinder Neustart ist während eines Vorfalls viel rauer.

Schritt 4: Die Website lokal mit dem richtigen Host und SNI testen

Dies ist die wichtigste Verzweigung in der gesamten Untersuchung. Ein einfaches curl 127.0.0.1 kann irreführend sein. Viele Server hosten mehrere Websites und wählen die Antwort basierend auf dem Host-Header oder bei HTTPS auf SNI. Sie fragen nicht, ob etwas lokal antwortet. Sie fragen, ob der richtige Website-Pfad lokal antwortet.

Verwenden Sie lokale Tests, die die Hostname-Logik bewahren:

curl -I http://127.0.0.1/ -H 'Host: example.com'
curl -v --resolve example.com:443:127.0.0.1 https://example.com/

# Only as a one-off diagnostic if you already know the cert is bad:
curl -vk --resolve example.com:443:127.0.0.1 https://example.com/

Ein aussagekräftiger Erfolg ist die erwartete Seite, die erwartete Umleitung oder die erwartete Anwendungsantwort von der richtigen Website. Es ist nicht der Standard-nginx-Host, das falsche Zertifikat oder ein generisches „es hat HTML zurückgegeben”. Von hier aus gibt es drei saubere Ergebnisse: lokaler Erfolg, falsches Verhalten bei lokaler Website oder Standard-Zertifikat oder lokaler Fehler/Timeout. Ein gutes lokales Ergebnis weist auf Firewall-, Provider-, CDN- oder Routing-Prüfungen hin. Ein schlechtes lokales Ergebnis hält Sie im Stack, in den Upstream- oder TLS-Zweigen.

Schritt 5: Wenn es lokal funktioniert, aber nicht extern, verfolgen Sie den Netzwerkpfad

Sobald der lokale Test gut läuft, hören Sie für einen Moment auf, nginx in Frage zu stellen. Der Site-Stack ist wahrscheinlich auf dem Server aktiv, und das fehlende Stück liegt normalerweise irgendwo zwischen dem Besucher und diesem funktionierenden lokalen Service. Beginnen Sie mit der Host-Firewall, da sie die nächste externe Grenze ist, die Sie kontrollieren.

Überprüfen Sie die Host-seitigen Regeln mit dem Tool, das Ihr System tatsächlich verwendet, und führen Sie eine schnelle Plausibilitätsprüfung durch, um selbst verursachte Blockierungen zu erkennen:

sudo nft list ruleset

# Or, on systems still using iptables directly:
sudo iptables-save
sudo ip6tables-save

# Fast sanity check for self-inflicted blocking:
sudo fail2ban-client status

Diese Ausgabe zeigt nur die Gast-OS-Schicht. Sie zeigt nicht Provider-seitige Filterung, Sicherheitsgruppen oder Panel-seitige Firewall-Regeln, die außerhalb der VPS selbst liegen. Auf einer AlexHost VPS zum Beispiel sind die Machine-Firewall und alle Panel-Level-Netzwerksteuerungen separate Fragen. Beide sind wichtig, wenn lokale Tests funktionieren, aber öffentliche Besucher immer noch fehlschlagen.

⚠️ Warnung: Wenn Docker Ports auf dem Host veröffentlicht, gehen Sie nicht davon aus, dass die UFW-Ausgabe die ganze Geschichte erzählt. Docker kann veröffentlichten Container-Traffic durch NAT leiten, bevor UFW seine üblichen Chains durchläuft. Das bedeutet, dass „UFW sieht gut aus” nicht immer bedeutet, dass der Paketpfad in Ordnung ist.

CDNs und Load Balancer verdienen hier auch ihren eigenen Zweig. Der Origin kann gesund sein und ist trotzdem nicht erreichbar, weil nur Edge-IP-Bereiche mit ihm kommunizieren dürfen. Wenn Sie einen Beweis dafür brauchen, ob Pakete überhaupt ankommen, verwenden Sie tcpdump als Ja-oder-Nein-Tool:

📝 Hinweis: Ein fehlgeschlagener Direct-Origin-Test hinter einer CDN-Allowlist deutet normalerweise auf die Edge-Richtlinie hin, nicht auf einen toten Origin. In diesem Setup ist der Origin so konzipiert, dass er dem CDN-Pfad vertraut, nicht jedem direkten Besucher.

sudo tcpdump -ni any 'tcp port 80 or tcp port 443'

Wenn Sie überhaupt keine SYN-Pakete sehen, erreicht der Traffic den Server nicht. Wenn SYNs ankommen und kein SYN-ACK geht, blockiert der Server oder der Firewall-Pfad immer noch die Übergabe. Wenn keines dieser Muster der Blocker zu sein scheint, sitzen die verbleibenden Fehler normalerweise hinter dem Frontend in der Upstream-Übergabe.

Schritt 6: Wenn das Frontend antwortet, aber die Website immer noch fehlerhaft ist, folgen Sie dem Upstream

In diesem Zweig ist der Webserver erreichbar, aber der nächste Hop dahinter ist nicht gesund genug, um die Anfrage abzuschließen. Hier bedeutet “Upstream” den Service, an den nginx die Anfrage als nächstes weiterleitet: einen App-Prozess, eine Socket-gestützte Runtime, einen Container oder eine andere interne Abhängigkeit.

Statische Seiten funktionieren, während Login, Suche, Checkout oder API-Routen fehlschlagen, ist ein starker Hinweis darauf, dass das Frontend vorhanden ist und der Fehler beim Handoff dahinter beginnt.

📝 Hinweis: Behandeln Sie 502 als “der nächste Hop hat schlecht geantwortet” und 504 als “der nächste Hop hat zu langsam geantwortet.” Beide sind Zeichen, dem Upstream-Pfad zu folgen, anstatt beim Frontend zu stoppen.

Überprüfen Sie den aktiven Handoff und testen Sie dann den Upstream direkt:

sudo nginx -T

# Direct HTTP upstream example
curl -i http://127.0.0.1:3000/

# Unix-socket-backed HTTP example
curl --unix-socket /run/app.sock http://localhost/

Suchen Sie in der nginx-Ausgabe nach Direktiven wie proxy_pass, fastcgi_pass oder uwsgi_pass. Sie überprüfen, ob nginx auf das richtige Ziel zeigt, über das richtige Protokoll, auf dem richtigen Port oder Socket. Wenn Container beteiligt sind, fügen Sie stattdessen einen kurzen Container-Health-Check hinzu, anstatt zu raten:

docker ps
docker logs --tail 50 <container_name>
docker inspect --format '{{json .State.Health}}' <container_name>
docker port <container_name>

Wenn der direkte App-Test fehlschlägt, liegt das Problem hinter dem Webserver. Wenn es direkt funktioniert, aber durch nginx fehlschlägt, ist die Handoff-Konfiguration der zu überprüfende Zweig. Datenbankverbindbarkeit ist hier nur als Abhängigkeitsprüfung relevant, nicht als separate tiefe Analyse. Wenn sich dieses Upstream-Fehlermuster immer wieder wiederholt, ist das der richtige Moment, um zu einem dedizierten Troubleshooting-Leitfaden zu wechseln, anstatt einen Vorfall in Vermutungen zu dehnen.

Schritt 7: TLS- und Zertifikatsfehler isolieren

Dieser Zweig ist enger: Etwas antwortet auf 443, aber der Browser kann immer noch keine saubere, vertrauenswürdige HTTPS-Sitzung abschließen. Eine erfolgreiche TCP-Verbindung zu Port 443 beweist nicht, dass das Zertifikat, die Hostname-Übereinstimmung oder der Handshake-Pfad fehlerfrei ist.

Überprüfen Sie, welches Zertifikat tatsächlich bereitgestellt wird:

openssl s_client -connect example.com:443 -servername example.com -verify_hostname example.com -brief

Hier fangen Sie die häufigen Fehlermuster: der falsche Hostname, ein abgelaufenes Zertifikat, eine unvollständige Kette oder eine Erneuerung, die nie sauber abgeschlossen wurde. In einfachen Worten: SNI teilt dem Server mit, welchen Hostname Sie gemeint haben. -verify_hostname prüft, ob das bereitgestellte Zertifikat diesem Hostname entspricht. Validieren Sie nach der Wiederherstellung den Erneuerungspfad, damit dies nicht zum nächsten Ausfall wird:

⚠️ Warnung: Wenn Sie sich auf HTTP-01-Validierung für die Zertifikatserneuerung verlassen, muss der eingehende Port 80 erreichbar sein. Eine Firewall- oder Provider-Regel, die 80 blockiert, kann Erneuerungen lange vor Benutzerberichten, dass HTTPS tot aussieht, stillschweigend unterbrechen.

sudo certbot renew --dry-run

Schritt 8: Ressourcenauslastung überprüfen, bevor Sie es als Zufall abtun

Einige Vorfälle sind überhaupt keine Erreichbarkeitsfehler. Der Pfad ist technisch intakt, aber der Server ist zu ausgehungert, blockiert oder überlastet, um rechtzeitig zu antworten. Das ist der Fall, wenn eine Website aus einem Blickwinkel “teilweise am Leben” aussehen kann und sich für Benutzer dennoch tot anfühlt.

Führen Sie ein kleines Ressourcen-Bundle für den ersten Durchgang aus:

df -h
df -i
free -h
uptime
vmstat 1 5
sudo journalctl -k -g 'oom|out of memory|killed process'

Lesen Sie die Ergebnisse in Mustern, nicht isoliert.

• df -h zeigt gewöhnliche Festplattenerschöpfung.
• df -i erfasst Inode-Erschöpfung, bei der Speicherplatz vorhanden zu sein scheint, das Dateisystem aber keine weiteren Einträge erstellen kann.
• free -h ist am wichtigsten, wenn der verfügbare Speicher zusammenbricht und die Swap-Aktivität steigt.
• uptime kann hohe Last anzeigen, selbst wenn die CPU nicht ausgelastet ist, was oft bedeutet, dass Tasks auf Datenträger- oder Speicherdruck warten, anstatt aktiv zu rechnen.
• Kernel-Log-Zeilen über OOM-Ereignisse zeigen Ihnen, ob das System begonnen hat, Prozesse zu beenden, um zu überleben.

Provider-Graphen können die Zeitleiste bestätigen. Auf einem AlexHost VPS können sie nützlich sein, um zu überprüfen, ob Spitzen bei RAM, Datenträger oder I/O mit dem Ausfall übereinstimmen. Aber die Terminal-Evidenz sollte die Diagnose immer noch anführen. Dieser Abschnitt ist kein Tuning-Leitfaden; er ist der Zweig, der Ihnen sagt, dass die Website möglicherweise unter Druck ausfällt, anstatt zu scheitern, zu routen.

In Schichten denken, nicht in Panik

Wenn SSH funktioniert, aber die Website nicht öffnet, halten Sie die Kette kurz und wiederholbar:

1. Fehler extern reproduzieren
2. letzte erfolgreiche Phase identifizieren
3. DNS und Ziel bestätigen
4. echten Listener auf 80/443 überprüfen
5. korrekte Website lokal testen
6. in Netzwerkpfad, Upstream, TLS oder Ressourcen aufteilen

💡 Tipp: Schließen Sie Ihre letzte funktionierende SSH-Sitzung nicht, bis Sie bestätigt haben, dass ein frischer Login noch funktioniert und Sie noch einen Backup-Zugriffspfad haben, z. B. Konsole des Providers. Bei einem Live-Incident ist die Beibehaltung der Kontrolle genauso wichtig wie die Behebung des ersten Symptoms.

Halten Sie Gewohnheiten leicht: extern überwachen, Logs führen und Zertifikate mit certbot renew –dry-run testen. Sichern Sie den Zugriff mit Backups und einem Konsolenpfad. Provider-Tools — Firewall, Grafiken, Konsole (einschließlich AlexHost) — sollten die Fehlerbehebung unterstützen, nicht ersetzen. Konzentrieren Sie sich darauf, die erste fehlerhafte Schicht zu beheben, damit jeder Incident mit klareren Beweisen und weniger Panik bewältigt wird.