Ping beweist nur, dass ein Server auf Netzwerkverkehr antwortet. Ob deine Website, deine API oder dein Zertifikat tatsächlich funktioniert, verrät er nicht. HTTP-Monitoring beweist, dass deine Anwendung die richtige Antwort liefert. HTTPS-Monitoring beweist, dass diese Antwort zusätzlich mit einem gültigen, nicht abgelaufenen Zertifikat verschlüsselt ist. Wenn du nur Ping-Checks laufen lässt, wiegst du dich in falscher Sicherheit darüber, was „online“ eigentlich bedeutet.
Was ein Ping-Check wirklich beweist
Ping sendet gemäß RFC 792 einen ICMP (Internet Control Message Protocol) Echo Request und wartet auf einen Echo Reply. Eine Antwort bestätigt genau eine Sache: Der Host ist auf der Netzwerkschicht (Layer 3) erreichbar und hat auf genau diesen Pakettyp geantwortet.
Das war’s. Ping weiß nicht, ob dein Webserver läuft, weiß nicht, ob deine Datenbank verfügbar ist, und kann nicht einmal sehen, ob Port 443 überhaupt offen ist. RFC 1122 sagt, dass Hosts einen ICMP-Echo-Responder implementieren sollten. Aber „sollten“ heißt nicht „müssen“, und viele Firewalls und Cloud-Security-Groups blockieren eingehendes ICMP standardmäßig. Das bedeutet:
- Ein völlig gesunder Webserver kann einen Ping-Check nicht bestehen, weil die Netzwerkschicht ICMP blockiert – ein Fehlalarm.
- Ein Server kann einen Ping-Check bestehen, obwohl Apache, nginx oder dein App-Prozess komplett abgestürzt ist – ein falsches „Alles okay“.
Wegen dieser beiden Fehlerarten ist Ping für sich genommen ein schwaches Signal. Für die grundlegende Netzwerkerreichbarkeit beim Debuggen der Infrastruktur ist er nützlich, aber er wurde nie dafür entwickelt, eine Anwendung zu validieren.
WarningStandardmäßige AWS-Security-Groups (und viele andere Cloud-Firewalls) blockieren eingehendes ICMP, sofern du es nicht explizit freigibst. Wenn du dich in der Cloud nur auf Ping-Monitoring verlässt, überwachst du womöglich gar nichts.
Was ein HTTP-Check wirklich beweist
Ein HTTP-Monitor sendet eine echte Anfrage – meist GET oder HEAD – an Port 80 und prüft die Antwort, entsprechend der Semantik in RFC 9110 und der Nachrichtensyntax in RFC 9112. Ein typischer Check stellt sicher:
- Die Verbindung kommt zustande und innerhalb eines Timeout-Fensters wird eine Antwort zurückgegeben.
- Der Statuscode liegt im erwarteten Bereich (meist 2xx, manchmal sind 3xx-Weiterleitungen erlaubt).
- Optional enthält der Response-Body ein erwartetes Keyword oder einen bestimmten String.
Das beweist, dass dein Webserver-Prozess läuft und die erwarteten Inhalte ausliefert – ein echter Fortschritt gegenüber Ping. Allerdings endet HTTP-Monitoring auf der Anwendungsschicht im Klartext. TLS (Transport Layer Security) wird überhaupt nicht berührt, daher erfährst du nichts darüber, ob dein HTTPS-Endpunkt – also der, den deine Besucher und Browser tatsächlich nutzen – funktioniert.
Eine Website kann auf Port 80 200 OK zurückgeben, während ihr HTTPS-Listener auf Port 443 wegen eines abgelaufenen oder falsch konfigurierten Zertifikats komplett defekt ist. Ein reiner HTTP-Monitor meldet die ganze Zeit „online“.
Was ein HTTPS-Check wirklich beweist
HTTPS-Monitoring macht alles, was ein HTTP-Check macht, und validiert zusätzlich die TLS-Schicht, die in RFC 8446 (TLS 1.3) definiert und durch RFC 2818 als HTTP-over-TLS festgeschrieben ist. Ein ordentlicher HTTPS-Check bestätigt:
- Der TLS-Handshake wird erfolgreich abgeschlossen.
- Die Zertifikatskette lässt sich gegen eine vertrauenswürdige Root validieren, gemäß dem X.509-Format in RFC 5280.
- Das Zertifikat ist nicht abgelaufen (und idealerweise wirst du Tage im Voraus gewarnt).
- Es wird eine moderne, nicht veraltete Protokollversion ausgehandelt – TLS 1.0 und 1.1 wurden durch RFC 8996 offiziell als veraltet eingestuft, ein Handshake, der auf diese Versionen zurückfällt, ist also an sich schon ein Warnsignal.
Das ist der einzige Check-Typ, der die häufigste Ursache für unerwartete „Website down“-Vorfälle erkennt, die eigentlich kein Serverabsturz sind: abgelaufene Zertifikate. Ein Ping-Check sieht das nicht. Ein reiner HTTP-Check auf Port 80 sieht das nicht. Nur ein Check, der über TLS mit Port 443 spricht, erkennt es.
Vergleich auf einen Blick
| Check-Typ | Bestätigt Netzwerkerreichbarkeit | Bestätigt Antwort von App/Server | Bestätigt korrekten Status/Inhalt | Bestätigt gültiges, nicht abgelaufenes TLS-Zertifikat |
|---|---|---|---|---|
| Ping (ICMP) | Ja | Nein | Nein | Nein |
| HTTP | Ja | Ja | Ja | Nein |
| HTTPS | Ja | Ja | Ja | Ja |
Jede Zeile weiter unten in der Tabelle schließt die darüberliegende ein – ein HTTPS-Check ist praktisch eine Obermenge eines HTTP-Checks, der wiederum eine Obermenge der grundlegenden Erreichbarkeit ist.
Warum Ping allein nicht reicht
Ping wurde 1981 für die Netzwerkdiagnose entwickelt, nicht zur Validierung moderner, in TLS verpackter Webanwendungen. Wenn du ihn als primäres Uptime-Signal nutzt, entstehen zwei gefährliche Lücken:
- False Positives, weil ICMP an einer Firewall, einer Security-Group oder am CDN-Edge blockiert wird und so Alarme für Server ausgelöst werden, die eigentlich einwandfrei laufen.
- False Negatives – der weitaus schädlichere Fall –, bei denen die Netzwerkschicht in Ordnung ist, aber deine App, deine Datenbankverbindung oder dein Zertifikat ausgefallen ist und Ping während des gesamten Ausfalls fröhlich „online“ meldet.
Wenn du wissen willst, ob ein Server im Netzwerk existiert, reicht Ping. Wenn du wissen willst, ob deine Kunden deine Website tatsächlich sicher laden können, brauchst du HTTP- und HTTPS-Checks, die zusammen laufen – plus eine Warnung vor Zertifikatsablauf, die rechtzeitig vor dem Ablauf des Zertifikats auslöst.
Welchen Check solltest du wirklich nutzen?
In der Praxis sollten die meisten Teams HTTPS-Monitoring als primären Check für alles einsetzen, was Kunden direkt erreicht, denn es validiert den gesamten Stack, den ein Besucher erlebt: DNS-Auflösung, TCP-Verbindung, TLS-Handshake, HTTP-Antwort und Inhalt. Ping- und reine HTTP-Checks lohnen sich trotzdem weiterhin als sekundäre Diagnose – sie helfen dir einzugrenzen, wo ein Fehler auftritt, sobald das HTTPS-Monitoring einen Vorfall meldet.
Ein sinnvolles Setup sieht so aus:
- HTTPS-Check auf deinem öffentlichen Endpunkt, der Statuscode, Antwortzeit und Zertifikatsablauf prüft – dein primärer Alarm.
- HTTP-Check auf einem internen oder Nicht-TLS-Endpunkt (Health-Check-Pfade, interne APIs), bei dem TLS keine Rolle spielt.
- Ping-/Port-Checks für die Erreichbarkeit auf Infrastrukturebene bei der Fehlersuche, nicht als dein Hauptauslöser für Alarme.
Wenn du nicht sicher bist, ob eine Website gerade überhaupt erreichbar ist, prüfe sie mit unserem kostenlosen Is-it-down-Checker – für einen sofortigen HTTP/HTTPS-Statuscheck von außerhalb deines eigenen Netzwerks. Ein guter erster Schritt, bevor du dich in die Logs stürzt.
Richtig einrichten
Ping-, HTTP- und HTTPS-Checks als separate, korrekt konfigurierte Monitore zu betreiben – jeder mit eigenen Alarmschwellen und Warnungen vor Zertifikatsablauf –, ist genau das, wofür spezialisiertes Uptime-Monitoring da ist. Einen umfassenderen Überblick darüber, wie Uptime-, Performance- und SSL-Checks zusammenspielen, findest du in unserem Leitfaden Website-Monitoring erklärt.
Richte mehrschichtige Checks – Ping, HTTP und HTTPS mit Alarmen vor Zertifikatsablauf – für alle Anbieter über ein einziges Dashboard ein, mit InfraNest Monitoring.
Häufig gestellte Fragen
#Ist HTTPS-Monitoring immer besser als HTTP-Monitoring?
Für jeden Endpunkt, den deine Besucher über HTTPS erreichen, ja – ein HTTPS-Check validiert den TLS-Handshake und den Zertifikatsablauf, die ein reiner HTTP-Check schlicht nicht sehen kann. Behalte HTTP-Checks für interne oder Nicht-TLS-Endpunkte, bei denen Zertifikate keine Rolle spielen.
#Warum zeigt mein Ping-Check einen Server als down an, obwohl die Website einwandfrei funktioniert?
Die meisten Cloud-Firewalls und Security-Groups blockieren eingehendes ICMP standardmäßig, daher antwortet der Server nie auf Ping, obwohl sein Webserver auf Port 80/443 gesund ist. Das ist ein klassisches False Positive – die Lösung ist, HTTP/HTTPS statt oder zusätzlich zu ICMP zu überwachen.
#Kann ein HTTP-Check auf Port 80 ein abgelaufenes SSL-Zertifikat erkennen?
Nein. Ein HTTP-Check auf Port 80 berührt TLS nie und kann daher weder Zertifikatsablauf noch schwache Cipher oder Handshake-Fehler auf Port 443 erkennen – das schafft nur ein HTTPS-Check.
#Wie weit im Voraus sollte ich vor einem Zertifikatsablauf gewarnt werden?
Bei den meisten Monitoring-Anbietern kannst du eine Vorlaufzeit für Ablaufwarnungen festlegen, üblicherweise irgendwo zwischen einigen Tagen und einigen Wochen vor dem Ablauf. Prüfe die aktuellen Einstellungen deines Anbieters und wähle die Vorlaufzeit großzügig genug, um das Zertifikat vor dem Ablauf zu erneuern.
Mit einem kostenlosen Tool ausprobieren
War dieser Artikel hilfreich?
