Port Scanner Guide: Check Open Ports and Audit Network Security

Every service your server exposes to the network does so through a port. Web servers, databases, mail relays, remote desktops, and SSH daemons all listen on specific port numbers, waiting for incoming connections. A port scanner is the tool you use to discover which of those doors are open, closed, or hidden behind a firewall. Whether you are hardening a production server, debugging a Docker compose stack, or auditing your home network, port scanning is one of the most fundamental skills in networking and security operations.

In this guide we explain how port scanning works, walk through the ports every developer should recognize, show you how to use our Port Scanner tool, and lay out the legal and ethical boundaries you must respect before you scan anything.

What Is a Port Scanner?

A port scanner is a network utility that probes a target host (identified by an IP address or hostname) to determine which network ports are open and accepting connections. Instead of guessing which services a server runs, a port scanner systematically asks each port, "Are you there?" and records the response.

To understand port scanning, you first need to understand ports themselves. When two computers communicate over an IP network, the IP address gets the packet to the right machine, but the port number determines which application or service on that machine should handle it. Ports are logical endpoints numbered from 0 to 65535. They are divided into three ranges:

• Well-known ports (0 to 1023): Reserved for system-level services like HTTP (80), HTTPS (443), and SSH (22).
• Registered ports (1024 to 49151): Assigned to specific applications by IANA, such as PostgreSQL (5432) and Redis (6379).
• Dynamic or ephemeral ports (49152 to 65535): Used temporarily by clients for outbound connections.

Ports operate over two main transport protocols:

• TCP (Transmission Control Protocol): Connection-oriented and reliable. A TCP connection uses a three-way handshake (SYN, SYN-ACK, ACK) before data flows. Most application services—web, mail, SSH, databases—use TCP.
• UDP (User Datagram Protocol): Connectionless and faster but without delivery guarantees. UDP is used for DNS lookups, DHCP, streaming media, and online gaming.

Scanning TCP ports is straightforward because the protocol responds predictably. Scanning UDP ports is harder, because silence does not necessarily mean closed—services may simply ignore malformed requests, leading to ambiguous results.

Why Scan Ports?

Port scanning is a core activity across several disciplines. Here are the most common reasons to scan ports.

Security Auditing

Every open port is a potential attack surface. A misconfigured server might expose an administrative interface, an unpatched database, or a forgotten FTP server to the internet. By scanning your own hosts, you discover what attackers would discover, giving you the chance to close unnecessary ports before someone else finds them.

Service Discovery

In dynamic environments—Kubernetes clusters, cloud auto-scaling groups, on-prem networks—you often need to know which services are running on which hosts. A port scan quickly maps the topology: which nodes run PostgreSQL, which expose Redis, which host a web server.

Troubleshooting Connectivity

When an application cannot reach a database or API, the first diagnostic question is often "Is the port even open?" A port scan answers that instantly, separating network-level problems (firewall blocking, service down, wrong host) from application-level problems (bad credentials, malformed requests).

Firewall and Access Control Verification

After writing firewall rules, the only reliable way to confirm they work is to test them from the outside. A port scan from a remote host tells you whether your rules actually permit or block the intended traffic.

Infrastructure Inventory

During acquisitions, migrations, or audits, engineers frequently inherit networks they do not fully understand. Scanning helps build an accurate inventory of live hosts and the services they expose, forming a baseline for documentation and planning.

Common Ports You Should Know

Below is a reference table of the most frequently scanned ports. Memorizing this list makes interpreting scan results dramatically faster.

When you scan a host and see port 22, 80, and 3306 open, you can confidently infer the host runs SSH, a web server, and a MySQL database. This kind of rapid inference is the real power of knowing common ports.

How Port Scanning Works

Port scanning relies on the fact that TCP and UDP define clear rules for how a host should respond to connection attempts. By analyzing those responses, a scanner classifies each port into one of several states.

Port States

