I'm geographically located in Seoul, Korea and traffic to api.fmf.io always get routed via LAX servers. My server is located in Tokyo, Japan so it adds up a lot of delay on the request. Tried with different ISPs and all same result. My friends are also experiencing this with their free plan enabled website, but I'm also experiencing this in pro-enabled paid plans.
This lasted for a quite long time (over several month) and my friend got a response from CloudFlare rep. that it's a temporarily routing problem and will be resolved soon. However seems like this is not the case.. If this is not getting resolved, I'm considering and testing migration of all my company and personal paid plans to Fastly.
Attaching cdn-cgi results
Hi Minku,
Thank you for contacting CloudFlare support. Sorry to hear you're experiencing some network connectivity issues here. Your ticket has been assigned, and will be reviewed by a member of our network team.
To better troubleshoot this, please share the ticket # that your friend previously opened on this matter, as well as a traceroute + mtr in text format into this ticket.
Best Regards, [rep name]
Hi [rep name],
My friend’s ref # is [rep #].
Also attaching traceroute results for two domains.
(Moved traceroute result to traceroute-cloudflare file)
(Moved traceroute result to traceroute-apifmfio file)
I’m using Korea Telecom (KT) DNS 168.126.63.1 / 168.126.63.2, but nslookup/traceroute result is similar when I use SK BroadBand or LG Uplus.
Also attaching MTR results.
(Moved MTR result to mtr-apifmfio file)
(Moved MTR result to mtr-cloudflare file)
Found this on GitHub, seems like other people are experiencing this as well. cdnjs/cdnjs#3395
Hi,
Currently we're awaiting an increase in capacity from a provider in Seoul. Currently traffic is temporarily re-routed.
It seems as though your ISP prefers to transit you to LAX rather than somewhere else in Asia, due to where they have connectivity.
Once the routes are re-introduced to Seoul after the capacity upgrade, traffic should again flow to there.
According to CloudFlare status page, however, Seoul is listed as 'Operational'. If status page shows false results, what's the point of having status page?
I'm sad that I can't trust CloudFlare, which is such an awesome service and I recommended to friends a lot. Also, I have 2 paid domains (one on [my personal email], one on [my work email]) and it's too bad that CloudFlare didn't have any notices even to paid customers.
Hi,
"According to CloudFlare status page, however, Seoul is listed as 'Operational'. If status page shows false results, what's the point of having status page?"
Because not all traffic is affected in that manner & only some customers may be in the situation. And, as Marty mentioned, it may also be an issue with how ISPs prefer to connect due to things like peering arrangements that they have (we don't have direct control over this).
We will update you as soon as the circumstance changes on our end relative to the upgrades, and we hope that changes the behavior. Until then, however, there's nothing we can do to force it to route the way you want it to.
Regards, [rep name]
Hi [rep name],
"Because not all traffic is affected in that manner & only some customers may be in the situation." Normally, according to Statuspage.io and other companies', they classifies component's status into four different steps :
- Operational
- Degraded Performance
- Partial Outage
- Major Outage
Especially, Statuspage.io describes 'Partial Outage' as this : This component is partially down or is experiencing an outage only affecting a small percentage of constituents. (example: 1 of 25 file servers offline)
I believe many customers of CloudFlare will recognize current component's status with a similar thinking, and like me, will not understand if some group of customers are experiencing a problem while status page indicates 'Operational' status.
Also, the CF websites I looked into (including cloudflare.com and cdnjs.com) was all routed into far away region (LAX, SJC, HKG). There were no exceptions.
"And, as Marty mentioned, it may also be an issue with how ISPs prefer to connect due to things like peering arrangements that they have"
I tried major 3 ISPs in Korea, KT(Korea Telecom/Kornet), LG Uplus and SK BroadBand (Powercomm). KT usually routes CF traffic into LAX, LG Uplus and SK BroadBand routes traffic into SJC/HKG. Of course we can blame ISPs, but customers will blame us when CloudFlare says there is no problem on the network. Some people seems to contacted ISP, but their technical team mentioned that CF's Anycast DNS seems having a problem.
Anyway, if CloudFlare is not honest about some of their components' status (and no willing to change it), it means I can't rely on CloudFlare. If CloudFlare made a honest notice on status page and claims that ICN edge has a bit of problem, the situation would be much, much better.
This network problem is spreading into Korean web communities, and I'm sure people's opinion on CF will get even worse in Korea before it gets better.
[ticket marked as solved]