HTTPS抓包失败主因是证书未被信任或App启用证书固定；iOS需手动开启完全信任，Android 7+需root改系统证书目录或用Frida绕过；mitmproxy因原生Python支持更适配自动化场景。
手机App HTTPS抓包失败，大概率是证书没装对
HTTPS抓包不是打开工具就能看到明文——中间人代理（Mitmproxy/Charles/Fiddler）必须让手机信任它的根证书，否则系统或App会直接断连、报错或跳过HTTPS请求。iOS和Android处理方式不同，尤其Android 7+默认不信任用户安装的证书，很多App还做了证书固定（Certificate Pinning），这时候光装证书根本没用。
- iOS：设置 → 已下载描述文件 → 安装证书 → 设置 → 关于本机 → 证书信任设置 → 手动开启“完全信任”
- Android 7+：证书必须放进
/system/etc/security/cacerts/（需root），或改用支持全局代理+绕过证书固定的方案（比如Frida hook） - 遇到
ERR_SSL_VERSION_OR_CIPHER_MISMATCH或 App直接闪退，基本是证书未被信任或App启用了证书固定
Mitmproxy比Charles/Fiddler更适合Python生态
如果你需要写脚本自动过滤、重放、修改请求，或者集成进CI/自动化测试流程，mitmproxy 是唯一原生支持Python脚本扩展的工具。Charles靠Java写插件，Fiddler用C#，而mitmproxy 的 mitmdump 和 mitmweb 命令行接口天然适配Python工程流。
-
mitmdump -s script.py可直接加载Python脚本，拦截、修改请求/响应，无需额外编译或配置环境 - 脚本里能直接用
flow.request.headers、flow.response.text等属性，不像Charles要解析XML日志再parse - 不依赖GUI，适合跑在Linux服务器或Docker里，
mitmproxy的ctx.log.info()也能直接对接logging模块
Fiddler在Windows上最省事，但Mac/Linux得绕路
Fiddler原生只支持Windows，Mac用户得用FiddlerCap（功能阉割）或跑Wine（不稳定），Linux基本放弃。而Charles和Mitmproxy跨平台无压力，但Fiddler对.NET系App（比如某些Unity游戏）兼容性更好，因为它的TLS解密逻辑更贴近Windows SChannel。
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- Windows下装完开代理、装证书、点“Decrypt HTTPS traffic”三步就通，比Charles少一堆Java版本警告
- Fiddler的
AutoResponder功能做Mock响应极快，拖个本地JSON文件就能替换API返回，适合前端联调 - 但Fiddler导出的
.saz文件没法直接被Python读取，得先转成har或json，不如mitmproxy的flow.export()直接生成可序列化对象
证书固定（Pinning）绕过不能只靠代理工具
哪怕你把Mitmproxy证书装进系统，遇到用OkHttp（Android）、AFNetworking（iOS）或自定义SSLContext的App，依然看不到HTTPS流量——它们在代码里硬编码了服务端证书指纹，拒绝任何中间人证书。这时候代理工具本身无能为力，必须配合运行时Hook。
立即学习“Python免费学习笔记（深入）”；
- Android常用
FridahookOkHttpClient的sslSocketFactory字段，或重写TrustManager - iOS可用
frida-ios-dump+SSLKillSwitch2，但越狱或需调试权限 - 别信“关闭证书固定开关”的一键脚本——多数已失效，且容易触发App的反调试逻辑（比如检测
FridaGadget进程）
真正卡住的从来不是选哪个工具，而是App用了什么网络库、有没有加固、是否校验调试器。抓包只是第一步，后续得看log、逆向smali/mach-o、甚至动态调试才能继续。
