Nmap online course

Adjust Delay Between Nmap Probes with --scan-delay

Learn how Nmap's --scan-delay option controls the pause between probes, affects scan duration, and differs from timing templates and rate controls.

Nmap sends probes—packets or packet sequences used to learn whether hosts, ports, or services respond—during a scan. A port scan tests network ports and reports a port state, such as open, closed, or filtered.

The scan delay is an enforced waiting interval between probes directed at a particular target host. Nmap's --scan-delay option lets you set that interval explicitly.

Why control the delay between probes?

A rapid scan can produce a relatively intense burst of traffic. An operator may deliberately reduce the pace to lower traffic intensity, accommodate fragile services or congested networks, or fit an assessment within an agreed operational profile.

A delay can also moderate the likelihood of immediate detection, but it is not an evasion guarantee. Monitoring systems may recognize connection attempts and scan patterns even when probes are separated by seconds or minutes.

How --scan-delay works

The long-form syntax is:

nmap --scan-delay <time> [scan options] <target>

The <time> argument specifies the fixed pause between applicable probes. Nmap time values can use human-readable suffixes such as ms for milliseconds, s for seconds, m for minutes, and h for hours where supported by the installed Nmap version.

The delay applies per target host. It does not create one single global pause that stops all activity across every target in a multi-host scan. Nmap may also perform other work, and its scan engine can operate on hosts in parallel.

Basic command placement

Place --scan-delay among the scan options. Port-selection options such as -p can be used with it. A target can be an IP address, hostname, or authorized range.

nmap --scan-delay <time> -p <port-list> <authorized-target>

The documentation addresses below use reserved example networks. Replace them only with systems in an authorized lab or approved assessment scope.

Practical examples

Apply a ten-second delay to a short TCP scan

nmap --scan-delay 10s -p 21,22,80,135 192.0.2.10

• -p 21,22,80,135 selects four TCP ports.
• --scan-delay 10s requests an approximately ten-second interval between applicable probes for that target.
• The scan should take substantially longer than the same command without the delay.
• Actual runtime can exceed a simple estimate of four ports multiplied by ten seconds.

Use milliseconds for a smaller fixed pause

nmap --scan-delay 500ms -p 80,443 198.51.100.20

The ms suffix means milliseconds, so 500ms is half a second. Even a half-second pause can add considerable time when many ports or hosts are included.

Compare an unchanged scan with a delayed scan

nmap -p 22,80,443 192.0.2.10
nmap --scan-delay 2s -p 22,80,443 192.0.2.10

Run both commands only in an authorized lab. Keep the target and port list unchanged, then compare elapsed times. Different results do not necessarily mean that a port state changed; network conditions and timing can affect observations.

Delay units and expected effect

Understanding scan duration

A fixed delay adds elapsed time as the number of probes increases. A small, explicit port list makes the relationship easier to observe, because there are fewer other scan activities competing for attention.

Runtime is not exactly the delay multiplied by the visible port count. Nmap may spend time on host discovery, DNS resolution, network response latency, retransmissions, parallel work, service or version detection, and other scan phases. A retransmission is a repeated probe sent when Nmap does not receive a response within its timing rules.

Latency is the network response time between the scanning host and target. It is different from an intentionally configured scan delay. Nmap output may report timing or round-trip information that describes response behavior; that value is not the same as the pause set by --scan-delay.

Choosing an appropriate delay

• Start with the authorization and documented scope. A maintenance window may permit only a limited scan rate or duration.
• Consider network capacity and target sensitivity. Fragile services and congested links may need a gentler approach.
• Use millisecond-scale delays when you need a modest reduction in probe intensity and have enough time for the scan.
• Expect multi-second delays to make even short scans lengthy. Minute-scale delays require especially careful planning.
• Test one authorized lab host with a narrow port list before expanding to a larger approved scope.
• Record the delay, port list, target scope, Nmap version, and related timing options in assessment notes so the test can be reproduced.

Relationship to other Nmap timing controls

Combining timing controls can produce expectations that are difficult to predict. For example, a fixed delay, a rate limit, a timing template, retries, and parallel host work may all influence observed behavior. Validate combinations in a controlled environment rather than assuming that one option overrides every other timing rule.

Host discovery and port scanning are separate considerations. A delay selected for port probes does not necessarily describe every packet used to discover hosts. Review the discovery method and the port-scanning method independently when planning a test.

For related timing behavior, see Nmap timing options. To limit the ports in a test, see specifying port ranges. For service probes that can add work and time, see determining service versions.

Troubleshooting

The scan takes much longer than expected

• Confirm that the delay value and unit are what you intended.
• Check whether more ports, targets, or probe types are involved than expected.
• Account for packet loss, retransmissions, host discovery, DNS resolution, or service detection.
• Repeat the test against one authorized host with a short explicit port list.
• Review other Nmap options that can add probes or waits.

The runtime is not exactly the delay multiplied by the number of ports

Nmap performs more work than one isolated probe per listed port. Responses, retries, host discovery, scan-engine scheduling, and other phases influence the result. Treat --scan-delay as one contributor to total time, not as an exact runtime calculator.

Nmap rejects the delay value

• Use a numeric value with a recognized suffix, such as 500ms or 10s.
• Check for a typo or a value separated incorrectly from the option.
• Run nmap --help or consult man nmap to verify syntax supported by the installed version.

A slower scan is still logged or alerted on

Security tooling may detect low-rate scans, and some environments record connection attempts regardless of their interval. Do not treat a delay as a way to bypass monitoring. Work under documented authorization and coordinate with defenders or system owners.

Exam-relevant points

• --scan-delay <time> sets a fixed delay between applicable probes.
• The delay is applied per target host, not as one global pause across all targets.
• ms, s, m, and h are examples of human-readable time suffixes supported by Nmap time specifications.
• Scan delay is distinct from network latency, which is the response time between scanner and target.
• --max-scan-delay limits adaptive delay, while -T0 through -T5 tune multiple timing behaviors.
• --min-rate and --max-rate influence probe rate rather than specifying a fixed pause.
• A slower scan may reduce traffic intensity but does not guarantee that monitoring systems will miss it.

Summary

Use --scan-delay when an authorized assessment needs a predictable pause between probes sent to each target host. Choose the value according to scope, target sensitivity, network capacity, maintenance windows, and available time. Measure it with a narrow lab scan, account for other sources of runtime, and document the timing configuration for reproducibility.