听起来这个问题确实挺棘手的——明明单独测试都正常，一放进n8n工作流连续调用就掉链子，太闹心了！我之前也遇到过类似的n8n HTTP节点连续调用的奇怪问题，给你几个排查方向试试：

• 检查n8n HTTP节点的连接复用设置
  n8n在工作流执行时，可能会复用同一个HTTP客户端实例，而你的Steel浏览器服务可能没正确处理复用连接的情况（比如会话残留、资源没释放）。试试在HTTP节点的高级设置里，开启Disable SSL/TLS Session Reuse选项，或者在请求头里添加Connection: close强制每次调用后关闭连接，避免复用旧连接。

• 排查服务端的状态隔离问题
  虽然你的服务单独调用没问题，但工作流的两次调用可能因为n8n的执行上下文，导致服务端的Steel实例没有完全隔离。比如第一次调用后浏览器实例没销毁，第二次调用时复用了残留状态，引发了类似协议解析的错误（那个奇怪的报错看起来像是数据格式或解析层面的问题）。建议在你的NodeJS服务里，每次请求处理完成后强制销毁Steel实例，确保每次调用都是全新的运行环境。

• 查看n8n的详细执行日志
  当前的报错信息比较模糊，建议把n8n的日志级别调到debug（在n8n的设置面板里可以修改），看看第二次调用时的请求参数、响应头甚至传输过程中的数据有没有异常。有时候n8n在工作流执行时会自动添加一些默认头信息或者修改请求体，可能和你的服务预期不匹配。

• 尝试封装成自定义节点
  如果原生HTTP节点的复用逻辑有问题，试试把你的HTTP请求逻辑写成n8n自定义节点。这样你可以完全控制请求的创建、发送和销毁流程，避免n8n内置HTTP客户端带来的未知问题。

另外，你也可以试试把两次HTTP调用放在工作流的不同分支，或者用「Execute Workflow」节点把第二次调用作为独立工作流执行，看看能不能绕过这个问题。

内容来源于stack exchange