投递行为
取自该平台的官方文档，最近核对于 2026-08-06。平台没有给出数字的地方，这张表也不填。
| 响应时限 | 2 秒 机器人服务器 2 秒内没有应答，即计为 request_timeout |
|---|---|
| 重试 | Webhook 重新投递，默认关闭（在频道的 Messaging API 设置中开启）；次数和间隔未公开 |
| 放弃 | 机器人服务器持续无法接收时，可能暂停发送 Webhook；阈值未公开 |
| 出处 | https://developers.line.biz/en/docs/messaging-api/receiving-messages/ |
签名
用一个经测试套件证明的可运行验证器核对，不是照着文档读来的。最近核对于 2026-08-20。
| 算法 | HMAC-SHA256 |
|---|---|
| 待签名串 | raw body |
| 编码 | base64 |
| 请求头 | x-line-signature = base64 |
| 时间容差 | 无强制要求 |
验证签名
要用原始请求体，逐字节一致，并且在任何 JSON 解析之前。框架一旦重新序列化请求体，本页的每一种方案都会失效。
const crypto = require("node:crypto");
// base64(HMAC-SHA256(channel secret, raw body))
const expected = crypto
.createHmac("sha256", channelSecret) // Messaging API → Basic settings
.update(rawBody)
.digest("base64");
const received = Buffer.from(req.headers["x-line-signature"] ?? "");
const wanted = Buffer.from(expected);
// timingSafeEqual throws on a length mismatch, so check that first.
const valid =
received.length === wanted.length && crypto.timingSafeEqual(received, wanted);容易踩的坑
重新投递功能是有的，但默认关闭：必须在频道的 Messaging API 设置中开启，而且 LINE 不公开次数和间隔。在你打开它之前，每一次投递失败都意味着丢失一条消息。
如果机器人服务器持续接收失败，LINE 可能会完全暂停发送 Webhook，而且阈值未公开。一个约 1 秒应答、只拒收无法保存的请求的转发服务，能把这个不确定因素基本排除。
延伸阅读
AnyHook 挡在接收 LINE Webhook 的端点前面：约 1 秒应答，你的服务器宕机时按自己的计划重试，并且每个事件都可以重放。 只改一个 URL，代码不用动。