Charles进阶实战：断点、重写与HTTPS证书信任

1. 能看见流量和能改造流量，是两件完全不同的事

很多人第一次用 Charles 抓包，兴奋点都在"哦原来这个接口长这样"。把视图切到 Structure，点开一个请求看 JSON，看完关掉，这套动作意义有限。Charles 真正的分水岭在于：它不只能看见，还能在你眼皮底下把请求和响应按停、拆开、改掉、再放行。断点、重写、Map Local/Remote 这几样东西，才是把 Charles 从"观察工具"变成"调试实验室"的关键。

这篇讲的就是这套进阶打法：怎么用断点拦 HTTP/HTTPS 流量做临时的手工修改，怎么用重写（Rewrite）把重复几十次的手工活沉淀成规则，以及为什么很多人卡在"HTTPS 那一列全是灰色的 CONNECT 和一堆报错"上。全文都围绕一个前提展开——调试的是自己项目的 App 和自己的服务端接口，在联调阶段给自己造条件、造异常、造边界。如果你正好在后端改了字段但 App 还没发版、或者想验证一下客户端对某个异常 code 的处理逻辑，下面这套东西能省掉很多次打包和等待。

我先把话说在前面：Charles 的这三板斧各有各的脾气，用错了地方会非常难受。断点适合"我需要停下来想一想"的场合，重写适合"这个改动我要重复一百遍"，Map 适合"我要整个文件换掉"。分不清边界，就会陷入"用断点手动改了一下午，第二天发现全白干"的循环里。

1.1 Charles 在本机链路里扮演的角色：一个愿意为你停留的中间人

要理解为什么能改，得先理解它在哪儿。Charles 启动时会在本机监听一个端口（默认 8888），把自己变成一个标准的 HTTP 代理。客户端把请求发给它，它再转发给真正的目标服务器，收到响应后原路返回。所以一条请求在你的设备和服务端之间实际上走了两跳，中间那一跳完全由 Charles 控制。

这个位置决定了它的能力上限和下限。上限是：既然是它转发，它就有权在转发前改请求、在回传前改响应，甚至干脆不转发、自己编一个响应回去（Map Local 干的就是这个）。下限是：只能管到走这个代理的流量，而且必须是它看得懂的应用层协议。本地 socket 直连、非 HTTP 的私有协议、WebSocket 的帧内容，它就没那么好使了。

还有个被忽略的点：Charles 是"逐条"处理的。它不像某些压测工具那样整条链路流水线化，遇到断点时它会把这一条挂住，等你操作。这个特性既是断点能工作的原因，也是断点让人抓狂的原因——后面第 6 节会细说超时问题。

1.2 四种介入手段的能力边界对比

先把工具摆齐，很多踩坑其实源于"用错了工具"。下表是我自己总结的对照，其中"生效范围"指的是规则命中后影响的是单次会话还是持续生效：

我见过最常见的误用是：拿断点去改一个每次进页面都要请求的接口，结果每切一次 Tab 就被拦一次，一天下来手都点酸了。这种场景应该用重写，一次配好，之后全自动。反过来，如果你只是想看看某个请求在响应前长什么样、临时插一个字段验证一下客户端崩不崩，那用重写反而麻烦——你得先建规则集、写正则、再关掉，不如断点两秒钟解决。

选择逻辑其实就一句话：这次改动会不会重复发生？会，就用重写；不会，就用断点。判断标准简单粗暴但极其有效。

2. 断点：把一条请求按在手里改

断点的本质是"拦截 + 暂停 + 编辑 + 放行"。听上去简单，但实际用起来有几个地方特别容易出岔子：拦错了方向、拦太宽、改完忘了放行、改完发现客户端根本不认。这一节把流程拆开讲，顺带说说那些文档里不会写的手感问题。

2.1 打点之前先决定拦请求还是拦响应

Charles 的断点可以分别命中请求和响应，这是很多人没注意的细节。设置入口在 Proxy 菜单里的 Breakpoint Settings，或者直接在会话列表里右键某条请求选 Breakpoints。勾选时会出现两个选项：Request 和 Response，可以只勾一个，也可以都勾。

