我们在AWS上的ubuntu实例上运行了许多Web服务器（nginx，php5.6-fpm）。 他们已经运行好几个月了，但是在过去的几天里，我们已经开始讨论一个事件发生后一切正常，但在12个小时左右之后，networking调用开始失败（特别是在这个实例套接字tcp调用redis）。
在使用tcpdump进行了一些挖掘之后，由于udp校验和失败，看起来dns查找被抛出：
17：13：38.013346 IP（tos 0x0，ttl 64，id 46236，offset 0，flags [DF]，proto UDP（17），length 103）10.0.0.121.34071> 10.0.0.2.53：[bad udp cksum 0x14df – > 0x3ae1！] 25855+ Type20736？ xxxxxxxx.us-east-1.rds.amazonaws.com。 （75）
如果我使用telnet从同一个实例连接到Redis服务器，那么很好，它似乎只影响fpm。 同样奇怪的是，它只是在实例开始后才发生 – 最初的所有请求都没有问题。 同样，重新启动php5.6-fpm服务似乎已经清除了一段时间的问题。
在这一点上，我的知识基本已经结束了，所以希望有人能指出我正确的方向！
您安装的安全修复程序存在缺陷 – 这听起来像USN-3239-2的问题。
GNU libc的一个安全更新，解决（除其他外）…
GNU C库的
getaddrinfo()函数中的无限堆栈分配。
….包含了一个回归 – 一个意想不到的ABI变化 – 似乎导致类似于您所描述的问题… DNSparsing最终将停止工作，直到进程重新启动。
原始更新是发布2017-03-20和修复发布2017-03-21。 如果是这样，应用最新的操作系统安全修复程序应该可以解决问题。
错误的校验和可能是由于校验和卸载造成的 。
我会检查是否是这种情况，你可以通过运行：
sudo ethtool --show-offload ethX
值得深入研究一下tcpdump可能会对你的数据包的内容做些什么，但值得注意的是，我想知道你是否可能没有达到某种速率限制。 您可能想检查NXDOMAIN或类似的返回数据包。
如果这是问题，有某种cachingparsing器可能会有所帮助。
更新为以下评论：
如果重新启动服务本身就是“解决”问题（感谢@ Liam Wiltshire提供的更多信息），那么我同意速率限制听起来不正确（或者至less是上游没有速率限制）。
我认为由于本地资源的限制可能仍然是一个值得考虑的可能性：例如，确保没有conntrack条目的限制，或限制打开的文件（即nofiles是低的。
话虽如此，坏的安全补丁/坏的软件引导似乎更有希望 – 所以我肯定会给予重量（并给予积分）@ 迈克尔 – sqlbot的build议。