Does WordPress.com block/limit traffic coming through CloudFlare?
What I don’t understand is why this worked (support for cloudflare) for quite a while, and then suddenly just stopped.
It looks like we retired the IP address that you had your A Record directed to. As WordPress.com is a cloud-based infrastructure, we cannot guarantee 100% uptime for every server or IP, but we can guarantee fairly solid uptime for the entire system as everything can easily fail-over to another server/IP. If you’re mapping to a specific IP, you’ll be left behind when that happens.
Your name servers are directed to Cloudflare, so your DNS is controlled by Cloudflare. We can’t control where your connection goes if it’s directed to a single IP, even if that IP has been retired. If you direct your name servers to us, we have control over the DNS, and that’s how we can redirect everything if a server or IP goes offline.
Moreover, even with cloudflare turned off to prevent any potential conflicts, my site availability was 69% and 72% (EU and US) over the past week, despite being pretty much 100% for a long time.
Turning off Cloudflare’s features don’t change anything. If your name servers are still directed to Cloudflare, it means you’re directed to a single IP here via an A Record, and that leaves you open to the same problem described above.
If you don’t want to support cloudflare, is there any plan to use something like nginx to speed up the sites, as response times on their own so-so.
WordPress.com actually runs on nginx.
Is there any way that we can get a few IP addresses to put into cloudflare, to bypass the DNS problem, and see if that is good enough to keep this going?
No, there are over a hundred of them, and we cannot guarantee their availability. We can pretty much guarantee the availability of the entire system and its fail-overs (moving traffic to another server when one fails), but we cannot guarantee the availability of one single component, which is why mapping to a single IP via A Record is a very bad idea.
There is a difference, of course, between “not supported” and “actively blocked.”
If WordPress does not support off-site DNS but does not actively block traffic coming through CloudFlare, the problem is with CloudFlare and we assume all risk for traffic routing because we choose to host our DNS entries in a non-recommended manner.
Even today, if we set our DNS entries on CloudFlare but do not enable any CloudFlare services, traffic flows to the WordPress.com blogs perfectly. This is true whether we use multiple A records or simply set a CNAME pointing customdomain.com to lb.wordpress.com.
When CloudFlare services are activated, all traffic to our blogs goes first through the CloudFlare servers for caching, additional statistics, etc., which means that it would appear to WordPress.com as though it were originating from the CloudFlare servers.
Or, depending on the type of malevolent traffic detection being used, it may appear to WordPress.com that the request is being spoofed.
What we’re trying to identify, since this problem is so new (remember that it has worked flawlessly for months for all of us), is whether WordPress.com servers are seeing the traffic from CloudFlare as potentially malevolent (or in violation of some terms of service) and actively blocking it. If so, we can either work toward or resolution or have WordPress.com explicitly state, “We do not allow traffic that comes from CloudFlare because [it triggers our network protection systems too easily|it violates TOS | we just don’t like it].” All of those are okay, so long as we know the policy and can make an informed decision.
If, on the other hand, you tell us “We do not and cannot support off-site DNS or services such as CloudFlare, but we do not block such traffic, either. If you choose to use CloudFlare, you are on your own for issues related to your domain’s traffic,” then we know that it’s time to push back on CloudFlare and let them know that you are NOT blocking traffic from their servers, and it’s time to point the finger away from WordPress.com and back at them.
Can you please help us determine which of those two is closer to the official stance, so we know what to do next?
Ah, looks like you replied while I was typing. I think that you’ve pretty well hit on what I was asking.
Just to clarify in case anyone else stumbles across this, we don’t block Cloudflare, but the IP address you were mapping to was retired.
So, it wasn’t blocked, it was just going quite literally nowhere.
What if lb.wordpress.com is a cname, as mentioned by @sparkanthology? Apologies, I don’t understand DNS in that much detail. This is actually how cloudflare suggest that this be done in their FAQs. Is lb the server that got retired? Could that work in theory, without being too disrputive to the approach you are using?
That’s the same issue, in this case it’s directed to a single server, not a single IP. It’s just as bad though.
We don’t support using CloudFlare for your WordPress.com site, for several reasons:
1. Their method of pointing your domain to your WordPress.com site requires using an IP address or specific server, which we don’t support. Your site does not have a static IP address or specific server. Instead, requests to load your site are shifted between several IP addresses and servers in order to balance the demand on servers. This means that specifying an IP address or server won’t work.
2. The features of their cloud-based infrastructure simply duplicate the infrastructure already being provided to you by WordPress.com, such as:
* CDN’s (Content Delivery Networks) that deliver your site content from the location closest to your visitor
* Caching/optimizing files for faster loading times
* Security measures protecting your site from denial of service attacks and other forms of hacking/malware
* Site stats, including search engine terms and incoming link referrers, that are easier to read than Google Analytics
You can direct your domain back to your WordPress.com blog by changing your name servers to:
If your domain is registered with us, you can change your name servers following this guide: http://en.support.wordpress.com/domains/change-name-servers/
If there are other features you were interested in using via CloudFlare, besides the ones listed above, can you let me know more about what you’re trying to do? I’ll be happy to help you learn more about the equivalent feature on WordPress.com.
The single most important feature (to me) enabled by using CloudFlare is Google Analytics. It provides a very different perspective into traffic statistics, and allows me to do detailed traffic-flow exploration that is simply not possible with WordPress site statistics (which I also use daily, as an overview).
WordPress statistics are improving; the addition of “Number of Visitors” was a huge step forward. However, they’re no match for the insights I gain with Google Analytics.
Yes, that’s one of the very few things that we can’t match at this time. We are working to improve stats though, and exploration-related stats are on the roadmap.
I’ve switched back to wordpress for DNS, albeit admittedly somewhat sad.
As you were kind enough to ask, I second the need for Google Analytics, as it’s much more than just basic analytics, including the ability to track by goals, use regex matching of paths, and much greater detail in terms of traffic sources.
Also, when I originally enabled cloudflare, I saw a massive drop in site latency, i.e. time to load. I realize there are a lot of moving parts in managing a massive operation like wordpress.com, and I am very grateful for what you provide.
Nonetheless, initially cloudflare let me get much better speed (4s down to 120 ms), without really bothering anyone either at cloudflare or wordpress, pretty much for free. I think this was before wordpress was doing nginx-type caching.
Even if the infrastructure was duplicated, it didn’t have a performance downside for users, and also it was providing an extra layer of redundancy (more anti-fragile in the Nassim Taleb sense). So overall, it was pretty much a big win, without needing to self host, so that I could focus on creating content rather than managing infrastructure in the time I have for the blog.
Thanks again for explaining the options.
We didn’t have stats goals on the roadmap, but I made note of it for consideration.
If you want more stats – Quantcast is built in – it does number of visitors, number of visits and Page views – if you have a mapped domain you need to request Quantcast to enable the counting – it does some other nice metrics also –
How disappointing, thanks for the response though.
Perhaps it’s finally time to move to wordpress.org. Google Analytics is invaluable.
I do appreciate the candor in your responses. I feel I should point out that it’s not a matter of trying to supplant WordPress services with CloudFlare, but effectively merge the offerings of WordPress and CloudFlare as paying customers of both platforms.
I wouldn’t even be using CloudFlare to get me that “last 20%” if WordPress.com didn’t already provide 80% of what I need, and CloudFlare means I don’t have to demand that WordPress.com add additional features while still providing me the perfect solution. For me, it’s mostly “easy DNS changes, email obfuscation, malware and bad behavior protection (I know WordPress does a good job of filtering traffic & spam, but CloudFlare prevents the traffic from ever reaching WordPress in the first place), and Google Analytics.” For other customers, the feature list might include any of the long list of supported apps enabled by CloudFlare.
Thanks again for your responses and for your consideration of customer needs!
(Also, thanks to auxclass for the Quantcast tip—I’ll be looking into that right away.)
the Quantcast hooks are built into WordPress.COM – it is just a matter of asking them to add your custom domain name – all I had to do was ask them and then be a bit of a pest as it took them a couple of three tries to get the stats working – I had to do nothing to my site here other than keep asking them each week what happened –
Never bothered to ask how things are done – I also Admin some blogs that are some-name.wordpress.com and the QuantCast stats just started working after a short time – sort of magic I guess
PS – the numbers are not supposed to be an educated guess – the page views are quite close to those from WordPress.COM stats – the people count is different –
remember all stats are a bit different – counting people – what is a new person? if a person visits your site today and the last time they visited was yesterday – is that a new person or new visit by a person that has been here before – what if the person last visited three months ago – new person or returning person?
I left out one other great features of CloudFlare I use so often I didn’t even think about it: page rules.
Instead of creating a slew of dedicated landing pages for maintaining hierarchy, or for managing semi-dynamic content, I love being able to specify (on CloudFlare), a page rule that automatically redirects http://SparkAnthology.org/contests/ to http://SparkAnthology.org/contests/one for our current contest; when the next contest begins, I would simply point the same address (http://SparkAnthology.org/contests/) to http://SparkAnthology.org/contests/two (which doesn’t exist yet).
Another example is http://SparkAnthology.org/support, which I print on business cards and automatically point to our current campaign (e.g. Kickstarter, Indiegogo, etc.) if there is one, or just to the static donation page when there’s not.
Is there any chance some sort of page rule/URL rewriting might become part of an advanced upgrade bundle on WordPress.com?
That probably won’t be coming to WordPress.com any time soon, but you could set /contests/ to just be a page that details the current contest, or lists the contests with the most recent one highlighted.
The same for the support page, list the donation details, but also highlight the current campaign on top.
The topic ‘Does WordPress.com block/limit traffic coming through CloudFlare?’ is closed to new replies.