排查Nginx proxy_cache缓存文件被意外篡改，核心是确认缓存写入链路是否被非法干预：检查缓存路径权限与归属是否被绕过、验证上游响应是否被注入恶意内容、确认proxy_cache_key是否引入不可信变量导致串扰、排查文件系统层是否被劫持或挂载异常。
排查 Nginx proxy_cache 缓存文件被意外篡改，核心不是检查“文件内容是否变”，而是确认缓存写入链路是否被非法干预——篡改往往源于配置失控、路径越权或上游污染，而非磁盘被黑。
检查缓存路径权限与归属是否被绕过
缓存文件若被非 Nginx 进程修改，最常见原因是目录权限过宽或属主错误：
- 运行
ls -ld /var/cache/nginx（路径以proxy_cache_path配置为准），确认属主是 Nginx 工作用户（如www-data或nginx），且权限不包含 world-writable（如drwxrwxrwx） - 检查父目录是否可写：Nginx 必须对整个路径有
x权限才能进入子目录，ls -ld /var/cache和/var/cache/nginx都要验证 - 搜索是否有其他服务向该目录写入：用
lsof +D /var/cache/nginx | grep -v nginx查看非 Nginx 进程是否持有缓存目录句柄
验证上游响应是否被注入恶意内容
缓存内容本身被篡改，大概率是后端返回了异常数据，Nginx 照单全收并缓存：
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
- 临时关闭缓存，在对应
location中加proxy_cache_bypass 1; proxy_no_cache 1;，用curl -I多次请求同一接口，比对Set-Cookie、X-Content-Type-Options等关键响应头是否稳定 - 开启详细日志：
log_format debug '$remote_addr - $request_time $upstream_response_time $upstream_status $upstream_http_content_length "$upstream_http_x_source"'，配合access_log观察后端返回状态和大小波动 - 若发现
200响应中混有302重定向、HTML 注入片段或异常 JS 脚本，说明上游已被攻陷或存在逻辑漏洞
确认缓存键是否引入不可信变量导致串扰
看似“被篡改”，实则是不同用户/场景的响应被错误复用到同一缓存条目：
- 检查
proxy_cache_key是否含$cookie_*、$http_authorization、$args等未过滤字段——这些若被攻击者控制（如伪造 Cookie），就能让其响应覆盖他人缓存 - 快速验证：临时将键简化为
proxy_cache_key "$scheme$host$request_uri";，观察异常响应是否消失；若消失，说明原键设计引入了不稳定因子 - 对需隔离的接口（如
/api/user），应使用后端可控标识（如$upstream_http_x_user_hash），而非前端传入的原始凭证
排查缓存文件系统层是否被劫持或挂载异常
极少数情况下，篡改发生在文件系统层面：
- 运行
mount | grep "$(dirname $(grep proxy_cache_path /etc/nginx/nginx.conf | awk '{print $2}'))"，确认缓存目录所在分区未被 bind mount 或 overlayfs 覆盖 - 检查是否启用
use_temp_path=off：若为on，Nginx 先写临时目录再 rename，中间过程可能被截获；生产环境应始终设为off - 用
stat /var/cache/nginx/xxx查看文件的Change时间戳，对比访问日志时间——若变更时间远早于请求时间，说明是历史残留或外部写入
