BurpSuite抓包改包实践：无加密HTTP环境下的入门操作指南

在Web安全测试和接口调试这条路上，BurpSuite几乎是绕不开的一个工具。我见过很多人第一次打开它，对着满屏的英文面板不知所措，社区里也总有人问“BurpSuite怎么抓包”、“为什么开了抓不到”、“改了包发出去没反应”。这篇文章我从最基础的场景讲起，不带任何加密、不搞插件、不碰复杂配置，就用BurpSuite对一个无加密的网页做完整的抓包和改包操作，把从下载安装、监听设置、流量捕获到修改请求、重放请求的每一步都拆开讲清楚。无论你是刚接触安全测试的新手，还是想补一下抓包基本功的开发同学，这篇文章应该都能帮你省不少绕弯的时间。

1. 为什么抓包要单独用BurpSuite，而不是浏览器自带的开发者工具

很多人一开始会觉得疑惑：我按F12打开开发者工具，网络面板里也能看到请求和响应，数据量也不小，为什么还要专门装一个BurpSuite来做抓包改包？

这个问题的答案，直接决定了你是否真的需要这个工具。

浏览器开发者工具的定位是“查看”。你能看到页面发了哪些请求、返回了什么状态码、加载了哪些资源，它是围绕前端调试设计的。但它的能力边界也很明显：你没法轻松地拦截一个请求、把它修改之后再放行，也没法把一个请求反复发送多次并随意改动参数。你可以用开发者工具编辑并重放单个请求，但那只是“Copy as cURL”之后在终端里手动改，操作繁琐且不直观。

BurpSuite的核心定位是“拦截与转发”。它在你和服务器之间充当一个中间人的角色，浏览器的请求先到BurpSuite，由它转交给服务器；服务器的响应也先回到BurpSuite，再由它返回浏览器。在这个位置上的好处是，你可以随时把流量按住、停下来、改掉、再放出去，整个过程对所有中间链路透明，不只是在浏览器上“看”，而是真正掌握了流量通路的控制权。

抓包工具按流量处理方式可以分两类：基于网卡流量的被动捕获，比如Wireshark、tcpdump；基于HTTP代理的主动截获，比如BurpSuite、Fiddler、Charles。如果你要处理的是网页请求、接口调试、Web安全测试，BurpSuite的代理模式最贴合需求，因为它停留在HTTP/HTTPS协议层，对请求的解析、修改、重放都有成熟的交互逻辑。而Wireshark工作在更低层，能看TCP、UDP甚至MAC帧，对Web应用的定向抓包反而没那么顺手。

再补充一个重要概念：BurpSuite和Fiddler、Charles是同一类工具，都依赖代理机制工作。所谓监听，本质上是在你本机开一个HTTP代理端口，然后让浏览器的流量指向这个端口。BurpSuite默认监听127.0.0.1:8080，浏览器只要是走HTTP协议发起请求，就会被这个端口截住。这里不涉及任何破坏性技术，一切都是标准HTTP交互流程，你手动指定浏览器走本地代理，流量就会经过BurpSuite，原理和公司内网指定的正向代理一样，区别只是BurpSuite是本地自建的，且允许你实时查看和篡改内容。

对我个人来说，日常调试接口时F12其实够用，但一旦涉及“这个参数改成其它值会怎样”、“去掉某个Cookie还能不能访问”、“批量测试几个ID返回什么差异”这一类问题，我就必须回到BurpSuite。它有专门的Repeater模块可以无限制地改包发包，还有Intruder模块可以自动遍历参数，这些是浏览器开发者工具给不了的。

2. 搭一套本地实验环境，先把“无加密网页”准备好

无加密网页的正式说法是HTTP明文流量。它的特点是从客户端到服务端全程不加密，所有请求头、表单、Cookie都以文本形式在网络里传输。在BurpSuite上做基础练习，HTTP站点是最友好的，因为你完全不需要处理HTTPS证书信任问题，抓包过程更干净，也更容易理解代理抓包的机制。

