Country- or ISP-level UDP restrictions and packet inspection UDP blocking, throttling and inspection by networks
Cause ID isp-udp-block · Primary owner External (External) · Also Game team (Client development), Game team (Server development), Infra team (Network infrastructure)
Some networks block specific UDP addresses and ports or throttle UDP, and packet inspection equipment filters out protocols it doesn’t recognize. Games that communicate over UDP can’t connect on those networks or disconnect often.
Why Connecting from an ISP network that throttles UDP, or from a network with country- or ISP-level traffic inspection (censorship) equipment → Effect Specific UDP addresses and ports are blocked, UDP is throttled at busy hours, ports or protocols not on an allowlist are filtered out, or the first few packets get through before the flow is blocked → On screen Only players in certain countries or on certain ISPs can’t connect or get infinite loading, disconnect soon after connecting, or teleport from packet loss at busy hours
Right after login or maintenance, Always, Evening peak hours
Owner
Primary owner External (External) · Also Game team (Client development), Game team (Server development), Infra team (Network infrastructure)
Game team action items
Client: fall back automatically to a TCP/TLS 443 path if UDP doesn’t connect within a few seconds, also detect connections that drop soon after succeeding and retry them on the fallback path, log which path was used. Server: accept the same game protocol over TCP 443 (TLS) as well, adjust timeouts because the fallback path can add latency.
Infra team action items
Before launching in a new country, measure UDP reachability and peak-hour loss on local ISP networks, place relays or gateways that accept the TCP 443 fallback close to the region, monitor UDP and TCP connection success rates per country and ASN, gather evidence and escalate for ISPs confirmed to throttle UDP.
External action items
Ask the ISP or agency about its UDP restriction criteria and any relief, tell players to try connecting from another network to compare.
Ballpark numbers
Measurements cited by an IETF document show that 3–5% of networks block UDP entirely. When Google reviewed its 2016 QUIC (UDP-based) usage, 4.4% of clients couldn’t use UDP/QUIC because it was blocked or the path MTU was too small, mostly behind corporate firewalls, and it saw no case of an entire ISP blocking it. Another 0.3% were on networks where loss rose sharply at peak hours, apparently from UDP throttling; Google brought that down from 1% in 2015 by working with the ISPs.
On the graph
Outliers only · UDP connection success rate (by country/ASN)
Where to look
Split UDP connection success rate and TCP 443 fallback success rate by country and ASN. From a cloud VM or a player’s PC on that ISP’s network, test connections to the game’s UDP port and to TCP 443 separately, and compare mtr -u -P (game port) with mtr -T -P 443 to see at which hop responses disappear
Confirmed if
Only in a specific country or ASN, UDP gets no first response or drops within a few seconds, while TCP 443 works from the same place. With throttling, UDP loss rises clearly only at peak hours and TCP is less affected
Ruled out if
TCP fails too: points to a path outage, IP blocking, or “DNS failures and delays.” Same in every country: our own server or firewall configuration. Loss only during traffic bursts, for UDP and TCP alike: “Policer drops excess traffic”
Check with
Infra tools (no game code needed)
Learn more
According to an IRTF survey document, packet inspection equipment may pick out UDP flows by address, port, and protocol and block them, or block everything except the protocols it allows (an allowlist). If the equipment decides based on only a few fields of the packet, even a small protocol change can get traffic blocked. In the early days of QUIC, one firewall let the first few packets through after a single header bit changed and then blocked the rest, so the client’s logic for falling back to TCP never kicked in. When launching in a new country, this can surface as reports that “it works fine in Korea, but players on some ISPs in that country can’t connect.” If it’s blocked only on one location’s network, such as a café or an office, see the “Public Wi-Fi and corporate network restrictions” entry.
Sources
RFC 9308: Applicability of the QUIC Transport ProtocolIETF Measurement studies show 3–5% of networks block UDP entirely, so UDP-based apps must accept connection failures or provide a TCP (TLS) fallback; firewalls may block ports that aren’t tied to a registered service
The QUIC Transport Protocol: Design and Internet-Scale Deployment (SIGCOMM 2017)ACM 2016: 4.4% of clients couldn’t use QUIC over UDP because UDP/QUIC was blocked or the path MTU was small (mostly behind corporate firewalls; no ISP-wide blocking observed); 0.3% were on networks that appeared to throttle UDP (higher loss at peak hours; down from 1% in 2015 after requests to ISPs); a case where a firewall let only the first few packets through after a 1-bit header change and blocked the rest, defeating the TCP fallback logic
RFC 9505: A Survey of Worldwide Censorship TechniquesIRTF Inspection equipment in the network can pick out and block TCP and UDP flows by address, port, and protocol (blocking of UDP endpoints has been observed with QUIC); allowing only approved protocols leads to overblocking, and throttling of specific traffic is also used
mtr(8) manual page sourcemtr Sends UDP with -u or TCP SYN with -T and sets the destination port with -P, so the route is measured with the same protocol and port as the game