Nginx proxy_cache仅支持本地磁盘，无法直接使用Redis作为后端；实际的“Nginx结合Redis”是多级缓存架构：Nginx负责边缘一级缓存，Redis承担中心二级共享缓存，职责分离，协同工作。
Nginx 本身不支持直接将 Redis 作为 proxy_cache 的后端存储——proxy_cache 只能使用本地文件系统，其缓存路径（proxy_cache_path）必须指向本机磁盘。所谓“Nginx 结合 Redis 实现分布式缓存管理”，实际是构建**多级缓存架构**：Nginx 负责边缘层本地缓存（一级），Redis 承担中心层共享缓存（二级），两者职责分离、协同工作，而非让 Nginx 把缓存写进 Redis。
明确角色分工：Nginx 缓存 ≠ Redis 缓存
二者定位不同，不可替代：
- Nginx proxy_cache：部署在离用户近的边缘节点（如各机房），缓存静态资源（JS/CSS/图片）或简单 API 响应；高性能、低延迟、零网络开销；但仅限本机，无法跨节点共享
- Redis：集中部署在中心集群，缓存结构化、个性化、需强一致性的数据（如用户会话、商品详情、带权限的接口结果）；支持过期、淘汰、持久化与集群扩展；天然适合分布式场景
典型二级缓存流程（推荐架构）
一次请求的缓存流向如下：
- 客户端请求到达 Nginx → 先查本地
proxy_cache（命中则直接返回，最快） - 未命中 → Nginx 转发请求至后端服务（如 Node.js/Java 应用）
- 后端服务先查 Redis（二级缓存）→ 命中则组装响应并回写 Nginx 缓存（可选）
- Redis 未命中 → 后端查数据库 → 写入 Redis（设 TTL）→ 返回响应 → Nginx 可按规则缓存该响应（如 public 接口）
关键点：Nginx 不操作 Redis，Redis 也不参与 Nginx 的缓存生命周期管理；所有协调逻辑由后端服务控制。
WebChat Voice Proxy
下载
⚠️ 已弃用 — 该技能已拆分为两个独立技能，以提升模块化程度：**webchat-https-proxy**（HTTPS/WSS 反向代理）和 **webchat-voi...**
配置要点：让两级缓存不冲突
避免因 HTTP 缓存头混乱导致行为异常：
- 对需 Redis 管理的数据（如含 Cookie、Authorization 的接口），后端返回
Cache-Control: private, no-store或no-cache，确保 Nginx 不缓存也不落盘 - 对可被 Nginx 缓存的公共数据（如首页轮播图、公告），后端返回
Cache-Control: public, max-age=3600，并确保响应不含敏感头（如Set-Cookie） - Nginx 配置中显式忽略干扰头：
proxy_ignore_headers Set-Cookie Cache-Control Expires;（防止源站禁止缓存的指令覆盖你的策略） - 用
proxy_no_cache主动拦截私有请求：proxy_no_cache $http_authorization $cookie_sessionid $arg_debug;
不推荐的“伪集成”方式（踩坑预警）
以下做法看似“结合 Redis”，实则违背设计原理，易引发问题：
- 试图用第三方模块（如
ngx_http_redis_module）把 Nginx 当 Redis 客户端去读写 —— 这属于自定义反向代理逻辑，不是proxy_cache，且丧失缓存原子性、锁机制（proxy_cache_lock）、自动驱逐等核心能力 - 将
proxy_cache_path指向 NFS/CephFS 等共享存储，幻想实现“跨机房共享缓存” —— 文件系统不支持 rename 原子操作，会导致缓存损坏、key 冲突、inactive失效、cache_lock彻底失能 - 在 Nginx 层解析 Redis 响应并手动 set_header 回传 —— 绕过
proxy_cache机制，等于放弃整个缓存管理体系，变成手工缓存代理
真正可靠的分布式缓存管理，靠的是分层职责 + 协议驱动（HTTP 头）+ 后端主动控制，而不是让 Nginx 去接管 Redis。