很多人抓不到包，并不是BurpSuite配置错了，而是他们找了个HTTPS网站做实验，然后卡在了证书安装步骤上。这个教训我在社区里看到太多次。如果你只是想学抓包改包的基本功，建议先在HTTP环境里跑顺整条链路，再考虑HTTPS和证书。

本地起一个HTTP实验站点的方法有很多，我给你的方案是：什么都不装，直接用一个公开的HTTP测试网站。这类站点存在的意义就是让学习者做实验，服务端已经开启了明文HTTP协议入口，内容大多是演示性页面和不敏感API，非常合适。

国内能稳定访问的纯HTTP测试站，几个可以用：http://httpbin.org 虽然提供接口镜像，但有时被网络环境影响；http://neverssl.com 是一个坚持不走HTTPS的演示站，适合验证代理是否生效。你请求它，它会返回一个简单页面，页面内容是什么不重要，关键是它能通过HTTP明文方式正常打开。如果你想测更丰富的请求方法、Header、表单提交，也可以用基于HTTP开放的API Base地址，只要协议前缀是http://即可。

如果你希望实验目标在自己掌控之下，可以本地起一个极简的HTTP服务，用Python的http.server模块就行：

bash复制python3 -m http.server 8000

这样你的电脑上就多了一个监听8000端口的HTTP静态文件服务器，用浏览器访问http://127.0.0.1:8000，就能看到目录列表。这个方案的妙处在于：流量从浏览器到本机端口，没有任何加密，也没有任何跨网络干扰，是排查BurpSuite配置问题的绝佳环境。

如果你想测表单提交和参数回显，非要用一个能接收POST并返回数据的接口。Httpbin的/post接口会用JSON格式返回你提交的所有参数，这在练习改包时非常方便，一眼就能看出你修改的参数是否真实生效。它的地址是http://httpbin.org/post，同样是明文HTTP。

在开始抓包之前，还有一个概念要提醒：BurpSuite的代理监听只对“走代理的流量”生效。浏览器直接发起请求不走代理的话，BurpSuite只能干瞪眼。所以后面配置浏览器时，要确保流量确实被引导到本地8080端口。

3. BurpSuite的安装不是难点，配置监听入口才是

BurpSuite的版本选择，社区里讨论很多。免费版（Community Edition）足够完成基础的抓包改包练习，如果你之前没买过专业版也不想折腾各种未知来源的授权文件，我建议先从社区版开始。官方网站是portswigger.net，下载页会给出Windows、macOS、Linux的安装包，界面逻辑基本一致，下载完成直接双击安装，没有复杂的依赖。

启动后，BurpSuite会询问临时项目还是新建项目。临时项目适合做短期测试，选中之后界面会进入主工作区。首次启动弹出的配置选项保持默认即可，重点要打开的是Proxy模块的监听设置。默认配置下，BurpSuite的代理监听地址是127.0.0.1:8080，也就是只监听本机回环地址，不对外网开放。

这里有一个常见的安全习惯要养成：不要随意把监听地址改成0.0.0.0。默认的127.0.0.1意味着只有你这台电脑能连上代理，如果改成所有网卡监听，局域网内其它设备也能把流量导到你的BurpSuite上来，轻则产生大量干扰流量，重则被别人利用做中间人转发。除非你明确要做手机抓包，需要让手机通过局域网IP连到电脑端口，才需要改监听IP，且用完立刻改回。

验证BurpSuite代理是否正常，有一个很简便的方法：在浏览器里把HTTP代理设为127.0.0.1:8080，然后访问任意HTTP站点，如果BurpSuite的Proxy > HTTP history页面出现了一条条记录，说明流量已经成功经过它。

