You need to enable JavaScript to run this app.
优惠活动
大模型
产品
解决方案
定价
更多

GitHub Webhook通过HTTPS触发超时问题排查求助

GitHub Webhook HTTPS请求超时,但Postman/curl可正常调用——求排障最佳实践

问题描述

我的预发布站点GitHub Webhook指向https://staging.domain.com/git_webhook,遇到了奇怪的问题:

  • HTTP协议下Webhook工作完全正常,能正常接收并处理payload
  • 切换到HTTPS后,GitHub始终返回**"We couldn’t deliver this payload: Service Timeout"**,即使关闭Webhook的SSL验证选项也无效
  • 用Postman或curl调用该HTTPS接口完全正常,能收到正确响应,没有任何超时或错误

已尝试的排查步骤

防火墙与系统服务排查

服务器是Ubuntu 18.04,运行apparmor、ufw、fail2ban:

  • 确认ufw已开放HTTPS端口(443),规则配置正确
  • 逐一禁用apparmor、ufw、fail2ban后重启Apache,问题依旧存在
  • 检查所有防火墙规则,未发现针对GitHub IP段的拦截策略

SSL证书相关排查

  • 主域名domain.com持有Comodo SSL证书(不包含子域名),预发布域名staging.domain.com有有效的Let's Encrypt SSL证书
  • 执行openssl s_client -showcerts -servername staging.domain.com -connect staging.domain.com:443 </dev/null,返回的是staging.domain.com的Let's Encrypt证书,验证正常
  • 但执行openssl s_client -showcerts -connect staging.domain.com:443 </dev/null(不带-servername参数),返回的是主域名的Comodo证书——怀疑GitHub Webhook不支持SNI(Apache虚拟主机已配置<ServerName ...>)
  • 后续尝试调整证书配置,均未解决问题:
    • 禁用Comodo证书,将Let's Encrypt证书扩展为包含domain.com和staging.domain.com,重启Apache后问题依旧
    • 给staging.domain.com配置Comodo免费30天证书,问题仍未解决
  • 用ssllabs测试staging.domain.com时,显示Let's Encrypt证书,但同时出现主域名的Comodo证书(因域名不匹配被标记警告)

数据包捕获分析(Edit 1)

触发Webhook推送时,执行tshark命令捕获GitHub IP段的流量:

sudo tshark -d tcp.port==443,ssl -f "net 140.82.112.0/20 or net 185.199.108.0/22 or net 192.30.252.0/22"

关键输出如下:

1 0.000000000 140.82.115.240 → <MY_SERVER_IP> TCP 74 64733 → 443 [SYN] Seq=0 Win=26880 Len=0 MSS=8960 SACK_PERM=1 TSval=2233744096 TSecr=0 WS=1024 
2 0.000066037 <MY_SERVER_IP> → 140.82.115.240 TCP 74 443 → 64733 [SYN, ACK] Seq=0 Ack=1 Win=61936 Len=0 MSS=8860 SACK_PERM=1 TSval=2212655787 TSecr=2233744096 WS=128 
3 0.000879665 140.82.115.240 → <MY_SERVER_IP> TCP 66 64733 → 443 [ACK] Seq=1 Ack=1 Win=27648 Len=0 TSval=2233744097 TSecr=2212655787 
4 0.012202817 140.82.115.240 → <MY_SERVER_IP> TLSv1 313 Client Hello 
5 0.012281121 <MY_SERVER_IP> → 140.82.115.240 TCP 66 443 → 64733 [ACK] Seq=1 Ack=248 Win=61696 Len=0 TSval=2212655799 TSecr=2233744109 
6 0.013146175 <MY_SERVER_IP> → 140.82.115.240 TLSv1.2 2799 Server Hello, Certificate, Server Hello Done 
7 0.231698984 <MY_SERVER_IP> → 140.82.115.240 TCP 2799 [TCP Retransmission] 443 → 64733 [PSH, ACK] Seq=1 Ack=248 Win=61696 Len=2733 TSval=2212656019 TSecr=2233744109 
8 0.451700300 <MY_SERVER_IP> → 140.82.115.240 TCP 2799 [TCP Retransmission] 443 → 64733 [PSH, ACK] Seq=1 Ack=248 Win=61696 Len=2733 TSval=2212656239 TSecr=2233744109 
9 0.895731268 <MY_SERVER_IP> → 140.82.115.240 TCP 2799 [TCP Retransmission] 443 → 64733 [PSH, ACK] Seq=1 Ack=248 Win=61696 Len=2733 TSval=2212656683 TSecr=2233744109 
10 1.791706743 <MY_SERVER_IP> → 140.82.115.240 TCP 2799 [TCP Retransmission] 443 → 64733 [PSH, ACK] Seq=1 Ack=248 Win=61696 Len=2733 TSval=2212657579 TSecr=2233744109 
11 3.551693664 <MY_SERVER_IP> → 140.82.115.240 TCP 2799 [TCP Retransmission] 443 → 64733 [PSH, ACK] Seq=1 Ack=248 Win=61696 Len=2733 TSval=2212659339 TSecr=2233744109 
12 4.930201185 140.82.115.240 → <MY_SERVER_IP> TCP 66 64733 → 443 [FIN, ACK] Seq=248 Ack=1 Win=27648 Len=0 TSval=2233749027 TSecr=2212655799 
13 4.930468118 <MY_SERVER_IP> → 140.82.115.240 TCP 66 443 → 64733 [FIN, ACK] Seq=2734 Ack=249 Win=61696 Len=0 TSval=2212660718 TSecr=2233749027 
14 4.931240019 140.82.115.240 → <MY_SERVER_IP> TCP 54 64733 → 443 [RST] Seq=249 Win=0 Len=0 

解密后发现:服务器发送完Server Hello, Certificate, Server Hello Done(帧6)后,GitHub没有任何握手响应;服务器重传5次该数据包仍无反馈,随后GitHub主动关闭连接,无错误信息返回。

额外测试(Edit 2)

  • 搭建了一个仅配置Apache+自签名SSL证书的测试服务器,GitHub Webhook同样出现超时问题
  • 在一个配置了有效付费Comodo证书的公开站点测试Webhook,也遇到了相同的超时情况

求助需求

  1. 请问可能导致GitHub Webhook HTTPS请求超时的原因是什么?
  2. 针对这类GitHub Webhook的HTTPS排障,有哪些最佳实践可以遵循?

内容的提问来源于stack exchange,提问作者paulrw

相关产品推荐
方舟 Agent Plan

超全模态模型 × Harness 升级,最新支持 Deepseek-V4.1-Flash、GLM-5.3 系列、Doubao-Seedream-5.0-pro、Kimi-K3 (部分), 限时 9.9 元起

最近更新时间:2026.05.07 17:02:36