这个区分至关重要，因为两者的使用场景完全不同。拦请求是为了"改我想发出去的东西"——改参数、改 Header 里的 token、改 query 里的分页大小、把 GET 改成 POST 试试。拦响应是为了"改我收到的东西"——把 code 从 0 改成 -1 看客户端报错弹窗、把列表里的价格从 99 改成 0.01、把空数组塞几条假数据进去看 UI 会不会崩。

实操中最容易犯的错是两个都勾上。后果是：请求阶段停一次，你点放行；响应回来又停一次，你还没反应过来客户端那边已经转圈转了七八秒。单勾一个，心智负担小一半。

还有一个隐蔽的坑：如果你只勾 Response，那请求本身是正常发出去的，服务端该落库还是落库。调试"客户端如何处理坏数据"没问题，但千万别拿它去验证"某个操作会不会真的生效"——请求已经实实在在打到后端了。我吃过一次亏，想验证幂等逻辑，用响应断点改了个失败状态，结果后台数据多了一条，排查了半天。

2.2 命中之后的操作流程与手抖重灾区

断点命中时 Charles 会弹出一个编辑窗口，分成几个 Tab：Headers、Query、Form、Raw、JSON Text（具体名字随版本略有差异）。改完之后点 Execute 放行，或者点 Abort 直接掐断这条请求。Abort 很好用，能模拟"网络中断"，比拔网线文明多了。

编辑窗口里最需要注意的是内容长度和编码。如果你改的是 Raw 模式，手动加长或缩短了 body，Charles 一般会自动重算 Content-Length，但如果你自己手动改过 Header 里的 Content-Length，两边就对不上了，服务端会直接返回 400 或者干脆挂住不响应。我的习惯是：能用 JSON Text Tab 就不用 Raw，让工具去算长度。

第二个雷区是中文和转义。JSON Text 里改中文一般没问题，但如果你的字段值里本来就有\u转义序列，改的时候容易破坏转义结构，客户端解析直接抛异常。这种情况我会在本地编辑好一段完整合法的 JSON，整段粘贴进去覆盖，而不是在原文上抠字。

第三个是放行时机。断点窗口开着的时候，如果客户端有全局超时（比如 10 秒），时间一到它会自己断开重试，而此时你手里的断点还挂着，等你点 Execute 会发现"请求已取消"。所以改断点的动作要快，或者干脆先把客户端的超时调大。这一条在真机调试时尤其重要，手机端超时策略往往比想象中激进。

提示：调试期间可以把断点窗口当草稿纸——先 Execute 放行一个改好的版本，如果不对，直接在会话列表里选中那条请求按 Repeat 重发，比重新触发一次页面加载快得多。

2.3 断点为什么不能当日常主力

断点的最大问题是它强迫人参与。所有命中的请求都会停下来等你，而你在调试一个页面时，往往同时有七八条请求在飞。就算你只给一条 URL 打了断点，其他请求照常跑，但那条被你挂住的请求会让页面卡在 loading 状态，后续依赖它的逻辑全都不走。这时候你会不自觉地去点"Disable Breakpoints"把它全关了，于是断点白打。

另一个问题是状态不可保存。断点配置本身是能保存的，但你在编辑窗口里临时输入的那些内容，放行之后就没了，下次命中又得重新填。如果同一个测试数据要用二十次，手会废掉。

所以我的实际用法是：断点只用于"探索阶段"。我不知道这个接口返回什么结构、不知道某个字段的取值范围、不确定客户端对哪个字段敏感——这时候用断点，一条一条试，边试边看。等试出结论了，立刻把它固化成重写规则，把断点关掉。断点是手术刀，不是流水线。

3. Rewrite 重写：把手工活变成规则集

重写是 Charles 里被低估最严重的功能。很多人装了 Charles 只用它看包，从来没打开过 Tools 菜单里的 Rewrite。其实一旦你用顺了，会发现它能替掉一大半的断点操作，而且是全自动、可复用、可分享的。

