当前位置：首页 > news >正文

N8N系列：新手教程，“出色外交官” Webhook节点，打通外部应用，让工作流不再 “闭门运行”

news 2025/10/18 11:46:20

我是龙须草，深耕软硬件技术开发与管理，产品架构师；

一个相信“工具为人服务”的践行者，链接有缘之人，共探新可能。

在 n8n 的核心节点 “三巨头” 里，最后登场的 Webhook 节点，堪称工作流的 “对外关键接口”。

很多新手刚接触时可能疑惑，一个触发节点为何能跻身核心？答案其实很简单：它背后对接的是 HTTP 协议 —— 这个近代最伟大的网络发明，几乎覆盖了所有网络场景，只要有网络、有网络服务，就离不开 HTTP 接口。

而 Webhook 节点，正是 n8n 与这些接口对话的 “出色外交官”，专门负责让工作流与外部应用联动起来。

今天，我们就来拆解这个节点，搞懂它如何让工作流从 “独自运行” 变成 “主动响应外部事件”。

在 n8n 中，Webhook 节点是一个非常重要的组件，它属于 Trigger Node（触发节点），主要用于监听外部 HTTP 请求，它可以在事件发生时从应用和服务接收数据，从而触发工作流。

Webhook节点还支持返回工作流结束时生成的数据。这对于接收处理数据并返回结果 (如API端点) 非常有用。

一、核心特点

提供测试和生产两个URL：这个节点提供用于测试和生产的两个独立的URL，分别用于开发调试和生产部署。
提供唯一URL：Webhook 节点会自动生成唯一的URL，当其他服务或应用程序向该 URL 发送请求时，就会触发 n8n 工作流，并且接收请求中的数据。
实现实时自动化：它是实现实时自动化和应用间双向集成的关键。例如，当用户在 GitHub 上提交代码、在 web 应用程序发起 HTTP 请求时，可立即触发 n8n 工作流，进行后续的数据处理或操作。

二、使用场景

接收表单提交：可以与各种表单工具结合，当用户提交表单数据时，通过 Webhook 节点将数据发送到 n8n 工作流中，进行数据存储、分析或进一步的处理。
第三方回调：在与其他第三方服务集成时，若该服务支持 HTTP 接口，就可以使用 n8n 的 Webhook 节点来接收数据，实现不同系统之间的数据交互和流程自动化。

比如，支付平台在用户完成支付后，通过 Webhook 通知 n8n 工作流，以便进行订单状态更新、发货等后续操作。

总之一句话：凡是有 HTTP 接口都可以直接通过 Webhook 实现与 n8n 工作流进行数据交互。

三、如何找到Webhook节点

我们先来看下这个节点，怎么找到这个节点：

1、在工作流里面点击工作末端的节点的“+”，或者右上角的“+”

点击下图的Core：

可以看到N8N系统作为核心节点的也只有三个：

这三个都很重要，侧重点不同，我们今天只聊：webhook

2、直接在搜索框搜索

也可以找到这个节点。

四、Webhook节点参数

1、Webhook请求 URLs

Webhook节点对外的请求地址URL，这里有两个，一个用于测试，一个用于生产环境。

如果是调试开发，就使用测试的URL，这个需要点击触发才能生效，有两种方式：

可以点击节点上面的：三角符号，也可以点击下面的执行按钮：Execute workflow；

这两种方式稍有区别：一个是触发后只执行Wenhook节点，一个是触发后执行整个工作流；

而生产环境，只要打开了：Active，生产的URL就会一直有效。

2、HTTP请求方式 Method

支持标准的HTTP请求方法。

3、请求路径 Path

默认生成的请求路径是随机且唯一的，可以避免与其他URL冲突。

也可以自己手动指定URL路径：

更改后会影响测试和生产两个URL。

4、身份验证方式 Authentication

支持四种身份验证方法：

4.1 基本身份验证

基本身份验证，需要你预先将用户名和密码录入到n8n的凭证Credential，只有这个用户才可以登录。

