把 OpenClaw 网关接到 GitHub Webhook，本质是「公网能打到你的进程」，并且用 X-Hub-Signature-256 证明请求来自 GitHub、用 原始 body 保证摘要一致，再用 时间窗口与幂等键 顶住重放与自动重试。最后别忘了：GitHub 期待你在 超时窗口内尽快给出 2xx，重活放到队列里慢慢做。下文按网络 → 仓库 → 签名 → 401 → 超时 → 复现写；监听端口与健康检查以当前 OpenClaw 文档为准。
一、公网回调与 TLS
Payload URL 要对 GitHub 出口可达：HTTPS 链完整，反代保留 Host / X-Forwarded-Proto，否则容易出现「内网正常、外网 301 死循环」的假阳性。只监听 127.0.0.1 时公网永远进不来；应监听 0.0.0.0 或由 Nginx/Caddy 反代到本机端口。建议先用外网机器 curl -v 打健康检查与回调路径，确认 TLS、状态码与响应体都和内网一致，再回仓库点测试投递。路径与常驻方式见 了解更多：OpenClaw 远程 Mac 部署实操。
二、仓库 Webhook 设置要点
Content type 用 application/json；Secret 参与签名。事件按需订阅，避免无关事件刷爆队列。仓库里的「测试」按钮只能证明 GitHub 能连到你的入口，不代表后续中间件不会改写 body；仍要以真实 push 与 Redeliver 对照网关日志。
三、签名与时间戳
验签必须用 原始 body 参与 HMAC_SHA256(secret, rawBody)，再与 X-Hub-Signature-256 的 sha256=… 做 常量时间比较；任何先 JSON.parse 再序列化的写法，都会悄悄改掉空白符，从而「本地看起来对、线上永远不过」。X-GitHub-Delivery 建议落库作 幂等键，避免重试时重复触发副作用。若你还校验事件时间戳，窗口一般取 ±5 分钟，并记得用 ntp 或系统时钟服务校准。Actions 编排见 了解更多：OpenClaw 手把手部署与自动化集成手册。
四、401 常见根因
Secret 不一致、缺 sha256=、body 被中间件先解析，是最常见的三类问题。若你还在网关层校验 Bearer，记得与 Webhook Secret 分层：前者给管理面，后者给 GitHub 投递面。反代若挂了 Basic Auth，要确保 GitHub 的自动重试同样能拿到 2xx，而不是被拦在网关外却误以为业务拒绝。
五、超时与重试
GitHub 对单次投递常见 约 10 秒超时：网关应先 200/202，把克隆、构建、通知等重活丢给队列或 worker。否则会出现 失败重试 + 重复投递，只能靠 X-GitHub-Delivery 幂等兜住副作用。若网关进程频繁重启，会把重试风暴放大，这时先回到 launchd 与端口稳定性排查：了解更多：OpenClaw 网关 launchd 稳定性排错手册。
六、可复现排错
把下面几条写进团队 runbook，基本能覆盖 80% 的「为什么我这能过、GitHub 过不去」。
- 在仓库 Redeliver 同一条，比较两次
X-GitHub-Delivery、HTTP 状态与响应体。 - 用 curl 复现：TLS、路径、
Content-Type、User-Agent尽量与线上一致。 - 反代与网关打印同一 request id；核对 body 字节长度，gzip 或 pretty JSON 常是签名失败的元凶。
Webhook 网关，为什么适合落在 Mac mini 上
7×24 网关要静音与低功耗，Mac mini 待机约 4W 量级更省长期成本；macOS 上 Brew、反代与 OpenClaw 同机联调顺畅，Apple Silicon 带宽利于验签与队列，Gatekeeper、SIP、FileVault 降低无人值守风险。先把单机 TLS、签名、幂等跑顺再扩节点。
若你需要独享可 SSH 的远程 macOS，Mac mini M4 仍是 2026 年高性价比起点——前往 Macstripe 首页 查看机型与区域。
