微信公众号接收到的消息是通过的 HTTP 协议传递的，利用传递的规则，可以允许有多家代理存在。

对于粉丝发来的一条消息，代理 A 看一个自己能否处理，如果处理不了，那么消息转(POST)给代理 B，代理 B 同样处理不了的话，转给代理 C。最后代理 C 完整解决了问题，再回复给代理 B，代理 B 再回复给代理 A，代理 A 再回复给微信服务器，微信服务器再回复给公众号粉丝。(这是在 Denis 开发的 Wordpress 微信机器人插件中得到的启示)

粉丝发来 hi，微信公众平台自然根据管理员设置的接收消息的 URL 把 hi 这条消息发送给代理 A，代理 A 自己不知道 hi 是什么意思，就问其他代理，最终代理 C 知道怎么回答，就顺着这条链回复回去，最终粉丝收到了 hi。

这个流程看上去，像个双向折返的接力赛，一棒一棒跑到终点，再一棒一棒跑回起点。折返接力看上去挺美好，好像解决了问题，但存在几个潜在的问题：

第一代理，也就是代理 A 的权力太大。作为公众号管理员最信任的代理，他掌管和调度着其他所有代理。(当然企业或品牌可以自己充当这个第一代理的角色，但现实是很少有人这么做)

如果某个环节出了问题，不太容易界定责任。需要多个代理间协调的事情比较多。

微信规定一条消息需要在 5 秒钟内完成回复。

微信服务器在五秒内收不到响应会断掉连接，并且重新发起请求，总共重试三次。

如果图中转来转去的这个流程，在任何一个环节稍有耽搁，或者传输过程不顺畅，都会导致消息处理超时，粉丝收不到回复消息。