I measured why AI APIs "don't work" from Saudi Arabia

Ask anywhere why an AI service doesn't work from this part of the world and you'll get the same three words within about a minute. Use a VPN.

I got tired of guessing, so last night I measured it. Every major AI API, three requests each, from my desk in Saudi Arabia.

They all answered.

The measurements

Three requests per endpoint, averaged, taken on 26 July 2026 on ordinary residential fibre. The status code is the interesting column — not the speed.

A 401 means "I heard you, you're not authenticated." A 405 means "I heard you, wrong method." Both of those are the server talking. Neither is a block.

Nothing on that list is unreachable from here. Not one. And I've watched people spend a weekend and a subscription trying to fix a network problem they never had.

If the server answers with any HTTP status at all, your country is not the thing standing between you and that API.

Four different problems that all get called "blocked"

Once you stop assuming it's the network, the actual failures separate cleanly. I've hit three of these four personally.

1 — The signup country list. Some services only accept accounts from a published list of countries. You never reach an API error because you never get an account. This has nothing to do with your connection and everything to do with a dropdown.

2 — The payment method. The most common one, and the most quietly infuriating. The account creates fine, the API works fine, and then the card is declined at checkout because it was issued outside the billing regions the processor accepts. Your code was never the problem.

3 — A genuine service-level restriction. These exist, and when they happen you get a clear error from the service naming the reason. If you're guessing, this isn't what you have.

4 — Distance. Real, measurable, and the one everyone ignores because it doesn't produce an error at all. It just makes everything slightly worse until you assume that's how the tool feels.

The sixty-second diagnosis

Before you buy anything, run one command against the endpoint you think is blocked:

curl -s -o /dev/null -w "%{http_code} %{time_starttransfer}\n" https://api.example.com

Read the first number.

Any 2xx, 4xx or 5xx — you reached the server. It is not a network block. Go look at your account, your key, or your billing.

000, or a timeout — the connection never completed. Now you have something a network-level tool could plausibly address.

That single number separates "I need a different card" from "I need a different route," and those two problems have nothing in common except how they feel at 1am.

The routing result I did not expect

Since I had the harness open, I measured the same AWS service across four regions. Same three-request average, same machine, same minute.

Mumbai is roughly half the distance to Frankfurt from here. It answered twice as slowly.

Packets don't travel as the crow flies; they travel along cables and peering agreements, and those don't care about your intuition. If you've been choosing regions off a map, measure instead. It took me four minutes to find out my nearest-feeling region was my worst one.

So what does a VPN actually fix?

Exactly one of the four problems above: number four, and only sometimes. Routing your traffic through a better-connected exit can genuinely beat your ISP's default path. It's also easy to make things worse — you're adding a hop.

Here's the part I want to be blunt about, because the internet is full of advice that skips it.

A VPN does not fix your payment method. Your card's issuing country doesn't change because your traffic took a detour. This is the single most common reason people in this region can't buy an AI tool, and it is the one thing a VPN is completely powerless against.

And using one to misrepresent where you are, to get around a signup restriction, is a bad trade. Not because of some abstract principle — because of what happens next. Terms of service generally prohibit it, accounts get suspended when the billing country and the login pattern disagree, and if you're building anything that eventually pays out, that mismatch surfaces at exactly the worst moment: verification, or payout. I've seen enough affiliate and platform accounts die on identity mismatches to treat this as a real risk rather than a technicality.

If a service genuinely isn't available where you are, the honest answers are to use one that is, or to wait for it. Neither is satisfying. Both beat losing an account with money in it.

Where I do use one

Two jobs, and both are legitimate.

Seeing my own product from somewhere else. I write for an American audience from a chair in Saudi Arabia, which means I have never once loaded my own site the way most of my readers do. I wrote a whole article about what that hides — currency detection, consent banners, CDN edges, region-gated third-party scripts. Being able to sit in another country for ten minutes is the difference between assuming that's fine and knowing.

Untrusted networks. Airport, hotel, café. This one isn't clever, it's just correct.

For that I use NordVPN. Being straight with you about the depth of that recommendation: I've used it for regional testing and on public networks, not for two years of exhaustive throughput benchmarking, and this article would be dishonest if it implied otherwise.

What I'd actually tell you to check, whichever provider you pick:

Server locations that match your users, not a big number on a landing page. Fifty countries you'll never test from is worth less than the three your traffic actually comes from.

A real kill switch, so a dropped tunnel doesn't quietly put you back on the café's network mid-session.

An audited no-logs claim. Anyone can write "no logs" on a page. Independent audits are the only version of that sentence with weight behind it.

A refund window long enough to test properly. You cannot evaluate a VPN in an afternoon; you need a week of ordinary use to know whether it's in your way.

The checklist

Next time something "doesn't work from here," in order:

Curl the endpoint. Read the status code. If you got one, stop blaming the network.

Check the signup country list before you write a line of code against a service.

Check what payment methods it accepts before you build on it. This will save you more evenings than anything else on this list.

Measure your regions rather than picking the one that looks closest.

Then, and only then, consider whether a network-level tool helps — knowing it addresses one quarter of the problem space.

I lost more time to assuming I was blocked than I ever lost to actually being blocked. The measurement took four minutes and I should have run it a year ago.