记录一次对 Claude Desktop 的抓包

起缘

老早就给 Claude Desktop 配好了 GLM 的 API，但是 A 畜不是会检查模型名称吗，GLM 又没像 Deepseek 那样做了名称映射，我以为用不了，结果居然能对话。那到底是哪个模型在跟我说话呢？是 A 畜大发善心回退到免费的 Sonnet 了吗？还是 GLM 有个默认模型兜底？于是抓包分析了一下，过程中学到很多东西。

实践

首先是用 wireshark 直接抓包，发现想看的包都被 TLS 加密了。 GPT 给出这个办法：

export SSLKEYLOGFILE='path\to\claude-tls.log'

然后在同一终端窗口启动 Claude Desktop，再在 wireshark 中指定上面的存放 TLS 密钥的路径，就可以解密了。

不过只能解密最初的几个包：

我看了一下，这些包的作用如下：

• 测试 API 连通性，只发送一个字符 '.'，模型回复啥忘了，反正也很短。从这个包能得知模型用的是 glm-4.7，同时请求模型是 claude-sonnet。
• 让模型给这个对话起标题。

至此，我最初的问题解决了，但又多了一个问题：为啥有的没有被解密啊？

排查

（自此起 API 换成了 Deepseek）

问 GPT，走了以下的排查流程：

• 检查是哪个进程在连接 api.deepseek.com （当然要先查连接的 ip 地址，netstat -ano 出来都是 ip:port 的形式）
• 看看这个进程有没有使用 SSLKEYLOGFILE 这个环境变量。

结果是：这个进程是 Claude Desktop 的子进程，但是不知怎么着，它没继承环境变量或者别的什么原因，总之它没往 claude-tls.log 里面写东西。

再问 GPT，怎么获得这个子进程的 TLS 密钥，它往我脸上糊了一堆名词：BoringSSL、hook key-log callback、Bun HTTP/TLS... 我去，这都啥东西，看不懂。

再问，它给出用 mitmproxy 的办法。我问为啥这样可以，它给我画了俩图，挺形象：

app  <--TLS 1-->  mitmproxy  <--TLS 2-->  DeepSeek

app  ----------------TLS----------------> DeepSeek
              ↑
           Wireshark

ok 啊，我直接就是在终端中设置 HTTP_PROXY 和 HTTPS_PROXY 指向 mitmproxy，然后启动 Claude Desktop。

终局

我发现这货根本不走代理，也没办法配置代理，见 这个四月份的 issue。

那难搞了，于是我在终端中启动 Claude Code，用 mitmproxy 截流，看到了传输的提示词和模型回复，过了一把眼瘾，就这样吧。

Claude Code 的系统提示词：提示词