很多兄弟接入360CDN后，觉得开启了缓存和HTTPS就万事大吉了。其实，CDN控制台里那些看似枯燥的访问日志，才是真正排查线上疑难杂症的"金矿"。今天结合我最近的一个实战复盘，聊聊如何通过分析 upstream_response_time（源站响应时间）和 cache_status（缓存状态）这两个核心字段，快速定位是CDN的锅还是源站的锅。
核心痛点：用户反馈慢，到底是谁的锅？
当用户反馈页面加载慢时，传统排查往往是CDN运维和后端开发互相"甩锅"。CDN说节点正常，后端说代码没动过。其实，只要拉取360CDN的日志，答案一目了然。
实战分析：两个关键字段的排列组合
在日志中，我们重点关注以下两种极端情况：
cache_status为 MISS 且upstream_response_time较大
这说明请求没有命中CDN缓存，直接回源了，而且源站处理这个请求花了很长时间。- 结论 ：这是典型的源站性能瓶颈。可能是后端数据库查询慢、代码逻辑复杂或者服务器负载过高。这时候别折腾CDN配置了，赶紧去优化后端代码或给源站扩容。
upstream_response_time很小，但用户端延迟依然很大
这说明源站处理得飞快，但用户依然觉得卡。- 结论 ：问题大概率出在用户本地网络 或CDN节点至用户链路的"最后一公里"。比如用户处于弱网环境，或者跨运营商调度出现了异常。这时候可以检查CDN的智能调度策略，或者引导用户排查本地网络。
避坑指南：缓存策略的"生死线"
在配置日志分析前，一定要确保你的缓存策略没配错。我见过太多人误将 /api/* 这类动态接口设置为"缓存所有"，导致用户看到过期数据。正确的做法是：动态接口坚决不缓存，静态资源（如图片、CSS）开启"忽略参数缓存"并设置较长的过期时间（如30天）。这样不仅能提升缓存命中率（实测可从70%提升至92%以上），还能让日志分析的结果更具参考价值。
总结：运维不仅要会配CDN，更要会看日志。掌握了这两个字段，排查线上故障的效率至少提升一倍！