3.1 一条重写规则的四个组成要素

打开 Tools → Rewrite，你会看到一个规则集（Rule Set）的列表。规则集是一组规则的容器，可以整体启用/禁用，也可以导出成文件给别人用。这个设计很关键——它意味着你的调试配置是可以版本化管理的。

一条规则由四部分构成，缺一不可：

第一，作用域（Where）。决定这条规则对哪些请求生效。可以是整站，可以是某个域名下的某个路径前缀，也可以精确到单个 URL。作用域写太宽是新手第一大坑，比如你写了*匹配全部，然后加一条"给所有请求加 Header"，结果连 Charles 自己的健康检查都被改了，一堆莫名的报错。

第二，匹配位置（Match）。Charles 允许你匹配 URL、Host、Path、Query、Method、Header、Body、Response Status 等多个位置。这一层决定了你的正则作用在哪儿。很多人正则写得没问题，但匹配位置选成了 URL 而实际想改的是 Body，那当然不生效。

第三，匹配规则（Match Value）。使用正则表达式。这里有个开关叫 Match whole value，默认关闭，意思是"部分匹配即可"。如果你想让整个字段精确等于某个值才替换，就要打开它。这个开关我建议默认打开，能挡掉大量误伤。

第四，替换内容（Replace）。可以引用正则的捕获组，用$1、$2这种形式。这一点非常有用，意味着你可以做"保留原值只改一部分"的操作。

配置界面里还有一个容易忽略的下拉：这条规则是作用在 Request 上还是 Response 上。选错了就是"配了半天没反应"的经典成因。

3.2 高频场景的规则写法与正则示例

下面这几个是我在自己项目里长期保留的规则，基本覆盖了八成的日常需求。

场景一：改响应体里的业务状态码。后端约定code为 0 表示成功，我想测客户端对失败分支的处理。规则类型选 Body，作用在 Response 上，匹配"code"\s*:\s*0，替换成"code" : -1。注意冒号两边的空格要和原报文尽量保持一致，否则某些严格的解析器会因为格式突变而报错——虽然大多数 JSON 解析器不在意，但万一你调试的是个手写的字符串匹配逻辑呢。

场景二：给所有请求统一加调试 Header。这个在联调时特别香，后端可以靠这个 Header 走 mock 分支。规则类型选 Add Header（不是 Body），作用在 Request 上，Header 名X-Debug-Source，值charles-local。这里千万不要用 Body 类型去拼 Header，那是两回事。

场景三：短路某个接口，让它永远返回空数据。这个我不建议用 Rewrite 做，用 Map Local 更合适——写一个{"list":[]}的本地文件，映射过去。但如果你非要用重写，那就是匹配整个响应体，替换成空 JSON。问题在于响应体大小不固定，正则很难匹配"全部"，所以还是用 Map 更干净。

场景四：错误码替换成另一个错误码。这个用 Response Status 类型最直接。比如服务端返回的是 500，你改成 200 看客户端会不会因为"状态码对了但 body 是错误结构"而崩。这种组合边界特别容易暴露客户端解析逻辑的脆弱点。

场景五：把测试环境的域名转到预发。严格说这属于 Map Remote 的活，但用 Rewrite 的 URL 类型也能做。区别在于 Map Remote 会重新走一遍 DNS 解析，而 Rewrite 只是改了字符串，实际连接的目标可能因为连接复用而没变。所以这个场景我一定推荐 Map Remote，别用重写。

3.3 重写规则不生效时的排查顺序

重写最让人崩溃的地方是"静默失败"——它不报错，就是不生效。我总结了一个从外到内的排查顺序，按这个走基本五分钟能定位。

第一步，看规则集有没有开。Rewrite 界面里每个规则集前面有个复选框，没勾就是停用。这个太蠢了，但确实是我踩过最多次的坑，尤其是在导入了别人的规则集之后，默认是未启用的状态。

