Connection refused oder Timeout: was ein geschlossener Port wirklich verrät

17.08.2026

Thema: alle Beiträge zu Linux

Refused und Timeout sehen beide nach einem geschlossenen Port aus, sagen aber das Gegenteil voneinander. Wer den Unterschied kennt, liest aus drei Kommandos ab, ob eine Firewall wirklich schützt.

Inhaltsverzeichnis

Zwei Arten von zu

Wenn du einen TCP-Port testest und er nicht offen ist, bekommst du eine von zwei Antworten. Entweder ein sofortiges „Connection refused” oder ein Timeout nach mehreren Sekunden. Die meisten behandeln beide gleich: Port zu, nächster Versuch. Dabei sagen die beiden Antworten das Gegenteil voneinander.

Die Regel vorweg, der Rest des Beitrags begründet sie:

Connection refused heißt: der Server hat geantwortet. Timeout heißt: niemand hat geantwortet. Nur der Timeout beweist, dass eine Firewall das Paket verwirft.

Wer diese Regel kennt, liest aus einem simplen Port-Test ab, ob eine Firewall wirklich tut, was sie soll. Wer sie nicht kennt, hält ausgerechnet das Alarmsignal für Sicherheit.

Was beim Verbindungsaufbau wirklich passiert

TCP beginnt jede Verbindung mit einem Handshake. Dein Rechner schickt ein SYN-Paket an den Zielport. Ab da gibt es genau drei mögliche Ausgänge:

  1. Ein Dienst lauscht auf dem Port. Der Server antwortet mit SYN-ACK, dein Rechner bestätigt mit ACK, die Verbindung steht.
  2. Kein Dienst lauscht, aber das Paket kommt an. Der Kernel des Servers antwortet sofort mit einem RST-Paket, einem Reset. Das ist das „Connection refused”.
  3. Das Paket kommt nie an oder wird verworfen. Es gibt keinerlei Antwort. Dein Rechner wiederholt das SYN und gibt irgendwann auf. Das ist der Timeout.

Der entscheidende Punkt steckt in Fall 2: Das RST-Paket ist eine aktive Antwort des Ziel-Kernels. Damit sie bei dir ankommt, muss dein SYN vorher den ganzen Weg geschafft haben, durch jede Firewall hindurch bis zum Server. „Connection refused” ist also keine Abwehr, sondern eine Auskunft: Server erreichbar, Weg frei, nur der Dienst fehlt.

Nachgemessen: 2 Millisekunden gegen 3 Sekunden

Der Unterschied ist nicht nur konzeptionell, du siehst ihn an der Uhr. Erst ein Port auf dem eigenen Rechner, auf dem nichts lauscht:

$ time nc -z -v -w3 127.0.0.1 2222
localhost [127.0.0.1] 2222 (?) : Connection refused
nc -z -v -w3 127.0.0.1 2222  0.00s user 0.00s system 0% cpu 0.002 total

Die Antwort kommt nach 2 Millisekunden. So schnell antwortet nur ein Kernel, der aktiv ein RST zurückschickt.

Jetzt ein Port hinter einer Firewall, die Pakete verwirft, hier der SSH-Port dieses Servers:

$ time nc -z -v -w3 trutz.io 22
trutz.io [167.235.234.197] 22 (ssh) : Connection timed out
nc -z -v -w3 trutz.io 22  0.00s user 0.00s system 0% cpu 3.004 total

Exakt 3,004 Sekunden: die drei Sekunden aus -w3 plus Rauschen. nc hat die ganze Wartezeit ausgeschöpft, weil schlicht nichts zurückkam.

Ohne die Handbremse -w3 wäre das deutlich unangenehmer. Ein Linux-Kernel wiederholt ein unbeantwortetes SYN standardmäßig sechsmal, mit Abständen, die sich jeweils verdoppeln: nach einer Sekunde, nach zwei, nach vier und so weiter. Bis er aufgibt, vergehen gut zwei Minuten. Der Wert steht in net.ipv4.tcp_syn_retries und erklärt, warum sich ein Timeout ohne Zeitlimit endlos anfühlt: Er dauert wirklich so lange.

Die Entscheidung auf der anderen Seite: DROP oder REJECT

Ob du refused oder Timeout siehst, entscheidet die Gegenseite. Eine Firewall hat für unerwünschte Pakete zwei Möglichkeiten:

REJECT ist die höfliche Variante, sie lässt legitime Clients nicht warten. DROP ist die verschlossene: Der Absender erfährt nicht einmal, dass seine Pakete jemanden erreicht haben. Ein Scanner, der Tausende Adressen abklappert, bekommt von einem DROP-Host keinerlei Signal, dass sich hier weiteres Probieren lohnt. Cloud-Firewalls wie die von Hetzner oder AWS verwerfen deshalb still.

