Most people scan TCP, get their results in seconds, and stop there. But a huge amount of what runs on a real network lives on UDP: DNS, DHCP, SNMP, NTP, TFTP, IKE. If you only ever scan TCP, you are blind to half your own infrastructure. UDP scanning (-sU) fills that gap, but it is slower, noisier to interpret, and far more prone to ambiguous results than its TCP cousin, and understanding why is the difference between trusting the output and being misled by it. This guide is part of the complete Nmap guide, and it covers how UDP states are actually decided, how to read the ambiguous ones, which UDP services are worth your time, and how to keep a UDP scan from taking all night.
Why UDP scanning is hard and slow
TCP is a connection-oriented protocol with a handshake. Send a SYN, get a SYN/ACK, and you know the port is open; get a RST, and you know it is closed. The protocol itself gives you a clean signal. UDP has none of that. It is connectionless: you send a datagram and the protocol makes no promise of any reply at all. There is no handshake to interpret, so Nmap has to infer state from indirect evidence.
Worse, the one clear signal UDP scanning relies on - the ICMP "port unreachable" message a host sends when nothing is listening - is rate-limited by most operating systems. A target will only emit so many of those ICMP errors per second, so Nmap has to slow down and wait to avoid outrunning the target's willingness to answer. That rate limiting is the single biggest reason a full UDP scan can crawl. TCP can blast a thousand ports and read a thousand RSTs; UDP has to send, wait, and often send again because it cannot tell a dropped probe from a silent-but-open port.
How UDP states are decided
Nmap resolves a UDP port into one of three outcomes, and each comes from a different piece of evidence. The clearest case is closed: the host answers your probe with an ICMP type 3, code 3 (port unreachable) message, which is an explicit "nothing is listening here." You can see that reasoning spelled out when you add --reason to a scan of the common UDP ports on a Linux host:
$ nmap -sU --top-ports 20 --reason 127.0.0.1
Starting Nmap 7.95 ( https://nmap.org ) at 2026-07-05 15:05 PDT
Nmap scan report for localhost (127.0.0.1)
Host is up, received localhost-response (0.000042s latency).
PORT STATE SERVICE REASON
53/udp closed domain port-unreach ttl 64
67/udp closed dhcps port-unreach ttl 64
68/udp closed dhcpc port-unreach ttl 64
69/udp closed tftp port-unreach ttl 64
123/udp closed ntp port-unreach ttl 64
135/udp closed msrpc port-unreach ttl 64
137/udp closed netbios-ns port-unreach ttl 64
138/udp closed netbios-dgm port-unreach ttl 64
139/udp closed netbios-ssn port-unreach ttl 64
161/udp closed snmp port-unreach ttl 64
162/udp closed snmptrap port-unreach ttl 64
445/udp closed microsoft-ds port-unreach ttl 64
500/udp closed isakmp port-unreach ttl 64
514/udp closed syslog port-unreach ttl 64
520/udp closed route port-unreach ttl 64
631/udp closed ipp port-unreach ttl 64
1434/udp closed ms-sql-m port-unreach ttl 64
1900/udp closed upnp port-unreach ttl 64
4500/udp closed nat-t-ike port-unreach ttl 64
49152/udp closed unknown port-unreach ttl 64Every line reads closed ... port-unreach ttl 64. That is the ideal case: the host was cooperative, sent an ICMP unreachable for each port with no service behind it, and Nmap could state closed with certainty. The --reason column makes the evidence explicit, which is worth getting in the habit of on UDP scans specifically, because the states are so much easier to misread than TCP.
The second outcome is the frustrating one: open|filtered. If Nmap sends a UDP probe and hears absolutely nothing back - no service reply and no ICMP error - it genuinely cannot tell whether a service is quietly listening (open) or a firewall silently dropped the probe (filtered). Both look identical from the scanner's side: silence. So Nmap reports the honest ambiguity open|filtered rather than guessing. The third outcome is open, which you only get when an actual UDP service replies to the probe - a DNS server answering a query, an SNMP agent responding to a get. A real reply is unambiguous proof something is listening.
Seeing it on network gear
The same logic plays out against a Cisco router in the lab. Here is a UDP scan of five common infrastructure ports on R1:
$ nmap -sU -p 53,67,123,161,500 10.10.10.1
Starting Nmap 7.95 ( https://nmap.org ) at 2026-06-28 07:07 UTC
Nmap scan report for 10.10.10.1
Host is up (0.0036s latency).
PORT STATE SERVICE
53/udp closed domain
67/udp closed dhcps
123/udp closed ntp
161/udp closed snmp
500/udp closed isakmp
MAC Address: AA:BB:CC:00:5B:00 (Unknown)
Nmap done: 1 IP address (1 host up) scanned in 4.97 secondsAll five come back closed because R1 returned an ICMP port-unreachable for each - definitively closed, the same clean signal as the Linux host. Note the timing though: 4.97 seconds for just five UDP ports, versus the sub-second TCP scans you are used to. That is the rate limiting and probe retransmission tax in action, and it is why the capture comment simply reads "UDP is slow." Scale that up to thousands of ports and the cost compounds fast.
One more thing worth flagging from the lab. When the DNS host (DNS01) was scanned, Nmap reported Host seems down. If it is really up, but blocking our ping probes, try -Pn - because that container never got its LAN IP applied, so host discovery correctly found nothing there. That is a reminder that a UDP scan still depends on the target being reachable in the first place; a "host down" note is about discovery, not about the UDP ports.
UDP services worth scanning
You rarely want a full UDP sweep. Far more often you want the handful of ports that carry the services network engineers actually care about. These are the ones worth targeting first.
Targeting these directly with -p instead of scanning all 65535 UDP ports is the single biggest time-saver available. On network gear especially, SNMP on 161 and TFTP on 69 are the two worth auditing on every device, because an open, default-community SNMP agent or an unauthenticated TFTP server is a real exposure hiding in plain sight.
Speeding up a UDP scan
Because UDP is slow by nature, controlling scope and pace is essential. A few flags carry most of the weight.
--top-ports Nscans only the N most common UDP ports instead of the full range. The--top-ports 20in the capture above is a perfect example: twenty high-value ports in a fraction of a second, versus minutes or hours for everything.-T4raises the timing template, letting Nmap probe more aggressively. It helps, but remember the target's ICMP rate limiting sets a ceiling that no timing template can fully overcome.--min-rateforces a minimum packets-per-second floor, useful when you have measured the target can take it and you want to push past Nmap's cautious defaults.--host-timeoutcaps how long Nmap will spend on any single host before moving on, which stops one slow or heavily filtered target from stalling a whole sweep.
All of these lean on Nmap's broader timing and performance controls, which matter far more on UDP than on TCP precisely because there is so much waiting involved.
Pairing -sU with -sV
The open|filtered ambiguity is the weakness of a bare UDP scan, and version detection is one way to cut through it. Adding -sV to a UDP scan makes Nmap send protocol-specific payloads: a real DNS query to port 53, an SNMP get to 161, and so on. If the service is actually listening, it replies to the payload, and that reply promotes the port from open|filtered to a confirmed open with a version string attached. The trade-off is more time and more packets, so reserve it for the ports you have already narrowed down to. This is the same port scanning discipline you apply on TCP: scan wide to find candidates, then probe deep on the interesting ones. For deeper interrogation of a confirmed UDP service, the NSE scripts include targeted scripts for DNS, SNMP, and more.
All of this is why a full nmap -sU -p- across every one of the 65535 UDP ports can take hours against a single host. Every silent port forces a wait to distinguish open from filtered, every closed port is gated by the target's ICMP rate limit, and probes get retransmitted to rule out simple packet loss. It is a legitimate scan to run when you truly need complete UDP coverage, but it is never the scan you reach for first. Nmap's own notes on port scanning techniques go into the retransmission and rate-limit mechanics in detail.
Key takeaways
UDP scanning is slow and ambiguous by design because the protocol gives no handshake, and the one clean signal - an ICMP port-unreachable meaning closed - is rate-limited by the target. Learn to read the three states: closed from an ICMP unreachable, open from an actual service reply, and the honest open|filtered when the host stays completely silent. Use --reason to see the evidence, target the high-value ports (DNS, DHCP, TFTP, NTP, SNMP, IKE, UPnP) with -p or --top-ports rather than sweeping all 65535, and pace the scan with -T4, --min-rate, and --host-timeout so it finishes this decade. When ambiguity bites, add -sV so payload probes can turn open|filtered into a confirmed service. For the whole methodology, from discovery through TCP and UDP scanning to scripting, work through the complete Nmap guide.