• Open: An application is actively listening on the port and accepting connections. On TCP, the host responds to a connection request with a SYN-ACK packet. This is the most interesting state for security and service discovery.
• Closed: The host responds, typically with a TCP RST (reset) packet, indicating that no application is listening on the port but the host itself is reachable. Closed ports confirm the host is alive.
• Filtered: The host or a network device in between (such as a firewall) drops the probe packets, producing no response. You cannot tell whether a service is listening behind the filter. Filtered ports are common on well-secured networks.
• Unfiltered: The port is reachable, but the scanner cannot determine whether it is open or closed. This is rare and usually requires an ACK scan to detect.
• Open or Filtered / Closed or Filtered: Ambiguous states that arise with protocols (like UDP) where silence could mean either state.

TCP Connect Scan

A TCP connect scan completes the full three-way handshake:

1. The scanner sends a SYN packet to the target port.
2. If the port is open, the target replies with SYN-ACK.
3. The scanner completes the handshake by sending ACK, then tears down the connection.

Because it establishes a real connection, this method works on any system that supports standard sockets and requires no special privileges. The trade-off is that the connection is logged by the target application, making it noisy and easy to detect. Our browser-based Port Scanner uses this approach because it is reliable and universally compatible.

SYN Scan (Half-Open Scan)

A SYN scan, sometimes called a "half-open" scan, sends the initial SYN packet but never completes the handshake:

1. The scanner sends SYN.
2. If the target responds with SYN-ACK, the scanner sends a RST to abort the connection instead of completing it.

Because the connection is never established, the listening application never sees it, and it is usually not logged. SYN scans are faster and stealthier than connect scans, but they require raw socket access (typically root or administrator privileges) and are not possible directly from a browser sandbox.

UDP Scanning

UDP is stateless, so scanning it is slower and less reliable. The scanner sends a UDP packet to a port and waits for a response:

• An ICMP port unreachable error means the port is closed.
• A UDP response means the port is open.
• Silence could mean the port is open (the service ignored the probe) or filtered by a firewall.

Because of this ambiguity, UDP scans often produce uncertain results and take much longer than TCP scans, since the scanner must wait for timeouts on silent ports.

How to Use Our Port Scanner

Our Port Scanner runs entirely in your browser and is designed for quick, safe checks of hosts you manage. Follow these steps:

1. Open the tool. Navigate to the Port Scanner page.
2. Enter the target host. Type a hostname (such as example.com) or an IP address (such as 192.168.1.1). Only scan hosts you own or have explicit permission to test.
3. Choose the ports to scan. You can scan a predefined set of common ports, specify a custom list, or enter a port range such as 1-1024 to scan the well-known range.
4. Start the scan. Click the scan button. The tool sends TCP connection probes to each port and reports the result in real time.
5. Review the results. Each port is displayed with its state—open, closed, or filtered—along with the identified service name where possible.
6. Act on the findings. Close ports you do not need, lock down services behind a firewall, or verify that a newly deployed service is reachable.

The tool is especially handy for checking whether a home lab server, a cloud VM, or a local Docker container is exposing the ports you expect. Because it runs in the browser, there is nothing to install and no command line required.

Use Cases

DevOps Service Health Checks

After deploying a new service, run a quick scan to confirm the expected ports are listening. If you deployed a web application and a database, scanning for ports 443 and 5432 confirms both came up correctly. This is faster than wiring up a full health check pipeline during early development.

Developer Local-Stack Verification

When spinning up a local stack with Docker Compose—say, an API on 8080, PostgreSQL on 5432, and Redis on 6379—a port scan instantly confirms all three containers bound their ports correctly. It catches mistakes like a service binding to 127.0.0.1 only, or a port conflict where two containers claim the same host port.

Security Audits

Before putting a server on the public internet, scan it from an external network to see exactly what is exposed. Any unexpected open port is a finding that needs investigation. Compare scan results over time to detect configuration drift, such as an admin port that was opened temporarily and never closed.

Firewall Testing

After writing rules for a cloud security group or an on-prem firewall, scan the host from the outside to confirm only the intended ports are reachable. If a port you meant to block still shows as open, your rule has a gap.

Home Network Inventory

Home networks accumulate devices—routers, printers, IoT gadgets, security cameras, smart TVs—many of which expose services you might not know about. Scanning your own LAN (such as the 192.168.1.0/24 range) reveals what is listening, helping you disable unused services and tighten device security. Use our Subnet Calculator to identify your LAN range and our IP Range Calculator to enumerate the addresses.

