VMware ESXi and vSphere Cluster Management
Adjust Delay Between Nmap Probes with --scan-delay
Learn how Nmap's --scan-delay option paces probes, affects scan time and accuracy, and differs from --max-scan-delay and -T timing templates.
Use Nmap timing controls only on systems and networks you own or are explicitly authorized to test. Adding a delay can reduce traffic and help protect fragile systems, but it also makes scans take longer and does not guarantee complete or conclusive results.
Why Control Probe Timing?
Nmap is a network discovery and security auditing tool. It sends probes—packets or requests used to learn about hosts, ports, and services. Probes may be used during host discovery, port scanning, service detection, and related scan activity.
By default, Nmap adapts its timing to observed network conditions. If responses arrive quickly, it may proceed faster; if packets are delayed or lost, it can wait and retransmit. An explicit delay reduces the rate at which applicable probes are sent to a host.
Slowing an authorized scan can be useful when:
- A fragile device might be disrupted by a high probe rate.
- A firewall, intrusion-prevention system, or service uses rate limiting, meaning it restricts how frequently requests or packets are accepted or answered.
- A congested or sensitive network needs a lower scanning load.
- You want a controlled test that is less likely to resemble a burst of traffic.
Pacing is not a substitute for authorization or careful scope. It changes how quickly Nmap works, not whether the activity is permitted.
The --scan-delay Option
--scan-delay specifies a minimum interval between probes sent to an individual host. Its general form is:
nmap --scan-delay <time> <target>Time values can use units such as milliseconds and seconds:
250msmeans 250 milliseconds.2smeans 2 seconds.- A larger value creates a more conservative probe pace.
You can combine the option with a scan type, a port list, a target range, and other Nmap settings:
nmap --scan-delay <time> -p <ports> <target>The configured interval can substantially lengthen a scan. The effect becomes especially noticeable when scanning many ports or multiple hosts.
Reading a Paced Scan Command
nmap --scan-delay 10s -p 21,22,80,135 192.168.5.102This command has four important parts:
nmapstarts the program.--scan-delay 10srequests at least 10 seconds between applicable probes sent to the target host.-p 21,22,80,135selects four TCP ports: FTP, SSH, HTTP, and Microsoft RPC-associated TCP port 135.192.168.5.102is an example private IPv4 address. Replace it only with an authorized target.
A simple planning estimate might multiply the number of selected ports by the delay. For four ports and a 10-second interval, that suggests roughly 40 seconds of probe spacing. It is only an estimate, not a promised runtime. Nmap may also perform host discovery, wait for responses, handle timeouts and retransmissions, and perform scan setup and teardown work.
A Millisecond-Based Example
nmap --scan-delay 250ms -sS -p 80,443 192.168.5.102Here, 250ms sets a quarter-second minimum interval between applicable probes. This is slower than an unrestricted scan but much less extreme than a multi-second delay. The -sS option requests a TCP SYN scan, which may require appropriate privileges or operating-system capabilities for raw-packet operations.
A delay applies to pacing, not to the meaning of the selected ports. Ports 80 and 443 are still scanned as requested, and the scan can still report their observed port states.
How Delay Relates to Nmap Timing
Nmap normally adapts timing based on latency, responses, packet loss, and other network conditions. Latency is the time required for traffic to travel and for a response to be observed. A configured --scan-delay imposes a pacing floor, so faster adaptive behavior cannot send the relevant probes more quickly than that minimum.
--max-scan-delay has a different purpose. It limits how large Nmap's adaptive delay may become; it does not request the same fixed minimum pause between every applicable probe.
| Option | Primary effect | Typical value format | When to use | Key caution |
|---|---|---|---|---|
--scan-delay | Sets a minimum interval between probes to an individual host. | 250ms, 2s | Reduce probe rate for a sensitive or rate-limited authorized target. | Can make scans much longer. |
--max-scan-delay | Caps Nmap's adaptive delay. | 1s | Prevent adaptive waits from growing beyond an operational limit. | It is not a fixed pause after every probe; an overly low cap can reduce reliability. |
-T timing templates | Selects a preset profile that changes several timing behaviors. | -T3, -T4 | Use a broad timing profile when its tradeoffs are understood. | It is not equivalent to one explicit inter-probe delay. |
Timing templates and explicit delay options can interact. A command that combines them should be tested in the intended environment rather than assumed to behave like either setting in isolation.
Choosing an Appropriate Delay
| Delay range | Relative probe rate | Expected runtime impact | Appropriate authorized use case |
|---|---|---|---|
| No explicit delay | Fastest potential pacing, subject to Nmap's normal adaptation. | Usually shortest, but network conditions still control the result. | Routine checks on systems approved for normal scanning load. |
| Tens to hundreds of milliseconds | Moderately reduced rate. | Often adds measurable time while retaining practical throughput. | Small service checks, congested links, or targets that need gentler pacing. |
| One or more seconds | Very slow probe rate. | Can make broad port ranges or many targets impractical. | Highly sensitive devices, documented rate-limit requirements, or narrowly scoped validation. |
Start with a modest delay and increase it only when there is a documented operational reason. A large per-probe delay is usually unsuitable for a full port range or a large target list. Begin with a small, authorized test scan, observe its effect, and then decide whether the same setting is appropriate for the larger assessment.
Interpreting Results and Runtime
Nmap commonly reports these port states:
- Open: an application appears to be accepting connections or responding on the port.
- Closed: the host is reachable, but no application appears to be listening on that port.
- Filtered: a firewall or other filtering device prevents Nmap from determining the port state reliably.
A deliberately slowed scan can still identify these states. Slowing the scan does not change a filtered port into an open or closed one, and it does not guarantee that every probe receives a response.
To compare timing settings, run the same authorized target and port list while changing only the delay:
nmap -p 21,22,80,135 192.168.5.102
nmap --scan-delay 2s -p 21,22,80,135 192.168.5.102Compare the final elapsed-time summaries and the reported port states. Preserve the command, target scope, output, and date for each run. Elapsed time is not necessarily equal to the number of ports multiplied by the delay because host discovery, response latency, timeouts, retries, scan type, and other Nmap work also contribute.
Factors That Change Actual Scan Time
| Factor | How it affects duration | How to verify or respond |
|---|---|---|
| Host discovery | Nmap may spend time determining whether a host appears reachable before or during scanning. | Review the command and verbose output; keep discovery behavior consistent when comparing runs. |
| Network latency | Slow responses increase waiting time even when probe spacing is configured. | Compare results in the intended environment and account for observed response times. |
| Packet loss and retransmissions | Nmap may repeat probes when earlier probes do not receive expected responses. | Use measured, authorized settings and correlate with network monitoring where possible. |
| Port count | More selected ports create more probe opportunities and increase the effect of a per-host delay. | Test a narrow port list before scanning a broad range. |
| Multiple targets | Total work grows with the target count; Nmap's per-host pacing does not necessarily make all activity strictly sequential. | Plan for aggregate traffic and completion time rather than multiplying one-host results alone. |
| Firewall filtering | Suppressed responses can cause waits, retries, and filtered classifications. | Correlate results with authorized firewall and service telemetry. |
Operational Limitations
Slow scanning reduces the sending rate, but it does not guarantee that all packets arrive, all responses are returned, or all results are conclusive. Firewalls may filter traffic, services may be unstable or rate-limited, and packet loss may cause retransmissions. A delay applied per host also does not necessarily make a multi-host scan strictly sequential in every dimension of Nmap's operation.
When comparing normal and paced scans, keep the target, port selection, scan type, discovery settings, and relevant timing options consistent. Save the output from each run. Differences in network conditions can otherwise be mistaken for differences caused by the delay.
Using --max-scan-delay Correctly
nmap --max-scan-delay 1s -p 1-100 192.168.5.102This command limits Nmap's adaptive delay to one second. It does not mean that Nmap waits exactly one second between every probe. The option is useful when adaptive waits become excessive, but aggressively constraining timing can harm reliability on high-latency or lossy networks.
Troubleshooting
The scan takes much longer than expected
Confirm the delay value and suffix, and check whether a large interval is being applied to many ports. Host discovery, response waits, and retransmissions may add further time. Try a smaller port scope for a test run, review the elapsed-time summary and verbose output, and reduce the delay only if the authorized operational requirement permits it.
The duration is not exactly port count multiplied by the delay
That multiplication is only a rough estimate of probe spacing. Nmap also performs discovery and scan-control work, and actual responses, timeouts, retries, and scan type affect the total. Compare two runs with the same target and port list while changing only the delay.
The delay is rejected or behaves unexpectedly
Use explicit syntax such as 250ms or 2s. Check the locally installed version's help and manual page:
nmap --help | grep -E "scan-delay|max-scan-delay"Also verify whether you need a fixed minimum pace (--scan-delay) or a cap on adaptive waiting (--max-scan-delay).
Ports appear filtered or responses are inconsistent
Filtering, packet loss, high latency, or a rate-limited or unstable service may be responsible. Confirm the scope, repeat a narrowly scoped scan at a measured timing setting, and correlate the findings with authorized firewall, service, and network monitoring data.
A SYN scan fails because of permissions
The operating system may not permit raw-packet operations for the current user. Use the privileges or platform configuration required for the approved Nmap task, or choose an appropriate non-raw scan type when that is suitable.
Practical Checklist
- Confirm ownership, authorization, and scan scope.
- Choose a small target and port set for the first test.
- Start with a modest delay, such as a value measured in hundreds of milliseconds.
- Record the complete command and save the output.
- Compare elapsed time, port states, and operational impact with an unpaced or differently paced run.
- Increase the delay only when the results and operational requirement justify it.
- Do not interpret a slow scan as proof that filtered or missing responses are conclusive.
For related study, review Nmap probe-delay controls alongside host discovery, port selection, scan types, retransmission behavior, and interpretation of open, closed, and filtered ports.