我运行 SaaS 监控服务。我们的标准集成示例是向我们提供的特殊 URL 发出 curl 请求。我们遇到了一个间歇性问题，用户遇到了 10 秒的 curl 超时（-m 10 参数）。但是，我可以在我的服务器日志中看到，当时处理的请求只需要 100-300 毫秒，这对我们来说是正常的。
我们确实会在每分钟的顶部看到流量高峰，但即便如此，我们也很少需要超过 1000 毫秒的时间。
我们有一个特别容易受到超时影响的用户。我已经要求他在他的 hosts 文件中设置我们的 IP，以确保这不是 DNS 问题。（虽然我非常有信心这不是 DNS）。
我喜欢任何关于微创方式的想法，我可以请这个用户帮助我进行故障排除。在我们转储之前，亚马逊 ELB 超时更为常见（尽管仍然非常罕见），我能够重现它几次，我看到了非常奇怪的“在 0 毫秒时超时”错误，好像连接在 10 秒后立即以某种方式被拒绝了暂停。
在我们的 iptables 配置中没有什么奇异的东西，只是阻塞了端口和错误的 ips。网络服务器堆栈是 nginx-uwsgi
我今天花了一些时间审核我的 iptables 脚本。我是一名软件工程师，而不是 Ops 专家，但我尝试学习 iptables 的基础知识。我注意到一些东西肯定已经坏了很长时间了：
# Allows all loopback (lo0) traffic and drop all traffic to 127/8 that doesn't use lo0
-A INPUT -i lo -j ACCEPT
-A INPUT -i lo -d 127.0.0.0/8 -j REJECT
好的，所以，看起来应该是：
-A INPUT -i ! lo -d 127.0.0.0/8 -j REJECT
正确的？
麻烦的是，服务器正在运行实时流量。虽然这看起来像是一个无害的更改，但我对 iptables 有适当的尊重。此外，这意味着我一直在接受来自 /8 的来自其他接口的流量。这在现实世界中意味着什么？机器如何在不同的接口上接收来自 127/8 的任何请求？