最近在给团队搭建一套内部用的问卷成本评估工具测试完一版之后总感觉提交反馈的链路有点玄学有时候用户填到一半页面就卡住有时候提交完没跳转成功后台却已经收到了数据。我自己的第一反应不是去翻服务端日志而是先打开抓包工具把一次完整的问卷提交过程从浏览器到服务端从头到尾看一遍。这篇内容就当作一次抓包分析的复盘记录以问卷星这类常见在线问卷平台为例把方法、工具、参数含义和踩坑点一次讲明白。先说明边界这篇文章只讲网络调试、协议学习、前端接口排查等正当用途所有操作都以“自己创建的测试问卷”作为案例目的是理解 HTTP/HTTPS 请求的流转过程。不做任何绕过问卷限制、批量刷写、获取他人数据之类的越界操作。抓包工具本身是中性的用对了是研发和测试人员最趁手的调试利器用错了就是侵权工具差别全在用途上。1. 抓包分析的场景与边界1.1 什么情况下需要给问卷做抓包分析很多人一听“抓包分析”就想到逆向或者攻击其实大多数时候抓包就是一个标准的网络诊断流程。我在实际工作中遇到的场景基本集中在这几类。首先是问卷页面无法正常加载。这种问题特别难排查因为浏览器里看到的是白屏或者报错但搞不清楚是前端代码的问题、接口返回的问题还是网络中间层的问题。抓包可以快速定位请求到底发出去了没、状态码是多少、响应体里是什么内容。其次是提交失败。用户填完问卷点了提交结果一直转圈或者提示提交失败。这种情况后端日志可能看不到任何记录因为请求根本没到后端也可能后端收到了但返回了某个错误码。通过抓包可以看到请求是否到达服务器、服务器返回了什么、响应耗时是多少。然后是性能优化。我测试时发现某个问卷页面前端渲染特别慢抓包后看到有几个静态资源文件体积很大还有一些接口串行等待时间过长。这些数据只有通过实际网络请求才能准确拿到服务端日志是看不出来的。最后是接口联调和测试。比如你要给问卷系统接入第三方数据上报或者要确认某个字段在前端是怎么传的抓包是非常直观的沟通语言。前端说“我传了”后端说“我没收到”把两个包拉出来一对比问题就化解了。1.2 抓包分析有哪些绝对不能碰的红线既然要聊抓包就必须先把合规边界说清楚很多问题是“技术不复杂但性质很严重”。不要通过抓包获取或篡改其他用户的数据。问卷平台上的答卷数据属于填答者和问卷创建者的隐私财产任何未经授权的查看、保存、修改都涉及法律风险。不要利用抓包绕过问卷限制。比如答题次数限制、跳题逻辑限制、收集截止时间限制等。平台设置这些规则有它的目的用技术手段绕过等同于破坏规则可能会被平台封禁账号严重的还会涉及违约或违法。不要用于自动化灌量。很多平台有反作弊机制抓包分析后写脚本批量提交这种操作不仅影响数据质量也会给自己带来风险。正确的使用姿势是什么我在做抓包分析时一定是围绕自己创建的测试问卷、自己负责的系统、或者明确获得授权的测试环境来操作的。目标只有一个把网络请求链路看清楚把问题定位出来把性能分析透。这样用抓包它就是一把非常好用的工程工具。2. 抓包工具选型与前期准备2.1 三款主流工具的适用场景对比工欲善其事必先利其器。抓包工具我常用的是三款Wireshark、Charles 和 Fiddler它们各有侧重适合不同场景。工具擅长领域核心优势主要短板适用人群Wireshark底层网络协议分析能看到网卡上所有数据包TCP/UDP/DNS 全都能看对 HTTPS 解密配置较繁琐界面信息量大新手容易迷失网络工程师、协议学习者CharlesHTTP/HTTPS 抓包调试配置简单界面友好支持断点、重写、弱网模拟商业授权收费仅凭个人体验也不错前端、移动端、测试工程师FiddlerHTTP/HTTPS 抓包调试免费脚本扩展能力强可以写规则自动化处理界面老旧部分功能学习成本高Windows 用户、接口调试如果你只是想把一次问卷提交的请求和响应看清楚我建议优先用 Charles 或者 Fiddler它们是应用层代理工具专门针对 HTTP/HTTPS 设计信息呈现更直观。Wireshark 更偏底层能看到 TCP 握手、TLS 握手、丢包、重传等但也会展示大量无关的广播包和协议包新手容易被淹没。我之前踩过一个坑刚开始学抓包时直接用 Wireshark打开后看到满屏的 DNS 查询和 TCP 握手包完全不知道下一步该干嘛。后来才明白Wireshark 的强项是网络层分析而调接口、查请求响应这种应用层问题交给 Charles 或 Fiddler 更合适。当然做网络性能排查的时候 Wireshark 又是不可替代的比如你要看一个接口的整体握手耗时、确认是否有丢包重传用 Wireshark 的过滤器可以看得清清楚楚。2.2 HTTPS 解密的基本原理为什么一定要装证书现在的问卷平台基本全面启用 HTTPS直接代理上去会看到加密的一堆乱码根本没法分析。要解密 HTTPS就得理解 TLS 的握手过程。HTTPS 的核心是通过 TLS/SSL 协议对 HTTP 内容加密。网页和服务器之间先进行一次 TLS 握手协商出会话密钥之后双方用这个密钥加密通信。如果我们在中间做代理客户端信任了代理的证书后代理就能做一次“中间人解密”客户端与代理之间建立 TLS 连接客户端信任代理的 CA 证书所以代理能看到明文。代理再与真正的服务器建立 TLS 连接服务器验证代理的身份代理在这里充当一个转发和解析节点。所以你需要在电脑或手机上安装抓包工具自带的 CA 证书并信任它。装完证书后代理才能解密客户端发给服务器的流量。这就是为什么每次用 Charles/Fiddler 抓 HTTPS 时第一步都是下载并信任证书。这个机制用生活化的例子解释你本来和服务器用只有你俩知道的暗号通信抓包工具在中间装作服务器和你通信你信任了抓包工具的“信物”CA 证书就把暗号告诉它了然后它再用另一个暗号去和真正的服务器通信。整个过程就是通过双重身份把两边的内容都看了一遍。2.3 电脑端与手机端的抓包配置要点电脑端的配置相对简单。以 Charles 为例安装后默认会在 8888 端口开启 HTTP 代理你需要做的第一件事是确认系统代理已指向这个端口然后到菜单栏的 Proxy SSL Proxying Settings 里勾选 Enable SSL Proxying添加需要解密的域名或者直接用通配符*。需要注意一个细节为了让浏览器信任 Charles 的证书需要先访问chls.pro/ssl下载 CA 证书并导入到系统的“受信任的根证书颁发机构”中。在 macOS 上还要去“钥匙串访问”里手动设置为始终信任否则某些新版本的浏览器仍然不会信任它。手机端稍微麻烦一点。手机和电脑要在同一局域网内然后把手机的 WiFi 代理手动指向电脑的局域网 IP 和 8888 端口。手机浏览器访问chls.pro/ssl下载并安装证书。Android 7.0 之后有个坑系统本身不会信任用户安装的 CA 证书只在应用明确配置了信任时才生效。我自己的做法是如果只是调试普通的 Web 问卷页面优先用电脑上的 Chrome 开发者工具自带的 Network 面板不需要额外配置代理直接就能看到请求详情。但如果你要通过手机 App 访问问卷或者需要模拟弱网、打断点、重写响应那就得用 Charles/Fiddler 走代理。3. 问卷提交链路的抓包实操3.1 用一份测试问卷跑通全流程我建议所有想学抓包的朋友第一次操作都别拿生产环境来试老老实实自己建一个测试问卷。在问卷星上创建一个包含单选、多选、填空、量表题的测试问卷开启登录后才能填写之类的设置这样你会看到一个相对完整的网络交互链路。操作步骤很简单先打开抓包工具这里以 Charles 为例确认抓包开关已经开启。在电脑浏览器打开测试问卷的页面这时你会看到 Charles 里陆续出现很多请求包括 HTML、CSS、JS、图片、接口请求等。找到填写问卷的请求先不要急着点提交看一下页面加载时请求了哪些接口重点关注返回题目信息和配置的接口。在页面上填写几道题然后点击提交。回到 Charles找到刚才提交动作产生的 POST 请求双击查看详情。这样一次操作下来你就完成了第一次有目标的问卷抓包。整条链路基本会包含这样几个阶段页面静态资源加载、题目配置拉取、提交答卷、跳转或返回结果。3.2 一次提交背后的请求链路全景我把一次完整的问卷提交请求按时间线拆开大概是这样阶段请求方向主要目的常见方法与特征页面加载前端 - 静态资源服务器加载 HTML/CSS/JSGET返回 HTML 文档然后加载 JS/CSS题目拉取前端 - API 服务获取问卷题目、选项、跳题逻辑GET 或 POST请求参数中包含问卷 ID动态更新前端 - API 服务获取图片验证码、登录态校验等POST携带 token 或 cookie提交答卷前端 - API 服务将用户填写的选项和文本提交到后台POST请求体为 JSON 或表单格式结果确认API 服务 - 前端返回提交成功状态和后续跳转返回 JSON包含状态码、提示消息前端发起的请求数量会比预期的多很多。我观察到一次最简单的答题过程页面加载阶段可能就有几十个资源请求提交阶段反而相对集中通常就是几个核心接口。看请求别嫌多先用筛选工具把 Fetch/XHR 筛选出来这样剩下的就是主要接口。3.3 关键请求头和请求体的解读抓包最有价值的部分是读懂请求头和请求体里的字段含义。下面我用一个典型的提交问卷 POST 请求来拆解。先看请求头我抓到的类似这样实际信息做了脱敏处理POST /ws/answers/save HTTP/1.1 Host: www.wjx.cn Content-Type: application/json;charsetUTF-8 Origin: https://www.wjx.cn Referer: https://www.wjx.cn/vm/xxxxx.aspx User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 ... Cookie: PHPSESSIDxxxxx; tokenxxxxx几个核心字段挨个说Host目标服务器域名确认请求发往了正确的主机。Content-Type本次请求体的格式这里是 JSON说明答案数据是结构化传输的。Origin和Referer这两个字段标识请求来源。平台可以通过它们校验请求是否来自合法页面也是常见的防跨站攻击手段。分析这两个字段能帮你理解为什么直接拿 curl 重放请求有时候会失败。User-Agent浏览器环境和操作系统的标识。某些接口会用 UA 做简单的设备适配伪装 UA 也是抓包重放时一个常见的调整项。Cookie登录态和会话标识。提交问卷时如果要求登录这个字段通常携带了用户身份信息。再看请求体典型结构像这样{ surveyId: 12345678, submitTime: 2025-01-12 15:32:08, answers: [ { questionId: q1, type: radio, value: 2 }, { questionId: q2, type: multi, value: [1, 3] }, { questionId: q3, type: fill, value: 这是一段文本回答 } ], elapsedSeconds: 156 }这里值得琢磨的是几个细节。surveyId是问卷的标识answers数组是按题目顺序排列的答案集合elapsedSeconds是完成时长。平台后端通常会拿elapsedSeconds做填答质量的初步判断比如你三分钟前刚打开问卷提交时却说花了 1 秒填完这种异常样本就很容易被识别。这也是我特别提醒不要写自动化脚本灌量的原因平台的风控逻辑远比想象中复杂。响应部分通常是这样{ code: 0, message: 提交成功, data: { submitId: abcdef123456, redirectUrl: https://www.wjx.cn/thanks.aspx?sid12345678 } }code是业务状态码0 代表成功data.submitId是本次提交的唯一标识后续如果要查答疑卷数据这个 ID 可能是排查线索data.redirectUrl是提交成功后前端应该跳转的页面。读懂这些字段后你会发现排查问题就变成了简单的流程看状态码 - 看错误消息 - 看具体字段几乎不用再盲目猜。4. 抓包数据的进阶分析技巧4.1 从请求中分析参数传递与状态机制很多人抓包就停留在“看到请求了”这个层面其实后续的参数分析才是最有价值的。我在拿到抓包结果后通常会做几件事。先梳理参数之间的依赖关系。页面加载时返回的题目配置里通常会包含一个pageId或sectionId之类的参数这个参数会作为后续提交接口的入参。如果中间断掉了依赖链比如本地测试时直接拿一个旧的pageId去提交服务端大概率会拒绝。理解这种参数依赖能帮助你判断接口是不是存在前后逻辑校验。然后是观察 cookie 和 token 的变化。正常答题过程中服务端可能会下发多个 set-cookie 指令或者前端 JS 会在本地生成 token 并在后续请求中携带。我在分析时会把一次完整会话中所有请求的 cookie 变化记录下来看看到底是哪个环节开始需要认证。这在你排查“为什么我手动重放请求时总是 403”时特别有用。最后是看平台的风控痕迹。这不是教你绕过风控而是帮你理解系统的复杂度。我观察到问卷平台在提交接口前后经常有行为采集请求比如记录移动轨迹、点击热区、页面停留时长等。看到这些不用惊讶保持正常用户行为就是最好的配合。4.2 用 Wireshark 做网络性能与连接层分析如果问卷页面加载慢Charles 能看到每个请求的响应时间但看不到网络底层的握手、重传和排队。这时候就该 Wireshark 上场了。用 Wireshark 看网络性能核心是抓住几个指标TCP 三次握手耗时从 SYN 到 ACK 的时间反映客户端到服务器的网络延迟。TLS 握手耗时从 Client Hello 到 Finished 的时间反映握手过程中证书链校验、密钥协商的耗时。请求间隔页面在并行加载多个资源时是否存在串行等待。实操时先确认 Wireshark 抓取的网卡正确然后设置过滤条件比如目标是www.wjx.cn可以用tcp.host www.wjx.cn或者更直接的在抓包时只保留常用端口减少噪声tcp.port 443 || tcp.port 80再按方向排个序找到你想分析的那次 TCP 连接右键选择 Follow TCP Stream就可以看到从建立连接到断开的完整过程。通过 Statistics 菜单下的 Time Sequence Graph能直观看到数据包的时序关系快速定位到是否存在明显的延迟空洞。我自己的经验是应用层问题先看 Charles传输层问题才看 Wireshark两个工具配合起来才能搞定全链路分析。只用一个工具往往会漏掉一半信息。4.3 断点调试与请求修改的合法用法Charles 的 Map Remote、Breakpoints 和 Rewrite 功能很适合做本地调试。合法的用法是这样的你负责开发或测试一个问卷相关的应用联调时需要模拟后端返回异常数据、模拟延迟、验证前端容错能力。这时候通过断点把响应改了让前端展示异常状态是一件完全正当的测试工作。断点调试的操作思路是这样的先选中目标请求右键开启 Breakpoints。重新触发一次该请求Charles 会自动在请求发出前和响应返回前暂停。在断点编辑界面修改请求参数或响应内容。继续执行观察页面表现。我做过一个很典型的测试把响应里的code改成非 0然后让前端弹出错误提示验证交互逻辑是否完善。这种操作只针对自己控制范围内的测试场景不会对真实用户造成任何影响。要特别强调一点断点修改请求参数来伪造提交内容这是非常敏感的操作只可以在自己搭建的测试问卷上做。真实的问卷平台有严格的安全校验你改了参数服务端不一定接受但就算技术上可行越权的尝试本身就是不应该做的事。5. 常见问题与排查技巧5.1 为什么明明打开了抓包工具却抓不到请求这是被问得最多的一个问题。抓不到请求原因通常集中在代理设置、目标流量、证书信任、App 不走代理这四类。先说代理设置。Charles/Fiddler 的默认端口是 8888如果你用手机抓包要确保手机 WiFi 代理确实指向了电脑 IP并且在同一个网段。电脑抓包时还要留意系统代理是否被其他应用修改。Windows 上频繁切换代理时很容易出现设置没生效的情况。再看目标流量。如果你用的是 Wireshark它默认抓所有网卡的所有流量你需要在过滤栏中输入目标地址否则光靠肉眼找几百上千条数据包确实容易漏掉关键请求。然后是证书信任。HTTPS 解密失败是最常见的原因之一。如果你用的是一台刚重装的电脑或者手机上安装了新版本 App很可能是新环境下证书没有被信任。安卓 7.0 之后用户证书默认不受系统信任很多 App 根本不会把请求交给 Wireshark 这种底层抓包工具处理。我在测试时经常用这招打开手机浏览器访问一个普通网页看 Charles 里面有没有流量。如果网页流量都看不到说明代理链路有问题跟具体 App 无关。我给新手一个排查顺序先用电脑浏览器打开任意 HTTP 网站确认 Charles 能看到 HTTP 明文请求再打开 HTTPS 网站确认证书解密正常最后才进入 App尝试抓包。每一步都能看到数据才能进入下一步排查。5.2 HTTPS 解密失败与证书报错的处理抓包时最常见的报错是 SSL 相关比如SSLHandshake: Remote host closed connection during handshake或者The certificate for this server is invalid。出现这类问题我一般按下面几步排查确认证书已经安装并被信任这一步是 90% 问题的根源。检查 Charles/Fiddler 的 SSL Proxying Settings 里是否包含了目标域名没有通配符且没加域名就会漏掉。确认系统时间准确。手机或电脑的系统时间不准确会导致证书有效期校验失败这是很多新手根本想不到的坑。检查目标服务器是否开启了证书固定Certificate Pinning。一些安全要求高的 App 会把服务器证书的指纹直接写死在客户端代码里中间人证书即使被系统信任也会被应用层拒绝。如果遇到证书固定唯一正规的应对方式是拿到开发团队提供的调试包或者让开发在测试环境关闭证书校验。不要尝试去破解 App 的证书校验逻辑这是高风险的越界操作而且很不值得。5.3 响应内容乱码或压缩数据怎么处理抓到的接口响应乱码多数时候不是数据有问题而是内容被压缩了。HTTP 压缩机制下服务器会把响应体用 gzip 或 deflate 压缩后再传给客户端。Charles 和 Fiddler 这类代理工具通常会自动解压但如果你用 Wireshark则默认看到的是压缩后的原始字节流直接看会是一堆乱码。解决方法是在用 curl 重放请求时显式加上解压参数curl -H Accept-Encoding: gzip, deflate, br --compressed https://www.wjx.cn/xxx另外还要注意字符集。响应头里如果有Content-Type: application/json;charsetUTF-8但浏览器或工具却按 GBK 解析也会有乱码。我处理这类问题时会先确认Content-Type里的 charset 字段再确认页面源码里的 meta 标签两者一致才不会出错。5.4 请求重放与复现时容易踩的坑有些同学抓包成功后喜欢直接把请求复制出来用 curl 重放方便反复测试。这个思路本身没问题但有三个常见的坑。第一是缺 Cookie。重放请求时必须带上完整的 Cookie包括会话 ID 和登录态。最简单的做法是右键 Charles 里的请求选择 Copy cURL Request这样工具会自动把所有请求头都复制出来包含 Cookie。第二是有效期问题。接口请求中经常会有时间戳或一次性 token服务端会校验时间差。你抓包拿到的是当时的时间戳隔一分钟再重放可能就会因为超时被拒绝。处理方法是把时间戳改成当前时间再重新计算签名。第三是 HTTP 版本问题。很多 CDN 已经支持 HTTP/2而 curl 默认可能使用 HTTP/1.1。某些服务端会根据 HTTP 版本返回不同内容导致重放结果不一致。加上--http2参数就能与浏览器行为靠齐。我把这个流程整理成一个检查清单检查项操作方法作用请求头完整性直接复制 cURL 命令避免遗漏 Cookie、Referer、Origin时间戳更新重放前替换 timestamp避免因超时被服务端拒绝HTTP 版本加 --http2 参数对齐浏览器请求方式请求体编码注意 URL 编码避免中文参数乱码这里要说一句请求重放是用来做开发调试和问题复现的目的是验证“为什么这条请求会失败”。如果在真实问卷上反复重放提交接口会造成垃圾数据也违反平台规则千万不要做。6. 从抓包结果反推问题根因的经验最后分享一个典型的排查案例很能说明抓包分析的价值。我这边有一次测试问卷提交后迟迟没有跳转到感谢页后台数据显示答卷已经收到但前端总是在提交接口返回后卡住。我没有急着看代码而是把抓包结果里提交接口前后的所有请求按时间线排列出来。发现提交接口本身返回很快状态码是 200响应体也正常但紧随其后前端发起了一个获取问卷剩余提交次数的请求这个接口返回了 500。再往下查发现是我配置的某个自定义字段格式有误导致服务端在拉起统计信息时报错。整个问题根源根本不在核心提交链路而在一个旁路接口上。这个案例里抓包的价值在于它把问题从“提交失败”这种模糊描述精确定位到了“提交成功但后续统计接口异常”这个具体环节。如果是盲目翻代码很可能盯着提交接口看半天也找不到原因因为你根本不知道问题出在旁路接口上。还有一次性能排查也很有意思。用户反馈在某个网络环境下打开问卷特别慢Charles 显示的请求耗时并不高。后来我用 Wireshark 看了一下 TCP 连接发现大量数据包存在重传说明是无线网络丢包严重导致的慢而不是服务端问题。这类结论仅靠应用层抓包工具是得出来的。做抓包分析这几年我最大的体会是不要把它当成一门“黑客技术”来学它就是网络调试的一双眼睛。懂一点 TCP/IP、懂一点 HTTP 协议、会看请求和响应的字段遇到问题的时候用这双眼睛死盯链路很多问题根本不需要猜数据会告诉你答案。想入门的同学我建议从最简单的场景开始练起创建一个测试问卷打开抓包工具填一遍提交一遍把过程中的每个请求都点开看一遍。连续做三次你对 HTTP 请求的感觉就会完全不一样。下次再遇到问卷提交失败、页面加载缓慢你不再是一个对着屏幕干瞪眼的人而是一个拿着抓包结论可以直接开干的人。