在移動開發與線上故障排查中，iOS 抓包幾乎是所有網絡問題的起點。但 iOS 對證書、安全策略、網絡代理等方面的限制，使抓包經常遭遇各種失敗：HTTPS 無法解密、App 開啓證書 pinning、HTTP/3 繞過代理、數據流量噪音巨大……要想解決問題，不能只依賴一種抓包方式，而是需要“多工具協同 + 分層排查”的工程化方法。

一、iOS 抓包為什麼經常遇到阻礙？

iOS 的安全鏈路導致抓包過程可能失敗，最常見原因包括：

  • 代理證書無法被系統完全信任
  • App 默認啓用證書 pinning
  • 自定義 TLS 棧繞過系統代理
  • HTTP/3（QUIC）未走 TCP，導致代理無效
  • 多 App 搶流量，噪音太大難以分析
  • 無法按 App 過濾數據，pcap 難以拆解

因此，iOS 抓包必須具備替代方案與不同層級的抓包能力。

二、iOS 抓包工具矩陣（按職責拆分）

代理式抓包（查看明文）

代表工具：

  • Charles
  • Proxyman
  • Fiddler
  • mitmproxy（免費）

適合：

  • 查看 HTTP/HTTPS 請求
  • 斷點修改 Header / Body
  • 模擬異常響應

侷限：

  • App 啓動 pinning → 無法抓取
  • 無法處理 HTTP/3（QUIC）
  • iOS CA 信任鏈可能受限

底層抓包（TCP/TLS 證據）

代表工具：

  • tcpdump
  • Wireshark / tshark

適合：

  • 分析三次握手、重傳、窗口
  • 分析 TLS 握手失敗
  • 判斷流量是否到達後台

這些工具是“工程證據鏈”的核心。

腳本化工具（批量分析）

代表：

  • pyshark
  • scapy
  • mitmproxy 腳本

適合：

  • 批量提取 TLS Alert
  • 統計 RTT、丟包率、流量模式
  • 自動回放

代理失敗/證書 pinning 場景的補充工具

代表：

  • 抓包大師（Sniffmaster）

用途自然融入：

  • 無需配置代理即可抓取 iOS TCP/HTTPS 流量
  • 按 App / 域名 過濾數據，避免噪音
  • 自動識別常見協議（HTTPS / HTTP / mdns）
  • 支持查看 TCP 數據流原始內容（文本、HEX、二進制）
  • 可將流量導出為 Wireshark 兼容 pcap
  • 擁有攔截器與 JavaScript 腳本，支持動態修改請求/響應

適用於：

  • 代理證書不被信任
  • App 啓用證書 pinning
  • 流量中 HTTP/3/QUIC 導致代理抓不到包
  • 自定義協議或混合協議
  • 需要端側流量與服務器 pcap 做逐幀比對

三、iOS 抓包標準流程（TCP → TLS → HTTP）

TCP 層：判斷流量是否真正發出去

服務端抓包命令：

sudo tcpdump -i any host <client_ip> and port 443 -s 0 -w server.pcap

關鍵檢查項：

  • TCP 三次握手是否完整
  • 是否存在大量重傳
  • 是否存在 RST

TLS 層：證書鏈與握手分析

驗證證書鏈：

openssl s_client -connect api.example.com:443 -servername api.example.com -showcerts

Wireshark 常用過濾器：

  • tls.handshake.type == 1（ClientHello）
  • tls.alert_message

若 app 抓不到 HTTPS，則重點檢查：

  • 是否有證書替換
  • 是否存在 pinning 攔截
  • 是否有中間網絡設備導致 handshake 失敗

HTTP 層：明文請求檢查

若代理正常，直接在 Charles/Proxyman 查看：

  • Header、簽名、時間戳
  • 業務響應體
  • 異常狀態碼

若代理失敗，則需要：

  • 使用 Sniffmaster 導出 pcap
  • 再用 Wireshark 解密或比對服務端流量

四、常見抓包失敗案例與解決方案

場景 原因 解決方案
瀏覽器能抓，App 抓不到 pinning 用 Sniffmaster 補抓或請求開發提供禁用版本
HTTPS 有握手但無請求 TLS Alert 比對證書鏈、SNI、Cipher suite
抓不到 HTTP/3 流量 QUIC 走 UDP 強制關閉 QUIC 或分析 UDP 443
pcap 噪音太大 多應用搶流量 需按 App / 域名過濾（Sniffmaster 支持）
無法導出完整 pcap 工具限制 使用支持 pcap 導出的補充方案

五、工程團隊應如何標準化 iOS 抓包流程？

每次抓包建議遵循統一格式：

輸入信息

  • 時間窗（秒級）
  • App 名稱、系統版本
  • 網絡類型
  • 使用的工具（代理 / pcap / 腳本）

必須包含的抓包內容

  • TCP 三次握手截圖
  • TLS ClientHello 與證書鏈截圖
  • HTTP 頭+體
  • 重傳/Alert 異常

輸出結論

  • 問題歸屬：客户端 / 網絡 / 後端
  • 修復建議（證書鏈、網絡鏈路、超時策略等）

iOS 抓包需要“工具鏈”而不是“單一工具”

iOS 抓包本質上是網絡工程問題，不可能靠一個工具解決所有場景。 最佳實踐是：

  • 代理工具負責能解密的部分
  • tcpdump + Wireshark負責底層證據
  • 腳本工具負責批量分析
  • **抓包大師（Sniffmaster）**負責代理失效、pinning、QUIC、自定義協議等特殊場景的數據流捕獲與 pcap 導出

這樣可以形成覆蓋所有場景的網絡調試體系。