日常做開發的人，特別是和客戶端接口打交道的同學，應該對“抓包”這件事不陌生。
調試登錄流程、分析接口格式、排查錯誤返回、分析網絡性能、甚至研究第三方 App 的數據通信……說到底，都繞不開“抓 HTTPS 包”這一步。
而這一步，正變得越來越難。
抓包為什么越來越難？
早幾年，抓包是一件相對輕松的事。安裝個 Charles、Fiddler，或者開個 mitmproxy，設好代理、裝下證書就能抓個痛快。
但現在，各種防護機制一層套一層：
- App 開啟了證書校驗，連不上代理就拒絕聯網
- 有些還上了 HTTPS 雙向驗證（Mutual TLS），客戶端必須驗證服務端證書外還要給服務器提供自己的一套證書
- 少數 App 甚至硬編碼了 Pinning，不信任系統證書
Charles、Fiddler、mitmproxy 全部失靈。
于是我找遍了幾乎能找到的所有工具。
工具盤點：每種都有一類適配人群
1. Charles
經典老牌，不多介紹。HTTP 抓得穩，HTTPS 要繞 Pin 就麻煩了。對 mac 用戶友好，對 iOS 支持一般，證書注入限制多。
2. Fiddler
Windows 上用得多，功能強，但配置復雜。要設置代理、安裝證書，有時連抓安卓包都覺得麻煩。
3. Wireshark
底層抓包利器，但不解密 HTTPS 意義不大。更多用在網絡層調試，做協議分析不錯。
4. mitmproxy
命令行黨福音，Python 可編程。但對于圖形化用戶門檻高，部署中間人代理還是會遇到 Pin 限制。
5. Sniffmaster 抓包大師（一個偶然發現的小眾工具）
某次調試一個 iOS 上的企業應用，客戶反饋某個操作頻繁失敗，服務端日志里沒有任何記錄。
我一邊抓 Charles，一邊開 Fiddler，發現都抓不到這個 App 的 HTTPS 請求。
最后在一個討論組里看到有人提到 Sniffmaster 這個跨平臺的小工具，說插上線就能抓，沒多想就試了下。
結果讓我很驚訝：
- 插上 iPhone 設備，幾秒內在軟件界面看到所有請求
- 請求完整無缺，而且已經自動解密
- 雙向 HTTPS 的請求也能看到內容
翻了下工具介紹，Sniffmaster 居然支持腳本編寫，可以實時修改請求響應內容，有點像 mitmproxy + Charles 的結合。
實戰體驗：調試帶 Pin 的 iOS HTTPS 接口
說個具體例子，我調試的是一個醫療 App，它對安全性要求極高：
- 強制 HTTPS，所有 HTTP 請求會直接被中間件拒絕
- 接口全量啟用雙向認證
- APP 內置了 SSL Pinning，如果不是特定證書鏈直接斷聯
傳統代理全廢。
而 Sniffmaster，因為是用設備連接的方式，繞過了系統信任鏈，可以無視 Pinning 行為直接攔截 TCP 流。
打開“攔截器”，我寫了一段 JavaScript 修改接口返回數據，秒變測試環境狀態。
同時它還能用來分析網絡性能，顯示請求鏈路耗時、TLS 握手時長、請求體大小等，UI 簡單但很實用。
抓包工具沒必要“一刀切”
每款工具都有其適配人群和場景：
- Charles、Fiddler 更適合日常 Web 調試
- mitmproxy 拿來寫自動腳本抓分析包很合適
- Wireshark 用來排查底層 TCP 問題很專業
但像 iOS HTTPS + 雙向認證這種“毒瘤場景”，只能靠專門的工具處理。
我不想說哪款工具一定最好，但 Sniffmaster 抓包大師確實在我最無助時解決了問題。
也許，有時候解決問題的關鍵不是“全能”，而是“剛剛好”。
如果你也在調試 iOS HTTPS 接口時卡住了，不妨多試試不同的方式。
不是每個工具都能解決所有問題，但合適的工具 + 合理的方式，可以讓你少熬很多夜。
