1. 为什么我要在三个平台上折腾同一套抓包流程
做移动端和桌面端联调的朋友大概率都遇到过这种场景：后端同学说接口返回没问题，前端同学说数据没收到，iOS 端说 Android 端能跑，Android 端说 iOS 端能跑，最后发现是某个平台上的证书没装对，或者代理没生效。抓包这件事，单平台跑通不难，难的是在 Windows、iPhone、Linux 三个平台上用同一套思路把链路打通，并且能互相印证。
我这次做的事情，就是拿一个具体的业务场景，在三个平台上分别抓一遍同样的请求，对比差异、记录坑点、整理出一套可以复用的流程。核心目标有三个：第一，确认每个平台上抓包工具能正常解密 HTTPS 流量；第二，搞清楚三个平台在证书信任机制上的差异；第三，沉淀一份遇到问题时能快速定位的排查清单。
这篇文章适合谁看？如果你是会写一点代码、需要调试自己 App 或者网页请求的开发者，或者你是测试同学需要验证接口数据，再或者你只是好奇自己手机上的 App 到底在发什么请求，那这篇内容都能直接拿去用。我不打算讲太多理论，重点放在“我实际怎么做的”和“哪里容易翻车”。
抓包工具的选择上，Windows 和 Linux 我用的都是 Fiddler 和 Charles 这类主流工具的思路，iPhone 上则是通过代理方式把流量导到桌面端工具里。需要提前说明的是，下面提到的所有操作都仅用于调试自己拥有或已获授权的应用和设备，不要拿去抓别人的流量，这是底线。
2. 三平台抓包的整体设计与工具选型思路
2.1 为什么选代理式抓包而不是其他方案
抓包方案大致分几类：代理式、网卡混杂模式、Hook 注入、系统级抓包驱动。我选代理式，原因很直接：跨平台一致性最好。代理式抓包的本质是在客户端和服务器之间插一个中间人，客户端把请求发给代理，代理转发给服务器，再把响应传回来。只要客户端支持设置 HTTP 代理，这套逻辑在 Windows、iPhone、Linux 上都能跑通。
代理式抓包的另一个好处是解密 HTTPS 的门槛相对低。工具会生成一张自己的根证书，你把这根证书装到客户端并设为信任，工具就能用这张证书给每个域名动态签发证书，从而解密流量。这个机制在三个平台上原理一样，但“怎么让系统信任这张证书”差别很大，这也是后面踩坑最多的地方。
相比之下，Hook 注入方案虽然能抓到不走代理的流量，但需要越狱或者 root，而且不同系统版本兼容性差，不适合作为通用方案。网卡混杂模式只能看到明文，HTTPS 全是乱码。所以代理式是性价比最高的起点。
2.2 三个平台的角色分工
我把三个平台分成两类角色：抓包工具运行端和被抓包端。Windows 和 Linux 既可以跑抓包工具，也可以作为被抓包的对象；iPhone 通常只作为被抓包端，把流量代理到桌面端的工具上。
具体分工是这样的：Windows 上跑 Fiddler 或者 Charles 作为主抓包工具，同时 Windows 本身也作为被测对象抓本机请求；Linux 上跑 Charles 或者 mitmproxy，验证在命令行环境下抓包和证书配置的差异；iPhone 上通过 Wi-Fi 代理把流量指向 Windows 或 Linux 上的抓包工具，验证移动端的证书信任流程。
这样安排的好处是，Windows 作为主力工具端，Linux 作为补充验证端，iPhone 作为移动端代表。三者结合基本覆盖了日常开发中会遇到的所有场景。
2.3 工具选型的几个关键考量
Fiddler 和 Charles 是我主要用的两个工具。Fiddler 在 Windows 上体验最好，免费版功能就够用，界面直观，过滤和断点功能都很顺手。Charles 跨平台做得好，Windows、Linux、macOS 都有版本，界面统一，适合需要在多个系统间切换的人。mitmproxy 是命令行的，适合 Linux 服务器环境或者需要脚本化处理的场景。
选哪个工具，我一般看三点：一是目标平台有没有原生支持，二是证书安装流程是否清晰，三是能不能方便地导出和对比请求。Fiddler 在 Windows 上证书安装几乎是一键的，Charles 在 Linux 上需要手动处理系统证书库，mitmproxy 则完全靠命令行。这三个工具我都实际跑过，下面会分别讲。
提示：不管用哪个工具，第一次配置时都建议先抓一个简单的 HTTP 请求验证代理是否生效，再上 HTTPS。直接上 HTTPS 容易在证书环节卡住，分不清是代理问题还是证书问题。
3. Windows 平台抓包实操与证书配置细节
3.1 Fiddler 的安装与基础代理设置
Windows 上我首选 Fiddler Classic。安装过程没什么好说的，一路下一步就行。装完之后第一件事是确认代理端口，默认是 8888。打开 Fiddler，点 Tools 菜单下的 Options，在 Connections 标签页里能看到端口设置。我一般会勾上“Allow remote computers to connect”，这样 iPhone 才能把流量代理过来。
这里有个细节：勾选允许远程连接后，Fiddler 会提示需要重启，而且 Windows 防火墙可能会弹窗询问是否允许。一定要点允许，否则 iPhone 连不上。如果当时手滑点了取消，可以去 Windows 防火墙的入站规则里手动放行 8888 端口。
代理设置好之后，Fiddler 会自动把 Windows 系统的 WinINET 代理指向自己。也就是说，浏览器和大部分走系统代理的应用，流量会自动经过 Fiddler。但有些应用不走系统代理，比如某些用 Java 或者 Go 写的程序，需要单独配置。这一点在后面 Linux 部分也会提到。
3.2 HTTPS 解密与根证书信任
Fiddler 默认只抓 HTTP，要抓 HTTPS 得在 Options 的 HTTPS 标签页里勾上“Capture HTTPS CONNECTs”和“Decrypt HTTPS traffic”。勾上之后会提示安装根证书，点“Yes”就行。Fiddler 会把证书装到 Windows 的证书存储里，并且自动设为信任。
但这里有个坑：Fiddler 的证书默认装在“个人”存储区，有些应用只信任“受信任的根证书颁发机构”里的证书。如果发现某个应用抓不到 HTTPS，可以去 certmgr.msc 里检查一下 Fiddler 的证书在不在受信任根证书列表里。不在的话，手动把证书从个人区导出，再导入到受信任根证书区。
另一个坑是证书过期。Fiddler 的根证书有有效期，过期后所有 HTTPS 都会报证书错误。解决办法是在 HTTPS 标签页里点“Actions”，选“Reset All Certificates”，重新生成一张。这个操作会清掉旧的证书并装新的，一般能解决大部分证书相关的报错。
3.3 抓本机请求的注意事项
抓 Windows 本机请求时，最容易遇到的问题是“为什么这个应用的请求没出现”。原因通常是这个应用不走系统代理。比如用 Electron 写的桌面应用，有些版本会忽略系统代理设置；再比如用 Python requests 库写的脚本，默认也不走系统代理。
遇到这种情况，我的做法是分两步排查。第一步，先用浏览器访问一个 HTTPS 网站，确认 Fiddler 能抓到浏览器的流量，说明代理和证书都没问题。第二步，针对目标应用，看它有没有自己的代理设置项，或者能不能通过环境变量指定代理。比如很多命令行工具认 HTTP_PROXY 和 HTTPS_PROXY 这两个环境变量，设置一下就能走代理。
还有一个常见问题是 localhost 请求抓不到。Fiddler 默认不抓 localhost 的流量，因为本机回环流量不走网卡。如果调试的是本地服务，需要在 Fiddler 的规则里加一条，把 localhost 的请求也导进来。具体做法是在 Custom Rules 里改 OnBeforeRequest 函数，把 localhost 的判断去掉。这个改动不大，但能省很多事。
3.4 Windows 抓包的经验总结
Windows 上抓包整体是最顺的，因为 Fiddler 和系统集成得好。我的经验是：装完工具先别急着抓业务，先抓一个自己写的简单请求，把代理、证书、解密三个环节都验证一遍。验证通过后再上真实业务，这样出问题时能快速定位是哪个环节的问题。
另外，Fiddler 的过滤器功能很实用。抓包时流量很多，可以用 Filters 标签页按域名、按进程、按响应码过滤，只看自己关心的请求。我一般会先按域名过滤，把无关的第三方请求都屏蔽掉，界面清爽很多。
4. iPhone 端抓包配置与证书信任的完整流程
4.1 让 iPhone 流量走代理
iPhone 抓包的第一步是让手机流量经过桌面端的抓包工具。前提是手机和电脑在同一个 Wi-Fi 网络下。打开 iPhone 的设置，进无线局域网，点当前连接的 Wi-Fi 右边的信息按钮，滑到最下面找到“配置代理”，改成“手动”，服务器填电脑的局域网 IP，端口填抓包工具的端口，比如 8888。
电脑的局域网 IP 可以在命令行里用 ipconfig 查看，找 IPv4 地址那一项。填完之后，iPhone 的流量就会走电脑上的抓包工具。这时候在 Fiddler 里应该能看到手机发出来的请求，但 HTTPS 的还是乱码，因为证书还没装。
这里有个常见问题：填完代理后 iPhone 上不了网。原因通常是电脑防火墙拦了，或者 IP 填错了。排查方法是先在电脑上用浏览器访问一下抓包工具的端口，看能不能打开；然后在 iPhone 的 Safari 里访问一个 HTTP 网站，看 Fiddler 里有没有记录。如果 Fiddler 里有记录但手机显示打不开网页，说明代理通了但转发有问题，检查一下抓包工具是不是卡在某个断点上。
4.2 安装并信任根证书
HTTPS 解密的关键一步是把抓包工具的根证书装到 iPhone 上并设为信任。Fiddler 和 Charles 都提供了一个下载证书的地址，通常是 http://电脑IP:端口。用 iPhone 的 Safari 打开这个地址，会提示下载一个证书文件。
下载完成后，去设置里会看到“已下载描述文件”的提示，点进去安装。安装完描述文件还不算完，还得去“设置 - 通用 - 关于本机 - 证书信任设置”里，把刚才装的证书对应的开关打开。这一步很多人会漏掉，结果就是描述文件装了但 HTTPS 还是抓不到。
注意：iOS 对证书信任的管理比较严格，描述文件安装和证书信任是两个独立步骤。只装描述文件不打开信任开关，系统不会把这张证书当作可信根证书，HTTPS 解密就会失败。
4.3 iOS 版本差异带来的坑
不同 iOS 版本在证书信任流程上有差异。较新的版本把证书信任设置藏得更深，而且每次系统大版本更新后，有些用户会发现之前装好的证书失效了，需要重新信任。我遇到过升级系统后抓包突然不行的情况，排查半天发现是证书信任开关被重置了。
另一个坑是某些 App 使用了证书固定（SSL Pinning），即使你装了根证书，这些 App 也不信任，HTTPS 依然抓不到。这种情况在银行类、支付类 App 上很常见。遇到这种 App，代理式抓包基本无解，除非用更高级的手段，但那超出了本文的范围，也不建议普通开发者去折腾。
我的建议是：抓包前先确认目标 App 有没有做证书固定。可以先用 Safari 访问一个 HTTPS 网站，如果 Safari 能抓到，说明证书配置没问题，那抓不到 App 的请求大概率就是证书固定导致的。
4.4 iPhone 抓包的实操心得
iPhone 上抓包最耗时的部分就是证书。我的经验是，第一次配置时把每一步都截图记下来，包括代理设置、描述文件安装、证书信任开关的位置。因为 iOS 的设置界面经常变，下次换手机或者升级系统后，照着截图走能省很多时间。
还有一点，抓完包记得把代理关掉。iPhone 的代理设置是持久的，如果不关，离开这个 Wi-Fi 后可能上不了网。我一般抓完包就把代理改回“关闭”，避免影响日常使用。
5. Linux 平台抓包与命令行工具的组合用法
5.1 Linux 上抓包工具的选择
Linux 上我主要用两种方案：图形界面用 Charles，命令行用 mitmproxy。Charles 在 Linux 上有安装包，界面和 Windows 版一致，适合习惯图形界面的人。mitmproxy 是纯命令行的，适合在服务器上跑，或者需要写脚本自动处理流量的场景。
如果只是临时抓一下本机请求，用 mitmproxy 最快。装好之后运行 mitmproxy 或者 mitmweb，前者是纯命令行界面，后者会起一个 Web 界面，可以在浏览器里操作。mitmweb 对不熟悉命令行的人更友好，我一般推荐先用 mitmweb 上手。
Charles 在 Linux 上的安装稍微麻烦一点，需要先装 Java 运行环境。装好之后启动，代理设置和 Windows 版一样。但 Linux 上系统代理的配置方式和 Windows 不同，需要手动设置环境变量或者改系统网络设置。
5.2 Linux 系统证书库的处理
Linux 上装根证书比 Windows 和 iPhone 都麻烦，因为不同发行版的证书管理方式不一样。以常见的发行版为例，系统根证书一般放在 /usr/local/share/ca-certificates/ 目录下，把证书文件放进去后运行 update-ca-certificates 命令更新。
但这里有个关键点：系统证书库更新了，不代表所有应用都会用。比如 Firefox 有自己的证书库，不读系统证书库，需要单独导入。再比如 Java 应用有自己的 cacerts 文件，也得单独处理。所以 Linux 上抓 HTTPS，经常出现“curl 能抓到但 Firefox 抓不到”或者反过来情况。
我的做法是分应用处理。命令行工具如 curl、wget，认系统证书库，更新完就行。Firefox 去设置里的隐私与安全，找到证书管理，手动导入。Java 应用用 keytool 命令导入到 cacerts。这样逐个击破，虽然麻烦但最稳妥。
5.3 命令行抓包的实用技巧
mitmproxy 的命令行界面功能很强，但需要记一些快捷键。常用的有：按 f 进入过滤模式，按 i 进入拦截模式，按 q 返回上级。过滤模式可以按域名、按方法、按响应码筛选请求，拦截模式可以修改请求后再放行，调试接口时很有用。
另一个实用功能是 mitmproxy 的脚本能力。可以写一个 Python 脚本，在请求或响应经过时自动处理，比如自动替换某个字段、自动记录特定请求到文件。这个在批量测试时特别方便，比手动一个个看效率高很多。
Linux 上还有一个场景是抓服务器上的流量。如果服务跑在远程 Linux 服务器上，可以在服务器上跑 mitmproxy，然后通过端口转发把流量导到本地来看。不过这种场景涉及网络配置，稍微复杂一些，普通开发调试用得不多。
5.4 Linux 抓包的避坑经验
Linux 上最大的坑就是证书。我踩过好几次，明明系统证书更新了，某个应用还是报证书错误。后来发现是那个应用用了自己的证书库。所以 Linux 上抓 HTTPS，先确认目标应用用哪套证书体系，再决定怎么装证书。
还有一个坑是权限问题。mitmproxy 默认监听 8080 端口，普通用户就能跑。但如果想抓系统级的流量，或者监听 443 端口，就需要 root 权限。我一般不建议用 root 跑抓包工具，安全风险大。更好的做法是用普通用户跑，然后通过环境变量或者应用配置把流量导过来。
6. 三平台抓包常见问题与排查速查
6.1 代理不通的排查顺序
代理不通是最常见的问题，表现是客户端设置了代理但抓包工具里没有任何记录。排查顺序我一般是这样：第一步，确认客户端和抓包工具在同一网络，用 ping 命令测试连通性。第二步，确认抓包工具的端口没有被防火墙拦截，在抓包工具所在机器上用 telnet 测试端口。第三步，确认客户端代理设置里的 IP 和端口没填错。第四步，确认抓包工具本身在正常运行，没有卡在某个断点上。
这四步走完，基本能定位到问题在哪。我遇到最多的是防火墙拦截，尤其是 Windows 上第一次运行 Fiddler 时，防火墙弹窗被忽略了。
6.2 HTTPS 解密失败的常见原因
HTTPS 解密失败的表现是抓包工具里能看到 CONNECT 请求，但看不到具体的请求内容，或者显示证书错误。原因通常有三个：证书没装、证书没被信任、应用做了证书固定。
排查方法是先用浏览器访问一个 HTTPS 网站，如果浏览器能抓到，说明证书没问题，问题在目标应用。如果浏览器也抓不到，那就是证书没装好或者没信任。按平台去检查证书安装和信任设置。
6.3 三平台差异对照表
| 环节 | Windows | iPhone | Linux |
|---|---|---|---|
| 代理设置 | 系统自动或手动 | Wi-Fi 设置里手动 | 环境变量或系统设置 |
| 证书安装 | 工具自动安装 | Safari 下载描述文件 | 手动复制到证书目录 |
| 证书信任 | 自动信任 | 需手动打开信任开关 | 需运行更新命令 |
| 常见坑 | 防火墙拦截 | 信任开关漏开 | 应用自带证书库 |
| 推荐工具 | Fiddler | 代理到桌面工具 | mitmproxy/Charles |
这张表是我实际踩坑后整理的，每次换环境配置时对着看一遍，能省不少时间。
6.4 抓包时的安全与合规提醒
最后必须强调一点：抓包只能用于调试自己拥有或已获授权的应用和设备。抓别人的流量涉及隐私和法律问题，不要碰。另外，抓包工具生成的根证书权限很大，能解密所有经过它的 HTTPS 流量，所以不要在不信任的网络环境里随便开代理，也不要把抓包工具长期开着。
我自己的习惯是，抓完包立刻关掉代理和抓包工具，证书也只在需要时安装。这样虽然每次配置麻烦一点，但安全上更放心。
7. 我在这三个平台折腾下来的一些真实体会
三个平台都跑通之后，我最大的感受是：抓包这件事，工具本身不是难点，难点在于每个平台的信任机制和安全策略不一样。Windows 最省心，因为工具和系统集成得好；iPhone 最麻烦，因为 iOS 对证书信任管得严；Linux 最灵活，但也最需要手动处理各种细节。
如果让我给新手一个建议，我会说：先从 Windows 开始，把代理、证书、解密这三个环节跑通，建立信心。然后再去折腾 iPhone 和 Linux，因为后两者的问题大多是 Windows 上问题的变种，有了基础排查思路后，解决起来会快很多。
另外，抓包工具的选择不用纠结。Fiddler、Charles、mitmproxy 这三个，随便选一个先用起来，核心原理都一样。等真正遇到某个工具解决不了的问题时，再换另一个试试。工具是为人服务的，别在选型上花太多时间。
最后分享一个小技巧：每次配置新环境时，先抓一个自己写的简单请求，比如用 curl 访问一个公开的 HTTP 接口，确认整条链路通了，再上真实业务。这个习惯帮我省了很多“到底是代理问题还是业务问题”的纠结时间。
