CloudFlare is not blocked in China. A handful of IPs could be potentially, but if you're seeing something indicating that I'd recommend contacting our support team.
The GFC (Great Firewall of China) also changes daily (or sometimes hourly) so it's entirely possible whatever may have been an issue at one point in time has already been addressed.
If you're referring to making different origin calls based on the geographic region -- such as when we go back to your origin for a request hitting our LAX data center if you happen to have an origin near LAX we'd use that origin specifically versus your other origin which might be located in let's say LHR. We currently only support that functionality for our higher end enterprise contracts. The functionality will likely to be available for other plan levels in the future though.
anycast does not route to the geographically nearest datacenter but the topologically nearest. anycast is great, but it isn't magic.
I get it: you have marketing folks that probably specifically told you not to delve into the details but let's face it..."anycast routes it to the nearest datacenter automatically!" isn't completely true.
Hey, this brings up a good point for some more clarification.
There are two common ways CDNs do routing:
method 1) by using a customized dns server (like the one I used in the example) that responds differently to the resolvers end users use. You can use something like Maxmind (like I did in the example) to determine where you think that resolver is.
method 2) you can use anycast all the way to the TCP level for terminating traffic to ports 80 and 443. This is the most common way we do it at MaxCDN.com. We find it to be the fastest.
To do method 1 you can use the Go GeoDNS server from github (and there's one in PERL) or you can use a service like Dyn.com, DNSMadeEasy (only has broad geo), NSone.net, Verisign's DNS product or Cedexis (which can also incorporate latency data). One thing to keep in mind with doing DNS based routing is eDns for the big public DNS providers. The downside is that you can only respond by the resolver or edns subnet someone uses which can lead to a lot of inaccuracies. The big pro about method 1 is it's easy to deploy and it's easy to balance traffic if a PoP gets over loaded since it's just DNS records.
Anycast (Method 2) is great and fast, but it is high maintenance. We've spent a lot of time tweaking this over the past 4 years at MaxCDN. I've heard you can announce anycast blocks with ServerCenteral and Internap, but I haven't tried it. I've done it with Softlayer for testing. You need to have your own /24 to do it with them. We have our own infrastructure and several upstream providers. The biggest challenges with anycast are dealing with Asia (to make sure routes don't trombone) and traffic management since you can't control where traffic goes.
"anycast does not route to the geographically nearest datacenter but the topologically nearest."
That is correct, and as you point out in a later comment -- in roughly perhaps 85-90% the geographic route and the topological route will be identical and ideal. In the other 10-15% cases some additional network engineering can be done to work with a problem ISP to correct the less than ideal routing for a customer.
Good point. In my testing of CF, I couldn't get my requests route to nearest datacenter though CF status page indicated green for datacenters near my request origin. It always routed me to SJC irrespective of which location the request originated from in US.
yeah, if you're only controlling one side of the conversation you just have to deal with the limitations. We use a lot of data from RUM measurements to further tune things.
That being said, if you control both sides you can do some better stuff (ie: Aspera, Netflix clients, etc) you can really ensure accuracy. Please feel free to post any good links to this stuff.
before you gleefully skip into the panacea geo-DNS has been marketed as, please take a quick skim of this 2009 paper[1] from microsoft research about mobile clients and geolocation.
has it gotten better in five years? is an exercise left for the reader :)
This geo-DNS is related to finding Cloudflare's servers, not finding your servers. I love and use Cloudflare but their support for Route 53 like multi-host configurations (health checks, latency, etc) is pretty bad (I think they only support roundrobin cnames).
Disclosure: yes, I work at CloudFlare but the previous details are simply facts.