简介
支持服务需要一个安全的位置来预览配置更改。你将让预览环境和线上环境运行相同的代码，分别维护它们的公开标签和密钥，并保护一个模拟维护端点，同时保持健康检查公开可访问。
使用你自己的 Cloudflare 学习账号，以及前面实验中学到的设备授权、部署和日志知识。本实验从 /home/labex/project/worker-config 独立开始，环境中已安装 Node.js 22.22.0、项目本地 Wrangler 4.131.1 和一个小型健康路由示例。实验不会复用之前的虚拟机或云资源。两套部署都可以删除，维护操作也只是演练。这里只能使用生成的模拟令牌。Workers Free 和 workers.dev 足以支持本练习；请求会计入你的账号用量。不需要购买域名、数据库或付费升级。
你将删除两套云端部署和本地令牌文件，然后在结束虚拟机前退出登录。整个实验期间保持同一个终端打开。
分离预览环境和线上环境的配置
本步骤中，你将使用同一个已提供的健康处理程序和两个命名环境。这里的 live 仍然只是可删除的学习部署；两个环境都不会处理真实生产数据。preview 是 Wrangler 环境名称，不是版本预览 URL。
进入准备好的项目并检查健康路由示例。Node 和项目本地 Wrangler 已经安装。
进入项目目录：
cd /home/labex/project/worker-config
检查 Node 版本：
node --version
检查项目本地 Wrangler 版本：
npx wrangler --version
查看健康路由处理程序：
cat src/index.js
预期 Node 版本为 v22.22.0，Wrangler 版本为 4.131.1。该处理程序从 env 读取非敏感的显示值。在你自己的机器上，需要安装 Node，并将 wrangler@4.131.1 添加为项目开发依赖；使用 npm ci 按现有依赖安装。
生成一个可删除的基础名称。命令替换会将随机十六进制输出插入 shell 变量。保持此终端打开，后续命令还会使用它。
WORKER_NAME="labex-config-$(openssl rand -hex 6)"
使用 heredoc 写入配置；未加引号的结束标记允许替换 $WORKER_NAME。main 指定共享代码，compatibility_date 指定运行时行为。env 对象分别为 --env preview 和 --env live 覆盖配置。每个环境都必须定义所有 vars 值，因为这些绑定不会继承。这里没有数据库或队列资源：QUEUE_LABEL 只是公开显示标签。
cat > wrangler.jsonc <<CONFIG
{
"name": "$WORKER_NAME",
"main": "src/index.js",
"compatibility_date": "2026-09-14",
"workers_dev": true,
"preview_urls": false,
"env": {
"preview": {"vars": {"ENVIRONMENT": "preview", "QUEUE_LABEL": "sandbox"}},
"live": {"vars": {"ENVIRONMENT": "live", "QUEUE_LABEL": "primary"}}
}
}
CONFIG
启动两个本地运行时。> 会重定向输出，2>&1 会包含错误输出，& 会让进程在后台运行。使用不同的 HTTP 端口和调试器端口，避免端口冲突。
npx wrangler dev --env preview --port 8080 > preview.log 2>&1 &
npx wrangler dev --env live --port 8081 --inspector-port 9230 > live.log 2>&1 &
查看预览环境日志：
cat preview.log
查看线上环境日志：
cat live.log
等待两个日志都报告已就绪；如果需要，可以再次执行对应的 cat 命令。然后比较两个响应：
curl -i http://127.0.0.1:8080/health
curl -i http://127.0.0.1:8081/health
两个请求都应返回 200。预览环境返回 {"status":"ok","environment":"preview","queue":"sandbox"}；线上环境返回 {"status":"ok","environment":"live","queue":"primary"}。curl -i 会同时显示状态和响应头。在两个服务器都运行时，点击验证按钮。
环境文档介绍了环境继承规则，以及默认的 <name>-<environment> 部署名称。
使用本地密钥保护维护路由
本步骤中，你将为每个环境设置不同的令牌，以保护一个模拟维护操作。密钥是可以通过 env 获取的私有配置；它不能出现在公开的 vars、返回的 JSON 或应用程序日志中。这个简单的 bearer token 示例用于讲解服务器端边界，并不是完整的用户身份验证系统。
添加密钥文件前，先停止两个本地任务。检查实际的任务编号；以下示例假设预览环境是 1，线上环境是 2。
jobs
kill %1 %2
生成两个仅用于测试的随机令牌，但不要显示它们。umask 077 会使新文件只有虚拟机用户可读。printf 会分别向每个环境的文件写入一条 dotenv 赋值。这里绝不能使用真实账号的 API 令牌。
umask 077
PREVIEW_TOKEN=$(openssl rand -hex 24)
LIVE_TOKEN=$(openssl rand -hex 24)
printf 'MAINTENANCE_TOKEN=%s\n' "$PREVIEW_TOKEN" > .dev.vars.preview
printf 'MAINTENANCE_TOKEN=%s\n' "$LIVE_TOKEN" > .dev.vars.live
查看 .gitignore：
cat .gitignore
确认 .dev.vars* 和 .env* 已被排除。不要打印或提交密钥文件。对于 --env preview，Wrangler 会加载 .dev.vars.preview；对于 --env live，会加载单独的线上环境文件。环境专用的 .dev.vars 文件会替代通用文件。这些文件不会自动将密钥上传到 Cloudflare。请参阅本地密钥和已部署密钥。
替换处理程序。加引号的 heredoc 会原样保留 JavaScript。未配置密钥时返回 503；请求缺少凭据或凭据错误时返回 401。服务器会先比较 Authorization 请求头，再返回成功结果。日志中只记录固定的事件名称、公开环境和数字状态码。接受的操作只是演练，不会产生任何持久化副作用。
cat > src/index.js <<'JS'
export default {
async fetch(request, env) {
const path = new URL(request.url).pathname;
if (path === '/health' && request.method === 'GET') {
return Response.json({status: 'ok', environment: env.ENVIRONMENT, queue: env.QUEUE_LABEL});
}
if (path !== '/maintenance') return Response.json({error: 'not_found'}, {status: 404});
if (request.method !== 'POST') {
return Response.json({error: 'method_not_allowed'}, {status: 405, headers: {Allow: 'POST'}});
}
// Fail closed if this environment has no configured secret.
if (!env.MAINTENANCE_TOKEN) {
return Response.json({error: 'maintenance_unconfigured'}, {status: 503});
}
const authorized = request.headers.get('Authorization') === `Bearer ${env.MAINTENANCE_TOKEN}`;
const status = authorized ? 200 : 401;
console.log(JSON.stringify({event: 'maintenance', environment: env.ENVIRONMENT, status}));
if (!authorized) return Response.json({error: 'unauthorized'}, {status});
return Response.json({operation: 'dry-run', environment: env.ENVIRONMENT});
}
};
JS
启动预览环境：
npx wrangler dev --env preview --port 8080 > preview.log 2>&1 &
启动线上环境：
npx wrangler dev --env live --port 8081 --inspector-port 9230 > live.log 2>&1 &
查看预览环境日志：
cat preview.log
查看线上环境日志：
cat live.log
两个服务器都报告已就绪后，测试访问边界。-X POST 指定请求方法，-H 提供 bearer 请求头。使用真实凭据时，不要使用 curl 的详细输出。
curl -i -X POST http://127.0.0.1:8080/maintenance
curl -i -X POST http://127.0.0.1:8080/maintenance -H "Authorization: Bearer incorrect-token"
curl -i -X POST http://127.0.0.1:8080/maintenance -H "Authorization: Bearer $LIVE_TOKEN"
curl -i -X POST http://127.0.0.1:8080/maintenance -H "Authorization: Bearer $PREVIEW_TOKEN"
curl -i -X POST http://127.0.0.1:8081/maintenance -H "Authorization: Bearer $LIVE_TOKEN"
curl -i http://127.0.0.1:8080/health
curl -i http://127.0.0.1:8081/health
前 3 个请求都返回 401 unauthorized，其中也包括另一个环境中本来有效的令牌。后两个请求返回 200，响应包含 operation: dry-run，并显示各自的环境。健康检查仍然公开可访问。使用验证功能检查两个方向的令牌隔离、请求方法、公开配置，以及本地日志中不存在令牌值。
部署每个环境并上传对应密钥
本步骤中，你将为这台全新的虚拟机授权，部署两个命名环境，并显式上传它们的密钥。先停止本地任务；使用 jobs 查看实际任务编号。
jobs
kill %1 %2
npx wrangler login --device --browser=false --scopes account:read user:read workers_scripts:write workers_tail:read
在已登录的浏览器中打开终端显示的链接，并输入当前代码。查看 Wrangler 请求的权限和所需的 Background Access，只选择你的学习账号，然后按照连接实验中的说明完成授权。等待终端显示操作完成。
npx wrangler whoami --json
确认输出中的 loggedIn: true、账号名称和账号 ID。将下面的 YOUR_ACCOUNT_ID 替换为实际的账号 ID；保留原来的资源名称。
cat > wrangler.jsonc <<CONFIG
{
"name": "$WORKER_NAME",
"main": "src/index.js",
"compatibility_date": "2026-09-14",
"account_id": "YOUR_ACCOUNT_ID",
"workers_dev": true,
"preview_urls": false,
"env": {
"preview": {"vars": {"ENVIRONMENT": "preview", "QUEUE_LABEL": "sandbox"}},
"live": {"vars": {"ENVIRONMENT": "live", "QUEUE_LABEL": "primary"}}
}
}
CONFIG
本项目始终要包含 --env。否则 Wrangler 会针对未命名的顶层环境，而该环境不属于本实验的部署计划。
npx wrangler deploy --env preview
npx wrangler deploy --env live
从每次部署输出中复制准确的 workers.dev 地址。复用学习账号已有的子域名。首次使用时，按照 Wrangler 显示的可用子域名提示操作，不要修改已有子域名。
PREVIEW_URL="https://YOUR_BASE-preview.YOUR_SUBDOMAIN.workers.dev"
LIVE_URL="https://YOUR_BASE-live.YOUR_SUBDOMAIN.workers.dev"
curl -i -X POST "$PREVIEW_URL/maintenance"
curl -i -X POST "$LIVE_URL/maintenance"
两个请求都应返回 503 maintenance_unconfigured：普通部署不会上传本地密钥文件。健康检查独立于维护授权。
使用标准批量命令，将 dotenv 文件上传到对应环境。即使只有一个密钥，也可以使用这种基于文件的操作；命令输出会显示密钥名称，不会显示密钥值。更新密钥会立即创建并部署一个版本。
npx wrangler secret bulk .dev.vars.preview --env preview
npx wrangler secret bulk .dev.vars.live --env live
npx wrangler secret list --env preview
npx wrangler secret list --env live
两个列表都应包含类型为 secret_text 的 MAINTENANCE_TOKEN。比较公开值和授权行为：
curl -i "$PREVIEW_URL/health"
curl -i "$LIVE_URL/health"
curl -i -X POST "$PREVIEW_URL/maintenance"
curl -i -X POST "$PREVIEW_URL/maintenance" -H "Authorization: Bearer $LIVE_TOKEN"
curl -i -X POST "$PREVIEW_URL/maintenance" -H "Authorization: Bearer $PREVIEW_TOKEN"
curl -i -X POST "$LIVE_URL/maintenance" -H "Authorization: Bearer $LIVE_TOKEN"
健康检查应继续显示预览环境为 preview/sandbox，线上环境为 live/primary。缺少凭据和跨环境凭据返回 401；匹配的令牌返回 200。如果出现连接错误，先等待主机名完成初始传播，再重试。在同一个 Dashboard 账号中，打开 Compute → Workers & Pages。找到名称以 -preview 和 -live 结尾的两个 Worker，将它们的完整名称和 URL 与部署输出进行比较。本示例中，每个命名 Wrangler 环境都有自己的已部署 Worker；不要在 Dashboard 中创建其他应用。
打开 -preview Worker，选择 Settings。在 Runtime variables and secrets（Variables and secrets 部分）中，比较 Type、Name 和 Value 列。ENVIRONMENT 应为 preview，QUEUE_LABEL 应为 sandbox。MAINTENANCE_TOKEN 的类型应为 Secret，其 Value 应显示为 encrypted，而不是可读值。
返回 Workers & Pages，打开 -live Worker，检查相同的部分。它的公开值应为 live 和 primary，而独立上传的密钥使用相同的绑定名称。比较表格前，先检查顶部面包屑中的 Worker 名称。
图片中的随机名称后缀和子域名只是示例值。加密显示只能确认密钥绑定存在且类型正确，不能证明两个环境的密钥值不同；上面的匹配令牌和跨环境 HTTP 检查才说明了实际行为。在此检查点只进行查看：不要在 Dashboard 中编辑变量，也不要显示、替换或复制凭据。使用验证功能；它会检查两个环境的实际归属、已部署绑定类型和公开行为。
检查应用程序日志，同时避免暴露密钥
本步骤中，你将检查已部署预览环境中的一个被拒绝请求和一个被接受请求。应用程序日志应能解释请求结果，但不能复制凭据或请求头。
使用之前学过的 tail 命令启动日志流。漂亮格式会显示应用程序消息；将输出保存下来，以便停止日志流后检查这次有界测试。
npx wrangler tail --env preview --format pretty > preview-tail.log 2>&1 &
cat preview-tail.log
等待日志流报告已连接；连接期间可以重复执行 cat。然后发送新的模拟请求：
curl -i -X POST "$PREVIEW_URL/maintenance" -H "Authorization: Bearer incorrect-token"
curl -i -X POST "$PREVIEW_URL/maintenance" -H "Authorization: Bearer $PREVIEW_TOKEN"
使用 grep 只显示包含固定应用程序事件名称的行：
grep 'maintenance' preview-tail.log
等待出现状态为 401 和 200 的事件。它们的公开环境都应为 preview。两条消息中都不应包含令牌值。事件传输可能晚于 HTTP 响应；最多重试 grep 一分钟。如果缺少事件，请检查源代码中对应的 console.log。
jobs
kill %1
两个事件都出现后，停止实际的 tail 任务；示例假设它是任务 1。使用验证功能检查捕获的日志，并独立重新检查远程授权约束。本步骤只测试模拟请求，不能证明未来任意日志更改都安全。
删除两个环境的部署
本步骤中，你将在仍然获得授权的情况下，删除两个可删除的环境 Worker。先确认配置中的基础名称和学习账号：
cat wrangler.jsonc
只删除本实验的预览和线上部署。在每个提示处，检查准确的 <base>-preview 或 <base>-live 名称，然后按一次 y 键。
npx wrangler delete --env preview
npx wrangler delete --env live
删除这些 Worker 也会移除它们关联的密钥绑定。之后，Wrangler 4.131.1 可能会报告之前记录过的旧版 Workers Sites KV 身份验证错误。不要因此扩大权限，也不要将该错误视为删除成功的证据。刷新 Workers & Pages 并使用验证功能：成功授权的资源清单必须显示两个名称都不存在。身份验证错误或网络错误都无法得出结论。保留无关的 Worker、学习账号及其现有子域名。
删除本地密钥并断开连接
本步骤中，你将在确认云端清理完成后，删除本实验的本地密钥副本，然后断开虚拟机。rm 只会删除下面列出的两个文件，unset 会删除两个临时 shell 变量。
rm .dev.vars.preview .dev.vars.live
unset PREVIEW_TOKEN LIVE_TOKEN
npx wrangler logout
npx wrangler whoami --json
预期会明确显示 "loggedIn": false；如果出现该结构化结果，未认证命令以非零状态退出是正常现象。使用验证功能，然后结束虚拟机。浏览器登录是独立的，可以保留给下一个实验使用。退出登录或结束虚拟机都不能代替先删除云端资源。
总结
你按 Wrangler 环境分离了公开配置，加载了环境专用的本地密钥，上传了加密的密钥绑定，并检查了匹配、缺失和跨环境凭据。公开的健康路由保留了环境标识，同时服务器保护了模拟维护路由。你检查了有界的应用程序日志，没有打印令牌；随后在删除本地凭据并退出登录前，先验证了云端资源已删除。
在本课程后续内容中，同样的配置管理规范将帮助你诊断预览配置漂移问题。
