Form Trigger execution succeeds but editor remains stuck on “Waiting for you to submit the form”

快速结论：在自托管 n8n（Docker）中用 Form Trigger 测试工作流时，表单能正常提交、执行也成功，但编辑器一直停在 “Waiting for you to submit the form”，通常是编辑器的实时推送（/rest/push）没有把 testWebhookReceived / 执行事件送到浏览器。优先排查推送链路（WebSocket/推送后端、host 是否一致、浏览器端 WS 帧是否真的到达），而不是工作流逻辑。

适用环境：Issue 已确认：n8n 2.46.7 与 2.47.5；Docker 自托管；Windows 11 Pro；Node.js v26.13.0；SQLite；执行模式 regular（main）；单实例；浏览器 Edge / Chrome。Python、CUDA、PyTorch、GPU 均不涉及。

最快修复方案：暂无确认的一步修复方案。Issue 中的报告者先后尝试了统一 localhost 与表单/编辑器 host、显式设置 WEBHOOK_URL、N8N_EDITOR_BASE_URL、N8N_PUSH_BACKEND=websocket，问题仍在，最终由仓库侧跟进（标签 status:in-linear）。可优先尝试的隔离手段：刷新编辑器页面恢复可用状态，同时按下文在 DevTools 的 /rest/push 上确认是否收到 testWebhookReceived 帧。

注意事项：刷新页面只是绕开卡住的等待状态，并非修复；Issue 中编辑器与后端日志不一致（后端记录推送成功、浏览器 WebSocket 消息为空）的根因未在讨论链中给出确认结论。上述 host / 反代 / 推送后端配置属于社区建议，报告者实测均未解决，不能视为已验证方案。

问题场景

用户运行自托管 n8n（Docker on Windows 11 Pro），创建一个以 Form Trigger 为起点的测试工作流（Form Trigger 连接 Edit Fields 节点），点击 Execute Workflow，打开 Form Trigger 的 Test URL 并提交表单。表单提交成功、执行成功，但编辑器不更新，仍停在 “Waiting for you to submit the form”，刷新页面后才恢复。

报错原文

Form Trigger execution succeeds but editor remains stuck on "Waiting for you to submit the form"

原因分析

根据讨论，问题不在表单提交或执行本身，而可能出在编辑器的实时推送链路：

编辑器的等待态由 testWebhookReceived 处理器清除（n8n 2.47.5 中，该处理器在消息 workflowId 与当前编辑器文档匹配时才生效）。若消息未到达或未匹配，等待态不会消失。
报告者核查后确认：保存的执行 #33 的 mode 为 manual，workflow ID 与 executions 请求中的一致，但在 /rest/push 的 WebSocket Messages 中看不到 testWebhookReceived 消息。
报告者开启 debug 日志后看到：n8n 已将 testWebhookReceived 推送到正确的活动 pushRef，随后的 executionStarted、节点执行事件、executionFinished 也均记录为推送成功；WebSocket 返回 101 Switching Protocols，但 DevTools Messages 面板为空，Edge 与 Chrome、localhost 与 ngrok 表现一致。
因此可能原因是后端事件已发出、但帧未能实际送达浏览器/未被编辑器处理的推送通道问题，而非单纯的 origin 或 session-ID 不匹配（报告者已排除）。具体根因在 Issue 中未给出确认结论。

环境排查

确认 n8n 版本（Issue 中复现于 2.46.7 与 2.47.5），以及是否为 Docker 自托管、单实例。
确认执行模式为 regular（main），数据库为 SQLite，Node.js 版本正常报告于 debug info。
确认编辑器访问地址（如 localhost:5678 与 127.0.0.1:5678）与表单 Test URL / WEBHOOK_URL 的 host 完全一致。
确认 N8N_HOST、N8N_PORT、N8N_PROTOCOL、WEBHOOK_URL、N8N_EDITOR_BASE_URL、N8N_PUSH_BACKEND 是否按需显式设置。
若位于 Nginx/Caddy/Traefik 等反向代理之后，检查是否转发 WebSocket 升级头，以及是否关闭代理缓冲。
在 DevTools → Network → 选中 /rest/push 连接，查看状态是否为 101 Switching Protocols，并检查 WS Messages 是否收到 testWebhookReceived 以及后续执行事件。
在 Edge 与 Chrome 中分别复测，并分别用 localhost 与 ngrok 地址复测，判断是否与浏览器或入口地址相关。

解决步骤

先复现一次：打开工作流，点击 Execute Workflow，打开 Form Trigger 的 Test URL 提交表单，确认执行成功但编辑器卡在等待态。
保持 DevTools → Network 打开，选中编辑器的 /rest/push 连接，记录其状态码以及是否收到 testWebhookReceived 帧；如收到，记录 workflowId 与 executionId。
查看已保存执行的 mode（manual 或 webhook）与 workflow ID，和推送帧中的字段对照（可优先尝试的定位手段）。
统一 host：确保编辑器页面 URL 与 WEBHOOK_URL / 表单 Test URL 使用完全相同的主机名，可优先尝试在 docker-compose 中显式设置 N8N_HOST、N8N_PORT、N8N_PROTOCOL、WEBHOOK_URL、N8N_EDITOR_BASE_URL、N8N_PUSH_BACKEND=websocket。
若使用反向代理，可优先尝试确认升级头已转发、proxy_buffering off; 已设置，避免 /rest/push 阻塞。
若以上均无效且 WebSocket 消息仍为空，保留 debug 日志中关于 pushRef 与各执行事件的推送记录，以及 /rest/push 帧截图，提交到 Issue / 内部跟进单，用于区分是事件发送端还是浏览器接收端的问题。
临时恢复编辑：刷新编辑器页面，等待态会清除，可重新测试工作流。

验证方法

重新提交表单后，编辑器应自动结束等待态，并显示已完成的节点及其输出；同时在 DevTools 的 /rest/push WebSocket Messages 中应能看到 testWebhookReceived 及后续执行事件，且其中的 workflowId 与当前工作流一致。若执行成功但 DevTools 消息仍为空、编辑器继续卡住，说明推送链路问题尚未解决。