抓包技术-Web应用-http/s-Burp&Yakit
作为有编程经验的你，可能经常用浏览器F12开发者工具查看网络请求，但那个调试面板只能被动观察，如果你想主动修改请求包、重放攻击、或者查看HTTPS加密后的真实内容，就需要更专业的抓包工具。抓包技术在Web安全中就像是“网络显微镜”，让我们能看清客户端和服务器之间的每一次对话，甚至能中途篡改对话内容。今天我们就聚焦Web应用中的HTTP和HTTPS协议，并介绍两大主流抓包工具：Burp Suite和Yakit。
在深入工具之前，我们先要理解HTTP和HTTPS的本质区别。HTTP是明文协议，所有传输的数据都可以被直接读取，就像寄明信片；而HTTPS通过TLS/SSL加密，相当于把明信片装进了只有收发双方能打开的保险箱。但作为安全测试人员，我们恰恰需要查看和修改这些加密流量，这就引出了抓包工具的核心机制——中间人代理。抓包工具在客户端和服务端之间扮演“双面间谍”：对客户端它伪装成服务端，对服务端它又伪装成客户端，从而解密流量，让我们能看到明文并任意修改。这个机制的关键在于让客户端信任抓包工具提供的伪造证书，所以我们需要提前把抓包工具的CA证书安装到操作系统的受信任根证书列表里。
Mermaid 图表：HTTPS中间人抓包原理图
这张图里，客户端首先向抓包工具发起CONNECT请求，这是HTTP代理的标准握手；抓包工具立刻返回一个由它自己的CA证书签名的伪造服务器证书，因为客户端已经信任了这个CA，所以TLS连接成功建立。同时，抓包工具作为客户端与真正的服务端建立另一个TLS连接。这样一来，抓包工具就能看到从客户端发来的明文请求（比如登录密码），也能看到从服务端返回的明文响应，而且还能在转发前修改它们。整个过程对客户端和服务端都是透明的，但双方其实都在跟抓包工具对话。
接下来我们看第一个主力工具：Burp Suite。它是由PortSwigger公司开发的Java平台Web安全测试套件，功能极其丰富。在抓包这个场景下，最核心的模块是Proxy（代理），它负责拦截和转发流量；Target（目标域）帮你整理站点地图；Repeater（重放器）让你手动修改请求并反复发送；Intruder（入侵者）用于自动化参数枚举和爆破；Scanner（扫描器）能主动发现漏洞；还有Decoder、Comparer等辅助工具。Burp之所以成为行业标准，是因为它的模块化设计让测试流程非常顺畅：你从Proxy抓到请求，然后一键发送给其他模块做深入测试，所有操作都在图形界面里完成。
Mermaid 图表：Burp Suite 核心组件协作关系
这张图展示了Burp的工作流程：客户端流量通过代理设置进入Burp Proxy，我们在Proxy界面看到拦截的请求，可以选择放行（Forward）或丢弃（Drop），也可以右键把请求发送到Repeater、Intruder或Scanner进行深度测试。所有经过代理的流量都会被记录在HTTP History里，并自动归类到Target的站点地图，方便我们梳理应用的攻击面。箭头表示数据流向和用户操作路径，整个过程非常直观。
安装和配置Burp也很简单：从官网下载社区版或专业版，启动后默认代理监听地址是127.0.0.1:8080。在浏览器里设置HTTP代理为localhost:8080，然后访问http://burp 即可下载CA证书。根据操作系统不同，把证书导入到受信任的根证书颁发机构列表里，这样就能解密HTTPS流量了。测试是否成功：访问任意HTTPS网站，如果Burp的Proxy -> HTTP History里能看到明文请求和响应，说明配置正确。
另一个值得一提的工具是Yakit，它是近年来国内流行的集成化安全测试平台，基于Yaklang语言驱动，内置了MITM代理、端口扫描、漏洞利用等模块。Yakit的MITM代理与Burp Proxy功能类似，但它把流量展示和修改做成了Web界面，同时支持通过Yak脚本实现动态劫持和自动化逻辑。相比Burp，Yakit更轻量，完全免费，而且与国产生态集成更好，比如内置的漏洞库和插件市场对国内常见应用做了优化。
Mermaid 图表：Yakit MITM模块与Burp对比
这张图对比了Yakit和Burp的MITM模块架构。左侧Yakit中，MITM代理捕获流量后一方面在Web界面展示，另一方面可以通过Yak引擎执行热加载脚本，动态修改请求或响应，这种设计非常适合编写自动化测试逻辑。右侧Burp则通过Java扩展机制（BApp商店）来增强功能，生态更成熟但扩展开发门槛较高。两者都能实现抓包和篡改，但实现思路不同：Yakit倾向于脚本化，Burp倾向于图形化加扩展。
现在看一个典型场景：测试一个Web登录接口是否存在SQL注入。假设目标站点是http://example.com/login ，我们用Burp来操作。首先确保浏览器代理指向Burp，并已安装证书。在登录页面输入任意用户名密码（如admin/123456）并提交，Burp Proxy会拦截到这个POST请求。右键请求选择“Send to Repeater”。在Repeater标签页中，我们可以看到完整的原始请求包：
POST /login HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) ...
Content-Type: application/x-www-form-urlencoded
Content-Length: 29
username=admin&password=123456在Repeater里，我们可以修改username参数的值，比如改成 admin' OR '1'='1，然后点击“Go”发送。观察响应内容，如果返回了登录成功的页面特征（比如跳转到首页），就说明存在SQL注入漏洞。这个过程中，Burp让我们能任意篡改请求并看到实时响应，比浏览器F12强大得多。
最容易踩的坑主要有三个。第一是证书安装失败，导致无法抓取HTTPS包，症状是浏览器显示证书错误或连接不安全。正确做法是确认抓包工具的CA证书已经正确导入到系统受信任的根证书存储中，并且没有过期。在移动端抓包更复杂，比如Android 7以上默认不信任用户安装的证书，需要将证书安装到系统证书目录（需root）或使用VirtualXposed等工具。第二是代理配置遗漏，比如浏览器只设置了HTTP代理，但HTTPS流量依然直连，这时需要把代理设置应用到所有协议。第三是流量被其他代理工具干扰，比如开启了VPN或系统代理，导致Burp收不到流量。验证方法很简单：访问http://burp 能看到Burp的欢迎页面，访问HTTPS网站时Burp历史中有解密后的记录。
下一步建议是联动其他测试模块。比如把抓到的请求直接发送到Burp Scanner进行自动化漏洞扫描，或者导出请求格式后配合SQLMap（加上-r参数）进行更深入的数据库注入测试。对于Yakit，同样可以将抓包数据发送给内置的漏洞检测插件，实现无缝衔接。
最后是决策指南：什么时候必须用Burp？当你需要最全面的Web安全测试功能、庞大的社区支持和丰富的扩展生态时，Burp是无可争议的首选，尤其是专业版自带的主动扫描和爬虫能力能大幅提升效率。什么时候Yakit够用？如果你倾向于国产工具、习惯脚本化操作、或者预算有限，Yakit提供了非常优秀的MITM体验和灵活的Yak脚本能力，对于日常抓包改包和快速漏洞验证完全够用。更轻量级的场景，比如仅仅想查看和解密HTTPS流量，甚至可以使用浏览器的开发者工具（仅查看）或Fiddler（Windows平台），但它们的篡改和自动化能力远不如Burp和Yakit。总之，抓包技术是Web安全测试的基石，掌握了Burp和Yakit，你就拥有了深入剖析Web应用的利器。
抓包技术-APP应用-http/s-Burp&Yakit
当我们把目光从浏览器转向移动端APP时，抓包技术面临新的挑战。APP不像浏览器那样可以轻松设置系统代理，而且移动操作系统对HTTPS证书的管控更加严格，很多APP还实现了证书绑定（SSL Pinning）来防止中间人攻击。但作为安全测试人员，我们依然需要看清APP与服务器之间的加密通信。今天我们就继续沿用Burp Suite和Yakit这两把利器，深入讲解如何在Android和iOS环境下完成APP的HTTP/HTTPS抓包，以及如何应对那些反抓包机制。
移动端抓包的核心场景是什么？比如你正在测试一个电商APP的下单接口，想查看提交订单时发送了哪些参数，或者想篡改商品价格。这时你无法直接从APP内部看到网络请求，必须在设备层面把流量引到抓包工具。这就涉及到网络代理设置和证书管理。与Web抓包最大的区别在于，移动端抓包必须解决两个关键问题：一是如何让APP的流量经过我们指定的代理，二是如何让APP信任抓包工具的CA证书。第二个问题在Android 7.0及以上和较新的iOS版本中尤其棘手，因为系统默认不再信任用户安装的证书，只有系统证书才被认可。此外，一些安全性较高的APP还会在代码中固定校验服务器证书或公钥，这就是证书绑定（SSL Pinning），即使安装了抓包工具的证书，APP依然会拒绝连接。
Mermaid 图表：移动端HTTPS抓包拓扑与挑战
这张图展示了移动端抓包的完整路径和数据流向。APP发起的请求先经过系统网络层，如果我们设置了HTTP代理，流量会被转发到代理客户端（如WiFi代理设置或VPN），然后到达抓包工具。抓包工具用自己的CA证书生成目标服务器的伪造证书返回给设备。此时设备系统或APP会进行证书校验：如果系统不信任抓包工具的CA（用户证书不被信任），或者APP内置了证书固定逻辑（SSL Pinning），校验就会失败，导致连接中断。图中红色部分标出了两个最常见的失败原因，也就是我们接下来要解决的问题。
对于第一个问题——如何让流量经过代理，最直接的方法是在设备的WiFi设置中手动配置HTTP代理，将代理服务器指向运行Burp或Yakit的电脑IP和端口（例如192.168.1.100:8080）。但在某些APP中，可能会忽略系统代理（例如使用OkHttp库时默认遵循代理，但部分APP可能强制使用直连），这时我们可以考虑使用VPN软件将流量转发到抓包工具，比如使用Postern（Android）或BProxy等工具配置VPN转发。另一种方案是在电脑上开一个透明代理，通过ARP欺骗或路由表将设备流量全量转发，但这比较复杂，日常测试用WiFi代理基本够用。
第二个问题更核心：让APP信任我们的证书。在Android上，如果APP的targetSdkVersion低于24（Android 6及以下），用户安装的证书默认就被系统信任，直接安装即可。但从Android 7开始，系统不再信任用户证书，只有安装在系统分区下的证书才被认可。解决方案有两种：一是将设备root，然后把抓包工具的证书推送到系统证书目录（/system/etc/security/cacerts/）。二是使用VirtualXposed等虚拟框架，在框架内运行APP，并安装模块将抓包证书添加到框架的信任域。对于iOS，越狱设备可以安装证书到系统钥匙串，并使用AppSync等绕过签名；非越狱设备则需要借助代理工具如Surge或Quantumult X的MITM功能，并信任其描述文件。至于证书绑定（SSL Pinning），就需要更高级的注入技术，比如用Frida hook证书校验函数，或者使用Xposed模块（如JustTrustMe）一键绕过。
现在来看实际工具的操作。Burp Suite在移动端抓包中的配置与Web端基本一致：启动Burp，在Proxy -> Options中确认代理监听地址为0.0.0.0:8080，这样局域网内的设备才能访问。然后在手机上设置WiFi代理为电脑IP和8080端口。接下来是关键步骤：让手机信任Burp的CA证书。用手机浏览器访问http://burp ，点击右上角的“CA Certificate”下载证书。在Android上，下载的cacert.der文件需要在设置中“从存储设备安装”为CA证书。但如前所述，Android 7+直接安装后仅对部分APP生效（那些显式信任用户证书的APP），大多数APP依然不认。我们需要root设备，然后用adb将证书移到系统目录。具体命令：
# 将der格式转换为pem
openssl x509 -inform DER -in cacert.der -out burp.pem
# 重命名为证书的哈希值.0
mv burp.pem `openssl x509 -inform PEM -subject_hash_old -in burp.pem |head -1`.0
# 挂载系统分区为可读写（假设已root）
adb root
adb remount
# 推送到系统证书目录
adb push <hash>.0 /system/etc/security/cacerts/
# 修改权限
adb shell chmod 644 /system/etc/security/cacerts/<hash>.0之后重启设备，Burp的证书就成为系统证书，所有APP都会信任。
Yakit的配置类似，但Yakit提供了更便捷的移动端抓包辅助功能。在Yakit的MITM界面，可以开启“全局代理”并设置监听地址，同样在手机上设置代理。Yakit也支持自动生成证书，并提供了详细的证书安装指引。值得一提的是，Yakit内置了“热加载”脚本功能，你可以编写Yak脚本在流量经过时动态修改请求或响应，这对于处理某些APP的签名校验或加密参数非常有用。例如，你可以在脚本里自动替换请求中的某个字段，而不必手动修改每个包。
Mermaid 图表：Burp vs Yakit 在移动端抓包的解决方案对比
这张图对比了Burp和Yakit在移动端抓包的扩展能力。Burp主要通过手动配置和外部工具（如Frida、Xposed）的组合来绕过限制；Yakit除了同样需要证书安装，还提供了Yak脚本引擎，你可以直接在脚本里实现类似Frida的Hook逻辑，甚至调用系统命令来辅助抓包，将多个步骤集成在一个界面中。
一个典型场景：测试一个金融APP的转账接口，APP可能使用了证书绑定。我们先用Frida来绕过绑定。假设手机已root并安装了frida-server。运行命令：
frida -U -f com.example.bank -l frida-script.js --no-pause其中frida-script.js可以是常见的绕过证书绑定的脚本，比如：
Java.perform(function() {
var TrustManagerImpl = Java.use('com.android.org.conscrypt.TrustManagerImpl');
TrustManagerImpl.verifyChain.implementation = function(chain, authType, host, clientAuth, ocspData, tlsSctData) {
return chain; // 直接返回原始链，绕过校验
};
});同时，我们让Burp或Yakit处于监听状态，手机代理指向电脑。这样，当APP发送请求时，Frida已经修改了证书校验逻辑，APP会接受Burp的伪造证书，流量顺利到达抓包工具。我们就能在Burp中看到明文的请求参数，比如amount=1000&toAccount=123456，可以尝试修改为amount=1再重放，观察服务器是否校验。
最容易踩的坑包括：忘记关闭手机的VPN或代理冲突，导致流量没有经过Burp；证书安装后忘记重启设备，新证书未生效；移动端使用模拟器时，某些APP会检测模拟器环境并拒绝运行；Frida脚本没有正确附加进程，或者APP有反调试机制导致崩溃。验证方法很简单：在Burp或Yakit的HTTP History中能否看到来自APP的请求。如果能看到但连接失败，可能是证书问题；如果根本看不到请求，则是代理配置问题。
下一步操作建议是联动Burp的扫描功能。抓取到APP的API接口后，可以将请求发送到Scanner进行漏洞扫描，或者导出为文件后用sqlmap测试注入。对于Yakit，可以直接在流量页面上右键选择“漏洞检测”或“端口扫描”，利用内置的POC插件进行自动化测试。
最后是决策指南：什么时候必须用Burp？当你需要全面、成熟的移动端测试环境，并且愿意配合Frida/Xposed等外部工具进行深度定制时，Burp依然是首选，因为它的生态和社区支持最丰富。什么时候Yakit够用？如果你希望在一个工具内完成抓包、脚本绕过和漏洞验证，减少多工具切换的成本，Yakit是更好的选择，特别是它的Yak脚本引擎让自动化变得非常灵活。对于简单的非加固APP，甚至只用Yakit的MITM配合系统证书安装就足够了。但在面对有强证书绑定和反调试的APP时，Burp+Frida的组合往往更稳定，因为Frida的Hook生态更成熟。总之，移动端抓包是对Web抓包技术的延伸和深化，掌握这些技巧后，你就能对任何APP的通信了如指掌。
两篇抓包技术教程的核心区别解析
在分别讲解了Web应用和APP应用的抓包技术之后，我想和你深入聊聊这两者之间的本质区别。理解这些差异，能帮你更清晰地把握不同场景下的测试思路，而不是简单地套用同一套方法。实际上，从浏览器到APP，抓包技术经历了从“简单配置”到“复杂对抗”的演进，这种演进背后反映的是应用安全模型的升级和攻击面的转移。
首先最直观的区别在于抓包的拓扑结构。Web应用中，抓包工具直接运行在PC上，浏览器和工具在同一台机器或同一网络段，代理配置只需要修改浏览器设置，甚至可以用浏览器插件自动切换。流量路径非常短：浏览器 -> 127.0.0.1:8080 -> 互联网。但在APP场景下，抓包工具运行在PC上，APP运行在手机或模拟器上，两者通过WiFi或USB连接。流量路径变成了：APP -> 手机系统网络层 -> WiFi路由器 -> PC抓包工具 -> 互联网。这条路径上多了无线传输和系统网络栈的介入，意味着我们需要考虑网络延迟、信号干扰，以及手机系统对代理的特殊处理（比如Android的VPN代理和WiFi代理可能冲突）。
Mermaid 图表：Web端与移动端抓包拓扑对比
这张图里，Web端的箭头直接从浏览器指向抓包工具，因为代理是本地的；而移动端APP必须经过系统网络层和路由器，物理路径更长，中间环节更多。这就解释了为什么移动端抓包经常遇到代理不生效、连接超时的问题——任何一个中间环节配置错误都会导致失败。
更深层的区别在于证书信任链的管理。Web端抓包时，我们只需要把抓包工具的CA证书安装到操作系统的受信任根证书列表，浏览器会自动继承这个信任。因为桌面操作系统（Windows/macOS/Linux）对用户安装证书的信任策略相对宽松，而且浏览器通常会调用系统证书存储。但移动端完全不同，从Android 7.0（API 24）开始，Google改变了安全策略：系统不再信任用户安装的证书，只有预置在系统分区的证书才被认可。这意味着即使你在手机上通过“从存储设备安装”把Burp的证书装进去，对大多数APP来说它依然无效。iOS也有类似机制，从iOS 10开始，用户安装的证书默认对第三方APP不可信，除非APP显式配置了允许用户证书。
为什么移动操作系统要这么设计？因为手机是个人设备，用户经常连接公共WiFi，如果APP随意信任用户添加的证书，攻击者很容易通过社会工程学让用户安装恶意证书，然后实施中间人攻击。所以操作系统收紧信任策略，本质上是把安全责任从用户转移到了开发者——开发者必须在代码中明确声明是否信任用户证书（通过networkSecurityConfig），或者更激进地实现证书绑定。
Mermaid 图表：证书信任策略的Web与移动端对比
这张图清晰地展示了移动端多出来的两道关卡。左侧Web端是线性信任链，安装即信任；右侧移动端出现了分支，系统默认不信任用户证书（红色），只有APP通过配置声明（信任用户证书）或者绕开证书绑定（红色），流量才能通过。这就是为什么移动端抓包经常需要root、越狱或者使用VirtualXposed——我们必须把抓包证书塞进系统证书存储，让它伪装成系统预装证书，从而绕过APP的默认不信任。
第三个关键区别是反抓包机制的对抗强度。Web应用很少会主动对抗抓包，因为浏览器环境是相对开放的，而且开发者也知道测试人员会使用开发者工具。但APP不同，尤其金融、支付、版权保护类的APP，会主动检测抓包行为并采取反制。最典型的就是证书绑定（SSL Pinning），它在代码中硬编码了服务器的证书或公钥，APP在建立TLS连接时不仅校验系统证书链，还要额外对比服务器返回的证书是否与硬编码值匹配。即使你把抓包工具证书装进系统存储，APP发现证书指纹对不上，依然会断开连接。
对付证书绑定，Web端基本不需要考虑，但移动端必须使用Hook技术，比如Frida或Xposed。我们在第二篇文章里演示了用Frida hook TrustManagerImpl.verifyChain方法，直接让APP跳过证书校验。这种对抗已经超出了抓包工具本身的能力范围，需要引入动态 instrumentation 工具。而Yakit的优势在于可以把这些脚本集成到抓包流程中，让你在同一个界面完成流量捕获和注入绕过。
Mermaid 图表：反抓包机制与对抗技术
这张图展示了反抓包机制和对抗技术的对应关系。左边是APP可能使用的三种反制手段：证书绑定、代理检测（比如调用NetworkCapabilities.hasCapability检测是否设置了代理）、环境检测（检测是否root）。右边是对应的对抗技术：Frida可以动态Hook任意函数，VirtualXposed能在非root环境下运行Xposed模块，JustTrustMe这类模块专门针对常见的证书绑定库进行绕过。Web端几乎没有这类对抗，因为浏览器没有提供这些API让网页检测代理或环境。
从工具使用模式来看，Web端抓包更依赖图形界面和手工操作。你用Burp的Proxy拦截请求，用Repeater手工修改，整个过程是可视化、交互式的。而移动端抓包往往需要结合命令行工具（adb、frida）和脚本编写，自动化程度更高。比如你写一个Frida脚本批量绕过证书绑定，然后用Python调用Burp的API自动标记请求，最后生成测试报告。这种“抓包 + Hook + 自动化”的组合拳，在移动端测试中是常态。
Yakit在移动端的优势恰好体现在这里：它内置了Yak脚本引擎，你可以用Yak语言编写包含Hook逻辑的脚本，在流量经过时动态执行。比如你可以在Yakit的MITM页面加载一个脚本，脚本里调用Frida附加到目标APP进程，自动绕过证书绑定，然后所有流量正常显示。这比在Burp和命令行之间来回切换要流畅得多。
最后是思维模式的区别。Web端抓包时，你的视角是“页面-请求-响应”，思考的是参数、Cookie、Session这些高层概念。移动端抓包则必须深入到系统层，考虑进程、权限、文件系统。你需要知道APP的包名是什么，它的networkSecurityConfig文件放在哪里，是否需要绕过VPN检测。这种从应用层到系统层的视角下沉，是Web开发者转向移动安全时必须跨越的门槛。
总结一下两篇教程的核心区别：
- 拓扑结构：Web端本地代理 vs 移动端跨设备网络转发
- 证书信任：用户证书直接生效 vs 需要系统证书或绕过绑定
- 对抗强度：无对抗或弱对抗 vs 证书绑定、代理检测等主动防御
- 工具组合：单一抓包工具 vs 抓包+Hook+自动化框架
- 思维深度：应用层测试 vs 系统层攻防
理解这些区别后，你再看具体的抓包操作就不会觉得困惑了。比如为什么Web端那么简单，移动端却要root、装框架、写脚本？因为移动端的设计初衷就是阻止中间人攻击，而我们作为测试人员，正是在模拟攻击者的视角突破这些防护。当你掌握了Web和移动端两种抓包技术，你就拥有了从浏览器到APP、从应用到系统的完整测试能力。
抓包技术-PC端应用-http/s-Burp&Yakit
作为开发者，你肯定写过 HTTP 请求，也知道应用通过 SharedPreferences 存了些 token，但当你拿到一个别人开发的 PC 软件（比如游戏、即时通讯工具、某个行业客户端）时，你可能会好奇：它到底在后台给服务器发了什么？有没有上传我的隐私数据？是不是在偷偷下载东西？要回答这些问题，你就需要“抓包”——在软件和服务器之间装一个“监控摄像头”，把双方的通信内容原原本本地记录下来。抓包技术是安全分析、接口逆向、调试网络问题的基础，也是你从“会写代码”进阶到“能看懂任何应用通信”的关键一步。
抓包在整个系统中扮演什么角色？
任何网络通信都遵循客户端‑服务器的模型。正常情况下，你的 PC 应用直接与远程服务器建立 TCP 连接，发送 HTTP 请求，接收响应。抓包工具相当于一个“中间人”，它把自己伪装成目标服务器与客户端通信，同时又作为客户端与真实服务器通信，从而把整个对话过程转录下来。为了实现这一点，抓包工具必须在操作系统层面或应用层面获得网络流量的转发权，通常是以“HTTP 代理”的形式存在。当你在系统网络设置或应用代理设置里填入 127.0.0.1:8080 时，所有 HTTP 和 HTTPS 流量就会被先发送到抓包工具，再由它转发出去。这样一来，抓包工具就能看到、甚至修改请求和响应的内容。
为什么需要这种中间人设计？它具体怎么工作？
对于 HTTP 流量，代理工作很简单：客户端明文发送请求，代理原样转发，同时拷贝一份供你查看。但今天的网络几乎全是 HTTPS（HTTP over SSL/TLS），流量是加密的，代理如果只转发密文，你看到的只会是一堆乱码。为了解决这个问题，抓包工具采用了“中间人（MITM，Man-in-the-Middle）”技术：当客户端试图与服务器建立 TLS 连接时，抓包工具会拦截这个请求，然后自己生成一个伪造的服务器证书，并用这个证书与客户端完成 TLS 握手。同时，抓包工具又与真实的服务器建立另一个 TLS 连接。这样一来，客户端和抓包工具之间的通信是加密的，抓包工具和服务器之间的通信也是加密的，但抓包工具拥有两边的密钥，可以在中间把密文解密成明文后再重新加密转发。你看到的，就是解密后的明文的 HTTP 消息。
为了让客户端信任伪造的证书，你需要把抓包工具自己生成的 CA 根证书安装到操作系统的“受信任的根证书颁发机构”列表里。这样，当抓包工具为任意域名签发即时证书时，系统就会认为这个证书是合法的。整个过程对客户端应用是透明的，它以为自己正和真正的服务器安全通信，其实所有的秘密都被中间人看光了——这就是你主动授权的“监控摄像头”。
Mermaid 图表：HTTPS 中间人抓包原理
这张图里，蓝色方框代表三个角色：你的 PC 应用、抓包工具（Burp/Yakit）、真实服务器。箭头上的数字展示了消息的先后顺序。最关键的是第 3 步：抓包工具返回了伪造的证书，而不是真实服务器的证书，但因为你的系统信任了抓包工具的 CA，所以应用不会报错。第 5 步和第 8 步是抓包工具内部的工作，它把数据解密成明文，你可以看到请求头、请求体、响应内容。整个过程应用和服务器都以为自己在进行端到端的加密通信，实际上所有明文都被你掌握了。
主流抓包工具：Burp Suite 与 Yakit
目前最常用的抓包工具，一个是老牌且功能强大的 Burp Suite，另一个是近年崛起的国产集成工具 Yakit。它们都支持 HTTP/HTTPS 的拦截、查看、修改、重放，也都能作为代理工作。Burp 的社区版免费，功能对于抓包和分析已经足够，它的 UI 比较传统但极其稳定，拥有庞大的插件生态。Yakit 则把很多常见的安全测试功能（比如端口扫描、漏洞验证）集成在一起，界面更现代化，操作更符合国内开发者的习惯，而且它也完全支持作为代理抓包，并内置了类似 Burp 的“Web Fuzzer”用于重放和爆破。两者的核心抓包能力几乎没有差别，你可以根据个人喜好选择。在后续的示例中，我们以 Burp 为主讲解，因为它的配置流程是行业标准，而 Yakit 的操作几乎完全对应。
典型场景：分析 PC 端应用的 API 请求
假设你想分析“网易云音乐”PC 客户端在播放歌曲时调用了哪些接口，有没有上报你的听歌历史。下面是一套完整且可复制的抓包配置步骤。
第一步：设置 Burp 代理监听。 打开 Burp，点击 Proxy 选项卡，再点击 Options。在 Proxy Listeners 区域，点击 Add，绑定地址选 127.0.0.1，端口填 8080，勾选“Running”启用。这样 Burp 就在本地的 8080 端口开启了 HTTP 代理服务。
第二步：导出并安装 Burp 的 CA 证书。 为了解密 HTTPS，需要让系统信任 Burp 的根证书。在 Burp 中，点击 Proxy 选项卡下的 Intercept，确保拦截关闭（Intercept is off）。然后访问 http://burp（直接在浏览器里打开），点击右上角的“CA Certificate”下载证书文件 cacert.der。对于 Windows，双击下载的文件，点击“安装证书”，选择“本地计算机”，然后选择“将所有的证书都放入下列存储”，点击“浏览”选择“受信任的根证书颁发机构”，完成导入。对于 macOS，打开“钥匙串访问”，将证书拖入“系统”钥匙串，然后双击证书，在“信任”中选择“始终信任”。这一步至关重要，如果证书没有正确安装，HTTPS 流量会失败，应用可能报网络错误。
第三步：配置 PC 应用的代理。 最简单的方法是设置系统全局代理。Windows 打开“设置” → “网络和互联网” → “代理”，开启“使用代理服务器”，地址填 127.0.0.1，端口 8080。macOS 在“系统偏好设置” → “网络” → “高级” → “代理”中，勾选“Web 代理（HTTP）”和“安全 Web 代理（HTTPS）”，都填入 127.0.0.1:8080。设置后，几乎所有走系统代理的应用都会把流量发给 Burp。但有些 PC 应用不走系统代理（比如它们自己实现了 HTTP 栈，不读取系统设置），这时你需要使用强制代理工具，比如 Proxifier 或 ProxyCap，它们可以强制将指定进程的所有 TCP 流量转发到你的代理端口。
第四步：验证抓包是否成功。 用浏览器访问一个 HTTPS 网站，比如 https://www.baidu.com。如果 Burp 的 Proxy 下的 HTTP history 里出现了百度的请求，并且你能看到请求和响应的明文，说明证书安装成功，代理工作正常。接下来，启动网易云音乐，执行一些操作（如搜索、播放），观察 Burp 里不断出现的请求，你就可以分析这些请求的 URL、参数和返回的 JSON 数据了。
第五步（可选）：用代码测试代理连通性。 如果你熟悉 Python，可以用 requests 库通过 Burp 代理发送请求，以确认你的代码也能被抓包。下面是一个完整的示例：
import requests
# 设置代理，指向 Burp 的监听地址
proxies = {
'http': 'http://127.0.0.1:8080',
'https': 'http://127.0.0.1:8080'
}
# 因为使用了自签名证书，需要关闭证书验证，否则会抛出 SSL 错误
response = requests.get('https://www.baidu.com', proxies=proxies, verify=False)
print(response.status_code)
print(response.text[:200]) # 打印前 200 个字符proxies字典定义了 HTTP 和 HTTPS 的代理服务器，都指向本地的 8080 端口。verify=False告诉 requests 不要验证服务器的 SSL 证书，因为我们正在用中间人证书，默认验证会失败。在实际抓包分析时，这个选项是必要的。- 运行这段代码，你会在 Burp 的 HTTP history 里看到一条对
www.baidu.com的请求，并且可以查看到完整的请求头和响应体。这证明了即使是你自己写的程序，只要配置了代理，流量也会被拦截。
最容易踩的坑以及正确做法
坑 1：证书未正确安装或安装后未重启应用。 很多新手在 Burp 里导出了证书，也双击安装了，但抓取 HTTPS 时仍然看到的是乱码或连接失败。原因可能是安装到了“当前用户”存储而不是“本地计算机”，或者应用（尤其是已经运行的应用）没有重新加载系统证书。正确做法：务必安装到“本地计算机”的受信任根存储，安装后重启你要抓包的应用，甚至重启操作系统确保证书缓存刷新。之后可以用浏览器再次验证。
坑 2：应用不走系统代理。 这是抓 PC 端应用最常见的拦路虎。浏览器会自动使用系统代理，但很多 PC 软件（特别是游戏、老旧软件）无视系统设置，直接发起连接。正确做法：使用 Proxifier 这类强制代理工具，它可以捕获指定进程的所有 TCP 流量（无论是否支持代理），并转发到你的代理端口。Proxifier 的配置很简单：添加代理服务器（127.0.0.1:8080，协议 HTTPS），然后设置规则让目标进程强制走这个代理。
坑 3：应用使用了证书固定（Certificate Pinning）。 有些安全性较高的应用会在代码里硬编码服务器的证书公钥或证书，如果中间人换成了自己的证书，应用会直接拒绝连接。正确做法：这时简单的抓包就不够了，你需要对应用进行逆向工程，Hook 掉验证证书的代码，或者使用 Frida、Xposed 等框架绕过 pinning。不过这超出了本文的入门范围，你只需要知道存在这种反抓包机制，碰到时意识到不是你的配置问题，而是需要更高级的技术。
验证方法：除了用浏览器测试，你也可以在命令行使用 curl 测试代理：curl -x http://127.0.0.1:8080 https://www.baidu.com -v，如果返回正常页面，且 Burp 里有记录，证明代理通路没问题。如果应用无法联网，先暂时关闭代理看看是不是应用本身网络问题。
下一步操作建议：当你成功抓到包之后，就可以利用 Burp 或 Yakit 的更多功能了。比如用 Repeater 模块修改请求参数，重放请求来测试接口的健壮性；用 Intruder 进行简单的暴力猜解；或者把流量保存下来，作为 API 文档的参考。你也可以在 Yakit 里使用“Web Fuzzer”来对抓到的请求进行变异和测试。这些是后续安全测试的基础。
决策指南：什么时候必须用抓包？什么时候替代方案够用？
必须用抓包的场景：当你需要分析一个你没有源代码的 PC 应用、需要调试第三方服务的 API、怀疑软件存在恶意行为、或者进行安全审计时，抓包是唯一能直接看到明文通信内容的方法。它也是学习他人优秀 API 设计的最佳途径。
替代方案何时够用：如果你只需要调试自己开发的应用，那么浏览器开发者工具、Android Studio 的 Network Profiler 或者 iOS 的 Charles 集成往往更方便，因为不需要操心证书和代理。如果你只是想监控本机网络流量而不关心 HTTPS 内容，Wireshark 可以捕获所有数据包，但无法直接看到加密后的明文。如果你只需要知道某个请求是否发出，系统自带的任务管理器或资源监视器也能看网络连接，但看不到具体内容。
总的来说，抓包技术是移动和 PC 双端安全分析的基石，掌握了它，你就拥有了“看见”任何应用网络行为的能力，这是从“应用开发者”迈向“安全研究者”的重要一步。希望这篇教程能帮你顺利开启抓包之旅。
抓包技术-WX小程序-http/s-Burp&Yakit
当你掌握了 PC 端应用的抓包之后，自然会想把手伸向更封闭、更轻量的微信小程序。小程序运行在微信的沙盒环境里，你没办法像控制普通应用那样直接设置系统代理让它乖乖把流量送过来，而且微信本身对网络请求做了很多封装，传统的全局代理方式要么失效，要么会干扰微信的正常使用。但小程序的接口往往承载着核心业务数据——电商的下单接口、工具类的查询接口、游戏的排行榜接口，学会抓小程序的包，意味着你能看透这些隐藏在聊天面板背后的秘密。
小程序抓包的本质难题与解决方案
小程序抓包和 PC 应用抓包在底层原理上完全一致：都是通过中间人技术解密 HTTPS，通过代理转发流量。但小程序多了一层微信外壳，它不像普通应用那样会读取操作系统的代理设置。如果你直接把系统代理指向 Burp，微信主程序可能会尝试连接代理，但小程序进程根本不理这一套，导致你什么都抓不到。解决思路不是让小程序“主动”走代理，而是“强制”它走代理——这就需要用到一个叫 Proxifier 的工具。Proxifier 工作在系统底层，它可以捕获指定进程的所有网络连接，不管这个进程是否支持代理，都可以把流量重定向到你设定的 HTTP/HTTPS 代理服务器上。所以小程序抓包的经典组合是：Burp/Yakit 做代理和中间人解密 + Proxifier 做流量强制转发。
Mermaid 图表：小程序抓包整体架构
这张图展示了三个核心组件的协作关系。左侧的“微信小程序进程”是你想监控的目标，它尝试连接网络时，Proxifier 会拦截这个动作（箭头1），并根据你设定的规则（比如进程名匹配）把流量转给 Burp 或 Yakit（箭头2）。中间的抓包工具既做代理又做中间人解密，你可以在这里看到明文的请求和响应（箭头3和6）。最后抓包工具把请求发往真实的服务器（箭头4），并把服务器的响应沿原路返回（箭头7和8）。整个链条中，小程序进程并不知道自己被“拐”到了代理上，它以为自己在和微信服务器直接通信。
核心工具链：Proxifier + Burp/Yakit 的配置实战
先说 Proxifier 的配置。打开 Proxifier，第一步是设置代理服务器。点击“配置文件”->“代理服务器”，添加一个新的代理，地址填 127.0.0.1，端口填你 Burp 或 Yakit 的监听端口（比如 Burp 默认 8080，Yakit 默认 8083），协议选择 HTTPS。为什么要选 HTTPS？因为 Burp 和 Yakit 的代理虽然接收的是 HTTP 流量，但它们能处理 CONNECT 方法建立的 HTTPS 隧道，选 HTTPS 协议是为了让 Proxifier 知道这是一个支持 CONNECT 的代理。第二步是最关键的：设置代理规则。点击“配置文件”->“代理规则”，添加一条新规则。名称随便填，比如“WeChatApp”。在“应用程序”一栏，你需要指定微信小程序的进程名。Windows 下通常是 WeChatAppEx.exe，你可以打开任务管理器，展开微信的进程树，找到运行中的小程序对应的进程名确认。Mac 下的路径比较复杂，通常是一个名为 WeChatAppEx Helper 或 Mini Program.app 的可执行文件，位置可能在 /Applications/WeChat.app/Contents/MacOS/WeChatAppEx.app/Contents/Frameworks/... 下，需要你到对应目录下找到它。在规则的动作中，选择刚才添加的代理服务器，然后点击确定。配置完成后，Proxifier 的主界面会显示连接日志，如果看到有来自 WeChatAppEx.exe 的连接被转发到了 127.0.0.1:8080，就说明强制代理生效了。
接下来是 Burp 或 Yakit 的配置，这部分和你之前抓 PC 应用时一模一样。打开 Burp，确保 Proxy 下的 Listeners 中有一个绑定到 127.0.0.1:8080 的正在运行的监听器。Yakit 则是在“MITM 劫持”页面，点击“启动”，默认监听 127.0.0.1:8083。证书的安装也是同理，你需要把 Burp 或 Yakit 的 CA 证书下载下来，安装到操作系统的“受信任的根证书颁发机构”里，否则 HTTPS 流量会解密失败。这一步做完之后，可以用浏览器访问 https://www.baidu.com 测试一下，如果能抓到包且看到明文，说明证书和代理都正常。
Mermaid 图表：Proxifier 规则配置流程
这张图浓缩了配置 Proxifier 的核心步骤。先从定位小程序进程名开始，然后配置代理服务器和规则，最后通过日志验证。如果日志里没有显示转发，最常见的原因是进程名写错了，比如你写的是 WeChat.exe 但小程序实际运行在 WeChatAppEx.exe 下，那就无法匹配。另外注意，有些小程序可能会有多个辅助进程，你需要把相关的都加进规则，或者干脆规则里只写进程名，让 Proxifier 按名称匹配。
高阶场景：在模拟器中抓小程序包
除了 PC 端，你有时候可能需要在安卓模拟器里分析小程序，因为移动端的小程序功能更全，而且可以绕过 PC 微信的一些限制。在模拟器中抓包，思路又不一样了：你需要让模拟器通过代理连接到 PC 上的 Burp/Yakit。但安卓从 7.0 开始，默认不再信任用户安装的证书，所以你安装的用户证书对小程序无效，必须把抓包工具的证书安装到系统证书目录。这需要模拟器有 root 权限。
以雷电或夜神模拟器为例，首先在 Yakit 里下载证书（格式选 .crt.pem），然后用 OpenSSL 计算证书的 hash 值：openssl x509 -inform PEM -subject_hash_old -in 你的证书.crt.pem，你会得到一串 hash，比如 38555061。把证书重命名为 38555061.0。接着用 adb 连接模拟器，先以读写方式挂载系统分区：adb shell mount -o remount,rw /system，然后把重命名后的证书文件 push 到 /system/etc/security/cacerts/ 目录下，并修改权限为 644：chmod 644 /system/etc/security/cacerts/38555061.0。最后重启模拟器。此时你再打开模拟器里的微信小程序，Yakit 里就能看到解密后的 HTTPS 流量了。这个方法的原理是把 Yakit 的证书伪装成系统预装证书，绕过安卓的证书信任机制。
工具链的扩展：Burp 与 Yakit 的联动
当你熟悉了 Burp 和 Yakit 各自的操作后，可以尝试把它们串联起来，发挥各自的优势。Burp 的强项是手动测试、请求重放、插件生态，Yakit 的强项是自动化漏洞扫描、流量分析、内置的各类安全插件。你可以通过“下游代理”的方式让它们协同工作。例如，让 Proxifier 把流量转发给 Burp（8080 端口），然后在 Burp 的配置里设置上游代理指向 Yakit（比如 Yakit 监听 8083 端口）。这样流量路径就变成了：小程序 -> Proxifier -> Burp -> Yakit -> 真实服务器。返回的响应也会原路返回。Burp 和 Yakit 都能看到流量，你可以在 Burp 里手动分析和重放，同时 Yakit 在后台自动进行漏洞扫描，互不干扰。配置 Burp 的上游代理在 “User options” -> “Connections” -> “Upstream Proxy Servers” 里，添加一条规则，目标主机填 *，代理主机填 127.0.0.1，端口填 8083。
Mermaid 图表：Burp 与 Yakit 联动架构
这张图清晰地展示了联动时的数据流向。Burp 在这里既充当了 Proxifier 的目标代理，又把自己变成了 Yakit 的客户端。对于 Proxifier 来说，它只认识 Burp；对于 Yakit 来说，它看到的所有请求都来自 Burp。这种串联方式不会丢失任何数据，而且两个工具都能独立工作，大大提升了测试效率。
最容易踩的坑和验证方法
小程序抓包最大的坑是流量根本没有进入 Proxifier。很多人配置完规则后发现 Burp 里空空如也，就开始怀疑证书问题。其实首先要检查 Proxifier 的日志窗口，看有没有 WeChatAppEx.exe 的连接记录。如果日志一片空白，说明规则里的进程名没对上，或者小程序根本没启动。正确的做法是：先打开任务管理器，找到小程序进程，记下全名，然后在 Proxifier 规则里精确填写。如果进程名后面有路径，你也可以直接填 *WeChatAppEx* 用通配符匹配。
另一个常见坑是证书安装后仍然无法解密，表现为小程序加载失败或白屏。这是因为某些小程序可能使用了证书固定（Certificate Pinning）技术，或者系统时间不对导致证书验证失败。排查方法是先用浏览器测试抓包工具能否正常工作，如果浏览器可以而小程序不行，那很可能就是证书固定的问题，需要配合 Xposed 或 Frida 进行绕过，这属于进阶内容。如果浏览器也不行，请检查证书是否真的安装到了“受信任的根证书颁发机构”，以及抓包工具是否开启了拦截模式导致请求挂起。
验证是否成功抓到包的最简单方法是在小程序里执行一个搜索操作，然后在 Burp 的 HTTP history 里过滤 servicewechat.com 或者小程序的业务域名（比如 api.shop.com），看是否有对应的 POST 或 GET 请求出现。如果能看到请求的 URL、参数和返回的 JSON，说明抓包完全成功。
决策指南：什么时候必须用这种组合？替代方案够用吗？
当你需要深度分析小程序的接口协议、数据格式、或者进行安全测试时，Proxifier + Burp/Yakit 的组合是必经之路，因为只有这样才能完整地看到所有 HTTPS 流量。但如果你只是粗略地想知道小程序调用了哪些域名，微信开发者工具自带的“网络调试”功能就够用了，它不需要配置代理，直接就能看到请求列表，不过它只能用于你自己开发的小程序，无法分析别人的线上小程序。如果你是在手机上临时看一眼小程序的请求，且手机已 root，也可以直接用 Postern 配合 Burp 做 VPN 代理，但配置更复杂且容易受系统限制。
总的来说，针对微信小程序的抓包，本质是“进程级强制代理”与“中间人解密”的组合，它比普通 PC 应用抓包多了一层 Proxifier 的配置，但一旦掌握，你就能解锁对所有微信小程序网络通信的监控能力。
抓包技术-软件联动-http/s-Proxifier
当你已经熟悉了 Burp 或 Yakit 的基本用法，能通过设置系统代理抓取浏览器和大部分 PC 应用的流量后，很快会遇到一个尴尬的局面：你想分析的某个游戏、某个老旧的企业软件、甚至是命令行的 curl 请求，无论你怎么设置系统代理，它们就是无动于衷，流量依然直接发往服务器。这时候，你就需要一个“交通警察”站在系统的网络路口，强制把指定车辆（进程的流量）引导到你设定的代理通道上。这个角色就是 Proxifier。它并不关心流量是 HTTP 还是 HTTPS，也不做解密，它只做一件事：把进程的所有 TCP 连接重定向到指定的代理服务器，让原本“看不见”的流量现出原形。Proxifier 是你打通从“只能抓系统代理流量”到“能抓任意进程流量”这一关的关键工具。
Proxifier 在整个抓包体系中的位置
正常的网络流程中，一个进程如果想通过代理访问网络，它必须自己实现代理协议（比如 HTTP CONNECT），或者读取操作系统的代理设置。但很多程序出于性能或兼容性考虑，完全忽略了系统代理，直接发起原始 TCP 连接。Proxifier 位于操作系统内核与应用程序之间，它通过注入驱动或 Hook 系统网络 API（如 Windows 的 Winsock），拦截进程发起的 TCP 连接请求。当它发现某个进程符合你设定的规则时，就会把这个连接的原始目标地址（比如真实服务器的 IP 和端口）封装起来，然后重新连接到你的代理服务器（比如 Burp 的 127.0.0.1:8080），并告诉代理“请帮我连接到原始目标”。之后，代理服务器与真实服务器建立连接，数据就在这条链路上双向传输。整个过程对目标进程完全透明，它根本不知道自己的流量被拐了一个弯。
Mermaid 图表：Proxifier 强制转发原理
这张图里，上半部分是进程原本的行为：调用系统的 connect 函数想连接目标服务器。中间的 Proxifier 模块拦截了这个调用（虚线箭头表示拦截），然后改变了连接的目标地址，改为连接你的抓包代理。代理再与真实服务器通信。注意箭头 2 和 3，这是 Proxifier 最核心的工作：它保存了原始目标的信息，通过代理协议告诉代理应该去连接谁。后续的数据传输也经过 Proxifier 的中转，但对进程来说，它从头到尾只知道自己连接了某个 IP 并收到了数据，并不知道数据其实绕过了直接路径。
Proxifier 的核心能力与同类工具对比
Proxifier 是目前 Windows 平台下最成熟的强制代理工具，它的核心能力包括：支持 HTTP、HTTPS、SOCKS 等多种代理协议；可以根据进程名、IP 范围、端口等条件灵活定义规则；支持代理链（多个代理串联）；拥有详细的连接日志，方便调试。它的同类工具有 ProxyCap、SocksCap、Redir（Linux 下的 tsocks）等。ProxyCap 功能类似，但配置稍显复杂；SocksCap 较老，只支持 SOCKS 代理；Linux 下通常使用 tsocks 或 proxychains 这类命令行工具，它们通过预加载库实现类似效果。Proxifier 的优势在于图形化界面、规则管理清晰、以及对 Windows 平台的良好支持。对于新手，Proxifier 是学习强制代理概念的最佳工具，它的日志能让你直观地看到每一个连接是如何被处理的。
典型场景：让任意软件乖乖走 Burp 代理
假设你想分析一个网络游戏（比如《英雄联盟》）的登录协议，但它根本不读系统代理设置。下面是一套完整的 Proxifier + Burp 配置步骤。
第一步：确认 Burp 正在监听。 打开 Burp，确保 Proxy -> Options 里有一个监听器绑定到 127.0.0.1:8080，并且是 Running 状态。暂时可以关闭 Intercept 以免请求被挂起。
第二步：配置 Proxifier 的代理服务器。 打开 Proxifier，点击“配置文件”->“代理服务器”。在弹出的窗口中点击“添加”，地址填 127.0.0.1，端口填 8080，协议选择“HTTPS”。这里选 HTTPS 是因为 Burp 支持 CONNECT 方法建立隧道，对于所有发向 Burp 的流量，Proxifier 都会用 CONNECT 方法告诉 Burp 要连接的真实目标。如果你选 HTTP，Proxifier 只会转发纯粹的 HTTP 请求，对于 HTTPS 流量会失败。点击“确定”后，可以点击“检查”按钮测试连通性，Proxifier 会尝试通过这个代理访问一个测试网站，如果成功会提示“代理服务器工作正常”。
第三步：配置代理规则。 点击“配置文件”->“代理规则”。默认有一条“localhost”的规则是“直接连接”，避免代理工具本身被自己转发。点击“添加”新建规则。名称填写“Game”。在“应用程序”一栏，你需要指定目标游戏的进程名。最简单的办法是在游戏运行时打开任务管理器，找到对应的 .exe 文件，把完整进程名复制过来，比如 LeagueClient.exe。如果不确定，可以用通配符 *League* 匹配。动作选择“使用代理服务器”，并选中刚才添加的 127.0.0.1:8080。点击确定。如果你想同时抓取所有走这个代理的流量，也可以建一条默认规则，把“默认”的动作改成使用代理，但这样可能会把系统服务也转发过去，导致网络异常，所以建议只针对特定进程。
第四步：验证配置是否生效。 确保 Proxifier 正在运行，然后启动游戏，执行登录操作。观察 Proxifier 主界面下方的“日志”窗口，你应该能看到来自游戏进程的连接记录，状态为“通过代理服务器”，目标地址是游戏服务器的 IP 和端口。同时打开 Burp 的 HTTP history，如果游戏使用了 HTTPS，你应该能看到 CONNECT 隧道和后续的加密流量，并且因为 Burp 的证书已安装，这些 HTTPS 流量会被解密成明文显示在 history 里。如果 Burp 里只看到 CONNECT 而没有后续的请求，说明证书可能未正确安装，或者游戏使用了证书固定。
第五步（可选）：高级规则与排除。 有时候游戏可能会有多个进程协同工作，比如一个启动器、一个主游戏进程、一个反作弊进程。你可以在规则里添加多个进程名，用分号隔开，或者使用通配符。还可以设置某些 IP 或端口不走代理，比如游戏更新服务器走直连避免影响更新速度。Proxifier 的规则支持按“应用程序”、“目标主机”、“目标端口”多重条件组合，非常灵活。
Mermaid 图表：Proxifier 规则配置流程图
这张图把配置过程按顺序列出，从确定进程名开始，到测试代理、建规则、验证。关键点是进程名必须精确匹配，以及代理协议要选 HTTPS。日志窗口是你排查问题的第一手资料，如果看到“直接连接”而不是“通过代理”，说明规则没有匹配上。
Proxifier 与 Burp、Yakit 的联动进阶
当你掌握了基本的 Proxifier 使用后，可以进一步利用它的“代理链”功能实现更复杂的流量管理。比如你想同时用 Burp 的手动测试功能和 Yakit 的自动化扫描功能，可以把 Proxifier 的流量先发给 Burp，然后让 Burp 把流量转发给 Yakit。配置方法：在 Burp 的 User options -> Connections -> Upstream Proxy Servers 中，添加一条规则，目标主机填 *，代理主机填 127.0.0.1，端口填 Yakit 的监听端口（如 8083）。然后在 Proxifier 里把代理服务器设置为 Burp 的 8080。这样流量路径就是：目标进程 -> Proxifier -> Burp -> Yakit -> 真实服务器。Burp 和 Yakit 都能看到并处理流量。如果你想让特定进程绕过 Yakit 只走 Burp，或者绕过整个代理，也可以在 Proxifier 里设置多条规则，优先级从上到下匹配。
最容易踩的坑及正确做法
坑 1：代理协议选错为 HTTP。 这是最常见的新手错误。如果选成 HTTP，Proxifier 只会把发往 HTTP 端口的流量（如 80）用普通 HTTP 代理方式转发，而对于 HTTPS 流量（443）则会尝试用 HTTP 代理的 CONNECT 方法吗？实际上选 HTTP 时，Proxifier 对所有 TCP 连接都会用 HTTP 代理协议，也就是发送 CONNECT 请求，这其实是可以的，但问题在于很多老旧的代理服务器（或配置不当的代理）可能不支持 CONNECT 到非 443 端口，或者客户端对 CONNECT 响应的解析有差异。稳妥的做法是选 HTTPS，它明确告诉 Proxifier 这是一个支持 CONNECT 隧道的代理，兼容性最好。
坑 2：进程名没写对。 很多游戏或软件有多个进程，比如主程序叫 game.exe，但网络通信可能在一个叫 game_network.exe 的子进程里。如果你只抓了主程序，可能还是看不到流量。正确做法是先用 Process Monitor 或任务管理器观察哪个进程真正在建立网络连接。Proxifier 本身也有日志，你可以先不加规则，让所有流量都直连，然后查看日志里目标进程的连接记录，找到准确的进程名，再针对性建规则。
坑 3：Proxifier 和抓包工具的代理端口冲突。 如果你开了多个代理工具（比如同时开了 Burp 和 Fiddler），可能其中一个占用了 8080 端口，导致 Proxifier 连接失败。检查端口占用情况，或者给 Proxifier 的代理服务器配置正确的端口。
验证方法：除了看 Proxifier 日志，还可以在目标软件里执行一个你已知的网络操作，比如登录，然后去抓包工具里按时间排序，看是否有新的请求出现。如果 Proxifier 日志显示转发成功但 Burp 里没有，那问题在 Burp 或证书上；如果 Proxifier 日志里根本没有该进程的连接，那就是规则问题。一个常用的测试工具是 telnet 或 Test-NetConnection（PowerShell），你可以在命令行执行 telnet www.baidu.com 80，如果 Proxifier 规则中包含了 telnet.exe，你应该能在日志里看到这个连接被转发。
决策指南：什么时候必须用 Proxifier？替代方案有哪些？
必须用 Proxifier 的场景：当你需要分析一个你无法修改源代码的第三方软件、游戏、老旧应用，而且它完全不遵循系统代理设置时，Proxifier 是唯一能强制抓取其流量的方式。它也是安全分析人员在面对未知软件时的标准工具，因为你可以精确控制只转发目标进程的流量，不影响其他网络连接。
替代方案何时够用：
- 如果你只需要抓取浏览器的流量，系统代理 + 浏览器插件（如 SwitchyOmega）就足够了，不需要 Proxifier。
- 如果你在 Linux 或 macOS 下，可以使用
proxychains命令启动目标程序，它通过预加载库实现类似功能，但需要每次都在命令行中启动，不适合已运行的进程。 - 如果你需要抓取整个系统所有流量（包括系统服务），可以使用 VPN 类工具（如 Proxifier 其实也算一种，但 VPN 会全局转发），但 VPN 无法精细控制进程，且配置复杂。
- 如果你自己开发软件，可以在代码里显式设置代理，根本不需要 Proxifier。
总之，Proxifier 是抓包工具箱里的一把“万能扳手”，它让你摆脱了对目标软件自身代理能力的依赖，将抓包的主动权完全掌握在自己手中。掌握了它，你就能从容应对各种“顽固”的 PC 应用，为后续更深入的安全分析铺平道路。
抓包技术-通用方案-http/s-Reqable
当你已经走过了用 Burp 抓 PC 应用、用 Proxifier 强制定向、用组合拳抓小程序这一路，工具箱里已经攒了不少利器。但每次换个场景就要换套工具，有时候你只是想快速看一眼某个 App 的接口返回了什么 JSON，或者临时想重发一个请求改个参数，打开 Burp 这种“重型武器”总觉得有点杀鸡用牛刀。更重要的是，你肯定遇到过这种需求：抓到包之后，想直接把这个请求转成测试用例，或者想对特定请求自动做一些修改（比如给每个请求加个 token），Burp 里要么需要装插件，要么得写复杂的正则。这时，一个叫 Reqable 的工具就走进了视野——它把自己定位成“通用方案”，试图在一个软件里搞定抓包、调试、重发、脚本处理这整套流程，而且跨平台支持 Windows、Mac、Linux 甚至手机端。
Reqable 在整个抓包体系中的定位
Reqable 的前身是安卓上知名的抓包工具 HttpCanary，作者把它重写成了一个全平台产品。它和 Burp、Yakit 最大的区别在于：Burp 是专业安全测试平台，功能强大但学习曲线陡峭；Yakit 是集成化安全工具，强调自动化；而 Reqable 更贴近“开发者友好”，它把自己包装成一个 HTTP 调试工具，核心使用场景是开发、测试、调试过程中的抓包分析与接口验证。你可以把它理解成 Fiddler 和 Charles 的现代替代品，但又加上了 Postman 那样的 API 测试功能。在抓包层面，它同样基于中间人（MITM）原理，需要安装 CA 证书、设置代理；但在功能设计上，它把“查看请求”“修改请求”“重放请求”“编写脚本”这几个环节无缝衔接起来，让你不需要在多个工具之间来回切换。
Mermaid 图表：Reqable 在开发者工具链中的位置
这张图把 Reqable 放在抓包工具家族里做对比。Burp 和 Yakit 更偏安全测试，功能围绕漏洞挖掘展开；Fiddler 和 Charles 是老牌抓包工具，功能专一但相对陈旧；Reqable 则在保持抓包核心能力的同时，融入了 API 测试和脚本扩展，让自己成为“开发者日常伴侣”。下半部分列出了它的三个核心能力模块，以及对应的适用场景——当你处于开发调试、数据验证、快速逆向这些需要“轻量级介入”的场景时，Reqable 往往比 Burp 更顺手。
为什么说它是“通用方案”？它的工作原理
Reqable 的通用性体现在几个层面：第一，它支持 HTTP/1.x、HTTP/2，甚至开始支持 HTTP/3（QUIC），这意味着无论你面对的接口协议多新，它基本都能处理。第二，它内置了代理服务器，默认监听 127.0.0.1:9000（端口可在设置里改），可以同时接受 HTTP、HTTPS、SOCKS 代理请求。第三，它提供了“一键安装证书”的引导流程，极大降低了新手配置门槛。
它的工作原理和 Burp 一样是标准的 MITM：启动后开启本地代理，你在系统或设备里把代理指向 Reqable 的端口，所有流量先经过它。如果请求是 HTTPS，Reaqble 会用自己生成的 CA 证书与客户端握手，同时与真实服务器建立另一个 TLS 连接，从而解密流量让你看到明文。但 Reqable 在设计上有一个和 Burp 不同的哲学：它默认不拦截请求（Intercept 默认关闭），而是把所有流量实时展示在列表里，你随时可以点进去看详情。这种“被动监听”的模式更符合开发调试的习惯——你只是想观察数据，而不是一开始就想篡改它。
为什么这样设计？因为 Reqable 的典型用户是开发者和测试人员，他们首要需求是“看清楚接口返回了什么”，然后才是“改点什么试试”。而 Burp 的安全测试场景里，拦截和修改往往是第一步。这种设计上的微妙差异，决定了 Reqable 的上手体验更平滑。
Mermaid 图表：Reqable 抓包数据流
这张图展示了 Reqable 内部的几个关键环节。箭头 2 代表它会把流量实时展示在界面上，让你看到原始请求和响应。箭头 3 和 4 代表如果启用了脚本功能，请求和响应在转发前后会被 Python 脚本处理，你可以在脚本里修改任意字段。这种架构的好处是“观察”和“修改”解耦：即使不写脚本，你也能正常抓包；写了脚本，就能实现自动化处理，比如自动给请求加认证头、替换响应里的某些字段。
核心功能解析与工具对比
Reqable 和 Burp、Yakit 的差异，可以从下面这个表格看得更清楚：
| 维度 | Reqable | Burp Suite | Yakit |
|---|---|---|---|
| 核心定位 | HTTP 开发调试 + API 测试 | Web 安全测试平台 | 集成化安全工具 |
| 上手难度 | 低，UI 现代，引导清晰 | 中高，界面传统 | 中，功能集成度高 |
| 脚本扩展 | Python 脚本，支持 onRequest/onResponse 钩子 | Java 插件（扩展性强但门槛高） | 内置大量 Poc 和插件 |
| 跨平台 | Windows/macOS/Linux/移动端 | Windows/Linux/macOS（需 Java） | Windows/macOS/Linux |
| API 测试 | 内置类似 Postman 的请求编辑器 | 需配合 Repeater 手动组装 | 提供 Web Fuzzer |
| 协同抓包 | 手机扫码连接桌面端，无需配代理 | 需手动设代理 | 需手动设代理 |
| 典型场景 | 开发调试、接口验证、逆向分析 | 漏洞挖掘、渗透测试 | 自动化扫描、渗透测试 |
从这个对比能看出，Reqable 的“通用方案”定位其实是在“开发调试”这个细分领域里做到了一站式覆盖。它不像 Burp 那样为安全测试而生，但如果你只是要“抓个包看看接口”，它比 Burp 轻得多；如果你需要“改个包再发一次”，它内置的请求编辑器和重放功能比 Fiddler 顺手；如果你熟悉 Python，它的脚本功能甚至可以让你实现一些自动化测试逻辑。
典型场景配置：从零开始用 Reqable 抓包
假设你现在想分析一个安卓 App 的登录接口，或者只是想看看某个网页加载了哪些请求。下面是完整的 Reqable 使用步骤。
第一步：下载安装并启动。 从官网下载对应系统的安装包，一路下一步安装完成。启动后，你会看到简洁的主界面，顶部有几个核心按钮：启动调试（小飞机图标）、安装证书（盾牌图标）、设置代理（网络图标）。
第二步：安装证书。 点击盾牌图标，选择你的操作系统（Windows/macOS/Linux），Reqable 会弹出引导窗口。以 Windows 为例，点击“现在安装”，它会自动把 CA 证书安装到系统受信任的根证书存储里。安装成功后，盾牌图标会从红色叉号变成绿色勾号。这一步是解密 HTTPS 的前提，如果不安装，你只能看到 CONNECT 隧道，看不到明文。
第三步：设置系统代理。 点击网络图标，Reqable 会自动帮你把操作系统的 HTTP/HTTPS 代理设置为 127.0.0.1:9000。图标变绿说明设置成功。这时你打开浏览器访问任意 HTTPS 网站，应该就能在 Reqable 的调试列表里看到请求了。
第四步（可选）：抓取手机 App 流量。 如果你想抓手机上的 App，确保手机和电脑连同一个 Wi-Fi。在 Reqable 顶部可以看到电脑的 IP 地址和端口（例如 192.168.1.100:9000）。在手机 Wi-Fi 设置里配置手动代理，填入这个 IP 和端口。然后在手机上访问 http://reqable 下载并安装 Reqable 的 CA 证书（Android 可能需要从设置里安装）。之后手机上的所有 HTTP/HTTPS 流量就会出现在电脑的 Reqable 列表里。
第五步：分析请求。 在 Reqable 的调试列表里，每个请求会显示域名、方法、路径、状态码、大小和时间。双击任意请求，右侧会滑出详情面板，分为 Request（请求行、头、体）和 Response（响应行、头、体）两个 Tab。你可以在这里仔细查看接口返回的 JSON 数据，确认字段是否符合预期。
脚本功能：让 Reqable 自动处理流量
Reqable 最独特的功能之一是其内置的 Python 脚本引擎。你可以编写脚本，在请求发送前（onRequest）或响应返回前（onResponse）对其进行修改。比如你想给所有发往 api.example.com 的请求自动添加一个 Authorization 头，可以这样配置：
首先，点击顶部脚本图标（类似“{}”），选择“新建规则”。输入规则名称，URL 匹配模式填 api.example.com/*。然后编写 Python 脚本：
def onRequest(context, request):
# 给请求添加一个自定义头
request.headers['X-Debug-Tag'] = 'Reqable-Script'
# 如果请求体是 JSON，可以在这里解析修改
# import json
# body = json.loads(request.body)
# body['debug'] = True
# request.body = json.dumps(body)
return request
def onResponse(context, response):
# 可以记录响应状态码
print(f"Response status: {response.statusCode}")
# 如果响应体是 JSON，也可以修改
return responseonRequest函数接收context和request对象，你可以在返回前任意修改request的属性（headers、body、url 等）。onResponse类似，可以修改响应内容。context对象可以用来在两个函数间共享数据（比如在请求里存个时间戳，响应里读出来）。- 脚本修改后自动生效，你可以在右侧的控制台看到
print输出的日志。
这个脚本功能让你能实现很多自动化操作：自动添加签名参数、替换测试环境的域名、拦截特定响应并 mock 数据等等。相比 Burp 里需要写复杂扩展，Python 脚本对普通开发者友好得多。
Mermaid 图表：Reqable 脚本处理流程图
这张图展示了脚本引擎介入的时机。请求在发往服务器之前，会检查是否有匹配的规则，如果有就执行 onRequest；响应返回客户端之前同样会经过 onResponse 检查。整个过程对客户端和服务器透明，你可以在中间层随心所欲地注入逻辑。
最容易踩的坑和验证方法
坑 1：证书安装后 Chrome 仍然报错 NET::ERR_CERT_AUTHORITY_INVALID。 这通常是因为 Chrome 有自己的证书缓存，或者你安装的证书没覆盖到所有浏览器。正确做法：重启浏览器，或者打开 Chrome 的“管理证书”里确认 Reqable CA 确实在“受信任的根证书颁发机构”列表中。也可以试试用无痕模式访问。
坑 2：手机配置代理后无法上网。 可能是电脑防火墙阻止了 9000 端口的入站连接。正确做法：在 Windows 防火墙或 macOS 安全设置里，允许 Reqable 应用通过防火墙，或者临时关闭防火墙测试。也可以在 Reqable 里把端口改为其他数值（比如 8888）试试。
坑 3：脚本修改不生效。 先检查脚本编辑器右侧的“控制台”有没有报错信息（比如语法错误）。另外注意 onRequest 必须返回修改后的 request 对象，如果忘了 return，请求会被中断。
验证方法：最简单的是用浏览器访问 http://httpbin.org/get，你会在 Reqable 里看到请求详情，包括 URL、headers、IP 等。如果你写了脚本添加头，可以在请求头里看到你添加的字段。也可以尝试用手机访问，确认代理链路通顺。
决策指南：什么时候用 Reqable？什么时候用 Burp/Yakit？
优先选 Reqable 的场景：日常开发调试接口、快速查看 App 或网页的请求数据、需要经常重放请求测试、希望用 Python 脚本自动化处理流量、需要在手机和电脑之间无缝协同抓包、想要一个界面清爽且跨平台的工具。尤其当你只是“看一眼接口返回什么”而不是“系统地挖掘漏洞”时，Reqable 比 Burp 轻巧得多。
仍然需要 Burp/Yakit 的场景：专业的渗透测试，比如需要 Intruder 进行暴力破解、Scanner 自动化扫描漏洞、各种复杂的安全插件支持、多人协作的测试项目。Burp 在安全领域的生态积累是 Reqable 短期内无法替代的。Yakit 的集成化漏洞扫描和 Poc 管理也远超 Reqable 的能力范围。
替代方案够用的情况：如果你只需要抓取自己写的 App 的包，用 Android Studio 的 Network Profiler 或 iOS 的 Charles 集成更直接。如果你只是临时看一眼某个请求，浏览器自带的开发者工具（F12 的网络面板）已经足够，不需要额外装软件。
Reqable 的出现，填补了“重型安全工具”和“简陋浏览器工具”之间的空白。它用一种现代化、低门槛的方式，把抓包、调试、测试整合在一起，让你在处理日常开发中的网络问题时，不用在多个软件间反复横跳。对于从零开始学习抓包的新手，它可能是最友好的起点；而对于已经熟悉 Burp 的你，它则是一个高效的辅助工具——尤其是当你需要快速验证一个想法，却又不想打开庞大的 Burp 时。
抓包技术-其他工具-http/s-Fiddler&Charles
当你已经熟悉了 Burp 这样的安全测试平台，也体验过 Reqable 这种现代开发调试工具，可能会觉得抓包世界好像就是这些新锐工具的天下。但如果你去问一个做了十年 Windows 开发的老程序员，或者一个长期从事 iOS 应用调试的工程师，他们大概率会脱口而出两个名字：Fiddler 和 Charles。这两个工具可以说是抓包界的“活化石”，诞生于互联网早期，经历了从 HTTP/1.0 到 HTTP/2、从明文到全面 HTTPS 的变迁，至今仍在无数开发者的电脑里占有一席之地。它们没有 Burp 那样强大的漏洞挖掘能力，也没有 Reqable 那样现代化的界面和脚本系统，但它们以极致的稳定、对特定平台的深度优化、以及一些独门绝技，在“开发调试”这个细分领域里牢牢占据着一席之地。
Fiddler 与 Charles 在抓包工具谱系中的位置
整个抓包工具家族可以按照使用场景大致分为三类。第一类是安全测试平台，以 Burp Suite、Yakit 为代表，核心功能围绕渗透测试展开，强调可扩展性和自动化漏洞发现。第二类是开发调试工具，以 Fiddler、Charles、Reqable 为代表，它们更关注帮助开发者看清接口数据、模拟网络环境、快速重放请求。第三类是系统级抓包工具，如 Wireshark、Tcpdump，它们工作在网络层，不关心应用层协议，能看到所有数据包但无法直接解密 HTTPS。Fiddler 和 Charles 就稳稳地站在第二类里，而且它们是这个类别的开创者和长期领跑者。Fiddler 由 Eric Lawrence 开发，最初是作为微软技术栈下的 HTTP 调试代理，对 Windows 和 .NET 应用有着天然的支持；Charles 则是 Mac 平台上的明星，深受 iOS 和 macOS 开发者的喜爱，它的界面设计和对苹果生态的适配让它成为移动端调试的标配。两者的核心功能高度重叠：都作为本地代理服务器，都通过中间人技术解密 HTTPS，都提供请求列表和详情查看，都支持断点修改和重放。但在具体实现和特色功能上，它们走出了两条不同的路。
Mermaid 图表：抓包工具分类图谱
这张图把 Fiddler 和 Charles 放在开发调试工具的范畴内，并标注了它们各自的生态倾向。Fiddler 紧密集成 Windows 系统，可以捕获所有 WinHTTP 和 WinINET 请求，包括 IE/Edge 浏览器和许多 Windows 原生应用；Charles 则与 macOS 和 iOS 模拟器无缝协作，甚至能直接作为 iOS 设备的代理并自动安装证书。Reqable 作为后起之秀，试图融合两者的优点并跨平台，但 Fiddler 和 Charles 在各自领域的深度优化仍是其不可替代的优势。
它们的核心原理：依然是标准的中间人
无论 Fiddler 还是 Charles，底层原理和你已经熟悉的 Burp 完全一致：它们在你电脑上启动一个 HTTP 代理服务器（Fiddler 默认监听 127.0.0.1:8888，Charles 默认 127.0.0.1:8888 或 9090），你需要把系统或应用的代理指向这个地址。对于 HTTPS 流量，它们同样需要生成自己的 CA 根证书，并要求你安装到系统受信任存储中。当客户端发起 HTTPS 连接时，它们用自己的证书与客户端握手，同时与真实服务器建立另一个 TLS 连接，从而在中间解密流量。这个原理如此经典，以至于所有基于代理的抓包工具都遵循同一套模型。
但 Fiddler 和 Charles 在细节上有所不同。Fiddler 最初是为 Windows 上的 HTTP 调试设计的，它深度集成 Windows 的证书存储和代理设置，甚至可以自动捕获所有使用 WinHTTP 的应用程序（包括许多后台服务）而不需要你手动配置代理。Charles 则更关注易用性，它提供了“外部代理设置”向导，可以一键帮你配置 macOS 的系统代理，并且在 iOS 设备上可以通过 Wi-Fi 代理直接连接，还能通过 USB 连接调试真机（需要配合相关工具）。
功能对比：Fiddler 的过滤与脚本 vs Charles 的映射与限速
Fiddler 最强大的地方在于它的过滤器和 FiddlerScript。过滤器（Filters）可以让你根据请求类型、主机、状态码、请求体等条件筛选出关心的流量，这在面对海量请求时极其有用。你可以设置“只显示发往 api.example.com 的请求”或者“隐藏图片和 CSS 请求”，过滤器会实时更新列表。而 FiddlerScript 是一个基于 C# 的脚本引擎，你可以编写自定义规则来修改请求和响应，甚至实现复杂的自动化逻辑。比如你想在所有请求里添加一个自定义头，可以写一小段脚本：
static function OnBeforeRequest(oSession: Session) {
if (oSession.HostnameIs("api.example.com")) {
oSession.oRequest["X-Debug-Tag"] = "Fiddler";
}
}这段脚本会在每个请求发出前执行，检查主机名，如果匹配就添加一个请求头。这种脚本能力虽然不如现代工具的 Python 脚本灵活，但对于 Windows 环境下需要深度集成的场景，它依然很实用。
Charles 的杀手级功能则是 Map Local 和 Throttle。Map Local 允许你把某个远程请求映射到本地文件，比如你想调试一个前端页面，可以把 https://example.com/app.js 映射到本地的 app.js 文件，这样浏览器加载的就是你修改过的代码，非常适合前端开发和 mock 数据。Throttle 功能可以模拟各种网络环境，比如 3G、4G、高延迟、丢包，让你测试应用在弱网下的表现。这两个功能在开发调试中非常常用，而 Burp 虽然也能实现类似效果（比如通过匹配替换），但 Charles 的界面更直观，操作更简单。
Mermaid 图表：Fiddler 与 Charles 核心功能对比
这张图将两个工具的特色功能放在左右两侧，中间是它们共有的代理和 MITM 基础。Fiddler 的强项在 Windows 平台上的脚本化和精细过滤，Charles 的强项在便捷的本地映射和网络模拟。这些差异决定了它们在不同场景下的适用性。
典型场景配置：用 Fiddler 调试 Windows 应用，用 Charles 抓 iPhone 包
假设你现在用 Windows 电脑，想分析一个 Windows 桌面应用（比如网易云音乐）的接口，但发现设置系统代理后它不走代理。这时 Fiddler 有一个隐藏技能：它可以把自身注册为系统根证书，并开启“解密 HTTPS 流量”后，自动捕获所有使用 WinHTTP 的应用程序的流量，即使它们不理会系统代理。你只需要在 Fiddler 的 Tools -> Options -> HTTPS 里勾选“Decrypt HTTPS traffic”，并在 Connections 里勾选“Allow remote computers to connect”（如果你需要抓其他设备）。然后启动目标应用，Fiddler 里就会自动出现它的请求，无需任何额外配置。这是因为 Fiddler 在 Windows 底层注入了一些机制，强制部分应用走它的代理。但需要注意，这种方法对某些使用自定义网络栈的应用无效，此时仍需要 Proxifier 配合。
如果你在 Mac 上，想抓 iPhone 上某个 App 的包，Charles 是最顺手的工具。步骤如下：
- 在 Charles 的 Proxy -> Proxy Settings 里，确保 HTTP Proxy 勾选，端口默认 8888。
- 在 Charles 的 Help -> Local IP Address 里查看电脑的局域网 IP。
- 在 iPhone 的 Wi-Fi 设置里，选择当前网络，配置 HTTP 代理为手动，填入电脑 IP 和端口 8888。
- 在 iPhone 上用 Safari 访问
chls.pro/ssl，下载并安装 Charles 的 CA 证书。然后进入 iPhone 的“设置”->“通用”->“关于本机”->“证书信任设置”，开启对 Charles 根证书的信任。 - 此时 Charles 会弹出一个提示框，询问是否允许该设备连接，点击 Allow。之后 iPhone 上的所有流量就会出现在 Charles 的会话列表中。
高级技巧：用 Fiddler 的 AutoResponder 进行 mock 测试
Fiddler 的 AutoResponder 是一个很实用的功能。假设你正在开发一个前端页面，后端接口 /api/user/info 返回的数据格式不符合预期，你想在没有后端配合的情况下测试前端展示。你可以先用浏览器访问这个接口，在 Fiddler 里找到这个请求，右键选择“Save”->“Response”->“Save Response Body”把 JSON 保存下来。然后打开 AutoResponder 选项卡，勾选“Enable rules”和“Unmatched requests passthrough”。点击“Add”添加规则，在顶部的编辑框里输入匹配条件（比如 regex:(?ins).*/api/user/info.*），在下面的下拉框里选择“Find a file…”并选中刚才保存的 JSON 文件。之后所有匹配的请求都会直接返回你保存的那个文件内容，而不去请求真实服务器。这让你可以快速模拟各种后端响应，测试前端边界情况。
最容易踩的坑与验证方法
坑 1：Fiddler 抓不到 localhost 流量。 这是 Fiddler 用户最常见的问题。因为很多应用直接访问 http://127.0.0.1 时会绕过代理。正确做法：在 Fiddler 中，可以在 Rules -> Customize Rules 里找到 OnBeforeRequest 函数，加入一行代码：if (oSession.HostnameIs("localhost")) oSession.host = "127.0.0.1:8888"; 然后重启 Fiddler。或者在访问 localhost 时使用 http://localhost.fiddler 代替，Fiddler 会自动处理。
坑 2：Charles 抓取 iOS 真机 HTTPS 时出现 SSL 握手失败。 通常是因为证书没正确安装或未信任。正确做法：按照官方流程，在手机上下载安装证书后，一定要去“设置”->“通用”->“关于本机”->“证书信任设置”里把 Charles 的证书开关打开（iOS 10.3 以上需要这一步）。另外注意，iOS 13 以后，如果应用使用了证书固定（Certificate Pinning），即使证书安装也无法解密，需要配合越狱或 Hook。
坑 3：Fiddler 和 Charles 同时运行导致端口冲突。 两者默认端口都是 8888，如果同时运行，后启动的那个会提示端口被占用。正确做法：修改其中一个的默认端口。Fiddler 在 Tools -> Options -> Connections 里修改，Charles 在 Proxy -> Proxy Settings 里修改。最好让它们使用不同端口，避免冲突。
验证方法：无论用哪个工具，最简单的验证就是打开浏览器访问一个 HTTPS 网站，比如 https://www.baidu.com，看抓包工具里是否出现请求，且请求详情里能看到明文（比如响应里的 HTML 内容）。如果只看到 CONNECT 隧道而没有后续请求，说明证书解密未生效。
决策指南：什么时候用 Fiddler/Charles？什么时候用其他？
优先用 Fiddler 的场景：你在 Windows 平台上开发，需要调试 .NET 应用、Windows 服务或者 IE 浏览器的行为；你需要一个强大的过滤器来从海量请求中提取关键信息；你习惯用 C# 编写脚本扩展功能；或者你只是需要一个稳定、免费（Fiddler 免费版功能已经很全）的抓包工具。
优先用 Charles 的场景：你在 macOS 上开发 iOS/macOS 应用，需要经常抓取模拟器或真机的流量；你需要频繁使用 Map Local 来 mock 接口数据；你需要模拟各种网络环境测试应用的健壮性；或者你更偏好图形化操作和直观的界面。
替代方案足够用的情况：如果你只是偶尔抓一下浏览器请求，Chrome 开发者工具的网络面板完全够用，不需要额外装软件。如果你需要自动化安全测试，Burp 或 Yakit 是更好的选择。如果你希望一个工具跨所有平台且界面现代，Reqable 可能更适合你。如果你需要分析非 HTTP 协议（如 DNS、TCP），Wireshark 才是正确的工具。
Fiddler 和 Charles 虽然年纪不小，但它们在一些特定场景下的独到之处，让它们至今没有被完全替代。它们就像工具箱里的老牌扳手，也许不是最炫的，但在拧某些螺丝时，只有它们最顺手。理解它们的特点，并在合适的场景下选择它们，会让你的抓包技能更加全面。
