聊到抓包技术很多人第一反应是抓Web请求但真正把HTTPS协议、证书信任、APP、小程序、PC应用、Web这些场景串起来的其实是一套完整的流量链路客户端把数据交给本地代理代理转发到目标服务器要想看到HTTPS的明文还得先处理证书信任再让多个代理节点之间做好转发联动。我打算就按这条链路来拆把每个环节为什么这么做讲清楚给基础入门的朋友一条可以直接上手的路径。1. 抓包到底在抓什么从一次接口调试说起最近有朋友问了个很典型的问题浏览器里看请求没问题换个App就抓不到。我让他看一下代理有没有生效、证书信不信任结果两头都没配。抓包这件事表面上是个“代理设置”的问题实际上是一整条链路客户端流量要走代理代理要能解开HTTPS解不开HTTPS就要处理证书信任遇到多个代理节点还要考虑转发联动。把它们拆开看抓包就简单了。1.1 抓包的本质一个中转站抓包工具本质上就是一个“中转站”。原本客户端直接和目标服务器建立连接现在改成客户端先连本地代理代理再连目标服务器。响应的数据从目标服务器回到代理再由代理交回客户端。整个过程代理都能看到流量的样子。这个模型不管场景怎么换都成立。抓Web、抓App、抓小程序还是抓PC应用第一步都是让流量“绕道”经过代理。用一个生活化类比平时寄快递是直接交给快递员抓包等于在中间加了一个中转仓库仓库里的人会把每个包裹打开看一眼再重新打包送出去。用在合法的接口调试、日志分析和故障排查场景中这个“看一眼”的环节就能帮我们定位问题。1.2 能抓什么、不能抓什么先有个正确预期不少新手以为装上抓包工具就能看到所有流量实际不是。HTTP协议的流量是明文代理可以直接看到请求头和请求体。HTTPS协议的流量是加密的如果客户端不信任代理的证书代理最多只能看到目标IP和端口看不到具体内容。只有完成了证书信任配置代理才能解密HTTPS看到里面的明文。另外一些底层基于TCP或UDP的私有协议也不是所有抓包工具都支持。入门阶段你只要牢牢记住抓包能不能看到内容取决于流量经过代理之后代理能不能“读懂”。纯HTTPS需要证书纯私有协议可能需要更底层的处理这两种情况不要混在一起。注意抓包调试只适用于自己拥有或已经获得明确授权的系统、服务和数据。不要对他人系统做未授权的流量分析这是技术伦理的底线。2. HTTPS 为什么默认抓不到SSL/TLS 与证书信任机制想抓HTTPS先得明白为什么默认抓不到。很多人卡在这里不是因为代理没配好而是不知道HTTPS加密和证书信任是怎么工作的。2.1 HTTP 和 HTTPS 差在哪里HTTP的报文是纯文本代理看一眼就能读到URL、Header和Body。HTTPS在HTTP下面多了一层TLS加密通道客户端和服务器在真正传输数据之前要先完成一次“握手”客户端发ClientHello服务器回ServerHello并附上自己的证书客户端验证证书合法性协商出对称密钥之后所有HTTP内容都用这个密钥加密传输。这个过程中的关键点是“证书验证”。服务器证书里包含域名、公钥、签发者等信息并由一个权威机构CA签名。客户端验证证书时要检查证书是否由系统内已信任的CA签发、域名是否匹配、证书是否过期。如果客户端不信任这个证书连接就会中断。这也是为什么你直接开代理抓HTTPS经常看到一堆连接失败而不是完整的明文内容。2.2 中间人原理代理怎么解密抓HTTPS的通用方案是让代理作为一个“中间人”对客户端伪装成服务器对服务器伪装成客户端。具体流程是这样的你在手机或电脑上安装了一个代理生成的CA根证书并把它设为系统信任的根证书。当客户端请求某个HTTPS域名时代理收到请求后用自己保存的CA根证书现场签发一张目标域名的证书交给客户端。客户端在证书信任链里找到你刚安装的根证书验证通过于是它以为自己在跟目标服务器通信。代理再向真正的目标服务器发起HTTPS连接目标服务器用真实证书验证连接也正常建立。这样客户端和代理之间是一套加密代理和目标服务器之间是另一套加密代理在中间能同时解开两边的密文并把内容从一边搬运到另一边。这个过程叫中间人MITM。我不太喜欢“中间人攻击”这个说法因为在调试场景里这就是自己给自己搭跳板目的不是攻击谁而是看清自己程序的请求。2.3 证书信任链为什么装了证书还不行证书信任不是“装上就完事”它是一条链系统/浏览器内置的根证书库是信任锚点根证书签发中间证书中间证书再签发服务器证书。客户端验证时会从服务器证书一路追溯到根证书。代理要做的就是把自己生成的CA根证书塞进信任锚点之后由它签发的所有域名证书都会被客户端认可。常见的坑有两个。第一个是只装了证书没有“信任”它。有些系统安装证书后会默认不信任需要手动在证书设置里把信任开关打开或者把证书用途设为“用于验证网站”。第二个是装到了错误的位置。比如浏览器用独立证书库你只装进了操作系统证书库浏览器不一定认反之你只装进用户证书库某些系统级服务不认用户证书。所以当你发现HTTPS仍然抓不到时第一反应不是“代理坏了”而是先确认证书是否装进了正确的信任区并且信任开关打开没有。3. Web 端抓包实操从浏览器开发者工具到系统代理Web端是抓包入门最友好的场景。新手一开始可以在浏览器开发者工具里直接看请求但那只适合“看一眼”不适合做系统调试。真正要联动App、小程序和PC应用还得把抓包代理工具接进来。3.1 浏览器开发者工具到底缺什么现代浏览器开发者工具自带网络面板能看到页面发出的所有请求包括请求头、响应头、时间线、JSON返回。这个功能简单直观但有两个限制第一它只能看到当前浏览器发出去的流量第二它不能替你修改请求并一键重放也不能对非网页流量生效。所以浏览器开发者工具更像一个“查看器”不是完整的抓包代理。你要做接口Mock、拦截修改、断点调试或者把同一个代理配置复用给App、小程序、PC应用还是需要独立的抓包代理工具。3.2 一套通用的 Web 端 HTTPS 抓包配置我平时在PC端调试Web时会按下面这套流程走打开抓包代理工具先记住监听地址和端口。一般默认是127.0.0.1:8888端口可以改成8080、8899等不常用的数字避免和本机其他服务冲突。在工具里开启“系统代理”选项或者手动把系统网络代理设置为127.0.0.1:8888。这一步是让浏览器流量绕进代理。用浏览器访问http://localhost:8888这类代理入口下载代理生成的CA根证书。下载后导入到“受信任的根证书颁发机构”并确认信任用途包含“网站身份验证”。清空浏览器连接缓存重启浏览器。再访问一个HTTPS网站回到代理工具里应该能看到请求列表。为了不被无关流量刷屏配一个域名过滤规则只保留目标域名的请求比如api.example.com。过滤规则不用写得复杂通用的做法是匹配域名关键字。比如我调某接口时只关心/v1/order就写一个路径包含规则其他一律隐藏。这样列表干净很多。3.3 Web 端三个高频问题证书、HSTS、双向认证实际调试时Web端最常见的是证书警告。如果你安装证书后浏览器仍然提示“不安全”先确认证书是否导入正确。浏览器一般有两种证书库一种是操作系统级一种是浏览器自带两个地方都装上再重启能解决大部分问题。第二个是HSTS。有些站点启用了HTTP严格传输安全浏览器一旦知道这个域名只允许HTTPS就会拒绝你手动添加例外。HTTPS证书不信任时连接会直接失败连“忽略警告继续访问”的按钮都不给你。解决办法是先装好CA根证书确认链完整再打开目标站点。如果还不行可以临时在代理工具里关闭对该域名的拦截只透传至少能看到流量是否打通。第三个是双向认证。普通HTTPS只有服务器向客户端证明身份双向认证要求客户端也出示证书。代理抓包时服务器会向代理要客户端证书这时候你需要在代理工具里导入对应的客户端证书和私钥并勾选“在TLS握手时发送客户端证书”否则连接会在握手阶段被服务器重置。4. APP 抓包实操从模拟器到真机App抓包比Web多一个步骤得先让手机流量经过你电脑上的代理。然后是证书信任这步在手机上比电脑上更讲究。4.1 让 App 流量走代理的两种方式第一种是WiFi代理。把手机和电脑连到同一个局域网在手机WiFi设置里找到HTTP代理填上电脑的局域网IP和代理工具的端口。比如电脑IP是192.168.1.100代理端口是8888就填192.168.1.100:8888。这种配置对大多数App都有效因为App一般会走系统网络栈。第二种是用模拟器。在手机系统模拟器里安装抓包工具或者把模拟器的网络代理指到宿主机端口。模拟器好处是证书安装和截图方便坏处是某些App要求真机环境模拟器里跑不起来。一定要记得代理只对配置生效后的新连接有效。改完代理后把App从后台彻底划掉重新冷启动一次避免旧连接还在跑。4.2 真机安装 CA 证书并开启信任手机端安装证书没有电脑端那么“傻瓜”。我建议这样操作手机连上电脑代理后用手机浏览器访问代理入口下载CA证书。常见格式是.cer或.pem。打开系统设置找到“证书”或“加密与凭据”入口选择“安装CA证书”。安装完成后很多系统不会立刻信任它需要在“受信任证书”列表里找到刚才安装的证书开启“完全信任”或类似开关。回到App重新请求接口代理工具里能看到明文HTTPS。这里有一个非常关键的坑主流手机系统对“用户证书”和“系统证书”区别对待。普通用户安装的CA证书是用户级证书很多App出于安全考虑默认不信任用户级证书。如果你发现Web能抓App抓不到多半就是这个原因。入门阶段最省事的办法是用调试版App开发同学在打包时把networkSecurityConfig里的trust-anchors加上用户证书信任就能正常抓包。不要在未经授权的线上生产App上折腾绕过方案这个代价很大。4.3 App 的证书校验、SSL Pinning 与代理检测App比Web更“精明”除了系统证书信任很多App还会自己校验服务器证书。这种机制叫SSL PinningApp把服务器公钥或证书指纹内置在客户端里请求时对比当前证书是否是内置的那张。代理给你签发了一张“合法”证书但和App内置指纹对不上连接照样断。遇到SSL Pinning基础入门阶段不用硬刚。你可以联系开发同学出一个带调试开关的测试包在测试环境关闭Pinning校验或者使用支持常用加解密库Hook的调试工具在合法授权范围内观察流量。不要一上来就想着暴力破解很多是徒劳而且容易踩合规红线。还有的App会检测系统代理设置检测到HTTP代理就拒绝联网。这种情况要先看一下App是否有“仅信任系统证书”或“禁止代理”的开关。实在不行用网络层透明转发方式代替传统HTTP代理但这已经超出基础入门范围了。5. 小程序与 PC 应用抓包同源不同路App能抓到之后小程序和PC应用其实也就通关了一半。它们底层仍然是客户端网络请求只是入口和信任方式略有不同。5.1 小程序抓包从宿主环境找流量小程序运行在宿主App的容器里但网络请求一般还是走操作系统的网络栈。也就是说你在手机上配备好代理和证书后小程序里的HTTPS请求照样能被代理看见。实际操作时有三种情况第一种是在小程序开发者工具里调试。开发者工具自带请求面板可以看网络请求适合日常开发。第二种是真机预览。把手机代理设到电脑安装CA证书再在小程序宿主App里打开预览模式抓包代理能看到请求。第三种是线上正式版小程序。这类流量能不能抓取决于宿主App是否启用了额外证书校验和代理检测。能抓就抓抓不到就回到开发环境调试不要贸然绕过。小程序还有一个域名白名单限制请求的域名必须在后台配置过合法域名否则请求直接失败。这个限制发生在业务层不是代理层。如果你发现代理能看到请求但返回是“url not in domain list”那就是小程序平台侧的校验。5.2 PC 应用抓包系统代理之外的路PC应用比App更复杂因为不是所有软件都听系统代理的话。有些桌面软件自己实现网络库比如用某些跨平台运行时默认走自己的代理设置有些软件干脆不读代理只走直连。处理方法按优先级试先在应用设置里找“代理”或“网络连接”选项手动填入代理地址这是最干净的办法。如果没有代理选项再尝试开启全局系统代理很多原生应用会继承。如果带系统代理效果还不理想就只能在网络层把该应用的流量重定向到本地代理端口或者在抓包代理里开启透明转发模式让应用无感知地走代理。PC端抓HTTPS仍然要装根证书而且要装到系统证书库。遇到抓不到的情况先排查进程是否真的走了代理在PC终端里用网络连接查看命令找到目标进程对应的TCP连接再看它的远程端口是不是你的代理端口。比如用netstat找443对应的进程能快速定位。5.3 系统级、用户级与进程级证书信任证书信任范围是PC应用抓包里最容易被忽视的细节。系统级证书所有应用和浏览器都会信任抓包代理的根证书装到这里覆盖面最广。用户级证书只影响当前用户运行的进程有些系统服务和高权限进程不认。进程级证书某些应用自带证书库需要你往它自己的证书文件里导入代理证书常见于Java系和部分运行时类应用。我调试一个PC桌面客户端时系统代理和根证书都装好了但抓不到HTTPS明文。最后发现是这个软件用自己的证书库不读系统证书。我在它的启动参数里指定了额外的信任库路径重新加载证书流量才出来。所以先搞清楚你调试的对象读哪种证书库比反复重装证书有用得多。6. 转发联动的核心代理串联与流量编排前面几章都是“客户端到本地代理”的单跳模式。实际项目里你经常需要把流量从一个代理转发到另一个代理或者让多个代理各干一件事。这就是题目里提到的“转发联动”。6.1 为什么需要转发联动单层代理能解密和查看但做不了更复杂的编排。比如你在A代理解密之后希望把请求交给B代理做二次过滤或者B代理负责把某个接口的返回替换成预设的Mock数据。如果只有单层代理你只能在一个工具里写规则节奏容易乱。还有一种典型场景是跨机联动。手机配置连到电脑A的代理电脑A再把流量统一转给内网测试环境前的代理B这样B可以做统一的权限校验或者日志记录。转发联动本质就是让多个代理节点组成流水线每个节点只干一件事。6.2 代理串联的配置方法最常见的链路是客户端 - 本地代理A - 上游代理B - 目标服务器配置步骤很简单启动代理B记下监听地址和端口。比如B监听在192.168.1.200:8080。在代理A的设置里找到“上游代理”或“父代理”选项填上B的地址和端口。在代理B的过滤规则里放行代理A的转发流量避免B把A的请求也当成无关流量过滤掉。客户端只配置代理A不需要直接连B。要注意的是A和B之间仍然可能是HTTPS加密连接。A在向B发起CONNECT请求时B也会返回证书并接受验证。如果B的证书不是受信任CA签发的A会验证失败整条链路直接断掉。所以要么在A的信任存储里安装B的CA证书要么在A的上游代理配置里关闭对B的证书校验。调试环境通常选后者但你要知道这个开关可能带来的安全性影响。6.3 规则匹配与流量修改转发联动不只是“连起来”还要让流量按规则走不同出口。实际我在本地调试一个模拟项目X时会配置类似这样的规则域名匹配api.example.com的请求转发到上游Mock代理。路径包含/v1/payment/callback的请求在上游代理里命中特定规则直接返回预置的JSON。其余请求直接放行到真实服务器。这种写法把“抓包”升级成了“控制流量”。你可以基于Host、路径、Header、Cookie等维度做匹配。常见的规则语法是用正则或关键字比如匹配路径以/v1/开头、请求头X-Env: test再联合条件判断。联动里有个高频坑上游代理不支持CONNECT方法时HTTPS请求会返回400看起来像是端口不通其实是B只支持普通HTTP转发不支持隧道建连。排查方法很简单先用HTTP明文网站做连通性测试如果HTTP能通、HTTPS不通基本就是CONNECT隧道的问题。7. 常见问题速查与个人心得最后集中写一份排查清单。我平时从零配抓包环境碰到的坑基本都在下面这张表里。7.1 快速排查表现象可能原因处理办法网页能抓App抓不到App不信任用户级证书改用支持调试开关的测试包或在开发配置中允许用户证书证书装完仍然提示不安全没开信任开关或装错了证书库确认证书进入系统受信任根并开启网站身份校验HTTS请求显示无法连接HSTS拦截装好根证书或临时在代理中关闭该域名的拦截抓包工具只有CONNECT记录代理没有完成证书验证检查指代目标端口确认CA根证书已导入且信任手机代理配置后完全没流量WiFi代理地址写错或端口不通用电脑IP:端口形式重新填手机访问代理入口测试PC应用不走系统代理应用自己实现网络层在应用内设置代理或使用网络层透明转发上游代理转发后HTTPS失败上游不支持CONNECT先用HTTP测试连通性确认B支持隧道建连代理串联后请求成环A转发给BB又转发给A检查上游代理地址不要指回当前代理自身7.2 几条我从实操里悟出来的经验第一抓包环境要从最基础的开始搭。先抓一个HTTP网站确认代理链路通再装证书抓一个HTTPS网站最后才去抓App和PC应用。不要一上来就同时配手机、装证书、搞规则问题混在一起很难定位。第二证书安装后一定要重启目标客户端。很多系统的TLS会话缓存不会立刻刷新旧连接握的还是旧证书重启客户端能让新证书生效。第三代理端口尽量避开80和443也不要用常见业务端口。8888、8899这类端口在多数机器上比较安全。如果代理工具自带端口检测启动后看到端口被占用换一个再试。第四保存好代理工具生成的CA证书私钥别泄露。这个证书等同于你设备上的“根信任”一旦泄露任何装了这个证书的设备都会信任它签发的域名证书。调试完可以按安全策略清理不用的信任条目。第五抓包是为了调试和排查不是为了“绕过”。碰到SSL Pinning、代理检测这些安全机制先走正规开发接口申请测试包不要硬来。我在一个项目里就因为线上包启用了完整的证书校验死活抓不到后来找后端要了测试环境地址和调试开关几分钟就解决了。技术和流程都不难难的是先找对人、走对路。就我个人体会把Web、App、小程序、PC应用理解成同一条链路会少走很多弯路。证书信任是你能不能看到HTTPS内容的关键转发联动是你能不能灵活组织多个代理节点的关键。先把HTTP链路跑通再加证书再做规则过滤层层叠加比一上来就想搞复杂架构稳得多。找一台闲置电脑搭一个本地代理用自己写的Demo项目完整练一遍你手里这套抓包技术才算真正落地。 
长河君 · 2026/10/19 5:25:37 · 阅读 1.2k 从HTTPS证书信任到代理串联：抓包技术全链路拆解与实战
聊到抓包技术很多人第一反应是抓Web请求但真正把HTTPS协议、证书信任、APP、小程序、PC应用、Web这些场景串起来的其实是一套完整的流量链路客户端把数据交给本地代理代理转发到目标服务器要想看到HTTPS的明文还得先处理证书信任再让多个代理节点之间做好转发联动。我打算就按这条链路来拆把每个环节为什么这么做讲清楚给基础入门的朋友一条可以直接上手的路径。1. 抓包到底在抓什么从一次接口调试说起最近有朋友问了个很典型的问题浏览器里看请求没问题换个App就抓不到。我让他看一下代理有没有生效、证书信不信任结果两头都没配。抓包这件事表面上是个“代理设置”的问题实际上是一整条链路客户端流量要走代理代理要能解开HTTPS解不开HTTPS就要处理证书信任遇到多个代理节点还要考虑转发联动。把它们拆开看抓包就简单了。1.1 抓包的本质一个中转站抓包工具本质上就是一个“中转站”。原本客户端直接和目标服务器建立连接现在改成客户端先连本地代理代理再连目标服务器。响应的数据从目标服务器回到代理再由代理交回客户端。整个过程代理都能看到流量的样子。这个模型不管场景怎么换都成立。抓Web、抓App、抓小程序还是抓PC应用第一步都是让流量“绕道”经过代理。用一个生活化类比平时寄快递是直接交给快递员抓包等于在中间加了一个中转仓库仓库里的人会把每个包裹打开看一眼再重新打包送出去。用在合法的接口调试、日志分析和故障排查场景中这个“看一眼”的环节就能帮我们定位问题。1.2 能抓什么、不能抓什么先有个正确预期不少新手以为装上抓包工具就能看到所有流量实际不是。HTTP协议的流量是明文代理可以直接看到请求头和请求体。HTTPS协议的流量是加密的如果客户端不信任代理的证书代理最多只能看到目标IP和端口看不到具体内容。只有完成了证书信任配置代理才能解密HTTPS看到里面的明文。另外一些底层基于TCP或UDP的私有协议也不是所有抓包工具都支持。入门阶段你只要牢牢记住抓包能不能看到内容取决于流量经过代理之后代理能不能“读懂”。纯HTTPS需要证书纯私有协议可能需要更底层的处理这两种情况不要混在一起。注意抓包调试只适用于自己拥有或已经获得明确授权的系统、服务和数据。不要对他人系统做未授权的流量分析这是技术伦理的底线。2. HTTPS 为什么默认抓不到SSL/TLS 与证书信任机制想抓HTTPS先得明白为什么默认抓不到。很多人卡在这里不是因为代理没配好而是不知道HTTPS加密和证书信任是怎么工作的。2.1 HTTP 和 HTTPS 差在哪里HTTP的报文是纯文本代理看一眼就能读到URL、Header和Body。HTTPS在HTTP下面多了一层TLS加密通道客户端和服务器在真正传输数据之前要先完成一次“握手”客户端发ClientHello服务器回ServerHello并附上自己的证书客户端验证证书合法性协商出对称密钥之后所有HTTP内容都用这个密钥加密传输。这个过程中的关键点是“证书验证”。服务器证书里包含域名、公钥、签发者等信息并由一个权威机构CA签名。客户端验证证书时要检查证书是否由系统内已信任的CA签发、域名是否匹配、证书是否过期。如果客户端不信任这个证书连接就会中断。这也是为什么你直接开代理抓HTTPS经常看到一堆连接失败而不是完整的明文内容。2.2 中间人原理代理怎么解密抓HTTPS的通用方案是让代理作为一个“中间人”对客户端伪装成服务器对服务器伪装成客户端。具体流程是这样的你在手机或电脑上安装了一个代理生成的CA根证书并把它设为系统信任的根证书。当客户端请求某个HTTPS域名时代理收到请求后用自己保存的CA根证书现场签发一张目标域名的证书交给客户端。客户端在证书信任链里找到你刚安装的根证书验证通过于是它以为自己在跟目标服务器通信。代理再向真正的目标服务器发起HTTPS连接目标服务器用真实证书验证连接也正常建立。这样客户端和代理之间是一套加密代理和目标服务器之间是另一套加密代理在中间能同时解开两边的密文并把内容从一边搬运到另一边。这个过程叫中间人MITM。我不太喜欢“中间人攻击”这个说法因为在调试场景里这就是自己给自己搭跳板目的不是攻击谁而是看清自己程序的请求。2.3 证书信任链为什么装了证书还不行证书信任不是“装上就完事”它是一条链系统/浏览器内置的根证书库是信任锚点根证书签发中间证书中间证书再签发服务器证书。客户端验证时会从服务器证书一路追溯到根证书。代理要做的就是把自己生成的CA根证书塞进信任锚点之后由它签发的所有域名证书都会被客户端认可。常见的坑有两个。第一个是只装了证书没有“信任”它。有些系统安装证书后会默认不信任需要手动在证书设置里把信任开关打开或者把证书用途设为“用于验证网站”。第二个是装到了错误的位置。比如浏览器用独立证书库你只装进了操作系统证书库浏览器不一定认反之你只装进用户证书库某些系统级服务不认用户证书。所以当你发现HTTPS仍然抓不到时第一反应不是“代理坏了”而是先确认证书是否装进了正确的信任区并且信任开关打开没有。3. Web 端抓包实操从浏览器开发者工具到系统代理Web端是抓包入门最友好的场景。新手一开始可以在浏览器开发者工具里直接看请求但那只适合“看一眼”不适合做系统调试。真正要联动App、小程序和PC应用还得把抓包代理工具接进来。3.1 浏览器开发者工具到底缺什么现代浏览器开发者工具自带网络面板能看到页面发出的所有请求包括请求头、响应头、时间线、JSON返回。这个功能简单直观但有两个限制第一它只能看到当前浏览器发出去的流量第二它不能替你修改请求并一键重放也不能对非网页流量生效。所以浏览器开发者工具更像一个“查看器”不是完整的抓包代理。你要做接口Mock、拦截修改、断点调试或者把同一个代理配置复用给App、小程序、PC应用还是需要独立的抓包代理工具。3.2 一套通用的 Web 端 HTTPS 抓包配置我平时在PC端调试Web时会按下面这套流程走打开抓包代理工具先记住监听地址和端口。一般默认是127.0.0.1:8888端口可以改成8080、8899等不常用的数字避免和本机其他服务冲突。在工具里开启“系统代理”选项或者手动把系统网络代理设置为127.0.0.1:8888。这一步是让浏览器流量绕进代理。用浏览器访问http://localhost:8888这类代理入口下载代理生成的CA根证书。下载后导入到“受信任的根证书颁发机构”并确认信任用途包含“网站身份验证”。清空浏览器连接缓存重启浏览器。再访问一个HTTPS网站回到代理工具里应该能看到请求列表。为了不被无关流量刷屏配一个域名过滤规则只保留目标域名的请求比如api.example.com。过滤规则不用写得复杂通用的做法是匹配域名关键字。比如我调某接口时只关心/v1/order就写一个路径包含规则其他一律隐藏。这样列表干净很多。3.3 Web 端三个高频问题证书、HSTS、双向认证实际调试时Web端最常见的是证书警告。如果你安装证书后浏览器仍然提示“不安全”先确认证书是否导入正确。浏览器一般有两种证书库一种是操作系统级一种是浏览器自带两个地方都装上再重启能解决大部分问题。第二个是HSTS。有些站点启用了HTTP严格传输安全浏览器一旦知道这个域名只允许HTTPS就会拒绝你手动添加例外。HTTPS证书不信任时连接会直接失败连“忽略警告继续访问”的按钮都不给你。解决办法是先装好CA根证书确认链完整再打开目标站点。如果还不行可以临时在代理工具里关闭对该域名的拦截只透传至少能看到流量是否打通。第三个是双向认证。普通HTTPS只有服务器向客户端证明身份双向认证要求客户端也出示证书。代理抓包时服务器会向代理要客户端证书这时候你需要在代理工具里导入对应的客户端证书和私钥并勾选“在TLS握手时发送客户端证书”否则连接会在握手阶段被服务器重置。4. APP 抓包实操从模拟器到真机App抓包比Web多一个步骤得先让手机流量经过你电脑上的代理。然后是证书信任这步在手机上比电脑上更讲究。4.1 让 App 流量走代理的两种方式第一种是WiFi代理。把手机和电脑连到同一个局域网在手机WiFi设置里找到HTTP代理填上电脑的局域网IP和代理工具的端口。比如电脑IP是192.168.1.100代理端口是8888就填192.168.1.100:8888。这种配置对大多数App都有效因为App一般会走系统网络栈。第二种是用模拟器。在手机系统模拟器里安装抓包工具或者把模拟器的网络代理指到宿主机端口。模拟器好处是证书安装和截图方便坏处是某些App要求真机环境模拟器里跑不起来。一定要记得代理只对配置生效后的新连接有效。改完代理后把App从后台彻底划掉重新冷启动一次避免旧连接还在跑。4.2 真机安装 CA 证书并开启信任手机端安装证书没有电脑端那么“傻瓜”。我建议这样操作手机连上电脑代理后用手机浏览器访问代理入口下载CA证书。常见格式是.cer或.pem。打开系统设置找到“证书”或“加密与凭据”入口选择“安装CA证书”。安装完成后很多系统不会立刻信任它需要在“受信任证书”列表里找到刚才安装的证书开启“完全信任”或类似开关。回到App重新请求接口代理工具里能看到明文HTTPS。这里有一个非常关键的坑主流手机系统对“用户证书”和“系统证书”区别对待。普通用户安装的CA证书是用户级证书很多App出于安全考虑默认不信任用户级证书。如果你发现Web能抓App抓不到多半就是这个原因。入门阶段最省事的办法是用调试版App开发同学在打包时把networkSecurityConfig里的trust-anchors加上用户证书信任就能正常抓包。不要在未经授权的线上生产App上折腾绕过方案这个代价很大。4.3 App 的证书校验、SSL Pinning 与代理检测App比Web更“精明”除了系统证书信任很多App还会自己校验服务器证书。这种机制叫SSL PinningApp把服务器公钥或证书指纹内置在客户端里请求时对比当前证书是否是内置的那张。代理给你签发了一张“合法”证书但和App内置指纹对不上连接照样断。遇到SSL Pinning基础入门阶段不用硬刚。你可以联系开发同学出一个带调试开关的测试包在测试环境关闭Pinning校验或者使用支持常用加解密库Hook的调试工具在合法授权范围内观察流量。不要一上来就想着暴力破解很多是徒劳而且容易踩合规红线。还有的App会检测系统代理设置检测到HTTP代理就拒绝联网。这种情况要先看一下App是否有“仅信任系统证书”或“禁止代理”的开关。实在不行用网络层透明转发方式代替传统HTTP代理但这已经超出基础入门范围了。5. 小程序与 PC 应用抓包同源不同路App能抓到之后小程序和PC应用其实也就通关了一半。它们底层仍然是客户端网络请求只是入口和信任方式略有不同。5.1 小程序抓包从宿主环境找流量小程序运行在宿主App的容器里但网络请求一般还是走操作系统的网络栈。也就是说你在手机上配备好代理和证书后小程序里的HTTPS请求照样能被代理看见。实际操作时有三种情况第一种是在小程序开发者工具里调试。开发者工具自带请求面板可以看网络请求适合日常开发。第二种是真机预览。把手机代理设到电脑安装CA证书再在小程序宿主App里打开预览模式抓包代理能看到请求。第三种是线上正式版小程序。这类流量能不能抓取决于宿主App是否启用了额外证书校验和代理检测。能抓就抓抓不到就回到开发环境调试不要贸然绕过。小程序还有一个域名白名单限制请求的域名必须在后台配置过合法域名否则请求直接失败。这个限制发生在业务层不是代理层。如果你发现代理能看到请求但返回是“url not in domain list”那就是小程序平台侧的校验。5.2 PC 应用抓包系统代理之外的路PC应用比App更复杂因为不是所有软件都听系统代理的话。有些桌面软件自己实现网络库比如用某些跨平台运行时默认走自己的代理设置有些软件干脆不读代理只走直连。处理方法按优先级试先在应用设置里找“代理”或“网络连接”选项手动填入代理地址这是最干净的办法。如果没有代理选项再尝试开启全局系统代理很多原生应用会继承。如果带系统代理效果还不理想就只能在网络层把该应用的流量重定向到本地代理端口或者在抓包代理里开启透明转发模式让应用无感知地走代理。PC端抓HTTPS仍然要装根证书而且要装到系统证书库。遇到抓不到的情况先排查进程是否真的走了代理在PC终端里用网络连接查看命令找到目标进程对应的TCP连接再看它的远程端口是不是你的代理端口。比如用netstat找443对应的进程能快速定位。5.3 系统级、用户级与进程级证书信任证书信任范围是PC应用抓包里最容易被忽视的细节。系统级证书所有应用和浏览器都会信任抓包代理的根证书装到这里覆盖面最广。用户级证书只影响当前用户运行的进程有些系统服务和高权限进程不认。进程级证书某些应用自带证书库需要你往它自己的证书文件里导入代理证书常见于Java系和部分运行时类应用。我调试一个PC桌面客户端时系统代理和根证书都装好了但抓不到HTTPS明文。最后发现是这个软件用自己的证书库不读系统证书。我在它的启动参数里指定了额外的信任库路径重新加载证书流量才出来。所以先搞清楚你调试的对象读哪种证书库比反复重装证书有用得多。6. 转发联动的核心代理串联与流量编排前面几章都是“客户端到本地代理”的单跳模式。实际项目里你经常需要把流量从一个代理转发到另一个代理或者让多个代理各干一件事。这就是题目里提到的“转发联动”。6.1 为什么需要转发联动单层代理能解密和查看但做不了更复杂的编排。比如你在A代理解密之后希望把请求交给B代理做二次过滤或者B代理负责把某个接口的返回替换成预设的Mock数据。如果只有单层代理你只能在一个工具里写规则节奏容易乱。还有一种典型场景是跨机联动。手机配置连到电脑A的代理电脑A再把流量统一转给内网测试环境前的代理B这样B可以做统一的权限校验或者日志记录。转发联动本质就是让多个代理节点组成流水线每个节点只干一件事。6.2 代理串联的配置方法最常见的链路是客户端 - 本地代理A - 上游代理B - 目标服务器配置步骤很简单启动代理B记下监听地址和端口。比如B监听在192.168.1.200:8080。在代理A的设置里找到“上游代理”或“父代理”选项填上B的地址和端口。在代理B的过滤规则里放行代理A的转发流量避免B把A的请求也当成无关流量过滤掉。客户端只配置代理A不需要直接连B。要注意的是A和B之间仍然可能是HTTPS加密连接。A在向B发起CONNECT请求时B也会返回证书并接受验证。如果B的证书不是受信任CA签发的A会验证失败整条链路直接断掉。所以要么在A的信任存储里安装B的CA证书要么在A的上游代理配置里关闭对B的证书校验。调试环境通常选后者但你要知道这个开关可能带来的安全性影响。6.3 规则匹配与流量修改转发联动不只是“连起来”还要让流量按规则走不同出口。实际我在本地调试一个模拟项目X时会配置类似这样的规则域名匹配api.example.com的请求转发到上游Mock代理。路径包含/v1/payment/callback的请求在上游代理里命中特定规则直接返回预置的JSON。其余请求直接放行到真实服务器。这种写法把“抓包”升级成了“控制流量”。你可以基于Host、路径、Header、Cookie等维度做匹配。常见的规则语法是用正则或关键字比如匹配路径以/v1/开头、请求头X-Env: test再联合条件判断。联动里有个高频坑上游代理不支持CONNECT方法时HTTPS请求会返回400看起来像是端口不通其实是B只支持普通HTTP转发不支持隧道建连。排查方法很简单先用HTTP明文网站做连通性测试如果HTTP能通、HTTPS不通基本就是CONNECT隧道的问题。7. 常见问题速查与个人心得最后集中写一份排查清单。我平时从零配抓包环境碰到的坑基本都在下面这张表里。7.1 快速排查表现象可能原因处理办法网页能抓App抓不到App不信任用户级证书改用支持调试开关的测试包或在开发配置中允许用户证书证书装完仍然提示不安全没开信任开关或装错了证书库确认证书进入系统受信任根并开启网站身份校验HTTS请求显示无法连接HSTS拦截装好根证书或临时在代理中关闭该域名的拦截抓包工具只有CONNECT记录代理没有完成证书验证检查指代目标端口确认CA根证书已导入且信任手机代理配置后完全没流量WiFi代理地址写错或端口不通用电脑IP:端口形式重新填手机访问代理入口测试PC应用不走系统代理应用自己实现网络层在应用内设置代理或使用网络层透明转发上游代理转发后HTTPS失败上游不支持CONNECT先用HTTP测试连通性确认B支持隧道建连代理串联后请求成环A转发给BB又转发给A检查上游代理地址不要指回当前代理自身7.2 几条我从实操里悟出来的经验第一抓包环境要从最基础的开始搭。先抓一个HTTP网站确认代理链路通再装证书抓一个HTTPS网站最后才去抓App和PC应用。不要一上来就同时配手机、装证书、搞规则问题混在一起很难定位。第二证书安装后一定要重启目标客户端。很多系统的TLS会话缓存不会立刻刷新旧连接握的还是旧证书重启客户端能让新证书生效。第三代理端口尽量避开80和443也不要用常见业务端口。8888、8899这类端口在多数机器上比较安全。如果代理工具自带端口检测启动后看到端口被占用换一个再试。第四保存好代理工具生成的CA证书私钥别泄露。这个证书等同于你设备上的“根信任”一旦泄露任何装了这个证书的设备都会信任它签发的域名证书。调试完可以按安全策略清理不用的信任条目。第五抓包是为了调试和排查不是为了“绕过”。碰到SSL Pinning、代理检测这些安全机制先走正规开发接口申请测试包不要硬来。我在一个项目里就因为线上包启用了完整的证书校验死活抓不到后来找后端要了测试环境地址和调试开关几分钟就解决了。技术和流程都不难难的是先找对人、走对路。就我个人体会把Web、App、小程序、PC应用理解成同一条链路会少走很多弯路。证书信任是你能不能看到HTTPS内容的关键转发联动是你能不能灵活组织多个代理节点的关键。先把HTTP链路跑通再加证书再做规则过滤层层叠加比一上来就想搞复杂架构稳得多。找一台闲置电脑搭一个本地代理用自己写的Demo项目完整练一遍你手里这套抓包技术才算真正落地。