Test a UDP endpoint before buying

5 datagrams answer the first question

The endpoint tester answers one question before payment: can UDP packets from 64.130.40.90 reach the public IP and port you plan to use. It is free and needs no account.

The test sends real UDP datagrams. It does not simulate a firewall rule in the browser. A short-lived probe session creates a random nonce, sends five numbered datagrams from the same source IP used by the paid feed, and waits for the receiver to acknowledge those nonces through the tool's HTTPS reporting endpoint. The page updates as acknowledgements arrive.

A browser cannot listen on an arbitrary UDP port. The target machine therefore runs the displayed temporary receiver command or integrates the small acknowledgement format into an existing listener. UDP delivery and HTTPS reporting are separate paths. The UDP packet proves inbound reachability. The HTTPS acknowledgement lets the browser learn the result.

Method

Each probe begins with the same protocol family used for destination verification and includes a random session identifier plus a sequence from 1 through 5. The nonce is unguessable for the short session. The receiver checks it, records arrival time, and acknowledges the sequence over HTTPS.

The result uses four values:

sent = 5
received = number of distinct acknowledged sequences
loss_percent = 100 * (sent - received) / sent
spread_ms = last_udp_arrival_ms - first_udp_arrival_ms

Duplicate acknowledgements do not increase received. Acknowledgements with the wrong nonce or an expired session are ignored. The session expires after 600 seconds, matching the product's challenge lifetime.

The sender binds to 64.130.40.90. That point matters. A successful probe from some unrelated cloud address would not validate the production allowlist. The destination is the exact public IPv4 address and UDP port the visitor enters.

The tool validates the address before sending. It rejects private, loopback, link-local, multicast, broadcast, unspecified, and malformed targets. It caps requests per session and per destination. Those controls keep a free diagnostic from becoming a general packet source.

Worked example

Assume the intended receiver is public address 203.0.113.40 on UDP port 9000. The example address is documentation space, so a real test must use an address you control.

The user starts the temporary receiver on the target host, enters its real public IP and port in the page, then presses send. The service transmits sequences 1 through 5 from 64.130.40.90. The receiver sees sequences 1, 2, 4, and 5 and acknowledges them. Sequence 3 does not arrive before the deadline.

The page calculates:

sent = 5
received = 4
loss_percent = 100 * (5 - 4) / 5 = 20 percent

The result is partial reachability. It proves the source and destination tuple can pass at least some traffic. It also says the five-packet test was not clean. The next step is to inspect host firewall counters, cloud firewall rules, NAT state, and socket receive counters, then repeat.

If all five arrive across repeated tests, the page reports reachable. That is enough to answer whether packets can reach the listener now. It is not enough to establish production capacity.

Read failures by boundary

Zero acknowledgements has several possible causes. The UDP datagrams may not reach the host. The cloud security group may block them. A network firewall or NAT rule may point at another machine. The process may not be bound to the named port. The temporary receiver may receive UDP but fail to reach the HTTPS acknowledgement service.

The command prints local receipt before attempting acknowledgement. If it prints a valid nonce but the page remains waiting, inbound UDP worked and outbound HTTPS reporting failed. If it prints nothing, inspect packet capture and counters on the target.

Use a narrow capture filter:

source host 64.130.40.90 and UDP destination port 9000

If the interface sees packets but the process does not, the fault is between NIC, kernel firewall, socket binding, and receive queue. If the interface sees nothing, inspect provider rules, routing, public-address mapping, and upstream firewall.

What success proves

Success proves that at least one real datagram from 64.130.40.90 reached the named UDP socket during the active 600-second session and that its nonce was reported. Five of five gives a cleaner reachability signal than one packet because it catches an intermittent drop in a tiny sample.

Success also verifies the operator tested the exact port rather than a nearby TCP service. UDP and TCP firewall rules are different. A listening TCP command on port 9000 says nothing about UDP port 9000.

The test is useful before purchase because the paid product sends raw UDP to one IP and port. A receiver that cannot pass five probes will not become ready after checkout.

Limitations

Five packets do not estimate loss at production confidence. One lost packet produces a coarse 20 percent result. Use a longer controlled sample and shred sequence analysis for packet-loss measurement.

The test does not reproduce the measured feed load of 54.3 Mbps and 5,585 packets per second. It does not exercise a 17.6 TB monthly path, short bursts, kernel receive-buffer pressure, decoder throughput, or application queues. Passing the probe can coexist with heavy production loss.

The test does not prove the destination is safe to expose, that its firewall denies other sources, or that source IP filtering is cryptographic authentication. It does not test packet ordering or retransmission because raw UDP provides neither.

NAT can expire mappings. A port opened by outbound traffic during the test may close later. Cloud rules can differ across instances or interfaces. Any address change requires a new verification under the product workflow.

The tool reports observed delivery, not why a packet failed. Its most valuable result is often a clean boundary: sender dispatched, interface saw nothing, or receiver saw UDP but acknowledgement failed. That evidence turns a vague activation problem into a specific network check.