2026年OpenClaw Linux云VPS：网关Webhook返回HTTP 202导致第三方集成失败？Nginx/Caddy改写与健康探针联动的可复现排障（决策矩阵+FAQ）

在 Linux 云 VPS 前用 Nginx 或 Caddy 做 TLS 与反代时，OpenClaw 网关 Webhook 有时返回 HTTP 202 Accepted。RFC 上 202 表示「已接受处理」，但不少内网桥、监控脚本或自研集成只认 200，于是出现「curl 通、控制台却失败」。先区分直连端口与经反代的状态码是否一致，再决定改网关、改反代还是改对端验收。HTTPS 基线可参考 OpenClaw Gateway 生产化与 Nginx/Caddy HTTPS FAQ；自托管 Git 触发构建可对照 Gitea/Forgejo 与云 Mac 的 Webhook 决策矩阵。

1. 可复现现象：谁在「不接受」202？

第三方平台登记公网 URL → 反代 → 本机 OpenClaw。请在服务器上对「域名」与「127.0.0.1:监听端口」各执行 curl -i，确认 202 来自上游而非反代误包装。

2. 为什么会出现 202？

异步网关常尽快向回调方确认「报文已入队」。官方集成多要求 200 与固定 body；自建中间层若写死 status==200，就是契约不一致：改上游、在边界整形状态码，或放宽对端。

3. 决策矩阵：改哪里最划算？

4. Nginx 与 Caddy 边界改写

标准 Nginx 无法在纯声明配置里把上游成功响应码改掉；常见做法：OpenResty 用 header_filter_by_lua 条件把 202 置 200，或换 Caddy 的 replace_status。务必只匹配 Webhook location，避免全局抹平其它 202 API。

handle_path /openclaw/webhook/* {
    reverse_proxy 127.0.0.1:<gateway-port> {
        @upstream202 {
            status 202
        }
        replace_status @upstream202 200
    }
}

5. 健康探针与 Webhook 联动

负载均衡若对根路径 GET 拿到非 200，可能摘除后端，使回调间歇失败。应单独暴露 /healthz 等恒 200 的只读路径，与需 POST、验签的 Webhook 分离；探针勿对 Webhook URL 高频 POST，以免触发限流与签名校验。

6. FAQ

Q：202 违规吗？ 不违规；对端写死 200 就只能对齐契约或改对端。Q：proxy_intercept_errors 能改 202 吗？ 不能，它处理的是错误页映射，与成功码改写无关。