BurpSuite的主界面模块排布比较固定：Dashboard是任务总览，Proxy是抓包历史和拦截开关的核心，Target（目标树）、Intruder（爆破/遍历）、Repeater（重放）是后续会频繁用到的模块。初学阶段只需要盯住Proxy和Repeater两个模块，其它模块往后用到再深入，不要指望第一个下午就全部掌握。

关于浏览器选择，我强烈建议用Firefox来做抓包实验。理由很简单：Firefox可以独立于系统设置单独配置代理，不需要动操作系统的全局网络配置，抓完包之后把浏览器代理设置为“不使用代理”就能恢复到正常上网状态。Chrome虽然也可以配代理，但它更多依赖系统代理设置，切换起来麻烦且容易影响其它程序。

Firefox的代理配置路径如下：设置 > 常规 > 网络设置 > 设置，选择“手动配置代理”，HTTP代理填127.0.0.1，端口填8080，勾选“也将此代理用于HTTPS”，然后保存。此时访问HTTP站点，BurpSuite就能看到流量了。

如果你在配置完代理后发现浏览器无法打开任何网页，就要立刻怀疑代理设置本身。常见原因有几种：BurpSuite没在运行、端口不是8080、浏览器代理设置保存失败但界面显示勾选了。逐个排查就好。代理状态是否生效可以通过访问一个HTTP测试站来验证，如果页面一直转圈但BurpSuite记录里出现请求，说明流量已经进入管道，只是响应没有被转发出来，这种我会在第6节结合排查链路细说。

4. 第一次完整抓包：把HTTP请求的每一个细节都识别出来

代理配置到位后，第一次抓包建议按下面这个顺序操作，不要把动作搞复杂。

先在BurpSuite的Proxy模块里，确保Intercept开关处于关闭状态。这个开关的默认状态是关闭，但很多人不知道它代表什么意思。Intercept开（On）的时候，所有经过的请求都会被挂起，等你在界面上手动点击Forward才放行；Intercept关（Off）的时候，流量只是被记录，不拦截。初学阶段你先让它Off，这样浏览网站不会卡住，同时请求记录会一条一条地出现在HTTP history里。

然后回到Firefox，地址栏输入http://neverssl.com，回车。页面加载完成后，切回BurpSuite，点击Proxy > HTTP history，你会看到若干条记录。第一条通常是你访问根路径的请求，状态码200说明它成功拿到了页面。

这时候点击这条记录，在右侧的Raw（原始报文）标签页里，能看到完整的HTTP协议原文。一个典型的HTTP GET请求文本，大致长这样：

http复制GET / HTTP/1.1
Host: neverssl.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:115.0) Gecko/20100101 Firefox/115.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: zh-CN,zh;q=0.7,en-US;q=0.3
Accept-Encoding: gzip, deflate
Connection: keep-alive
Upgrade-Insecure-Requests: 1

这段文本里，第一行的GET是请求方法，/是请求路径，HTTP/1.1是协议版本。往下的每一行都是请求头，其中Host字段表示目标服务器地址，User-Agent表示客户端类型，Accept-Language告诉服务器你接受的语言。这些都是HTTP协议的基础内容，抓包时你能一眼看到明文，这就是“无加密网页抓包”最直观的体验。

看完了请求再看响应。在HTTP history里选中刚才那条记录，切换到Response选项卡，能看到服务器返回的状态码和响应头，以及HTML页面源码。比如：

http复制HTTP/1.1 200 OK
Server: nginx/1.18.0
Content-Type: text/html
Content-Length: 390

Content-Length字段表示响应体长度，单位是字节；Content-Type告诉浏览器这是一份HTML文本。这些字段在后续做更高级的测试时会经常用到，比如判断服务端是否压缩了响应、是否设置了CORS头、是否存在信息泄露头等。

如果想一步步看请求的实时到达过程，可以把Intercept切到On，然后刷新页面。此时浏览器应该停在等待状态，BurpSuite的Intercept选项卡里出现了一个被截获的请求，等待你决定。点Forward放行到服务器，点Drop丢弃。这个拦截过程并不复杂，但它是整个抓包改包工作的核心入口。

