👁 69 次阅读

n8n 升级 2.17.4 后 Chat Trigger 公网 URL 为何返回 Connection rejected？

问题来源：https://github.com/n8n-io/n8n/issues/28891

现象描述

从 n8n 2.14.2（报告者判断 2.16.1 可能同样受影响）升级到 2.17.4 之后，一个原本正常运行的 workflow 停止工作。该 workflow 使用了 Chat Trigger、带审批按钮的 Chat 节点 sendAndWait，以及一条 timeout 分支。问题的关键点在于，故障与自定义前端无关：直接使用 Chat Trigger 生成的公网 Chat URL 即可复现，而编辑器的内嵌 chat 不会显示按钮，报告者指出这属于另一个尚未修复的问题（https://github.com/n8n-io/n8n/issues/27187）。打开公网 URL 后：

https://xxxxxxxx/webhook/3e79xxxxxxxxx/chat

执行会启动，但聊天最终返回：

Connection rejected

同一个 workflow 在升级前的 2.14.2（报告者认为 2.16.1 也如此）上工作正常。报告者期望的行为是 Chat 正常询问 “Do you prefer boat or plane travel?”，并允许用户用 Plane 或 Boat 按钮作答，或在未收到回答时走 Timeout 分支；实际行为是公网 Chat URL 本身失败并返回 Connection rejected。报告者表示无法给出最后一个节点的可靠成功输出，因为故障发生在聊天交互过程中，用户侧可观察到的结果就是 Connection rejected。

背景原因

这条 issue 目前处于 open 状态，标签为 status:in-linear，创建于 2026-04-22，最后更新 2026-06-02。全部讨论中有 1 条为机器人或无效留言，实质讨论共 24 条。官方尚未合入统一方案，但期间出现过版本相关的分歧。复现条件在讨论中被进一步简化。有用户反馈，仅用两个节点即可复现：

Chat Trigger 节点版本 1.4（Latest），开启 Make Chat Publicly Available
Chat 节点版本 1.3（Latest），使用 Send Message 操作

此时 Chat 节点在执行中一直处于 “Waiting” 状态，而公网 Chat URL 给出 Connection rejected。关于版本边界，讨论中给出的对照是：在 n8n V 2.16.2 上工作正常，在 n8n V 2.17.5 上仍然不工作。另有用户表示不确定自己原先使用的版本，但在当晚升级后，使用内部 chat trigger 节点的 workflow 直接不再执行，鼠标触发与编辑节点工作正常。还有用户反馈同类现象也出现在移动端应用中，因为他使用了与浏览器相同的连接方式，同样得到 Connection rejected。

排查或量化方法

讨论中出现的可行排查动作集中在版本回退/升级对照与连接路径两个维度。版本对照方面，社区反馈呈现明显分歧：

有用户更新到 2.18.4 后，公网 chat URL 恢复正常。该用户同时提到自己移除了前面的反向代理，改为直接使用完整域名和 n8n 端口，因此认为可能是新版本与不再使用 nginx 代理的组合效果。
报告者在 2.18.4 上复测，确认同一条 workflow 不再出现问题，包括 sendAndWait 交互。
但另一位用户报告在 2.18.4 上问题仍可复现。

这位仍可复现的用户给出了更具体的操作路径，可作为量化复现的对照步骤： 1. 创建 Chat 节点，选项选择 “Using Response Nodes” 2. 创建 agent，并为其配置 chat tool “Send And Wait For Response” 3. 发布该 flow 4. 打开 Chat 节点并复制公网 URI 5. 在浏览器中打开该 URI（必要时先登录） 6. 发送任意消息，结果得到 Connection rejected 该用户随后又反馈在 2.18.5 上问题依旧。连接路径方面，上述移除反向代理后恢复的反馈提示：公网访问链路（nginx 代理与直连端口）可能是变量之一，但报告者在保留原有部署方式的情况下仅升级版本即可恢复，说明版本因素也不能排除。

完整解决方案

官方目前尚未提交统一修复方案，issue 仍为 open，因此不存在可直接应用的补丁。可依据 issue 讨论整理的处置路径如下：

升级到 2.18.4 并复测。报告者与另一位用户均在该版本上确认公网 Chat Trigger URL 恢复正常，sendAndWait 交互可用。
若升级到 2.18.4 后仍复现，可参照仍复现用户给出的路径排查特定组合：Chat 节点使用 “Using Response Nodes” 选项、agent 上挂载 chat tool “Send And Wait For Response”。
检查公网访问链路。有用户通过移除前置反向代理、改为直接访问完整域名与 n8n 端口后恢复正常，并将该变化与版本升级并列作为可能原因。

