What Is a Port Scanner?
A port is a 16-bit number (0–65535) that identifies a specific process or service running on a host — port 443 for HTTPS, port 22 for SSH, port 53 for DNS. A port scanner systematically attempts connections to a set of these ports on a target IP address or hostname and records how each one responds, building a map of which services are exposed and reachable.
Network and security teams use port scanners for three main purposes: auditing your own exposure (confirming that only intended services are reachable from the internet), diagnosing connectivity failures (determining whether an unreachable service is a firewall block, a stopped process, or a routing issue), and penetration testing (mapping attack surface during an authorized security assessment). The scanner itself is a neutral diagnostic technique — its purpose and legality depend entirely on who runs it and against what target.
A scan against a single host checking a handful of well-known ports takes seconds. Scanning the full 65,535-port range, or scanning many hosts at once, takes proportionally longer and is far more likely to trigger intrusion detection systems, which is one reason most diagnostic scans — including the DNSnexus Port Scanner — check a curated list of common service ports rather than the entire range.
How Does a Port Scanner Work?
At the protocol level, TCP port scanning exploits the three-way handshake defined in RFC 9293 (the current TCP specification). A normal TCP connection starts when the client sends a SYN packet; if a service is listening, the server replies with SYN-ACK, and the client completes the handshake with ACK. A port scanner uses the server's response to this initial exchange — without necessarily completing it — to infer the port's state:
- Send a probe — a
SYNpacket for TCP scans, or a UDP datagram for UDP scans, directed at a specific port. - Read the response — a
SYN-ACKmeans a service is listening (open); aRST(reset) means the port is reachable but nothing is listening (closed); no response after retransmission attempts means a firewall or network device is silently dropping the packet (filtered). - Classify and repeat — the scanner records the state and moves to the next port, repeating across the full list being checked.
Per the official Nmap port scanning documentation, this three-way classification — open, closed, filtered — is the standard model every major scanning tool follows, whether it's a full-featured tool like Nmap or a lightweight browser-based checker.
Port States Reference Table
| State | What It Means | Typical Cause | What to Check |
|---|---|---|---|
| Open | A service actively accepted the connection | A process is listening on that port and reachable | Confirm this is intentional — an open port you don't recognize is an attack surface issue |
| Closed | The host responded but refused the connection (TCP RST) | No process is listening on that port, but the host itself is reachable | Normal for unused ports; not a firewall issue |
| Filtered | No response was received at all | A firewall, ACL, or security group is silently dropping packets to that port | Check firewall rules, security groups, or ISP-level blocking if you expect the port to be open |
| Unfiltered (rare, ACK scans) | The port is reachable but openness can't be determined | Used mainly to map firewall rule sets rather than find services | Requires a different scan type (ACK scan) to interpret |
| Open|Filtered (UDP) | No response — could be open or filtered | UDP doesn't require a reply, so silence is ambiguous | Send an application-specific probe or check the service directly |
A closed port confirms the host is reachable and simply isn't running that service — this is the normal, healthy state for the vast majority of ports on any server. A filtered port is the state to investigate when a service that should be reachable isn't responding, since it points to a firewall rule rather than the service itself being down.
Scan Types: SYN, Connect, and UDP
TCP SYN scan (also called a half-open scan) sends a SYN packet and, on receiving SYN-ACK, sends a RST instead of completing the handshake with ACK. Per Nmap's official documentation on the TCP SYN scan, this technique never establishes a full connection, making it faster and less likely to be logged by the target application — though it requires raw-packet privileges to construct the custom packet.
TCP connect scan completes the full three-way handshake using the operating system's normal connect() system call. Per Nmap's documentation on the TCP connect scan, this is the fallback used when raw-packet access isn't available — which includes every browser-based or server-side web tool, since those run through the OS network stack rather than crafting raw packets. The DNSnexus Port Scanner uses this connect-based approach, which is why its results reflect a fully-established connection state rather than a stealth probe.
UDP scan sends a UDP datagram to the target port. Because UDP is connectionless, a listening service may not reply at all even when open, and a closed port typically returns an ICMP "port unreachable" message. This ambiguity is why UDP scan results are frequently reported as "open|filtered" rather than a definitive state — the absence of a reply doesn't distinguish between a service silently accepting the packet and a firewall silently dropping it.
# TCP connect scan against common ports with Nmap (requires nmap installed)
nmap -sT -p 22,80,443 example.com
# TCP SYN (half-open) scan — requires root/raw-socket privileges
sudo nmap -sS -p 1-1000 example.com
The first command performs a standard connect scan against three named ports and works without elevated privileges. The second performs a SYN scan across the first 1,000 ports and requires root because it constructs raw TCP packets directly rather than going through the OS socket API.
Is Port Scanning Legal?
Port scanning your own infrastructure, or infrastructure you have explicit written authorization to test, is standard practice and not a legal issue. Per Nmap's own legal issues documentation, no United States federal law makes port scanning explicitly illegal, and the technical act of sending a probe packet to see whether a port responds is treated as legally neutral in most jurisdictions. What changes the legal picture is authorization and intent: scanning a system you don't own or have permission to test can implicate the Computer Fraud and Abuse Act (CFAA) if it's a precursor to unauthorized access, and some organizations' terms of service specifically prohibit scanning their infrastructure regardless of intent.
The practical rule: only scan hosts you own, or hosts where you have documented authorization (a signed penetration test scope, a bug bounty program's rules of engagement, or your employer's own infrastructure). Scanning third-party production systems without permission — even "just to check" — can trigger abuse reports from the target's ISP or hosting provider, independent of whether any law was actually broken.
Common Port Scanning Issues
Problem: Every port shows "filtered" instead of open or closed. Cause: a firewall (host-based, network, or cloud security group) is dropping all probe packets before they reach the service, rather than responding with a reset. Fix: check firewall/security-group rules for the target IP and port range, and confirm the scan isn't itself being blocked by an intermediate device (corporate proxy, VPN egress filtering).
Problem: A port scan from a cloud or hosted scanning tool shows different results than a scan run from your own network. Cause: firewall and security-group rules are frequently IP-allowlisted, so a port open to your office network can appear closed or filtered to an external scanner, and vice versa. Fix: run the scan from the vantage point that matters for your use case — an external tool like the Port Scanner tells you what the public internet sees, which is the relevant view for exposure audits.
Problem: UDP scan results are inconsistent between runs. Cause: UDP scanning relies on the absence of a response to infer state, and packet loss, rate-limited ICMP responses, or transient network conditions can change the outcome between scans. Fix: treat "open|filtered" UDP results as inconclusive and verify by testing the actual application-layer service (e.g., an actual DNS query to port 53) rather than relying on the scan alone.
Frequently Asked Questions
Q: What is the difference between a closed port and a filtered port?
A closed port means the host is reachable and actively responded with a TCP reset — no service is listening. A filtered port means no response was received at all, almost always because a firewall silently dropped the probe packet before it reached the host.
Q: Is port scanning illegal?
Scanning your own systems, or systems you have explicit authorization to test, is standard and legal practice. Scanning third-party systems without permission can implicate the CFAA in the US if it's a precursor to unauthorized access, and may violate the target network's terms of service regardless.
Q: What's the difference between a SYN scan and a connect scan?
A SYN scan sends a SYN packet and resets the connection before completing the handshake, requiring raw-packet privileges but leaving less of a trace in application logs. A connect scan completes the full three-way handshake through the OS's normal connection API, which is what browser-based and hosted scanning tools use.
Q: Why does my port show open on one scanner but filtered on another?
Firewall and security-group rules are frequently scoped to specific source IP ranges. A scanner running from a different network vantage point than your usual access point can see a completely different result for the same port.
Q: Can a port scan crash a server or service?
A standard connect or SYN scan against common ports is extremely unlikely to affect a properly configured service — it's functionally identical to a normal connection attempt. Aggressive full-range scans or scans combined with exploit payloads are a different category of activity and are not what a diagnostic port scanner performs.
Q: What ports should never show as open on a public-facing server?
Administrative and internal-service ports — RDP (3389), unencrypted database ports (3306, 5432, 27017, 6379), and Telnet (23) — should never be reachable from the public internet. See the Common Network Ports Reference for the full table of high-risk ports.
Related Guides
- Common Network Ports: The Complete Reference Table
- Home Network Security: A Practical Hardening Guide
- What Is a Network Security Key?
Next Steps
Run a live check against your own domain with the Port Scanner tool to see open, closed, and filtered states in practice. If a service you expect to be reachable shows filtered, cross-check network path issues with Online Traceroute or confirm basic host reachability with Ping. For the full reference of which ports map to which services — and which should never be exposed — see the Common Network Ports Reference guide.