Is this port open?
Check from 22 locations.

Test if a specific TCP or UDP port is open and accepting connections from 22 servers across 15 countries. See exactly where a service is reachable, blocked, or filtered — without having to set up VPNs or run scripts from multiple regions.

22 Monitoring nodes

15 Countries

< 2s Per check

$0 No account

Test if a specific TCP or UDP port is open and reachable from 22 worldwide locations. Enter any host plus a port between 1 and 65535 — results stream back per region in seconds.

Host

Port

Protocol

Try:

Note: All checks are public. To keep your checks private, create a free account.

Global Network Diagnostics

Run a check to see your service from around the world.

Tested from 22 monitoring locations worldwide
Results in seconds, not minutes
Shareable result links for your team
No account or signup required

What is a Port Check?

Every network service runs on a numbered port — a logical endpoint that lets your operating system route incoming connections to the correct application. Web servers listen on port 80 (HTTP) and 443 (HTTPS), SSH daemons on port 22, and databases on their own dedicated ports. When you run a port check, you test whether that endpoint is reachable from the outside world.

TCP vs UDP

TCP (Transmission Control Protocol) is connection-oriented. To check a TCP port, a tool initiates a three-way handshake (SYN → SYN-ACK → ACK). If the remote server completes the handshake, the port is open. If it sends back a RST (reset) packet, the port is closed. If there is no response at all, the port is likely filtered — blocked by a firewall before the packet ever reaches the service.

UDP (User Datagram Protocol) is connectionless and harder to test definitively. A UDP port check sends a datagram and waits for a response or an ICMP "port unreachable" message. Silence can mean the port is open and the service is running, or it may mean a firewall is silently dropping packets — context and protocol-aware probing usually help disambiguate.

Port States Explained

Every port check returns one of three results. Open means a service is actively listening on the port and accepted the connection — your application is reachable. Closed means the host responded but no service is listening — the port is accessible but not in use. Filtered means a firewall, security group, or ACL blocked the connection and no response was received within the timeout window.

Common Reasons to Check a Port

Verify a newly deployed service is accessible after configuring firewall rules. Troubleshoot why users cannot connect to a database or API endpoint. Confirm a VPN or hosting provider is not blocking specific ports. Test whether a service is reachable globally or only from certain regions. Validate that a security configuration correctly blocks unauthorized ports.

Three results, three completely different stories. Open means the service is alive. Closed means nothing's listening. Filtered means a firewall is in your way — and silence is the only signal you'll ever get.

A Real Port Scan, Up Close

The three port states make more sense when you see them at the same time. Below is what nmap prints when scanning a host with a mix of open services, blocked ports and unused ports — every state side-by-side, with colour coding that matches the traffic-light convention.

On the wire — what nmap -p 22,25,80,443,3306,8080 example.com prints

