Nmap: How to Scan All 65535 Ports (With Real Timings)

Hi folks! “How do I scan all ports with Nmap” is one of those questions with a one-line answer and a twenty-minute follow-up. The one-liner is nmap -p- target. The follow-up is everything people actually want to know: how long it takes, why it is slower than you expected, which flags genuinely help, and when you should not be using Nmap for the job at all.

So we did the boring part for you. Nmap 7.94 on a real server, scanning a machine we own, every measurement taken with time. Below are the numbers, including a couple that contradict advice you will find everywhere.

Table of Contents

• The Short Answer
• Why the Default Scan Misses 64 535 Ports
• How Long a Full Port Scan Really Takes
• The -T4 Myth
• –min-rate: The Flag That Did Help
• Why -sV Costs More Than Scanning Every Port
• Reading the Output: Closed, Filtered, Open
• Scanning a Whole Network
• When to Use Masscan Instead
• Conclusion

The Short Answer

nmap -p- 203.0.113.10

That is it. -p- means every TCP port from 1 to 65535. Two variations worth knowing:

# skip host discovery — use this when ICMP is blocked
nmap -Pn -p- 203.0.113.10

# an explicit range, identical to -p-
nmap -p1-65535 203.0.113.10

Add -Pn by default when scanning internet hosts. Without it Nmap first pings the target, and plenty of servers drop ICMP — Nmap then declares the host down and never scans a single port. That is the most common reason a full scan comes back empty.

Why the Default Scan Misses 64 535 Ports

Run Nmap with no port options and it checks 1000 ports — not all of them, and not the first thousand either. It is a curated list of the most commonly used ports, ranked by how often they were found open in internet-wide research.

nmap -Pn 203.0.113.10

Not shown: 997 closed tcp ports (reset)
PORT    STATE SERVICE
22/tcp  open  ssh
80/tcp  open  http
443/tcp open  https

Nmap done: 1 IP address (1 host up) scanned in 0.41 seconds

For most hosts that is enough. But anything deliberately hidden — an admin panel on 8443, a database moved to 54320, a backdoor on 31337 — lives outside those 1000 ports precisely because whoever put it there did not want it found by a default scan.

How Long a Full Port Scan Really Takes

Here are our measurements. Same source host, same target, same network, one host with three open ports:

Sixteen seconds for all 65 535 ports sounds fast, and on a well-connected server against a responsive target it is. Do not read these as universal numbers though — a firewall that silently drops packets instead of sending resets will turn the same scan into minutes, because Nmap has to wait out its timeout on every unanswered port rather than getting an instant “closed”.

That is the real variable. A target that answers takes seconds; a target that stays silent takes as long as your timeouts allow.

The -T4 Myth

Every guide tells you to add -T4 to speed things up. In our test it changed nothing: 16.2 seconds with it, 16.2 seconds without.

This is not a contradiction, it is a misunderstanding of what timing templates do. -T4 shortens timeouts and allows more parallelism — it helps when the scan is waiting. Our target answered every probe instantly with a RST, so there was nothing to wait for and nothing to shorten.

Where -T4 earns its reputation is against filtered hosts and slow links. Against a healthy server on a fast network it is a no-op. So do not cargo-cult it and then wonder why your scan is still slow — the bottleneck is somewhere else.

–min-rate: The Flag That Did Help

Unlike the timing template, --min-rate sets a floor on packets per second directly, and that moved the needle:

nmap -Pn -p- --min-rate 5000 203.0.113.10
# 13.2 s vs 16.2 s without the flag

Roughly 18% off, from one flag. Push it higher and returns diminish quickly while packet loss grows — and lost probes get reported as filtered ports, which quietly corrupts your results. Somewhere between 1000 and 5000 is a sane band for internet targets; on a LAN you can go considerably higher.

Why -sV Costs More Than Scanning Every Port

This one surprised us enough to double-check. Version detection on three known-open ports took 12.8 seconds — nearly as long as scanning all 65 535 ports without it.

nmap -Pn -p22,80,443 -sV 203.0.113.10

80/tcp  open  http     nginx 1.18.0 (Ubuntu)
443/tcp open  ssl/http nginx 1.18.0 (Ubuntu)

The reason is that a port scan is one packet per port, while version detection is a full conversation: connect, send probes, wait for banners, match them against a database of thousands of signatures. Ports are cheap, dialogue is expensive.

The practical consequence is the two-stage approach. Never run -p- -sV in one go against a wide target list. Find the open ports first, then interrogate only those:

# stage 1: find what is open, fast
nmap -Pn -p- --min-rate 5000 203.0.113.10 -oG open.txt

# stage 2: identify only those ports
nmap -Pn -p22,80,443 -sV 203.0.113.10

Reading the Output: Closed, Filtered, Open

The line most people skim past is the most informative one:

Not shown: 65532 closed tcp ports (reset)

Note the word in brackets. (reset) means the host actively refused those ports with a RST packet — the target is reachable and simply has nothing listening there. That is a healthy, honest answer.

A scan that returns thousands of filtered ports is telling you about the firewall, not about the services. And if you cranked --min-rate too high, some of those “filtered” ports are simply your own dropped packets — rerun slower before drawing conclusions.

Scanning a Whole Network

Multiply everything above by the number of hosts. We scanned 64 addresses of our own subnet across ports 1–1000:

nmap -Pn -p1-1000 198.51.100.0/26
# 12.1 s

Twelve seconds for 64 hosts and a thousand ports each. Now extrapolate to -p- across a /16 and you will see why full-range scans of large networks with Nmap are an overnight-job proposition.

Two habits that help at this scale: write results to a file with -oA basename so you never have to repeat a long scan, and split target lists into chunks so a single failure does not cost you the whole run.

When to Use Masscan Instead

We ran the exact same two scans with Masscan for comparison:

Masscan found exactly the same three open ports, in about half the time. Which sounds decisive until you remember what it did not give you: no service names, no versions, no scripts. Just “this port answered”.

And note how modest the gap is at this scale. Masscan’s real advantage appears at hundreds of thousands of hosts, where it keeps a flat packet rate while Nmap’s per-host overhead accumulates. For one server or one small subnet, Nmap is the better tool because it tells you more.

The combination beats either alone: Masscan sweeps wide to find what is open, Nmap follows up on the handful of hosts that matter.

masscan -iL targets.txt -p1-65535 --rate 20000 -oJ - 2>/dev/null 
  | jq -r '.[] | .ip' | sort -u > live.txt

nmap -Pn -sV -iL live.txt

Conclusion

Scanning all ports is nmap -Pn -p- target, and on a responsive host it takes seconds rather than the hours people fear. If it drags, the target is filtering, not Nmap being slow.

From our measurements: -T4 did nothing against a healthy target, --min-rate 5000 shaved 18%, and -sV on three ports cost almost as much as the entire 65 535-port sweep — which is exactly why you split discovery and identification into two stages.

If you need the wide sweep without maintaining scan nodes and answering abuse mail, that is what ScaniteX does — you pick ranges and ports, we run it at scale and hand back the results. Happy scanning, and only against hosts you are allowed to touch.