WhatsApp Cloud API多次向webhook重复推送旧消息入站通知问题

• Webhook响应不符合Meta官方规范：WhatsApp Cloud API的推送容错逻辑明确要求，接收端必须在收到推送后的20秒内返回200 OK的HTTP状态码。如果Meta服务端未在窗口期收到正确的成功响应，就会按照梯度退避策略反复重试推送，重试周期最长覆盖消息生成后的24小时。90%以上的重复推送问题都源于此：多数开发者会把消息存库、自动回复生成、内部系统接口调用等耗时逻辑放在webhook的同步响应链路里，一旦逻辑执行超时、代码抛出异常未捕获，就会让Meta判定推送失败，持续重推旧消息。
• 缺失幂等去重逻辑：Meta的重试机制本身是为了保证消息不丢的正常设计，但如果接收端没有基于消息唯一ID做去重，就会把重试推送的旧消息当成新入站消息处理，表现为无意义的重复通知。
• 存在重复的webhook订阅：如果同一个WhatsApp Business Account（WABA）下，同一个回调地址被重复添加了订阅规则，或是测试应用、其他绑定号码的webhook也指向了同一个回调地址，会触发多链路的重复推送。
• 前置网关层拦截/超时：如果webhook服务前挂了Nginx、云API网关、WAF等组件，这类组件的默认超时时间如果短于20秒，或是拦截规则误拦截了Meta的推送IP段，会导致后端即使正常处理了请求，Meta收到的也是超时、403、5xx等非成功响应，同样会触发重试。

• 调整webhook响应逻辑：收到Meta推送后，完成签名校验就第一时间返回200 OK状态码，所有业务处理逻辑全部放到异步任务队列执行，不要让任何耗时操作阻塞响应返回，尽量把接口整体响应耗时控制在1秒以内，从根源避免触发重试机制。
• 加严幂等去重规则：每条WhatsApp入站消息都带全局唯一的messages[0].id字段，收到请求先提取这个ID，查本地缓存或数据库判断该消息是否已经处理过，若已处理直接丢弃请求返回200即可，不要重复执行业务逻辑。建议缓存过期时间设为25小时，完全覆盖Meta的最长重试窗口。
• 排查重复订阅配置：登录Meta开发者后台，进入对应WhatsApp应用的Webhooks配置页，检查是否存在重复添加的同地址订阅规则，同时排查WABA下其他绑定号码、测试应用的webhook配置，删除所有多余的重复订阅。
• 校准前置网关配置：把webhook前挂载的Nginx、API网关、WAF的超时时间统一调整为30秒以上，同时检查WAF拦截规则，不要把Meta官方的推送IP段加入拦截列表，避免网关层提前截断请求返回非200响应。
• 加日志定位异常节点：给webhook服务加全量日志，记录每次推送的消息ID、接口响应状态码、响应耗时，以及前置网关的访问日志，快速定位是代码逻辑超时、网关拦截还是其他问题导致Meta没有收到成功响应。

内容的提问来源于stack exchange，提问作者Parth Panchal