Wenn eine Verbindung fehlschlägt, ist "der Port ist nicht offen" eines der ersten Dinge auf der Checkliste. Aber es gibt einen wichtigen Unterschied zwischen einem geschlossenen Port, einem gefilterten Port und einem Port, der offen ist, dessen Dienst aber kaputt ist. Die Diagnose hängt davon ab, welche Situation vorliegt.
Drei mögliche Zustände
Offen — etwas lauscht aktiv auf diesem Port. Ein TCP-Verbindungsversuch schließt den Drei-Wege-Handshake erfolgreich ab.
Geschlossen — die Maschine ist erreichbar, aber nichts lauscht auf diesem Port. Das Betriebssystem sendet sofort ein TCP-RST-Paket zurück. Das ist eigentlich nützlich: Es zeigt, dass die Maschine läuft und das Netzwerk funktioniert — nur dieser Dienst läuft nicht.
Gefiltert / Timeout — eine Firewall verwirft die Pakete stillschweigend. Der Verbindungsversuch hängt bis zum Timeout. Kein RST, keine Ablehnung — nur Stille. Das ist der häufigste Zustand bei Produktionsservern mit strikten Firewall-Regeln.
Port von mehreren Standorten prüfen
Der eigene Rechner kann nur zeigen, ob ein Port von der eigenen IP und dem eigenen ISP erreichbar ist. Eine Firewall könnte genau diese IP blockieren, oder eine geografische Regel blockiert ein bestimmtes Land — während der Port von überall sonst zugänglich ist.
Das TCP-Check-Tool testet, ob ein Port von 50+ globalen Knoten gleichzeitig erreichbar ist. example.com:443 eingeben, Check starten — und sofort sehen, welche Regionen sich verbinden können und welche ein Timeout bekommen.
Wenn manche Knoten erfolgreich sind und andere nicht, ist das fast immer IP-basiertes Blocking oder Geo-Filterung, kein echtes Serviceproblem.
Vom eigenen Rechner testen
Für schnelle lokale Tests:
Telnet (auf den meisten Systemen verfügbar):
telnet example.com 443
Sofortige Verbindung = offen. Hängt = gefiltert. Sofortiges "Connection refused" = geschlossen.
Netcat (Linux/macOS):
nc -zv example.com 443
PowerShell (Windows):
Test-NetConnection -ComputerName example.com -Port 443
Häufige Ports im Überblick
| Port | Dienst |
|---|---|
| 22 | SSH |
| 25 | SMTP |
| 80 | HTTP |
| 443 | HTTPS |
| 3306 | MySQL |
| 5432 | PostgreSQL |
| 6379 | Redis |
| 8080 | Alternativer HTTP-Port |
Warum ein Port, der gestern offen war, jetzt gefiltert ist
Die häufigsten Gründe:
Firewall-Regeländerung. Eine neue DROP- oder REJECT-Regel wurde für diesen Port hinzugefügt. iptables/nftables/Security-Group-Regeln prüfen.
Dienst abgestürzt. Wenn das OS sofort RST zurückschickt, lauscht nichts. Wenn es timeoutet, blockiert eine Firewall den Port auch dann, wenn der Dienst nicht läuft.
Fail2ban oder automatisches IP-Blocking. Tools wie fail2ban sperren IPs nach wiederholten fehlgeschlagenen Login-Versuchen. Wenn der TCP-Check inkonsistente Ergebnisse zeigt (manche Knoten kommen durch, andere nicht), ist das oft die Ursache. Von einem anderen Land aus testen.
UDP-Ports sind anders
UDP hat keinen Handshake. Es gibt keine Möglichkeit, einen UDP-Port so sicher als "offen" zu bestätigen wie bei TCP. Ein Paket wird gesendet; gibt es eine Antwort, lauscht etwas. Bleibt eine Antwort aus, könnte der Port offen sein und Traffic verarbeiten — oder er wird geblockt.
Das UDP-Check-Tool sendet Probes und meldet erhaltene Antworten. Nützlich für Gameserver, VPN-Endpunkte (WireGuard 51820, OpenVPN 1194), DNS (Port 53) und NTP (Port 123).