One late evening, I moved a backend for one of my apps over to Cloudflare Workers, and every Gemini API call started failing with 400 INVALID_ARGUMENT: User location is not supported for the API use. The same code worked fine from my Mac. Only the deployed Worker was failing — universally.
When local and remote behave differently, your morale takes a real hit. I've been shipping personal apps since 2014 — somewhere north of 50 million cumulative downloads at this point — and "environment drift" still wears me down every time. So I want to leave a clean, ordered triage flow that I now reach for whenever this error shows up.
Why this error actually appears
User location is not supported for the API use means that the Gemini API decided the source IP of your request belongs to a region it does not serve. The Gemini Developer API (api.generativelanguage.googleapis.com) has an explicit list of supported countries, and requests from outside that list are rejected with HTTP 400.
The frustrating part is that "Japan is supported" — yet the error fires anyway. The cause is almost always one of these:
- Cloudflare Workers' egress IP looks like a non-supported region to Google
- Vercel / Netlify Edge Functions routed your request through a PoP in another country
- A VPN or proxy is rewriting your egress IP
- The Google Cloud billing region tied to your service account points outside supported zones (when using Vertex AI)
The right first step is to find out, from Google's perspective, where your request actually came from.
Step 1: Make the egress IP visible (the first 30 seconds)
Before anything else, find out what region your server's outbound IP is mapped to. I usually drop a tiny endpoint into the Worker for this:
// Check the egress IP your Cloudflare Worker is presenting
export default {
async fetch(req: Request): Promise<Response> {
const res = await fetch("https://ipinfo.io/json");
const data = await res.json();
return new Response(JSON.stringify(data, null, 2), {
headers: { "content-type": "application/json" },
});
},
};
// Expected output (sample):
// {
// "ip": "104.16.xxx.xxx",
// "city": "...",
// "country": "...",
// "org": "AS13335 Cloudflare, Inc."
// }If country shows up as anything other than what you expect (US, SG, etc. instead of your home region), you've found it. Cloudflare Workers run from the closest edge to the user, but the egress IP your Worker presents to Google can resolve to a completely different data center country.
Step 2: Switch to Vertex AI (the most reliable fix)
The recommended long-term fix is to migrate from the Gemini Developer API (generativelanguage.googleapis.com) to Vertex AI (aiplatform.googleapis.com). Vertex AI lets you pin a Google Cloud region — asia-northeast1 (Tokyo), asia-northeast2 (Osaka), us-central1, etc. — so the destination side becomes deterministic regardless of which edge your call leaves from.
# Pin a Tokyo region with the Vertex AI client
from google import genai
client = genai.Client(
vertexai=True,
project="your-gcp-project-id",
location="asia-northeast1", # critical: explicitly choose a supported region
)
response = client.models.generate_content(
model="gemini-2.5-flash",
contents="Summarize the Vertex AI migration steps for an indie developer in three bullet points.",
)
print(response.text)
# Expected output (summary form):
# 1. Create a GCP project and a service account
# 2. Enable the Vertex AI API and configure ADC
# 3. Switch the client to genai.Client(vertexai=True, location="asia-northeast1")The one extra hurdle is authentication. Vertex AI does not accept API keys; it requires Application Default Credentials (ADC). If you get stuck on service-account permissions, the Vertex AI + Gemini auth error guide covers the failure modes I've seen most often.
Step 3: Move the call to a region-pinned origin
If migrating to Vertex AI right now isn't realistic, the pragmatic answer is to route only the Gemini API call through an origin that is guaranteed to leave from a supported region. Three patterns I've shipped on small apps:
- Cloud Run in
asia-northeast1as a proxy: the Worker accepts the request, then delegates the model call to Cloud Run - Vercel Functions on the Node.js Runtime: switch the route from Edge Runtime back to a regional serverless function
- A tiny Node server on Fly.io's
nrt(Tokyo) region: a few hundred yen per month is plenty for low-volume work
The deciding factor is "request rate × latency budget." Unless you need real-time, sub-second turnaround, the Cloud Run or Fly.io combination handles it without drama.
Step 4: When the same error has a different cause
Sometimes the egress IP is clearly in a supported region and the error still fires. The easy thing to miss here: the Google account that issued your API key may itself be tied to a non-supported region through stale billing-address metadata.
Places to verify:
- The country shown in your Google AI Studio account settings
- The billing address on the Google Cloud billing account (when using Vertex AI)
- API keys that were originally issued under a non-supported region
In every one of these cases, rotating the API key under a clean account is faster than chasing the metadata. From experience, three hours of debugging often loses to ten minutes of issuing a new key.
Step 5: The last lever
If nothing above resolves it, suspect the SDK version × model combination. Some preview models in the Gemini 3 line are restricted from certain regions even when stable models work fine.
# Confirm and bump the SDK
pip show google-generativeai
pip install --upgrade google-generativeai
# Drop back to a stable model (gemini-2.5-flash / gemini-2.5-pro) and retry
# Expected: if it now passes, the preview model itself was region-lockedThis is the order I keep going back to whenever this error reappears. The goal is "keep the app running for the user," not "always run the bleeding-edge model" — letting that priority lead makes the decisions faster.
What to try right now
If you're stuck on this error tonight, just do Step 1 first — five minutes of egress-IP visibility. If country is anything other than what you expected, skip to the Vertex AI migration; you'll spend less total time getting to a stable production setup. To weigh the migration trade-offs, the Gemini API vs. Vertex AI comparison guide is a useful sanity check.
After more than a decade of running apps as a one-person operation, "environment drift" errors are still the ones that quietly burn the most hours. I hope this saves yours.