需要注意，2.18.4 能否解决问题在讨论中存在明确分歧：报告者一方复测通过，另一位用户明确报告该版本下问题仍可复现。因此升级到 2.18.4 属于据 issue 讨论的社区结论，不能视为官方已确认的修复。讨论末尾，报告者再次询问其他参与者是否在新版本上复测，并说明自己在 2.18.4 和 2.22.5 上均工作正常；此前报告仍可复现的用户回复称，他已复测，现在工作正常，并强调有一条重要注意事项需要传递。至此，社区侧的反馈整体转向可用，但官方 issue 状态仍为 open。

版本与现象对照表

n8n 版本	报告的现象	来源
2.14.2	工作正常	报告者
2.16.1	报告者认为工作正常	报告者
2.16.2	工作正常	社区用户
2.17.4	公网 Chat URL 返回 `Connection rejected`	报告者
2.17.5	仍然不工作	社区用户
2.18.4	恢复正常（报告者与另一位用户复测通过）	报告者等
2.18.4	仍可复现（一位用户报告）	社区用户
2.18.5	仍可复现	社区用户
2.22.5	工作正常	报告者

常见错误排查

报错字符串为 Connection rejected，出现在公网 Chat URL 的聊天交互阶段，而非某个节点的最终输出。报告者明确无法提供最后一个节点的成功输出。
不要只把问题归因于自定义前端。报告者已强调与自定义前端无关，用 Chat Trigger 自带公网 URL 即可复现。
编辑器内嵌 chat 不显示按钮属于另一条独立问题（https://github.com/n8n-io/n8n/issues/27187），报告者建议使用公网 URL 来观察按钮行为，这条不应与 Connection rejected 混在一起排查。
最小复现可以只用两个节点：Chat Trigger 1.4（开启 Make Chat Publicly Available）与 Chat 节点 1.3（Send Message 操作）。此时 Chat 节点保持 “Waiting”，公网 URL 报 Connection rejected。
若使用 Chat 节点 “Using Response Nodes” 选项并搭配 agent 的 chat tool “Send And Wait For Response”，即使在其他用户已恢复的版本上，也有用户报告仍可复现，需按该组合单独验证。

实践建议

升级前先在可回退的环境里用公网 Chat URL 走通一次 sendAndWait 流程，不要只测编辑器内嵌 chat。
把反向代理层与 n8n 版本作为两个独立变量分开验证：有用户的恢复同时伴随移除反向代理，无法据此单独判断版本作用。
对移动端同样接入公网 Chat URL 的场景，需一并复测，已有用户在移动端应用上报告相同报错。
关注 issue #28891 的后续更新。当前状态为 open，status:in-linear 标签说明已进入 Linear 跟踪，但讨论末段以用户之间互相确认复测结果为主，官方未给出统一修复说明。

FAQ

Q：这个问题的官方修复版本是哪个？ A：官方没有给出统一修复版本，issue 仍为 open。社区在 2.18.4 上出现分歧：报告者复测通过，另一位用户报告仍可复现。据 issue 讨论，可先升级到 2.18.4 复测，但不能视为官方已确认修复。 Q：只在编辑器里聊天能复现吗？ A：编辑器的内嵌 chat 不会显示按钮，报告者指出这是另一条独立问题（https://github.com/n8n-io/n8n/issues/27187）。要复现 Connection rejected，应使用 Chat Trigger 生成的公网 URL。 Q：最少需要几个节点就能复现？ A：有用户用 Chat Trigger 1.4（Latest，开启 Make Chat Publicly Available）加 Chat 节点 1.3（Latest，Send Message 操作）两个节点复现成功，Chat 节点保持 “Waiting”，公网 URL 报 Connection rejected。 Q：反向代理会影响这个问题吗？ A：有一位恢复正常的用户同时移除了前置反向代理、改为直连完整域名和 n8n 端口，因此认为可能是新版本与不再使用 nginx 代理的组合效果。报告者则在保留原有部署的情况下仅升级版本即恢复，两种因素都存在，尚无定论。 Q：升级到 2.18.5 或更高能解决吗？ A：有用户报告 2.18.5 仍可复现；报告者称 2.22.5 上工作正常。据 issue 讨论，版本区间内的表现不一致，需要按自身 workflow 结构（是否使用 “Using Response Nodes” 与 “Send And Wait For Response”）实际验证。