Apache 不主动识别业务重复请求,需通过后端协作实现幂等:透传幂等头、禁用干扰ETag、配置mod_cache缓存只读接口(需Cache-Control: public且无Set-Cookie),并可用mod_evasive防御高频异常请求。

Apache 本身不主动识别“重复请求”的业务语义,它不会自动判断两个 POST 是否内容相同、是否属于同一笔订单。所谓“规避重复请求处理”,实际是通过组合配置与后端协作,实现防止重复提交、降低重复响应开销、拦截已知重复标识
用 Apache 拦截显式重复标识(如请求 ID)
若前端在每次请求中携带唯一且可验证的标识(如 X-Request-ID 或 X-Dedup-ID),可用 mod_rewrite + mod_headers + 外部缓存(如 Redis)配合拦截——但 Apache 原生不支持 Redis 查询,因此推荐由后端统一校验。Apache 可做轻量级前置过滤:
- 用
RewriteCond检查请求头是否存在重复 ID,并记录到日志便于审计:RewriteCond %{HTTP:X-Request-ID} ^(.+)$RewriteRule .* - [E=REQID:%1]LogFormat "%h %l %u %t \"%r\" %>s %b %{REQID}e" deduplog - 若已有成熟防重服务(如 Nginx + Lua 或独立网关),建议将去重逻辑前置,Apache 仅作静态资源或透传角色
配合后端实现幂等性,Apache 透传关键头
真正可靠的重复请求规避,依赖后端生成并验证幂等键(如基于参数哈希、时间戳+用户ID)。Apache 需确保不干扰这些机制:
Apache Superset 是一个广泛采用的开源 BI 平台,用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时,此技能非常有用。
- 禁用可能覆盖或混淆的默认行为:
Header unset ETagFileETag None(避免 Apache 自动加 ETag 干扰业务 ETag) - 透传客户端携带的幂等头:
RequestHeader set X-Idempotency-Key "expr=%{req:X-Idempotency-Key}"
确保该头完整传递给后端应用(如 Spring Boot 的@RequestHeader("X-Idempotency-Key")) - 对已确认幂等的响应,可加缓存提示(非强制缓存):
<LocationMatch "^/api/v1/order/create"><br> Header set Cache-Control "no-store, max-age=0"<br></LocationMatch>
利用 mod_cache 缓存只读接口,天然规避重复计算
对查询类 API(如 GET /users/123),让 Apache 缓存响应体,后续相同请求直接返回,无需后端参与——这本质是“规避重复处理”最高效的方式:
- 后端必须返回合法缓存头:
Cache-Control: public, max-age=300,且不含Set-Cookie、Vary: *、Vary: Authorization - Apache 配置启用磁盘缓存:
LoadModule cache_module modules/mod_cache.soLoadModule cache_disk_module modules/mod_cache_disk.soCacheRoot /var/cache/apache2/mod_cache_diskCacheEnable disk /api/v1/ - 关键开关不能漏:
CacheIgnoreCacheControl Off(否则后端设了max-age也会被忽略)
限制高频重复行为(防御性配置)
针对明显异常的重复请求模式(如 1 秒内同一 IP 对同一路径发 5 次 POST),可用 mod_evasive 或 mod_ratelimit 做粗粒度防护:
- 安装并启用
mod_evasive(非默认模块,需单独编译或 apt install libapache2-mod-evasive):DOSPageCount 2DOSSiteCount 50DOSPageInterval 1DOSSiteInterval 1DOSBlockingPeriod 60 - 注意:这类规则适用于防护爬虫或误操作,不能替代业务层幂等设计;真实支付、下单等场景必须由后端基于业务状态做精确判重

















