Gitlab CI个人VPS运行NestJS项目Jest测试偶发write EPIPE错误如何解决

核心错误本质 #

write EPIPE属于系统级网络错误，触发原因是本地进程向已经被对端提前关闭的TCP连接写入数据，结合你描述的偶发、无规律的特征，以下是从高到低的概率排查修复方案：

最高概率诱因：Supertest 请求构造顺序错误 #

你提供的测试代码存在调用顺序问题：supertest中.expect属于断言触发逻辑，必须放在所有请求构造操作（.attach、.set、.send等）之后。你当前将.expect(200)放在.attach前面，会导致请求已经开始发送后仍在组装文件附件，异步逻辑时序错乱时就会偶发连接提前断开。

修正后的测试代码如下：

it('should be able to upload image', () => {
    return request(myHost)
      .post('/upload-image')
      .attach('image', './testimage.jpg') // 先完成所有请求参数构造
      .expect(200) // 最后执行断言
      .then((res): any => {
        expect(res.body).toEqual({});
      });
  });

其他常见诱因与修复方案 #

• Jest 并行执行冲突：Jest 默认启用多进程并行跑测试用例，可能出现端口抢占、服务实例未完全启动就执行测试的情况。测试命令添加--runInBand参数强制单进程串行执行，同时检查beforeAll钩子中服务启动逻辑，必须等待服务listen回调完成后再resolve，避免未就绪就接收请求。
• 服务端中间件冲突：检查NestJS全局中间件配置，若同时启用了全局body-parser和multer文件上传中间件，会导致multipart请求被重复解析，偶发被中间件提前拒绝、关闭连接。需要配置body-parser跳过multipart/form-data类型的请求，交由multer单独处理。
• Node 版本固有bug：Node 14.16.0 存在偶发的HTTP socket 提前销毁的已知问题，可升级到Node 14.x的最新LTS版本（14.21.3），小版本升级无兼容性风险。
• Gitlab CI Runner 资源限制：检查CI Runner的CPU、内存配置，若资源不足会偶发杀掉NestJS服务进程，导致连接被强制断开，可调整Runner资源配额，或测试阶段增加服务启动后的等待时间。
• 连接池坏连接复用：若测试中复用了同一个supertest agent实例，之前出错的连接会留在连接池中被复用，导致偶发错误。每次测试用例执行前新建独立的agent实例即可。

内容的提问来源于stack exchange，提问作者felixbmmm