Send a UDP datagram to a host and port and report whether the service replies. UDP is connectionless, so no reply is ambiguous — it does not necessarily mean the port is closed.
• Target：Enter host:port (e.g. 8.8.8.8:53); the default port is 53 (DNS) when none is given
• What is checked：A single UDP datagram is sent and the probe waits for an application-layer reply within the timeout
• Why no reply is ambiguous：A closed UDP port usually stays silent too, so open and filtered cannot be distinguished without raw ICMP — a reply proves open, silence proves nothing
• Node selection：Optionally select specific nodes; all available nodes are used by default
A UDP test sends a single datagram to the specified host and port and waits for a reply. Because UDP is a connectionless protocol with no handshake, receiving a reply proves the port is open and a service is answering, but receiving nothing is ambiguous — the port could be open-but-silent, filtered by a firewall, or the packet could simply have been lost.
Common uses include checking that a DNS resolver (port 53), NTP server (port 123), SNMP agent (port 161), or a game / VoIP service is reachable and responding, and diagnosing whether a firewall is silently dropping UDP traffic to a service.
Unlike TCP, UDP has no handshake. A closed UDP port may respond with an ICMP 'port unreachable' message, but many hosts and firewalls suppress or rate-limit those messages, so the absence of a reply looks identical to an open port that simply didn't answer. Only a positive reply is conclusive.
By default the probe sends a single null byte, which is enough to elicit a response from simple echo-style services. For protocol-specific services you can supply a hex payload (e.g. a DNS query) so the service recognises the request and replies.
If you enter a bare host with no port, the probe uses port 53 (DNS), the most common UDP service to reach for a quick reachability check. Specify host:port to target any other service.
It means the port is open and something answered at the transport layer. It does not validate the application-level response content; use a protocol-specific tool (e.g. the DNS or NTP test) to confirm the service behaves correctly.