Nginx可能直接提供缓存或在特定条件下提供旧副本，因此客户端收到200不一定代表本次访问成功请求了上游。排查健康状态时，应区分返回状态、缓存状态和上游响应，再关联真实应用检查。
记录客户端与服务器两侧信息
查看访问日志中的最终状态、适用的upstream状态及缓存状态，确认当前日志格式确实包含这些字段。不能看到一个200就假设PHP本次已执行，也不能看到缓存HIT就推断后台、数据库和所有接口都正常。先限定请求对象和时间。
理解命中、回源和旧副本条件
命中可能不访问上游，过期后重新验证或在错误条件下使用旧缓存又有不同路径。读取当前proxy或fastcgi缓存配置，不把另一站的缓存行为套过来。某些请求因登录或业务Cookie绕过，因此要分别查看匿名公共页与动态路径。
为健康检查选择合适端点
静态缓存页面适合验证对外内容可达，但不足以确认依赖链。根据监控目的设计受控、低成本的应用检查，避免公开重操作或敏感状态。健康探测不能每几秒触发真实下单、发信或备份，也不应成为新的服务器负担。
在实际故障与恢复中对照
观察上游出错时缓存是否按既定策略提供内容，用户是否仍能进入需要动态处理的业务。恢复后核对新内容和缓存失效，避免长期旧副本掩盖更新失败。报告中分开写公共内容可访问、上游健康与功能验证，不用一个状态替代全部。
关键区别
最终状态：客户端收到的响应；可能来自缓存副本。
缓存状态：本次缓存处理路径；不等于应用健康。
上游状态：后端响应的线索；需要结合日志和业务。
怎样确认处理到位
监控和日志能区分缓存提供与真实回源，应用关键依赖有合适检查，恢复后内容更新正常且结论注明各自范围。
容易误判的边界
公共页面缓存可用并不保证登录、询盘或支付正常；健康检查也不能通过制造真实业务来证明。
