在扫描、实时审计还有攻击测试的时候，资源池要怎么配置，以及它的并发数跑起来不太稳，碰到这种情况，主要得先分清楚当前跑的到底是扫描器、实时审计，还是攻击任务，Burp Suite里的资源池，作用是让好几个任务共享同一套网络资源配额，用它来控制同一时间发出去的请求数量，还有请求往外发的速度，如果没有手动去选一个资源池，扫描任务就会自己去用系统默认的那个，这个资源池主要是给扫描和实时审计这类任务用的，对于被动爬取那类任务，它并不适用。

在站点测试的初期，有一个情况是挺常见的，就是浏览器只要一走Burp的代理去访问页面，Burp就会一刻不停地，把抓到的域名、目录、文件，还有带参数的请求，全给放进站点地图里面去，按照官方的文档说明，站点地图这个东西，就是用来展示Burp在探索目标应用的时候，所收集到的那些信息的，并且，它还支持在按地址去看的视图，和按爬虫路径去看的视图之间，来回切换。

在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的正常抓包功能，确保测试顺利进行。