我正在尝试调试一些包含大型文件上传（约 500 MB）的失败 HTTP POST 请求。最终用户收到奇怪的 HTTP 响应，这些响应未记录在 varnish 的 varnishncsa 工具、varnish 的 varnishlog 工具或任何内部 Web 服务器日志中。由于我无法复制该问题（可能是 ISP 代理的结果），我正在尝试找到一些选项来记录整个请求（由 URL 标识）并稍后在开发或暂存服务器上重放它。
看起来 Snort 可能是解决这个问题的最佳方法，因为它允许我们在传入数据包被（错误）解释之前记录它们，但我担心它可能会导致如此大的请求带来显著的延迟、内存开销或其他不可预见的问题。我们需要做的所有匹配都将基于 URL，因此实际上只需要过滤第一个 KB 左右，但我们需要请求的其余部分才能重放。
我正在查看 snort 文档中的 readme.stream5，这使得这看起来可能并且合理，但文档和现实世界之间的差距可能相当大。
Snort 是否适合这项任务？我可以应用哪些优化来避免过多的内存、磁盘或处理器开销？如果您认为 Snort 不适合这项任务，您会建议采用什么方法？
服务器安装在全球范围内分布在运行最新 Linux 设置的无头机上，因此任何解决方案都必须是可编写脚本的、自动化的，并且能够通过某种方式向我报告它已捕获的请求。