先看现象。给 /v1/models 配了 CDN 缓存 1 小时，新上线的模型在网关里能查到，前端列表一小时都看不到，手动 purge 才出现；后来发现 /v1/chat/completions 也被同一条规则缓存，两个租户拿到了彼此的响应。
排查方向其实有限，先把可能性排一排。CDN 规则按路径前缀匹配，把 /v1/* 全缓存了。也可能是源站没返回 Cache-Control: no-store。
少数情况下是缓存 key 没带 Authorization，不同租户互相命中。
不容易想到的是，purge 只清了边缘节点，中间层还有残留。
动手时先看响应头里的缓存标记
curl -sI https://api.example.com/v1/models | grep -i -E 'cache-control|age|x-cache'随后确认源站是否显式禁缓存
curl -sI https://origin.example.com/v1/models | grep -i cache-control接着把动态接口的缓存规则改成 bypass
python -c "print('path: /v1/* action: bypass')"剩下的就是按路径 purge 后立刻复测
curl -s -X PURGE https://api.example.com/v1/models && curl -s https://api.example.com/v1/models | head -c 200怎么算真的好了，看的是同一批现象。响应头里 age 为 0 或没有 x-cache: HIT，新模型上线后立即出现在列表里，不同租户的请求不再互相串数据。
这里还有个坑。CDN 默认按路径后缀猜缓存策略，/v1/* 这种 API 前缀一定要显式 bypass；带鉴权的接口缓存 key 必须包含身份，否则就是数据泄露。如果同一现象隔几天又出现，说明根因没找到，别当偶发处理。