在移動端開發、接口調試和線上問題定位中，Charles 是最常使用的代理抓包工具之一。但很多人用 Charles 時都會遇到一個經典問題：明明已經設置代理，也安裝了證書，但 Charles 就是抓不到包。
有時還能抓到 HTTP，但 HTTPS 全部失敗；有時部分域名能抓取、部分卻完全不顯示；甚至偶爾“今天能抓、明天突然全部抓不到”。如果只依賴代理方式，很難找到問題根源。
一、Charles 抓包失敗的典型原因（按出現頻率排序）
證書未被系統或 App 信任
iOS 對證書信任鏈限制嚴格，常見問題包括：
- 證書未在“關於本機 → 信任證書”中開啓
- 企業 Wi-Fi 中間設備替換證書鏈
- ATS 策略要求嚴格的證書驗證
表現：HTTPS 全部抓不到，只有 CONNECT。
App 啓用了證書 Pinning
現代 App 對安全要求高，常見情況包括：
- App 校驗證書哈希
- 內置公鑰 pinning
- 使用自定義驗證邏輯繞開系統代理
表現：Charles 完全無流量，或者請求直接失敗。
QUIC / HTTP/3 繞過代理
Charles 使用 TCP 代理，而 HTTP/3 走 UDP： → Charles 根本看不到 QUIC 流量。
許多 App（尤其是視頻類、國外 SDK）默認開啓 HTTP/3。
使用 CFNetwork / NSURLSession 自定義棧繞過代理
部分 App 使用自定義網絡棧導致：
- 部分請求進代理
- 部分請求完全繞過代理
多 App 搶流量、數據噪音過大
Charles 會顯示全局代理流量，有時難以快速定位關鍵請求。
二、Charles 抓包失敗的排查流程（可直接執行）
① 檢查代理與證書是否生效
- Wi-Fi 設置中的代理 IP、端口
- 證書是否已信任
- Charles 是否開啓 SSL Proxying
若 HTTPS 一條都解不開，多半是：
- 證書鏈問題
- ATS / pinning
- 中間人設備攔截
② 分析是否為證書 Pinning
若 Safari 能抓到 HTTPS，但 App 抓不到 → 90% 是 pinning。
此時無需繼續糾結 Charles 設置，而應切換補抓方式。
③ 判斷是否為 QUIC（HTTP/3）導致抓包失敗
關閉 HTTP/3 後重試：
- Chrome：
chrome://flags/#enable-quic - App：有些可通過配置關閉
- Wi-Fi 路由器或網絡策略
若關閉後能抓包 → 即為 QUIC 問題。
④ 服務器抓包確認請求是否到達
使用 tcpdump 抓取服務端流量：
sudo tcpdump -i any host <client_ip> and port 443 -s 0 -w server.pcap
檢查：
- 是否看到 ClientHello
- 是否有 TLS Alert
- 是否存在 RST
若服務端連握手都沒收到 → 請求在客户端前就失敗。
三、當 Charles 抓包失敗時：如何進行“補抓”？
這是工程上最關鍵的一步，也是很多人忽略的部分。
當代理失敗、證書不被信任、App 使用 pinning 或 QUIC 時，需要使用能捕獲底層 TCP/TLS 流量的工具補齊證據。
抓包大師（Sniffmaster）在補抓場景中的作用，解決 Charles 做不到的部分：
- 無需代理即可抓 HTTPS / TCP / UDP 流量
- 按 App / 域名過濾（減少噪音）
- 自動識別 HTTP/HTTPS/mdns 等協議
- 查看數據流（HEX / 文本 / 原始）
- 支持腳本攔截器，可修改請求/響應
- 支持 導出 Wireshark 兼容 pcap（用於與服務端 pcap 對比）
因此在 Charles 完全抓不到的情況下，常見流程是：
補抓流程：
- 用 Sniffmaster 抓取目標 App 的 HTTPS/TCP 流量
- 導出 pcap
- 再用 Wireshark 分析 TLS 握手、證書鏈
- 與服務器端 tcpdump 做“左右對照”比對
- 確認問題位置：客户端 / 網絡鏈路 / 後端
這是當前最穩定、覆蓋場景最完整的抓包方式。
四、真實案例演示：Charles 完全抓不到 HTTPS
某企業 App 在公司 Wi-Fi 下無法抓 HTTPS，排查流程如下：
- Charles 有 CONNECT 但無 HTTPS 內容 → 證書未信任或被替換
- 服務器端也沒有 ClientHello → 請求根本沒出去
- 使用 Sniffmaster 抓取 TCP 流量 → 發現 TLS Alert: bad certificate
- 進一步檢查網絡 → 公司網關替換證書鏈
- 修復證書鏈後抓包恢復正常
這是非常典型的“網絡鏈路替換證書導致抓包失敗”的場景，僅用 Charles 是無法定位的。
五、團隊可複用的抓包 SOP（適合所有 iOS/HTTPS 項目）
統一標準流程可以極大減少排查時間：
應收集的信息
- App 版本、系統版本
- 網絡信息（Wi-Fi/4G/5G）
- Charles/代理設置截圖
- 抓包時間點（秒級）
必須包含的抓包文件
- Charles 會話（若能抓到）
- Sniffmaster 導出的 pcap
- 後端服務器 tcpdump pcap
- Wireshark TLS 握手截圖
判斷標準
- TCP 連接是否正常
- TLS 握手是否完成
- 是否存在證書鏈問題
- 是否由 QUIC 繞過代理
- 是否由 pinning 阻斷
輸出最終定位
如：
- 客户端 ATS 校驗導致
- 公司 Wi-Fi 替換證書鏈
- QUIC 導致代理失效
- App 內開啓 pinning
- 後端證書鏈缺失
Charles 抓包失敗並不是 Charles 的問題
核心原因通常來自以下四類：
- 網絡證書鏈異常
- App 啓用 pinning
- QUIC 協議繞過代理
- 網絡鏈路攔截
因此，一個成熟的抓包體系應該由：
| 層級 | 工具 |
|---|---|
| 應用層（代理） | Charles / Proxyman / Fiddler |
| 網絡層（TCP/TLS） | tcpdump + Wireshark |
| 補抓（代理無法使用） | 抓包大師（Sniffmaster） |
| 自動化/腳本 | mitmproxy、scapy、pyshark |