第二步，看这条规则在规则集里有没有启用。规则集启用不代表里面的每条规则都启用，每条规则前面还有单独的勾。

第三步，看目标请求有没有走过 Rewrite。在会话列表里选中那条请求，切到 Rewrite 选项卡（有的版本叫 Notes/Rewrite），如果规则命中了，这里会显示应用的规则名。没显示就是没命中，问题在匹配条件上。这一步能省掉大量瞎猜。

第四步，检查匹配位置。你要改的是响应体，规则却配在 Request 上；你要改 Header，规则却配在 Body 上。这种错配在对正则本身产生怀疑之前就该排除。

第五步，怀疑正则。把匹配值暂时改成一个宽泛的字符串（比如只匹配code），看能不能命中。能命中说明正则写错了，不能命中说明前面四步还有问题。正则本身的坑我单独说一句：\s在有的环境里匹配不到全角空格，.*默认不跨行，$在部分模式下的语义和预期不一致。我一般会用[\s\S]*代替.*来做跨行匹配，稳得多。

第六步，检查是否有更高优先级的规则先改掉了。如果同一个规则集里有两条规则都能命中同一个请求，Charles 会按顺序都执行，前一条把内容改了，后一条的正则可能就匹配不上了。规则顺序在界面上是可以拖动的，把范围窄的放前面比较安全。

4. HTTPS 能改的前提：证书信任这件事得先走通

前面讲的所有拦截和修改，在 HTTP 下是白送的，在 HTTPS 下需要过一道门。这道门就是证书信任。绝大多数"Charles 抓不到 HTTPS""一开 SSL Proxying 就全部报错"的问题，根源都在这里。

4.1 根证书安装到底装的是什么

Charles 的工作原理决定了它必须扮演一个"中间人"才能解密 HTTPS：它拿自己的根证书给你发一张临时证书，冒充目标服务器和你握手，同时它自己再和目标服务器正常握手。这样两头都通了，明文在它手里过一遍。

问题就在那张临时证书上。客户端凭什么信它？因为你的设备信任了 Charles 的根证书。所以整个流程是：先从 Charles 导出根证书，安装到设备上，然后在设备的信任设置里把它标记为受信任的根。注意"标记为受信任"这一步在 iOS 上是独立的操作——在设置里装完描述文件之后，还要去"通用 → 关于本机 → 证书信任设置"里把开关打开，很多人就是漏了这一步，装完以为是好了，结果还是抓不到。

根证书有几年的有效期，到期之后需要重新生成安装。我遇到过证书过期后所有 HTTPS 请求在 Charles 里显示成红色的感叹号，排查了半小时才发现是证书时间问题。

4.2 Android 7 之后的那道坎

这是国内开发者最容易卡住的地方。从 Android 7.0（API 24）开始，系统的默认策略变成了：应用只信任系统证书，不信任用户手动安装的证书（除非应用在清单里显式声明了要用用户证书）。也就是说，你把 Charles 的证书装进手机里了，浏览器能正常抓，但你自己 App 的请求还是一堆握手失败。

解决方式是在自己 App 的工程里加一段网络安全配置，在 debug 构建中允许用户证书：

<!-- res/xml/network_security_config.xml --> <network-security-config> <base-config cleartextTrafficPermitted="true"> <trust-anchors> <certificates src="system" /> <certificates src="user" /> </trust-anchors> </base-config> </network-security-config>

然后在清单文件里通过android:networkSecurityConfig引用它。关键点是这段配置只能出现在 debug 变体里，release 包绝对不能带上，否则就是把线上应用的安全性一起开了口子。工程结构上应该放在src/debug/res/xml/下面，release 变体根本不包含这个文件。

这个做法的另一个好处是：不用改业务代码，纯配置层面解决，也不会污染主分支。我在几个项目里都这么处理，配合调试包专用的签名，既方便抓包也不会误发到线上。

4.3 各类失败现象的对照排查

HTTPS 抓不到时，Charles 的报错信息通常很含糊，下面是几种典型现象和对应的原因，按这个表查比盲目试要快得多：

