已知问题

以下是 Cloudflare Pages 的一些已知 bug 和问题：

构建和部署

GitHub 和 GitLab 目前是自动 CI/CD 构建唯一支持的平台。Direct Upload 允许你集成自己的构建平台或从本地计算机上传。
Cloudflare Pages 目前不支持增量构建。
通过仪表板的 Direct Upload 选项上传 /functions 目录不起作用（请参阅在 Direct Upload 中使用 Functions）。
来自 fork 仓库的提交/PR 不会创建预览。未来会支持此功能。

Git 配置

若使用 Git 集成部署，之后无法切换到 Direct Upload。但是，若你已使用 Git 集成项目且不想在每次推送提交时触发部署，可以禁用/暂停自动部署。或者，你可以删除 Pages 项目并创建指向不同仓库的新项目以进行更新。

构建配置

*.pages.dev 子域名目前无法更改。若需要更改 *.pages.dev 子域名，请删除项目并创建新项目。
Hugo 构建自动运行旧版本。要运行最新版本的 Hugo（例如 0.101.0），需要设置环境变量。将 HUGO_VERSION 设为 0.101.0 或你选择的 Hugo 版本。
默认情况下，Cloudflare 在 Pages 构建环境中使用 Node 12.18.0。若需要使用较新的 Node 版本，请参阅构建配置页面了解配置选项。
对于从 Netlify 迁移的用户，Cloudflare 不支持 Netlify 的 Forms 功能。Pages Functions 可用作 Netlify Serverless Functions 的等效方案。

自定义域名

目前无法添加具有以下特征的自定义域名：
- 通配符，例如 *.domain.com。
- 该域名上已路由 Worker。
目前无法在该域名已启用 Cloudflare Access 策略的情况下添加自定义域名。
Cloudflare 的 Load Balancer 不适用于 *.pages.dev 项目；将出现 Error 1000: DNS points to prohibited IP。
添加自定义域名时，若 Cloudflare 无法验证该主机名上的 SSL 证书请求，域名将不会验证。为使 SSL 验证成功，确保 Cloudflare Access 或 Cloudflare Worker 允许对验证路径的请求：http://{domain_name}/.well-known/acme-challenge/*。
由于 Cloudflare for SaaS 的证书优先级，Advanced Certificates 无法与 Cloudflare Pages 一起使用。

Pages Functions

Functions 目前不支持添加/移除 polyfill，因此打包器（例如 webpack）可能无法运行。
Advanced Mode Pages Functions（使用 _worker.js 文件的 Pages Functions）目前不可用 passThroughOnException()。
passThroughOnException() 目前不如 Workers 中那样 resilient。我们目前将 Pages Functions 代码包装在 try...catch ↗ 块中并回退到调用 env.ASSETS.fetch()。这意味着任何严重故障（例如超出 CPU 时间或内存）仍可能抛出错误。

在 `*.pages.dev` 域名上启用 Access

若要为预览部署和 *.pages.dev 域名启用 Cloudflare Access ↗，必须：

在 Cloudflare 仪表板中，前往 Workers & Pages 页面。
Go to Workers & Pages ↗
选择你的 Pages 项目。
前往 Settings（设置） > Enable access policy（启用访问策略）。
在为预览部署创建的 Access 策略上选择 Manage（管理）。
在 Access > Applications（应用程序） 下，选择你的项目。
选择 Configure（配置）。
在 Public hostname（公共主机名） 下，在 Subdomain（子域名） 字段中删除通配符（*）并选择 Save（保存）。此步骤可能需要更改 Application name（应用程序名称） 以避免错误。

此时，你的 *.pages.dev 域名已在 Access 后面得到保护。要重新保护预览部署：

返回 Pages 项目 > Settings（设置） > General（常规），并重新选择 Enable access policy（启用访问策略）。
确认已创建两个 Access 策略，一个用于 *.pages.dev 域名，一个用于预览部署（*.<YOUR_SITE>.pages.dev）。

若有自定义域名并将 *.pages.dev 域名保护在 Access 后面，必须：

在 Cloudflare 仪表板 ↗中，前往 Zero Trust > Access controls（访问控制） > Applications（应用程序）。选择 Create new application（创建新应用程序） > Self-hosted and private（自托管和私有）。
选择 Add public hostname（添加公共主机名），从 Domain 下拉菜单中选择自定义域名。
配置访问规则以定义谁可以访问 Access 身份验证页面。
选择 Create（创建）。

如果你遇到未列出的问题，请在 Cloudflare Workers Discord 中告知团队。在 discord.cloudflare.com ↗ 获取邀请，并在 #pages-general 频道分享 bug 报告。

删除部署数量较多的项目

若 Pages 项目部署数量较多（超过 100 个），可能无法删除。Cloudflare 团队正在跟踪此问题。

作为解决方法，可以使用 wrangler pages deployment delete 单独删除部署。删除部署后，即可删除 Pages 项目。

npx wrangler pages deployment delete <DEPLOYMENT_ID> --project-name <PROJECT_NAME>

使用 --force 标志跳过确认提示并强制删除别名部署。

要删除特定项目名称的所有部署，可以运行以下 shell 脚本：

prod_id=""
while :; do
  ids=$(npx wrangler pages deployment list --project-name <PROJECT_NAME> --json | jq -r '.[].Id')
  to_delete=$(echo "$ids" | grep -v -F -x "$prod_id" | grep .)
  [ -z "$to_delete" ] && { echo "Done. Production: $prod_id"; break; }
  echo "Deleting $(echo "$to_delete" | wc -l | tr -d ' ') deployments..."
  while IFS= read -r id; do
    if ! npx wrangler pages deployment delete "$id" --project-name <PROJECT_NAME> --force 2>&1 | tee /tmp/wrangler-del.log | grep -q "Successfully deleted"; then
      grep -q "active production deployment" /tmp/wrangler-del.log && prod_id="$id"
    fi
  done <<< "$to_delete"
done

请注意，若存在活动的生产部署，此操作不会删除它。

在 Cloudflare Load Balancer 中将 Pages 用作源站

Cloudflare Load Balancing 未设置 host 标头将无法工作。要将 Pages 项目用作目标，在创建池时确保选择 Add host header（添加主机标头），并将 host 标头值和端点地址都设置为 pages.dev 域名。

请参阅将 Cloudflare Pages 用作源站获取完整教程。