Port scanner benchmarksNmap vs masscan vs RustScan vs naabu
Four scanners run against the same lab /16 on identical hardware, from the same uplink, with the same port set. The headline is not which is fastest — it is how much accuracy each one trades away to get there.
Headline numbers
Full results
| Benchmark | Score | Test profile | How to use it |
|---|---|---|---|
| Nmap 7.95 | 61m 04s | -sS -T4 --top-ports 1000 | The accuracy baseline every other result is measured against. Use it when a missed port is more expensive than the wait. |
| masscan 1.3.2 | 42s at 100k pps | --rate 100000 -p1-1000 | Fastest sweep by a wide margin, but it drops responses under load. Treat the output as a candidate list, not an inventory. |
| masscan 1.3.2 | 4m 51s at 10k pps | --rate 10000 -p1-1000 | Dropping the rate to 10k recovers most of the accuracy. This is the setting to use if you only run masscan. |
| RustScan 2.3 | 3m 18s | -b 4500 --ulimit 5000, Nmap handoff | Finds open ports quickly then hands them to Nmap for service detection. The best default for most engagements. |
| naabu 2.3 | 5m 42s | -rate 5000 -top-ports 1000 | Slower than RustScan here but integrates cleanly into ProjectDiscovery pipelines. Pick it for tooling fit, not speed. |
| Accuracy — masscan 100k | 95.9% | vs Nmap ground truth | 1,204 of 29,380 known-open ports were missed. Re-run confirmed hosts at a lower rate before reporting. |
| Accuracy — masscan 10k | 99.1% | vs Nmap ground truth | A tenfold rate reduction buys back 3.2 points of accuracy for about four extra minutes. |
| Accuracy — RustScan | 99.2% | vs Nmap ground truth | Close enough to Nmap for most purposes at a twentieth of the runtime. |
| Peak memory | Nmap 412MB / masscan 61MB | RSS at peak | masscan's flat memory profile is why it survives a /8. Nmap's scales with host count. |
| Packets dropped | 0.02% at 10k / 4.4% at 100k | Kernel counters | The drop rate is the accuracy loss. If you can see this number, you can predict your miss rate. |
Why the fastest scanner is usually the wrong answer
masscan finishing a /16 in 42 seconds is a real result, and it is also the least useful number on this page. At 100,000 packets per second the kernel dropped 4.4% of responses, and the scan missed 1,204 ports that Nmap confirmed were open.
For asset discovery that feeds a vulnerability programme, a 4% miss rate is not a rounding error — it is the host that does not get patched.
The pattern worth internalising
Across all four tools, accuracy tracks the drop rate almost exactly. That is convenient, because the drop rate is something you can observe while the scan is running rather than something you discover afterwards by comparing against ground truth you do not have.
If you take one operational habit from this page: watch the kernel drop counters during the scan, and treat any sustained figure above about 1% as a signal to halve the rate and re-run.
Test conditions, stated plainly
Every run used the same lab /16 of 65,536 addresses with a known, fixed set of 29,380 open ports across the top 1,000 TCP ports. Hardware, uplink and kernel were identical between runs, and each figure is the median of five runs.
These numbers describe a clean lab network with no rate limiting, no IPS and no packet shaping in the path. A real engagement will be slower and less accurate than every result here. Use the relative ordering, not the absolute times.
Were these benchmarks helpful?
If something here is wrong or out of date, tell us and we will check the source.
Thanks — that is recorded.
Last updated July 22, 2026 · by Arjun Nair