Github Enterprise Webhook服务超时：curl/Postman正常但平台配置报错

你遇到的这个情况挺典型的——手动用curl/Postman能正常请求，但GitHub触发Webhook就报服务超时，大概率是请求上下文差异或者GitHub侧的特殊限制导致的，下面给你几个针对性的排查和解决方向：

1. 补全请求头再测试 #

GitHub发送Webhook请求时会自带一系列专属请求头（比如X-GitHub-Event、X-Hub-Signature、X-GitHub-Delivery等），你手动测试时可能没完全模拟这些头，这可能导致服务端处理逻辑差异。试试在curl里补上这些头再验证：

curl -X POST \
  -H "X-GitHub-Event: push" \
  -H "X-Hub-Signature: sha1=你的签名值" \
  -H "Content-Type: application/json" \
  -d '@本地payload文件路径' \
  你的Payload URL

如果加上这些头后也出现超时，说明你的服务在处理这些专属头时存在性能瓶颈或逻辑阻塞。

2. 排查网络与防火墙规则差异 #

虽然你能手动访问服务，但GitHub Enterprise服务器和你的服务端之间可能存在特殊的网络限制：

• 确认GitHub Enterprise的出口IP已添加到你服务端的防火墙白名单（部分企业防火墙会拦截非人工发起的自动化请求）
• 检查服务端是否对来自GitHub的请求有额外的速率限制或安全校验，导致请求被阻塞超时

3. 优化服务端响应速度 #

GitHub的Webhook超时阈值通常比较严格（一般在10秒左右），手动测试可能没注意到细微的延迟，但批量触发或GitHub的请求队列会放大问题：

• 检查服务端处理Webhook payload的逻辑，把同步执行的耗时操作（比如大文件处理、远程API调用）改成异步处理（比如把任务丢到消息队列，先快速返回200响应）
• 给服务端添加简单的健康检查接口，对比健康检查和Webhook接口的响应速度，定位是否是Webhook逻辑本身拖慢了响应

4. 调整GitHub Webhook配置 #

试试在GitHub Enterprise的Webhook设置里做这些调整：

• 切换Content type为application/x-www-form-urlencoded（如果之前用的是JSON），部分服务对表单格式的解析速度更快
• 暂时只勾选单个事件（比如仅选push），缩小payload体积，测试是否还会超时
• 开启SSL verification（如果之前关闭了），部分环境对未验证的HTTPS请求会有额外的处理延迟

5. 查看GitHub Enterprise的详细日志 #

如果以上方法都没效果，登录你的GitHub Enterprise后台，查看Webhook的交付日志——里面会有更具体的超时细节（比如是连接超时还是读取响应超时），能帮你精准定位问题。

内容的提问来源于stack exchange，提问作者quki