I used to think -T4 was just “the fast one” and left it at that. It wasn’t until I actually read through Nmap’s timing documentation and started watching packet captures that I understood timing templates aren’t a single speed dial — they’re a bundle of several independent parameters (round-trip time estimates, parallelism, retry counts, scan delays) that Nmap adjusts together as presets. Understanding what’s actually happening under each template changed how deliberately I choose them.
This article breaks down exactly what each template changes, when I use each one, and how to fine-tune beyond the presets when a specific engagement calls for it.
The Six Templates at a Glance
| Template | Name | Typical Use Case |
|---|---|---|
-T0 | Paranoid | Maximum stealth, IDS evasion research |
-T1 | Sneaky | Very slow, minimal footprint |
-T2 | Polite | Reduced load on production networks |
-T3 | Normal | Default, balanced |
-T4 | Aggressive | Fast, reliable networks (my daily default) |
-T5 | Insane | Maximum speed, best on very fast/local networks |
flowchart LR
A[T0 Paranoid] --> B[T1 Sneaky] --> C[T2 Polite] --> D[T3 Normal] --> E[T4 Aggressive] --> F[T5 Insane]
A -.stealthiest, slowest.-> A
F -.fastest, least stealthy.-> F
What Timing Templates Actually Control
Each template is really just a preset combination of several individually tunable parameters:
--min-rtt-timeout/--max-rtt-timeout/--initial-rtt-timeout— how long Nmap waits for a response before considering a probe lost--max-retries— how many times Nmap resends a probe that got no response--scan-delay/--max-scan-delay— minimum time between probes to the same host--min-parallelism/--max-parallelism— how many probes Nmap sends simultaneously--host-timeout— maximum time to spend on a single host before giving up entirely
The -T flag is convenient shorthand for a coherent combination of all of these — you can absolutely override any individual parameter after selecting a base template.
T0 — Paranoid
sudo nmap -T0 192.168.1.10
This is the slowest possible setting: a five-minute delay between each probe. Scanning even a handful of ports at T0 can take hours. I’ve genuinely only used this once, in a controlled lab exercise specifically to observe how a particular IDS’s rate-based alerting thresholds behaved against extremely low-and-slow traffic.
When it’s actually appropriate: Studying detection thresholds in a lab, or in the rare real-world case where absolute stealth matters more than getting results back this week.
T1 — Sneaky
sudo nmap -T1 192.168.1.10
A 15-second delay between probes. Still very slow, but more tolerable than T0 for scanning a small number of ports.
When I use it: Occasionally for demonstrating evasion concepts in training material, rarely for actual assessment work — it’s simply too slow to be practical for most engagements with real deadlines.
T2 — Polite
nmap -T2 192.168.1.10
A 0.4-second delay between probes, and reduced parallelism compared to the default. This template exists specifically to minimize bandwidth and target load — Nmap’s own documentation describes it as intended to ease network strain.
When I use it: Scanning production infrastructure where I’ve been asked to minimize any chance of service disruption, or scanning over an unstable/low-bandwidth link (like a VPN into a remote client site) where aggressive parallelism would just cause packet loss and retries anyway.
T3 — Normal (Default)
nmap -T3 192.168.1.10
This is what runs if you don’t specify a -T flag at all. It’s a genuinely reasonable balance and honestly fine for most casual or exploratory scanning where you’re not optimizing for either speed or stealth specifically.
T4 — Aggressive
sudo nmap -T4 192.168.1.10
This is my actual daily default for lab work, home network audits, and any environment where I control the network or have clear authorization and speed matters more than subtlety. It assumes a reasonably fast and reliable network, reduces timeouts, and increases parallelism significantly compared to T3.
When I use it: Nearly always, unless I have a specific reason not to — internal pentests on modern infrastructure, home lab scanning, CTF ranges, anything where the network itself isn’t the bottleneck.
T5 — Insane
sudo nmap -T5 192.168.1.10
Maximum speed, minimal timeouts, maximum parallelism. Genuinely useful on very fast local networks or when scanning a small number of hosts where you can tolerate some accuracy loss from packets timing out prematurely on a slower or more distant target.
Caveat: On networks with any real latency or packet loss, T5’s aggressive timeouts can cause Nmap to mark ports as filtered or closed simply because it gave up waiting too soon — not because the port state is actually ambiguous. I only use T5 on networks I know are fast and low-latency, like a local lab segment.
Fine-Tuning Beyond the Presets
I regularly override specific parameters rather than accepting a template wholesale:
# Fast scan but with more retries for a flaky network
nmap -T4 --max-retries 3 192.168.1.10
# Polite base timing, but faster than the default T2 parallelism
nmap -T2 --max-parallelism 10 192.168.1.10
# Custom scan delay independent of any template
nmap --scan-delay 1s 192.168.1.10
# Custom RTT timeouts for a known-slow satellite/high-latency link
nmap --initial-rtt-timeout 500ms --max-rtt-timeout 2000ms 192.168.1.10
This granular control is genuinely more useful in real engagements than the six presets alone — I usually start from T4 as a baseline and adjust one or two parameters based on what I observe in the first few seconds of a scan.
Host Timeout
nmap --host-timeout 5m 192.168.1.0/24
Sets a hard ceiling on how long Nmap will spend on any single unresponsive host before giving up and moving to the next one — invaluable on large subnets where one or two hosts silently dropping everything would otherwise stall an entire sweep.
Practical Example: Choosing Timing for Different Scenarios
# Scenario 1: internal lab, fast network, need results quickly
sudo nmap -T4 -p- 192.168.1.10
# Scenario 2: production network, client explicitly asked for minimal impact
nmap -T2 --max-parallelism 5 -p 1-1000 192.168.1.10
# Scenario 3: scanning over an unstable VPN link to a remote site
nmap -T2 --max-retries 5 --host-timeout 10m 10.50.0.0/24
# Scenario 4: large subnet sweep, need to avoid getting stuck on dead hosts
nmap -T4 --host-timeout 3m -sn 192.168.1.0/24
Timing and Its Relationship to Evasion
I cover firewall/IDS evasion in a dedicated article, but timing deserves a mention here specifically because it’s one of the more durable evasion techniques against modern rate-based detection:
nmap -T1 --scan-delay 10s 192.168.1.10
Many IDS/IPS platforms flag scanning activity based on the rate of connection attempts from a single source within a time window. Slowing probes down enough can keep traffic under those thresholds — though it obviously trades speed for that benefit, sometimes dramatically.
Python Integration
import nmap
import time
scanner = nmap.PortScanner()
start = time.time()
scanner.scan('192.168.1.0/24', arguments='-T4 -sn')
elapsed = time.time() - start
print(f"T4 sweep of /24 completed in {elapsed:.2f} seconds")
print(f"Live hosts found: {len(scanner.all_hosts())}")
I use timing comparisons like this when I need to justify a specific template choice in a report — showing the actual measured time difference between, say, T2 and T4 on a specific network makes a much stronger case than just asserting “T4 is faster.”
Troubleshooting
T5 scan reports ports as filtered that are actually open — the aggressive timeouts are likely giving up before a slower or more distant host can respond. Drop to T4 or T3, or manually increase --max-rtt-timeout.
T2/T1 scan is taking far longer than expected — this is by design; if you need results faster, you’ll need to accept a less polite/stealthy template.
Scan hangs on one unresponsive host in a large sweep — add --host-timeout to cap time spent per host regardless of the timing template selected.
Results are inconsistent between runs at the same timing template — network conditions (latency, packet loss, congestion) can genuinely vary between runs; this is more likely on remote or unstable links than on a local lab network.
Limitations
Timing templates are presets, not guarantees — network conditions ultimately determine whether a given template’s assumptions hold. T4/T5 on a genuinely congested or high-latency network will produce less reliable results than T3, regardless of how “fast” the template is theoretically supposed to be. No timing template can fully disguise a scan from a well-tuned, modern IDS that correlates traffic over longer windows than a single session.
Security Best Practices
- Default to T2 or T3 on any network you don’t fully control, especially production infrastructure, unless you have explicit sign-off for a faster/noisier scan.
- Never assume slow timing alone constitutes adequate stealth against a modern SOC — timing is one variable among many that detection systems consider.
- Document the timing template used in any professional report; a client should know whether a “clean” result came from a conservative scan that might have missed things due to conservative timeouts.
- When in doubt on an unfamiliar network, start with T2 or T3 and a narrow port range before committing to a wider, faster sweep.
Frequently Asked Questions
What’s the actual default if I don’t specify -T? T3 (Normal) — a genuinely balanced middle ground that Nmap’s developers chose as sensible for most situations.
Is T5 ever a bad idea on a local network? Rarely, but it can still produce inaccurate results against specific slow-to-respond services even on a fast local network — if accuracy matters more than raw speed, T4 is usually the safer daily choice.
Can I mix a base template with custom parameters? Yes, and I do this constantly — specify -T4 as a starting point, then override individual flags like --max-retries or --scan-delay as needed for the specific network you’re on.
Does a slower timing template guarantee I won’t be detected? No. Timing is one signal among many that modern detection systems evaluate; a sophisticated SOC can still correlate slow, low-volume probing over a longer analysis window.
Watching Timing Decisions in Real Time
For long-running scans, I always add --stats-every so I can watch how a chosen timing template is actually performing rather than staring at a blank terminal wondering if the scan is stuck:
sudo nmap -T4 -p- --stats-every 10s 192.168.1.0/24
Stats: 0:01:40 elapsed; 12 hosts completed (2 up), 2 undergoing SYN Stealth Scan
SYN Stealth Scan Timing: About 34.34% done; ETC: 14:32 (0:03:10 remaining)
That estimated-time-to-completion line is genuinely useful for deciding, mid-scan, whether a chosen template needs adjusting. If the ETC keeps growing rather than shrinking, that’s usually a sign the network is struggling to keep up with the current parallelism level, and I’ll often kill the scan and restart at a more conservative template rather than waiting out an increasingly unreliable run.
A Note on Perceived vs. Actual Stealth
I want to close this out with something I’ve noticed causes real confusion: choosing a “sneaky” timing template does not automatically mean a scan is undetected. Timing is one input among many that a modern detection stack considers — source IP reputation, packet header anomalies, destination port sequencing, and correlation across a longer time window than any single scan session. A -T1 scan spread across six hours is still, eventually, a recognizable pattern to a SOC analyst reviewing a full day’s logs, even if it never triggers a real-time rate-based alert. Treat timing as a real, useful lever — not a cloak of invisibility.
Wrapping Up
Timing templates seem like a minor cosmetic choice until you’re standing in front of a client explaining why a scan took six hours, or why a “quick check” accidentally set off alerts on a production firewall. Understanding what each template actually changes under the hood — not just “T4 is fast” — lets me make a deliberate, defensible choice for every engagement instead of just defaulting to whatever I used last time.
