很多開發(fā)者在調(diào)試 iOS App 時(shí)都會(huì)遇到同一個(gè)難題：HTTPS 抓包不穩(wěn)定，某些請(qǐng)求能看到，部分請(qǐng)求抓不到，甚至整條鏈路直接失敗。
原因可能是證書校驗(yàn)、代理限制、協(xié)議版本、網(wǎng)絡(luò)環(huán)境、App 內(nèi)部實(shí)現(xiàn)等多層因素造成的，單靠 Charles 或 Proxyman 很難覆蓋所有情況。

本文圍繞“iOS app https 抓包”主題，從網(wǎng)絡(luò)工程角度分析常見瓶頸，并給出適用于所有抓包場(chǎng)景的工具鏈組合。

一、為什么 iOS App 的 HTTPS 抓包特別容易失??？

對(duì)于 iOS App，有幾個(gè)常見的影響因素：

• 應(yīng)用開啟證書 pinning（最常見） → 代理證書無法被信任
• 系統(tǒng)限制第三方證書信任鏈 → 抓包工具無法解密
• HTTP/3 / QUIC 走 UDP → Charles、Fiddler 完全抓不到
• App 內(nèi)自定義網(wǎng)絡(luò)層 → 繞過系統(tǒng)代理
• 多域名 / 多 App 同時(shí)發(fā)包 → 抓包噪音嚴(yán)重
• 網(wǎng)絡(luò)中間鏈路替換證書 → TLS 握手失敗

因此，想穩(wěn)定抓 HTTPS，不僅需要代理，還需要能直接觀察 TCP/TLS、過濾應(yīng)用流量、導(dǎo)出 pcap 的工具來組合分析。

二、iOS HTTPS 抓包工具分層（各司其職）

代理類工具（查看明文）

適用場(chǎng)景：開發(fā)調(diào)試、快速驗(yàn)證接口
工具包括：

• Charles
• Proxyman
• Fiddler
• mitmproxy

優(yōu)點(diǎn)：能查看明文、支持?jǐn)帱c(diǎn)、易用
限制：pinning / QUIC 時(shí)失效

底層抓包工具（網(wǎng)絡(luò)證據(jù)）

用于分析：

• TCP 三次握手
• TLS 握手流程
• 丟包 / 重傳
• 是否抵達(dá)服務(wù)器

工具：

• tcpdump
• Wireshark

這些工具對(duì)定位“請(qǐng)求沒到后臺(tái)”“TLS 握手失敗”等問題非常關(guān)鍵。

自動(dòng)化/腳本工具（批量分析）

mitmproxy 腳本、pyshark、scapy
適合自動(dòng)化檢測(cè)或 CI 測(cè)試場(chǎng)景。

補(bǔ)抓工具（代理失敗、pinning、混合協(xié)議場(chǎng)景）

抓包大師（Sniffmaster）在 HTTPS 場(chǎng)景下補(bǔ)齊代理工具的限制：

• 無需系統(tǒng)代理，也無需安裝證書即可抓到 TCP/TLS 流量
• 支持 按 App / 域名過濾，減少噪音
• 可識(shí)別 HTTPS / HTTP / mdns / 自定義協(xié)議
• 可查看原始 TCP 數(shù)據(jù)流（HEX/二進(jìn)制/文本）
• 支持 導(dǎo)出 Wireshark 兼容 pcap，用于深度分析
• 內(nèi)置 攔截器 + JavaScript 編輯 可以修改請(qǐng)求與響應(yīng)

它的作用不是取代 Charles，而是在 Charles 失敗時(shí)用于補(bǔ)抓底層流量、比對(duì) TLS 握手和導(dǎo)出證據(jù)。

三、iOS App HTTPS 抓包的標(biāo)準(zhǔn)排查流程

以下流程可以直接作為團(tuán)隊(duì)抓包腳本：

用代理工具進(jìn)行初步抓包

• 安裝代理根證書
• 在 Wi-Fi 設(shè)置中填入代理
• 測(cè)試是否可以抓到 HTTPS

若只有部分接口抓得到 → 可能是 pinning 或特定域名限制。

