ARTICLE DETAIL

资讯详情

深耕网站视觉设计与运营推广的一线实战洞察。

Charles代理进阶:Block、Breakpoint、Rewrite与Map实战指南

Charles代理进阶:Block、Breakpoint、Rewrite与Map实战指南 1. 从“看”到“控”Charles代理工具的进阶玩法如果你用过Charles大概率还停留在“抓包看看”的阶段。这工具界面看着有点老派但它的威力远不止于当一个透明的网络流量观察者。很多开发、测试甚至安全分析的朋友把它当成了瑞士军刀而其中最锋利、最能解决实际问题的几把刀就是标题里提到的这几个功能阻塞Block、拦截Breakpoint、篡改Rewrite和接口重定向Map。这几个词听起来有点技术甚至带点“攻击性”但它们的本质是对网络请求的精细化控制。想象一下这些场景你正在测试一个APP想看看某个关键图片加载失败时页面会不会优雅降级或者后端接口还没开发完但前端需要联调你急需一个能返回模拟数据的“假接口”又或者你想测试APP在弱网环境下的表现但总不能真跑到电梯里去吧这些恰恰是Charles这些进阶功能大显身手的地方。它们让你从一个被动的流量记录员变成了一个主动的网络环境导演可以按需制造各种“剧情”来验证你的应用是否足够健壮。今天我们就抛开基础抓包深入聊聊这几个功能的原理、具体操作和那些官方文档里不会写的实战心得。2. 理解核心Charles如何成为“中间人”在深入每个功能之前我们必须先搞明白Charles运作的基石。它不是一个简单的嗅探器而是一个标准的HTTP/HTTPS代理服务器。当你把设备手机或电脑的网络代理设置为Charles时所有的应用网络请求都会先流经Charles再由Charles转发给真正的目标服务器。服务器的响应也同样会先回到Charles再返回给你的设备。这个“中间人”的位置赋予了Charles无与伦比的操控能力。它可以在请求发出的路上将其“堵住”Block可以在请求/响应的关键时刻“叫停”让你修改Breakpoint可以在数据流过时悄无声息地“掉包”Rewrite甚至可以指挥流量“改道”去另一个地方Map。这一切都建立在SSL代理即安装Charles根证书的基础上否则对于HTTPS流量你只能看到一堆加密的乱码。这里有一个关键细节Charles的操控是基于规则Rules的。无论是阻塞、重写还是重定向你都需要设定匹配条件Match比如URL包含某个关键词、主机名是某个域名等。这种基于规则的设计使得操作可以非常精准只影响你关心的那部分流量而不会干扰其他正常请求。理解了这个“规则引擎”的思维后面所有功能的学习都会事半功倍。2.1 环境准备与证书信任一切操控的前提要让Charles的进阶功能对HTTPS流量生效安装并信任其根证书是第一步也是新手最容易踩坑的一步。操作本身不复杂在Charles的Help - SSL Proxying - Install Charles Root Certificate菜单中可以将证书安装到系统钥匙串或证书存储区。但真正的坑在于“信任”。在macOS的钥匙串访问或Windows的证书管理器中找到名为“Charles Proxy CA”的证书你必须手动将其设置为“始终信任”。我见过太多案例证书安装了但没完全信任导致HTTPS网站显示连接不安全或者APP直接报网络错误。一个快速的验证方法是用浏览器访问https://www.google.com或其他知名HTTPS站点在Charles的SSL Proxying设置中确保该域名已被添加或使用通配符*:*然后查看Charles主界面如果能看到明文的HTTP请求和响应且浏览器不报错才算成功。对于移动设备过程类似但需要先在电脑Charles上获取安装地址Help - SSL Proxying - Install Charles Root Certificate on a Mobile Device然后用手机浏览器访问chls.pro/ssl下载证书。在iOS上下载后需进入“设置 通用 关于本机 证书信任设置”找到Charles Proxy CA并启用完全信任。Android因版本和厂商UI差异较大但核心步骤都是将下载的证书文件安装为“CA证书”。这一步的完整性直接决定了后续所有拦截和篡改功能能否作用于加密流量。3. 精准阻断Block阻塞功能的策略与应用Block功能顾名思义就是让指定的网络请求无法到达服务器或者让服务器的响应无法返回客户端。它在Charles的Tools - Block List...菜单中管理。你可能会想这和直接断网有什么区别区别就在于精准和可控。断网是“无差别攻击”所有请求都失败而Block是“外科手术式打击”只让你指定的请求失败。3.1 配置阻塞规则从简单到复杂启用Block功能后你可以通过Add按钮创建规则。最基本的规则是匹配域名Host和路径Path。例如你想阻塞所有对api.example.com的请求就在Host里填api.example.comPath留空或填*。如果你想更精确比如只阻塞api.example.com/user/profile这个获取用户资料的接口就在Path里填/user/profile。更强大的地方在于Block支持正则表达式Regular Expression。比如你想阻塞所有带版本号的静态资源请求如v1.2.3/main.js可以在Path里填写.*/v\d\.\d\.\d/.*\.(js|css)$。正则表达式给了你极大的灵活性但也要谨慎使用避免误杀正常请求。一个建议是先通过Charles的抓包记录精确复制你需要阻塞的请求的URL部分再从中提取出关键特征来构建规则而不是凭空想象。3.2 实战场景故障模拟与性能边界测试Block功能的核心价值在于模拟异常情况验证程序的健壮性。场景一资源加载失败对UI的影响。前端页面上有一个至关重要的背景图来自static.cdn.com/banner.jpg。你想知道如果这个CDN节点故障图片加载失败页面是空白、崩溃还是有一个友好的占位图此时你只需添加一条阻塞规则Host为static.cdn.comPath为/banner.jpg然后刷新页面。你会发现这个请求在Charles的序列视图Sequence里会显示为Blocked状态根本不会发出去。这时观察你的页面表现就能直观地看到处理逻辑是否完善。场景二接口超时或失败的业务流回退。移动端APP在提交订单时会调用pay.example.com/submit接口。你想测试在支付环节网络异常时APP是否会提示“支付失败请重试”而不是卡死或崩溃。除了阻塞你还可以结合下面要讲的Breakpoint先阻塞请求模拟网络超时一段时间后再放行观察客户端的超时处理和重试机制。更真实的做法是不直接Block而是用Rewrite功能后面会讲将响应状态码改为500 Internal Server Error或408 Request Timeout这能更真实地模拟服务器端或网络层错误。一个重要的心得单纯阻塞请求客户端收不到任何响应和返回一个错误HTTP状态码对客户端代码来说触发的是不同的异常处理分支。前者通常会被网络库归类为“网络连接错误”后者则是“服务器错误”。你的测试应该覆盖这两种情况。Block功能更适合模拟前者而Rewrite更适合模拟后者。4. 实时干预Breakpoint断点的拦截与修改艺术如果说Block是“一枪毙命”那么Breakpoint就是“活体解剖”。它允许你在HTTP请求发送前或响应返回前暂停这个传输过程让你有机会查看并修改其中的任何内容——URL、请求头、请求体、响应头、响应体。这个功能在Proxy - Breakpoint Settings...中设置。4.1 断点的工作机制与配置要点启用Breakpoint后你可以指定需要中断的请求同样基于Host和Path规则。当一个匹配的请求发生时Charles会弹出一个可编辑的窗口左边是即将发出的请求如果你在请求阶段中断右边是即将返回的响应如果你在响应阶段中断。你可以修改任何内容然后点击Execute继续或Abort终止。这里有一个极其关键的细节Breakpoint会真正暂停网络线程。这意味着如果你在手机上中断了一个请求那么整个APP的网络请求线程通常是主线程或某个网络线程会被挂起直到你在Charles上点击Execute。如果中断时间过长可能会导致客户端触发自己的超时机制比如Android的OkHttp默认10秒超时从而在Charles释放请求前客户端就已经因为超时抛出了异常。所以使用Breakpoint做调试时动作要快。为了避免干扰我强烈建议不要使用全局断点Locations里为空表示全部中断而是针对性地添加你需要调试的特定接口。例如只对POST /api/login这个登录接口设置断点。你可以先正常操作一次在Sequence视图里找到这个请求右键选择BreakpointsCharles会自动为你创建一条精确的断点规则。4.2 经典应用场景前后端联调与安全测试场景一修改请求参数测试边界情况。一个商品搜索接口通常传入关键词和分页参数。你想测试如果传入一个超长的关键词比如1000个字符或者分页参数传入一个负数后端如何处理。通过Breakpoint在请求阶段中断你可以轻松地将keyword手机修改为keyword手机手机手机...一千次然后放行观察服务器返回的是截断处理、错误提示还是直接崩溃。这比让前端同事修改代码再打包测试要高效无数倍。场景二篡改响应数据验证前端容错性。用户信息接口正常返回一个JSON里面包含username和balance余额字段。你想测试如果后端返回的数据里balance字段突然变成了一个字符串rich或者这个字段直接缺失了前端页面会不会显示异常、崩溃或者有默认值兜底。在响应阶段中断直接修改JSON内容然后放行就能立刻在APP或页面上看到效果。场景三安全测试——越权操作尝试。这是一个Breakpoint在安全领域的典型应用。假设你发现一个请求头里带着Authorization: Bearer user_token_123通过这个token可以访问用户A的数据。你可以尝试复制这个请求在Breakpoint里将token替换成另一个用户的token如果你有或者修改请求体里的用户ID参数尝试访问用户B的数据。然后观察服务器是返回“403 Forbidden”正确地拒绝了请求还是错误地返回了用户B的敏感信息。这种测试必须在授权范围内进行切勿用于非法攻击。注意使用Breakpoint修改HTTPS请求/响应体时确保Charles的SSL代理对该域名已启用否则你看到的将是乱码无法编辑。5. 自动化改写Rewrite重写规则的批量魔法Breakpoint虽然强大但它是手动的、一次性的。如果你需要对大量请求或响应进行某种固定的修改比如在开发环境中给所有请求添加一个调试头或者将生产环境的图片请求指向本地的测试图片手动一个个中断修改会累死。这时就需要Rewrite功能。它在Tools - Rewrite...中配置其核心思想是定义一组“查找并替换”规则当流量匹配条件时自动执行修改。5.1 规则配置详解类型、位置与值一个Rewrite规则集Set包含多个规则Rule。每个规则需要定义几个关键部分Type类型你要修改什么是请求头Request Headers、响应头Response Headers、请求体Request Body还是响应体Response Body甚至可以直接修改URL的Host、Path、Port等。Where位置匹配条件。和Block、Breakpoint一样通过Host、Path等来限定规则的作用范围。Action动作通常是“Replace”或“Add”。Match匹配与 Replace替换对于“Replace”你需要指定匹配的字符串或正则和要替换成的内容。举个例子一个非常实用的规则为所有发往测试环境的请求自动添加一个认证头。Location: 匹配你的测试服务器域名如test-api.example.com。Rule Type:Request HeadersAction:Add(如果头不存在) 或Replace(如果已存在)Header Name:X-Test-AuthValue:your_secret_token_here这样配置后任何发往test-api.example.com的请求都会自动带上这个头省去了你在每个客户端手动设置的麻烦。5.2 高阶应用环境模拟与数据MockRewrite的真正威力在于其批量处理和正则表达式能力。应用一将生产环境静态资源指向本地加速调试。前端页面引用了生产CDN上的数十个JS、CSS文件每次修改都要部署到CDN才能测试效率极低。你可以创建一条Rewrite规则Location: Host matchescdn.production.comRule Type:HostMatch:cdn.production.comReplace:localhost(或者你本地静态服务器的IP) 同时你可能还需要一条规则修改Path或者在你的本地服务器上建立相同的目录结构来提供文件。这样浏览器请求https://cdn.production.com/static/app.js时会被Charles重写到http://localhost/static/app.js直接使用你本地最新的文件。应用二修改API响应模拟特定数据状态。假设你正在开发一个会员等级系统需要测试“钻石会员”的UI展示。但你的测试账号只是普通会员。你可以对用户信息接口的响应体进行RewriteLocation: Path matches/api/user/profileRule Type:Response Body(注意需要启用Enable Response Body选项)Match:level:regularReplace:level:diamond这里有一个巨坑如果响应是Gzip压缩的Charles默认展示和Rewrite的是解压后的内容。但你的Match规则是针对解压后的文本字符串。这通常没问题但要确保你的替换字符串长度不会导致压缩后的数据格式错乱。对于JSON响应更安全的做法是结合Map Local或Map Remote功能下文会讲直接替换整个响应文件。应用三全局修改响应内容进行A/B测试。你想测试网站上一个按钮的文案“立即购买”和“马上抢购”哪个点击率更高。如果文案是后端接口返回的你可以写一条Rewrite规则将响应JSON中button_text字段的值从“立即购买”替换为“马上抢购”无需前后端发布任何代码即可让一部分用户看到不同的版本。6. 流量改道Map映射功能的本地与远程重定向Map功能是Rewrite的一个特化和强化专门用于重定向整个请求。它分为两种Map Local和Map Remote。前者将请求映射到本地文件后者将请求映射到另一个远程地址。它们在Tools - Map Local...和Tools - Map Remote...中设置。6.1 Map Local极速本地Mock的利器Map Local 的核心思想是“这个网络请求别发了直接返回我电脑上的这个文件作为响应。”这是前端和后端并行开发时的神器。配置与使用你只需要指定匹配的请求如https://api.example.com/v1/users和一个本地的JSON文件路径如/Users/yourname/mock_data/users.json。当Charles捕获到匹配的请求时它会立即中断向真实服务器的请求并直接读取你指定的本地文件将其内容作为HTTP响应返回给客户端。响应头如Content-Type会根据文件扩展名自动推断你也可以在规则中手动设置。实战场景与避坑指南场景后端接口延迟前端需要数据联调。后端同事说用户列表接口/v1/users下周才能好但你现在就要开发前端列表页。你可以让后端提供一个接口的JSON Schema或者自己根据文档 mock 一个数据文件users.json。然后在Charles中设置Map Local将对该接口的请求指向这个文件。前端代码无需任何修改就能收到看起来“像真的一样”的数据进行页面渲染和交互逻辑的开发。避坑点1动态接口与静态文件的矛盾。Map Local返回的是静态文件。如果你的接口是动态的比如分页查询/v1/users?page2你本地只有一个users.json文件那么无论page参数是多少返回的都是同一套数据。对于简单的分页你可以创建users_page1.json,users_page2.json等多个文件并使用Charles的{query}变量或更复杂的正则表达式在Path匹配中区分它们但这会变得繁琐。对于复杂的动态Mock可能需要更专业的Mock服务器工具。避坑点2响应头缺失。真实的服务器响应通常带有重要的头信息如分页相关的X-Total-Count或缓存控制头Cache-Control。本地JSON文件无法提供这些。你可以在Map Local的设置中手动添加响应头但这要求你预先知道需要哪些头。一个折中办法是先用Charles抓取一次后端其他类似接口的完整响应包括头部保存为文件然后基于这个文件修改Body部分。6.2 Map Remote无缝切换测试环境Map Remote 的核心思想是“把这个地址的请求转发到另一个地址去。”它不直接返回文件而是做了一次请求的转发。配置与使用配置项通常有From和To。From是你想拦截的原始请求可以包含Protocol, Host, Port, PathTo是你要转发的目标地址。例如你可以将https://production.example.com/api/*的请求映射到http://test-environment.example.com/api/*。核心应用场景场景在生产环境页面上测试新版本的后端服务。假设你的网站www.myapp.com已经在线运行后端API域名为api.myapp.com。现在你在一个测试服务器test-api.myapp.com上部署了一套全新的、尚未上线的新版本API。你想在不修改任何网站前端代码代码指向的还是api.myapp.com的情况下全面测试新API的兼容性。只需在Charles中设置一条Map Remote规则From: Host:api.myapp.com, Path:/*To: Host:test-api.myapp.com这样当你的浏览器访问www.myapp.com时页面加载后发出的所有指向api.myapp.com的API请求都会被Charles透明地转发到test-api.myapp.com。对你来说操作的是完全真实的生产环境前端但背后调用的却是全新的测试后端。这比在代码里写环境判断、切换配置要干净和真实得多。一个高级技巧路径重写。Map Remote的To字段可以只写一部分。比如你的测试环境和生产环境的API路径前缀不同生产是/api/v1/测试是/api/v2/。你可以这样设置From:api.myapp.com/api/v1/(.*)To:test-api.myapp.com/api/v2/$1这里使用了正则捕获组(.*)和引用$1表示将v1后面的所有路径原封不动地附加到v2后面。这提供了非常灵活的重定向能力。7. 组合拳实战复杂场景下的综合运用在实际项目中我们很少孤立地使用某一个功能。更多时候需要将这些功能组合起来模拟出复杂的、贴近真实的测试场景。下面通过一个综合案例展示如何串联使用这些工具。场景测试一个电商APP在“商品详情页 - 加入购物车 - 结算页”流程中的全面容错能力。模拟商品图片加载慢弱网我们不直接Block因为那样太极端。更真实的方法是使用Throttle功能在Proxy - Throttle Settings...中模拟一个慢速网络如256 Kbps并针对图片域名img.cdn.com启用限流。这样图片会加载但非常慢你可以测试页面的加载占位图、超时处理以及用户是否会因等待过久而流失。模拟加入购物车接口偶发性失败使用Rewrite功能。为加入购物车接口POST /api/cart/add创建规则将响应状态码Rule Type:Response Status从200替换为503 Service Unavailable并可以同时修改响应体为一个友好的错误JSON。你可以设置这个规则为“启用”和“禁用”交替模拟服务器不稳定的情况观察APP是否有重试机制、错误提示是否友好。Mock结算页的优惠券和运费计算接口由于结算页依赖的这两个接口后端逻辑复杂且依赖其他系统在开发初期可能不可用。此时使用Map Local是完美选择。让后端或测试提供预期的响应JSON文件分别映射到对应的接口地址。这样前端开发可以独立完成结算页所有UI和交互逻辑的验证。在测试环境将支付请求导向沙箱环境真正的支付接口 (pay.gateway.com) 不能随便调用。在集成测试时我们需要调用支付网关的沙箱环境 (sandbox.pay.gateway.com)。使用Map Remote将所有向pay.gateway.com的请求重定向到sandbox.pay.gateway.com。同时支付回调通知 (notify.myapp.com) 可能也需要从公网映射到你的内网开发机这里可以结合使用反向代理或ngrok等内网穿透工具再通过Charles的Map Remote将回调地址指向穿透后的公网地址。关键步骤的请求/响应审查与篡改在最终测试支付流程时在“提交支付”这个最关键的点上启用Breakpoint。中断请求你可以检查发送给支付网关的金额、订单号等信息是否准确无误。中断响应你可以模拟支付网关返回“支付成功”、“支付失败”、“处理中”等不同状态全面验证客户端的后续处理逻辑跳转成功页、显示失败原因、轮询查询结果等。通过这样一套组合拳你几乎可以在一个可控的环境里模拟出这个电商流程线上可能遇到的大部分异常情况从而极大地提升测试覆盖度和应用质量。Charles不再是一个简单的“抓包工具”而是变成了一个功能强大的“网络环境仿真测试平台”。掌握这些进阶功能能让你在开发、测试、调试甚至问题排查中的效率提升数个量级。
返回列表