页面打不开、内容不更新或只有部分地区访问失败时，先别急着改源站配置。CDN日志分析如何定位请求异常，关键是把同一请求在边缘节点与源站的记录对起来，再看状态码、缓存结果和耗时分别指向哪一层。以下方法适用于网页、图片、下载文件及 API 等常见请求；日志字段名称会因服务商和日志版本而异。
先把异常请求缩小到可比范围
一条日志只有和明确的请求条件对应，才有排查价值。记录发生时间及所用时区、完整路径、请求方法、状态码、客户端大致地区，以及异常表现。若 URL 含查询参数，也要确认参数是否影响内容或缓存键；把不同参数的请求混在一起，可能会误判为同一资源表现不一致。
优先选一个成功请求和一个失败请求对比。检查两者是否使用相同域名、路径、方法和关键请求头，并确认采集时间覆盖故障时段。排查 API 时，注意 GET、POST 的处理规则可能不同；不要为了复现而记录或传播 Cookie、令牌等敏感信息。
按状态码判断异常在哪一层
先区分边缘响应与源站响应
不要只看客户端最终收到的状态码。若日志提供边缘状态码和源站状态码，先并排查看：边缘返回 403、源站没有对应请求，可能需要检查 CDN 的访问控制或安全规则；边缘返回 502 或 504，且有回源失败记录，则应继续看源站连接、响应时间和网络错误。具体原因仍要结合服务商定义，不能仅凭一个码下结论。
404 可能来自源站，也可能是边缘缓存了先前的未找到响应；200 也不保证内容正确，缓存中的旧版本仍可能成功返回。304 表示客户端可使用已缓存内容，需同时核对缓存验证相关请求头。对 CDN日志分析如何定位请求异常而言，状态码是分流线索，不是最终诊断。
同一状态码也要看缓存结果
查看缓存命中、未命中、绕过或重新验证等记录（各平台命名不同）。命中时，请求通常由边缘直接响应，源站可能没有新记录；未命中时才会发生回源。若仅命中请求异常，检查缓存键、缓存时长及失效操作；若命中与未命中都异常，则要进一步核对源站响应和访问规则。
用节点和回源记录验证判断
边缘节点标识可帮助判断故障是否集中在特定区域或节点，但单个请求不足以证明节点故障。对比相同时间、相同资源的多条请求：若某一地区反复失败而其他地区正常，检查该节点的错误类型、缓存状态与回源结果；若各地都出现相同源站错误，优先检查源站服务。
回源日志重点看请求是否到达、源站状态码、连接或响应耗时，以及返回内容长度等字段。边缘记录显示回源超时，源站日志却没有对应请求，问题可能发生在请求到达源站之前；源站已收到请求但迟迟未响应，则应检查源站负载、上游依赖或超时设置。日志时间有偏差时，应先统一时区并留出采集延迟。
按顺序执行，避免同时改多项配置
固定一条异常请求，保存时间、路径、方法、状态码及请求 ID；请求 ID 可用于跨日志关联，字段名称依服务商而定。
在 CDN 访问日志中查找该请求，核对边缘状态码、节点标识、缓存结果和回源耗时。日志尚未生成时，先确认日志投递与查询的时间范围。
有回源记录时，用时间、路径或关联 ID 查源站访问日志，判断源站是否收到请求，并对照其状态码和响应耗时。
将失败请求与相同条件下的成功请求比较。若差异只在节点或缓存结果，针对对应缓存策略、区域或规则继续查；若差异落在源站响应，转查源站配置和依赖服务。
每次只调整一项配置，并用相同请求复核边缘日志与源站日志。变更缓存规则后，还要考虑旧缓存何时失效；不要用一次命中变化就认定问题已解决。
以 Amazon CloudFront 为例，访问日志中可查看边缘位置、请求结果及状态等信息；具体字段和可用日志类型会随配置而不同。使用其他 CDN 时也按同一思路找等价字段，而不是照搬字段名。CDN日志分析如何定位请求异常，最终依靠的是请求关联、节点对比和回源证据相互印证。
常见问题
只有用户反馈，没有请求 ID，怎么查？
先取得大致发生时间、访问路径、方法和客户端地区，再用短时间窗口筛选日志。若同一时间请求很多，补充响应状态或可安全提供的请求标识；不要索取密码、令牌等敏感信息。
边缘返回 200，为什么页面仍然异常？
200 只说明请求成功返回。检查响应内容是否过旧或错误、缓存键是否区分必要参数，以及浏览器是否使用了本地缓存。
日志里没有源站记录，是否一定是 CDN 故障？
不一定。缓存命中本来就可能不回源；访问也可能被边缘规则拦截，或相关日志尚未生成。先结合缓存结果、边缘状态和日志采集延迟判断。