1

Type

New feature

Description

Do not put Cloudflare Workers in regions which are typically not allowed to access LLM APIs

Benefit

Currently I am in a region (Melboure, Australia) which is allowed to access the Google Gemini LLM API:

However when I access workers (across different domains and accounts), I can see that the workers I am connecting to reside in Hong Kong (colo: HKG), which is 4,600 miles away from me.

Hong Kong is NOT allowed to access the Gemini API, so Google returns this error when we try ti access its Gemini LLM API from both a Workers and via the AI Gateway:

“User location is not supported for the API use.”

With LLM API adoption growing, this problem will only get bigger.

A potential solution is being able to mark a worker as an “AI API worker”, whereby Cloudflare should then avoid placing the worker in a region which is typically not allowed to access LLM / AI API services (as long as the HTTP client is also in a typically-allowed-access region).

2

@user4841 did you ever figure out a solution or workaround for this?

Hi Cloudflare Team, any workaround to this issue?

We are based in Singapore and Philippines but our API calls the worker get routed to HKG servers most of the time and gets blocked by open ai. This only started happening recently with Cloudflare and its not right, as we are not even residing in the restricted regions .

Please help to put a feature to resolve this, or will will cancel our worker subscription

Have you tried using Smart Placement?

Thanks for the suggestion!

Yes we enabled it, unfortunately did not work for us. after testing for a day, the calls from Philippines/Singapore still gets routed to HKG intermittently.

Will be great if there is an option to opt out of LLM forbidden locations, else we wont be able to use worker for our AI workflows.

6

I really hope this gets addressed. Tried OpenRouter, but it didn’t work, because even their API seems to be on Cloudflare (lol)

Most viable option for me right now seems to be moving away from CF for deployments.

Any alternatives that you guys found?

This needs ot be addressed soon. We should have a way to restrict putting the worker in some regions.

9

This is so critical…
Any workaround for the situation?
I’m seriously considering about moving away from CF because of this issue.

10

Make the request from inside a Durable Object created with a location hint for say WNAM if the Worker is running in a PoP you don’t want to use.

11

I have a perfect solution for this issue:

 1. Build a proxy on a VPS at an allowed location.
  1. Check the request.cf.colo value.

If the request is from a forbidden cc datacenter, make a request to your proxy at step one. If not, make a request to the official api.openai.com

12 

const openaiUnsupportedColos = [
			// BY - Belarus
			'MSQ',
			// CN - China
			'SHA', 'PEK', 'SZX', 'CTU', 'HGH', 'TNA', 'CKG', 'CSX', 'DLC', 'FOC',
			// HK - Hong Kong
			'HKG',
			// MO - Macau
			'MFM',
			// RU - Russia
			'DME', 'LED', 'OVB', 'SVX', 'KJA',
			// VE - Venezuela
			'CCS' 

			// REMOVED (No Cloudflare Edge in these countries):
			// CU, IR, KP, SY
			];

const cf = request.cf as IncomingRequestCfProperties;
const cfColo =cf?.colo;
if (cfColo && nonSupportedCFColos.includes(cfColo)) {
   console.log(`Notice: Non-supported Cloudflare colo for provider ${provider}: ${cfColo}`);
  return "https://your_proxy_address.com/v1/chat/completions
} else {
  return "https://api.openai.com/v1/chat/completions"
}