Understand Nmap --reason Output

Learn how Nmap --reason explains host and port states using responses such as SYN-ACK, reset, no-response, TTL, and latency.

Nmap normally reports whether a host appears up and whether a TCP port is open, closed, or filtered. It may not show the packet evidence behind those classifications. The --reason option adds that evidence to the output.

This makes scan results easier to validate and troubleshoot. You can see whether a port was marked open because of a SYN-ACK, closed because of a TCP reset, or filtered because no decisive reply was observed.

What the --reason Option Does

--reason tells Nmap to display the observed reason behind host and port state determinations. The reason is based on the selected scan technique, the packets sent and received, and Nmap's timeout and classification rules.

For example, normal output might show:

80/tcp open  http

With reason reporting, the row may include evidence similar to:

80/tcp open  http  syn-ack ttl 64

The exact formatting and wording can vary by Nmap version and scan type. The important distinction is that the second result tells you what response supported the open classification.

Host discovery: shows why Nmap decided that a target appears reachable.
Port scanning: shows why an individual port was classified as open, closed, or filtered.
Diagnostics: helps distinguish an actual reset from silence, and helps identify possible filtering or packet-loss conditions.

For background on interpreting states, see Nmap port states and interpreting Nmap scan results.

Basic Command Usage

Add --reason anywhere in the command's option list. This example scans a private laboratory host that the operator is authorized to test:

nmap --reason 192.168.56.10

A TCP SYN scan can be made explicit with -sS:

nmap -sS --reason 192.168.56.10

You can limit the demonstration to selected ports:

nmap -p 21,53,80,514 --reason 192.168.56.10

A timing template is independent of reason reporting. For example, -T4 requests faster timing while --reason requests additional explanation:

nmap -T4 --reason 192.168.56.10

-T4 is not required for --reason. Faster timing can increase traffic, affect timeout behavior, and reduce reliability on congested or heavily filtered networks. Choose timing for the environment rather than assuming that faster is always better. See Nmap timing options and adjusting the delay between probes.

Host-State Reasoning

Host discovery is Nmap's process for deciding whether a target appears reachable before or during scanning. A host can be considered up even when none of its tested application ports are open.

With reason reporting, a host status line may look similar to this:

Host is up, received syn-ack ttl 64 (0.0031s latency).

This says that Nmap received a SYN-ACK during the relevant discovery or scan exchange. That response demonstrates that the target, or a device responding on its behalf, is reachable and participating in TCP. The line may include:

Response type: such as a SYN-ACK, reset, or another discovery reply.
TTL: the observed IP Time To Live value in the reply.
Latency: the measured communication time associated with the reply.

A TCP reset can also establish reachability in an appropriate discovery context. For example, a host that receives a TCP probe for a port where no service is listening may respond with RST. The reset proves that a packet reached a responding TCP stack and that a reply returned to the scanner.

Do not confuse this host evidence with port evidence. The host-up line answers, “Did something respond in a way that suggests this target is reachable?” A port row answers, “What does the response to the port-specific probe suggest about this port?”

Output location	Information shown	How to interpret it
Host status line	Reachability response, TTL, and sometimes latency	Evidence that the target appears up; it does not say that every port is available.
Aggregate hidden-port summary	A count of ports sharing a state and reason	Many equivalent results may be grouped instead of printed one by one.
Per-port result row	Port, state, service label, and reason	Evidence supporting the classification of that particular port.
TTL and latency details	Observed packet metadata and timing	Useful context about the path and response, but not conclusive identity information.

Port-State Reasoning in a TCP SYN Scan

A TCP SYN scan sends a SYN, the TCP connection-start packet. It interprets the response without completing a normal application connection.

SYN-ACK Usually Means Open

If a listening service receives the SYN, it normally responds with SYN-ACK. Nmap uses that response to classify the port as open:

80/tcp open  http  syn-ack ttl 64

The SYN-ACK indicates that a TCP service is willing to continue the handshake. Nmap then typically sends a reset to avoid completing the connection.

Reset Usually Means Closed

If no service is listening on the tested port, the TCP stack commonly responds with RST, also called a reset. In the relevant TCP scan context, that supports a closed classification:

23/tcp closed  telnet  reset ttl 64

Closed does not mean unreachable. It usually means that the host or another responding device was reachable, but no listening service accepted the probe on that port.

No Response Can Mean Filtered

If Nmap receives no decisive response within its timeout behavior, it may classify the port as filtered:

514/tcp filtered shell  no-response

No-response is an observation, not proof of a particular firewall product or rule. A firewall, host filter, routing problem, rate limit, asymmetric path, or packet loss can all suppress a reply.

Observed reason	Typical port or host interpretation	What it means	Important caveat
SYN-ACK received	Port is typically open	A TCP listener responded as if it would continue the handshake.	A middlebox or proxy could generate the response, so verify unusual results.
Reset received	Port is typically closed; may also establish host reachability	A TCP stack actively rejected the probe.	It identifies a response behavior, not necessarily the final host responsible.
No response	Port may be filtered	Nmap did not observe a conclusive reply before its timeout behavior.	Silence can also result from packet loss, routing issues, or rate limiting.
Host-up reply indication	Target appears reachable	A discovery response, such as a reset or SYN-ACK in a suitable context, came back.	Host reachability does not imply that any particular port is open.