还有一种情况是客户端做了证书固定（Certificate Pinning），即便系统信任了 Charles 的根证书，应用层还会额外比对证书指纹，发现不是预期的那张就断开。这类校验在自家 App 的 debug 构建里通常是可配置的，我一般会在 debug 变体里留一个开关把校验逻辑关掉，或者给调试包配一张单独的、由调试体系信任的证书。这件事必须在工程内部解决，因为它本来就属于产品自己的安全策略设计，调试便利性和线上安全性要分开处理。

顺带一句：SSL Proxying 的域名列表不要图省事就写*:443长期开着。一方面所有 HTTPS 都要走一遍解密，性能有影响；另一方面你可能会抓到一堆和当前调试无关的第三方请求，把会话列表塞得乱七八糟。我的习惯是配几个项目相关的域名，调试期间只开需要的。

5. 把三种手段串起来：一个联调场景的完整推演

单独讲每个工具都太抽象，我把实际工作中最常见的一条链路完整走一遍，你就能体会到什么时候该切哪个工具。

5.1 场景：后端字段改了，前端还没发版

情况是这样的：后端把一个列表接口里的price字段从数字改成了对象，结构从99.00变成{"amount": 99.00, "currency": "CNY"}。前端代码已经按新结构写好了，但线上跑的还是旧版客户端，需要验证新旧两版在同一个后端下分别是什么表现。而前端新版本还没发测试包。

第一步，先用断点探路。给这个列表接口打一个 Response 断点，命中后看一眼原始响应到底是什么结构，确认后端确实已经切到新格式。这一步必须做，因为很多时候你以为的"后端已经改了"其实还没发到这套环境。

第二步，用断点手工把响应改成旧格式（price: 99.00），放行，看线上旧版客户端能不能正常展示。如果显示正常，说明后端的新旧兼容做到了位；如果显示成空白或者 NaN，说明旧版客户端的解析逻辑太脆弱，需要跟后端确认灰度策略。

第三步，把这个手工改动固化成重写规则。规则作用在 Response 的 Body 上，匹配"price"\s*:\s*\{\s*"amount"\s*:\s*([\d.]+)[^}]*\}，替换成"price" : $1。这样每次刷新列表都自动转换，不用再手工点了。写完之后反复刷新几次验证规则的稳定性——正则里最容易出问题的是空格和换行，第一次写完不生效很常见，回去调整一下\s*的位置就好。

第四步，用同一套思路反向验证：把旧格式转成新格式，看看新版客户端的展示。这时候可以再建一条重写规则，但要注意两条规则不要同时命中同一个请求，否则会互相干扰。正确做法是分组管理，测试哪边就开哪边的规则集。

整个流程下来，你没有改一行代码、没有重新打包、没有求后端同学临时切分支。这就是这三样东西组合起来的价值。

5.2 构造异常分支和边界条件的几种套路

真实环境里最难等到的就是异常。网络超时、服务端 500、字段缺失、数组为空、重复 ID、超长字符串——这些情况在联调环境里往往复现不了，但它们恰恰是客户端最容易崩的地方。用 Charles 造这些条件特别方便。

造服务端错误，用重写改 Response Status，把 200 改成 500。注意这会改变客户端对整条响应的判定，如果客户端在 500 时不解析 body，那你改 body 就没意义了。想测"状态码正常但业务失败"，就保持 200 改 body 里的 code。

造网络超时，断点其实是个好工具：命中之后干脆不放行，让客户端自己超时。这比在系统层面限速要精准得多。但要注意客户端往往有重试逻辑，你得连续拦三次才能让重试彻底失败。

造畸形数据，比如把某个必填字段删掉。这里推荐用 JSON Text Tab 整段编辑，删掉字段后确认一下 JSON 整体还是合法的（少个逗号就变语法错误了，那是另一个测试项）。顺便说，JSON 语法错误在这种情况下是个很有价值的测试用例——客户端的异常捕获做得好的话，应该能优雅降级而不是闪退。

