本文详解 nginx fastcgi 缓存中 `fastcgi_cache_key` 失效的根本原因，重点分析 `$request_uri` 与自定义变量（如 `$original_path`）在缓存键生成中的行为差异，并提供稳定、可复现的配置实践。
在 Nginx 的 FastCGI 缓存机制中，fastcgi_cache_key 是决定缓存是否命中（HIT/MISS）的核心参数。你当前配置中使用了自定义变量 $original_path 作为缓存键：
set $original_path $request_uri;
if ($request_uri ~ "^([^?]*)(\?.*)?$") {
set $original_path $1;
}
# ...
fastcgi_cache_key "$original_path";问题本质在于：if 指令在 location 块外执行时，其作用域和执行时机存在不确定性，且 if 在 server 级别中属于“重写阶段前”的非标准上下文——它不保证在所有请求路径中都被一致执行，尤其在涉及多 ISP、不同 User-Agent、代理转发或请求头差异时，$original_path 可能未被正确赋值或被覆盖。
更关键的是：Nginx 的 fastcgi_cache_key 在内部缓存查找阶段对变量的求值，严格依赖变量的“确定性”和“可缓存性”。而 if 块中定义的变量（尤其是跨 location 边界的）可能因执行顺序、条件跳过或模块兼容性问题，导致实际参与哈希计算的值为空、为默认值，或每次请求不一致——这直接造成缓存键失真，表现为同一 URL 在不同网络环境（如 ISP 1 vs ISP 2）下缓存命中率不一致。
✅ 推荐解决方案：直接使用内置可信变量
fastcgi_cache_key "$request_uri";
$request_uri 是 Nginx 内置变量，始终包含原始请求的完整 URI（含 query string），且在 FastCGI 缓存上下文中被安全、稳定地解析。若需去除 query string（如忽略 ?utm_source=xxx），应改用更健壮的方式：
# ✅ 安全、无 if 的方式：使用 map 指令（推荐）
map $request_uri $cache_uri {
~^(?<clean_uri>[^?]+) $clean_uri;
default $request_uri;
}
# 然后在 location 中使用：
fastcgi_cache_key "$cache_uri";⚠️ 注意事项：
- if 在 server 块中应尽量避免，尤其不应用于影响缓存逻辑的关键变量；Nginx 官方文档明确指出 if 在 location 外的行为“不可预测”。
- fastcgi_cache_key 必须在 location ~ \.php$ 块内定义，且确保其引用的变量已在该作用域中可靠初始化。
- 确保 fastcgi_cache 指令与 fastcgi_cache_key 同处一个 location，否则缓存策略可能不生效。
- 验证缓存状态：通过 add_header X-Cache "$upstream_cache_status-$ua_device"; 查看响应头，同时启用 log_format 记录 $upstream_cache_status 和 $cache_uri 便于调试。
? 总结：
不要用 if + set 构造缓存键变量。优先使用 $request_uri；如需剥离 query string，请使用 map 指令（在 http 块中定义），它在请求处理早期即完成匹配，线程安全、无副作用，是 Nginx 官方推荐的替代方案。此外，建议升级至 Nginx 1.20+（支持更严格的变量作用域控制与调试能力），并配合 nginx -t 和 error_log ... debug; 进行深度验证。
