OVHcloud's "global" CDN routes AU traffic to LAX, support says it's "optimal"

Hey folks! Gonna keep this short cause the data speaks for itself

Super stoked to share my distributed uptime experiment. I spun up three monitoring nodes:

• London — HostHatch VPS, 2€/mo
• Sydney — my mate's garage server (cheers dave)
• Seattle — Contabo dedi I've had forever

Ran httping against my OVHcloud "global" CDN endpoint for 31 days. Results?

EU: 12ms avg, zero packet loss
US: 45ms avg, solid
AU: 178ms avg... wtf?

traceroute from sydney hit california first. Always. Never singapore, never sydney. Asked OVHcloud support, they said "your traffic is routed optimally." nah fam, optimally for *your* bandwidth bill maybe.

Turns out their "APAC pop" is a cname to lax. My aussie users been hitting california for years and nobody noticed. I messed up not checking this sooner — fixed my dns to bypass their "global" network entirely.

Data's public, hit me up. Gonna set up proper rtt maps next month.

Those pings are clean

IMO this is more common than people realize. YMMV but I've seen similar with smaller CDNs that lease IP space and claim global presence without actual edge deployment.

Take it with a grain of salt, but your methodology seems sound. The three-continent baseline is something more reviews should include. I ran something comparable against GreenCloudVPS last year and found their "amsterdam" node was actually amsterdam with a geolocated IP. Not malicious, just... optimistic marketing.

Would be curious if you tested from south america or africa too. Those regions tend to get the worst routing surprises.

The virtualization tax on these CDN nodes is worth mentioning. OVHcloud runs OpenVZ on their edge from what I can tell — cgroup limits visible in /proc, no proper kernel isolation. You're sharing that 12ms Frankfurt latency with however many containers on an oversold host.

Not a knock on your test, just context. Bare-metal edge would show different tail latencies under load. I've measured 3-5x worse p99 on OpenVZ versus KVM or proper metal at the same price tier.

Their routing decision makes sense from cost perspective. Trans-pacific transit is expensive. California-to-sydney is cheaper than singapore-to-sydney if you have committed volume on the former. Still dishonest to call it APAC.

Anyway here's the thing

Ran mtr from a random oracle free tier in melbourne for giggles. Same deal. 14 hops to lax, then back across the pacific to sydney if the destination is actually local. Idk why I do this at 3am.

Host                                    Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. _gateway                             0.0%    60    0.3   0.4   0.2   1.2   0.2
 2. ???                                 100.0    60    0.0   0.0   0.0   0.0   0.0
 3. 192.9.200.1                          0.0%    60  178.2 180.1 176.5 245.3  12.4

That 192.9.200.1 is palo alto.

The real kicker? Some australian ISPs peer cheaper with US west coast than with each other. The internet is held together with twine and routing table folklore.

Great work on the monitoring setup! Before everyone rushes to change providers though — did you test your restore?

I mean: if you reconfigure DNS away from OVHcloud, do you have your origin IP documented? Your SSL cert chain? The 3-2-1 rule applies to infrastructure state too, not just files.

• 3 copies of your DNS config (primary, secondary, version control)
• 2 different formats (zone file export, provider API backup)
• 1 offline or cross-account

Seen too many people "fix" routing only to discover their origin can't handle direct traffic. Not saying that's you, just worth a checklist before the cutover.

178ms to a "global" CDN? That's not global, that's california with extra steps

What hardware is Dave running in Sydney?

I had the same issue with a "singapore" pop that routed through tokyo