Nmap Timing Options: Scan Speed, Accuracy, and Timing Templates
Learn how Nmap timing templates from -T0 to -T5 affect scan speed, retries, accuracy, and operational safety, with practical comparison and troubleshooting guidance.
Nmap timing options control how quickly a scan sends probes, waits for responses, retries unanswered probes, and schedules work across hosts. The right setting helps you balance scan duration, result quality, and the operational impact on an authorized target or network.
This lesson assumes familiarity with basic Nmap syntax, IP addresses, ports, and common port states. Perform every scan only against systems and networks for which you have explicit authorization.
Why Scan Timing Matters
Port scanning is often the most time-consuming part of an Nmap assessment. Nmap may need to test many ports, wait for responses, and retry probes that appear to have been lost. A scan that is fast on a local network can take much longer across a congested or high-latency path.
Latency is the delay between sending a probe and receiving its response. Packet loss occurs when a probe or its response fails to reach the other endpoint. Firewalls may silently drop packets, devices may rate-limit responses, and an overloaded target may respond slowly. Each condition can increase retransmissions and total scan time.
Timing therefore involves a trade-off:
- A faster scan completes sooner and may reduce waiting time.
- A slower scan allows more time for delayed responses and retries.
- An aggressive scan can produce incomplete or less reliable results on an imperfect network.
- A conservative scan can be more complete, but may take substantially longer.
Nmap Timing Templates
The -T option selects a timing template, which is an Nmap preset that adjusts multiple timing-related behaviors. It is not merely a fixed delay between packets. A template can influence probe scheduling, parallelism, timeout assumptions, retransmission behavior, and related performance settings.
The numeric range is -T0 through -T5. Lower numbers are more conservative; higher numbers are more aggressive. -T3, named normal, is Nmap's general-purpose default.
| Option | Template Name | Relative Speed | Typical Use Case | Reliability and Operational Considerations |
|---|---|---|---|---|
-T0 | paranoid | Extremely slow | Exceptional cases requiring very conservative operation | Minimizes scan intensity but can take a very long time. It is not a normal choice for routine inventory. |
-T1 | sneaky | Very slow | Highly cautious, authorized assessments | Reduces intensity and increases duration. It does not guarantee that monitoring systems will not notice the scan. |
-T2 | polite | Slow | Fragile systems, low-bandwidth links, high-latency paths, or impact-sensitive work | Allows a more measured scan and can improve stability where aggressive probing causes loss or overload. |
-T3 | normal | Balanced | Ordinary authorized scans | Nmap's default general-purpose timing. A useful baseline for comparison. |
-T4 | aggressive | Fast | Responsive modern systems and reliable local or well-connected networks | Often practical when the scope permits it, but verify that results remain consistent. |
-T5 | insane | Extremely fast | Controlled tests in exceptionally reliable, low-latency environments | Highly aggressive. Shorter waits and fewer retransmission opportunities make incomplete results more likely on imperfect paths. |
What the Template Names Do Not Mean
The names are shorthand for groups of internal timing and retransmission-related settings. They do not mean that every probe is sent at one simple, fixed interval. Nmap also adapts some behavior based on observed round-trip time and network conditions.
Choosing a Timing Template
Use -T2 When Operational Impact Matters
-T2 may be appropriate for fragile systems, legacy equipment, low-bandwidth links, high-latency paths, or environments where minimizing traffic is more important than completing quickly. It can also be useful as a validation setting after a fast scan produces an important or questionable result.
nmap -T2 192.168.5.102Record the elapsed time and the counts of open, closed, and filtered ports. This establishes a conservative reference result.
Use -T3 as the Normal Baseline
-T3 is the default timing template, so explicitly specifying it is usually unnecessary:
nmap -T3 192.168.5.102It is a practical starting point for ordinary authorized scans. Begin here unless the engagement plan or observed network behavior suggests a slower or faster profile.
Use -T4 on Reliable Networks
-T4 is a common choice for responsive, modern local networks and well-connected targets when the assessment scope permits faster probing. Monitor packet loss, target behavior, and result consistency rather than assuming that faster is always better.
nmap -T4 192.168.5.102Use -T5 Only in Carefully Validated Conditions
-T5 is highly aggressive. Limit it to exceptionally reliable, low-latency environments such as a controlled lab or a carefully approved test segment. Validate its results against a more conservative scan before treating a missing port as definitive.
nmap -T5 192.168.5.102Speed Versus Result Quality
Aggressive timing reduces waiting and may reduce the number of opportunities Nmap has to retransmit an unanswered probe. If packets are delayed, dropped, throttled, or blocked by an intermediate device, a fast scan may classify a port as filtered or fail to report a response that a slower scan would receive.
A slower scan gives responses more time to arrive and can permit additional retries. This may produce a more complete result, especially over a lossy or high-latency path.
For the same target, different timing templates can report different numbers of open, closed, and filtered ports. A port missing from one output is not proof that the port is unavailable. It may indicate that Nmap did not receive enough evidence to classify it during that run.
Treat a rapid scan as potentially incomplete when the target or path is uncertain. Validate important findings with a narrower, more conservative follow-up scan.
Reading Timing-Related Scan Output
Elapsed Time
Nmap normally prints a completion line containing the elapsed scan time. Compare this line between runs that use the same target, ports, scan type, and other options. A meaningful comparison changes only the timing profile whenever possible.
Exact durations vary with target load, route conditions, filtering, packet loss, and the time of day. A faster result is useful only if its port and service findings are sufficiently consistent.
Open, Closed, and Filtered States
- Open: An application is accepting connections or responding according to the scan type.
- Closed: The port is reachable, but no service is listening according to the scan type.
- Filtered: Filtering or a lack of response prevents Nmap from determining whether the port is open.
Timing differences are especially visible in filtered counts. A short timeout can turn delayed or dropped responses into filtered results, while a slower run may receive enough information to classify some of those ports differently. For a broader explanation, see Nmap port states and how to interpret scan results.
Retransmission-Cap Warnings
A retransmission is a probe sent again after Nmap receives no response within the expected period. A retransmission cap limits how many retries Nmap will make. If Nmap reports that it is giving up after reaching a retransmission cap, unanswered probes may have been lost, filtered, delayed, or affected by an overly aggressive profile.
This warning does not automatically prove that a port is closed. Lower the timing level, narrow the port scope, and validate the affected result.
Controlled Timing Comparison
Use the same authorized lab target and equivalent scan parameters for both runs. The following commands use the default port scope for a simple comparison:
nmap -T2 192.168.5.102
nmap -T5 192.168.5.102For each run, record the command, target, date and time, elapsed duration, open/closed/filtered totals, reported services, warnings, and relevant network conditions. Do not compare results if the target changed, services changed, or other scan options differ without documenting those differences.
| Setting | Target Scope | Elapsed Time | Open Ports Reported | Closed Ports Reported | Filtered Ports Reported | Warnings | Interpretation |
|---|---|---|---|---|---|---|---|
-T2 | Authorized lab host, same ports and scan type | Record from output | Record from output | Record from output | Record from output | Record any retransmission messages | Conservative reference; often slower and potentially more tolerant of delay or loss. |
-T5 | Same authorized lab host and equivalent scope | Record from output | Record from output | Record from output | Record from output | Check for retransmission-cap warnings | Fast comparison; discrepancies or additional filtered results require validation. |
| Note | Environment-dependent | Varies | Varies | Varies | Varies | Varies | Exact timings and results depend on latency, loss, filtering, and target behavior. |
A useful workflow is to start at -T3, observe latency and loss, then move to -T2 if reliability or operational safety is a concern. Consider -T4 only when the network is responsive and the engagement permits it. Use -T5 only after controlled validation.
Packet Tracing for Timing Diagnosis
Packet tracing is verbose diagnostic output showing probes Nmap sends and packets it receives. It can help determine whether a missing result is associated with latency, packet loss, filtering, retransmission limits, or rate limiting.
nmap -T5 --packet-trace -p 21,80,443 192.168.5.102Keep the port list narrow because packet traces can be very verbose. Look for the following patterns:
- A probe is sent and a response arrives only after a long delay: the path may have high latency.
- A probe is sent repeatedly without a response: packets may be lost or filtered, or the target may be rate-limiting.
- A response appears during a slower run but not during the fast run: the aggressive profile may have stopped waiting too soon.
- Replies arrive consistently but classification differs: compare scan type and other options before blaming timing.
Repeat the small test at a lower timing level and compare the traces. See Nmap packet tracing for related diagnostic use.
Timing Templates Versus Granular Timing Controls
-T is a convenient preset. Nmap also provides explicit controls for cases where measured network conditions require more precise tuning. Manual changes should be made one at a time, documented, and tested against a known baseline.
| Control | General Role |
|---|---|
--min-hostgroup, --max-hostgroup | Set lower or upper bounds for groups of hosts scanned together. |
--min-parallelism, --max-parallelism | Control the number of probes that may be outstanding in parallel. |
--min-rtt-timeout, --max-rtt-timeout | Set lower and upper bounds for round-trip-time response timeouts. |
--initial-rtt-timeout | Set the starting estimate used while Nmap learns response timing. |
--max-retries | Limit retransmissions for probes that receive no response. |
--host-timeout | Stop work on a host after a specified maximum duration. |
--scan-delay, --max-scan-delay | Control the delay between probes, including a maximum adaptive delay. |
For example, these commands illustrate explicit retry, timeout, and pacing controls:
nmap --max-retries 5 --max-rtt-timeout 1000ms 192.168.5.102
nmap --scan-delay 100ms 192.168.5.102These values are examples, not universal recommendations. Increasing retries or timeouts can improve tolerance of delay but also extend scan duration. Reducing them can make a scan finish sooner while increasing the chance of incomplete results.
Host-group and parallelism settings affect how Nmap schedules work across hosts. RTT and retry settings affect how it waits for and repeats probes. Scan-delay settings affect pacing between probes. Host discovery is a related but distinct stage: discovery options determine how Nmap decides whether a host appears online, while port-scan timing controls the subsequent port-probing behavior. Review host discovery and probe delay when tuning those stages separately.
Common Timing Problems and Responses
| Symptom | Likely Cause | Recommended Next Step |
|---|---|---|
| Retransmission cap reached | The target did not answer in time, probes or replies were dropped, or timing is too aggressive. | Lower the timing template, narrow the port scope, and validate the individual port. Increase retry or timeout values only when measured conditions justify it. |
| Many filtered ports at high timing levels | Shorter waits, packet loss, filtering, or target rate limiting. | Repeat with -T2 or -T3; compare a small set with --packet-trace. |
| Inconsistent port results across runs | Latency, loss, changing services, load, rate limiting, or different scan parameters. | Keep parameters equivalent, reduce scope, repeat at a conservative timing level, and document network conditions. |
| Scan takes unexpectedly long | Conservative timing, a large scope, slow links, packet loss, or many filtered ports. | Confirm scope, use -T3 as a measured baseline, and split large authorized jobs into manageable segments. |
| Target or network appears overloaded | Scan rate is too high for the target, legacy equipment, resource constraints, or sensitive infrastructure in scope. | Stop or reduce intensity according to the engagement plan, use a narrower scope, and coordinate with system owners. |
Example: Fast Scan Reports Fewer Open Ports
Suppose a -T5 scan completes quickly but reports fewer open ports than a -T2 run. Possible causes include delayed responses, packet loss, fewer retries, rate limiting, or an intermediate filtering device.
- Repeat only the affected ports with
-T2or-T3. - Use a narrow packet trace to inspect probes, replies, and retries.
- Check whether the path is congested or high latency.
- Compare services and target state to ensure the target did not actually change.
- Document the discrepancy instead of immediately concluding that the fast scan is correct or that the target changed.
nmap -T2 -p 80,443 192.168.5.102Documenting a Reproducible Timing Choice
A timing result is easier to evaluate when another tester can reproduce it. Record:
- Target addresses and authorized scope.
- Scan type, port list or range, and all relevant Nmap options.
- Timing template and any granular timing controls.
- Start time, elapsed duration, and Nmap version.
- Open, closed, and filtered totals, reported services, and warnings.
- Observed latency, packet loss, congestion, rate limiting, and target load.
- Whether the target or services changed between comparisons.
Store output using an approved format and location; consistent output handling supports later comparison. Important findings should have a conservative validation run attached to the assessment record.
Responsible and Safe Operation
Scan only systems and networks covered by explicit authorization. High scan rates can stress network devices, trigger rate limits, increase firewall logs and alerts, or produce unreliable results. Legacy and resource-constrained hosts may be especially sensitive.
Coordinate timing with maintenance windows, assessment scope, service owners, and stakeholder requirements. If users report performance problems or a target appears unstable, stop or reduce the scan according to the rules of engagement. Operational safety and trustworthy results are more important than finishing a scan quickly.
Exam-Relevant Notes
-T0through-T5are Nmap timing templates, not simple fixed-delay switches.-T3is the normal default.- Lower values are slower and more conservative; higher values are faster and more aggressive.
- Aggressive timing can reduce wait and retry opportunities, causing delayed or lost responses to appear as filtered or absent.
- A missing port in one result does not prove that the port is unavailable.
- Retransmission-cap warnings indicate that Nmap stopped retrying an unanswered probe after reaching its configured limit.
- Use
--packet-traceon a small authorized scope to diagnose probe, response, and retry behavior. - Use granular controls only after understanding measured latency, loss, filtering, and target behavior.
Summary
Nmap timing is a balance between speed, completeness, and operational safety. Start with -T3 for a normal authorized scan, use -T2 when reliability or low impact matters, and consider -T4 only on responsive networks where faster scanning is approved. Reserve -T5 for carefully controlled, reliable environments.
When results differ, compare elapsed time, port-state totals, services, warnings, and packet behavior. Validate important findings with a narrower and more conservative scan, and document the conditions well enough for the result to be reproduced.