proxy_cache_methods 不阻止请求，而是白名单机制；验证 POST 未缓存需检查日志中 upstream_cache_status 为“-”、缓存目录无新增文件、响应头无缓存标识、后端每次均收到请求。
proxy_cache_methods 本身不“阻止”请求，它只是白名单开关——没列在里面的 HTTP 方法，压根不会进入缓存流程。所以测试重点不是看它“拦住”了什么，而是验证：当 POST 不在 proxy_cache_methods 列表中时，它是否真的完全绕过缓存（包括不生成、不读取、不更新任何缓存条目）。
确认 POST 请求未被纳入缓存路径
最直接的验证方式是检查 Nginx 缓存日志或响应头，确认 POST 响应从未触发缓存写入逻辑：
- 确保 未配置
proxy_cache_methods GET HEAD POST，只保留默认或显式写为GET HEAD - 在对应 location 中启用缓存（
proxy_cache my_cache）并开启缓存日志：log_format cache '$remote_addr - $request_method $request_uri $upstream_cache_status';
然后在 access_log 中使用该格式 - 发起一次 POST 请求（如
curl -X POST http://example.com/api -d '{"id":1}'），观察日志中$upstream_cache_status字段：
→ 若显示 -（短横线），说明缓存模块完全未参与；
→ 若显示 MIS、HIT 或 EXPIRED，说明缓存流程被意外触发（配置有误）
检查缓存存储目录是否新增文件
Nginx 只对进入缓存流程的请求才写入缓存文件。可人工验证 POST 是否产生缓存实体：
- 先清空缓存目录（如
rm -rf /var/cache/nginx/my_cache/*） - 发起若干次相同参数的 GET 请求，确认缓存目录中出现新文件（用
find /var/cache/nginx/my_cache -type f | wc -l统计） - 再发起相同 URL 的 POST 请求（保持其他条件一致），等待几秒后再次统计：
→ 若数量未增加，说明 POST 未写入缓存；
→ 若数量增加，说明proxy_cache_methods或配套指令（如proxy_cache_key）配置错误，导致 POST 被误判为可缓存
对比响应头与缓存行为
即使不写日志或查文件，也能通过响应头快速判断缓存是否介入：
- 对同一接口分别发 GET 和 POST 请求，都带上
Cache-Control: no-cache或后端返回X-Accel-Expires: 0 - 观察 GET 响应头中是否出现
X-Cache: HIT或X-Cache: MISS（需你自定义添加）；而 POST 响应头中不应出现任何缓存标识字段** - 更关键的是：多次重复相同 POST 请求，后端日志应显示每次都被转发（无跳过），且响应时间基本一致；若某次明显变快且后端无日志，则说明缓存被意外命中
排除常见误配干扰
很多“POST 被缓存”的现象其实和 proxy_cache_methods 无关，而是其他指令覆盖或绕过了它：
- 检查是否误用了
proxy_no_cache或proxy_cache_bypass—— 它们作用于已进入缓存流程的请求，不能替代proxy_cache_methods的准入控制 - 确认没有在 http 块顶层单独写
proxy_cache_methods POST，该写法无效（必须配合proxy_cache在 location 中使用） - 避免
proxy_cache_key中遗漏$request_method：如果 key 里没包含方法，GET /api 和 POST /api 可能共用一个缓存项，造成“伪命中”
