Anmelden

Webserver Grundlagen

Lektion 5 von 6

Webserver-Fehleranalyse

Grenze typische Fehler eines Webdienstes systematisch ein.

Lernziele

Nach Abschluss dieser Lektion kannst du:

  • DNS-, IP-, Port-, TLS-, HTTP- und Anwendungsfehler trennen
  • eine belegbasierte Diagnosereihenfolge anwenden
  • Connection refused und Timeout konzeptionell unterscheiden
  • TLS-Zertifikatsfehler einordnen
  • 4xx-, 5xx- und Upstream-Statuscodes interpretieren
  • Browserwerkzeuge, nslookup und curl passend einsetzen
  • Beobachtungen vor Änderungen dokumentieren

Vom Namen bis zur Anwendung

Entscheidungsfluss mit Bedeutung

  1. 1. Name?

    Ist der angefragte Hostname korrekt?

  2. 2. DNS?

    Kommt die erwartete Adresse zurück?

  3. 3. IP/Pfad?

    Ist grundlegende Erreichbarkeit plausibel?

  4. 4. Port?

    Ist der Zielport erreichbar und lauscht der Dienst?

  5. 5. TLS?

    Passen Name, Zeitraum und Vertrauenskette?

  6. 6. HTTP?

    Trifft eine HTTP-Antwort ein?

  7. 7. Status?

    Welche Codeklasse und welcher konkrete Status?

  8. 8. Pfad?

    Ist Ressource beziehungsweise Route korrekt?

  9. 9. Anwendung/Upstream?

    Ist ein Backend beteiligt und erreichbar?

  10. 10. Logs/Config?

    Nach Eingrenzung gezielt Belege prüfen.

Eine Antwort einer späteren Schicht belegt oft, dass frühere Schritte für genau diesen Austausch hinreichend funktioniert haben. Ein 404 Not Found setzt beispielsweise genug DNS/Netz/Transport/HTTP-Kommunikation voraus, damit ein Server antworten konnte.

DNS, Connection refused und Timeout

DNS schlägt fehl

Wenn web01.firma.test in einer gezielten DNS-Abfrage nicht aufgelöst wird, untersuche Resolver und DNS-Daten vor Webinhalten. Eine Browsermeldung allein beweist DNS nicht.

Connection refused

Der Zielpfad war meist weit genug erreichbar, um abzulehnen, aber am Endpunkt akzeptierte kein Dienst die Verbindung oder eine Policy lehnte aktiv ab. Prüfe Dienst, Port, Listen-Adresse, Firewall und Protokollerwartung.

Timeout

Die erwartete Verbindung oder Antwort kam nicht rechtzeitig. Routing, Paketverlust/Filterung, Ausfall, Überlastung oder ein langsamer Upstream sind Möglichkeiten – nicht automatisch eine Firewall.

Lauscht dieser HTTP-Dienst auf 8080, muss der Aufruf http://web01.firma.test:8080/ den Port nennen; ohne Angabe verwendet HTTP gewöhnlich 80. Port 8080 bedeutet nicht inhärent HTTP – nur dieses Beispiel definiert es so.

TLS-Fehler gezielt untersuchen

DNS liefert korrekt, die Verbindung erreicht den Server, aber das Zertifikat gilt für old.firma.test statt für das angefragte portal.firma.test. Das ist Evidenz für Hostname-Mismatch beziehungsweise falsche Zertifikatsbereitstellung. Prüfe Zertifikatsidentitäten sowie Webserver-/Reverse-Proxy-Zuordnung; das blinde Umgehen der Prüfung ist keine Lösung.

HTTP-Fehler unterscheiden

403 Forbidden

Server versteht die Anfrage, verweigert aber Zugriff. Autorisierung, Serverregeln, anwendungsbezogene Policy und je nach Setup Datei-/Verzeichnisrechte kommen infrage.

404 Not Found

GET /azubi/index.html wurde beantwortet, aber Ressource/Route ist nicht verfügbar. Prüfe URL, Document Root, Routing und Deployment – nicht pauschal DNS.

500 Internal Server Error

Serverseitige Verarbeitung scheiterte, etwa durch Anwendungsfehler, Konfiguration oder Backend-Abhängigkeit; kein Beweis für Hardwaredefekt.

502 Bad Gateway

Gateway/Proxy erhielt eine ungültige oder ungeeignete Upstream-Antwort.

