CloudFlare, We Have a Problem
Ohhh boy.<p>&gt; Single-homed bandwidth can be gotten for $0.35&#x2F;TB, DDoS mitigation services are plentiful and sometimes even provided by default, and the web is generally Fast Enough.<p>This only works when you&#x27;re buying _a lot_ of bandwidth or you&#x27;re buying cheap bandwidth (which usually has sub-standard routing). If you host your app servers on a standard cloud like AWS you&#x27;re paying dollars per TB (but you&#x27;re on a damn good network). DDoS mitigation services in many cases consist primarily of &quot;we&#x27;ll blackhole your IP if one happens&quot;. DDoS mitigation services that are affordable and leave your site running are costly.<p>The web is _maybe_ generally Fast Enough when you&#x27;re lucky to be on an ISP and network connection that gives you a decent path to wherever your content is hosted but that&#x27;s not a given, particularly these days when the majority of most services&#x27; users are mobile, users are increasingly geographically distributed and consumer ISPs are increasingly hostile towards service providers (e.g. if your transit was through Cogent, Comcast&#x27;s Netflix dispute may have interfered).<p>&gt; Essentially, there&#x27;s not really a reason to use CloudFlare anymore, and the majority of sites won&#x27;t see any real benefit from it at all. I&#x27;ll go into the alternatives further down the article, but I want to address some of the problems that CloudFlare introduces first.<p>You haven&#x27;t provided nearly enough evidence to backup this statement.<p>&gt; Encryption<p>Yes, like any CDN, CloudFlare needs to have access to your content in order to cache it. Like any CDN, if the connection between the edge nodes and your own servers is not secure, a hostile ISP can do whatever it wants with it. This isn&#x27;t CloudFlare specific or even CloudFlare universal. This here is a fault in your backend service. CloudFlare offers you the option to encrypt that traffic and you&#x27;ve chosen not to.<p>&gt; In contrast, CloudFlare is just a reverse proxy with a very fast connection. Layer 3&#x2F;4 attacks (those aimed at the underlying network infrastructure, rather than the application or protocol itself) will only ever reach up to the point where it&#x27;s handled by a server rather than just passed through, and in a &quot;reverse proxy&quot;-type setup, that server is CloudFlare. They&#x27;re not actually mitigating anything, it just so happens that they are the other side of the connection and thus &quot;take the hit&quot;!<p>So what you&#x27;re saying is that a DDoS isn&#x27;t hitting my servers and my users still get their content? That&#x27;s called DDoS mitigation. Just because it doesn&#x27;t work the way you&#x27;re used to doesn&#x27;t mean it&#x27;s not working.<p>&gt; Indeed it is essentially impossible to archive something that&#x27;s in &quot;I&#x27;m Under Attack&quot; mode, despite that usually being the exact moment where archival is necessary!<p>Preventing automated systems from making requests to your site when you&#x27;re in the middle of a DDoS seems sensible enough. If it&#x27;s truly necessary (and permitted), contact the site and ask for the IP of the backend. If your work is appreciated, they&#x27;ll give it to you. As a site operator, if you want to archive my site, I&#x27;d rather you contact me. I&#x27;ll give you my backend IP and hell, might even give you rsync access or something. Archiving through a browser is the least desirable way to have my stuff archived.<p>&gt; In most of the Western world, connectivity is pretty good. You can go from most places in the US to Europe and back - across the ocean! - in about 140 milliseconds. A commonly used metric in the web development industry is that your page and all your assets should be loaded in under 300 milliseconds.<p>I&#x27;m located in Silicon Valley and a ping to Germany takes 172ms, a ping to Canada takes 90, a ping to Amsterdam takes 154 and so on. A ping to San Jose where my nearest CloudFlare&#x2F;Akamai&#x2F;everything POP is located takes 14ms.<p>&gt; Assuming you&#x27;re declaring all the assets on your page directly, that would make it two roundtrips totalling about 280 milliseconds, since the assets can be retrieved in parallel.<p>This is incredibly optimistic. Open up the Network tab in Chrome&#x27;s dev tools and open Amazon, Facebook, even a WordPress blog sometime. Hell, HN&#x27;s front page barely loads that fast.<p>&gt; CloudFlare can&#x27;t cache the actual pageloads locally, because they are dynamic and different for everybody.<p>This depends entirely on the content of the page. Not all content is dynamic. Blogs and news sites for example are largely static. Further, CloudFlare can cache the static _parts_ of the page and send only the dynamic content: <a href="https:&#x2F;&#x2F;blog.cloudflare.com&#x2F;cacheing-the-uncacheable-cloudflares-railgun-73454&#x2F;" rel="nofollow">https:&#x2F;&#x2F;blog.cloudflare.com&#x2F;cacheing-the-uncacheable-cloudfl...</a><p>&gt; So why not just use a CDN? Using a CDN means you can still optimize your asset loading, but you don&#x27;t have to forward all your pageloads through CloudFlare. Static assets are much less sensitive, from a privacy perspective.<p>CloudFlare is a CDN. Why not use CloudFlare as a CDN for your static assets? CloudFlare isn&#x27;t making you turn it on for all your domains. You can totally turn CloudFlare on for static.mysite.com and leave mysite.com on your own server.<p>&gt; And this is the problem with CloudFlare in general - you can&#x27;t usually make things faster by routing connections through somewhere, because you&#x27;re adding an extra location for the traffic to travel to, before reaching the origin server.<p>This is the same for every CDN and like every CDN, you&#x27;re relying on the CDN&#x27;s internal network to get somewhere faster than your own would, and for the CDN&#x27;s cache to eliminate the need even to do the round trip. If the content is already in Asia, the CDN doesn&#x27;t need to make the request back to the origin at all. That eliminates entire intercontinental round trips and that&#x27;s massive.<p>&gt; Unfortunately, all of these issues together mean that CloudFlare is essentially breaking the open web. Extreme centralization, breaking the trust model of SSL&#x2F;TLS, a misguided IP blocking strategy, requiring specific technologies like JavaScript to be able to access sites, and so on. None of this benefits anybody but CloudFlare and its partners.<p>No, you have opinions biased by (valid but not universal) philosophies and concerns. These features are desired and beneficial to many people.<p>This is way too much text for me so I&#x27;ll stop here.<p>TL;DR: This article mainly complains about things that are common to every CDN, while demonising CloudFlare specifically for unknown reasons. The rest is mainly complaints about Under Attack Mode.