Coding Lever

Appearance

关于 window 下 charlse 抓不到包的分析 ​

正常情况下，charlse 安装证书、设置 ssl proxy 后，应该能够捕获到 应用的 http 和 https 请求。但有些应用始终不行...

1. 为什么有些应用抓不到包？ ​

首先，我们要知道 Charles 作为一个 HTTP 中间人代理 (MITM)，其工作前提是流量必须经过 Charles 监听的端口。 那么应用抓不到包通常由以下原因造成：

  • 忽略系统代理：应用使用独立网络栈，不读取 Windows 注册表中的代理设置。
  • 证书校验 (SSL Pinning)：应用内部硬编码了服务端证书，拒绝 Charles 的自签证书。
  • 协议不支持：应用使用 WebSocket、gRPC 或非 HTTP/HTTPS 协议。
  • 沙盒限制：UWP 应用（如 Windows 商店应用）默认被禁止访问本地回环地址（Loopback）。

这里我们主要关注：在 Windows 中设置了系统代理后，依然有应用抓不到包的问题

首先，来看看 Windows 中的网络代理模式：

  • 系统代理 (System Proxy)：由 WinInet 库管理，大多数浏览器（Edge, Chrome）和标准 API（WinHTTP/WinInet）会遵循此设置(读取这个设置)。
  • 应用级代理 (App-level Proxy)：应用内部自行实现（如电报 Telegram、某些 IDE），独立于系统设置。
  • 虚拟网卡/透明代理 (Transparent Proxy: TUN/TAP)：在三层（网络层）拦截流量。通过路由拦截转发，应用感知不到代理的存在。

也就是说：应用连接网络的三种“心智模式”

  1. 遵纪守法型 (WinInet)：
    • 应用直接调用系统 API。此时，WinInet 接口会自动读取设置的系统代理，从而走 Charles。
  2. 自立门户型 (独立网络栈)：
    • 如 Chromium (CEF) 或 libcurl。它们自带解析逻辑，可能会使用系统设置，或者完全只看自己的配置信息。
  3. 底层越境型：
    • 直接通过 Winsock 发送原始 TCP/UDP 包，完全跳过应用层的代理协议。

也就是说，在 window 系统上, 设置了系统代理后依然抓不到应用程序的网络包，的核心在于它使用了不同的网络协议栈。

2、了解 Windows 中设置代理的几种方式 ​

在 Windows 中，代理不是一个全局的“硬开关”，而是分层次的“建议”。

此外 window 系统中有 VPN 和 代理 两种设置，他们的区别有：

  • 代理应用在 应用层(L7), 而 VPN 工作在 网络层(L3)

其中，应用层是 Charles 工作的“主战场”，所以一般配置系统代理而不是系统VPN。

系统层 (WinInet/IE 代理) ​

是 Windows 官方提供的默认配置方式，配置的值会保存在注册表中。常见设置方式如下：

  1. window 设置 -> 网络和 Internet -> 网络和共享中心 -> Internet属性 -> 连接 -> 添加VPN
  2. window 设置 -> 网络和 Internet -> 代理
  3. window 设置 -> 网络和 Internet -> VPN 设置会在系统全局(WinInet)生效，影响比如 浏览器、标准 Windows API 应用等使用 WinInet 网络编程接口的应用。但是，使用独立网络栈的应用 (Java, Go, CEF)则不会受影响。

服务层 (WinHTTP) ​

通过 netsh winhttp 设置。主要影响 Windows 更新、系统后台服务等。

环境层 (Environment Variables) ​

环境变量中设置 HTTP_RPOXY 和 HTTPS_RPOXY 等。主要影响命令行工具(Git, Curl, Pip等)和脚本语言。

Windows VPN 或 第三方软件的 TUN 模式 ​

工作在网络层 (L3)，几乎会接管全局所有流量

3、常见应用分析与针对性方案 ​

A. 浏览器与标准应用 (WinInet) ​

  • 特征：高度遵循系统代理。
  • 方案：开启 Charles 的 Windows Proxy 即可。

B. curl 库应用 (libcurl) ​

  • 特征：默认直连，不看系统代理设置。
  • 方案：在启动前通过命令行设置环境变量：
    bash
    set http_proxy=[http://127.0.0.1:8888](http://127.0.0.1:8888)
set https_proxy=[http://127.0.0.1:8888](http://127.0.0.1:8888)

C. CEF 框架应用 (Chrome 嵌入式内核) ​

  • 特征：如钉钉、微信、VS Code。它们有独立网络栈，常被开发者锁定代理。
  • 方案：强制注入命令行参数启动应用： app.exe --proxy-server="http://127.0.0.1:8888" --ignore-certificate-errors

D. Clash 等代理软件的协作 ​

  • 特征：作为二级代理。
  • 方案：配置代理链。在 Charles 中设置 External Proxy Settings，转发至 Clash 端口（默认 7890）。

4. 终极解决方案：Proxifier (传输层劫持) ​

当应用不听从任何代理指令时，Proxifier 是最强力的工具。

为什么它是终极方案？ ​

Proxifier 不在应用层“求”程序走代理，而是在 传输层 (L4) 通过劫持 Winsock 调用，强行把指定 .exe 的流量“扭送”到 Charles。

操作指南： ​

  1. 添加服务器：在 Proxifier 中添加 127.0.0.1:8888 (HTTPS 代理)。
  2. 设置规则：指定特定进程（如 target_app.exe）的 Action 为 Proxy。
  3. 解析 DNS：在设置中确保“通过代理服务器解析 DNS”，防止抓包时出现域名解析错误。