做移动端开发和测试这两年Charles基本是我电脑上常驻的工具。平时排查接口问题、看请求参数、抓App的HTTPS包它都是最顺手的那个到了上线前要模拟弱网环境还是它最省事。这篇文章我想把两件事一次讲透一个是Charles抓包的底层原理从代理机制到HTTPS中间人解密到底是怎么运作的另一个是弱网测试的参数怎么设、流程怎么走才能模拟出接近真实的网络状况。如果你在做App开发、客户端测试、接口联调或者性能排查这篇内容值得看完能省掉不少瞎折腾的时间也能帮你真正理解为什么有些包抓不到、为什么弱网参数看起来设了却没生效。1. Charles抓包原理深度拆解中间人到底是怎么当上的1.1 代理的本质请求链路上的中间人我给团队新人讲Charles时最常打的比方是传话。你托朋友去问对方“今天吃什么”朋友跑过去问完再跑回来告诉你整个过程里你和对方没有直接对话但所有信息都经过了朋友。Charles就是这个传话的朋友只不过它传的不是一句话而是一个个HTTP请求和响应。理解了“中间人”这个身份Charles的全部能力就都顺了。它能看所有经过它的数据都能被拦下来解析成可读的请求行、请求头、请求体和响应内容它能改调试时你不用求后端改接口直接在Charles里把响应改成你想要的样子就行它能放决定请求什么时候发出去、以多快的速度发出去。弱网模拟的本质就是利用最后这个“放”的能力在客户端和服务器之间人为加了一段“烂路”让数据走得又慢又抖。这里有个前提要说清楚Charles是应用层代理只处理HTTP和HTTPS流量。它抓不了底层的TCP/UDP原始数据包也管不了不走系统代理的Socket连接。想做那种级别的抓包得换Wireshark。很多人的误区在于装了Charles就以为天下所有包都能抓到结果发现某个App完全没反应就开始怀疑工具坏了——其实不是工具的问题是流量压根就没走Charles这条路。1.2 HTTPS也能看透证书信任与中间人机制纯HTTP时代Charles做代理转发数据明文可见没有任何难度。可现在的App和网站几乎全是HTTPSHTTP层之下多了一层TLS加密。如果Charles只是傻傻地转发它看到的全是一堆密文除了CONNECT请求什么都解析不出来。这也是很多人第一次配好Charles后抓不到内容、列表里一串unknown的根本原因——你没有启用SSL解密或者说证书信任链没打通。Charles的解密思路其实就是安全领域常说的中间人技术只不过它是合法的调试工具。整个流程分四步第一步客户端向服务器发起HTTPS请求Charles拦截这个请求并出示一张由Charles自己的根证书Charles Proxy CA签发的证书。第二步如果客户端信任了Charles的根证书它就会把这张证书当成服务器证书来校验然后与Charles建立一条正常的TLS连接。注意从客户端视角看它认为自己正在和服务器通信实际上另一端是Charles。第三步Charles再作为客户端去和真正的服务器建立另一条TLS连接这一侧服务器校验的是真证书一切正常。第四步两条连接都握在Charles手里它就能把客户端方向解出来的明文再加密发给服务器从服务器方向解出来的明文再加密还给客户端。你来我往所有数据都逃不过它的眼睛。看到这里你就明白了整个环节里最要命的就是第二步——客户端凭什么信任Charles的根证书答案是你得主动帮它建立信任链。电脑上要把证书装进受信任的根证书颁发机构手机上要把描述文件装进去iOS还要额外去“设置 - 通用 - 关于本机 - 证书信任设置”里手动打开开关。这一步漏掉后面全是白忙。另外还有一个很多人忽略的开关Proxy - SSL Proxying Settings。就算证书信任了如果这里没有启用SSL Proxying、没有把目标域名加进列表Charles只会建立CONNECT隧道依然不解密。调试阶段我通常直接填*和443让所有HTTPS流量都走解密正式排查时再按域名收窄减少不必要的性能开销。1.3 抓不到包的三大元凶unknown、SSL Pinning、不走代理先说unknown。这个英文单词在Charles的列表里非常刺眼。它的含义不是“出错了”而是“Charles知道客户端和某个地址建立了连接但无法看到里面的内容”。最常见的原因是SSL解密没开其次是证书没被信任。一旦你看到某个host列出现大量的unknown优先往这两个方向查。再说SSL Pinning。很多金融类、电商类App会在客户端代码里写死服务器证书的指纹做二次校验。即使系统信任了Charles的证书App自己还要再比对一次比对不上直接掐断连接。结果就是证书装了、代理也配了抓包列表里却只有失败记录或者一团unknown。像微信小程序、抖音这类对证书校验比较激进的应用抓包难度天然就比普通App高一个档次。想绕的话需要配合动态插桩工具在运行时hook证书校验逻辑这个放到后面问题排查章节再展开。最后是不走代理。系统代理只对遵守系统网络栈的App生效有些App使用自定义的Socket通道、有些使用了非标准端口、有些根本就是在Native层直接发包这些流量Charles统统看不到。遇到这种情况要么用Wireshark抓底层包要么用透明代理加路由转发把流量强制引过来难度会大不少。测的时候先搞清楚App的网络实现能省很多无用功。2. 弱网测试工程化参数拆解与场景预设2.1 弱网测试测的到底是什么很多团队把弱网测试当成“把网速调慢点看看App卡不卡”这个理解太粗了。线上用户遇到弱网时真正影响体验的往往不是网速本身而是网络抖动和丢包带来的连锁反应请求超时、重试风暴、数据重复提交、本地缓存与服务器状态不一致。弱网测试要做的是把这些恶劣场景提前暴露在测试阶段而不是等用户在网上吐槽了才去修。具体来说弱网下App至少要做对这几件事一是接口超时时间要合理不能一个请求等了几十秒还在转圈二是失败后的重试策略要收敛不能无限重试、不能并发重试三是页面要有明确的加载态和错误态要么骨架屏要么toast不能让用户对着白屏发呆四是涉及支付的场景要保证幂等用户点了一次提交哪怕网络卡了再点一次服务器也不能扣两次钱。所以要测的重点不光是“加载慢不慢”更是“加载挂了之后App怎么表现”。Charles的Throttle功能正好提供了整套参数来模拟这些场景关键是把参数理解到位别只会拉一个带宽滑块。2.2 Throttle Settings六个参数逐项拆解Charles弱网设置的入口在Proxy - Throttle Settings工具栏上那个乌龟图标也是。勾上Enable Throttling后会看到一整套参数我逐个说一下实际理解。带宽单位是kbps代表数据能跑多快。有个很常见的误解是把这里填成文件大小其实它是个速率。想模拟2G网络的话填几十kbps就能明显感觉到卡顿模拟4G或千兆Wi-Fi填几千kbps反而不一定有效果因为Charles限速模型本身是尽力而为的最终还要看实际体感去调。利用率这个概念比较抽象它描述的是带宽的“占用比例”。填100%代表全部带宽都能用上填30%就代表只有三成带宽可用。真实网络很少稳定跑满所以我会习惯把利用率调低一点比如70%左右更贴近现实。往返延迟就是RTT单位毫秒。在请求-响应式的业务模型里延迟比带宽的影响更大。你ping服务端看到的耗时大约是RTT的一半RTT从30ms变成300ms用户点一下要白等半秒体感差异极其明显。弱网场景建议从100ms起步往上调。MTU是网络包的最大尺寸一般默认保持1300到1500就好很少需要动它。它影响的是数据包拆分方式值越小包越碎传输效率越低但在应用层测试里通常感知不明显。可靠性就是丢包率。填90%代表有10%的包会丢。这是最能让接口“看起来像坏了”的参数——一旦丢包触发TCP重传请求时间会被明显拉长严重时直接超时。很多线上弱网问题的根子都出在丢包上测试一定要覆盖。稳定性对应网络抖动填100%代表网络质量稳定填50%代表时好时坏。移动场景下信号本身就忽高忽低地铁里、电梯里、过隧道时都是典型波动场景。做这类场景测试时把稳定性调低才有意义。把这六个参数组合起来才能还原一个“真实感”比较强的弱网环境。我的习惯是先用预设打底再根据实际体感微调而不是凭感觉拍脑袋填数字。这样整条链路的测试数据才有可比性。2.3 实操预设清单不同业务怎么配直接给一套我多年试下来比较顺手的预设你可以按业务直接抄也可以当起点再调。场景带宽往返延迟可靠性稳定性适合验证的内容常规3G780kbps100ms95%80%页面加载、图片压缩、接口超时极端2G40kbps300ms85%60%超时重试、断点续传、失败提示弱Wi-Fi1Mbps50ms97%70%公共Wi-Fi场景、存储型接口地铁/高铁2Mbps200ms90%50%高延迟高抖动、轮询逻辑完全断网关掉Wi-Fi或断代理---离线缓存、首次启动、错误引导实际操作时还要学会组合Charles的其他功能来加强测试。比如用Breakpoints把请求挂起几秒模拟服务器迟迟不响应看App的超时逻辑是否触发用Repeat批量重复请求验证重试会不会造成重复下单。弱网不只是“慢”断断续续、半路没响应、恢复后状态不一致这些都是值得专门设计的用例。3. 手机端抓包与弱网模拟完整实操3.1 环境准备让手机流量走Charles手机端抓包的第一步是让手机的所有HTTP流量都经过Charles这台“传话人”。常规做法是电脑和手机连同一个Wi-Fi在手机Wi-Fi设置里把HTTP代理指到电脑的局域网IP和Charles的端口默认8888。有几个前置细节容易踩坑。第一电脑端要确认Charles的代理开关是打开的Mac上点菜单栏的ProxyWindows上默认会接管系统代理第一次在Windows装Charles的话记得从官网下载安装包装完检查一下系统代理是否被正常接管。第二Windows防火墙如果拦截了8888端口手机是连不上的需要手动放行。第三IP别填错填的是电脑的局域网地址不是127.0.0.1也不是外网地址。最稳的查看方式是在Charles菜单里用Help - Local IP Address它会直接告诉你当前电脑的IP。如果嫌手动在手机上填IP麻烦Charles还提供了更省事的方案用手机浏览器访问代理页面按提示扫码或者直接在Proxy Settings里生成配置二维码。当然最常用的还是手动配代理因为可控性最高排查问题时也最直观。还有一个进阶玩法如果手机和电脑不在同一个Wi-Fi下但你在做Android真机调试可以用USB线连接手机执行一条adb reverse tcp:8888 tcp:8888把手机的8888端口反向映射到电脑的8888端口然后手机代理直接填127.0.0.1:8888。这样既不依赖Wi-Fi也不受路由器隔离限制实测很稳。3.2 证书安装与信任iOS、Android、鸿蒙的区别代理通了之后下一步是装证书目标是让手机信任Charles的根证书。具体下载地址是chls.pro/ssl手机浏览器打开就能拿到。iOS端比较容易踩坑。装完描述文件后你要去“设置 - 通用 - 关于本机 - 证书信任设置”里找到Charles Proxy CA把开关打开。不少人在这一步漏掉结果HTTPS请求全是失败或者unknown。另外iOS的描述文件有时候会被系统清理掉如果发现证书不见了重新下载一次就好。Android端麻烦一点。Android 7.0之后普通App默认不信任用户安装的CA证书即使你把证书装进了“用户凭据”很多App依然不会拿它去校验服务器。想覆盖全量App最稳妥的办法是把证书放进系统凭据存储里这就需要有root权限或者用Magisk模块导入。没有root的测试机退而求其次的选择是优先测试那些在网络安全配置里放开了用户证书的App或者用低版本Android的模拟器来跑。鸿蒙系统这边HarmonyOS NEXT对证书管理有自己的策略。基础流程和Android类似都是在浏览器里下载安装描述文件但证书信任开关的菜单位置不一样需要在“设置 - 安全”里找。由于新一代鸿蒙不再兼容Android APKApp生态变了抓包时你面对的是鸿蒙原生应用它们对证书的校验策略千差万别遇到抓不到的先看是不是App自己做了更严格的校验。不管是哪个平台装完证书后先用手机浏览器打开一个HTTPS网站如果Charles能看到解密后的内容说明证书链路已经打通看不到就先别急着测App把基础链路搞通再说。这一步很重要能帮你把问题隔离在“证书层”而不是“App层”。3.3 弱网测试标准流程从配置到观察点完整的弱网测试流程我一般按下面六步走。第一步正常网络下跑一遍。确认App在Charles里能抓到包、HTTPS能解密然后手工把App的关键页面都点一遍记录每个接口的正常响应时间这组数据是后面的基准线。第二步开启Throttle。进入Proxy - Throttle Settings勾选Enable Throttling按前面第二节的预设选一组参数比如模拟3G网络的780kbps、100ms延迟、95%可靠性。第三步在App里重复触发关键请求。重点看列表刷新、图片加载、提交表单这类核心链路。每触发一次在Charles里记录一次观察Timing面板里的耗时变化和响应状态。第四步观察App表现。这一步最关键记录几个点有没有loading指示、超时时间是不是合理、失败后有没有重试、重试间隔怎么样、失败提示文案是否友好。建议用表格把这些表现记下来方便后面直接对比。第五步切换更恶劣的参数。把可靠性降到85%延迟拉高到300ms再次触发同样的操作看App在极端情况下的表现。真实线上问题大部分在这种条件下才会现出原形。第六步结合Breakpoints和Repeat做补充。Breakpoints可以把请求挂住模拟服务器迟迟不响应Repeat可以连续发出多个请求验证重试逻辑和幂等性。因为“弱网重复请求”是最容易暴露重复下单、重复扣款这类恶性Bug的组合。整个流程跑完你手里就有了一个从正常到极端弱网的表现对照表后面提测、上线都有据可查。4. 高频问题与独家排查经验4.1 HTTPS全是unknown按这个顺序排查遇到HTTPS列表一堆unknown先别慌按顺序查。第一步查SSL解密。打开Proxy - SSL Proxying Settings确认Enable SSL Proxying是勾选状态Location里有没有你正在访问的域名。没有就填*、端口填443把解密范围放开再试。第二步查证书信任。手机上重新检查证书安装状态iOS重点看证书信任开关有没有打开。第三步查App的SSL Pinning。这个最麻烦确认是不是做了二次校验需要配合hook工具处理。第四步查代理是否真的生效。用手机浏览器先访问一个HTTPS页面如果浏览器能抓到、App抓不到问题多半出在App自身。按照这个顺序排查绝大多数unknown问题都能定位。很多人在第一步就翻车证书装了挺高兴结果SSL Proxying里压根没配域名白折腾半天。4.2 乱码和内容显示异常怎么处理很多人看到Charles响应里一堆乱码就以为是工具坏了其实八成是内容编码问题。最常见的三种情况一是gzip压缩没解压Charles一般会自动解压但如果你在配置里把自动解压关了或者服务器返回的是Brotli压缩就会出现乱码。这时候看响应头里的Content-Encoding换成对应的解压方式或者直接用Response选项卡里的Raw模式对比。二是字符编码不对。App用GBK编码Charles用UTF-8解码中文自然变成一堆问号和乱码。这种情况在响应头里往往能看到charsetutf-8或charsetgbkCharles的右键菜单里也可以手动切换编码。三是响应体本身就是二进制比如图片、音视频、压缩文件你拿文本方式去看它当然是乱码。这种情况切换到Hex视图就能看明白了。套路就一条先看响应头确认Content-Type和Content-Encoding再对症下药。绝大多数“乱码”其实是展示方式的问题不是数据真丢了。4.3 手机连不上Charles的常规排查手机怎么都连不上Charles从底层往上捋其实就几个层面连通性、端口、代理设置、系统拦截。连通性层面确认手机和电脑真在同一个局域网互相能ping通。别一会儿连路由器Wi-Fi一会儿连手机热点网络一跳就全断。端口层面查看Charles窗口下面状态栏显示的端口默认8888如果被占用了在Proxy Settings里改掉手机上同步改代理端口。代理设置层面检查手机的代理类型是手动HTTP代理不是别的服务器IP一定是你电脑的局域网IP。系统拦截层面Windows的防火墙偶尔会拦掉8888需要在入站规则里放行同时关掉电脑上其他占用了代理端口的工具避免端口冲突导致Charles收不到流量。还有一个容易被忽略的如果电脑上还开着其他代理类软件它会抢在Charles前面接管系统代理手机流量就被别人截走了。排查时看一眼系统代理设置确保只有Charles在监听。4.4 SSL Pinning的绕过思路前面说了SSL Pinning让证书链路直接断裂。测试时想突破这层限制业内常用的技术路线有两类。一类是动态插桩。借助Frida、objection这类工具在App运行时hook住证书校验的函数让校验直接返回成功。这个方案不依赖root也能用但要具备一定的逆向能力而且App加固做得好时hook难度会直线上升。另一类是改包重打包。直接把App里的证书校验代码干掉再重新签名安装简单粗暴但工作量大而且现在主流App基本都有完整性校验改了包体就拒绝启动。我自己在测试中更推荐先和研发确认测试包能不能临时放开证书校验或者提供一个测试开关。如果实在要自己动手优先上Frida方案因为它对App本体的改动最小换个环境随时能恢复。需要提醒的是绕过SSL Pinning属于安全测试范畴一定要在你有授权的测试环境里做别对着生产环境乱来。4.5 Charles、Fiddler、Wireshark怎么选很多新人会被工具选择搞晕其实三者定位差别很大。Charles是跨平台的图形化代理调试工具界面清晰、移动端配套完善日常App开发和接口调试选它最合适。Fiddler是老牌工具脚本能力强但主要面向Windows生态配置起来比Charles繁琐一点Windows团队里用它的也很多。Wireshark走的是另一条路线它是包级分析工具抓取的原始数据包不经过应用层语义解析适合排查底层网络问题比如TCP重传、DNS解析、延迟分布但它不关心HTTP业务层也没法像Charles一样方便地改请求改响应。用一张表快速对照对比项CharlesFiddlerWireshark主用平台Mac/WindowsWindows/Mac跨平台抓包层级应用层HTTP(S)应用层HTTP(S)网络层数据包HTTPS解密支持图形化操作支持需配置脚本需要预共享密钥等高级设置弱网模拟内置Throttle内置模拟调制解调器不支持需配合系统流量控制工具请求篡改Breakpoints/RewriteFiddlerScript钩子基本不支持上手难度较低中等较高我的结论是移动端App开发和测试首选CharlesWindows环境下团队协作Fiddler也够用做底层网络分析和故障定位上Wireshark。三者不是竞争关系而是覆盖链路的不同层次。4.6 几个让效率翻倍的小技巧最后分享几个Charles的实用技巧都是我平时用得最多的。第一个是Map功能。Map Local可以把某个接口的响应直接映射到本地文件非常适合Mock数据Map Remote可以把一个域名转发到另一个环境联调时不用改代码就能切换环境。第二个是Repeat功能右键一个请求选Repeat就能直接重放压测或者验证重复提交非常好用。第三个是Focus和Filter请求一多列表就乱用Focus把关心的域名置顶再用Filter按关键词过滤URL效率立刻提升。第四个是保存会话File - Save Session把一次完整的抓包记录存下来后面复盘或者提Bug时附上这个文件研发还原问题会快很多。还有个跨平台折腾的提醒网上那些所谓汉化版翻译质量和时效性参差不齐而且来源不明的汉化包有夹带的风险建议还是用官方原版配合中文教程理解界面即可别为了省几个英文单词给自己埋雷。我个人这两年用下来最大的体会是Charles也好、弱网测试也罢真正的价值不在于工具本身而在于你能不能根据工具的反馈看懂App的真实网络表现。原理层面搞懂中间人机制遇到抓不到包时才能有条理地排查而不是瞎点点碰运气参数层面理解带宽、延迟、丢包各自的影响弱网测试才能覆盖到“想象中会发生”的问题之外的那些真实坑。如果你刚上手Charles别急着把所有按钮都点一遍就按这篇文章的顺序先跑通一次HTTP抓包再解开HTTPS再做一次像模像样的弱网测试相信你会比那些只会看流量监控数字的人更懂自己的App。