Debian服务器PM2接收请求但未处理：Node.js应用高负载异常排查求助

1. 核查PM2与Node.js进程的通信状态 #

• 执行 pm2 show <app-name>，确认worker进程的status为online，且listening ports与Nginx转发目标端口完全匹配。
• 临时调高PM2日志级别到debug模式：pm2 set pm2:logLevel debug，重启应用pm2 restart <app-name>，查看是否有连接建立/断开的详细日志，定位PM2主动终止连接的触发原因。

2. 验证Nginx反向代理配置 #

• 查看Nginx错误日志（默认路径/var/log/nginx/error.log），搜索upstream prematurely closed connection类错误——这类日志直接说明Nginx与PM2的连接在响应完成前被中断。
• 调整Nginx超时配置，适配高负载场景：

  proxy_connect_timeout 60s;
  proxy_send_timeout 60s;
  proxy_read_timeout 60s;
  

• 确保启用HTTP/1.1与长连接：

  proxy_http_version 1.1;
  proxy_set_header Connection "";
  

3. 排查Node.js应用的连接处理能力 #

• 检查Node.js的maxConnections设置（http模块默认值为511），高负载下可能触达上限导致请求无法转发，可在代码中调整：

  const server = http.createServer(app);
  server.maxConnections = 1024; // 根据实际负载调整
  

• 用pm2 monit实时监控worker进程的事件循环延迟，或添加--trace-event-loop参数启动应用，排查是否存在事件循环阻塞导致的请求处理停滞。
• 检查应用内部日志，确认是否有限流中间件在高负载下直接拒绝请求但未记录日志，或存在未捕获异常导致进程静默失效。

4. 系统层面连接限制检查 #

• 执行ulimit -n查看进程文件描述符限制，若默认1024无法满足高负载需求，修改/etc/security/limits.conf：

  * soft nofile 65535
  * hard nofile 65535
  

  重启系统或重新登录后生效。
• 执行ss -s查看TCP连接状态，若TIME_WAIT连接过多占用端口，调整TCP参数：

  echo "net.ipv4.tcp_tw_reuse = 1" >> /etc/sysctl.conf
  echo "net.ipv4.tcp_tw_recycle = 1" >> /etc/sysctl.conf
  sysctl -p
  

5. PM2集群模式配置验证 #

• 执行pm2 list确认所有worker进程状态稳定，无频繁重启情况；若使用instances: max，检查是否与CPU核心数匹配。
• 调整PM2的kill_timeout配置（默认1600ms），避免应用未完成请求处理就被强制终止：

  module.exports = {
    apps: [{
      name: 'your-app',
      script: 'app.js',
      instances: 8,
      kill_timeout: 5000 // 延长至5秒
    }]
  };
  

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