在Burp Suite里处理Proxy历史记录，最容易混掉的是两件事。一件事是把当前已经抓到的记录清掉，另一件事是以后别再继续堆很多。PortSwigger现在的官方文档明确说明，HTTP history主要负责展示经过Burp Proxy的浏览器流量，过滤器只影响显示，不会删除数据；而Proxy设置页则提供了“不要再把请求送进Proxy history”的控制项。也就是说，清理和限量不是同一个入口。

Burp Collaborator 本质上是一套 OAST 服务，也就是用“目标站点是否主动回连外部域名”来验证那些页面上看不出明显回显、报错或延时差异的问题。PortSwigger 官方文档写得很清楚，Burp 会先把一个 Collaborator payload 发到目标应用里，再由 Burp 轮询 Collaborator 服务器，看有没有 DNS 或 HTTP 这类交互发生。所以它的使用重点，不是先盯响应包，而是先把 payload 放到合适的位置，再去看有没有回连。

BurpSuite抓HTTPS流量时用的是本机生成的一套CA证书，你一旦更换或重生成CA，浏览器和设备端原先信任的证书链就会失效，表现为页面报证书错误或历史里只剩下CONNECT看不到内容。处理思路很固定，先在Burp里重生成或迁移CA，再把新CA安装到你实际使用的信任库里，最后把旧CA从各端清理掉并做一次验证闭环。

很多人装BApp时卡住，并不是扩展本身坏了，而是Burp访问BApp Store的网络链路、证书信任链或运行环境没配齐，导致列表刷新失败、安装按钮灰掉、安装中一直转圈、装完立即报错。把问题拆成可检查的几条线，先把Burp能稳定连到PortSwigger站点，再把需要的语言运行时与日志出口补齐，通常就能在一次排查周期内收敛到明确原因。

在公司内网、受控网络或需要代理链路的环境里，BurpSuite常要把外发请求先转给上游代理，再由上游代理出网。如果上游代理规则没匹配、连通性不通、认证信息不完整，就会表现为浏览器一直转圈、工具报超时、或直接返回407。围绕“BurpSuite上游代理为什么会连不上，BurpSuite上游代理认证怎么填写”，按可验证的路径把规则、连通与认证三件事分别确认，基本都能定位到具体故障点。

进行Web渗透测试或接口调试时，BurpSuite作为核心流量拦截工具，其会话记录模块承担了请求跟踪、漏洞定位的重要职责。然而，当测试目标稍微复杂一些，短短几分钟内就可能产生数百上千条请求，造成Target、Proxy、HTTP history等页面信息混乱，难以快速定位关键请求。要解决BurpSuite会话记录混乱的问题，必须合理设置过滤器，提升数据可视性与可控性。

在使用BurpSuite进行HTTPS流量抓包时，很多初学者会遇到“明明设置了代理却抓不到明文内容”的问题。浏览器访问HTTPS网站后，Burp中只显示CONNECT或乱码，无法解密任何内容。这种现象通常源于BurpSuite根证书没有正确安装或未被信任，导致客户端拒绝Burp的中间人证书，最终握手失败或数据加密无法还原。

在使用BurpSuite进行渗透测试或接口调试时，有时明明已开启代理监听，却始终抓不到任何流量。这类问题看似棘手，其实大多源自代理配置、证书设置、网络转发等环节未正确执行。只有系统梳理抓包失败的可能性，逐项排查，才能恢复BurpSuite的正常抓包功能，确保测试顺利进行。

在Web安全测试中，BurpSuite以其强大的拦截、重放与扫描功能成为渗透测试工程师的主力工具。而当内置模块无法满足项目需求时，BurpSuite也提供了强大的扩展机制，允许用户基于Extender API开发自定义插件，嵌入自己的逻辑流程或集成外部分析模块。围绕“BurpSuite Extender如何开发，BurpSuite ExtenderAPI应怎样调用”这一问题，下面从开发环境搭建、API结构理解到插件编写流程进行逐步展开。

在Web安全测试过程中，跨站请求伪造漏洞是一个常见且危害较大的问题。BurpSuite作为主流渗透测试工具，其内置的Scanner模块可自动检测CSRF漏洞。但很多用户在使用过程中发现检测精度不高、结果不完整或无法识别特定业务逻辑下的CSRF风险。要想发挥其最大效能，必须对BurpSuite的CSRF检测流程进行细致设置，并针对业务特点调整相关规则。