在服務(wù)器端抓取 pcap（確認(rèn)請(qǐng)求是否到達(dá)）

如果懷疑 HTTPS 鏈路失敗，用 tcpdump 觀察服務(wù)器側(cè)流量：

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

若連 ClientHello 都沒有 →
說明 App 并未發(fā)送請(qǐng)求，或被中間鏈路阻斷。

分析 TLS 握手失敗的原因

Wireshark 過濾：

• ClientHello:

  tls.handshake.type == 1
  

• TLS Alert：

  tls.alert_message
  

重點(diǎn)檢查：

• SNI 是否正確
• 證書鏈?zhǔn)欠裢暾?/li>
• 是否出現(xiàn)證書替換
• Cipher suite 不兼容
• QUIC 是否導(dǎo)致代理失效

代理抓不到包時(shí)的補(bǔ)抓策略

這類問題最常見，例如：

• App 強(qiáng)制 pinning
• App 使用 ATS 新策略
• App 使用自定義網(wǎng)絡(luò)庫
• 部分域名強(qiáng)制開啟 HTTP/3

此時(shí)使用抓包大師（Sniffmaster）可直接捕獲：

• HTTPS / TCP / UDP 數(shù)據(jù)流
• 按 App / 域名過濾的請(qǐng)求
• 可導(dǎo)出 pcap 供 Wireshark 對(duì)照分析
• 甚至可用腳本攔截請(qǐng)求做實(shí)驗(yàn)驗(yàn)證

通常流程為：
客戶端流量（Sniffmaster） + 服務(wù)端流量（tcpdump） → Wireshark 并排分析 → 找出差異點(diǎn)

這是最穩(wěn)、最工程化的抓包方法。

HTTP 層內(nèi)容分析（若能解密）

當(dāng)代理可正常解密時(shí)，檢查：

• Header
• Authorization / Token
• 簽名字段
• 時(shí)間戳
• 響應(yīng)內(nèi)容

用于最終定位應(yīng)用層問題。

四、實(shí)際案例解析：HTTPS 抓不到包如何定位

案例：某 iOS App 新版本無法抓 HTTPS 請(qǐng)求。

排查順序：

1. Charles 完全無包 → 代理失效
2. 服務(wù)器 tcpdump 未看到 ClientHello → 請(qǐng)求未出發(fā)或被提前攔截
3. 使用 Sniffmaster 過濾該 App 流量 → 可看到 TLS ClientHello
4. Wireshark 分析握手 → 發(fā)現(xiàn)證書鏈中間節(jié)點(diǎn)被公司 Wi-Fi 改寫
5. 修復(fù)證書鏈后恢復(fù)正常

這類問題通過單一工具幾乎無法定位，需要完整鏈路分析。

五、團(tuán)隊(duì)?wèi)?yīng)當(dāng)建立的抓包規(guī)范

所有 iOS 抓包應(yīng)包含以下內(nèi)容：

• 時(shí)間戳（秒級(jí)）
• 網(wǎng)絡(luò)詳情（Wi-Fi/4G/5G）
• 使用工具說明
• 服務(wù)端 pcap
• 客戶端 pcap（如 Sniffmaster 導(dǎo)出）
• Wireshark 關(guān)鍵截圖
• 判定鏈路位置（客戶端 / 網(wǎng)絡(luò) / 后端）
• 解決方案（證書鏈、超時(shí)、協(xié)議等）

這樣每次抓包都可以復(fù)現(xiàn)、復(fù)盤、積累經(jīng)驗(yàn)。

iOS HTTPS 抓包不是單一工具能解決的

最佳實(shí)踐工具鏈為：

• Charles / Proxyman：查看明文
• tcpdump + Wireshark：分析底層與 TLS
• mitmproxy：腳本自動(dòng)化
• 抓包大師（Sniffmaster）：代理失效 / pinning / QUIC / 自定義協(xié)議 / 多流量混合場(chǎng)景的補(bǔ)抓與 pcap 導(dǎo)出

通過“分層分析 + 多工具協(xié)作”，幾乎可以定位所有 iOS HTTPS 抓包失敗的問題。