How to run Workers on specific datacenter colo's?

Cloudflare doesn’t care if your proxy is turned on or off, they just serve/proxy requests hitting their network for zones setup on their platform. There are exceptions but thats one point you need to know for this demo.

When a Worker makes a sub-request to the same hostname it will resolve to the IP of that record even if its proxied. For example if your public DNS record is proxy-off but you use cURL to force the connection to hit Cloudflare then the worker is invoked and sub requests will resolve that hostname to the IP; and for example if your DNS is proxy-on then requests should naturally hit CF first and sub-requests will resolve to the IP.

You can use the resolveOverride property on fetch for sub-requests to force resolution to a hostname while maintaining the host header so in-effect this is a way to force connection on a specific IP.

With Cloudflares Anycast IPs that are front-facing for proxied domains, you cannot force a TCP HTTP connection to a specific datacenter but as I said in point #1 that CF will respond to requests for you zone that hit their network so is there other IPs we can try that are for specific datacenter location?

Well after scanning for IPs in the Cloudflare ASN and I found hundreds of these IP starting with 8.x.x.x that appears to be used for WARP. These IP’s are used for specific COLO.

So like in point #1, can you also force the connection to a 8.x.x.x and Cloudflare will handle it? No, from outside the network you cant. Cloudflare must have some kind of security rule to prevent HTTP connections on these IP’s. You can ping them but you cant connect (with exceptions).

We already know that Cloudflare applied different levels of trust for traffic hitting their network, and that requests being made by Workers are evaluated to going through the front-door or going to origin. So knowing that we have different levels of entry in the traffic flow of Cloudflare’s network, can we hit these 8.x.x.x IP’s from a Cloudflare Worker? YES!

Theres a few elements here that are valuable information to an attacker, and illegitimate use:

  • Can send traffic to specific colo
  • Can get around geo-restrictions.
  • Can go back through the front-door.
  • Can appear to have traffic from WARP but fake your IP address as literally anything.
  • Can loopback requests with unmetered egress
  • Break out of the 50 sub-request limit, potential for exponential request attacks.

Mix and match these points and you have potential for numerous attacks or your platform being used for illegitimate use.

1 Like

Hi user2765,

Thanks for your video. I’ve raised this with the appropriate team who are looking into it.

With regards to where your initial connection is being handled: connections to Cloudflare from China are generally, but not exclusively, handled outside of China. Websites hosted from China, and that includes those that are using our China Network, are required to have, and display, an ICP license at all times. This is one among a number of reasons that the China Network is exclusively available for Enterprise customers. You can read more on that here

Best regards,


@wouter, I am fully aware of the Cloudflare China Network but that is aside from the point of this video.

This video is about the ability for you to control which colo your Workers are executed in and apply controlled routing within your network; I don’t believe this is supposed to be in the users control.

I did raise this as a bug report but the case was closed without discussion.

@user2765 yes, that is what the “I’ve raised this with the appropriate team who are looking into it” was about.

However at the beginning of your video you mention that we could somehow handle your request in China, quoting “they really could fix it, they haven’t”.

Oh, that was in reference to Cloudflare’s network performance & reliability issues in China (well outbound of China). You guys could massively improve performance & reliability with a few changes of your network architecture.

Always happy to hear suggestions :slight_smile:

Pass my info onto the right team and they can setup a call with me

@wouter I didn’t hear anything back on this

The resolution to the issue shown in your video is still in progress. Thanks again for reporting it.

You’re welcome to post suggestions for our network w.r.t. China in this thread.

Please open a ticket and include me so I can communicate further details which were not included in this post, and ensure the people handling this understand.

I made efforts to report this bug on 2 occasions; you guys finally acknowledge this so I should get compensated for my efforts. I could have just given up the first time and sold this information elsewhere.

I have pointed out issues & opportunities on multiple occasions but the persons who respond do not have the necessary knowledge and experience to understand why something is an issue, let alone understand the solutions.

I have an ongoing ticket for almost a year which the assigned “engineers” demonstrate a complete lack of understanding, time and time again, that ticket being just one example why I need to make sure I speak to the right person or else I’ll just be wasting my time.

Hello @user2765,

Any compensation for bug reports is handled through HackerOne. Unfortunately your report for this bug was closed as duplicate as it had already been reported by someone else. Please refer to HackerOne for the details of the program.

What ticket are you referring to exactly? The hCaptcha issue?

1 Like

Wait I need to sign in to hacker1, I only saw an email notification last week, it was closed without discussion.

I’ve read their message. They said it was already reported through other channels awhile ago. Since they said “awhile ago” does this means someone at Cloudflare has had the chance to review all the details and impact of this? Are they aware of the issue that build upon this bug to fake any IP and fake any host header?

Sure use that hCaptcha one for example. You read that ticket and you’ll find that its not only about hCaptcha anymore but rather Cloudflare too. Over 6 months since I advised that and, and are still down.

Unfortunately they (whoever they may be, someone/something at the local ISP level presumably) are actively interfering with DNS requests for those domains, and aside from trying to contact them (which we are doing) there is not much else we can do.


This post was flagged by the community and is temporarily hidden.

Right. Well, good luck!