BurpSuite中的Logger用于集中记录Burp各工具产生的HTTP流量，除了浏览器代理请求，还能看到Repeater、Scanner、Intruder以及扩展主动发送的请求。处理“BurpSuite怎么使用Logger记录流量，BurpSuite Logger记录不完整如何排查”时，关键是先分清“请求没有被记录”和“请求已经记录但当前没有显示”。这两种情况表现相似，背后的原因却不同。

　　一、BurpSuite怎么使用Logger记录流量

　　Logger适合在测试过程中统一观察不同工具产生的请求，尤其是自动扫描、扩展调用或会话处理产生的后台通信。与Proxy中的HTTP history相比，它覆盖的Burp内部流量范围更广。

　　1、开启Logger并确认基础记录正常

　　①启动BurpSuite并打开当前测试项目。

　　②进入【Logger】，确认日志记录处于开启状态。

　　③打开【Proxy】→【Intercept】，选择【Open Browser】启动Burp内置浏览器。

　　④访问测试目标并执行登录、页面跳转或接口请求等操作。

　　⑤返回【Logger】，观察列表是否持续增加新的记录。

　　⑥单击其中一条请求，检查下方是否能够看到完整的请求和响应内容。

　　Burp内置浏览器会自动通过Burp Proxy访问目标，因此很适合作为Logger是否正常工作的基础测试环境。

　　2、设置需要记录的流量范围

　　Logger可以通过捕获过滤器决定哪些请求真正进入日志。这里的设置会直接影响数据是否被保存，因此首次排查时不宜配置得过于严格。

　　①单击【Capture filter】打开捕获设置。

　　②在【Capture by tool】中勾选需要记录的Proxy、Repeater、Scanner、Intruder或Extensions等来源。

　　③需要查看完整测试流量时，暂时取消【Capture only in-scope items】。

　　④检查是否启用了【Discard items without responses】或【Capture only parameterized requests】。

　　⑤查看MIME类型、状态码和搜索条件，确认没有把目标请求排除。

　　⑥应用设置后重新发送几条测试请求，观察Logger记录变化。

　　官方说明中，未通过Capture filter的项目会直接从Logger中丢弃，即使之后取消过滤条件也无法恢复，因此这部分更适合控制真正不需要保存的数据。

　　3、使用显示过滤快速定位请求

　　当Logger记录数量较多时，可以通过显示过滤缩小观察范围，而不改变已经保存的数据。

　　①单击【View filter】打开显示过滤设置。

　　②按【Filter by tool】选择当前需要查看的工具来源。

　　③根据测试需要设置MIME类型、状态码或文件扩展名。

　　④需要定位特定域名、参数或内容时，再使用搜索条件缩小范围。

　　⑤分析结束后取消过滤，确认其他已记录请求能够重新显示。

　　与捕获过滤不同，View filter只改变当前显示结果，被隐藏的数据仍然保留在Logger中。

　　二、BurpSuite Logger记录不完整如何排查

　　Logger中缺少部分请求时，不要直接判断Burp没有抓到流量。更有效的方式是先观察缺失规律，例如只有某个工具的请求没有出现、早期请求逐渐消失，还是大响应只有一部分内容，这些现象对应的检查方向并不相同。

　　1、先排除View filter造成的隐藏

　　①打开【View filter】，暂时取消所有工具、状态码、MIME类型和文件扩展名限制。

　　②清除已有搜索关键词和正则条件。

　　③查看此前缺失的请求是否重新出现。

　　④如果请求恢复显示，重新逐项添加过滤条件，找到具体是哪项规则将其隐藏。

　　这种情况说明Logger本身记录正常，只是当前视图没有把全部数据展示出来，不需要重新抓取流量。

　　2、检查Capture filter是否直接丢弃了请求

　　①进入【Capture filter】，检查【Capture by tool】中是否遗漏当前使用的工具。

　　②关闭【Capture only in-scope items】，再发送一次目标请求。

　　③取消仅参数化请求、特定状态码或MIME类型等限制。

　　④重新执行原来的测试操作，并观察新请求是否进入Logger。

　　⑤新产生的请求能够显示时，再根据实际需求重新缩小捕获范围。

　　需要注意，Capture filter排除的数据不会保留，所以修改配置后只能重新发起请求，无法找回之前没有捕获的记录。

　　3、检查日志容量是否已经达到上限

　　长时间运行Scanner、Intruder或自动化扩展时，Logger可能积累大量记录。官方当前默认的【Capture limit】为50MB；如果Burp获得至少1GB内存，则默认可以达到100MB。达到限制后，Logger会在新数据进入时逐步丢弃最早的记录。

　　①进入【Capture filter】，查看当前【Capture limit】。

　　②如果表现为“后面的请求还在，但开始阶段的记录消失”，适当提高容量。

　　③清理不需要长期保存的高频工具流量，减少日志占用。

　　④调整后重新运行一段完整测试，确认早期请求是否仍然保留。

　　容量不宜无条件调得很大，因为官方也提醒，给Logger分配过多内存可能带来额外性能开销。

　　4、检查请求或响应是否被截断

　　有时列表中的请求数量正常，但打开后发现响应正文不完整，这属于单条记录大小受到限制，并非整条请求没有进入Logger。

　　①查看【Capture filter】中的【Limit request/response size】。

　　②确认目标接口是否返回大型JSON、文件下载、图片或较大的HTML内容。

　　③默认限制无法覆盖当前响应时，提高允许记录的单条数据大小。

　　④重新发送目标请求，再比较响应长度和正文结尾。

　　PortSwigger当前文档显示，Logger默认的单条请求或响应最大捕获大小为1MB。

　　三、还有哪些流量容易被误认为Logger漏记

　　有些问题并不来自Logger配置，而是测试者把不同通信类型或代理链路都当成普通HTTP请求来检查。此时即使反复修改过滤器，也不会得到预期结果。

　　1、确认外部浏览器流量确实经过Burp

　　①先使用Burp内置浏览器访问相同页面进行对照。

　　②内置浏览器能够正常记录时，再检查外部浏览器的代理地址和端口。

　　③确认对应Proxy Listener处于正常监听状态。

　　④HTTPS页面无法正常通信时，再检查Burp CA证书和代理配置。

　　Burp Proxy只有在流量实际经过代理时才能检查和转发请求，外部浏览器绕过Burp后，Logger自然不会产生对应的代理流量。

　　2、把WebSocket通信单独检查

　　部分网页加载阶段使用HTTP，建立连接后则通过WebSocket持续交换数据。此时只盯着普通HTTP记录，容易误以为后续消息没有被捕获。

　　①进入【Proxy】→【WebSockets history】。

　　②重新执行聊天、实时通知、行情刷新等相关操作。

　　③观察是否持续产生新的WebSocket消息。

　　④结合连接方向、时间和消息内容，与Logger中的握手请求对应起来。

　　Burp为WebSocket提供了独立历史记录，其中会保存浏览器与服务器交换的WebSocket消息，因此这类通信应与普通HTTP流量分开分析。

　　总结

　　“BurpSuite怎么使用Logger记录流量，BurpSuite Logger记录不完整如何排查”的核心，在于正确理解Logger记录范围以及不同过滤机制对结果的影响。实际测试中，完整记录并不等于无限保存所有数据，更重要的是根据测试目标保留有价值的通信，同时能够判断流量缺失究竟发生在哪一层。把Logger作为统一的请求观察入口，可以更清楚地梳理Burp各工具和扩展之间的通信情况。希望本文对大家使用BurpSuite Logger有所帮助，如果在流量记录范围、日志缺失判断或不同通信类型的分析方面还有疑问，欢迎联系咨询。