我在抓包过程中养成了一个习惯：每次打开BurpSuite做测试前，先清空一次HTTP history，避免旧记录干扰判断。点击HTTP history区域上方的垃圾桶图标即可清空。测试完成后，也可以把历史记录导出到文件里存档，BurpSuite支持导出为HTML和XML等格式，方便写报告时引用。

无加密抓包和HTTPS抓包在这里有一个显著差异：HTTPS流量经过BurpSuite后会显示“证书无效”的告警，直到你安装并信任BurpSuite自己签发的CA证书才不再报错。HTTP流量完全不需要这个步骤，所有内容直接明文呈现，这也就是为什么我把第一个实验放在HTTP环境上。先把代理链路理解透，再去碰证书体系，心里的困惑会少很多。

5. 改包的三种基础玩法：改参数、改请求方法、用Repeater批量重放

抓包只是手段，改包才是让BurpSuite真正发挥价值的地方。完整的“改包”操作，可以通俗地理解为：当浏览器已经发出一个请求但还未送达服务器之前，把请求内容篡改成你想要的数据，然后再放行。服务器接收到的，就是被你改过的那份请求。改包的玩法很多，最基础的是下面三种，建议按顺序练一遍。

5.1 拦截修改表单参数，观察服务器响应差异

目标地址用http://httpbin.org/post，这个接口会接收POST请求，并在响应JSON里返回你提交的参数内容。

操作顺序是：先在BurpSuite的Proxy选项卡里，把Intercept切到On。接着在浏览器里打开一个最简单的HTML表单提交页。你可以直接用一个本地HTML文件，内容就两个字段：一个叫username，一个叫role。表单提交地址填http://httpbin.org/post，method为POST。提交后，浏览器请求被BurpSuite截住，Intercept页面出现一份POST请求原文。

http复制POST /post HTTP/1.1
Host: httpbin.org
Content-Type: application/x-www-form-urlencoded
Content-Length: 28

username=alice&role=user

光标停留在请求体位置，把role=user改成role=admin，然后点击Forward放行。打开浏览器的响应页面，你会发现httpbin返回的JSON里的form字段中，role已经是admin。这虽然只是一个演示接口对你的修改没有真实校验，但整个链路已经完整跑通：流量经过BurpSuite，被修改，服务器接收到的是修改后的值。

服务端是否信任你提交的这个role字段，取决于它有没有在Session或数据库里二次核对权限，而不是取决于客户端字段叫什么名字。这就是很多Web漏洞产生的根源——对客户端提交的数据过度信任。作为测试者，你能通过改包验证出服务端有没有做这类校验。

5.2 修改请求方法和路径，访问接口的隐藏行为

浏览器里访问一个静态页面通常只能用GET。但如果后端允许同一URL支持不同请求方法，你就可以通过改包改变行为。比如把GET /post HTTP/1.1改成DELETE /post HTTP/1.1，再看服务器返回什么状态码。改成不存在的路径再试，比如GET /nonexistent HTTP/1.1，服务器会返回404。

这种修改方法的意义在于：探测服务器对异常输入的处理逻辑。有些接口会区分不同方法给出不同的业务行为；有些不允许的方法会返回405 Method Not Allowed，说明方法被显式禁止了；有些则返回200并执行了默认逻辑，这种情况就得警惕，可能意味着后端框架做了宽松的匹配。

实际操作时，只修改请求头里的方法名和路径，保留Host和其它头不动，Forward放行后观察响应。这是了解目标站点路由设计最快的方式之一。

5.3 使用Repeater保存请求模板，快速重复发包

抓包改包最累的操作是“每次都现改现发”，遇到需要反复测试的场景就烦了。BurpSuite提供了Repeater模块，翻译为“中继器”，就是让你把一份请求保存成可编辑模板，随时随地修改、发送、查看响应。

