Brother, thank you for the reply, I am from India and i have installed an extension in my google chrome browser name “Claire” it helps me to see which POP is getting used to route me. My server is in India and me too, But i am getting POP’s from Singapore.
I will ask few of my clients tomorrow and update/reply in this ticket. I will ask them to check that from where they are getting POP’s/Routed. I mean if they are from Sydney, Australia then are they getting routed from Sydney, Australia or Hong Kong or Singapore.
Thank you once again for helping us out in this community forms/tickets.
Hi, I’m on a Pro plan with an Australian site, my traffic still seems to be routing via SIN and LAX, can you please advise. (I’ve checked this from both Telstra and Optus connections)
Bandwidth in Australia is expensive for Cloudflare, you can only use their Australian PoPs if you are on Business or Enterprise plan. You can complain about that to Australian ISPs, AFAIK Cloudflare can’t do anything about that until they have more affordable bandwidth from locla ISPs.
I’ve seen and read about this, however about 3 weeks ago, in this thread, a Cloud Flare official (cscharff) noted that they now support all regions except China in their CDN with peering.
i have a similar problem till now, which my origin is in Hong Kong, and I am in Hong Kong, however i was routed to either SIN and FRA, SIN is still good to me, however FRA is too far from Hong Kong.
And i have found that that, the route is different when using Chrome and Safari under the same computer.
But i got the other domain which also in Hong Kong and front by Cloudflare, and which is correctly routed to Hong Kong.
How can i solve this issue? i have already paid the argo, and traffic steering in the load balancer.
I think that’s different. Unless Hong Kong is treated as a regular POP, the China network is only available to Enterprise customers that have an ICP license (required to serve content from inside China).
hong kong is not part of china in terms of network, it is not protected by the great firewall, and hong kong does not require a icp. and it must be a regular pop.
I too am based in Hong Kong.
I have two servers in Germany, each with a different host.
One connects me via HK pop and is therefore super-quick.
The other server insists on colo via Japan (NRT) and is really slow.
Is there anything I could do, or try to force my 2nd server to colo via HK? (It is actually the most important server to have quick access from HK).
Has there been any confirmation as to whether or not Argo solves the routing by cost issue we’re facing in Australia. We’re on Pro plan and our Sydney located infrastructure is routing via Tokyo today… Hong Kong last week… etc.
As far as I know and have read the issue here is not longer on Cloudflare’s side, all plans have access to all POPs, excep maybe for some temporary conditions (failures/DDoS/high loads). ISP choose where to send your traffic. To test things out you should try to see where Cloudflare’s homepage is served from and/or 1.1.1.1 replies from. Those are definitely available on all POPs (especially the former as its IPs are not being abused).
It’s been suggested this is an ISP issue rather than Cloudflare. Is this true?
If we move to the Business Plan (ie. 200USD monthly) will this ensure local peering or not? Can we get a definitive answer from someone at Cloudflare?
We’re at a point where we are looking at moving everything to AWS Route 53. But I really would prefer to stay at Cloudflare if there is some sort of solution available.
Yes, it’s most likely that since as far as I know and have been told by Cloudflare’s Team (there is a post somewhere in this thread about this by @cs-cf) all plan levels have access to all POPs (except China) on a general basis. There could be instances, but those are temporary are really rare, where for reasons a POP might be limited to high tier plans (Enterprise has priority, then Business, Pro and Free).
ISPs can decide what to do with packets they receive, so if the cheaper (or less congested route) for them is sending all traffic to Tokyo for Cloudflare’s IP ranges they can and most likely will do so. This is usually solved with direct peering, but - assuming this (Bandwidth Costs Around the World) is still valid, which I expect to be, even if to a lesser extent - are rare to set-up and have with the ISPs down under.
I unfortunately have only two solutions, both of which won’t be ideal, but unless you can get the ISPs to fix it (and I doubt in the short term) we are here.
Stay on Cloudflare, but move the AWS infrastructure closer to the actual POP from Cloudflare (ie. Tokyo), it would prevent double roundtrips for most traffic while most likely improving worldwide latency (Australia is a bit far from everything else). This basically halves the latency, while retaining caching and protections from Cloudflare, Argo won’t really help much then since the improved part is Cloudflare’s POP ↔ Origin. In this case you could probably think if maybe moving some of the infrastructure to Workers could help (reduce latency, still from Tokyo unfortunately, costs and improve availability).
Leave Cloudflare moving everything to AWS. It would increase costs (higher bandwidth for sure, most likely additional server capacity), but definitely lower latency to Australia. In this case ISPs don’t have the option to direct traffic off of Australia since that’s the only place the content is. It would have no DDoS protection, no WAF, no caching and no improvements on the worldwide market, but it depends on the target audience.
Unfortunately I don’t really see a good answer unfortunately, but Cloudflare can’t do anything. I am in some ways in the same boat as you where my ISP prefers a POP 3x times farther (latency wise) than the closest one. Luckily it’s only a handful of milliseconds in my case.
Decided to pony up the $200 per month on the domain and see if it made a difference. I can report that the Business Plan absolutely does fix the issue.
As soon as the plan is activated Australian requests are routed directly.
Could be a IP range issue or something about those POPs that have probably more load than average then. No reason to suspect that what @cs-cf wrote about all POPs being available to everyone is wrong.
up the $200 per month on the domain and see if it made a difference. I can report that the Business Plan absolutely does fix the issue.