Port Checker

What a port check tells you

Ports let one machine run many services on one address. A port check opens a TCP connection to one of them and reports what happened. Because the connection comes from outside your network, it answers a question you cannot answer from your own machine: is this service actually reachable from the internet?

How the check is actually performed

IPGet's server resolves the name you gave it, picks one of the resulting public addresses, and opens a TCP connection to that address on that port. It then records what happened and destroys the socket. It never sends a payload, never reads response data, never speaks HTTP or SSH or anything else, and never follows a redirect — because none of that is needed to answer the question, and all of it would make the tool something other than a reachability check.

Two consequences follow from that, and both matter when you read the result. The check is TCP only: there is no UDP test here, and a browser form claiming to test UDP reachability is worth treating with suspicion. And the connection is made from one machine, in one datacentre, over one network path — so the result describes whether the port is reachable from us, which is a good proxy for "from the internet" but is not identical to it.

The result also shows the address that was actually connected to, and every public address the name resolved to. That is there so the answer is verifiable rather than something you have to take on trust: if a name resolves to four addresses and only one is listening, you can see it.

The five result states, and what each one means

Most port checkers collapse everything that is not open into "closed". IPGet does not, because the states are genuinely different facts about the host and they lead to different fixes.

The distinction between timeout and closed is the one worth internalising. A closed port means the host is up, reachable, and actively told us nothing is listening — a TCP reset came back. A timeout means nothing came back at all, which a firewall configured to drop rather than reject produces, and which is indistinguishable from the host being switched off entirely. Dropping is far more common than refusing on real infrastructure, so timeout is the usual result for a port that is not open. Reporting it as "closed" would be telling you something we did not observe.

Open does not mean working, and it does not mean safe

An open port means one thing precisely: a TCP connection was accepted. It does not mean the service behind it is healthy, correctly configured, serving the right content, or running the software you think it is. A web server that accepts connections on 443 and then fails every TLS handshake will show as open here — use the SSL checker to see what it actually presents, and the HTTP headers checker to see what it actually serves.

Nor does open mean insecure. Ports 80 and 443 are open on essentially every website on the internet and that is exactly correct. What matters is whether a port is open that you did not intend to expose — a database on 3306 or 5432, a management interface on 8006, a remote desktop on 3389 reachable from the whole internet rather than from a VPN. Those are the results worth acting on.

Common ports

Why a port shows as closed

1. The service is bound to localhost. A process listening on 127.0.0.1 is unreachable from outside no matter what the firewall says. Bind to 0.0.0.0 or a specific external interface.
2. A host firewall is blocking it. Check ufw, firewalld or the cloud provider's security group — cloud instances usually have two layers.
3. No port forwarding. On a home connection the router must forward the port to the correct internal device.
4. Carrier-grade NAT. If your provider shares one public address across many customers, inbound connections cannot reach you and no amount of configuration will fix it. See the IPv4 checker for how to tell.
5. The provider blocks the port. Ports 25, 80 and 445 are commonly blocked on residential connections.

Which ports can be checked, and why it is a list

The checker accepts 38 ports rather than the full range of 65,535. Those are the ports people actually need to diagnose — the table above covers the common ones — and the restriction is deliberate rather than an oversight.

A tool that connects to any port on any host, on demand, from a server that is not yours, is a port scanner with a web interface. Offering that would make IPGet a way to probe other people's infrastructure anonymously through a third party, and it would get this server's address onto abuse blocklists within days — at which point every other tool on the site starts failing for everybody. The allowlist is what keeps a genuinely useful diagnostic from becoming scanner-as-a-service.

If you need to test a port outside the list, the check belongs on a machine you control: nc -vz host port from a shell on a different network answers the same question without involving anyone else's server.

What this check cannot tell you

Being explicit about the limits is more useful than implying there are none.

• It is one vantage point. If the host blocks our address specifically, or routes by geography, or is behind a firewall with per-source rules, you will see a timeout while the service works perfectly from where you are sitting. A result that contradicts your own experience is usually this.
• It cannot test your own machine directly. Private and reserved addresses are refused outright, so 192.168.1.10 or localhost will not be checked. To test a device on your own network from outside, check your public address and the forwarded port.
• It is TCP only. DNS on 53, game servers, VPN protocols such as WireGuard and many VoIP services use UDP, and UDP has no equivalent of a connection to accept or refuse. Port 53 appears in the list because DNS also runs over TCP; a timeout there does not mean UDP DNS is broken.
• It does not identify the software. No banner is read and no protocol is spoken, so the tool cannot tell you which server is listening or what version it runs.
• A single check is a moment in time. An intermittent result — open once, timeout the next minute — usually points at rate limiting, a failing health check or an overloaded service, and is worth more attention than a consistently closed port.

How IPGet keeps this safe

A feature that makes a server connect to an address a stranger supplies is a server-side request forgery primitive. Pointed carelessly it can reach private networks, localhost, or cloud metadata endpoints such as 169.254.169.254, which on an unprotected instance can hand out credentials.

The checker therefore does all of the following on every request:

• Validates the hostname and refuses internal-only names outright.
• Resolves the name itself and checks every returned address. If any one of them is private, loopback, link-local, carrier-NAT, multicast or reserved, the whole request is refused — not just that address — so a zone mixing a public and a private record cannot be used to reach the private one.
• Connects to the resolved address, never to the hostname. Handing the name to the socket would resolve it a second time, and someone controlling that zone could answer with a public address for the check and 127.0.0.1 a moment later. That is DNS rebinding, and pinning the validated address is the only reliable defence against it.
• Speaks no protocol and reads no data. The socket is closed the instant the connection settles, so nothing is ever fetched from the target.
• Applies a short timeout, per-address rate limits, and a fixed allowlist of well-known service ports — an unrestricted range would make this a port scanner.
• Returns a state only. No errno, no network-stack message, nothing that would describe our own infrastructure.

Please only check hosts you own or administer. Probing third-party systems without permission may breach computer-misuse law where you live, and is against our terms of service.