2019 Cloudflare Enterprise Best Practices
2019 Cloudflare Enterprise Best Practices
CDN Web Purge the cache via API for event-driven content…….…….…..….…..6
Optimization
DNS Load
Balancing Enable Argo for tiered caching and smart routing……….................9
Argo China
Network
Ensure optimal performance on our China Network…….…….……11
WAF Rate
Limiting Build Firewall Rules for fine-grained control………………….………...18
Argo Tunnel
Easily secure your origin connection with Argo Tunnel…………....20
Cloudflare can accelerate all of the content you are trying to deliver to your users. By optimizing
your images and being as near as possible to your end users, Cloudflare’s performance suite
provides the fastest experience for your application.
The features within our Speed application work by delivering your content
more intelligently. Some of these features are client-side (implemented in
the browser using javascript), while others are edge-side (performed at
Cloudflare’s edge before content leaves a Cloudflare data center).
Polish offers compression rates up to 30-40% with either lossy or lossless compression.
Polish should always be enabled in the lossless, ‘Basic’ mode, and even lossy for the
majority of web applications.
Auto-Minify removes comments and formatting meant for humans which leads to
improved load times. Minification can be safely enabled for HTML and CSS. For Javascript,
please make certain that line endings are denoted with a semicolon.
Cloudflare can even accelerate your content using Client-side tools such as Mirage and
Rocket Loader. These features are currently in Beta, and we recommend testing them
carefully before turning them on for production traffic. To test Mirage or Rocket Loader,
you can enable them for specific pages or subdomains with page rules.
● Rocket Loader grabs all javascript and forces it to be loaded asynchronously after
the page load. This feature is powerful and aggressive, ideal for customers who
can’t manage the loading order of the javascript on a page.
This can be turned on for each path in the Page Rule application:
1. Create a Page Rule with the URL pattern of your static HTML (i.e.
www.example.com/static-html/*)
2. Set Cache Level to ‘Cache Everything’
3. Set Edge and Browser TTLs
4. Press ‘Save and Deploy’
For content that changes only occasionally, you can set a conservative TTL to utilize our
cache as much as possible. A good way to tell if your TTLs may need to be adjusted is by
watching your Status Codes in our Analytics App for an abundance of 304 requests. If
you have a high percentage of re-validation requests, you could likely increase the TTLs
of your content without negatively impacting your customers. This will use our cache
more effectively and increase performance since you will revalidate less often.
● MISS: Not yet in the cache or the TTL expired (i.e. cache-control max age of 0)
● HIT: Asset delivered from cache
● EXPIRED: Resource was in cache but has since expired, served from origin server
● REVALIDATED: Delivered from cache. The TTL was expired, but a
“If-Modified-Since” request to the origin indicated the asset has not changed so
the version in cache is considered valid again.
Purging individuals objects is a great way to maintain your cache-hit ratio while still
ensuring certain objects are re-validated in our cache. API Documentation
Cache-Tags allow you to define buckets of content that you wish to purge all together.
This is an excellent way to combine objects that are commonly changed together. So an
HTML blog post, for example, and all of its image content could be tagged together.
Mobile-only content could also be bundled using cache-tags to purge everything when
you push a new update to your mobile domain.
You also have the option to force our entire cache to revalidate. This allows you to reset
all of the objects stored in our cache to ensure every request will return to the origin.
Page Rules allow you to effectively purge the entire cache by a basic regular
expression. These let you utilize a pre-defined Page Rule and re-validating all
hits against that Page Rule.
The ability, configured in a page rule, to serve a cached object unless we see a
cookie of a specific name, e.g., serve a cached version of the homepage unless
we see a SessionID cookie indicating the customer is logged in and therefore
should be presented personalized content.
❏ Cache on Cookie
Presents a cached page when only when we see a specific cookie, e.g., only
serves a cached page once a device type cookie has been set by the origin
server.
Generally, objects in Cloudflare’s cache are referenced by only their URI (e.g.
https://www.example.com/logo.png). We offer the ability to create custom cache
keys so that a different object is served for the same URI based on any arbitrary
request header or cookie. For example, https://www.example.com/logo.png with
a device type cookie set to desktop would be a different object in our cache than
https://www.example.com/logo.png with a device type cookie set to tablet.
Web applications often render personalized, dynamic content which means that
this content must be proxied through to the origin server. Railgun is an optional
feature available to Business & Enterprise accounts that accelerates requests for
this type of personalized content.Railgun is fundamentally a de-duplicating proxy.
The railgun listener is installed within the customer’s origin infrastructure so that before a
response is sent from the origin infrastructure, a binary diff is performed with the last
resource at the same URI. For example, when Bob attempts to access his shopping cart page,
the application server renders it, but before it leaves the origin datacenter, the railgun listener
compares Bob’s page with Alice’s page, and only sends the difference. Documentation
✓ Railgun
As Cloudflare will fall back to HTTP in the event railgun fails, a high availability
solution is generally not required. If high availability is a preferred solution, all
railgun instances should be placed behind a layer 3 load-balancer and registered
with the same activation code as seen in the diagram. If configured in an
active/active configuration, Railguns should share memcache to improved cache
hit rate. If configured in an active/passive configuration, Railguns can have
independent memcaches.
The railgun listener (stand-alone or cluster) should logically sit outside of the load
balancer allowing requests for all application servers to flow through the same
railgun instance increasing the cache hit ratio.
We’ve provided a link to some excellent documentation from our friends at AWS.
Smart Routing analyzes and optimizes routing decisions across the global Internet in real
time, steering your traffic around congested or unreliable network paths.
You can turn Smart Routing on in the Traffic app. It is a non-intrusive change that will not
cause downtime, but you may need to let it run for up to a few hours in order to find all of
the optimal paths to your origin across the globe.
Our Knowledge Base contains detailed setup instructions, which you can supplement with
the following best practices:
As with many features, we recommend thorough testing before enabling load balancing
on production traffic. That means creating a load balancing configuration with test traffic
to understand the effects on your origin servers before going live in production.
If your production traffic is served over HTTP, configure your health checks over
HTTP. If HTTPS, send health checks over HTTPS. This will ensure your health checks
provide an accurate representation of live traffic hitting your origin servers.
When deciding on the intervals at which Cloudflare’s load balancer should send
health checks to your origin, consider how quickly your origins are capable of
handling these requests.
Cloudflare’s network is very large, and growing. Before you configure health checks
to be sent from “All Data Centers”, ensure your origins are prepared to be checked
by every Cloudflare network node at the interval you configure.
Alternatively, you can set up health checks from specific regions, which will limit
these checks to a subset of our data centers.
If you have a load balancing configuration that you want to share with additional
domains, there is no need to recreate the load balancer for each one. Instead, you can
simply create a CNAME record in your Cloudflare DNS app to do so.
Another popular configuration option is sharing the same monitors and pools between
domains, but configuring separate load balancers. This is beneficial for use cases in which
you want to vary the failover priority among your domains.
Through our partnership with Baidu, Cloudflare customers can serve content to
their visitors within China from a network of more than twenty data centers across
mainland China. Enabling our China network will significantly reduce latency within
the country, but due to China’s unique internet architecture, the following best
practices are essential for optimizing performance.
One way to approach optimizing performance for China is to consider the strategy you
might use for mobile users in the rest of the world. The network difficulties are similar.
The key is to focus on serving the lightest possible load. In particular, consider relieving
your site of all non-essential third-party resources.
Extensive testing is critical to successful performance inside China. Testing will help you
uncover unnecessary third-party resources being served, determine how to improve your
cache hit rate, and lead to many other ideas for reducing latency
Check out this detailed tutorial on our blog that shows how you
can use Cloudflare Workers to make your Google Fonts
lightning-fast.
Analyze your logs (and work with your dedicated account team) to uncover the top
un-cached files being served. Can any of these be cached?
Brotli will greatly reduce the write time transfer. If multiple compression
✓ methods are supported by the client, Cloudflare will select Brotli compression
as the preferred content encoding method. If the client does not indicate that
Brotli compression is supported, then gzip compression will be applied.
By default, Cloudflare’s security settings are set to safe defaults that aim to avoid false positives
and negative influences on your traffic. However, this is not necessarily the best security posture
for every Enterprise customer. The following steps will ensure Cloudflare is configured in a
secure and safe manner.
❏ Orange-cloud all DNS records for HTTP(S) traffic from your origin
Any records that cannot be proxied through Cloudflare but still utilize your origin IP such
as FTP — can still be secured with additional obfuscation. If you require a record to your
origin that cannot be proxied by Cloudflare, use a non-standard name for this record. For
example, instead of ftp.example.com use [random word or-random
characters].example.com — this will make dictionary scans of your DNS less likely to
expose your origin IP addresses.
Some customers will use separate IP ranges for HTTP and non-HTTP traffic, allowing
them to orange-cloud all records pointing to their HTTP IP range and obscuring all
non-HTTP traffic with a different IP subnet.
Cloudflare sees nearly 2 billion unique IPs every month from more than 13
million websites on our network. Each IP is assigned a threat score, and as an IP
engages in malicious behavior on our network, its threat score increases. The
scale of this data, and the automatic process of assigning threat scores, allows
Cloudflare to quickly find bad actors and prevent them from reaching your
assets.
❏ Increase for sensitive admin and login pages
Security Level Options
Customers often create Page Rules to
heighten the Security Level on admin and Each Security Level is aligned
login pages in order to prevent brute-force with a threat score from our
attempts. IP Reputation Database. A
threat score above 10 is
1. Ensure the proper domain is selected considered risky. A threat
2. Create a Page Rule with the URL pattern of score above 50 indicates real
your API (i.e. www.example.com/wp-login) hazard.
3. Select the ‘Security Level’ setting
4. Mark the setting as ‘High’ HIGH - Threat scores greater
5. Select ‘Save and Deploy’ than 0 will be challenged.
Cloudflare’s ‘Medium’ Security Level has a very low false positive rate (1 in 50
million) and is recommend as a starting point for all customers. The global
setting is available in the Firewall Application.
Your WAF is available in the Firewall Application in the Web Application Firewell
section. We will walk through these settings in reverse to ensure that the WAF is
configured as safely as possible before turning it on for your entire domain. The
goal of these initial settings is to reduce false positives and to populate the Traffic
Application with WAF events for further tuning.
For example, if you use a Drupal application, that group should be activated while
Joomla and Magento groups are turned Off.
Our Knowledge Base includes detailed instructions for creating various rate limiting
rules. Below are some best practices we developed with our Enterprise customers:
To avoid interfering with good traffic to your site or application, you will want to set
your rate limiting thresholds comfortably (at least 4x) above typical request levels.
Cloudflare rate limits requests per IP address. That could be a problem if you expect
traffic from many users that share a single IP address, such as those on corporate
networks or Carrier-Grade NATs.
Use your logs to learn from rate limited events and improve your security posture. If
you encounter an IP address appearing repeatedly, consider adding it to your
Cloudflare IP Firewall.
The comprehensive managed rules within our WAF are automatically updated by
our engineers to keep you protected from new, advanced threats. You can also
use our IP Firewall to manually block or challenge IPs, countries, and ASNs that
you know to be malicious. Firewall Rules give you greater power and flexibility to
examine and take action on your traffic. You can define a filter using multiple,
custom criteria and declare a specific action to apply when that filter is matched.
Access our Developer Portal for detailed documentation on configuring Firewall Rules.
Cloudflare’s WAF is applied globally. Once enabled, the rules are triggered on all of your
orange-clouded records. If any part of your site is incompatible with specific WAF rules,
you can instead use Firewall Rules to apply a rule only to specific paths.
The above is an example of a “negative” security control, in which you allow all traffic by
default, but create a rule to block or challenge a specific type of traffic. But Firewall
Rules enable you to implement a “positive” security control, in which all traffic is
blocked by default, but you allow access to specific types of traffic, in line with the trend
towards a “Zero Trust” security model.
To take just one example, you can create a Firewall Rule to block all traffic to a specific
subdomain on your website except for traffic from a specific IP range - i.e. from your
employees. Or you can challenge all requests to a login API endpoint except for those
made via API.
Below are a few best practices we recommend, but contact your dedicated account
team to access the SSL for SaaS Onboarding Guide for detailed instructions.
If you are migrating any customers’ vanity domains that already have HTTPS (perhaps
they’re self-hosted or you’ve manually provisioned), these customers will likely want to
avoid the few minutes of downtime during the cutover process.
To minimize the risk of downtime, you can employ additional “pre-validation” methods
to obtain a certificate in advance of setting the CNAME to your domain:
Pre-Validation Methods
1. HTTP-based validation (Recommended)
- HTTP-based validation - manually hosting the DCV token at your origin server -
is the most common validation method, in part because it does not require
involvement from your end customer.
- Reference the SSL for SaaS Onboarding Guide (sent to you by your account
team) for complete instructions.
By default, Cloudflare will send all of your custom hostname traffic to the proxy fallback
record you provide. But that’s not your only option. If you have typically segmented
your customers to send traffic to different origin servers (e.g. by region or tier), you can
configure your SSL for SaaS setup to continue doing so.
To enable custom origins, please contact your dedicated account team, who can entitle
this feature and walk you through the configuration process.
Note: Your custom origins must be added to the DNS panel in your Cloudflare account in
order to be used.
As the name suggests, Argo Tunnel utilizes Cloudflare’s Argo network, and is included in
your Argo subscription. This means enabling Argo Tunnel will not only improve your
origin security, but performance, as well.
Note: As a daemon installed at your origin providing the benefits of delta compression, Argo
Tunnel can be thought of as a replacement for Cloudflare’s Railgun technology. If you are
enabling Argo Tunnel, you will not need to run Railgun in parallel.
The Analytics app in the Cloudflare dashboard is designed to provide you with insights
into your traffic at a high level. As an Enterprise customer, you also have the ability to
ingest all of your website’s raw request logs, either by pulling these logs via API or
having Cloudflare push them to you:
Cloudflare’s ELS service is a RESTful API for consuming request logs over HTTP using
your client API key. To enable, contact your dedicated account team and ask for ELS to
be turned on.
This guide from our Knowledge Base provides detailed instructions for log ingestion
using ELS.
❏ Cloudflare Logpush
Your can also have your HTTP request logs pushed to you at a set interval (every 5
minutes) using the Cloudflare Logpush service. All Enterprise Log Share (ELS)
functionality — including selecting fields and sampling — is also available in Logpush.
Currently, you can push your logs to Amazon S3 and Google Cloud Storage (GCS).
Cloudflare will be expanding the list of destinations on an ongoing basis.
Contact your dedicated account team for to for Logpush entitlement, at which point
you can navigate to the Analytics → Logs and begin the configuration process:
1. First, click on the name of your Account in the top left corner of the dashboard
navigation and select Account Home
2. From your Account Home page, navigate to the Members tab, where you’ll find
the option to Enforce 2-Factor Authentication:
Cloudflare has to occasionally show content to your end-users. This can include
security challenge pages, block pages, and error pages. All of this content can be
customized by you to ensure a consistent branding experience for your
customers. There are two ways to customize the content on these pages:
- After selecting the domain from the top-level navigation, select the Custom Pages
app. From here, you can customize the pages shown to your visitors for several
different security rules and error codes. These pages will only be shown to
visitors of this domain.
- To apply the same custom pages across your Cloudflare domains, simply
navigate to your Account Home (by selecting the name of your account from the
top left corner of the dashboard navigation).
- From there, select Configurations → Custom Pages. Any custom pages you
configure here will apply across all domains in that account.
- Note: If you have setup more than one account in Cloudflare to organize your
domains under, you will need to apply custom pages separately to each account.