Charles HTTPS 抓包、Rewrite 与移动端调试手册
Structure 里没有请求时，不要先碰证书
Charles 是桌面前向代理。客户端先把 HTTP 或 HTTPS 连接交给 Charles，Charles 再连接目标服务。界面空白意味着请求没有走到这个代理进程，常见原因是系统代理未接管、目标应用有自己的代理设置、手机与电脑不在可达网络、VPN 改写了路由，或者客户端主动绕过了系统代理。此时反复安装 Charles Root Certificate 不会增加任何证据，因为 TLS 解密发生在代理连接建立之后。
先用受控测试地址跑一条普通 HTTP 请求。Charles 5 安装后会在桌面会话中监听本地代理端口；确认端口没有被其他程序占用，再让浏览器或命令行显式指向它。下面的命令不依赖系统代理，适合判断进程、地址和端口是否成立：
curl --proxy http://127.0.0.1:8888 http://example.com/ \
-o /dev/null -w '%{http_code}\n'状态码出现在终端，并且 Charles 的 Sequence 或 Structure 视图出现同一请求，才能继续处理 HTTPS。若 curl 报连接拒绝，检查 Charles 是否正在运行、监听端口是否改过以及本机安全软件是否阻断；若 Charles 收到连接却没有上游响应，再查代理主机自身的 DNS、企业出口代理和目标服务。客户端到 Charles、Charles 到上游是两段不同连接，错误不能混成一句“抓包失败”。
Structure 按 host 组织会话，适合从域名进入；Sequence 保留时间顺序，适合还原登录跳转、重试和并发请求。排查一次移动端登录时，可以先在 Structure 里确认目标 host 是否出现，再回 Sequence 查看它前后的认证跳转。不要一开始就用大范围过滤隐藏所有非目标会话；先证明流量存在，再用 host、path、method 和状态码收窄。
SSL Proxying 只打开获准的 host
HTTPS 客户端通常先发出 CONNECT api.example.test:443。Charles 与真实服务完成一条 TLS 连接，同时为该 host 动态生成一张由 Charles Root Certificate 签名的证书，交给客户端建立第二条 TLS 连接。客户端只有信任这张根证书，Charles 才能看到 HTTP 明文。
在 Help > SSL Proxying > Install Charles Root Certificate 安装证书后，还要在 Proxy > SSL Proxying Settings 把目标 host 加入 SSL Proxying 列表。Charles 官方行为是按 host 明确启用；通配符 * 会解密所有经过代理的 HTTPS 流量，不适合作为日常默认值。已有连接可能继续复用旧会话，规则变更后应关闭目标应用连接再复现，必要时重启 Charles。
命令行实验不必把 CA 永久放进系统信任库。先从 Charles 导出只含公开证书的根证书文件，再让本次 curl 调用显式信任它：
curl --proxy http://127.0.0.1:8888 \
--cacert ./charles-root-public.pem \
https://api.example.test/health \
-H 'X-Debug-Case: charles-baseline' \
-o /dev/null -w '%{http_code}\n'终端状态码、Charles 中的明文请求和服务端日志里的 X-Debug-Case 应互相印证。去掉 --cacert 后出现证书不受信，再恢复参数后成功，说明代理路径与上游网络都没有变化，变化点只有客户端信任链。如果连 CONNECT 都不存在，仍应回到代理接入层；如果只有 CONNECT 而没有明文，才检查 CA、SSL Proxying host 和客户端 pinning。
手机接入时，Charles 需要监听电脑的局域网地址，手机 Wi-Fi 代理填写电脑 IP 与 Charles 端口。监听地址对局域网开放后，主机防火墙必须只允许测试设备来源，公共网络不得暴露代理端口。iOS 安装描述文件后还需要在证书信任设置中显式启用完整信任；Android 应用是否接受用户安装 CA 由应用网络安全配置决定。拒绝代理 CA 可能是应用安全策略正常工作，不应为了抓包去修改未获授权的生产包。
Map Local 是替换响应，不是修改服务器
Map Local 把匹配的远程 URL 映射到本地文件。它适合验证前端对某个 JSON、脚本或静态资源变化的处理，不会把文件写回服务器。先保存一份不包含真实个人数据的响应样例，例如 fixtures/profile-expired.json，再为精确的 host、path 和 query 建立 Map Local 规则。
验证时给请求加入独立调试标识，同时观察三个结果：Charles 命中 Map Local，客户端收到本地文件内容，服务端没有对应响应体读取。关闭 Map Local 后重新请求，客户端恢复真实上游响应。只有这组正反证据齐全，才能把客户端分支变化归因于本地映射，而不是缓存、灰度或服务端恰好返回了相似内容。
Map Remote 把一个远程地址改送到另一个远程地址，适合在兼容环境间切换。它会改变真实上游，风险高于 Map Local。目标必须是同一授权范围内的测试服务，认证 Cookie、Host、CORS、证书与数据隔离需要重新判断。把生产域名映射到测试环境，或把测试凭证送到另一套环境，都可能造成跨环境数据泄露。
Map Local 和 Map Remote 都有 enable 开关。团队共享配置时应把规则名称写成场景和失效条件，而不是“临时规则”；任务结束先关闭规则，再用一次未命中的请求证明流量已经回到真实路径。
Rewrite 与 Breakpoints 会改变正在观察的事实
Rewrite 可以按 location 集合匹配 host、path、query、请求头、响应头和正文，并执行增加、替换或删除。它适合模拟特性开关、响应头、缓存策略和有限的错误体，但规则范围必须比抓包过滤更严格。过滤器只影响界面展示，Rewrite 会改变线上传输的字节；两者不能用同一种“看起来只剩目标请求”的直觉管理。
一个稳妥的 Rewrite 实验只对测试 host、固定 path 和 X-Debug-Case 命中。先记录不启用 Rewrite 的基线响应，再打开规则给响应增加 X-Debug-Proxy: charles，验证客户端确实进入目标分支；随后关闭规则并证明响应头消失。若规则修改正文，还要处理 Content-Type、编码、压缩和长度，避免由格式损坏制造与业务无关的失败。
Breakpoints 会在请求发往上游前或响应返回客户端前暂停会话，允许人工编辑后继续。它适合一次性的交互探索，不适合稳定回归：人工停顿会改变超时、重试和并发顺序。断点未释放时，客户端看到的可能只是超时。复现性能、流式响应、WebSocket 或竞态问题时应关闭 Breakpoints，改用可重复规则或服务端夹具。
Charles 还提供 Throttle，用带宽、延迟和可靠性参数模拟较差网络。这里同样要先记录未限速基线，再启用命名 profile，并同时记录客户端超时、重试次数和 Charles 时序。代理增加的排队与两段连接本身也会改变网络表现，关键结论仍需用不经过 Charles 的请求和服务端 trace 对照。
.chls 会话不是普通附件
Charles session 的 .chls 文件可能保存完整 URL、Cookie、Authorization、请求体、响应体、内部域名、设备标识和文件内容。即使界面里只选中一条会话，导出范围也必须再次确认。优先复制必要的请求行、状态码、脱敏头和相对时序，不默认把整个 session 上传工单。
保存原始会话时使用受控临时目录和最短留存窗口，只允许当前处理者访问。分享前人工检查查询参数、认证头、Set-Cookie、JSON 字段、表单、上传文件和二进制响应；仅删除可见的 Authorization 不能证明压缩正文或其他会话没有秘密。会话若必须进入问题系统，应记录脱敏人、复核人、保留原因和销毁时间点。
大响应、长连接和持续抓取会推高 Charles 内存和会话文件体积。先限定 host 和时间窗，再决定是否保留 response body；看到内存持续增长时停止新采集并保存最小证据，而不是等桌面进程失去响应。一次调试的容量上限应由测试流量和终端可用空间决定，不用“抓十分钟”代替字节数与会话数约束。
退出要让网络恢复到没有 Charles 的状态
先关闭 Breakpoints、Rewrite、Map Local、Map Remote 和 Throttle，再停止 Recording。随后解除浏览器、系统或手机的代理设置，从对应用户或设备信任库删除 Charles Root Certificate，最后关闭 Charles 并清理 .chls、导出文件和临时 fixture。若曾开放局域网监听，还要撤销防火墙例外。
清理后的反证很直接：不走代理访问测试服务应成功；显式请求已关闭的 127.0.0.1:8888 应连接失败；证书库搜索不到 Charles Root Certificate；进程和监听端口不存在；原先命中 Map 或 Rewrite 的调试标识不再出现。Charles 的商业授权、配置备份和升级由团队资产管理，但抓包 CA 与会话数据不应随个人配置备份长期扩散。
当工作主要依赖桌面交互、移动端引导、Map 和断点时，Charles 的路径清晰。需要跨平台团队协作与 Fiddler Rules 时应进入 Fiddler；需要代码审查、CI 夹具和非交互流量处理时更适合 mitmproxy。三者都不能替代未授权生产流量审计，也不能绕过客户端原本应当生效的证书固定策略。