在移動(dòng)應(yīng)用開發(fā)、接口聯(lián)調(diào)、性能分析以及網(wǎng)絡(luò)異常排查中，移動(dòng)端抓包是最重要也是最常用的技術(shù)手段之一。無論是 iOS 還是 Android，移動(dòng)端網(wǎng)絡(luò)協(xié)議正在變得越來越復(fù)雜：HTTPS 全面普及、HTTP/2/HTTP/3 使用增多、證書 Pinning 成為常態(tài)、App 內(nèi)部自定義協(xié)議不斷出現(xiàn)。這些變化導(dǎo)致開發(fā)者常遇到一個(gè)問題：
“為什么移動(dòng)端抓包這么難？代理明明開了，卻抓不到包?！?/strong>
這不是工具的問題，而是移動(dòng)端網(wǎng)絡(luò)本身的特性決定的。
要解決移動(dòng)端抓包難題，一定需要 分層工具協(xié)同：代理 + 協(xié)議分析 + 底層補(bǔ)抓，而不是依賴某一種軟件。
一、為什么移動(dòng)端抓包比 PC 抓包更困難？
移動(dòng)端抓包之所以困難，主要因?yàn)榫W(wǎng)絡(luò)鏈路復(fù)雜、協(xié)議多樣、安全策略嚴(yán)格。
HTTPS 證書鏈嚴(yán)格，只要鏈不完整就無法解密
表現(xiàn)：
- Charles 看到 CONNECT
- 明文 HTTPS 看不到
- App 報(bào) SSL 錯(cuò)誤
iOS/Android 都對(duì)證書鏈極其敏感。
App 普遍使用證書 Pinning（最高頻原因）
特征：
- 瀏覽器能抓
- App 完全抓不到
- 代理工具界面干干凈凈
Pinning 直接拒絕代理證書，所有代理類抓包工具統(tǒng)統(tǒng)失效。
HTTP/3 / QUIC（UDP）繞過所有代理工具
移動(dòng)端大量接口開始使用 QUIC。
代理工具抓不到的常見原因：
- QUIC 流量天然不走 TCP
- 視頻 / 動(dòng)態(tài)流媒體 / 熱點(diǎn) API 常用 QUIC
- Wireshark 可以看到 UDP，但代理工具沒有請(qǐng)求
App 可能使用 WebSocket 或自定義 TCP 協(xié)議
大量 SDK 和業(yè)務(wù)邏輯采用自定義協(xié)議，絕不會(huì)走系統(tǒng) HTTP 代理，因此：
- Charles / Fiddler 全部無效
- tcpdump 能看到二進(jìn)制流
- 流量分析需要底層工具
系統(tǒng)代理容易被覆蓋
包括：
- VPN
- 安全軟件
- MDM 網(wǎng)絡(luò)策略
- Wi-Fi 企業(yè)代理
代理失效，自然抓不到包。
二、移動(dòng)端抓包軟件的分類（按分工，而不是誰好誰壞）
只有分層使用才能覆蓋所有網(wǎng)絡(luò)場景。
① 代理類抓包工具（第一層）
常見：
- Charles
- Proxyman
- Fiddler
- mitmproxy
適用于：
- 解密 HTTPS
- 調(diào)試接口
- 修改請(qǐng)求與響應(yīng)
不適用于：
- Pinning
- QUIC
- 自定義協(xié)議
② 協(xié)議層抓包工具（第二層）
包括：
- Wireshark
- tcpdump
用途：
- 分析 TLS 握手
- 判斷丟包重傳
- 查看是否走 UDP/QUIC
- 判斷是否發(fā)起請(qǐng)求
疑難網(wǎng)絡(luò)問題必須回到協(xié)議層。
③ 自動(dòng)化抓包工具（第三層）
如：
- pyshark
- scapy
- mitmproxy scripting
適用于實(shí)驗(yàn)室和 CI 環(huán)境。
④ 底層補(bǔ)抓工具（關(guān)鍵的第四層）
當(dāng)代理工具完全失效時(shí)，需要“非代理”抓包方式。
抓包大師（Sniffmaster）在移動(dòng)端抓包體系中的作用
Sniffmaster 的實(shí)際功能：
- 捕獲 HTTPS / HTTP / TCP / UDP
- 自動(dòng)分析協(xié)議類型（mdns、HTTPS、HTTP 等）
- 按 App / 域名過濾，解決“噪音太大”的問題
- 查看數(shù)據(jù)流的多種格式（HEX / 文本 / 二進(jìn)制）
- 提供 JavaScript 攔截器，可修改請(qǐng)求/響應(yīng)
- 支持導(dǎo)出 Wireshark 可讀取的 pcap 文件
- 跨平臺(tái)支持 macOS / Windows / iOS
能夠覆蓋代理軟件抓不到的場景：
- App 啟用 pinning
- QUIC / HTTP3
- 自定義 TCP 協(xié)議
- 系統(tǒng)代理失效
- HTTPS 握手異常排查（配合 Wireshark）
它不是替代 Charles，而是成為移動(dòng)端抓包體系中不可或缺的“底層補(bǔ)抓層”。
三、移動(dòng)端抓包完整流程（適合直接寫進(jìn)團(tuán)隊(duì) Wiki）
① 首先使用代理工具抓包（能抓就繼續(xù)）
包括 Charles / Proxyman / Fiddler。
如果可以看到 HTTPS 明文 → 說明代理正常。
② 如果只有 CONNECT → 證書鏈問題
檢查：
- 證書是否被完全信任
- Wi-Fi 是否插入中間證書
- ATS 是否拒絕證書
③ Safari 能抓 App 抓不到 → 證書 Pinning
這是代理抓不到包的最典型場景。
④ 某些接口抓不到 → QUIC / HTTP3
驗(yàn)證：
- 禁用 QUIC
- 切換網(wǎng)絡(luò)
- Wireshark 查看是否走 UDP
⑤ 代理完全無效 → 用 Sniffmaster 抓底層流量
補(bǔ)抓步驟：
- 在 Sniffmaster 選擇 App 或域名過濾
- 捕獲 HTTPS/TCP/UDP 原始數(shù)據(jù)流
- 導(dǎo)出 pcap 文件
- 在 Wireshark 分析 TLS 握手、協(xié)議類型、錯(cuò)誤碼
- 確定根因：Pinning？QUIC？自定義協(xié)議？鏈路異常？
- 若需要，繼續(xù)使用代理工具做業(yè)務(wù)調(diào)試
這是解決移動(dòng)端抓包疑難問題最有效的方式。
四、工程案例：移動(dòng)端 App 一直抓不到包
表現(xiàn)：
- Charles 無流量
- 證書已信任
- Wi-Fi 切換無變化
排查步驟：
- Charles 設(shè)置無問題
- Safari 可抓 → proxy 有效
- App 無流量 → 懷疑 pinning
- 使用 Sniffmaster 攔截流量
- Wireshark 發(fā)現(xiàn) TLS Alert: unknown_ca
- 后端日志無對(duì)應(yīng)請(qǐng)求
- 最終確認(rèn)：App 啟用了證書指紋校驗(yàn)
只有通過底層抓包才找到真正原因。
移動(dòng)端抓包可以采用多工具組合
| 抓包層級(jí) | 工具 | 作用 |
|---|---|---|
| 代理層 | Charles / Fiddler / Proxyman | 常規(guī) HTTPS 抓包 |
| 協(xié)議層 | tcpdump / Wireshark | TLS、QUIC、TCP 問題定位 |
| 自動(dòng)化層 | pyshark / scapy | 自動(dòng)化測試與統(tǒng)計(jì) |
| 補(bǔ)抓層 | 抓包大師（Sniffmaster） | pinning / QUIC / 自定義協(xié)議 |
單一軟件永遠(yuǎn)無法覆蓋移動(dòng)端所有場景，多工具協(xié)同是唯一解決方案。
