Cloudflare Workers on Free plan


#1

The cloudflare workers page boasts “Run JavaScript Service Workers in Cloudflare’s 150+ data centers around the world. Modify a site’s HTTP requests and responses, make parallel requests, or generate responses from the edge.”

However, using the free plan I highly suspect we are only limited to a handful of edge locations. For example, from Australia I am served a cloudflare worker from Hong Kong (200ms!) instead of a local one, and from Sweden I am served a cloudflare worker from Berlin (only about a 30ms difference) instead of one from Sweden or Denmark.

I really believe I am being jimmy’d here


#2

Then it might be time to move on :wink:

First of all, you are referring to two distinct and unrelated issues. Routing and the ability to run JavaScript on Cloudflare’s infrastructure. Your title refers to the latter whereas you seem to actually address the former.

Second, in the past free plans did not have access to all datacentres but that should have changed recently (except for China AFAIK), though I also still read some contradicting responses. In any case the routing is mostly up to your ISP and particularly in your Swedish case it is probably something you need to take up with your ISP.


#3

I know it’s not a routing issue because if I visit https://www.cloudflare.com/cdn-cgi/trace I get a local PoP, whereas on my free plan it will put me on Hong Kong


#4

Fair enough, as I mentioned free plans should have access to all PoPs (except for China) but I did read contradicting responses as well (this one is one more).

Maybe contact support or @cloonan and/or @cscharff can shed some light.


#5

Though you said “Hong Kong”. What happens when you open Cloudflare from the Swedish location? Are you still not routed to the Swedish PoP? If you are, the HK issue is simply the Chinese exclusion and easily explainable.


#6

Connecting from an Amazon EC2 in Stockholm I get a PoP in Berlin (for my worker)

And again, visiting https://www.cloudflare.com/cdn-cgi/trace from my EC2 I get Stockholm as the PoP


#7

Alright, that should not happen as far as I understood the PoP announcement.

Support or @cloonan/@cscharff


#8

Sorry I’m not sure sure what “am served a cloudflare worker from” means or how you are determining that? Are you saying the cdn-cgi/trace for your zone is reporting that location?

Can you provide a traceroute? For each?


#9

I’m determining the cloudflare worker’s location by performing a fetch to https://www.cloudflare.com/cdn-cgi/trace within the worker

and I get a response like such

fl=23f176
h=cloudflare.com
ip=2a06:98c0:3600::103
ts=1546091972.694
visit_scheme=https
uag=
colo=HKG
http=http/1.1
loc=GB
tls=off
sni=off

And here’s an MTR from myself to the my host which has the worker

|------------------------------------------------------------------------------------------|
|                                      WinMTR statistics                                   |
|                       Host              -   %  | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
|                             192.168.1.1 -    0 |   21 |   21 |    1 |    2 |    3 |    3 |
|                             10.20.25.96 -    0 |   21 |   21 |   10 |   12 |   16 |   15 |
|      per-apt-stg-crt1-be100.tpgi.com.au -    0 |   21 |   21 |   10 |   12 |   17 |   15 |
|       nme-apt-bur-crt1-be60.tpgi.com.au -    0 |   21 |   21 |   67 |   72 |   83 |   74 |
|      syd-gls-har-crt1-be-10.tpgi.com.au -    0 |   21 |   21 |   66 |   71 |   78 |   77 |
|      syd-gls-har-int2-be100.tpgi.com.au -    0 |   21 |   21 |   65 |   68 |   77 |   77 |
|               cloudflare1-100g.hkix.net -   58 |    7 |    3 |    0 |  198 |  198 |  198 |
|                           104.27.187.65 -   58 |    7 |    3 |    0 |  202 |  202 |  202 |

and my EC2 to my host with the cloudflare worker

HOST: ip-172-31-33-100            Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
  2.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
  3.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
  4.|-- 100.65.1.129               0.0%    10    0.7   1.7   0.4   8.3   2.4
  5.|-- 52.93.142.151              0.0%    10    3.3   5.7   2.5  16.9   4.8
  6.|-- 52.93.145.184              0.0%    10    7.9   3.7   2.8   7.9   1.5
  7.|-- 52.93.144.61               0.0%    10    3.5   4.4   2.6  10.5   2.3
  8.|-- 100.91.179.252             0.0%    10   25.2  24.8  24.4  25.3   0.3
  9.|-- 52.93.130.35               0.0%    10   24.3  24.4  24.3  24.4   0.0
 10.|-- 52.93.39.80                0.0%    10   31.5  29.0  24.8  34.2   3.1
 11.|-- 52.93.39.69                0.0%    10   24.4  24.4  24.3  24.7   0.1
 12.|-- cloudflare.ber.ecix.net    0.0%    10   24.3  24.4  24.3  24.8   0.1
 13.|-- 104.27.186.65              0.0%    10   24.3  24.3  24.3  24.3   0.0

#10

:confused:

Was there yet another shift in the geopolitical landscape I did not notice?


#11

The cloudflare workers seem to have their loc=GB always


#12

I originally understood you got those traces directly from the edges in your browser. Now it seems you are requesting the trace URLs from within a worker. Is that correct? If so I’d assume the request should typically stay within its own datacentre. Just speculating though -> @cloonan


#13

Can you provide the cdn-cgi/trace output from the same machine to cloudflare.com and your.domain? Same machine to both sites?

The colo is part of the initial request itself as is the country of the visitor(https://developers.cloudflare.com/workers/reference/request-attributes/).


#14

To my host (from my pc)

fl=23f103
h=obscenegaming.net
ip=194.223.x.x
ts=1546095386.997
visit_scheme=https
uag=Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36
colo=HKG
http=h2
loc=AU
tls=TLSv1.2
sni=plaintext

and to cloudflare.com (from my pc)

fl=84f12
h=www.cloudflare.com
ip=194.223.x.x
ts=1546095425.075
visit_scheme=https
uag=Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36
colo=PER
http=h2
loc=AU
tls=TLSv1.2
sni=plaintext

#15

loc is country for the client IP address
colo Cloudflare datacenter

IPs change hands often and I believe Cloudflare has a provider for this information, which might provide take some time to update.

The datacenter varies in a number of factors, it could be peering or load… Cloudflare might prioritise datacenter allocation depending on your plan.