假如你在做前后端联调或安全审计时发现某个 App 或小程序总在后台偷偷发送请求频率不高但动作很固定像一只蹑手蹑脚的小猫咪不声不响却一直在活动。要弄清楚它到底在传输什么、什么时候传、传给谁最直接的办法就是抓包。这篇教程就以“抓包一只鬼鬼祟祟的小猫咪”为主线从抓包原理开始逐步拆解 HTTP/HTTPS 抓包、手机代理配置、Wireshark 过滤分析、tcpdump 抓包等完整流程。文章会覆盖常见抓包工具的特点、抓不到包的排查思路以及如何判断一段流量是否可疑。适合刚开始接触抓包的开发者也适合需要做接口联调、网络排障和客户端安全分析的同学。1. 什么是“鬼鬼祟祟的小猫咪”1.1 抓包的一句话解释网络通信本质上是一台设备向另一台设备发送数据包数据包经过网卡、路由器、交换机等网络节点最终到达目标服务器。抓包就是在数据包经过的某个位置把它复制一份再按照 TCP/IP 协议栈逐层解析还原出 HTTP 请求、DNS 查询、TLS 握手等具体内容。所谓“鬼鬼祟祟的小猫咪”其实就是那些不像正常接口一样清晰可见的网络行为。例如某个应用在用户不知情的情况下每隔一段时间上传一次设备信息某个小程序页面未操作时却向第三方域名发送统计请求甚至一个开发同学临时加的调试日志接口部署到生产环境后仍在持续上报数据。这些行为不会在主界面上留下明显痕迹但网络层不会说谎。抓包可以把这些隐藏动作原原本本暴露出来。1.2 为什么应用会“偷偷”发请求一个应用发起网络请求的原因很多常见的有请求类型典型行为是否容易引起注意业务接口用户点击按钮后拉取数据容易用户有操作心跳保活定时通知服务器当前在线较隐蔽用户无感知统计上报上报启动次数、页面停留时长较隐蔽通常需要分析日志广告 SDK拉取广告配置、上报曝光隐蔽且常与业务请求混在一起崩溃日志发生异常后上传堆栈信息隐蔽仅在异常后触发定位服务周期性上报地理位置隐蔽依赖系统权限这些请求不一定都是恶意的很多只是产品功能的一部分。但在排查异常耗电、流量消耗、数据合规问题时我们必须先知道应用在做什么然后才能判断是否合理。抓包就是识别这些行为的起点。1.3 适合用抓包解决的典型问题前端说“接口已经调用了”后端却看不到请求需要确认请求是否真的发出。接口返回数据正常但页面展示不一致需要对比请求参数和响应内容。App 版本升级后出现网络异常需要确认访问的是哪个域名和 IP。需要梳理一个第三方 SDK 在启动后到底请求了哪些接口。怀疑应用存在后台静默上传行为需要找到对应域名和请求频率。在这些场景中抓包工具能帮我们快速建立“请求 - 参数 - 响应”的完整链路再结合代码逻辑定位问题。2. 环境准备与抓包工具选型2.1 常用抓包工具怎么选抓包工具种类很多要根据场景选择。下面是几类常见工具的横向对比工具抓包原理擅长场景适合人群Wireshark网卡镜像抓包分析 TCP 层、DNS、TLS 握手等底层协议网络工程师、后端排查Fiddler ClassicHTTP 代理Windows 平台抓 HTTP/HTTPS方便查看请求参数Web 前端、客户端开发CharlesHTTP 代理macOS/Windows 抓包手机代理配置友好前后端联调、移动端开发Burp SuiteHTTP 代理Web 安全测试、渗透测试中的请求改包重放安全测试工程师tcpdump命令行抓包服务器端离线抓包资源占用小运维、后端应急排障WhistleHTTP 代理前端调试、Mock 数据、代理规则灵活前端工程师mitmproxyHTTP 代理命令行交互可编写 Python 脚本自动化分析自动化测试、安全分析如果只是排查浏览器请求Fiddler 和 Charles 都很方便如果需要分析 DNS 解析过程和 TCP 连接建立细节Wireshark 更合适如果问题发生在服务器上tcpdump 是首选因为它不依赖图形界面也方便直接保存 pcap 文件。2.2 本文演示环境本文示例以常见环境为主具体版本可以根据实际情况调整操作系统Windows / macOS / Linux 均可抓包工具Fiddler Classic、Charles、mitmproxy、tcpdump、Wireshark测试设备一台 Android 手机或 iPhone与电脑处于同一局域网测试目标一个会周期性发送后台请求的测试 App不同版本的抓包工具界面会有差异但代理端口和证书安装思路是通用的。下面以 Fiddler 和 Charles 为例演示配置重点是理解整个流程而不是死记按钮位置。2.3 开启电脑端代理Fiddler 和 Charles 都工作在代理模式下需要在电脑端开启代理监听让手机或其他设备的请求先经过抓包工具再由抓包工具转发到目标服务器。Fiddler Classic 开启远程连接的方式打开 Fiddler点击菜单栏Tools - Options。切换到Connections标签页。勾选Allow remote computers to connect。确认代理端口为8888点击OK。重启 Fiddler 使配置生效。Charles 开启代理的方式打开 Charles点击菜单Proxy - Proxy Settings。勾选HTTP Proxy端口默认8888。点击OK。为了抓取 HTTPS 请求还需要在Proxy - SSL Proxying Settings中开启 SSL Proxying并添加需要解密的域名。手机端需要连接同一个 WiFi并将 WiFi 代理设置为电脑的局域网 IP 和对应端口。设置完成后再打开任意网页抓包工具里应该能看到请求日志。如果什么都看不到最常见的原因就是手机和电脑不在同一网段或者电脑防火墙拦截了代理端口。3. 抓包核心原理拆解3.1 HTTP 为什么可以直接抓HTTP 协议的数据是明文传输的。代理工具收到客户端请求后可以直接读取请求行、请求头和请求体不需要额外解密。所以在 Fiddler 或 Charles 中抓 HTTP 请求几乎不需要额外配置。但现代应用为了提高安全性已经大规模启用 HTTPS。HTTPS 在 HTTP 和 TCP 之间加入了 TLS 加密层代理工具不能再直接看到明文内容需要通过证书信任的方式完成解密。3.2 HTTPS 抓包是“中间人代理”HTTPS 抓包的核心思路是中间人代理。抓包工具会扮演目标服务器的角色与客户端建立一条 TLS 连接同时抓包工具又会扮演客户端的角色与真实服务器建立另一条 TLS 连接。两条连接都由抓包工具中转所以它能解密客户端发来的数据也能解密服务器返回的数据。为了让客户端信任抓包工具伪造的证书我们需要把抓包工具生成的根证书安装到测试设备中。设备信任该根证书后抓包工具就可以为任意域名动态签发证书HTTPS 流量得以解密。这里必须强调边界抓包只应该用于你自己负责的设备、接口或已经获得充分授权的测试环境中。不要随意在他人设备上安装证书更不要利用抓包工具窃取账号、绕过认证或获取未授权数据。证书安装后抓包工具能读取所有被代理的 HTTPS 明文数据这是非常强的能力必须慎用。3.3 代理抓包与网卡镜像抓包的区别代理抓包和网卡镜像抓包是两种不同思路对比项代理抓包网卡镜像抓包工作位置应用层代理网络接口层对客户端要求需要设置代理并信任证书不需要修改客户端数据包原本就经过网卡能否看 HTTPS 明文配置证书后可以只能看到 TLS 加密后的内容除非单独解密典型工具Fiddler、Charles、WhistleWireshark、tcpdump优点方便查看请求和响应细节能捕获不经过系统代理的流量缺点客户端不走代理时抓不到分析 HTTPS 明文比较困难实际工作中两种方式经常配合使用。先用代理抓包定位应用层问题再用 Wireshark 或 tcpdump 分析底层握手、DNS 解析和连接异常。3.4 抓不到包的常见原因抓包失败通常不是工具坏了而是流量根本没有经过代理或者经过代理但客户端不信任证书。常见原因包括手机没有设置代理或者代理 IP、端口错误。电脑和手机不在同一个局域网。防火墙拦截了代理端口。应用不使用系统代理自行建立 TCP 连接。HTTPS 证书未安装客户端拒绝了代理证书。App 使用 WebSocket 或自定义 TCP 协议普通 HTTP 代理无法解析。理解这些原因后再遇到抓包失败就能按方向排查而不是反复重启工具。4. 实战抓住那只偷偷上传数据的小猫咪4.1 场景设计假设我们要排查一个测试 App。它是公司内部开发的版本界面非常简单但我们怀疑它每隔一段时间会向一个陌生域名发送数据。现有线索是手机开启飞行日志后能看到该 App 存在周期性网络活动。整个排查目标如下找到 App 访问的完整域名和 URL 路径。确认请求间隔和时间规律。查看请求头中携带了哪些信息。分析请求体是否包含敏感字段。判断这个域名是不是业务方预期的服务器。为了便于演示我们把目标域名写成api.example-labs.comApp 每隔 30 秒向/v1/heartbeat发送一个 POST 请求。实际项目中替换成真实域名即可。4.2 用 Fiddler 抓取 HTTPS 请求先启动 Fiddler并开启远程连接。然后将手机代理指向电脑 IP192.168.1.100端口8888。在手机浏览器访问http://192.168.1.100:8888下载并安装 Fiddler 的根证书。安装完成后打开测试 App观察 Fiddler 会话列表。正常情况下Fiddler 会持续出现来自手机的新会话。为了只保留目标域名的请求可以在 Fiddler 左下角的过滤区域设置Filter: api.example-labs.com或者在会话列表顶部使用Find搜索example-labs快速定位相关请求。双击一条/v1/heartbeat请求可以在右侧 Inspector 面板中看到请求方法POST请求域名api.example-labs.com请求路径/v1/heartbeatUser-Agent包含 App 名称和版本信息请求体一串 JSON 数据这串 JSON 可能就是关键线索。把请求复制出来内容大致如下{ device_id: a1b2c3d4e5, app_version: 1.2.3, timestamp: 1700000000000, location: 116.397,39.908, user_id: u_10086 }这个例子中请求携带了定位信息、设备 ID 和用户 ID。如果产品不需要定位功能那这个请求就非常可疑后续需要回到代码里确认来源。4.3 用 Charles 抓取同样流量如果换到 macOS 环境Charles 是更方便的选择。开启 Charles 后手机设置代理指向电脑 IP端口8888。抓 HTTPS 前需要先安装 Charles 根证书。安装证书操作如下手机连接代理后浏览器访问http://chls.pro/ssl。下载 Charles 根证书。在系统设置中安装并信任该证书。在电脑端 Charles 的Proxy - SSL Proxying Settings中添加*表示解密所有 HTTPS 请求。完成后再启动 App可以在 Charles 的Structure视图中看到按域名分组的请求列表。右键目标域名选择Focus可以只关注该域名的会话方便后续分析和导出。4.4 用 tcpdump 抓取非 HTTP 流量代理抓包只能处理应用层 HTTP/HTTPS 流量。有些 App 不设置系统代理直接通过原始 Socket 发送数据这种情况下 Fiddler 和 Charles 都会失效。此时可以在手机端或服务器端使用 tcpdump 抓取全量数据包。如果目标设备是 Linux 服务器可以直接在服务器上抓包。假设服务监听在eth0网卡需要抓取来自 App 服务器的流量可以执行sudo tcpdump -i eth0 -s 65535 -w app_traffic.pcap -nn host 192.168.1.100参数含义参数说明-i eth0指定抓包网卡-s 65535每个数据包最多抓取 65535 字节防止截断-w app_traffic.pcap保存为 pcap 文件供 Wireshark 打开-nn不解析域名和端口名保持数字输出host 192.168.1.100只抓与该 IP 通信的包对于 Android 设备如果已经 root也可以使用 tcpdump。不过更稳妥的做法是在测试路由器上做端口镜像或者使用 mitmproxy 配合透明代理模式。抓包前记得确认操作环境已获得授权避免影响正常业务。抓完数据后使用 tcpdump 直接查看几条包sudo tcpdump -r app_traffic.pcap -nn -c 20输出会包含 IP、端口、TCP 标志位等信息可以初步判断连接是否建立、是否使用了非标准端口。4.5 用 Wireshark 分析 DNS 和 TLSpcap 文件最适合用 Wireshark 做深入分析。打开 Wireshark加载app_traffic.pcap后可以先看 DNS 请求。因为 App 发起任何网络请求前通常都会先解析域名DNS 查询记录能告诉我们它试图访问哪些域名。在 Wireshark 的过滤器栏输入dns.qry.name contains example-labs如果存在对应 DNS 查询会显示目标域名和解析出的 IP 地址。接着过滤该 IP 的流量ip.addr 203.0.113.10再继续分析 TCP 和 TLS 握手。对于 HTTPS 流量在 Wireshark 中默认无法直接看到解密后的 HTTP 内容除非提供 TLS 密钥。如果只是想确认请求域名和 IP可以查看 TLS 握手中的 Server Name Indication 字段tls.handshake.extensions_server_name contains example-labs这个字段会显示客户端在 TLS 握手中声明的目标域名即使后续数据加密也能确认连接指向。4.6 结果解读结合 Fiddler、Charles 和 Wireshark 的数据我们可以整理出可疑请求的关键信息维度抓包结果域名api.example-labs.comIP203.0.113.10请求路径/v1/heartbeat请求频率每 30 秒一次请求方法POST请求体字段device_id、user_id、location、timestampUser-AgentDemoApp/1.2.3 (Android)当这些信息完整呈现后再去对照业务代码。如果业务代码中根本没有这个接口或者产品需求中没有定位上传逻辑那这条流量就是典型的“小猫咪”。可以进一步和运维同学确认该域名是否归属公司或使用 whois 查询域名注册信息判断是否是第三方 SDK 或异常外联域名。5. 手机、小程序抓包的常见问题与排查5.1 抓不到包的原因总览抓包过程中最常见的三个字就是“抓不到”。许多初学者会把问题归结于手机不好使但实际上大多数情况是代理配置或证书信任问题。问题现象常见原因解决思路电脑能上网手机设置代理后无法上网代理地址或端口错误防火墙拦截检查电脑局域网 IP关闭防火墙或放行代理端口能打开网页但抓不到 App 请求App 不走系统代理尝试 mitmproxy 透明代理或在路由器做镜像抓到的请求都是 CONNECT看不到内容未安装根证书HTTPS 无法解密在测试设备安装并信任抓包工具根证书手机浏览器提示“连接不是专用连接”证书未被信任或证书域名不匹配为测试设备导入根证书不要在生产设备忽略警告App 接口在 Android 7.0 以上抓不到系统默认不信任用户证书在测试环境使用调试包或让开发同学调整网络安全配置抓包工具卡顿或崩溃流量过大过滤条件没设置先使用过滤规则缩小范围再开始抓包5.2 证书信任与 Android 系统限制Android 7.0 之后系统默认不再信任 App 层安装的用户证书。这意味着即使手机已经安装了 Fiddler 或 Charles 的根证书很多 App 的 HTTPS 请求依然会握手失败表现为连接中断或抓不到明文。在合法授权的前提下通常有三种处理方式使用内部测试环境在 App 的network_security_config.xml中允许调试环境信任用户证书。使用支持调试证书的测试包而不是发布包。在已 root 的测试设备中将证书安装到系统证书目录。这里不展开具体绕过方法因为抓包工具的定位是排查自有业务和审计授权流量而不是帮助绕过安全防护。遇到客户端做了证书校验时正确做法是反馈给开发同学让他们在测试环境提供可分析版本而不是尝试攻破生产环境的安全机制。5.3 微信小程序抓包要点微信小程序是一个高频抓包场景。小程序的网络请求基于 HTTPS正常配置代理后Charles 和 Fiddler 都能看到。但要注意几点微信小程序不一定完全走系统代理部分微信版本或 PC 端小程序需要额外设置系统代理。小程序要求服务端配置合法证书如果证书链不完整代理工具也可能显示握手失败。如果使用手机微信小程序抓包需要确保手机安装了代理根证书并且信任该证书。PC 端微信小程序的流量可能由微信进程发出抓包工具需要以管理员或 root 权限运行才能捕获其他进程的流量。建议先使用 Fiddler 或 Charles 抓一次普通网页请求确认代理环境正常然后再打开小程序页面。如果普通网页能抓小程序还是抓不到重点检查证书信任和微信的代理适配。5.4 抓包完成后记得恢复设备抓包结束后最容易被忽略的是清理工作。正确的清理步骤包括关闭手机或电脑上的代理设置恢复直连网络。在测试设备中删除 Fiddler、Charles 或 mitmproxy 的根证书。删除抓包过程中生成的 pcap 和日志文件或转移到安全位置。如果使用了 tcpdump需要CtrlC停止抓包确认没有残留进程。很多开发者抓包后忘记关闭代理导致手机无法正常上网甚至把代理配置带到生产环境引发线上请求异常。建议把“抓包后恢复设备”写进团队操作规范。6. 抓包分析如何判断一段流量是否可疑6.1 先看域名和 IP 是否正常拿到抓包结果后不要急着看请求体先看请求发往哪个域名。判断步骤比较简单搜索域名确认它是否属于当前业务方或合作方。使用 whois 查询域名注册时间、注册主体。对比 DNS 解析结果中的 IP 归属地判断是否使用了 CDN 或云厂商。如果域名是随机字符串注册时间很新且请求频率异常就要提高警惕。域名信息只能说明“这是一个真实存在的主机”不能直接证明恶意。关键还要结合请求内容和业务逻辑判断。6.2 观察请求规律“鬼鬼祟祟”的流量通常有一些规律。在一段 pcap 或代理日志中可以从时间维度分析请求是否严格固定间隔例如每 30 秒一次。请求是否只在特定页面启动后出现。请求是否在应用退到后台后仍然发起。请求体大小是否异常例如心跳包却携带几十 KB 数据。请求是否使用非标准端口或者 TLS 指纹与常见浏览器不一致。在 Wireshark 中可以通过Statistics - IO Graph绘制流量速率曲线直观看到周期性峰值。如果发现固定间隔的流量尖峰就值得继续跟踪。6.3 用脚本自动提取线索当抓包文件较大时手工点选效率太低。可以用 tshark 从 pcap 中提取关键字段。tshark 是 Wireshark 的命令行版本适合批量处理。例如提取所有 DNS 查询域名tshark -r app_traffic.pcap -Y dns -T fields -e dns.qry.name | sort | uniq -c | sort -nr输出会展示每个域名被查询的次数数量最多的域名很可能就是最主要的网络通信目标。如果需要记录代理层请求可以使用 mitmproxy 写一个很小的插件把每次请求的 URL、请求头和请求体实时写入日志。示例代码如下# addon.py import json from mitmproxy import http def request(flow: http.HTTPFlow) - None: record { url: flow.request.pretty_url, method: flow.request.method, headers: dict(flow.request.headers), body: flow.request.get_text(), } with open(requests.log, a, encodingutf-8) as f: f.write(json.dumps(record, ensure_asciiFalse) \n)运行 mitmproxy 时加载脚本即可mitmproxy -s addon.py这样不用一直盯着图形界面抓包结束后直接查看requests.log就能梳理出所有请求。脚本中可以加入过滤条件比如只记录某个域名或只记录 POST 请求减少无效数据。6.4 结合业务上下文一起判断抓包数据只是网络行为的一个切面。判断“是不是可疑小猫咪”时要把请求和业务上下文结合起来产品需求里有没有这个接口后端日志中有没有对应的调用记录请求参数是否包含超出业务范围的数据用户协议和隐私政策中是否说明了该类数据收集如果一致可能只是开发过程中遗留的统计逻辑不属于恶意行为如果不一致则需要进一步评估风险并联系对应团队确认。切忌只凭字段名称就下结论比如一个叫heartbeat的接口也可能在悄悄上报定位而一个看似可疑的接口也可能是正常功能的一部分。7. 最佳实践与工程建议7.1 抓包操作的合规红线抓包能力越强越要限制使用边界。建议遵循以下原则只抓自己负责开发的设备、服务器或接口。在测试环境进行抓包避免在生产环境大规模抓取。涉及其他团队或合作方系统时先获得授权。不允许使用抓包工具收集用户密码、验证码、支付凭证等敏感信息。抓包过程中发现的安全漏洞通过正规渠道提交不要公开利用。这些原则既是工程规范也是保护自己和团队的基本方式。7.2 证书与代理配置管理抓包用的根证书属于高权限凭证。如果证书泄漏攻击者可能用它构造恶意 HTTPS 中间人。建议项目组单独维护一套“本地调试证书”不要使用生产环境的证书体系也不要随意把证书上传到公开仓库。不同环境的代理配置建议放在独立文件中避免误提交。代理端口也建议统一规划避免多台电脑同时使用同一端口导致冲突。抓包完成后的清理步骤应写入团队文档防止设备长期暴露在代理环境中。7.3 抓包结果沉淀一次抓包不要只停留在“找到了问题”可以把结果沉淀下来保存 pcap 或 HAR 文件方便反复分析。记录请求域名、IP、证书信息形成接口资产清单。将异常外联域名同步给运维或安全团队。把抓包分析方法整理成团队模板减少重复踩坑。HAR 是 HTTP Archive 格式Fiddler 和 Charles 都支持导出。导出后可以直接交给后端同学定位问题不需要对方也装一套抓包工具。7.4 自动化抓包与持续监测对于长期运行的服务端进程手动抓包不可持续。可以结合 tcpdump 和定时任务在指定时间窗口内自动抓包并保留固定数量的 rolling 文件避免磁盘写满。例如使用 cron 每天凌晨抓取 5 分钟全量流量0 3 * * * /usr/sbin/tcpdump -i eth0 -s 0 -G 300 -W 1 -w /data/capture/daily_$(date \%Y\%m\%d).pcap核心参数说明参数含义-G 300每 300 秒轮转一次文件-W 1最多保留 1 个轮转文件-w指定输出文件路径$(date \%Y\%m\%d)文件名中携带日期在客户端侧也可以用 mitmproxy 脚本把异常请求实时推送出来。当请求命中了预设的可疑域名时直接输出告警。这样可以尽早发现线上环境是否存在异常外联。7.5 抓包与日志配合网络包解决的是“有没有请求”和“请求长什么样”的问题日志解决的是“业务层为什么会这样”的问题。排查时建议两边联动抓包发现请求未发出时看客户端日志确认代码逻辑是否执行到网络层。抓包发现请求已发出但响应超时时看服务端日志和链路追踪确认处理耗时。抓包发现请求参数异常时看代码中参数的组装过程。不要只盯着抓包工具。很多问题发生在代码逻辑、配置文件或网关路由上抓包只是帮助我们缩小范围。8. 收尾抓包是一个可以不断深入的能力。从一个陌生的周期性请求开始通过代理工具还原 HTTPS 明文通过 tcpdump 捕获底层连接再用 Wireshark 和 tshark 分析 DNS 与 TLS最终把“小猫咪”的活动轨迹完整呈现在面前。这个流程不止适用于分析可疑流量也适用于日常接口联调、App 网络排障和第三方 SDK 合规审计。下次再遇到抓不到包、请求神秘消失、后台悄悄上传数据这类问题不妨按照这篇教程的步骤走一遍先确认代理环境再解决证书信任最后用过滤和脚本把关键请求提取出来。只要你手里的工具和环境都合规网络层总会给你答案。