You have access to the following metrics:
+)} + +{ props.conditional === "dedicated-cache-tile" && ( +In the Overview section, under Cache Reserve, you have access to the following metrics:
+)} + +- **Egress savings (bandwidth)** - is an estimation based on response bytes served from Cache Reserve that did not need to be served from your origin server. These are represented as cache hits. +- **Requests served by Cache Reserve** - is the number of requests served by Cache Reserve (total). +- **Data storage summary** - is based on a representative sample of requests. Refer to [Sampling](/analytics/graphql-api/sampling/) for more details about how Cloudflare samples data. + - **Current data stored** - is the data stored (currently) over time. + - **Aggregate storage usage** - is the total of storage used for the selected timestamp. +- **Operations** - Class A (writes) and Class B (reads) operations over time. \ No newline at end of file diff --git a/src/content/partials/cache/cache-reserve-eligibility.mdx b/src/content/partials/cache/cache-reserve-eligibility.mdx new file mode 100644 index 000000000000000..498e0d7b1c32bad --- /dev/null +++ b/src/content/partials/cache/cache-reserve-eligibility.mdx @@ -0,0 +1,10 @@ +--- +{} +--- + +Not all assets are eligible for Cache Reserve. To be admitted into Cache Reserve, assets must: + +- Be cacheable, according to Cloudflare's standard [cacheability factors](/cache/). +- Have a freshness time-to-live (TTL) of at least 10 hours (set by any means such as Cache-Control / [CDN-Cache-Control](/cache/concepts/cache-control/) origin response headers, [Edge Cache TTL](/cache/how-to/edge-browser-cache-ttl/#edge-cache-ttl), [Cache TTL By Status](/cache/how-to/configure-cache-status-code/), or [Cache Rules](/cache/how-to/cache-rules/)), +- Have a Content-Length response header. +- When using [Image transformations](/images/manage-images/create-variants/), original files are eligible for Cache Reserve, but resized file variants are not eligible because transformations happen after Cache Reserve in the response flow. \ No newline at end of file diff --git a/src/content/partials/cache/cache-reserve-intro.mdx b/src/content/partials/cache/cache-reserve-intro.mdx new file mode 100644 index 000000000000000..e2f420e60a81457 --- /dev/null +++ b/src/content/partials/cache/cache-reserve-intro.mdx @@ -0,0 +1,7 @@ +--- +{} +--- + +Cache Reserve is a large, persistent data store [implemented on top of R2](/r2/). By pushing a single button in the dashboard, your website's cacheable content will be written to Cache Reserve. + +In the same way that Tiered Cache builds a hierarchy of caches between your visitors and your origin, Cache Reserve serves as the ultimate upper-tier cache, that will reserve storage space for your assets for as long as you want. This ensures that your content is served from cache longer, shielding your origin from unneeded egress fees. \ No newline at end of file diff --git a/src/content/partials/cache/cache-reserve-limits.mdx b/src/content/partials/cache/cache-reserve-limits.mdx new file mode 100644 index 000000000000000..e98031a3e1fb9ba --- /dev/null +++ b/src/content/partials/cache/cache-reserve-limits.mdx @@ -0,0 +1,10 @@ +--- +{} +--- + +- Cache Reserve file limits are the same as [R2 limits](/r2/platform/limits/). Note that [CDN cache limits](/cache/concepts/default-cache-behavior/#customization-options-and-limits) still apply. Assets larger than standard limits will not be stored in the standard CDN cache, so these assets will incur Cache Reserve operations costs far more frequently. +- Origin Range requests are not supported at this time from Cache Reserve. +- [Vary for images](/cache/advanced-configuration/vary-for-images/) is currently not compatible with Cache Reserve. +- Requests to [R2 public buckets linked to a zone's domain](/r2/buckets/public-buckets/) will not use Cache Reserve. Enabling Cache Reserve for the connected zone will use Cache Reserve only for requests not destined for the R2 bucket. +- Cache Reserve makes requests for uncompressed content directly from the origin. Unlike the standard Cloudflare CDN, Cache Reserve does not include the `Accept-Encoding: gzip` header when sending requests to the origin. +- Cache Reserve is bypassed when using the Cloudflare [O2O](/cloudflare-for-platforms/cloudflare-for-saas/saas-customers/how-it-works/) setup. \ No newline at end of file diff --git a/src/content/partials/cache/cache-reserve-operations.mdx b/src/content/partials/cache/cache-reserve-operations.mdx new file mode 100644 index 000000000000000..7d9ec8cabea8443 --- /dev/null +++ b/src/content/partials/cache/cache-reserve-operations.mdx @@ -0,0 +1,25 @@ +--- +{} +--- + +Operations are performed by Cache Reserve on behalf of the user to write data from the origin to Cache Reserve and to pass that data downstream to other parts of Cloudflare’s network. These operations are managed internally by Cloudflare. + +#### Class A operations (writes) + +Class A operations are performed based on cache misses from Cloudflare’s CDN. When a request cannot be served from cache, it will be fetched from the origin and written to cache reserve as well as our edge caches on the way back to the visitor. + +#### Class B operations (reads) + +Class B operations are performed when data needs to be fetched from Cache Reserve to respond to a miss in the edge cache. + +#### Purge + +Asset purges are free operations. + +Cache Reserve will be instantly purged along with edge cache when you send a purge by URL request. Refer to [cache configurations](/cache/how-to/purge-cache/) for details. + +Other purge methods, such as purge by tag, host, prefix, or purge everything will force an attempt to [revalidate](/cache/concepts/cache-responses/#revalidated) on the subsequent request for the Cache Reserve asset. Note that assets purged this way will still incur storage costs until their retention TTL expires. + +:::note +Note this differs from the standard CDN's purge by tag, host, or prefix features which force a cache miss, requiring the origin to deliver the asset in full. +::: \ No newline at end of file diff --git a/src/content/partials/cache/regional-tiered-cache.mdx b/src/content/partials/cache/regional-tiered-cache.mdx new file mode 100644 index 000000000000000..2da23da74a44c6f --- /dev/null +++ b/src/content/partials/cache/regional-tiered-cache.mdx @@ -0,0 +1,7 @@ +--- +{} +--- + +Regional Tiered Cache provides an additional layer of caching for customers who have a global traffic footprint and want to serve content faster by avoiding network latency when there is a cache `MISS` in a lower-tier, resulting in an upper-tier fetch in a data center located far away. + +Regional Tiered Cache instructs Cloudflare to check a regional hub data center near the lower tier before going to the upper tier that may be outside of the region. \ No newline at end of file diff --git a/src/content/partials/cache/smart-tiered-cache.mdx b/src/content/partials/cache/smart-tiered-cache.mdx new file mode 100644 index 000000000000000..79b3bc8c32fcd57 --- /dev/null +++ b/src/content/partials/cache/smart-tiered-cache.mdx @@ -0,0 +1,17 @@ +--- +{} +--- + +Smart Tiered Cache dynamically selects the single closest upper tier for each of your website’s origins with no configuration required, using our in-house performance and routing data. Cloudflare collects latency data for each request to an origin, and uses the latency data to determine how well any upper-tier data center is connected with an origin. As a result, Cloudflare can select the data center with the lowest latency to be the upper-tier for an origin. + +#### Load Balancing interaction + +While Smart Tiered Cache selects one Upper Tier per origin, when using Load Balancing, Smart Tiered Cache will select the single best Upper Tier for the entire [Load Balancing Pool](/load-balancing/understand-basics/load-balancing-components/#pools). + +#### Caveats + +Smart Tiered Cache does not work when an origin is behind an [anycast](https://www.cloudflare.com/en-gb/learning/cdn/glossary/anycast-network/) or a regional unicast network because that will prevent us from knowing where the origin is located. As a result, we are unable to select the optimal upper tier and latency may be negatively impacted. + +You need to be careful when updating your origin IPs/DNS records while Smart Tiered Cache is enabled. Depending on the changes made, it may cause the existing assigned upper tiers to change, resulting in an increased `MISS` rate as cache is refilled in the new upper tiers. If the origin is switched to a network behind anycast, it will significantly reduce the effectiveness of Smart Tiered Cache. + +If you need to use anycast or regional unicast and want to use Smart Tiered cache, please engage your account team. \ No newline at end of file diff --git a/src/content/partials/smart-shield/argo-analytics.mdx b/src/content/partials/smart-shield/argo-analytics.mdx new file mode 100644 index 000000000000000..32f48959a9305a7 --- /dev/null +++ b/src/content/partials/smart-shield/argo-analytics.mdx @@ -0,0 +1,5 @@ +--- +{} +--- + +Analytics collects data based on the time-to-first-byte (TTFB) from your origin to the Cloudflare network. TTFB is the delay between when Cloudflare sends a request to your server and when it receives the first byte in response. Argo Smart Routing optimizes your server's network transit time to minimize this delay. \ No newline at end of file diff --git a/src/content/partials/smart-shield/argo-intro.mdx b/src/content/partials/smart-shield/argo-intro.mdx new file mode 100644 index 000000000000000..268b8495d8fe135 --- /dev/null +++ b/src/content/partials/smart-shield/argo-intro.mdx @@ -0,0 +1,10 @@ +--- +params: + - conditional? +--- + +Argo Smart Routing detects real-time network issues and routes your web traffic across the most efficient network path, avoiding congestion. + +{ props.conditional === "dedicated-argo-tile" && ( +This results in faster loading times, increased reliability, and reduced costs. These benefits are most apparent for users farthest from your origin server.
+)} diff --git a/src/content/partials/smart-shield/health-checks-analytics.mdx b/src/content/partials/smart-shield/health-checks-analytics.mdx new file mode 100644 index 000000000000000..2983c5deb95bc9f --- /dev/null +++ b/src/content/partials/smart-shield/health-checks-analytics.mdx @@ -0,0 +1,197 @@ +--- +{} +--- + +You can evaluate origin uptime, latency, failure reason, and specific event logs: + +- **Health Checks By Uptime**: Shows the percentage of uptime for individual origins over time. +- **Health Checks By Failure Reason**: Shows a breakdown of failures by the specific reason. Refer to [common error code causes and solutions below](#common-error-codes). +- **Health Checks By Latency**: Shows average latency – measured in round trip time — for individual origins over time. +- **Event Log**: Shows individual health check data. + - Select each record for additional details on **Round trip time**, the **Failure Reason**, the **Average Waterfall** (showing chronological data about request stages), **Response status code**, and more. + - Note that **Global** is not a configured region; it represents the aggregated data from all enabled regions. + +## Common error codes + +### TCP connection failed + +#### Cause + +Health Checks failed to establish a TCP connection to your origin server. + +#### Solution + +This typically occurs when there is a network failure between Cloudflare and your origin, and/or a firewall refuses to allow our connection. Ensure your network and firewall configurations are not interfering with traffic. + +### HTTP timeout occurred + +#### Cause + +The origin failed to return an HTTP response within the timeout configured. This happens if you have the timeout set to a low number. For example, one to two seconds. + +#### Solution + +Cloudflare recommends increasing the HTTP response timeout to allow the origin server to respond. + +### Response code mismatch error + +#### Cause + +Cloudflare receives an HTTP status code that does not match the values defined in the `expected_codes` property of your Health Check configuration. + +#### Solution + +Response codes must match the `expected_codes`. Confirm the values are correct by comparing the expected response codes and the status code received in the Event Log. + +#### Alternate cause + +You may also see this issue if you have a Health Check configured to use HTTP connections and your origin server is redirecting to HTTPS. In this case, the response code will often be `301`, `302`, or `303`. + +#### Solution + +Change your Cloudflare Health Check configuration to use HTTPS or set the value of `follow_redirect` to `true` so that Cloudflare can resolve the correct status code. + +### Response body mismatch error + +#### Cause + +The response body returns from your origin server and does not include the (case-insensitive) value of `expected_body` configured in your Health Check. + +:::note +We only read the first 10 KB of the response. If you return a larger response, and the `expected_body` is not in the first 10 KB, the Health Check will fail. +::: + +#### Solution + +Ensure the `expected_body` is in the first 10 KB of the response body. + + +### TLS untrusted certificate error + +#### Cause + +The certificate is not trusted by a public Certificate Authority (CA). + +#### Solution + +If you’re using a self-signed certificate, Cloudflare recommends either using a publicly trusted certificate or setting the `allow_insecure` property on your Health Check to `true`. + +### TLS name mismatch error + +#### Cause + +Our Health Check (client) was not able to match a name on the server certificate to the hostname of the request. + +#### Solution + +Inspect your Health Check configuration to confirm that the `header` value set in the Cloudflare Health Check is correct. + +### TLS protocol error + +#### Cause + +This error can occur if you are using an older version of TLS or your origin server is not configured for HTTPS. + +#### Solution + +Ensure that your origin server supports TLS 1.2 or greater and is configured for HTTPS. + +### TLS unrecognized name error + +#### Cause + +The server did not recognize the name provided by the client. When a host header is set, this is set as the ServerName in the initial TLS handshake. If it is not set, Cloudflare will not provide a ServerName, which can cause this error. + +#### Solution + +Set the host header in your Health Check object. + +### No route to host error + +#### Cause + +The IP address cannot be reached from Cloudflare’s network. Common causes are ISP or hosting provider network issues (e.g. BGP level), or that the IP does not exist. + +#### Solution + +Ensure IP is accurate, and check if there is an ISP or hosting provider network issue. + +### TCP Timeout + +#### Cause + +Data transmission was not acknowledged and the retransmit of data did not succeed. + +#### Solution + +Confirm whether the SYN-ACK for the handshake takes place at your origin and contact [Cloudflare support](/support/contacting-cloudflare-support/). + +### Network Unreachable + +#### Cause + +Cloudflare cannot connect to the origin web server due to network unavailability. This is usually caused by a network issue or incorrect origin IP. + +#### Solution + +Check the IP entered for the origin in Cloudflare’s Health Checks configuration or the IP returned via DNS for the origin hostname. + +### HTTP Invalid Response + +#### Cause + +Usually caused by an HTTP 502 error or bad gateway. + +#### Solution + +Ensure the origin web server responds to requests and that no applications have crashed or are under high load. + +### DNS Unknown Host + +#### Cause + +The origin web server hostname does not exist. + +#### Solution + +Confirm the origin web server resolves to an IP address. + +### Connection Reset by Peer + +#### Cause + +A network error occurred while the client received data from the origin web server. + +#### Solution + +Confirm whether the origin web server is experiencing a high amount of traffic or an error. + +### Monitor Configuration Error + +#### Cause + +There was a configuration error in the Health Check and no checks were run against the origin. + +#### Solution + +Review your Health Check configuration to ensure it matches an expected request to your origin. + +### DNS Internal + +#### Cause + +The origin web server’s hostname resolves to an internal or restricted address. No checks are run against this origin. + +#### Solution + +Cloudflare does not allow use of an origin web server hostname that resolves to a Cloudflare IP. + +### Other Failure + +#### Cause + +If the failure cannot be classified as any other type of failure mentioned above. + +#### Solution + +Contact [Cloudflare support](/support/contacting-cloudflare-support/). \ No newline at end of file diff --git a/src/content/partials/smart-shield/health-checks-intro.mdx b/src/content/partials/smart-shield/health-checks-intro.mdx new file mode 100644 index 000000000000000..ed843ebdf208147 --- /dev/null +++ b/src/content/partials/smart-shield/health-checks-intro.mdx @@ -0,0 +1,7 @@ +--- +{} +--- + +A health check is a service that runs on Cloudflare's edge network to monitor whether an origin server is online. This allows you to view the health of your origin servers even if there is only one origin or you do not yet need to balance traffic across your infrastructure. + +Health Checks support various configurations to hone in on what you can check, including response codes, protocol types, and intervals. You can specify a particular path if an origin server serves multiple applications or check a larger subset of response codes for your staging environment. All of these options allow you to properly target your Health Check, providing a precise picture of what is wrong with an origin server. \ No newline at end of file diff --git a/src/content/partials/smart-shield/health-checks-regions.mdx b/src/content/partials/smart-shield/health-checks-regions.mdx new file mode 100644 index 000000000000000..1ed9c18dbf2e827 --- /dev/null +++ b/src/content/partials/smart-shield/health-checks-regions.mdx @@ -0,0 +1,13 @@ +--- +{} +--- + +Cloudflare has data centers in [hundreds of cities worldwide](https://www.cloudflare.com/network/). Health checks do not run from every single of these data centers as this would result in numerous requests to your servers. Instead, you are able to choose between one and thirteen regions from which to run health checks. Cloudflare will run Health Checks from three data centers in each region that you select. + +:::note +The exact location of these data centers are subject to change at any moment. +::: + +The Internet is not the same everywhere around the world and your users may not have the same experience on your application according to where they are. Running Health Checks from different regions lets you know the health of your application from the point of view of the Cloudflare network in each of these regions. + +If you select multiple regions or choose **All Regions** (Business and Enterprise Only), you may increase traffic to your servers. Each region sends individual health checks from three data centers. \ No newline at end of file diff --git a/src/content/partials/smart-shield/smart-shield-callout.mdx b/src/content/partials/smart-shield/smart-shield-callout.mdx new file mode 100644 index 000000000000000..15c3e70be832e5a --- /dev/null +++ b/src/content/partials/smart-shield/smart-shield-callout.mdx @@ -0,0 +1,7 @@ +--- +{} +--- + +:::note[Smart Shield] +This functionality is now offered as part of Cloudflare's origin server safeguard, Smart Shield. [Learn more](/smart-shield/). +::: \ No newline at end of file diff --git a/src/content/partials/smart-shield/zone-lockdown.mdx b/src/content/partials/smart-shield/zone-lockdown.mdx new file mode 100644 index 000000000000000..b1295d3558a5ad2 --- /dev/null +++ b/src/content/partials/smart-shield/zone-lockdown.mdx @@ -0,0 +1,42 @@ +--- +{} +--- + +Currently, any Cloudflare customer on a paid plan can configure Health Checks against any host or IP. [Zone Lockdown](/waf/tools/zone-lockdown/) specifies a list of one or more IP addresses, CIDR ranges, or networks that are the only IPs allowed to access a domain, subdomain, or URL. It allows multiple destinations in a single rule as well as IPv4 and IPv6 addresses. IP addresses not specified in the Zone Lockdown rule are denied access to the specified resources. + +Customers who use zone lockdown and want their health checks to continue passing can follow the guide below to bypass zone lockdown. + +## Bypass zone lockdown + +To bypass zone lockdown using a WAF custom rule: + +1. Log in to the [Cloudflare dashboard](https://dash.cloudflare.com) and select your account and domain. +2. Go to **Security** > **WAF** > **Custom rules**. +3. Select **Create rule**. +4. Create a custom rule matching on **user agent**. +5. Set the action to *Skip* and the corresponding feature to **Zone Lockdown** under **More components to skip**. + +Cloudflare Health Checks have a user agent of the following format: +`Mozilla/5.0 (compatible;Cloudflare-Healthchecks/1.0;+https://www.cloudflare.com/; healthcheck-id: XXX)` where `XXX` is replaced with the first 16 characters of the Health Check ID. + +To allow a specific Health Check, verify if the user agent contains the first 16 characters of the Health Check ID. + +### Via the API + +This example adds a new WAF custom rule to the ruleset with ID `{ruleset_id}` that skips zone lockdown for incoming requests with a user agent containing `1234567890abcdef`: + +```bash +curl "https://api.cloudflare.com/client/v4/{zone_id}/rulesets/{ruleset_id}/rules" \ +--header "Authorization: Bearer