具体操作如下：在HTTP history里右键点击一条请求，选择“Send to Repeater”，快捷键是Ctrl+R。切到Repeater选项卡，左侧是完整的请求原文，右上角的Send按钮是发送，右侧是服务器返回的响应。点一次Send，服务器就收到一次请求，响应的状态码、时间、内容都会更新。

Repeater最大的价值是让你把“一份请求”变成“可以反复修改的标本”。你可以在请求原文里改动任意一个字节，然后点击Send查看响应，整个过程不涉及浏览器。想测参数缺失、参数值异常、Header变更，都在这里改完直接发。

Repeater配合HTTP明文测试站，效率极高。比如访问http://httpbin.org/get拿到一个GET请求，把它发到Repeater，然后在URL参数后追加一个?name=value，Send，看响应里的args字段是否出现对应参数。如果你什么参数都不加，直接改User-Agent头，服务器会通过headers字段原样返回，一眼就能确认你改没改对。

我个人的习惯是：在Repeater里发送请求之前，先确认右侧的响应渲染模式。BurpSuite默认有Raw和Render等视图，Raw显示报文原文，这永远是排查问题的首选。如果看到响应是一大段压缩后的乱码，确认一下请求头里的Accept-Encoding是否包含deflate，必要时删掉这一行重发，就可以看到明文响应了。

6. 抓不到包时的完整排查链路：先证明流量到了哪里

这是一个大概率会遇到、也最打击新手信心的问题：Firefox里访问网页一切正常，但BurpSuite里一条记录都没有，或者浏览器直接打不开网页了。

不要慌，按下面这套链路从上往下排查。

第一步，确认BurpSuite的代理监听处于运行状态。打开Proxy > Options，在最上方的Proxy Listeners列表里，看有没有一行127.0.0.1:8080，状态显示Running。如果列表为空或没有处于Running状态，点Add添加，Bind to Port填8080，Bind to Address填127.0.0.1，保存即可。

第二步，确认浏览器代理设置指向了正确地址。Firefox里“不使用代理”和“手动代理配置”两个选项互斥，如果你选择手动代理后地址端口填错了，流量当然不会进BurpSuite。这里最容易被忽视的细节是端口号——BurpSuite显示的默认端口是8080，但如果你之前手动添加过其它端口的监听，浏览器配置的端口必须和监听列表里的端口完全一致，一个数字都不能差。

第三步，确认流量走了代理但BurpSuite漏掉了。有一个非常典型的场景：浏览器配置了HTTP代理，但访问的是HTTPS站点，并且你没有勾选“也将此代理用于HTTPS”选项。BurpSuite不会收到这些加密流量，表现就是浏览器正常打开网页，BurpSuite毫无动静。而我们实验用的是HTTP站点，不存在此问题，所以遇到问题时要回头核查站点协议。

第四步，用命令行验证本地端口是否真的有活动。Windows上可以运行：

bash复制netstat -ano | findstr 8080

如果能看到监听，说明BurpSuite端口正常。如果浏览器访问网页的同时这条命令里没有任何到127.0.0.1:8080的连接，说明流量根本没走这个端口，那是浏览器代理配置的问题，与BurpSuite无关。

这套排查逻辑的核心是分清责任边界。BurpSuite只负责接收发送到它监听端口的流量，不负责主动去“抓”，更不负责强制所有浏览器走代理。它的工作方式是守株待兔。所以判断时永远先问：兔子有没有经过这棵树下？如果访问的是通过HTTPS直连的地址，显然不会经过你配的HTTP代理；如果浏览器本身绕过了代理，也同样不会经过。

