Port Checker
A TCP connection test to a host and port — performed from the server.
The Port Checker tests a TCP connection to a given host and port — from our server, in other words “from the internet”. In a few seconds you’ll know whether the service is reachable from outside, or whether a firewall or NAT is standing in the way.
What is port checking for?
A port is a number (1 to 65535) that tells the system which service an incoming connection to a given IP address belongs to. A web server conventionally listens on port 443 (HTTPS) and 80 (HTTP), SSH on 22, mail on 25 (SMTP), and MySQL on 3306. A service works only when its port is open — that is, when a process is listening and no firewall along the way is blocking it.
An external test settles the administrator’s most common dilemma: “the service works locally, but clients can’t connect”. The cause tends to be a firewall on the server, a missing port forward on the router (NAT), a block at the ISP level, or simply a process listening only on the local address. This tool tells you unambiguously how the rest of the internet sees that port.
How to use the tool
- Enter a host — a domain (e.g.
sycope.com) or a public IP address. - Enter a port number — anything from 1 to 65535, or click one of the popular presets: 80 HTTP, 443 HTTPS, 22 SSH, 25 SMTP, 3306 MySQL.
- Click ‘Check’ — we attempt a TCP connection from our server and show the result moments later.
A result of “Port open” means the connection was established — the service is listening and reachable from the internet. “Port closed” means no response or a refused connection: the service isn’t running, is listening somewhere else, or a firewall is dropping the traffic.
Open, closed, filtered — what it means in practice
From TCP’s point of view, every connection begins with a three-way handshake. If the host answers with an acceptance — the port is open. If it sends back a refusal — the port is closed, but the host itself is alive. The third scenario is silence: packets vanish along the way, which usually means the port is filtered by a firewall. In our test, the latter two cases both show up as “Port closed” — from the outside, the effect is the same: the service is unavailable.
For diagnosing from the inside, it helps to know the local equivalents of this test: the netstat command (or ss) lists the ports the server is actually listening on along with connection states, telnet host port makes a manual connection attempt, and Test-NetConnection does the same in PowerShell. If the service is listening locally but the external test shows the port closed — blame the firewall or NAT.
Open ports and security
Every open port is a potential door into the system, so the iron rule is: expose to the world only what genuinely has to be public. Database panels, RDP and administrative interfaces should be reachable through a VPN at most. Port scanning — mass-probing which services respond — is the routine first step of every attack; bots do it round the clock across the entire address space of the internet.
Regularly auditing your own infrastructure is good practice: check from the outside the ports that ought to be closed (25, 3306, 3389…) and reconcile the results with your firewall rules. At scale, that job falls to network traffic monitoring — systems such as Sycope detect port scans and connections to unusual services in real time, before reconnaissance turns into an attack.
Frequently asked questions (FAQ)
What’s the difference between a TCP and a UDP port?
TCP establishes a connection and confirms delivery — it’s what the web, SSH and email run on. UDP sends packets with no acknowledgements, which suits DNS, voice and gaming. This tool tests TCP; UDP ports can’t be reliably checked with a simple connection attempt.
Why is a port open locally but closed from the internet?
The usual suspects are a firewall on the server or router, a missing port forward (NAT), or a process listening only on 127.0.0.1. ISP-level blocking happens too — port 25, for example, is often dropped by default to curb spam.
Which ports should be open on a typical web server?
Usually 80 (HTTP) and 443 (HTTPS) are enough, plus 22 (SSH) — ideally restricted to trusted addresses. Anything beyond that needs a specific justification; a database or RDP exposed to the public internet is asking for trouble.
Is it legal to check other people’s ports?
A single connection test against a public service is harmless and widely accepted. Systematic scanning of someone else’s infrastructure without permission may breach ISP terms of service and the law — test your own hosts, or ones you’re authorised to probe.
What should I do if port 443 on my site is closed?
Check, in order: whether the web server is running (systemctl status), whether it’s listening on the right address (netstat -tlnp), whether the firewall lets the traffic through (iptables/ufw rules or the firewall in your hosting panel), and whether the router has a port forward in place. Re-run the external test after every change.
Why does the result differ from what nmap shows?
The nmap scanner distinguishes more states (open, closed, filtered) and can probe UDP as well. Our test makes a single TCP connection attempt — it answers the practical question “is the service reachable from the internet”, without a full reconnaissance.
