nginx原生不支持正向代理缓存，proxy_pass仅用于反向代理；正向代理需第三方模块且不支持proxy_cache指令，强行配置会被静默忽略；所谓成功案例多为配置混淆或私有定制版，生产环境不可靠。
Nginx 本身不支持正向代理缓存，官方明确不推荐、也不维护正向代理功能；所谓“Nginx 正向代理缓存”，实际是误用或非标改造（如打补丁、混用模块），生产环境不可靠，更不存在标准的缓存清理机制。
为什么 Nginx 不适合做正向代理缓存
• 官方文档明确说明：Nginx 的 proxy_pass 仅设计用于反向代理；正向代理需依赖第三方模块（如 ngx_http_proxy_connect_module），且该模块不支持 proxy_cache 系列指令，无法启用磁盘缓存；
• 即使强行配置 proxy_cache_path 并在正向代理 location 中启用 proxy_cache，Nginx 会静默忽略缓存逻辑，请求始终穿透，缓存目录不会写入文件；
• 所有声称“Nginx 正向代理缓存成功”的案例，基本源于配置混淆（把反向代理当正向用）、日志误读，或使用了高度定制的私有分支（如某些旧版 OpenResty 衍生版），不具备通用性和可维护性。
如果你真在用非标正向代理并产生了缓存文件
这种情况极大概率是：
• 你实际部署的是反向代理，但客户端配置了 HTTP 代理（如浏览器设了 127.0.0.1:8080），而 Nginx 把它当作普通请求处理，并启用了 proxy_cache；
• 或者你使用了带缓存能力的增强版（如含 cache_purge + 自定义 connect 模块的编译版），此时缓存行为完全取决于该定制实现，Nginx 原生机制不适用。
若确认缓存目录（如 /var/cache/nginx/forward_cache）确实在增长，可按反向代理缓存方式处理：
- 检查
proxy_cache_path是否设置了inactive（例如inactive=30m），这是自动清理冷缓存的唯一原生方式； - 避免依赖“过期时间”清理——
proxy_cache_valid控制的是缓存是否可被复用，不触发物理删除；真正删文件只靠inactive+ worker 空闲扫描； - 不建议 cron 全量清空，除非你接受服务期间偶发缓存重建延迟；如必须，脚本中加锁（如
flock）防止并发冲突； - 用
find … -mmin +60 -delete替代rm -rf *，按修改时间过滤，更安全可控。
更合理的技术替代方案
• 需要正向代理缓存，请改用专为此设计的软件：
– Squid：成熟稳定，支持精细缓存策略（LRU、TTL、磁盘配额、定期 sweep）；
– Polipo 或 Privoxy（轻量级，适合内网）；
– 企业场景可用 Blue Coat 或 Zscaler 等商业代理网关。
• 若只是想节省出口带宽或加速上游访问，考虑：
– 在反向代理层统一缓存后端 API/静态资源，由客户端直连该反代地址；
– 用 CDN 或边缘节点（如 Cloudflare Workers + Cache API）替代本地正向缓存。
