Understanding Nmap Port States

Learn what Nmap open, closed, filtered, unfiltered, open|filtered, and closed|filtered states mean and how to interpret scan results responsibly.

Nmap port states describe how a target responds when Nmap sends probes to specific network ports. A port is a numbered communication endpoint associated with a transport protocol such as TCP or UDP. A port scan sends probes to selected ports and evaluates the responses.

The reported state is Nmap's interpretation of the evidence it observed from the scanner's network position. It is not an absolute guarantee about the service's condition. Firewalls, routing, scan technique, timing, and target behavior can all affect the result.

Finding reachable services is a central goal of most port scans. Once a reachable port is identified, an authorized administrator or tester can investigate the service, its configuration, and its security posture.

Prerequisites: ports, listeners, and probes

A listener is an application or service waiting to accept network traffic on a port. A probe is a packet or connection attempt Nmap uses to test a port.

TCP is connection-oriented and commonly provides response patterns that make open and closed classifications relatively clear. UDP is connectionless, and many UDP services do not reply to an unexpected datagram. That silence often produces an ambiguous result.

The six Nmap port states

Open

An open port has an application or service accepting connections or datagrams on the scanned port. The result suggests that the port is reachable from the scanner's location.

Open does not identify the exact application, version, configuration, or security posture by itself. For authorized follow-up work, use service and version detection, then perform an approved vulnerability assessment where appropriate. See Determine Service Version.

Closed

A closed port is reachable, but no application appears to be listening on it. The target produced enough of a response for Nmap to determine that the host and port can be reached.

Closed does not mean that the host is offline. It usually means that the tested protocol and port combination is reachable but has no current listener.

Filtered

Filtered means Nmap cannot determine whether the port is open because packet filtering prevents the expected response from being observed. A firewall, packet filter, access-control list, NAT device, or another network control may be involved.

A filter may silently drop probes, block responses, or return behavior that does not provide enough evidence for a definitive classification. Filtered does not prove that a service is listening behind the filter.

Unfiltered

Unfiltered means the port is reachable, but the scan method in use cannot determine whether it is open or closed. This state is associated with scan techniques that establish reachability without conclusively testing whether an application is listening.

A different, appropriate scan type is needed to classify the port as open or closed. The meaning depends on the technique used, so always interpret the state together with the scan command.

Open|filtered

Open|filtered is an ambiguous result. Nmap cannot distinguish between an open port and a filtered port. A common cause is receiving no response: the service might accept a probe silently, or a filter might discard it.

This state is frequently encountered during UDP scanning because UDP services may not respond to probes. Targeted protocol-aware verification, an alternative scan method, packet capture, or permitted firewall logs may help narrow the result.

Closed|filtered

Closed|filtered means Nmap cannot distinguish between a closed port and a filtered port. This state is uncommon and depends on the scan technique and the target's response behavior.

Do not interpret closed|filtered as confirmation that a service is available. It is an inconclusive result requiring context or follow-up testing.

Nmap port states at a glance

State	What Nmap observed	What can be concluded	What cannot be concluded	Typical next step
open	Evidence indicates that the port accepts traffic.	A reachable service appears to be listening.	The exact application, version, configuration, or security posture.	Authorized service and version detection, followed by approved assessment.
closed	The target responded, but no listener was detected.	The port and host are reachable.	That the host is offline or that no service exists elsewhere.	Verify the intended port, protocol, interface, and service configuration.
filtered	Filtering prevented a decisive response.	A firewall or other control may be blocking observation.	Whether a service is listening behind the filter.	Review authorized firewall rules, logs, paths, and packet captures.
unfiltered	The port is reachable, but this scan cannot test listener status conclusively.	Traffic can reach the port.	Whether the port is open or closed.	Use an appropriate follow-up scan method.
open\|filtered	No decisive response distinguished acceptance from filtering.	Either an application is silently accepting traffic or filtering is present.	Which of those explanations is correct.	Use protocol-aware verification, another scan method, packet capture, or logs.
closed\|filtered	The response behavior fits either a closed or filtered port.	The result is ambiguous and scan-method-dependent.	That a service is available.	Validate with an authorized scan and target-side evidence.