$ nmap -p 22,25,80,443,3306,8080 example.com
Starting Nmap 7.94 ( https://nmap.org )
Nmap scan report for example.com (93.184.216.34)
Host is up (0.024s latency).

PORT     STATE     SERVICE
22/tcp   filtered  ssh
25/tcp   filtered  smtp
80/tcp   open      http
443/tcp  open      https
3306/tcp closed    mysql
8080/tcp closed    http-proxy

Nmap done: 1 IP address scanned in 1.34 seconds

open — service is alive and accepted the connection closed — host replied but no service is listening filtered — firewall is blocking before the host can answer

The crucial distinction is between closed and filtered. A closed port means the host actively rejected the connection (TCP RST) — the host itself is reachable, just nothing is listening on that port. A filtered port means the packet never reached a service that could reject it; some intermediate firewall silently dropped it and Nmap is left waiting for a timeout. Both look like "the port doesn't work" from a browser, but they need completely different fixes.

In this scan, ports 22 and 25 are both filtered — typical for a server behind a corporate firewall that allows only HTTP/HTTPS through. Ports 80 and 443 are open — the web server is doing its job. Ports 3306 and 8080 are closed — MySQL and the alt-HTTP service simply aren't running on this host, but the host itself is reachable.

Common Ports Reference

Use this table as a quick reference when checking the most frequently used TCP and UDP ports for common services.

Port	Service	Protocol	Description
21	FTP	TCP	File Transfer Protocol — control channel for file transfers.
22	SSH	TCP	Secure Shell — encrypted remote login and command execution.
25	SMTP	TCP	Email sending — server-to-server mail transfer.
53	DNS	TCP / UDP	Domain Name System — hostname to IP address resolution.
80	HTTP	TCP	Web traffic — unencrypted hypertext transfer.
443	HTTPS	TCP	Secure web traffic — TLS-encrypted hypertext transfer.
3306	MySQL	TCP	MySQL database server connections.
5432	PostgreSQL	TCP	PostgreSQL database server connections.
6379	Redis	TCP	Redis in-memory data store and cache.
27017	MongoDB	TCP	MongoDB document database server connections.
8080	HTTP Alt	TCP	Alternative HTTP port — common for dev servers and proxies.
8443	HTTPS Alt	TCP	Alternative HTTPS port — common for application servers.

Why Check Ports From Multiple Locations?

A port that appears open from your office may be completely unreachable to users in other regions. Testing from a single location gives you an incomplete picture, and the failures it misses tend to be the most expensive: customers in one country quietly unable to reach your service while everything looks healthy from your laptop.

Multi-location port testing surfaces four distinct classes of issue:

Geo-blocking. Many organizations and cloud providers apply geo-based firewall rules that block traffic from specific countries or regions. A port can be wide open from the US and completely blocked from Asia or Europe — the kind of failure your domestic laptop will never reproduce.
ISP-level port blocking. ISPs in certain countries block specific ports by default. Port 25 (SMTP) is commonly blocked by residential ISPs worldwide to limit spam. Testing from multiple ISPs surfaces these restrictions before customers report mysteriously failing connections.
Asymmetric firewall rules. Firewalls frequently allow connections from known office or VPN IP ranges while silently dropping everything else. What works for you over the corporate VPN may be invisible to external users — the most insidious failure mode because it looks healthy from the only test you're running.
CDN & load-balancer routing. Anycast load balancers and CDN edges route traffic differently depending on source region. A port can be open on some edges but misconfigured or unavailable on others, causing intermittent failures only for users in specific locations.

Emercom runs all 22 port checks in parallel from geographically distributed nodes across North America, Europe, Asia Pacific, South America and the Middle East — full picture in seconds, no manual VPN dance.

Common Uses for Port Check

Port reachability sits at the intersection of operations and security — the question "is this port open from here?" drives very different workflows depending on who is asking:

Pre-Deploy Verification

Before announcing a new service, confirm the listening port is reachable from every region you serve. Catches misconfigured firewalls, missing security-group rules and ISP-level port blocks before users hit them. Cheaper than rolling back after an outage announcement.

Firewall Debugging

When users in one region report "cannot connect" while everyone else is fine, multi-location port checking pinpoints whether it's geo-blocking, an ISP-level filter, or asymmetric rules in your own firewall. The first answer in network triage: where exactly is the packet dying?

Compliance Audit

Verify that databases, admin interfaces, internal services and management ports are not reachable from the public internet. A scheduled scan across every endpoint produces audit evidence and catches accidental exposure the day it happens, not the day before the compliance review.

DDoS Surface Review

Enumerate which ports respond externally on every public-facing IP. Smaller attack surface = less to defend; finding stray dev-server ports or forgotten services exposed to the world is the cheapest hardening you'll do this quarter.

Port Check Myths That Won't Die

Ports are one of the oldest networking concepts still in daily use, and a lot of folk wisdom around them is wrong in load-bearing ways. Six assumptions worth retiring:

"Closed means safe."

Reality: A closed port still tells the outside world the host exists and is responding. Only filtered ports return nothing at all. From a security standpoint, "host is up but port not listening" is still useful reconnaissance — closed is not the same as invisible.

"Filtered means broken."

Reality: Filtered usually means the firewall is doing exactly what it's supposed to — silently dropping packets it didn't expect. Most production servers SHOULD have the majority of their ports filtered. A clean scan with three open ports and 65,532 filtered ones is healthier than the opposite.

"Open is always bad."

Reality: Open means a service is listening. That is the entire point of port 80, 443, 22 and everything else on this page. The real question isn't "is anything open" — it's "is the right thing open and properly authenticated." A web server with port 443 open is doing its job.

"Port 80 = HTTP, port 443 = HTTPS."

Reality: Ports are just integers. Nothing prevents a service from running HTTPS on port 80, plaintext HTTP on 443, or SSH on 8080. The numbers in the table above are conventions — strong, deeply entrenched conventions, but conventions. Always confirm what's actually listening, not what should be.

"Port checks tell you a service is healthy."

Reality: An open port means TCP accepted the connection — nothing more. It says nothing about whether the application is responsive, returning correct data, or running the right version. A misbehaving database can hold 3306 open while returning errors to every query. Use HTTP/protocol-level checks to verify the application layer.

"My firewall is on, so I'm safe."

Reality: Firewalls filter at the network layer. They don't catch SQL injection, deserialization bugs, weak auth, exposed APIs, or any application-level abuse on the ports they DO allow. An open port to a vulnerable service is still an attack surface — perimeter security is one layer, not the whole castle.

Frequently Asked Questions

Quick answers to the most common questions about port checks, scanning behaviour and the three port states.

What is the difference between open, closed, and filtered?

Open means a service is listening on the port and accepted the connection. Closed means the host responded but no service is listening — the host itself is reachable, just nothing on that port. Filtered means a firewall silently dropped the packet before it reached the service, so no response came back at all. Different problems, different fixes.

Why is port 25 (SMTP) blocked from my home internet?

Most residential ISPs block outgoing port 25 to prevent infected devices on their networks from sending spam. If you need to send outgoing mail from a residential connection, use port 587 (submission) with authentication via your mail provider, or port 465 for direct TLS. Server-to-server SMTP on 25 is generally only available from data centres and business connections.

Why does a UDP port check sometimes show ambiguous results?

UDP is connectionless — there is no handshake to confirm the port is open. A scanner sends a datagram and waits. Silence can mean either the service is listening but had nothing to reply, or a firewall silently dropped the packet. Both look identical from outside. Protocol-aware probing (e.g. sending a real DNS query to port 53) is the only reliable way to distinguish them.

Is it legal to scan ports on someone else's server?

Checking individual ports on a host you don't own is a grey area in most jurisdictions. Targeted checks for diagnostic purposes (e.g. testing whether you can connect) are generally tolerated, but enumeration-style scanning of many ports on a third-party host without permission may violate computer-misuse laws including the US CFAA and UK Computer Misuse Act — even if no exploit is attempted. When in doubt, get explicit permission.

What is the difference between a port check and a port scan?

A port check tests one or a few specific ports — a diagnostic action you take when you already know which service you are debugging. A port scan typically enumerates many ports (often all 65,536) to discover what is open on a host. Port checks are operational; port scans are reconnaissance and are sometimes restricted by acceptable-use policies.

Why does Emercom only support TCP and UDP?

TCP and UDP are the only widely deployed transport-layer protocols that use port numbers. SCTP and DCCP exist but are rare outside specific telco / streaming contexts. ICMP (used by ping) does not use ports at all — it operates at the network layer. For roughly 99% of services on the public internet, TCP/UDP covers everything.

Related Tools

More free network diagnostics, all running from the same 22-location footprint.