Best Practices

Port scanning is powerful, and using it well means following a few disciplined practices.

• Scan only hosts you own or are authorized to scan. This is the single most important rule. Unauthorized scanning can be illegal and is covered in detail in the next section.
• Document your scans. Record the date, target, ports scanned, and results. This creates a baseline you can compare against later and provides evidence of due diligence during audits.
• Understand false negatives. Firewalls, rate limiting, and network latency can all cause a scanner to report a port as closed or filtered when it is actually open. Treat scan results as one data point, not absolute truth, and verify critical findings with a direct connection test.
• Scan from multiple vantage points. A port that appears closed from inside your network may be open from the internet. For accurate external exposure analysis, scan from outside the firewall using a host on a different network.
• Combine with other tools. Port scanning tells you a port is open, but not whether the service is secure. Pair it with our HTTP Headers Viewer to inspect web server security headers, the API Endpoint Tester to probe API behavior, and the WHOIS Lookup to research domain ownership and registration.
• Automate recurring scans. For production systems, schedule regular scans and alert on changes. A new open port appearing unexpectedly is often the first sign of a misconfiguration or compromise.
• Respect rate limits and resources. Aggressive scanning can overwhelm small devices or trigger intrusion detection systems. Start with a measured scan rate and increase only if you control the target and the network.

Legal and Ethical Considerations

Port scanning occupies a legally sensitive space, and the rules vary by jurisdiction. The following principles apply broadly.

Unauthorized scanning is illegal. In many countries, scanning a system you do not own or have permission to test can constitute unauthorized access or attempted intrusion under computer crime laws, even if you do not exploit anything. Examples include the Computer Fraud and Abuse Act in the United States and the Computer Misuse Act in the United Kingdom. Some ISPs also prohibit scanning in their acceptable use policies.

Only scan systems you own or have written permission to test. Legitimate use cases include:

• Your own servers, virtual machines, and containers.
• Your home network and the devices you control on it.
• Systems covered by a penetration testing agreement or bug bounty scope, with documented authorization.
• Cloud resources in accounts you own or administer.

Authorization should be explicit and documented. A vague "go ahead" is not enough for sensitive engagements. For professional security work, use a signed scope-of-work document that names the target IP ranges, the allowed testing window, and the permitted techniques.

Be transparent. If you are scanning a shared environment such as a corporate network or a hosting provider, notify the relevant operations or security team beforehand so your activity is not mistaken for an attack.

Respect the spirit of the law, not just the letter. Even where scanning is technically legal, pointing aggressive scans at third-party infrastructure without consent is unethical and can still result in civil liability or service termination. When in doubt, do not scan.

Our Port Scanner is intended for checking your own systems and learning how network services behave. Use it responsibly.

Related Tools

Port scanning is part of a broader networking and security toolkit. These companion tools on Online Tools Forge help you investigate further:

• IP Range Calculator — Convert CIDR notation into a list of IP addresses so you know exactly which hosts fall within a scanning range.
• Subnet Calculator — Plan and verify subnet divisions, useful for structuring scans across a network.
• WHOIS Lookup — Research domain registration and ownership details for the hosts you are investigating.
• HTTP Headers Viewer — Once you find an open web port, inspect its HTTP response headers for security configuration issues.
• API Endpoint Tester — Probe REST and API endpoints discovered on open ports to verify behavior and authentication.

Conclusion

Port scanning is a foundational skill for anyone who builds, deploys, or secures networked software. It turns the invisible question "what is my server exposing?" into a concrete, actionable answer. By understanding port states, recognizing common service ports, and combining scans with complementary tools, you gain a clear picture of your network's attack surface and can close gaps before they become incidents.

Remember the golden rule: scan only what you own or are explicitly authorized to test. Used responsibly, a port scanner is one of the most valuable diagnostic instruments in your kit.

Ready to check your own servers? Open our Port Scanner and start a scan against a host you control today.

Updated: August 2026 | Reading time: 10 minutes