How do I check if a TCP port is open online?

Enter your server's IP address or domain followed by a colon and the port number (e.g. 1.1.1.1:80 or example.com:443) and run a TCP check. The tool attempts a TCP handshake from 50+ global nodes and reports whether each connection succeeded, was refused, or timed out.

What is the difference between a port being refused versus timing out?

A refused connection (TCP RST) means the port is actively closed — the server replied to reject the connection. A timeout means no reply was received at all, which typically indicates a firewall is silently dropping packets before they reach the server or application.

Which TCP ports can I test?

Any valid TCP port from 1 to 65535. Common examples include port 80 (HTTP), 443 (HTTPS), 22 (SSH), 25 (SMTP), 3306 (MySQL), 5432 (PostgreSQL), and 3389 (RDP). No login or special permissions required — the check only verifies whether the TCP handshake completes.

My port is open locally but fails from external nodes — why?

If a port works locally but fails from external nodes, something between the internet and your server is blocking it — commonly a cloud security group, iptables rule, upstream ISP filter, or geoblocking policy. Running the check from multiple regions helps identify whether the block is global or specific to certain countries or ASNs.

TCP-Port-Check für nl-ams-floki.check-host.eu:80

Name: Check-Host nl-ams-floki.check-host.eu:80 TCP-Port-Verbindungstest
Author: Check-Host

Erweiterte Einstellungen

Weltkarte anzeigen

Info Ping HTTP TCP UDP MTR DNS

TCP prüfen nl-ams-floki.check-host.eu:80

Permanenter Link |

Standort	Ergebnis	Zeit	IP-Adresse
Albania, Tirana
Australia, Sydney
Bosnia and Herzegovina, Novi Travnik
Bulgaria, Sofia
Canada, Montreal
Switzerland, Bern
Chile, Santiago
China, Hohhot
Germany, Nuernberg
Germany, Frankfurt am Main
Germany, Frankfurt am Main
Germany, Limburg
Germany, Frankfurt am Main
Germany, Duesseldorf
Denmark, Glostrup Municipality
Spain, Bilbao
Finland, Helsinki
Finland, Helsinki
France, Gravelines
France, Paris
United Kingdom, London
Georgia, Tbilisi
Greece, Athens
Hong Kong, Hong Kong
Croatia, Zagreb
Hungary, Budapest
Indonesia, Jakarta
Israel, Petach Tikwa
Israel, Netanja
India, New Delhi
Iceland, Reykjavik (Miðborg)
Italy, Como
Kuwait, Kuwait City
Lithuania, Pilaite
Latvia, Riga
Moldova, Chisinau
Netherlands, Amsterdam
Netherlands, Amsterdam
Netherlands, Amsterdam
Netherlands, Amsterdam
Norway, Oslo
Poland, Warsaw
Romania, Bacău
Romania, Bucharest
Serbia, Belgrade
Russia, St Petersburg
Singapore, Singapore
Turkey, Istanbul
Taiwan, Taipei
United States, Miami
United States, Dallas
United States, Kansas City
United States, Dallas
South Africa, Johannesburg

Globaler TCP-Port-Checker & Netzwerk-Konnektivitätstest

Ein TCP-Check versucht, einen Drei-Wege-Handshake (SYN → SYN-ACK → ACK) zu einem bestimmten Host und Port aufzubauen, und misst dabei die benötigte Zeit. Anders als Ping läuft das durch dieselben Firewall-Regeln und Routing-Richtlinien wie echter Anwendungs-Traffic. Wenn ein Port den TCP-Handshake akzeptiert, ist er offen — egal, was die dahinterliegende Anwendung danach mit den Daten macht.

Firewall & Routing-Validierung

Wenn ein Port lokal funktioniert, von externen Nodes aber nicht erreichbar ist, blockiert irgendetwas zwischen dem Internet und deinem Server — eine Cloud-Security-Group, eine iptables-Regel, ein ISP-Filter oder eine Geoblocking-Richtlinie. Der gleichzeitige Test aus mehreren Regionen zeigt, ob die Blockade global ist oder nur bestimmte Quell-Länder oder ASNs betrifft. Ein Timeout von allen Nodes bedeutet meistens, der Port ist von außen schlicht nicht erreichbar; eine abgelehnte Verbindung dagegen, dass der Port aktiv geschlossen ist.

Anwendungs- vs. Transportschicht

TCP-Checks arbeiten auf Layer 4, also lassen sich damit auch Ports testen, die keine HTTP-Schnittstelle haben — Datenbanken (MySQL 3306, PostgreSQL 5432), Mailserver (SMTP 25, IMAPS 993), SSH (22), RDP (3389) oder eigene Anwendungsports. Keine Zugangsdaten nötig. Der Check prüft nur, ob der TCP-Handshake abgeschlossen wird, nicht was die Anwendung danach macht. Für einen Test auf Anwendungsebene braucht man einen protokollspezifischen Check dazu.

Handshake-Latenzanalyse

Die gemessene Zeit ist der vollständige Round-Trip bis der TCP-Handshake abgeschlossen ist — also ungefähr die reine Netzwerklatenz plus etwas Server-Verarbeitungszeit. Große Unterschiede zwischen Regionen weisen meist auf suboptimales Routing hin — Traffic nimmt einen längeren Weg als nötig — und nicht auf ein Server-Problem. Der Live-Modus führt den Check 60 Sekunden lang durch und macht damit sporadische Verbindungsabbrüche sichtbar, die ein einmaliger Test nicht erwischt.