我们在 AWS 上的 ubuntu 实例上运行了许多 Web 服务器（nginx、php5.6-fpm）。它们已经运行了好几个月，但在过去的几天里，我们开始遇到问题：实例启动后一切都很好，但大约 12 小时后，网络调用开始失败（具体来说，在本例中是到 redis 的套接字 tcp 调用）。
使用 tcpdump 进行一些挖掘后，看起来 DNS 查找由于 udp 校验和失败而被丢弃：
17:13:38.013346 IP（tos 0x0、ttl 64、id 46236、偏移量 0、标志 [DF]、proto UDP（17）、长度 103）10.0.0.121.34071 > 10.0.0.2.53：[坏 udp cksum 0x14df -> 0x3ae1！] 25855+ Type20736？xxxxxxxx.us-east-1.rds.amazonaws.com。（75）
如果我使用 telnet 从同一实例连接到 Redis 服务器，则一切正常，它似乎只影响 fpm。同样奇怪的是，它只在实例启动后不久才会发生 - 最初所有请求都顺利通过。同样，重新启动 php5.6-fpm 服务似乎可以暂时解决问题。
我的知识已经基本到此为止了，所以希望有人能给我指明正确的方向！
答案1
您安装了有缺陷的安全修复程序——这听起来像是来自USN-3239-2。
GNU libc 的安全更新解决了（除其他问题外）...
getaddrinfo()GNU C 库函数中的无限制堆栈分配。
....包含一个回归 - 一个意外的 ABI 变化 - 这似乎导致了与您描述的类似的问题......DNS 解析最终会停止工作，直到重新启动进程。
原始更新于 2017-03-20 发布，修复于 2017-03-21 发布。如果确实如此，应用最新的操作系统安全修复应该可以解决问题。
答案2
错误的校验和可能是由于校验和卸载。
我会检查是否是这种情况，您可以通过运行以下命令进行检查：
sudo ethtool --show-offload ethX
也许有必要进一步研究一下 tcpdump 可能会说什么内容但是，我怀疑您是否遇到了某种速率限制。您可能需要检查返回数据包NXDOMAIN或类似情况。
如果是这个问题的话，某种缓存解析器可能会有所帮助。
更新解释以下评论：
如果重新启动服务本身可以“修复”问题（感谢@利亚姆·威尔特郡对于添加的信息），那么我同意速率限制听起来不正确（或者至少上游的速率限制不正确）。
我认为由于本地资源而限制速率可能仍然是值得考虑的可能性：例如，确保 conntrack 条目没有限制，或者ulimit打开文件的数量没有限制（即nofiles太低）。
话虽如此，糟糕的安全补丁/糟糕的软件线索确实看起来更有希望 - 所以我肯定会给予权重（并给出分数）@Michael - sqlbot的建议。