无需登录 数据私有 本地保存

Webhook 接收模拟器 - 查看外发请求体

12
0
0
0
Webhook URL https://hooks.example.com/receive/
监听中 0 条请求
发送测试请求
接收到的请求
0

暂无请求，发送测试请求或开启自动模拟

点击左侧请求查看详情

常见问题 (FAQ)

Webhook 是一种轻量级的 HTTP 回调机制。当某个事件在源系统发生时，源系统会向预先配置的目标 URL 发送一个 HTTP 请求（通常是 POST），携带事件相关的数据。这允许系统之间实现实时、事件驱动的通信，无需轮询。常见应用包括：GitHub 通知 CI/CD 系统、支付网关通知订单状态、表单提交触发邮件等。

API 是"拉取"模式——客户端主动请求数据；Webhook 是"推送"模式——服务器在事件发生时主动发送数据。API 需要不断轮询来检查更新，而 Webhook 是实时的、事件驱动的。Webhook 通常更高效，减少了不必要的网络请求。

调试 Webhook 的常用方法：
1. 使用模拟器（如本工具）：在本地或测试环境接收请求，查看请求体和Headers。
2. 使用在线服务：如 webhook.site、Beeceptor、RequestBin 等，它们提供临时URL来捕获请求。
3. 使用 ngrok：将本地服务器暴露到公网，接收真实的 Webhook 请求。
4. 查看日志：在接收端记录所有请求的详细信息。
5. 验证签名：确保请求来自可信来源，防止伪造。

保障 Webhook 安全的最佳实践：
1. 签名验证：使用 HMAC-SHA256 等算法对请求体签名，接收端验证签名（如 GitHub、Stripe 的做法）。
2. HTTPS：始终使用 TLS 加密传输。
3. IP 白名单：限制只接受已知来源的 IP。
4. 请求时效性：检查时间戳防止重放攻击。
5. 密钥轮换：定期更换 Webhook secret。

典型场景包括：
• CI/CD：GitHub/GitLab push 事件触发自动构建部署。
• 支付通知：Stripe/PayPal 支付完成后通知业务系统。
• 消息通知：Slack/Discord 机器人接收消息。
• 数据同步：CMS 内容变更时同步到静态站点。
• IoT 设备：设备状态变化时上报数据。
• 表单处理：用户提交表单后触发后续工作流。

大多数 Webhook 服务提供商都有重试机制：
1. 如果接收端返回非 2xx 状态码，发送方通常会在一定时间后重试（指数退避）。
2. 确保接收端快速返回 200 OK（先接收再异步处理）。
3. 实现幂等性——使用唯一事件 ID 防止重复处理。
4. 监控 Webhook 的送达率和失败率。
5. 提供手动重试或死信队列机制。

本工具是纯前端模拟器，所有请求在浏览器本地生成和展示，用于测试和学习。如需接收真实的 Webhook，推荐使用 webhook.site、Beeceptor 或 RequestBin 等在线服务，或使用 ngrok 将本地服务器暴露到公网。您也可以部署自己的接收服务，参考本工具的设计思路。
🔧 相关工具