关于凭证Credential的相关知识，可先看配套教程：

N8N系列：入门级，凭证（Credential）全解析：从概念到类型，新手也能轻松配置

4.2 请求头身份验证

这里同样需要选择或者新建一个请求头的凭证：

这里使用的是标准的HTTP请求头的格式，常用的如下：

WWW-Authenticate：用于访问资源的身份验证方法。

Authorization：用于向服务器验证用户代理的凭据。

Proxy-Authenticate：用于访问代理服务器后面的资源的身份验证方法。

Proxy-Authorization：用于代理服务器对用户代理进行身份验证的凭据。

4.3 JWT身份验证

这是一种使用JSON Web令牌 (JWT) 对数据进行数字签名的身份验证方法：

这里同样需要选择或者新建一个JWT凭证

4.4 无身份验证

5、应答 Respond

Immediately: 执行Webhook节点时，就立刻返回响应代码和消息。
When Last Nodes Finishes: 工作流执行完毕后，返回最后一个节点的响应代码和数据。
Using ‘Respond to Webhook’ Node: 按照响应Webhook节点的数据返回。
Streaming: 允许在工作流过程中实时将数据流回用户。

需要工作流中具有流支持的节点 (例如，大模型节点，就是返回的数据不是一次返回，分多次实时返回的数据)。

重点看一下When Last Nodes Finishes:

这里有四个选择：

5.1 All Entries

作用：返回 “上一个节点的所有数据条目”。
返回格式：始终是数组（即使只有一条数据，也会被包裹在数组里）。
典型场景：当需要把工作流中 “所有处理结果” 都返回给请求方时用。比如，批量处理了 10 条数据，想让请求方拿到完整的 10 条结果列表。

5.2 First Entry JSON

作用：返回 “上一个节点第一条数据的 JSON 格式内容”。
返回格式：始终是JSON 对象（直接返回单条数据，不包装成数组）。
典型场景：只需要返回 “第一条处理结果” 时用。比如，表单提交后，只需要返回 “是否提交成功” 的第一条确认信息。

5.3 First Entry Binary

作用：返回 “上一个节点第一条数据的二进制文件内容”。
返回格式：始终是二进制文件（比如图片、Excel、PDF 等文件的原始二进制流）。
典型场景：需要给请求方返回 “文件类数据” 时用。比如，用户上传图片后，Webhook 直接返回这张图片的二进制内容，让请求方可以直接下载或展示。

5.4 No Response Body

作用：不返回任何响应体（只有 HTTP 状态码，没有具体数据内容）。
返回格式：无内容（请求方收到的响应只有状态码，比如 200 OK，但没有 body 部分）。
典型场景：只需要 “告诉请求方‘我收到请求了’，但不需要返回具体数据” 时用。比如，接收日志上报，只需要确认收到，不需要给上报方反馈额外信息。

6、选项 Option

选项的内容是这个节点的高级应用，因为 Webhook 是暴露给网络的，尤其是公网的IP，对于安全性要求更高，所以对于需要产品化的工作流，下面的部分需要重点关注。

Add option 可以查看更多配置选项。

6.1 Allowed Origins (CORS)：跨域访问许可

作用：控制哪些外部网站 / 服务能向这个 Webhook 发送请求（解决浏览器 “跨域限制” 问题）。
配置说明：
- 输入 URL 列表（用逗号分隔），比如 https://example.com,https://test.com，只允许这两个域名请求。
- 默认是 *，表示所有域名都能请求（适合测试或不敏感的场景，生产环境建议指定具体域名，更安全）。
典型场景：如果你的 Webhook 要接收来自前端网页（比如自己的官网表单）的请求，就需要在这里配置网页的域名，否则 Webhook 会拦截请求。

6.2 Field Name for Binary Data：二进制数据字段名