Definitive versus ambiguous results

Open and closed are generally more definitive because Nmap received evidence supporting those classifications. The other states involve incomplete or inconclusive evidence, or depend strongly on the scan method.

Classification group	States	Reason for confidence or ambiguity	Validation approach
More definitive observations	open, closed	Nmap observed response behavior that supports a listener or no-listener conclusion.	Confirm the service and listening sockets on the authorized target.
Ambiguous or scan-method-dependent observations	filtered, unfiltered, open\|filtered, closed\|filtered	Filtering, silence, or the selected technique prevents a complete classification.	Compare approved scan types and locations; review firewall or service logs and use packet capture where permitted.

A port's observed state can vary with scanner location, protocol, scan type, firewall rules, timing, routing, NAT, load balancers, and target behavior. The same port may appear open from one network and filtered from another.

Basic commands for reading states

Run these examples only against an authorized target. The default scan demonstrates common TCP state output:

nmap <target>

To focus on a small set of ports, specify them explicitly:

nmap -p 22,53,80,443 <target>

UDP scanning often produces open|filtered results when no response is received:

nmap -sU <target>

A TCP SYN scan can provide a different classification view for authorized testing and normally requires elevated privileges:

sudo nmap -sS <target>

For broader output interpretation, see Interpret Scan Results, and for packet-level evidence see Packet Trace.

Practical examples

Reachable web service

A TCP web port is reported as open. This indicates that a service is accepting traffic on that port from the scanner's location. It does not establish which web server is running or whether it is safely configured. Authorized service identification can provide more detail.

Reachable host without a service on the tested port

A TCP port is reported as closed. The target responded, but no application is listening on that port. The host is reachable even though that particular service endpoint is not active.

Firewall silently drops probes

A port is reported as filtered. A filtering device or rule likely prevented Nmap from obtaining enough evidence to classify the port as open or closed. This result does not reveal whether a service exists behind the filter.

UDP service discovery

A UDP port is reported as open|filtered after no response. The service may have accepted the datagram without replying, or a filter may have discarded the probe or response. Network loss and rate limiting are additional possibilities.

Follow-up classification

An initial scan reports unfiltered. The port can be reached, but that scan method did not establish whether an application is listening. A suitable follow-up scan is required.

Troubleshooting port-state results

Many or all ports appear filtered

A host or perimeter firewall may be dropping probes.
Restrictive network controls may separate the scanner and target.
Rate limiting or intrusion prevention may be suppressing responses.
The scanner's network location may not be allowed by policy.

First confirm authorization and scope. Then, where approved, compare results from another network position, review applicable firewall rules or logs, and use packet capture to determine whether probes or responses are being dropped.

A UDP port appears open|filtered

The UDP service may not reply to the probe.
A packet filter may silently discard the probe or response.
Network loss or rate limiting may prevent an observable response.

Use targeted, protocol-aware verification in an authorized environment and examine packet-level behavior or service logs.

An expected service appears closed

The application may be stopped.
The application may listen on another port.
The service may bind only to a different interface or address family.
The target address, port number, or protocol may be incorrect.

On an authorized target, check listening sockets and service configuration. Then verify the address, port, and whether the service uses TCP or UDP.

Results differ between locations or scan types

Firewall rules may vary by source network, scan techniques may elicit different responses, and load balancers, NAT devices, routing paths, timing, or rate controls may alter observations. Record the scanner location, scan type, timing, and target path, then compare results under controlled and authorized conditions.

Responsible interpretation

Port states describe reachability and response behavior, not permission to access a system. An open result is an observation that a service appears reachable; it is not authorization to connect beyond the approved test scope.

Validate ambiguous findings before making operational decisions such as changing firewall rules, declaring a service exposed, or treating a host as unreachable. Combine Nmap output with service configuration, firewall logs, packet captures, and other approved evidence.