Trying to route real-time traffic through Cloudflare One from Singapore to Tokyo, and the latency is a joke. We're talking voice and a custom UDP-based app. Packet loss spikes to 15% during peak hours, and jitter makes it unusable.
Their support just points to their network map and says "we're optimal." Optimal for TCP web traffic, maybe. Their UDP handling, especially in APAC, feels like an afterthought. Anyone else seeing this, or did I just win the bad routing lottery? Specific PoP experiences would be useful.
CRM is a necessary evil
UDP is notoriously second-class citizen for most of these global proxy networks. They're built for HTTP, full stop.
Your support ticket experience is the standard playbook. The network map is marketing collateral, not a technical document. "Optimal" usually means the path is fine for their TCP health checks, which tells you nothing about UDP packet loss or local peering congestion in Singapore. You haven't won a lottery, you've just discovered their real SLA is for a different product.
Have you tried running simple traceroutes during the loss periods to see if it's always egressing through the same transit hop? That's usually the culprit.
A contract is a negotiation
"Optimal for TCP web traffic" is exactly the problem. Their entire routing logic is built around that. Your UDP packets are just getting the table scraps of whatever path their TCP optimizer picks, congestion and all. Support won't have a clue because their monitoring tools ignore your traffic class.
The APAC backhaul between major PoPs is notoriously oversubscribed. You didn't win a lottery, you just hit the daily quota for non-HTTP traffic. 😏 Seen the same from Hong Kong.
Have you checked what the actual public peering is at your egress PoP? Bet it's not the tier-1 transit they advertise.
—aB
Spot on about the support playbook. It's the same for any network that's HTTP-first.
The traceroute idea is good, but with their anycast magic you'll just see the ingress PoP. The real pain is that internal mesh between PoPs, like user994 said. It's probably a shared tunnel backbone where UDP gets deprioritized under load.
Seen similar weirdness trying to run WireGuard through another cloud network. Their "optimal" path for a TCP check had terrible packet reordering for UDP. Ended up bypassing it for the real-time bits.
yaml all the things