还有另一种常见现象：浏览器访问不了任何网页，而BurpSuite里可以看到请求积压着。这种情况通常是Intercept被打开了，所有请求被挂起。你会在界面上看到一个等待处理的请求，不点Forward它就一直卡住。如果你用“暂停抓包，先看看历史”的心理去操作，第一次遇到这个界面肯定会懵一下。解决方法是：点击一次Forward放行当前请求，或者在Interceptor选项卡里把Intercept开关关掉。如果积压了多个请求而你又不想逐个放行，可以直接在代理设置里取消代理，停止浏览器与BurpSuite的关联，再重新配置。

关于请求积压还有一个被人忽略的细节：Intercept只会拦截配置过的作用域条件内的请求。免费版不允许配置高级作用域条件，所以默认拦截所有流量。专业版可以通过“URL匹配规则”只拦截特定域名的请求，减少无关流量干扰。初学阶段建议直接全量拦截，等以后有明确目标时再做最小化拦截设置。

7. 无加密环境练熟了之后，下一步需要的几个进阶方向

无加密网页的抓包和改包本质上只是打开了BurpSuite的第一扇门。这个过程教会了你完整的代理交互链路，也让你对HTTP协议结构有了直观手感。但真实世界里的流量大部分已经是HTTPS加密的，无加密环境练熟之后，进阶方向大体分四条路，按优先级排列。

第一条路是处理HTTPS流量。你需要理解证书信任链，在BurpSuite里生成CA证书，导出给浏览器安装并信任。这个过程不复杂，但很多人的困惑在于“BurpSuite为什么能解密HTTPS”。原理是BurpSuite利用自己生成的CA证书，在浏览器和服务器之间重新建立了两段TLS连接。浏览器验证的是BurpSuite伪造的证书，而这段证书被你的浏览器手动信任了；BurpSuite再向真实的服务器发起另一段TLS连接。正是因为浏览器端信任了BurpSuite的CA，你在界面上才能看到解密后的明文HTTP内容。

第二条路是学习移动端的抓包。移动App和微信小程序的流量跟网页不同，它们对代理的感知更强，应用层可能自己实现了证书固定。基础的手机抓包可以理解为：手机和电脑处于同一个局域网，手机的网络代理指向电脑的局域网IP，BurpSuite监听地址需要从127.0.0.1改成局域网IP。这是第3节故意让你保持默认监听地址的另一个原因——先理解默认值，再突破默认值。

第三条路是深入学习Repeater、Intruder、Decoder等模块的组合用法。Repeater适合手工精细测试，Intruder则能批量遍历参数。比如你想测试一个ID参数从1到1000有什么差异，手工在Repeater里发1000次显然不现实，Intruder的Sniper模式可以指定payload字典自动填充参数位置并逐个发请求，返回的结果可以根据状态码和响应长度快速筛选。很多社区说的“爆破字典”本质上就是Intruder的payload集合。

第四条路是理解Session与Cookie机制，把改包能力应用到登录态相关的业务逻辑测试中去。HTTP是无状态的，服务端通过Cookie识别你是不是同一个用户，Cookie里可能存了Session ID、用户ID、Token等数据。你可以在BurpSuite里截获登录后的请求，修改Cookie中的某个值，观察服务器是否还能识别身份。这类实验在真实站点上有法律风险，做之前要确认你已获得授权，或使用专门练习用的靶机环境，比如DVWA、WebGoat，或者在线演武场。

无加密网页抓包改包真的是所有流量调试、安全测试、接口联调的基础课。它足够简单，让你把注意力放在了解工具本身；又足够完整，让你在十分钟之内理解“中间人代理”这个最核心的模型。把这套模型吃透了，后面所有的高级话题——HTTPS解密、移动端代理、自动化扫描、Token绕过——都是在它之上的一个个增强层。

还有一个小习惯值得养成：每次做完测试，记得把BurpSuite的Intercept恢复为Off，把浏览器代理恢复为“不使用代理”。我见过太多人在测试结束后忘了关代理，导致第二天上网突然打不开网页，然后折腾半天才发现是浏览器还在走本地代理。测试环境和个人上网环境严格分开，这个意识越早建立越好。