egg: error [ECONNRESET] occurred: read ECONNRESET

  • node: 8.10:
  • egg: 2.6:
  • system: centos 7:

阿里云生产环境日志报警截图

image

没有使用任何 插件,google下其他 issue提到 socketio 插件有类似的问题,但我们应用并没有使用这个插件

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Comments: 26 (20 by maintainers)

Most upvoted comments

@atian25 有进展,通过工单跟阿里云的人进行过较充分沟通,本质上的原因就是SLB健康检查导致的,跟head请求没关系(另外head问题自身比较复杂,无论slb还是egg框架都会有兼容处理,因此会干扰判断和分析)。

其中,SLB检查导致此问题出现的原因也比较简单,4层(tcp)SLB检查只会做简单TCP的三次握手,并主动断开连接,因此egg框架会报错。另外,4层(tcp)SLB检查中提供的HTTP健康检查是个伪的http,内部实现也会主动断开tcp连接,这个点找阿里云的人工单check过了。

所以,如果采用4层SLB,并开启健康检查就会必现上述错误。避免的方法有:

  1. 要么关闭健康检查
  2. 要么采用7层SLB,7层SLB健康检查不会遇到上述问题

另外,4层SLB健康检查导致上述现象是主要的原因,以及可以被验证、复现、解释的。但互联网中好像存在大量无效tcp连接,因此还会时不时出现ECONNRESET报错。我们这边改成7层SLB检查后,规律性ECONNRESET基本消失,但还是偶有出现。

#2924 是彻底静默处理把? @popomore

我提供一个其他场景下可复现的相同报错case:

场景是:阿里云SLB中以TCP方式进行健康检查,这个时候eggjs就会报上述错误(一模一样,100%复现,但因为跟正常业务场景没有关系,所以只能算作参考)

截图如下:

SLB配置界面:

image

(PS: 我们生产环境用的是 http健康检查,之前配置测试健康检查的时候留意到的一个现象)

日志报错规律:

image

图中绿色是开启TCP健康检查后的报错,关闭后很明显,报错消失

先抛下现象:

  • TCP SLB的HTTP健康检查会出现此问题(我Issue中最初的问题)
  • TCP SLB的TCP健康健康也会出现类似问题,但报错不一样
  • HTTP SLB的HTTP健康检查不会出现此类问题

结论就是采用HTTP SLB的健康检查即可,TCP SLB的HTTP健康检查为什么不行已经提工单给阿里云。

其中,我猜测,TCP SLB健康检查假定每2s作一次健康检查的时候,会并发同时发10个请求,如果有成功的后面的请求会cancel掉,不知道这个猜测是否站得住脚。

@johnnychq @changchengqin 原因找到了。 我们用的腾讯云,它做了负载均衡,会通过head方法轮询探测它方向代理的服务,然后它主动断开了。 你可以打印一下所有外部http请求,肯定能看到。 我们的解决办法就是直接将这个探测关闭。

@johnnychq 我们正在遇到和你一样的问题,我们服务端是windows环境。

前几天,我们部署以后,访问所有的接口,浏览器监控一直pending,服务端日志也是显示这样的错误: A client (undefined:NaN) error [ECONNRESET] occurred: read ECONNRESET

后来,我们把 egg-cluster(因为我们要自定义端口,必需通过配置egg-cluster来实现) 的一个配置项,listen.hostname 删除了,就正常了,之前listen.hostname是按照官方文档配置的127.0.0.1,如下图:image

但是,今天,部分接口偶尔性的又出现了上述问题,前端浏览器监控一直pending,服务端日志也是显示这样的错误: A client (undefined:NaN) error [ECONNRESET] occurred: read ECONNRESET image

@atian25

回复晚了,抱歉 @atian25 我重新安装依赖试了一下,但还不行,过程如下

先说明一下,我们的生产环境情况,大概并发在20QPS,可以看 SLB流量如下:

image

在上述流量下面,重新安装依赖之前的报错规律(15分钟):

image

重新安装依赖后的报错规律(15分钟):

image

结论 : 重新安装依赖后,错误依旧;重装解决不了问题。另外, 重新安装依赖排查的策略本身理论上也不是特别合理,因为不同用户间的package.json本来就不一样的

@atian25 解决问题的关键是复现。。。嗯,还没找到规律,尴尬。。。