Cloudflare Pages 包含提供 Pages 站点的多项默认设置。本页说明其中部分决策，以便你了解 Pages 的工作方式，以及如何覆盖某些默认行为。
若找到与当前请求路由路径匹配的 HTML 文件，Pages 将提供该文件。Pages 还会将 HTML 页面重定向到无扩展名对应路径：例如 /contact.html 将重定向到 /contact，/about/index.html 将重定向到 /about/。
可通过创建 404.html 文件定义 Pages 找不到请求文件时显示的自定义页面。Pages 将尝试找到最接近的 404 页面。若在当前请求路由的同一目录中未找到，将继续在目录树中向上查找匹配的 404.html 文件，直到 /404.html。这意味着你可以为 /blog/404.html 和 /404.html 等场景定义自定义 404 路径，Pages 将根据情况自动渲染正确的页面。
若项目不包含顶级 404.html 文件，Pages 假定你正在部署单页应用。这包括 React、Vue 和 Angular 等框架。Pages 的默认单页应用行为将所有传入路径匹配到根路径（/），允许你捕获 /about 或 /help 等 URL 并在 SPA 内响应。
在大多数情况下，应避免在站点上设置任何自定义缓存。Pages 带有内置缓存默认值，在提供最新内容的同时尽可能多地缓存。每次向 Pages 部署资源时，资源将缓存在 Cloudflare CDN 上，直到下次部署。
因此，若对 自定义域名 添加缓存，部署后可能提供过时的资源。
此外，对自定义域名添加缓存可能导致 Pages 重定向 或 Pages Functions 出现问题。这可能是因为缓存的响应可能在 Pages 处理请求之前就已提供给最终用户。
但在某些情况下，对自定义域名使用 Cache Rules 是合理的。例如，你可能有易于缓存的不可变资源位置，如文件名中包含内容哈希的 CSS 或 JS 文件。自定义缓存在此情况下有帮助，可在文件（及关联文件名）更改之前加速用户体验。只需确保缓存不会干扰任何重定向或 Functions。
请注意，使用 Cloudflare Pages 时，作为 Pages 项目一部分上传的静态资源自动从 Tiered Cache 提供。无需为 Pages 项目运行的自定义域名单独启用 Tiered Cache。
对于浏览器缓存，Pages 始终为 200 OK 响应发送 Etag 标头，浏览器随后在对该资源的后续请求中在 If-None-Match 标头中返回。Pages 将请求中的 If-None-Match 标头与计划发送的 Etag 比较，若匹配，Pages 将响应 304 Not Modified，告知浏览器可使用本地缓存中的内容。
Pages 目前对 HTTP 范围请求返回 200 响应；团队正在努力添加符合规范的 206 部分响应。
Pages 还尽可能提供 Gzip 和 Brotli 响应。
我们按数据中心将资源插入缓存。资源的生存时间（TTL）为一周，但可能随时消失。若进行新部署，资源在该数据中心最多可保留一周。
默认情况下，Pages 在提供资源时自动添加多个 HTTP 响应标头 ↗，包括：
Access-Control-Allow-Origin: *
Cf-Ray: $CLOUDFLARE_RAY_ID
Referrer-Policy: strict-origin-when-cross-origin
Etag: $ETAG
Content-Type: $CONTENT_TYPE
X-Content-Type-Options: nosniff
Server: cloudflare// if the asset has been encoded
Cache-Control: no-transform
Content-Encoding: $CONTENT_ENCODING
// if the asset is cacheable (the request does not have an `Authorization` or `Range` header)
Cache-Control: public, max-age=0, must-revalidate
// if requesting the asset over a preview URL
X-Robots-Tag: noindex要修改 Cloudflare Pages 添加的标头——例如添加 Early Hints——请更新项目中的 _headers 文件。