网站post抓包怎么找发送手机验证码的那个数据请详细解释下另外易

先打开你要测的那个网站，按F12调出开发者工具，切到Network（网络）面板，顺手勾上Preserve log（保留日志），这个选项特别重要，不然页面一刷新，前面的请求就全被清空了。再把Filter输入框旁边的类型筛选点成Fetch/XHR，因为验证码这种异步请求基本都是走ajax，过滤掉图片、样式这些乱七八糟的东西，看起来清爽得多。

准备工作做完了，在页面上找到那个输入手机号、点“获取验证码”的按钮。先别急着点，留意一下Network面板下方的状态，现在应该是空的或者只有几个静态资源，心里有个数。然后输入你的手机号，点一下那个按钮，眼睛盯着Network面板，你会看到唰地一下蹦出来好几个新请求，别慌，这时候需要做的就是甄别哪个才是真正发验证码的。

一般这种请求的URL里多少带点端倪，像sms、sendCode、captcha、verifyCode、mobile、phone这类英文词都是高频关键词，点开每个请求看一眼，右键复制它的URL，或者直接看Request URL那行，一眼扫过去基本就能锁定个大概。如果URL看不出来，那就看请求体里带没带你的手机号，几乎可以确定哪个请求里躺着你的手机号，哪个就是真身。还有个小技巧，看请求的Method，发送验证码绝大多数是POST，因为GET会把手机号怼在URL上，不太安全，当然也有个别网站图省事用GET的，但主流还是POST。

锁定目标后，点开这个请求，先看Headers标签，重点看Request Headers里的Content-Type，这决定了参数得按什么格式提交。如果看到application/json，那参数就在Payload标签里躺着，是一段JSON格式的字符串，大括号包着的那种，里面写着你刚输入的手机号，还有可能有一堆乱七八糟的字段，比如uuid、clientType、source、scene、sendType什么的，这些别管它们是干什么的，发送验证码的时候会一并提交过去，服务器那边用来做风控或者记录行为的。

如果Content-Type是application/x-www-form-urlencoded，那参数就在Request Payload或者Form Data里，是一串key=value&key2=value2这样格式的东西，像手机号、时间戳、随机字符串这些都有可能混在一起。还有一种情况是multipart/form-data，这个在验证码接口里不多见，遇到了就当长见识。

看完响应的预览，也就是Preview标签，点开看看里面返回什么，一般会有类似code、message、data这样结构的JSON，code为0说明发送成功，非0就是失败，失败信息往往就在message里直接告诉你，比如“验证码发送过于频繁”，这一块方便你判断自己到底有没有把那个请求找对。

还有一个值得观察的地方是请求之前页面可能还发了一个前置请求，比如先调了个接口取验证码倒计时时间，或者先申请了个签名token，这种请求也可以顺藤摸瓜找到，因为点击按钮的瞬间会同时发起多个请求，排列在发送验证码请求之前的那几个往往就是它的前置准备工序。

实际操作中遇到不易找的情况也很正常，比如网站把请求加密了，参数里有sign或者encrypt这样的字眼，一坨乱码看不出结构，这多半是JS混淆加再RSA或MD5摘要，到了这一步再去抠JS逆向工程量就大了，但如果只是想定位提交地址，完全够用。发出去的包里居然带着一堆base64字符串或编码后的数据，也不必慌张，通讯流程倒推回去，那串东西解开往往就是明文，用在线工具或者Node跑一段atob、decodeURIComponent就能看到本来的面貌。

多试几个网站，多拿几个真实案例练手，你会发现套路都是相通的，无非就是抓包、过滤、找真身、看参数，熟练了以后几十秒就能定位得死死的，真正麻烦的是碰到参数加密，但那已经是深水区的事了，跟找接口是两个维度的课题。先学会走，再学跑。