碰到这个问题太闹心了！我之前在Windows上玩Puppeteer的时候也踩过几乎一模一样的坑，给你捋捋原因和解决方案：

问题根源：--single-process参数的Windows兼容性问题 #

Chrome的进程架构在Windows和Linux/macOS上有本质区别，--single-process这个参数是强制Chrome以单进程模式运行，但Windows系统下Chrome本身对单进程模式的支持非常差，甚至可以说完全不兼容。

当你加上这个参数后，Puppeteer没办法正常和Chrome的DevTools服务建立WebSocket连接，就会触发ECONNRESET（连接被重置）的错误——也就是你看到的那个WebSocket相关的报错。

快速解决方案 #

1. 直接移除--single-process参数

这是最直接有效的办法，你已经发现去掉它错误就消失了。保留其他有用的参数即可，比如：

const puppeteer = require('puppeteer');
let browser;
const puppeteer_options = {
  headless: true,
  ignoreHTTPSErrors: true,
  args: [
    '--no-sandbox',
    '--disable-setuid-sandbox',
    '--no-zygote',
    '--disable-dev-shm-usage',
    '--shm-size=4gb',
  ],
  defaultViewport: {width: 1920, height: 1080},
  protocolTimeout: 1000000,
}

try {
  browser = await puppeteer.launch(puppeteer_options);
  const page = await browser.newPage();
  console.log('浏览器启动成功！');
} catch (err) {
  console.error('启动失败：', err);
}

2. 改用更稳定的新无头模式（推荐）

如果你是想追求轻量的无头运行效果，Puppeteer v19+支持的headless: 'new'模式比旧的headless: true更稳定，而且不需要依赖--single-process参数，在Windows上兼容性拉满：

const puppeteer_options = {
  headless: 'new', // 替换成新无头模式
  ignoreHTTPSErrors: true,
  args: [
    '--no-sandbox',
    '--disable-setuid-sandbox',
    '--no-zygote',
    '--disable-dev-shm-usage',
    '--shm-size=4gb',
  ],
  defaultViewport: {width: 1920, height: 1080},
  protocolTimeout: 1000000,
}

3. 降级Node.js到LTS版本

Node.js 25是尝鲜版（非LTS），可能和Puppeteer的底层依赖存在兼容性小问题。如果上面的方法还不行，可以试试降级到Node.js 20（当前LTS版本），稳定版本的兼容性通常更有保障。

额外注意点 #

• Windows上Chrome的沙箱机制本来就和Linux不同，--no-sandbox参数在本地开发时可以保留，但生产环境尽量在支持沙箱的系统（比如Linux）上运行。
• 每次修改依赖或参数后，记得杀掉所有残留的Chrome/Chromium进程，避免旧进程干扰新的启动。
• 如果还是有奇怪的连接问题，可以尝试重新安装Puppeteer，确保下载的Chromium版本和Puppeteer版本完全匹配：

  npm uninstall puppeteer && npm install puppeteer