这个问题是关于让github webhook在https上工作的。这也是一个缺乏经验的人提出的关于故障排除最佳实践的问题。
我有一个github webhook用于我的中转站点，它指向https://staging.domain.com/git_webhook
如果我把它指向http而不是https，它就可以完美地工作。但是使用https，github响应：We couldn’t deliver this payload: Service Timeout。即使对webhook禁用了SSL验证，也会发生这种情况。
使用Postman和curl，webhook可以在https上完美运行。
我尝试过的
- 检查防火墙是否负责
服务器是Ubuntu 18.04，带有apprmor、ufw和fail2ban。在ufw中，https对所有人开放。我禁用了每个服务并重新启动了apache，但没有成功。我还没有找到任何单独列出github ip的规则。但我缺乏经验，如果它们存在的话，我可能不知道如何深入观察。我认为，只要简单地禁用这些服务就足以测试它们是否参与其中。
- 使用tsark检查来自github的传入HTTPS POST请求
tshark显示，在"服务器你好，证书，服务器密钥交换，服务器你好完成"之后，没有握手。从我的服务器到github有4或5次[PSH，ACK]重传，github没有响应，然后github关闭连接。
- 我的SSL证书有问题吗
My main domain.com有一个Comodo SSL证书，该证书不适用于任何子域。我的staging.domain.com有一个有效的Let's Encrypt SSL Cert.
当我运行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时，我得到了属于主域的Comodo证书
也许github的webhook服务无法处理SNI？(主和子域Apache虚拟主机都包括<ServerName ... >(
然后，我禁用了Comodo SSL证书，并扩展了Let's Encrypt证书以包括domain.com和staging.domain.com，然后重新启动了Apache。仍然是github的"服务超时"。
github不喜欢Let's Encrypt吗？我从科莫多订购了一份30天的免费证书，并将其应用于staging.domain.com。运气不好。
当我通过运行staging.domain.com时https://www.ssllabs.com/ssltest，它显示了Let's Encrypt证书，但有趣的是，在它下面，它显示的是"certificate#2"，这是domain.com的Comodo证书。由于域名不匹配，该证书被标记为许多红色警告。这是异常行为吗？我是否应该在访问(或分析(staging.domain.com时发现一种无法检测domain.com证书的方法？
在这一点上，我完全没有主意了。我将感谢所有的指导。这也是我的第一个SO问题，我也愿意就我的问题礼仪提出建议。
编辑1：激活webhook推送事件时，这里是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"的输出(这些是github的webhook IP(：
1 0.000000000 140.82.115.240 → <IP OF MY SERVER> 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 <IP OF MY SERVER> → 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 → <IP OF MY SERVER> TCP 66 64733 → 443 [ACK] Seq=1 Ack=1 Win=27648 Len=0 TSval=2233744097 TSecr=2212655787
4 0.012202817 140.82.115.240 → <IP OF MY SERVER> TLSv1 313 Client Hello
5 0.012281121 <IP OF MY SERVER> → 140.82.115.240 TCP 66 443 → 64733 [ACK] Seq=1 Ack=248 Win=61696 Len=0 TSval=2212655799 TSecr=2233744109
6 0.013146175 <IP OF MY SERVER> → 140.82.115.240 TLSv1.2 2799 Server Hello, Certificate, Server Hello Done
7 0.231698984 <IP OF MY SERVER> → 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 <IP OF MY SERVER> → 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 <IP OF MY SERVER> → 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 <IP OF MY SERVER> → 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 <IP OF MY SERVER> → 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 → <IP OF MY SERVER> TCP 66 64733 → 443 [FIN, ACK] Seq=248 Ack=1 Win=27648 Len=0 TSval=2233749027 TSecr=2212655799
13 4.930468118 <IP OF MY SERVER> → 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 → <IP OF MY SERVER> TCP 54 64733 → 443 [RST] Seq=249 Win=0 Len=0
当我看到tshark的解密输出时，第6帧似乎是SSL证书信息从我的服务器到github的初始传输。然后，帧7到11是相同信息的又5次重传，全部没有应答。之后，github只启动关闭连接，没有任何错误。
编辑2：从那以后，我尝试使用默认的Apache和自签名SSL证书来启动测试服务器。同样的问题。我还试着在我的面向公众的网站上测试了webhook，该网站有一个功能齐全、签名并付费的科莫多证书。同样的问题。
Github支持花了几个星期的时间才回复我，但最终他们发现了问题：
"服务器上的MTU设置得很高，并且您不接受ICMP碎片整理响应(MSS=8860(">
键入ip addr显示网络接口(在本例中为ens3(的mtu设置为8900。这是我部署的Ubuntu 20.04镜像的开箱即用设置。
按照我在网上找到的说明，我使用了ping -s XXXX -c1 distrowatch.com，发现XXXX的任何数字高于1452都会导致100%的数据包丢失。
头的1452+28字节意味着1480 mtu设置应该有效。
从上一个ip addr命令中知道网络接口是ens3，我输入了sudo ip link set dev ens3 mtu 1480，并尝试重新交付github-webhook。沃伊拉，成功了。
在我的系统上，网络配置不是在/etc/network/interfaces，而是在/etc/netplan/50-cloud-init.yaml。因此，为了使mtu的更改永久化，我对该文件进行了备份，然后将其mtu从8900编辑到1480。最后，github-webhook成功了！