Daraus folgt die Umkehrung, die diesen Beitrag motiviert: Wenn ein Port durch eine solche Firewall gesperrt sein soll und du beim Test ein sofortiges „Connection refused” bekommst, stimmt etwas nicht. Die Absage kam dann nämlich vom Server selbst, das Paket ist durch die Firewall durchgekommen. Der Timeout ist bei dieser Konstellation nicht die lästige, sondern die einzig richtige Antwort.

Das Werkzeug: nc mit -z und -w

Für den Test reicht netcat, das auf fast jedem System vorhanden ist:

nc -z -w3 <host> <port>

Für Skripte und schnelle Checks:

nc -z -w3 trutz.io 443 && echo "offen" || echo "zu"
Bei UDP hilft dir das alles übrigens nur begrenzt. UDP hat keinen Handshake: Auf einen geschlossenen UDP-Port antwortet der Kernel mit einer ICMP-Fehlermeldung, auf einen offenen antwortet nur der Dienst selbst, wenn ihm das Paket gefällt. Schweigt der Dienst, sieht offen genauso aus wie gefiltert. Port-Scanner geben deshalb bei UDP oft „open filtered” aus: Sie können es prinzipbedingt nicht unterscheiden. Das klingt wie eine Schwäche des Scanners, lässt sich aber gezielt als Stärke des Dienstes nutzen. Dazu ein andermal mehr.

Der Beweis in drei Zeilen

Ein Timeout allein beweist noch keine Firewall. Er kann auch heißen: Server aus, Route kaputt, Tippfehler in der Adresse. Wasserdicht wird der Befund erst in Kombination:

$ ping -c2 trutz.io
2 packets transmitted, 2 received, 0% packet loss

$ nc -z -v -w3 trutz.io 443
trutz.io [167.235.234.197] 443 (https) open

$ nc -z -v -w3 trutz.io 22
trutz.io [167.235.234.197] 22 (ssh) : Connection timed out

Drei Aussagen, zusammen ein Beweis: Der Ping zeigt, dass der Server läuft und erreichbar ist. Der offene Port 443 zeigt, dass TCP-Pakete grundsätzlich ankommen und beantwortet werden. Und der Timeout auf Port 22 zeigt damit zwingend: Genau dieses Paket wird unterwegs still verworfen. Die Firewall hängt dran und tut ihren Job.

Ohne die ersten beiden Zeilen wäre die dritte wertlos. Mit ihnen ist sie ein Nachweis, den du von jedem Rechner der Welt aus führen kannst, ganz ohne Zugang zum Server.

Fazit

  1. Connection refused ist eine aktive Antwort des Ziel-Kernels per RST: Server erreichbar, Firewall durchlässig, nur der Dienst fehlt.
  2. Timeout heißt: keinerlei Antwort. Der Kernel wiederholt das SYN sechsmal über gut zwei Minuten, -w3 kürzt das Warten ab.
  3. Firewalls wählen zwischen REJECT (aktive Absage, wirkt wie refused) und DROP (stilles Verwerfen, wirkt als Timeout). Cloud-Firewalls verwerfen still.
  4. Auf einem Port, der gesperrt sein soll, ist refused ein Alarmsignal und der Timeout die einzig richtige Antwort.
  5. nc -z -v -w3 ist der Port-Test für die Praxis; der Exit-Code unterscheidet refused und Timeout nicht, die -v-Ausgabe schon.
  6. Beweiskräftig wird der Timeout erst im Dreisatz mit Ping und einem offenen Vergleichsport.

Warum mich das gerade beschäftigt: Ich baue an einem Server, bei dem der Timeout auf jedem Admin-Port die einzig richtige Antwort ist, und der sich trotzdem jeden Tag bequem administrieren lässt. Wie das zusammenpasst, zeige ich demnächst hier und auf dem YouTube-Kanal. Bis dahin gilt wie immer: nicht der Doku glauben, sondern selbst nachmessen.

© 2026 Trutz Software Consulting GmbH. CC BY 4.0: Dieser Text darf mit Namensnennung weiterverwendet und bearbeitet werden, auch kommerziell. Code-Beispiele darin stehen unter Apache 2.0. Ausgenommen sind Marke und Logo sowie gekennzeichnete Zitate Dritter. Was das genau heißt.

Newsletter

Erhalte praxisnahe Tutorials, Best Practices und echte Lösungen für die häufigsten DevOps-Probleme direkt in Dein Postfach.

Datenschutz: Deine E-Mail-Adresse wird DSGVO-konform in Deutschland gespeichert. Keine Spam, nur relevante Inhalte. Eine E-Mail alle 1 bis 2 Wochen.