API 接入 CDN 或其他边缘节点后，响应更快不代表规则更安全。API边缘加速中的缓存绕过、鉴权与速率控制需要一起检查：缓存决定谁能复用响应，鉴权决定请求是否有权访问，限流则约束请求速率。下面以公开目录接口和个性化账户接口为例，列出上线前可执行的五项检查。
1. 先划分可缓存与不可缓存接口
不要仅凭路径包含“/api”就统一缓存，也不要把所有接口都设为绕过。公开、内容相同且短时间变化不敏感的 GET 请求，可以评估边缘缓存；包含账户信息、权限结果或一次性数据的响应，通常应绕过缓存或明确禁止存储。
- 列出接口路径、HTTP 方法和响应是否因用户身份变化。
- 对个人资料、订单状态等个性化响应，在源站返回合适的 Cache-Control，例如 private 或 no-store；具体策略需与客户端缓存需求一致。
- 选一个公开 GET 接口验证命中，再用不同用户请求个性化接口，确认不会复用前一用户的响应。
边缘平台对响应头和缓存规则的处理可能不同，需查对应产品配置，并以实际响应头和缓存状态验证，不能只依赖控制台中的规则名称。
2. 核对缓存绕过条件与缓存键
第二项是确认哪些请求必须绕过，以及哪些请求差异必须进入缓存键。缓存键是边缘节点区分缓存对象的依据；若语言参数会改变公开内容，应将相关参数纳入缓存键或按规则拆分。反之，随意把所有查询参数都纳入，可能造成大量低命中缓存。
按请求特征逐项测试
- 检查 Authorization、Cookie 等身份相关请求头是否触发绕过，尤其要避免将带凭证的个性化响应存成共享对象。
- 检查影响内容的查询参数和必要请求头；忽略某个参数前，先确认它不会改变响应。
- 对 POST、PUT 等有副作用的方法，通常不应套用普通 GET 缓存规则。
用同一资源分别发送无凭证、有凭证及不同参数的请求，比较状态码、响应主体和缓存命中信息。若响应应当私有，却显示共享缓存命中，应暂停相关缓存规则并排查缓存键与绕过条件。
3. 把鉴权放在可靠的位置
缓存绕过不等于鉴权。边缘节点可以先做令牌校验以减少无效流量，但源站仍应保留必要的权限判断，不能把“请求经过边缘”当作已授权。使用 JWT 时，至少要验证签名、有效期和预期受众；具体检查项取决于令牌规范及系统设计。
- 明确由边缘还是源站负责身份认证，以及两者各自检查什么。
- 用过期令牌、缺失令牌和无权访问资源的有效令牌分别测试，预期结果应区分未认证与无权限。
- 确认边缘到源站的访问路径受控；避免攻击者绕过边缘，直接访问一个缺少同等保护的源站。
缓存鉴权结果会引入过期和撤销延迟，若确有必要，应限定缓存时间并确认用户、权限范围都不会串用。
4. 让速率控制既有效又不误伤
速率限制要说明计数对象、统计窗口和超限响应。按单一来源地址计数配置简单，却可能把共享出口后的正常用户一起限住；按账号或 API 密钥计数更贴近调用者，但匿名请求仍需有基础防护。可采用令牌桶控制平均速率并允许有限突发，具体额度应依据正常业务基线、接口成本和容量测试确定，不宜照搬通用数字。
先为高成本写操作和普通读取设置不同策略，再用受控测试逐步提高请求速率，观察何时出现 429、响应是否包含合理的重试提示，以及合法请求能否恢复。多边缘节点的计数可能存在传播延迟；需要全局一致时，应确认产品是否提供集中计数或近似限流能力，并评估延迟与可用性取舍。
5. 验证规则顺序、日志与回滚
最后检查规则执行顺序：缓存规则不能意外覆盖鉴权或限流要求，例外路径也不应宽到包含整个 API。上线前用测试环境或小范围流量验证，记录请求路径、响应状态、缓存结果、限流命中和鉴权失败原因；日志避免保留完整令牌、密码等敏感值。
API边缘加速中的缓存绕过、鉴权与速率控制应作为一组策略复测：调整一条规则后，再覆盖公开与私有接口、有效与无效凭证、正常与突发流量。预先准备关闭单条缓存规则、收紧绕过范围或回退限流配置的步骤，出现异常时才有明确处置路径。
常见问题
所有带 Authorization 的请求都要绕过缓存吗？
个性化响应通常应绕过共享缓存。若要缓存，必须证明响应与用户无关，并正确设计缓存键及权限边界。
为什么缓存命中后仍要保留源站鉴权？
边缘配置可能被误改，也可能存在绕过边缘直连源站的路径。源站保留必要权限检查可形成纵深防护。
速率限制应该按 IP 还是账号设置？
账号或 API 密钥适合约束已识别调用者；来源地址适合补充匿名流量防护。可组合使用，并根据共享出口和误限流情况调整。
缓存规则改完怎样确认生效？
用不同凭证和参数重复请求，比较响应内容、缓存状态及源站日志；同时验证不应缓存的接口确实绕过缓存。
