2024-02-20T08:15:16.431017+00:00 [error] supervisor: ‘esockd_connection_sup - <0.1888.0>’, errorContext: connection_shutdown, reason: {ssl_error,{tls_alert,{unexpected_message,“TLS server: In state hello at tls_record.erl:558 generated SERVER ALERT: Fatal - Unexpected Message\n {unsupported_record_type,16}”}}}, offender: [{pid,<0.1517.200>},{name,connection},{mfargs,{emqx_connection,start_link,[[{deflate_options,},{max_conn_rate,500},{active_n,100},{zone,external},{proxy_address_header,<<>>},{proxy_port_header,<<>>},{supported_subprotocols,}]]}}]
这个问题具体是啥错误,猜测是ssl证书问题,但不是很确定,请大佬帮忙看看
这个错误一直在无限刷控制台错误
我的版本是4.4.2.同步时emqx是部署在k8s集群内部通过nodeport再通过slb向外提供服务
这是我的slb转发
slb:31884(tcp)—>nodeport:31884(tcp)—>emqx内部:8883(tls)
slb:31883(tcp)—>nodeport:31883(tcp)—>emqx内部:1883(tcp)
slb:31889(https)—>nodeport:31889(http)—>emqx内部:8083(wss)
看这个错误是说 SSL 握手没有成功,应该是因为发送了非 SSL 握手的报文到 emqx 的 SSL 端口(8883)。
你可以使用 tcpdump 抓个包看看。
我在测试环境已经复现出这个问题了,确实是非 SSL 握手的报文到 emqx 的 SSL 端口,但现在有一个问题,我这边生产环境的日志一直在刷,我能用啥方式定位出到底是哪个clientid在一直发吗?
那的确是没有办法,你如果能抓到那个报文就好了。
报文里能看到是哪个clientid连过来的?
谢谢大佬,最终找到了罪魁祸首,是我们一个同事的pc端配置写错了,把mqtt的数据发到了mqtts上