How to Check If a Port Is Open on Your Server

To check whether a port is open, test it from outside the network. Enter the hostname or IP and the port into an external port checker: if a TCP connection completes, the port is open and reachable. Testing from the server itself only proves a service is listening locally, not that anyone can reach it.

What does an open port actually mean?

A port is a number that identifies which service on a machine a connection is meant for. The IP address gets traffic to the host; the port decides which program receives it. "Open" means something accepted a TCP connection on that number and the network between you and it allowed the attempt through.

Three distinct conditions have to hold, and conflating them is the root of most confusion:

A process must be listening on the port. If nothing is bound to port 443, nothing can answer on it.

The host's own firewall must permit the traffic. The service can be running perfectly while the local firewall silently discards packets.

Everything in between must permit it too. Cloud security groups, network ACLs, upstream firewalls and your provider's filtering all sit on the path, and any one of them can drop the connection.

An external checker tests all three at once, which is exactly why it is useful. It reports the answer to the only question that matters in production: can a real client out on the internet actually connect?

Open, closed, and filtered are three different answers

A closed port actively refuses the connection: something at the other end responds that nothing is there, and you learn this quickly. A filtered port says nothing at all, so your connection attempt sits until it times out. That difference is diagnostically valuable. A fast refusal usually means the host is reachable and no service is listening. A slow timeout usually means a firewall is dropping packets before they reach the host at all.

Watch the response time for this reason. The open port checker reports how long the attempt took alongside the result, and a check that returns near the timeout limit is a strong hint you are looking at a firewall rule rather than a stopped service.

How do I check a port from outside my network?

Enter the hostname or IP address and the port, and run the check. The tool resolves the hostname, attempts a TCP connection from an external server with a short timeout, and reports open or closed along with the response time. It also offers a scan of common ports if you want a broader picture of one host.

Two constraints worth knowing. It tests TCP, so UDP services such as DNS and plain WireGuard will not show up meaningfully: UDP has no connection handshake to complete, which is why a connect test cannot confirm it. And it will not test private or reserved address ranges, since a request from an external server cannot meaningfully reach your 192.168.x.x machine anyway.

Why not just check on the server itself?

Because a local check answers a different question. Running a listening-socket command on the host tells you a process is bound to the port. It tells you nothing about whether the firewall, the cloud security group, or your ISP lets anyone reach it. Plenty of outages come down to a service running correctly behind a rule nobody remembered.

Use both, in order. Confirm locally that something is listening, then confirm externally that it is reachable. When the local check passes and the external one fails, you have narrowed the problem to the network path, which is the single most useful thing you can learn in the first minute of an outage.

One subtlety that bites people: what address a service is bound to. A process listening only on 127.0.0.1 is reachable from the machine itself and from nowhere else, which looks like a firewall problem but is a configuration problem. If your local check shows the service bound to the loopback address rather than all interfaces, fix that before touching firewall rules.

Which ports should you expect to be open?

Port assignments are coordinated by IANA in its service names and port numbers registry, which is the authoritative list when you encounter an unfamiliar number.

Read the right-hand column carefully, because it is the part that matters. Finding 3306 or 6379 open to the internet is not a success, it is a finding. Databases and caches exposed publicly have been exploited at scale, particularly where they shipped with no authentication by default. If an external check shows a database port open, close it: bind the service to a private interface, restrict it with firewall rules, and reach it through a VPN or an SSH tunnel instead.

The useful habit is to check what is open and ask whether each one needs to be. An open port is attack surface, and surface you did not intend is the kind that goes unpatched.

Why does my port check say closed when the service is running?

Work down this list, roughly in order of how often each is the culprit.

A cloud security group or firewall rule is blocking it. On AWS, Azure, Google Cloud and most VPS providers, there is a network-level rule set separate from the operating system firewall. Both must allow the traffic. This is the most common cause by a wide margin, and people miss it because the host firewall looks correct.

The host firewall is blocking it. Check whatever your distribution uses, and remember that rule order matters: a permissive rule placed after a broad deny rule never takes effect.

The service is bound to the loopback address only. Covered above, and easy to misdiagnose as a network issue.

Your ISP or provider blocks the port. Residential connections commonly block inbound 80, 443 and 25, and many hosting providers block outbound 25 by default to limit spam. No amount of local configuration overrides this.

You are testing the wrong address. A domain behind a proxy or CDN resolves to the proxy's address, not your origin server, so you are testing the proxy. A stale DNS record points at an old host. Check what the hostname actually resolves to before concluding anything.

NAT or port forwarding is incomplete. On a home or office network, the router must forward the port to the right internal machine, and that mapping has to specify the correct internal IP, which breaks when the device's DHCP lease changes.

The service crashed or has not finished starting. Worth ruling out early with a local listening check, especially after a deployment.

IPv4 versus IPv6. A host with both may have a service listening on one and not the other, with firewall rules that differ between the two stacks. A checker connecting over one protocol can report closed while the other works.

How should you use these results responsibly?

Check hosts you own or administer, or ones you have permission to test. Testing your own server's reachability is routine administration. Scanning infrastructure belonging to other people is a different activity: unauthorised scanning is prohibited by most providers' acceptable use policies, and depending on jurisdiction and intent it can carry legal consequences. The tool here performs a single connection attempt to a port you specify, which is what a legitimate reachability check needs and nothing more.

Finding a port open on someone else's server is not an invitation. If you discover an exposed database belonging to an organisation, the constructive response is to report it through their security contact, not to connect to it.

finduid.net is not affiliated with any hosting or cloud provider, and the port checker needs no login. If you are working through server and account security generally, the TOTP code generator and the tool guides are nearby.

Frequently Asked Questions

Why does a port show closed even though my firewall allows it?

Most often because a second rule set is also in play. Cloud providers enforce network-level security groups independently of the operating system firewall, and both must permit the traffic. Other candidates are the service being bound to 127.0.0.1 only, or your hosting provider blocking that port upstream.

Can I check a UDP port with a TCP port checker?

No. UDP is connectionless, so there is no handshake for a connect test to complete, and a TCP checker cannot confirm a UDP service. Checking UDP reliably requires sending a protocol-specific probe and interpreting the reply, which is why DNS and some VPN services need different tooling.

Is it legal to scan ports on a server I don't own?

Testing hosts you own or administer, or have permission to test, is routine. Unauthorised scanning of other people's infrastructure breaches most providers' acceptable use policies and can carry legal consequences depending on jurisdiction and intent. If you find an exposed service, report it to the owner rather than connecting.

Should port 3306 be open to the internet?

Almost never. A publicly reachable MySQL port is attack surface for credential-stuffing and exploitation, and exposed databases have been breached at scale. Bind the database to a private interface, restrict access with firewall rules, and connect through a VPN or SSH tunnel from your application servers instead.

Why is my check slow for one port and instant for another?

A closed port usually refuses the connection immediately, so you get a fast answer. A filtered port drops packets silently, so your attempt waits for the timeout. A near-timeout result therefore suggests a firewall discarding traffic rather than a host with no service listening.

Can I check a port on my local network or home computer?

Not from an external checker, because private and reserved address ranges are not reachable from the internet and are rejected by design. To test a machine behind a router from outside, you need its public IP plus a port-forwarding rule. For purely internal testing, run a check from another machine on the same network.