上周一个做灯具的老板急了：蓝标办了、API也接了，测试的时候好好的，结果客户发来的消息一条都收不到，客服组干瞪眼。他第一反应是号被封了，吓得连夜问我要不要换号。
我让他先别动。ws蓝标接了API之后客户消息收不到，九成不是号的问题，是webhook这条「消息管道」断了。号没封、客户也没被拉黑，就是消息从Meta到你系统的路上丢了。
接API本身的坑，之前共存与迁移那篇讲过选型，承接分工讲过谁来回。这篇专讲管道：怎么判断断在哪一节、怎么修。
一、先分层：消息断在「Meta→服务器→程序」三段里的哪一段
排错误区是上来就改代码。正确的顺序是先分层，判断方法就一个动作——看你web服务器的access log：
| 判断 | 说明 | 断在哪 | 往哪修 |
|---|---|---|---|
| 日志里连POST都没有 | Meta根本没把消息推过来 | 上游配置（断点二、三） | 查订阅和号的状态 |
| 有POST但都是重复的 | 推过来了你没回200 | 接收层（断点四） | 改成先回200再干活 |
| 有POST、只回了一次，但客户消息还是没出现 | 你的程序把消息吞了 | 处理层（断点五） | 查签名校验和处理逻辑 |
这一步能帮你省掉大量瞎调的时间。如果access log里干干净净一个POST都没有，你改一百遍代码也没用，问题在配置。
二、断点一：验证做了，订阅没做（最常见的坑）
接webhook有三件事，很多人只做了第一件：
1. 公网HTTPS地址：必须是公网可访问、证书有效的地址，自签名证书Meta直接不认；
2. 验证握手：Meta发一个GET请求带challenge值，你原样返回，配置页才变绿；
3. 订阅：把你和WhatsApp业务账户订阅到一起。
坑在第三件上，它其实分两层：webhook地址在应用层配置一次就行，但每个WABA要单独做一次订阅。验证握手成功只代表「Meta确认这个地址是你家的」，不代表「这个账户的消息会推给你」——没订阅，握手游100次也是收不到。
判断方法：查询该WABA的订阅状态，返回是空的，就是这里断了。最容易中招的场景：接API的时候测试一切正常，后来新办了一个蓝标号挂在新WABA下面，没人记得给它做订阅——号是新的、配置页看着全绿，就是没消息。
还有一个很多人不知道的常识：接了API的号是纯API模式，客户消息只会推给webhook，永远不会出现在手机App的聊天列表里。别举着手机翻聊天记录了，那里注定什么都没有。往外发的这一侧（比如模板消息）是另一条线，别混着排查。
三、断点二：重试窗口一过，消息永久丢失，没有「补发」这回事
Meta对webhook的态度是：你不在，我重试；重试到底，就算了。
你的服务器返回200以外的任何东西、或者干脆没响应，Meta会按递减的频率自动重试，最长持续一周左右。听着很保险，但注意两点：一是这期间客户看到的是「消息发出去了」，你们的客服其实什么都不知道；二是重试窗口一过，这批消息就永久丢了，Meta没有提供任何回查历史通知的接口。
也就是说：宕机几小时，重试还能兜住；宕机一两天，那两天的客户消息就是凭空消失了，事后没有任何办法补。所以接API之后，日常运营那几件事里，监控告警要排进第一周。
| 丢消息方式 | 典型场景 | 后果 | 修复 |
|---|---|---|---|
| 没秒回200 | 处理逻辑太重，回包要等几秒 | Meta判定失败反复重推 | 先回200，重活丢队列 |
| 重试耗尽 | 服务器宕机超过窗口 | 消息永久丢失 | 监控告警，别靠人工发现 |
| 队列积压假象 | 回了200但后台程序挂了 | 看着正常实际没处理 | 监控队列深度，不只盯回包 |
重推还会带来重复消息，所以处理逻辑必须按消息ID去重，同一条消息可能被推好几次。这些接管细节，跟WABA归属是一套事：谁接管，谁就得保证管道不断。
四、断点三：签名校验把真消息也挡在门外
为了防伪造，Meta发的每条推送都带签名头，你要用应用密钥对原始报文算一遍校验值来比对。这里有两个经典错误：
- 先解析再校验：签名必须对Meta发来的原始字节算。如果你先做了解码、格式化，再拿处理后的内容去算，永远对不上——真消息被你自己当成假消息拒了。
- 密钥对不上：换了应用没换密钥，或者密钥填了别的应用的。
还有一个提醒：排查的时候千万别图省事把签名校验关掉。校验开着挡了真消息，最多是配置问题；关了以后，任何知道你地址的人都能给你的系统塞假消息，那是安全事故。
五、断点四：多个号共用一个webhook，路由靠payload里那串号码ID
蓝标号是按进粉量配的，三五个号很常见（怎么配看这篇配置表）。好消息是：多号不用给每个号单独配webhook——地址配置一次，同一批WABA订阅后，旗下所有号的消息都推到同一个地址。
那系统怎么知道哪条消息是哪个号的？每条推送里都带着来源号码的标识（phone_number_id和显示号码两个字段），你的程序按这个字段分发：A号的进粉给客服一组，B号的给二组，或者直接进自动回复流程。
| 做法 | 适用 | 要点 |
|---|---|---|
| 单地址统一收，按号码ID分发 | 号都在同一主体下 | 分发逻辑里给每个号码ID配好归属 |
| 每个WABA各配一套 | 多主体/多服务商 | 各自独立配置，互不影响 |
| 混着来不管路由 | 号少的时候能凑合 | 号一多必然串客户，提前规划 |
最容易犯的错是：新号加进来，webhook不重配是对的，但它所在的WABA订阅做了没有，没人检查——回到断点一。新号上线的检查清单里应该有一项「发条测试消息确认管道通」。
管道修好只是及格线。消息进来之后接得住不住，是另一套事：第一句话怎么回看话术对照，资料页留不留得住人看六个细节，投了广告的还有72小时窗口排班要排，投放侧的钱别漏在承接断档上。
把你的webhook配置页截图和服务器日志发我，我帮你定位断在三层里的哪一层，别一条条试。
微信：AIbaogongtou ｜ WhatsApp：8615757917922
六、常见问题
问：怎么最快判断是不是webhook的问题？
看服务器access log里有没有Meta的POST。有，问题在你程序里；没有，问题在订阅或号的状态。这一步不花十分钟。
问：收不到消息和发不出消息，是一个问题吗？
不是两条线。收不到查webhook管道；发不出多数是号的状态、限额或者模板问题，之前五种发不出消息的状态拆过，别混着修。
问：服务器挂了几个小时，这期间客户的消息怎么办？
重试窗口内Meta会自动补推，几小时内一般能兜住；超过窗口就永久丢了，没有补发接口。所以接API之后监控告警不是可选项，是必选项。
问：多号是不是每加一个号都要重新过一遍验证握手？
不用。地址和应用层的配置一次就够，要补的是新号所在WABA的订阅，以及程序里把这个号码ID加进路由表。新号上线发条测试消息验一下最稳。
问：两个服务商同时接管一个号，消息两边都能收到吗？
各自订阅了就能各自收到推送，互不排斥。但两边都回客户就是灾难，承接分工这篇的对照表先定好谁来回，再谈接管。