Reading Reason-Enhanced Output

A typical port result contains several components:

PORT     STATE     SERVICE  REASON
22/tcp   open      ssh      syn-ack ttl 64
23/tcp   closed    telnet   reset ttl 64
514/tcp  filtered  shell    no-response

PORT: the port number and transport protocol, such as 22/tcp.
STATE: Nmap's classification, such as open, closed, or filtered.
SERVICE: a name associated with the port or a name identified through service detection.
REASON: the observed response or lack of response that contributed to the state.

In a normal scan, Nmap may group ports that are not listed individually:

Not shown: 997 closed tcp ports (reset)

This means 997 ports were classified as closed and shared a reset-based reason. It is an aggregate summary, not evidence that every port produced a byte-for-byte identical packet in every field.

Service labels are hints, not proof of the application. For example, http beside port 80 may come from the conventional port assignment rather than an application banner. Use authorized service and version detection when the actual application matters. See determine service version.

Separating Reachability from Port Availability

Consider this simplified result:

Host is up, received reset ttl 64 (0.0020s latency).
Not shown: 998 closed tcp ports (reset)
80/tcp  open  http  syn-ack ttl 64
443/tcp filtered https no-response

The host-up reason shows that the target responded to reachability testing. The port reasons provide separate conclusions:

Port 80 is open because it returned SYN-ACK.
Port 443 is filtered because no conclusive response was observed.
The other 998 tested ports were closed because they returned resets.

An alive host can therefore have a mixture of open, closed, and filtered ports.

Interpretation Limits

Reasons are meaningful only in scan context. The selected technique, target operating behavior, network path, and filtering devices all affect which packets Nmap receives.

Middleboxes: firewalls, load balancers, proxies, and intrusion-prevention devices may answer, alter, or discard probes.
Rate limiting: a host may respond to some probes but suppress later ones.
Asymmetric routing: replies may take a different path or fail to return to the scanner.
Packet loss and congestion: silence does not distinguish filtering from a lost packet by itself.
Host firewalls: local rules may reset some traffic and silently drop other traffic.

TTL is useful observational metadata. It can provide clues about the path or packet behavior, but it is not a reliable operating-system determination by itself. Do not infer a particular operating system solely from a TTL value. For a dedicated operating-system assessment, see determine operating system.

When a result is important, confirm it with an appropriate repeat scan, a suitable scan type, authorized packet capture, or service/version detection. A packet trace can show whether probes left the scanner and whether replies returned; see Nmap packet trace.

Troubleshooting Common Results

Filtered with no-response

Symptom: A port is listed as filtered and the reason is no-response.

Likely interpretation: A filtering device, host firewall, routing issue, rate limit, or packet loss may be preventing a decisive reply.

Repeat the scan with an appropriate authorized timing setting.
Check firewall and routing policy in the test environment.
Compare with another scan type only when authorized and when it addresses a specific question.
Use packet capture to determine whether probes and replies traverse the expected path.

Host up but nearly all ports closed

Likely interpretation: The target responded to reachability testing, while most scanned TCP ports had no listening services and returned resets.

Review the aggregate closed-port reason.
Confirm that the intended port range was scanned.
Verify expected services directly on the authorized target.

Unexpected service label

A service name may be based on a conventional port assignment rather than verified application identification. Treat the reason as state evidence, not service proof. Use authorized version detection or application validation to confirm the service.

Results vary between scans

Changing reason strings can result from congestion, stateful filtering, rate limiting, changing host conditions, packet loss, or timing choices.

Compare reason strings across repeated runs.
Reduce scan speed when appropriate.
Inspect relevant network and firewall logs in the authorized environment.

Safe Operating Practices

Scan only systems and networks for which you have explicit authorization. Keep the target scope narrow while testing, especially when investigating a single port or firewall policy.

In production environments, choose conservative timing and avoid unnecessary port ranges. A faster timing template such as -T4 changes pacing and timeout behavior; it does not change the purpose of --reason, but it can affect network load and result reliability.

Practical Comparison

Run the same authorized lab scan normally and then with reason reporting:

nmap -p 21,53,80,514 192.168.56.10
nmap -p 21,53,80,514 --reason 192.168.56.10

The first command emphasizes the final states. The second adds the response-level clues that explain those states. Use the difference to practice connecting TCP behavior with Nmap classifications:

SYN-ACK supports open.
RST supports closed.
No observed reply can contribute to filtered.
A host-up reason describes reachability, not the state of every port.

Key Takeaways

--reason exposes the observed response or lack of response behind Nmap's host and port states.
A SYN-ACK normally supports an open TCP port in a SYN-style scan.
A TCP reset generally supports a closed port and can demonstrate host reachability.
No-response can produce filtered, but silence does not prove a specific firewall or rule.
TTL and latency add context but do not conclusively identify a host or operating system.
Interpret reason strings together with the scan technique and network conditions.
Repeat and validate important findings with suitable scans, packet capture, and service detection where authorized.