开始不知道为什么EMQ连接不上，使用MQTTX死活连接不上，使用MQTTbox偶尔能连上。看DashBoard好像是连上了又断开。因为重连问题，导致出现很多TIME_WAIT。经过我的判断，确定是web_hook的问题。web_hook我设置了上下线通知，在我没启动WEB服务来接收hook的数据时，就会导致客户端连接不上。解决办法只能时启动WEB服务或者关闭web_hook插件。我认为这不太合理。如果我的WEB服务宕机了，或者忘记开启了，那么客户端会一直连接不上，且由于每个客户端会反复重连，导致大量的TIME_WAIT，很快就会出问题，连带着整个网络都会出问题。我觉得底层应该要以新建线程或者其他方式来POST这个上下线信息，而不是等待，就是不管web服务接收是否存在，都不应该干扰客户端的连接。
在你的使用场景里，可能webhook之类的第三方推送服务不是很重要，但是对于我们的绝大部分客户来说，丢数据是不可接受的，也就是说，推送到第三方服务的过程出现错误，我们认为是整体的服务异常。服务异常并不是指单单的接入服务失败，数据流异常也算在内。你说的不应该干扰客户端链接，反而是错误的，在整体的服务质量出问题时，客户端没有任何感知，这种做法不可接受，如果你想做到第三方服务数据流允许异常，应该由你的server把控，可以接收了消息有选择的做业务。
你好，并不是丢数据，我是说假设web服务宕机掉了，那影响可就大了。你看哈，我web_hook只不过是用来上下线处理的，其实有时对我的整体业务系统影响不大（假设它宕机了）。但是如果客户端连接等出问题，并且导致我的网络阻塞等，我可能要重启服务器之类的，重启后我的客户端要重新连接，很多逻辑业务要重新启动等，风险加大很多。我的web服务正不正常我可以用另外的监控服务来给我告警，而不能影响EMQ的连接等，很容易让人觉得是EMQ的问题（刚开始我找半天不知道为什么，后面重新下载了一个新的未配置web_hook的正常了，我很当然的会觉得是EMQ的问题）。你看这样会不会更合理一些，可以在配置里面增加一个设置项，是否阻塞连接的配置（名称可能不太合理，但大体是那么个意思）。还有就是MQTTX一直是连不上的，MQTTbox有时可以连上，搞不太懂这个是为什么。
如果你仅仅是想监控设备上下线消息，并且对这个监控的数据不敏感可丢失，推荐使用订阅系统消息来做，而不是通过webhook，参考文档。
webhook设计不会增加可选项，对于我们来说服务质量是整体的，你可以把EMQX视作一个代理/负载均衡/网管，后续的服务挂掉了，EMQX的状态不应该是业务正常的。
至于你说到的webhook服务可能重启/更新的情况，我们推荐的方式是人为干扰，如果你的更新/重启之前关闭webhook，更新之后打开。如果是非人为更新/重启，那么我们认为业务流程异常，会导致服务异常。
好吧
