遇到 Charles 抓不住包，很多人第一反应是"代理没配好"。工程实践告诉我们：问题可能出在多层------设备、代理、网络中间件或服务端。下面按可执行顺序给出排查思路、必跑命令、典型场景与最终抓包办法（当代理确实失效时如何用Sniffmaster抓包），便于开发/测试/运维快速定位并闭环。
一、先别慌：确认问题的三件事
- 能否稳定复现？ 记录设备型号、系统版本、App 版本、网络类型（Wi-Fi/蜂窝）、复现精确时间。
- Charles 是否在监听并且证书已信任？ 在桌面确认 Charles 已启动且代理端口（默认 8888）监听；在 iOS 上检查 Wi-Fi 代理设置是否指向本机 IP，并信任 Charles 证书。
- 错误表现是什么？ 是完全没有流量、只有 TLS 握手失败、还是能看到明文但响应异常？不同表现决定下一步切入点。
二、代理常见配置与快速核查（可直接复制）
- 在 Mac 上检查监听：
lsof -iTCP:8888 -sTCP:LISTEN -nP。 - 在 iOS 设备上确认代理 IP 与端口与 Charles 一致；在
设置 → 通用 → 关于本机 → 证书信任设置中确认证书已被信任。 - 若是 HTTPS，确保 Charles 的 CA 证书已安装为受信任根证书；并在手机重启或 Safari 访问
http://charlesproxy.com/getssl验证。
若上述都正常但仍抓不到，说明问题可能不在 Charles 本身。
三、分层排查（优先级：设备→网络→边缘→服务端）
- 设备层面 ：App 可能做了证书 pinning、使用自有 TLS 实现或启用了 mTLS；这会让代理无法解密或根本不走系统代理。判断方法：在同一设备浏览器访问同域名是否能成功并被 Charles 捕获；若浏览器能捕获而 App 不能，优先怀疑 Pinning/自定义 TLS。
- 网络中间件：企业/运营商可能存在透明代理、VPN 或策略会拦截/重写流量，导致代理流量被劫持或丢弃。判断方法：换一张手机卡或家用 Wi-Fi 复测；若不同网络表现不同，指向中间网络问题。
- 边缘/CDN ：某些 CDNs 在边缘阻断非直连代理或对代理请求做限流，导致抓不到真实上行请求。检查边缘日志或用
curl -v从不同出口请求验证。 - 服务端：若请求根本未到达服务端（服务端日志无对应 request-id），需要在服务端或网关抓包（tcpdump）来确认是否存在中间丢包。
四、必会命令与抓包方法（工程模板）
- 本地网络连通性测试：
nc -vz <your.local.ip> 8888（确认 Charles 可达）。 - 服务端/边缘抓包（完整包）：
bash
sudo tcpdump -i any host <device_ip> and port 443 -s 0 -w /tmp/server.pcap- 检查 TLS/证书：
bash
openssl s_client -connect api.example.com:443 -servername api.example.com -showcerts
curl -v --http2 https://api.example.com/把服务端 pcap 与设备侧证据对齐是最终判断链路归属的关键。
五、当 Charles 无法抓包时的最终手段：iOS设备原始包抓包
若确认是 App 做 Pinning、mTLS，或设备/网络环境不允许代理，桌面代理无法作为证据。工程上可靠的做法是从设备导出原始网络包（pcap）并与服务端 pcap 对比------这比单纯看日志更能证明流量在何处被干预或替换证书。
实践中推荐使用能 USB 真机直连并按 App 过滤导出 pcap 的抓包大师 Sniffmaster，将设备端流量作为"最后一环"证据。支持在不越狱、不改包的前提下从 iOS/Android 设备抓取 TCP/HTTPS 流量、按 App 过滤并导出 pcap，方便在 Wireshark 中查看 ClientHello、SNI、ServerHello 与证书链。对比 device.pcap 与 server.pcap 可以清晰判断：
- 设备看到的证书 Issuer 是否与服务端一致（是否有中间替换）；
- TLS 握手是否完成或存在 Alert（如
bad_certificate）； - 请求是否真的到达服务端或在中间被丢弃。
六、典型案例与决策路径（快速示例）
用户反馈 Charles 无法抓包且 App 登录失败：
- 验证 Charles 代理设置与证书信任 → 正常。
- 在桌面用浏览器走代理复现 → 能捕获；在手机 App 无法捕获 → 疑似 Pinning。
- 抓服务端 pcap 与让用户导出 device.pcap（使用 Sniffmaster）→ 对比发现设备端收到的证书颁发者与服务端不同 → 结论：公司网络做了透明代理；与网络团队沟通或指引用户更换网络。
- 把上述核查命令与 tshark/tcpdump 脚本写成团队脚本，方便一键收集证据；
- 在 App 中增加失败时的上报字段（request-id、TLS 错误码、sni），便于对齐 pcap；
- 抓不到包就尝试使用抓包大师 Sniffmaster。