503 Service Unavailable

Dienst ist aktuell nicht verfügbar, beispielsweise wegen Wartung, Überlastung oder ausgefallenem Service.

504 Gateway Timeout

Gateway/Proxy wartete ohne rechtzeitige Upstream-Antwort.

502, 503 und 504 grenzen Kategorien ein, bestimmen aber keine einzigartige Grundursache.

Browser
Webserver / Proxy
Anwendung

Werkzeuge liefern Belege

nslookup web01.firma.test

Prüft die DNS-Antwort gezielt.

Test-NetConnection web01.firma.test -Port 80

PowerShell: prüft eine TCP-Verbindung, nicht die Korrektheit der Webanwendung.

Test-NetConnection web01.firma.test -Port 443

PowerShell: prüft TCP, nicht automatisch Zertifikat oder HTTP-Inhalt.

curl -I http://web01.firma.test/

Fordert per HTTP typischerweise Header mit HEAD an; Serververhalten kann variieren.

curl -v http://web01.firma.test/

Zeigt Verbindungs-/Requestdetails; niemals Zugangsdaten oder Tokens in Übungen verwenden.

ss -ltn

Auf einem zugänglichen Linux-Server: lokale lauschende TCP-Sockets prüfen.

ping liefert nur begrenzte ICMP-Evidenz und beweist keinen HTTP-Dienst. nc oder andere Portwerkzeuge können je nach Plattform vorhanden sein; keine Installation ist erforderlich. Browser-Entwicklungswerkzeuge zeigen Request, Status und Header.

Wissenscheck

404 richtig weiterverfolgen

nslookup liefert 192.168.10.20, TCP-Port 80 ist erreichbar und GET /missing.html ergibt HTTP 404. Was untersuchst du als Nächstes?

Zwei weitere Szenarien

Zertifikat für old.firma.test

Bei portal.firma.test liegt ein Hostname-Mismatch oder falsches Zertifikat am Webserver/Proxy nahe – kein generischer DNS-Ausfall.

502 Bad Gateway

Der Frontend-Proxy antwortet. Untersuche Upstream-Anwendung, Backend-Konnektivität und Antwort; den Browser neu zu installieren ist unbegründet.

Kompakte Checkliste

Name / DNS

  • Hostname korrekt?
  • Erwartete Adresse?

Netzwerk

  • IP, Subnetz, Gateway plausibel?
  • Welche Pfad-Evidenz?

Transport

  • Korrekter Port?
  • Dienst erreichbar/lauschend?

TLS

  • Hostname passend?
  • Kette vertraut?
  • Zeitraum gültig?

HTTP

  • Antwort und Status?
  • Pfad und Methode?

Anwendung / Upstream

  • Backend gesund?
  • Logs?
  • Proxy-/Upstream-Pfad?

Dokumentiere: beobachtetes Verhalten → Test → Ergebnis → Änderung → erneuter Test.

Typische Fehlvorstellungen

Falsch: „404 = Server nicht erreichbar.“
Korrektur: 404 ist eine HTTP-Antwort des Servers.
Falsch: „Connection refused = DNS-Fehler.“
Korrektur: Ablehnung betrifft den Verbindungsendpunkt; DNS ist eine andere Ebene.
Falsch: „Timeout beweist Firewall.“
Korrektur: Mehrere Pfad-, Server- und Lastursachen sind möglich.
Falsch: „500 bedeutet Hardwaredefekt.“
Korrektur: 500 meldet eine serverseitige Verarbeitungsstörung.
Falsch: „502 und 504 sind dasselbe.“
Korrektur: 502 betrifft eine ungeeignete Upstream-Antwort, 504 deren rechtzeitiges Ausbleiben.
Falsch: „Erfolgreicher Ping beweist HTTP.“
Korrektur: ICMP-Evidenz testet keinen Webdienst.
Falsch: „Bei Zertifikatsfehlern klickt man einfach auf Weiter.“
Korrektur: Validierungsfehler werden untersucht statt normalisiert.

Nächste Lektion

Praxis: Webserver mit Filius

Zum Abschluss baust du DNS, Client und HTTP-Webdienst in einem kontrollierten Lab zusammen und führst gezielte Fehler ein.

Dein Lernstand

Lektion in Bearbeitung

Das Öffnen startet die Lektion. Als erledigt zählt sie erst nach deiner ausdrücklichen Bestätigung.