先列出允许公开的内容
文章、归档和 RSS 面向读者；写作入口、账号管理和私人导航面向本人。隐藏按钮不能替代访问控制，noindex 也只是索引提示。先把路径列清楚，再设置可验证的规则，而不是简单关闭整个站点的保护。
更具体的路径规则很重要
Cloudflare 文档说明，匹配的主机名或路径规则优先于 Worker 级规则。可以让正式域名公开，同时让写作路径继续要求登录，备用 Worker 地址维持保护。这只是配置思路，真正上线必须检查规则是否匹配实际 URL。
别漏掉路径的其他写法
静态托管可能把带 .html 的地址重定向到不带后缀的路径。保护写作台时两种形式都要验证，同时关注编码、尾部斜杠和备用域名。最可靠的验收不是管理员自己能打开，而是未登录请求得到预期结果。
新功能出现时重新划边界
静态写作台可能只保存本机草稿，不是在线发布后台；若以后加入同步、上传或发布接口，必须重新检查后端身份验证与权限。不能因为原先只有静态页面，就默认新接口也适合公开。
把保护对象列成资源清单
本篇任务是让个人文章对访客开放，同时让写作入口及相关私有数据仍需身份验证。开始前准备站点路径清单、托管入口清单和预期身份角色；若只有本机草稿，也要写明保存位置，避免误以为存在在线账户后台。示例用 example.com，检查矩阵是待执行模板，未连接真实网站、NAS 或登录系统。
按实际资源而非按钮列项：首页、文章、RSS、公开图片、编辑页面、草稿接口、上传接口以及私有附件。隐藏导航只能减少偶然点击，资源本身若匿名返回，仍属于公开。尤其是打进 JavaScript 包的草稿内容，即使页面路由受保护，也可能从公开脚本取得。因此先确定哪些内容允许进入公开构建，再决定哪层实施请求保护。访问规则应保护有价值的数据边界，而不只是一个视觉入口。
| 资源 | 交付路径 | 可匿名 | 保护位置 | 是否含私人数据 |
| --- | --- | --- | --- | --- |
| 文章 | /articles/example | 是 | 公开构建范围 | 否 |
| RSS | /feed.xml | 是 | 仅发布文章 | 否 |
| 写作页 | /editor | 否 | 服务端/Access | 待核对 |
| 草稿数据 | /api/drafts | 否 | 接口身份与授权 | 是 |
| 私人附件 | <实际路径> | 否 | 资源交付前检查 | 是 |
| 前端脚本 | <实际资源路径> | 按设计 | 不嵌入私有草稿 | 待核对 |可复制工作表，示意且未实机验证；填写自己的材料，待测项不代表实际成功。
设计路径时先考虑容易验收的边界
可以把公开正文与私人写作放在明确分开的路径甚至部署中，使资源归属容易检查。若继续使用同一站点，就要列出每条私密路径依赖的接口和附件，防止编辑页需要登录而草稿 JSON 可以直接下载。配置清单中写明“允许匿名”的路径和“要求身份”的路径，默认行为也要写清；未列出的新接口不应靠猜测继承安全性。
Cloudflare 文档说明了 Worker 保护与主机名、路径应用之间的优先关系，不能只数规则条目就认定覆盖充分。查看实际匹配范围，特别是更具体的规则是否改变了较大范围的保护。此处提供设计与验收步骤，不提供脱离账户现状的一键策略片段，因为已有规则、身份提供方和入口绑定会影响最终效果。保存规则前保留原配置，随后以实际 URL 请求证明匹配结果。
完整案例：编辑页拦住了，草稿却在公开包里
构造情景中，匿名打开 /editor 会跳到登录页，作者因而认为写作台已私密。但编辑页引用的草稿列表被一并打进公共前端脚本，公共首页也加载了该脚本。先在构建内容清单查找草稿数据的来源和被引用位置，再检查匿名浏览器能取得哪些资源，而不是只测试编辑页入口。这里要解决的是数据发布范围，继续给同一路径叠加登录规则无法移除已经公开的内容。
修复方案是让私有草稿留在受保护的数据服务或独立私人构建中，公开站点仅纳入明确发布的文章。重新构建后检查公开脚本、索引与附件，不含私人正文才进入部署验收。若数据曾实际公开，需要另按内容暴露范围处理，不能宣称替换包后历史副本消失。本例仅为说明资源边界，不包含真实草稿，也没有制造一次泄漏或运行发布操作。
curl -sS -D - -o /dev/null --max-time 15 'https://example.com/articles/example'
curl -sS -D - -o /dev/null --max-time 15 'https://example.com/editor'
curl -sS -D - -o /dev/null --max-time 15 'https://example.com/editor.html'
curl -sS -D - -o /dev/null --max-time 15 'https://example.com/api/drafts'地址为占位，需换成自己的只读路径；不携带Cookie、不自动跟随跳转，后续用匿名浏览器核对正文。未实机验证。
匿名、授权、未授权三种身份分别测
先在无站点登录态的会话请求公开页面，预期拿到正文；再请求私人路径，预期在内容交付前要求身份。随后用允许身份确认可以使用私人功能，再用不在允许范围的身份确认被拒绝。若没有第二个测试身份，就将该项标为未验证，不能把管理员成功登录推断为授权名单正确。不要把登录页面二百状态当作私有正文泄漏，也不要只凭三零二就认定保护完备。
检查请求内容与跳转位置，尤其服务是否在前端加载私有数据后才把页面转走。接口应独立检查身份和权限，页面保护不是接口的替代品。读取接口与写入接口分别列在矩阵里，写入验收应采用无业务影响的受控测试对象并遵循应用流程；本文只提供只读请求示例，不要求读者对真实发布接口反复试点。保护规则的正反样本必须关联到同一个版本与配置。
补测别名、重定向与缓存
对同一私密资源列出带后缀、不带后缀、尾斜杠、平台默认入口和预览入口。不要假设某个地址不在导航里就不会被访问，也不要假设重定向后的地址继承了原地址保护。查看第一跳状态和目标，再继续检查最终响应；静态托管的路径标准化可能改变匹配到的规则，所以验收以实际请求为准。
缓存也需要作为交付链路检查：同一资源在已登录会话访问过后，匿名会话是否仍被拒绝；公开缓存是否可能保存私人响应。不要仅刷新自己的管理员标签页测试。macOS 与 GNU/Linux 的 curl 可以做无 Cookie 的基线请求，但它不会像浏览器一样完成所有登录交互；DSM 上若只是私人服务目标，仍优先从客户端检查，不改变系统防火墙来模拟外部访问。下方矩阵可在普通编辑器填写，不依赖系统差异。
| 入口 | 匿名 | 允许身份 | 不允许身份 | 缓存后匿名 |
| --- | --- | --- | --- | --- |
| 正式文章 | 正文/待测 | 正文/待测 | 正文/待测 | 待测 |
| /editor与尾斜杠变体 | 拦截/待测 | 可用/待测 | 拒绝/待测 | 待测 |
| 草稿只读接口 | 拦截/待测 | 可读/待测 | 拒绝/待测 | 待测 |
| 私人附件 | 拦截/待测 | 可读/待测 | 拒绝/待测 | 待测 |
| 平台默认入口 | 按保护设计/待测 | 待测 | 待测 | 待测 |
| 预览入口 | 按保护设计/待测 | 待测 | 待测 | 待测 |
规则版本：<待填>；未验证项：<待填>；恢复规则：<待填>可复制工作表，示意且未实机验证；填写自己的材料，待测项不代表实际成功。
让以后加入的功能也有检查入口
加入上传、同步或在线发布时，为新接口明确谁可调用、可操作哪些资源、未授权时如何响应。原本只在浏览器本地保存文本的写作台，一旦出现服务端存储，其威胁边界和恢复流程都会变化。把“新增公开资源审查”和“私人接口匿名拒绝”加入发布验收，比记住某个控制台开关更持久。每次更新保留实际核对日期，不回填未经发生的历史。
若调整后把公开正文也拦住，先对照路径命中规则修正最小范围，不把整个站点保护关闭作为应急默认。若私人内容能匿名取得，则暂停这次开放变更并恢复上一份已验证配置，同时检查是否有公开产物需要撤换。完成标准是公开体验与私人边界同时成立。收尾归档规则说明和矩阵，记录未测试身份、备用入口或缓存情景，下一次就知道还有哪些边界尚未证明。
填写工作表，把示例变成自己的记录
矩阵中的“匿名”指没有携带现有登录状态的请求，而不是管理员把页面刷新一次。先用 curl 的首跳结果观察拦截位置，再用新的浏览器会话核对最终内容；如果系统以登录页二百响应，记录正文类型和位置，而不是机械要求每项都返回同一状态码。矩阵不存 Cookie、令牌或身份详情，只保存角色与允许结果。写入接口的测试单独标为待验证，本文不会用真实发布动作检验权限。
资源归属模板可以在每次新增功能时复制一行。若新增附件属于私人草稿，应同时填写交付路径和保护方式，不能只给编辑页面加锁。若资源已打进公共脚本，应回到构建范围修正，不能在表里写“路径隐藏”当作保护方式。最后检查预览入口一栏是否有实际记录；没有权限或无法获取入口时，明确标为未核对，并把它留在上线前待办中。这样的空项比没有依据的全通过更能保护实际边界。