在Burp Suite里做项目时，很多人会把项目文件和项目配置当成同一件事，结果前面明明已经导出了配置，后面换一台机器或者换一个项目时，却不知道该从哪里重新接进去。PortSwigger官方现在把这两层分得很清楚。项目文件用来保存当前项目的数据和项目级设置，配置文件则是JSON格式的设置集合，可以单独导入、导出和重复加载。也就是说，真正想复用的通常不是整个项目，而是配置本身，所以导入和复用时要先分清你拿在手里的到底是project file还是configuration file。

在Burp Suite里用Decoder，看起来像是把一段编码内容丢进去再点一次解码就结束了，但实际使用里最常见的问题不是不会点，而是数据本身有多层编码、截断、压缩、混合格式，或者当前选择的解码方式根本和原始数据不匹配。PortSwigger官方现在把Decoder的定位说得很明确，它既支持手动解码，也支持自动识别并解码可识别的格式，比如URL编码；同时，Inspector也会在很多场景里自动解码选中的数据。所以真正高效的做法不是只守着一个窗口，而是先分清数据是不是“Burp能自动识别的格式”，再决定是用Decoder手动拆，还是借Inspector先看一轮。

BurpSuite证书通常被安装到系统或浏览器的受信任根证书里，用于让浏览器在走代理时不报证书错误。卸载时如果只删了证书但没关代理，或者只关了代理但浏览器里还残留证书与缓存，就容易出现打不开网站、一直提示不安全、连不上代理这类现象。下面按先卸载证书，再恢复访问的顺序，把常见平台的操作路径写清楚。

做渗透测试或接口联调时，抓到的请求响应往往是后续复现、写报告、交接排查的唯一依据。BurpSuite里看得到流量不等于已经保存到可长期留存的介质里，你需要先分清是临时会话数据，还是落盘的工程文件，再按目的选择全量保存或按需导出。

做移动端抓包时，核心就两件事：一是在BurpSuite里把代理监听开到局域网可访问，二是在手机上把网络代理指到这台电脑并把Burp的CA证书装进信任链。前者决定你能不能看到流量，后者决定你能不能解密HTTPS，否则常见现象就是HTTP有记录、HTTPS全红或直接打不开页面。

在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上游代理认证怎么填写”，按可验证的路径把规则、连通与认证三件事分别确认，基本都能定位到具体故障点。

在Burp Suite里，宏本质上不是“录屏回放”，而是一组从Proxy历史记录里挑出来、按顺序执行的HTTP请求。PortSwigger官方文档写得很直接，宏通常用来处理登录、会话恢复和令牌更新这类需要重复走一遍的流程；而真正让宏在测试里自动生效的，不是宏本身，而是后面的Session handling rule。也就是说，先把宏录对，再把规则挂对，登录流程复用才会稳。

在授权测试场景里，BurpSuite做手工验证时，常见痛点不是抓不到包，而是请求改完要回放很多次，列表一多就容易漏看关键差异。更顺的做法是先用Repeater把请求改到可复现，再用Repeater的分组发送把一组请求批量回放，等基线响应稳定后，再把同一条请求送进Intruder做参数变异，把异常响应筛出来，最后回到Repeater复核复现。

由PortSwigger发布的Burp Suite默认会记录代理通道里的HTTP与WebSocket消息，页面资源一多就会出现历史列表刷屏、检索困难、内存占用上升的问题。处理思路可以分两层，第一层先把抓取范围收敛到你确实要测的目标，第二层再用过滤规则把显示与记录分开控制，做到既不漏关键请求，也不被静态资源淹没。

在排查接口签名、复现偶发请求、验证边界条件时，你经常需要在不改代码的前提下，临时改一改请求头、Cookie、参数或响应内容。围绕“BurpSuite Match and Replace有什么用，BurpSuite Match and Replace规则怎么写”，把它理解成一套可控的流量改写器更准确：先按匹配条件抓住目标流量，再按替换动作把内容改成你想要的样子，并且可以对不同工具链的流量分别生效。

BurpSuite里一个项目文件往往承载了Proxy历史、站点地图、扫描与组织器数据等关键证据链，一旦出现“项目文件打不开”，轻则当天的抓包与记录需要重做，重则历史线索和复测依据丢失。处理这类问题要把思路拆成两步：先让文件“能被正常打开或被识别为可修复”，再把数据“尽可能完整地恢复到可继续使用的新文件”，同时补上备份与存储位置这道保险。

Burp Suite里的Comparer，本质上就是一个专门做可视化差异对比的小工具。PortSwigger官方文档写得很直接，它可以拿来比较任意两段数据，最常见的用法就是对比两条请求或两条响应，快速找出那些肉眼不容易一眼看出来的细微变化。真正用顺以后，它特别适合拿来比登录前后响应、不同参数下的请求差异，或者同一接口在不同权限下返回内容的变化。

BurpSuite里改了请求但服务器侧看起来没变化，通常不是编辑框没保存，而是你改的那一条并没有真正被转发出去，或者被拦截规则放行了没有停下来，又或者被自动规则二次改写覆盖。按下面顺序把流量是否经过、拦截总开关、拦截规则组合顺序、自动改写规则执行顺序逐个核对，问题一般能在十分钟内收敛到具体开关与具体规则上。

做Web测试时，如果站点或客户端默认走HTTP/2，你在BurpSuite里却看不到请求体、响应体，甚至HTTP history里没有任何条目，往往会让排查方向跑偏。处理这类问题要先确认流量是否真的进了代理链路，再把HTTP/2相关的入站与出站开关分别核对清楚，最后用协议显示位确认每条请求实际用的版本，避免“看起来像没数据”其实只是展示口径不同。

在授权范围内做Web测试时，真正麻烦的往往不是抓到一个Token，而是判断它到底“够不够难猜”。BurpSuite的Sequencer把这件事拆成可量化的统计结果与可定位的位置异常，帮助你从会话Cookie、CSRF令牌到重置链接参数，快速判断随机性质量与潜在可预测模式。读懂Sequencer结果的关键，是先看样本与总体，再落到每一位的异常原因，最后把结论回到业务语义上去验证。

做授权范围内的Web测试时，很多人会遇到登录态跑着跑着就失效，或每次请求都要带动态令牌与CSRF字段，导致Repeater复测、Intruder压测、Scanner审计都被迫中断。BurpSuite的会话保持本质是把登录续期、Cookie与令牌更新、会话有效性检查放到后台自动完成，让后续请求始终带着可用的会话信息，减少手工补票与漏测风险。