作用：当外部请求发送二进制数据（比如图片、文件）时，n8n 会把这些数据存到这个字段里，方便后续节点调用。
配置说明：默认是 .（点），表示二进制数据直接存到当前数据项的根目录；也可以自定义字段名，比如 uploadFile，数据就会存到 item.json.uploadFile 里。
典型场景：接收用户上传的图片、Excel 文件，后续用 “文件节点” 保存或解析时，需要通过这个字段找到二进制数据。

6.3 Ignore Bots：忽略机器人请求

作用：过滤掉搜索引擎爬虫（比如百度、谷歌爬虫）、链接预览工具（比如微信 / QQ 预览链接时的请求）发送的无效请求，避免工作流被误触发。
配置说明：勾选即启用，不勾选则会接收所有请求（包括机器人请求）。
典型场景：如果 Webhook URL 被放在公开网页上（比如官网表单），建议勾选，防止爬虫频繁触发工作流，浪费资源。

6.4 IP (s) Whitelist：IP 白名单

作用：只允许指定 IP 地址的设备向 Webhook 发送请求，相当于给 Webhook 加了 “IP 门锁”。
配置说明：
- 输入 IP 列表（用逗号分隔），比如 192.168.1.1,203.0.113.5，只有这些 IP 能触发 Webhook。
- 留空则允许所有 IP 请求（生产环境建议配置，比如只允许合作第三方的服务器 IP）。
典型场景：对接企业内部系统或固定合作方（比如只接收来自支付宝服务器的支付回调 IP），确保请求来源绝对可信。

6.5 No Response Body：不返回响应体

作用：控制 Webhook 触发后，n8n 给请求方返回的内容是否包含 “响应体”（即具体数据）。
配置说明：勾选后，n8n 只返回 HTTP 状态码（比如 200 表示成功），不返回任何数据；不勾选则会返回默认响应体（比如工作流的初始数据）。
典型场景：如果请求方（比如第三方服务）只需要 “确认收到请求”，不需要额外数据，勾选后能减少数据传输，提高响应速度。

6.6 Raw Body：接收原始数据

作用：让 Webhook 直接接收请求的 “原始数据格式”，不自动解析成 n8n 常规的 JSON 格式。
配置说明：勾选后，n8n 会把请求体原样存到 $input.item.json.rawBody 里（比如 XML 文本、纯文本）；不勾选则会自动尝试解析成 JSON（解析失败会报错）。
典型场景：接收非 JSON 格式的数据（比如微信公众号的 XML 消息、传统系统的纯文本日志），避免自动解析导致数据丢失。

6.7 Response Code：响应状态码

作用：自定义 Webhook 给请求方返回的 HTTP 状态码（用来告诉请求方 “这次请求的结果”）。
配置说明：默认是 200（表示 “请求成功接收”），也可以选 201（创建成功）、400（请求错误）等，或手动输入状态码。
典型场景：需要给请求方明确反馈时，比如 “请求数据格式错误” 时返回 400，让请求方知道需要修正数据后重新发送。

6.8 Response Data：自定义响应数据

作用：让 Webhook 给请求方返回 “自定义内容”（比如工作流的处理结果、特定提示信息）。
配置说明：输入要返回的数据（支持文本、JSON 格式），比如 {"status":"success","message":"已接收数据"}，请求方会收到这段自定义内容。
典型场景：给前端网页返回 “表单提交成功” 的提示，或给第三方系统返回 “数据已同步” 的确认信息。

6.9 Response Headers：自定义响应头

作用：在 Webhook 的响应中添加额外的 “响应头”（即 HTTP 协议的元数据，用于控制请求方的后续处理）。
配置说明：
- 按 “键值对” 添加，比如键填 Content-Type、值填 application/json（指定响应数据格式为 JSON）；键填 Cache-Control、值填 no-cache（禁止请求方缓存响应）。
- 可参考 MDN 文档了解常用响应头的含义。
典型场景：需要控制请求方的行为（比如指定响应数据的编码格式、设置跨域相关的额外头信息），确保请求方正确处理响应。