将 GitHub Copilot 置于中间人（MitM）代理之后后，我学到了什么

核心亮点

一位开发者用 mitmproxy 把 VS Code 中的 GitHub Copilot 流量做了中间人拦截，逆向拆解了它的网络请求、认证方式与后端调度逻辑。文章最有价值的洞察是：主流 AI 编程助手普遍基于 Electron，网络栈高度相似，因此对 Copilot 的探测方法可以平移到其他同类产品。

具体能力或事件经过

作者先在本地起一个 mitmproxy 实例，再把 VS Code 的 HTTPS 流量导向该代理，借助自签证书解密 Copilot 与远端服务之间的通信。过程中他记录下补全请求携带的元数据、模型路由路径，以及 IDE 与扩展进程间如何通过本地 socket 协作。文章还逐步给出了证书安装、代理转发与日志过滤的可复现指南。

技术细节

Copilot 的客户端并非直接对话大模型，而是先发往 GitHub 的网关，再由网关做鉴权、限流与模型选择。请求体里包含文件上下文窗口、光标位置与仓库结构摘要等信号。由于 Electron 应用共用 Chromium 的网络层，拦截手段对同类基于 Web 技术的 AI 桌面端基本通用，这正是文章强调"可迁移"的原因。

与竞品对比

相比闭源商业助手的黑盒体验，这种逆向思路更接近安全研究者的工作方式。Cursor、Windsurf 等同样基于 Electron 的产品，理论上可用相同手法观察其流量。差异在于各家网关的加密强度与是否启用证书绑定（certificate pinning），后者会显著提高拦截门槛。

行业影响或适用场景

对普通用户，这类分析有助于理解"我的代码到底发去了哪里"；对企业安全团队，则是评估 AI 编程工具数据合规性的起点。对开发者生态，公开运行时行为能倒逼厂商在透明度上做得更好。说白了，把 AI 助手放在代理后面看一眼，既是技术好奇，也是隐私意识的必修课。