我在 Amazon EC2 实例上运行 tcpdump 来监控流向 Nginx 的 HTTP 流量（这只是一个测试箱，唯一的资源是示例测试页面）。
使用以下命令运行 tcpdump
# tcpdump -vn -i any port 80
显示浏览器向网站发出的请求的数据包，但显示没有什么使用 Python 脚本（使用 Requests 库）或手动制作的数据包（Scapy）访问页面时。
- 没有运行本地防火墙并且安全组已正确设置。
- 脚本运行正常：我可以轻松地在本地端的 tcpdump 中捕获事务，并且它们返回状态为 200 OK 的页面。
- 将数据包直接保存到文件（-w）也没有区别，排除缓冲问题（我相信？）
- 我也试过看看VLAN导致了这个问题，但没有运气；搜索“80”仍然没有结果。
问题：
- 什么可能导致 tcpdump 错过这些非常特殊的数据包确实穿过防火墙到达 Nginx 然后再返回？
- 为什么来自 Firefox 的数据包可以被看到，而从脚本发送的数据包却被忽略了？
谢谢
答案1
尝试使用特定接口而不是“任何”。该“设备”不能在混杂模式下使用。请参阅 tcpdump 手册页：http://www.tcpdump.org/manpages/tcpdump.1.html
答案2
这个问题提出后发布的一项技术是VPC 流日志。这样您就可以查看 VPC 中的网络流量，并根据需要进行过滤。
VPC 流日志不会显示完整的数据包内容，只会显示一些基本信息，例如源、目标、端口、协议、大小、时间和操作（例如接受或拒绝）等。它也不会显示源自和终止于 EC2 实例内的流量。
这不是问题的直接答案，因为它没有解决问题。但它可能提供一种收集信息以解决类似问题的替代方法。
答案3
也许是snaplength？
- -s snaplen
- --快照长度=snaplen
从每个数据包中截取 snaplen 字节的数据，而不是默认的 262144 字节。由于快照有限而被截断的数据包在输出中用“[|proto]”表示，其中 proto 是发生截断的协议级别的名称。 请注意，拍摄较大的快照不仅会增加处理数据包所需的时间，还会有效减少数据包缓冲量。这可能会导致数据包丢失。 您应该将 snaplen 限制为能够捕获您感兴趣的协议信息的最小数字。将 snaplen 设置为 0 会将其设置为默认值 262144，以便与最近的旧版本的 tcpdump 保持向后兼容。
我通常使用 65535。