Docker环境下NestJS接收请求挂起，容器无法管控求助

• 僵尸进程积累引发容器阻塞：<defunct>状态的进程就是僵尸进程，这类进程是子进程退出后，父进程未调用wait()/waitpid()等系统调用回收其资源导致的。如果你的NestJS应用手动通过child_process模块创建了子进程，或者依赖的第三方库隐式生成了子进程，而父进程没有正确处理子进程的退出信号，僵尸进程会不断积累。当容器内进程表被占满时，应用会彻底挂起，Docker发送的停止信号也无法被主进程响应，最终导致容器无法正常停止或移除。

• WSL2与Docker Desktop的信号传递/资源限制问题：在WSL2后端的Docker环境中，Windows与Linux的信号处理机制存在兼容性差异，Docker发送的SIGTERM/SIGINT信号可能无法正确传递到NestJS主进程，导致主进程无法优雅退出，子进程沦为僵尸。另外，WSL2的内存、进程数等资源阈值触发时，可能会强制终止部分进程，但未清理关联子进程，也会产生僵尸进程。

• NestJS应用的异步资源泄漏或事件循环阻塞：如果应用存在未正确释放的异步资源，比如未关闭的MySQL连接池、Redis订阅客户端、长连接（WebSocket、MQTT），或者定时任务存在死循环、阻塞逻辑，会导致主进程的事件循环被阻塞，无法处理子进程的退出事件，进而产生僵尸进程。当事件循环完全阻塞后，应用会无响应，调试日志也无法输出（日志多为异步写入）。

• Docker容器的PID 1进程管理缺陷：如果Docker镜像的启动命令没有让NestJS主进程以PID 1运行（比如用npm run start启动，实际PID 1是shell进程），PID 1进程不会将终止信号转发给子进程的Node应用，容器停止时Node进程收不到信号，变成僵尸。此外，PID 1进程若未实现子进程回收逻辑，也会导致僵尸进程持续积累。

• 第三方依赖的底层进程管理Bug：部分NestJS第三方依赖（如ORM框架、Redis客户端、任务队列库）可能存在底层Bug，比如创建子进程后未处理退出事件，或者异常场景下未清理子进程资源，长期运行后引发僵尸进程，最终导致应用挂起。

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