
没有使用任何 插件,google下其他 issue提到 socketio 插件有类似的问题,但我们应用并没有使用这个插件
As you mentioned, there is no extra plugins used so it's no related to egg-socket.io or any other egg.js library. Maybe similar to this issue.
@johnnychq 一样的问题,本机正常,阿里云线上日志疯狂输出这个错误。你解决了吗?
cc @JacksonTian
@atian25
补充: 定位到错误是阿里云线上环境采集标准输出日志产生的。
详细描述:
2.在阿里云线上环境运行,关闭日志插件的标准输出,不会报错。但是阿里云日志服务也无法采集标准输出的日志
另外,同事使用Think.js,能正常采集标准输出,不会报这种错误。
关键是这个吧:在阿里云线上环境运行,打开日志插件的标准输出,疯狂报错,每秒4条。
你先关掉采集,然后检查下 stdout 上究竟是怎么回事。
@Benny233 还没解决,原始错误是在common-error.log中的

重新安装下全部依赖,不要锁版本,再看看。
这个看起来是某个请求挂了,不确定你是不是自行引入什么模块做了什么,请提供可复现方式。
好,我试一下
@johnnychq
是不是将配置文件中的cluster.listen.hostname配置了localhost或127.0.0.1,如果是的话,就不要配置hostname
回复晚了,抱歉
@atian25 我重新安装依赖试了一下,但还不行,过程如下
先说明一下,我们的生产环境情况,大概并发在20QPS,可以看 SLB流量如下:

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

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

结论 : 重新安装依赖后,错误依旧;重装解决不了问题。另外, 重新安装依赖排查的策略本身理论上也不是特别合理,因为不同用户间的package.json本来就不一样的
@atian25 解决问题的关键是复现。。。嗯,还没找到规律,尴尬。。。
@changchengqin cluster.listen.hostname这个是egg的配置嘛。。。我们没有配置这个属性哦~~
我提供一个其他场景下可复现的相同报错case:
场景是:阿里云SLB中以TCP方式进行健康检查,这个时候eggjs就会报上述错误(一模一样,100%复现,但因为跟正常业务场景没有关系,所以只能算作参考)
SLB配置界面:

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

图中绿色是开启TCP健康检查后的报错,关闭后很明显,报错消失
@johnnychq
我们正在遇到和你一样的问题,我们服务端是windows环境。
前几天,我们部署以后,访问所有的接口,浏览器监控一直pending,服务端日志也是显示这样的错误:
A client (undefined:NaN) error [ECONNRESET] occurred: read ECONNRESET
后来,我们把 egg-cluster(因为我们要自定义端口,必需通过配置egg-cluster来实现) 的一个配置项,listen.hostname 删除了,就正常了,之前listen.hostname是按照官方文档配置的127.0.0.1,如下图:
但是,今天,部分接口偶尔性的又出现了上述问题,前端浏览器监控一直pending,服务端日志也是显示这样的错误:
A client (undefined:NaN) error [ECONNRESET] occurred: read ECONNRESET

@atian25
@changchengqin 我们是通过egg-scripts启动的,cluster的配置都是默认的,不需要进行配置。
现在比较麻烦的是阿里云的日志不能添加白名单过滤掉这类错误;包括监控也不能添加白名单。
@johnnychq @changchengqin 原因找到了。 我们用的腾讯云,它做了负载均衡,会通过head方法轮询探测它方向代理的服务,然后它主动断开了。 你可以打印一下所有外部http请求,肯定能看到。 我们的解决办法就是直接将这个探测关闭。
。。。
@bymaxchen 是 head / 这个地址么?
谢谢 @bymaxchen 的提醒,问题出现的原因找到了,是SLB健康检查导致的 ,事情原委如下:
首页,问题发生的SLB TCP 4层SLB健康检查。(7层这里不作展开,自己尝试)
其次,4层SLB健康检查中,如果开启HTTP健康检查(其中要配置健康检查的路径),这时候健康检查的原理是发送HEAD请求到该健康检查URL!

如上图,我错误的误以为自己配置的/ok.htm是GET, 实际上是HEAD。
配置了HEAD ok.htm后的logger日志截图:

但是,即使正确处理了HEAD的/ok.htm,还是会报ECONNRESET的错误。
先抛下现象:
结论就是采用HTTP SLB的健康检查即可,TCP SLB的HTTP健康检查为什么不行已经提工单给阿里云。
其中,我猜测,TCP SLB健康检查假定每2s作一次健康检查的时候,会并发同时发10个请求,如果有成功的后面的请求会cancel掉,不知道这个猜测是否站得住脚。
另外,补充一个点,经过测试,这个报错跟是否HEAD请求没关系。原因:
router.get可以兼容同时处理router.head(实验过)也遇到了一样的问题,尝试按照这个方法修复
@johnnychq cool~ 有最新进展不?
@atian25 有进展,通过工单跟阿里云的人进行过较充分沟通,本质上的原因就是SLB健康检查导致的,跟head请求没关系(另外head问题自身比较复杂,无论slb还是egg框架都会有兼容处理,因此会干扰判断和分析)。
其中,SLB检查导致此问题出现的原因也比较简单,4层(tcp)SLB检查只会做简单TCP的三次握手,并主动断开连接,因此egg框架会报错。另外,4层(tcp)SLB检查中提供的HTTP健康检查是个伪的http,内部实现也会主动断开tcp连接,这个点找阿里云的人工单check过了。
所以,如果采用4层SLB,并开启健康检查就会必现上述错误。避免的方法有:
另外,4层SLB健康检查导致上述现象是主要的原因,以及可以被验证、复现、解释的。但互联网中好像存在大量无效tcp连接,因此还会时不时出现ECONNRESET报错。我们这边改成7层SLB检查后,规律性ECONNRESET基本消失,但还是偶有出现。
@johnnychq 是的,不过阿里云可以改成 7 层健康检查的。
Most helpful comment
@atian25 有进展,通过工单跟阿里云的人进行过较充分沟通,本质上的原因就是SLB健康检查导致的,跟head请求没关系(另外head问题自身比较复杂,无论slb还是egg框架都会有兼容处理,因此会干扰判断和分析)。
其中,SLB检查导致此问题出现的原因也比较简单,4层(tcp)SLB检查只会做简单TCP的三次握手,并主动断开连接,因此egg框架会报错。另外,4层(tcp)SLB检查中提供的HTTP健康检查是个伪的http,内部实现也会主动断开tcp连接,这个点找阿里云的人工单check过了。
所以,如果采用4层SLB,并开启健康检查就会必现上述错误。避免的方法有:
另外,4层SLB健康检查导致上述现象是主要的原因,以及可以被验证、复现、解释的。但互联网中好像存在大量无效tcp连接,因此还会时不时出现ECONNRESET报错。我们这边改成7层SLB检查后,规律性ECONNRESET基本消失,但还是偶有出现。
2924 是彻底静默处理把? @popomore