部分APP无法代理抓包的原因及解决方法

引言（转载仅作为笔记，作者：https://cloud.tencent.com/developer/column/5044）

 

HTTP应用层的抓包已经成为日常工作测试与调试中的重要一环，最近接触新项目突然之间发现之前的抓包手段都不好使了，顿时模块与模块之间的前端与服务之间的交互都变成了不可见，整个人都好像被蒙住了眼睛。

 

其实自己也很早就发现平时使用的支付宝等APP使用Fiddler 或 Charles这类代理抓包软件默认情况下就无法抓取请求的，但使用Wireshark这类网卡抓包软件可以看到这些APP的流量，而已这些流量也表明这些APP使用的主要应用层协议仍然是HTTP（https），不过我们的代理抓包工具却失效了。如今终于在实际工作中遇到了，也不得不解决了，毕竟眼前有东西挡住会让我浑身不适。

 

代理抓包原理

 

为了弄明白为什么Fiddler 或 Charles对这些APP无效，我们有必要先了解代理抓包我原理（当然您不想了解也是完全可以的，直接看后面的实际操作就可以完成，原理分析什么的可以有兴趣随时回来看）

 

Fiddler 或 Charles 这类使用的代理的抓包软件与Wireshark是完全不同的（Wireshark 使用的网卡数据复制，只要是经过指定网卡都会被抓取），其只能对使用代理的应用层网络协议生效，比如常见的HTTP（https），Websocket  。

 

这里以HTTP为例简单说明下

 

 

客户端需要完成一次HTTP请求，通常需要先找到服务器，客户端会根据http请求中url的主机名（实际会使用host中的主角名）及其端口与目标主机建立tcp连接，建立连接后会将http报文发送给目标服务器 （更多细节请参考https://tools.ietf.org/html/rfc7232）

 

接下来我来看下HTTP代理是如何运作的，我们启动Fiddler 或 Charles就是启动了一个HTTP代理服务器，这类工具会通知操作系统，“现在我在系统上创建了一个HTTP代理，IP为XXXXXX端口为XX。如果您使用的是linux您可以手动通知操作系统(export http_proxy=ip:port export https_proxy=$http_proxy),如果您使用的是手机等移动设备您可以在当前wifi设置处告诉系统你要使用http代理。 现在我们已经告诉系统我们想要使用代理，这个时候运行在系统上的http客户端再去发送请求的时候，他就不会再去进行DNS解析，去连接目标服务器，而是直接连接系统告诉他代理所在的地址（代理的ip及端口，注意无论是http或https或其他支持代理的协议都会连接同一个端口）。然后代理服务器会与客户端建立连接，再然后代理服务器根据请求信息再去连接真正的服务器。

 

 

这里还有个细节正常在没有代理的情况下客户端向服务器发送的请求行里只包含部分URI（实际上是没有方案，主机名及端口的）

 

 

如上图如果在没有代理的情况下，对www.baidu.com/index.html的请求的请求行实际上是GET /index.html HTTP/1.1 其实并不是我们常见的完整uri。因为在原始的HTTP设计中没有考虑中间服务器（即代理）的情况，客户端在发送报文前已经知道服务器的地址并与之建立了连接，没有必要再发送方案，主机名及端口。不过代理出现后这种做法就会有问题了，客户端连接了代理服务器，而代理服务器却没有办法连接正确的服务器。因此客户端发送给代理的请求其实稍有不同，客户端会在请求行里使用完整的uri，这样代理服务器才能解析真实的服务器的地址。

 

现在我们的请求实际上都是通过代理服务器（Fiddler 或 Charles）发送出去的，所以代理抓包软件不仅知道http请求及响应的所有报文，甚至还可以随时修改请求及响应。