How do I check if a UDP port is open online?

Enter a host and UDP port (e.g. 8.8.8.8:53) in the UDP checker. The tool sends protocol-appropriate payloads from 50+ global nodes — for example, a real DNS query to port 53 or an NTP request to port 123 — and reports whether a valid response was received from each location.

Why does UDP port testing require a payload?

Unlike TCP, UDP has no handshake. An empty packet sent to most UDP services produces no response because the application is waiting for meaningful data before replying. The tool automatically injects the correct payload for known ports (DNS/53, NTP/123, SNMP/161, game servers/27015) to get a real, meaningful response.

How do I test if my VPN UDP port is reachable?

Enter your VPN server IP and port (typically UDP 1194 for OpenVPN or UDP 51820 for WireGuard) and run the UDP check. Results from multiple global nodes will show whether your VPN port is accessible worldwide or blocked by specific ISPs or regional networks.

Can I test game server ports with this UDP checker?

Yes. For Source Engine game servers (CS:GO, TF2, Rust) on port 27015, the tool automatically sends a valid Source Engine query packet. For other game servers, you can enter a custom hex payload in the advanced options. Results show which global regions can reach your game server.

UDP-Port-Check für 1.1.1.1

Erweiterte Einstellungen

Weltkarte anzeigen

Erweiterte Optionen (Benutzerdefinierter Payload)

Bleibt das Feld leer, injiziert das System bei geläufigen Ports (DNS, NTP, SNMP, Source Engine usw.) automatisch einen genormten Probe-Request.

Info Ping HTTP TCP UDP MTR DNS

A port is required for UDP checks.

UDP-Port prüfen: Erweiterter Verbindungstest

Geben Sie eine Domain oder IP-Adresse mit Port ein (z. B. 8.8.8.8:53), um den UDP-Check zu starten.

Beispiele: 8.8.8.8:53 time.nist.gov:123 1.1.1.1:5060

Häufig verwendete UDP-Ports

Eine Referenz für Standard-UDP-Dienste und die typische Payload, die zum Testen benötigt wird.

Port	Dienst	Beschreibung
53	DNS	DNS; antwortet auf Standard-DNS-Abfragen.
67	DHCP	DHCP-Server; genutzt für dynamische IP-Zuweisung.
123	NTP	NTP (Network Time Protocol); antwortet auf Zeitsynchronisationsanfragen.
161	SNMP	SNMP; wird für das Netzwerkmanagement verwendet.
500	ISAKMP	ISAKMP/IKE; wird bei IPsec-VPN-Aushandlungen verwendet.
3478	STUN	STUN; wird von VoIP und WebRTC zum Durchqueren von NAT verwendet.
5060	SIP	SIP; unverschlüsselte VoIP-Signalisierung.
27015	Source Engine	Steam/Source Engine; Standard-Spieleabfrage-Port.

Globaler UDP-Port-Checker & Payload Injektor

UDP schickt Pakete an ein Ziel, ohne vorher eine Verbindung aufzubauen. Kein Handshake, keine Bestätigung — das Paket geht raus, und entweder kommt etwas zurück oder nicht. Das macht das Testen von UDP-Ports grundlegend anders als bei TCP: Ein leeres Paket an einen offenen UDP-Port erzeugt oft überhaupt keine Antwort, weil die Anwendung auf eine sinnvolle Payload wartet, bevor sie antwortet.

Stateless Routing & Payload-Injektion

Um eine echte Antwort von einem UDP-Dienst zu bekommen, muss die Probe wie legitimer Traffic aussehen. Für Port 53 heißt das, eine gültige DNS-Anfrage zu schicken. Für Port 123 eine NTP-Versionsanfrage. Für Gameserver auf 27015 eine Source-Engine-Query. Das Tool übernimmt das automatisch für bekannte Ports — es injiziert die passende Anwendungs-Payload, damit der Server überhaupt etwas hat, worauf er antworten kann. Sonst bleibt das Ergebnis einfach nur schweigen.

Firewall & DDoS-Mitigations-Test

Weil UDP-Amplification (NTP, DNS, Memcached) bei DDoS-Angriffen stark missbraucht wurde, filtern viele Netzwerke UDP standardmäßig aggressiv. Cloud-Provider blockieren oft eingehendes UDP außer auf explizit freigegebenen Ports. ISP-Scrubbing-Center verwerfen UDP, das bekannten Amplification-Signaturen entspricht. Ein Test aus mehreren Regionen zeigt, ob dein UDP-Dienst überhaupt aus dem Internet erreichbar ist oder irgendwo auf dem Weg lautlos verworfen wird.

Gaming, VoIP und Streaming-Analyse

Gameserver, SIP/RTP-Sprachverkehr und Live-Video-Streaming setzen alle auf UDP, weil der Latenz-Overhead eines TCP-Handshakes zu hoch ist. Wenn UDP-Pakete verloren gehen, zeigt sich das als Voice-Jitter, Lag-Spitzen in Spielen oder eingefriertes Video. Der Live-Modus läuft 60 Sekunden lang und zeichnet jede Antwort einzeln auf — so lässt sich erkennen, ob Paketverlust gleichmäßig verteilt oder in Bursts auftritt. Beide Muster zeigen auf sehr unterschiedliche Ursachen.