造弱网，Charles 有 Throttle 功能（Proxy → Throttle Settings），可以模拟慢速网络。它和断点是两套机制，Throttle 是限速不是暂停，更适合观察加载态、骨架屏、进度条这些 UI 表现。

5.3 规则集的导出、复用与团队共享

规则配好之后是有价值的资产，不该只活在你自己的机器上。Charles 支持把整个 Rewrite 规则集导出成文件，也能导出断点配置。我们团队的做法是把这个文件放进项目的调试文档目录里，新同学拉下代码之后导入一次，立刻就有全套调试环境。

共享的时候有两点要注意。一是文件里的域名要写相对路径或者用变量，别把某个人本地的测试域名写死进去，否则别人导入了满屏都是不命中的规则。二是规则里不要带任何敏感值，比如真实的 token、账号、内部地址，这些应该由使用者自己填。

还有一个进阶用法：把规则集按功能拆成多个，比如"模拟老旧客户端""模拟服务端异常""绕过某个频控"，需要哪个开哪个。比把所有规则堆在一个集里清晰得多，也避免了规则之间的相互干扰。

6. 几个只有真跑过才会知道的小细节

到这儿功能层面已经讲完了，剩下的是些零碎的实战体会，都是我踩过之后才明白的。

6.1 执行顺序、并发与超时

如果一条请求同时命中重写和断点，Charles 的处理顺序大概是：先应用重写规则、再触发断点。这意味着你在断点窗口里看到的，已经是重写之后的内容，而不是服务端返回的原始内容。这个行为一开始很反直觉，我第一次遇到时以为是重写没生效，排查了半天。

并发方面，断点是"逐条阻塞"的：被断点命中的请求会停下来，没命中的照常转发。但如果你把断点打在了某个关键接口上，页面上的其他请求已经回来了，唯独那一条挂着，前端可能会呈现出一个"数据一半有一半没有"的诡异状态。这种时候先别怀疑代码，看看 Charles 里是不是有断点挂着。

超时是断点的天然敌人。我的做法是调试期间把客户端的超时时间临时调大（如果是自己写的客户端代码，改个常量就行；如果是打包好的包，那就只能手快）。还有一个技巧：在断点窗口里点完 Execute 之后，如果客户端已经超时断开，可以在会话列表里选中那条请求按 Repeat 重发，不用重新走一遍页面流程。

6.2 性能代价与"看起来能改其实改不了"的地方

开着 SSL Proxying 全量解密，长时间调试会明显感觉到响应变慢，尤其是图片多的页面。这不是错觉，每条 HTTPS 都要多一次握手和加解密。调试时尽量把 SSL Proxying 的域名列表收窄。

另外有几类东西是 Charles 改不了的，认清楚能省很多时间。WebSocket 建立之后的帧内容，Charles 能看到但没法用重写去改帧；它就是透传。同理，基于 TCP 的自定义协议、本地文件读写、走的是原生 socket 而不是 HTTP 的库（部分推送通道就是这样），这些都不经过 HTTP 代理，Charles 看不到也改不了。遇到"某条关键请求怎么都抓不到"，先想想它是不是压根没走 HTTP。

还有一个小坑：如果你同时开着多个抓包工具，端口会打架。查问题时如果发现某些请求时好时坏、偶尔串味，先看看是不是有另一个工具也在监听同一个端口。

最后分享个我常年的习惯：调完之后一定要把重写规则集和 SSL Proxying 关掉，尤其是重写。忘了关的后果是几天后你对着一个"服务端明明改了但客户端显示还是老值"的 bug 排查一整天——因为规则的响应改写在中间悄悄生效了。这种事我干过不止一次，现在固定动作是关掉 Charles 之前扫一眼 Tools 菜单里哪些规则集还亮着。

把断点当探针、把重写当生产线、把证书信任当作一切的前提，这三件事想清楚了，Charles 就不只是个看包的工具了。真正好用的调试环境不是配得多复杂，而是配完之后你几乎感觉不到它的存在，只是恰好那个接口返回了你想要的坏数据。