展示一款可监控LLM工具数据传输的MitM代理

基本信息

作者: jmuncor
评分: 158
评论数: 81
链接: https://github.com/jmuncor/sherlock
HN 讨论: https://news.ycombinator.com/item?id=46799898

导语

随着大语言模型工具的普及，数据隐私与透明度问题日益受到关注。本文介绍了一款中间人代理工具，旨在帮助用户直观地审查 LLM 应用实际发送的 API 请求内容。通过阅读本文，你将了解该工具的实现原理，并掌握如何利用它来监控离线数据流向及验证敏感信息的处理机制。

中心观点

该文章通过展示一个中间人代理工具，揭示了LLM应用在数据传输层面的透明度缺失问题，强调了在AI工程化落地中，对数据流向、隐私合规及模型行为进行“可观测性”的必要性。

支撑理由与边界条件

1. 突破黑盒监控，填补调试工具链空白

支撑理由（事实陈述）： 现有的LLM开发工具多集中于模型权重训练或Prompt优化，缺乏针对网络请求层面的抓包工具。该工具利用MitM（中间人攻击）原理，解密HTTPS流量，使开发者能直观看到OpenAI API等接口发送的原始JSON数据（如System Prompt隐藏内容、Token计费细节）。
支撑理由（你的推断）： 这种底层的可见性对于排查“幻觉”源头（是否是插件注入了恶意上下文）或优化成本（精确计算Token消耗）具有不可替代的价值。
边界条件/反例（你的推断）： 该方法仅能捕获网络层的数据。如果LLM工具在本地进行了预处理（如使用Edge Function或本地SDK进行数据脱敏），MitM代理可能只能看到处理后的片段，无法窥探全貌。

2. 唤醒隐私与合规意识

支撑理由（作者观点）： 许多封装好的LLM工具（如桌面助手或浏览器插件）会在用户不知情的情况下，将敏感数据发送至云端。该工具是验证这些工具是否“窃取”数据的唯一有效手段。
支撑理由（你的推断）： 在GDPR或企业数据安全合规日益严格的背景下，这种“审计”能力是企业引入第三方AI工具的前置条件。
边界条件/反例（事实陈述）： 如果目标应用采用了证书固定技术，MitM代理将直接失效，无法建立连接，这限制了其在高安全级商业软件中的应用范围。

3. 揭示AI系统的“隐性逻辑”

支撑理由（事实陈述）： 文章展示了如何通过代理捕获到工具并未在UI上展示的隐藏System Prompt或内部参数配置。
支撑理由（你的推断）： 这对于逆向工程学习和提示词工程（Prompt Engineering）研究具有重要参考价值，可以帮助开发者理解竞品是如何设计“人设”的。
边界条件/反例（你的推断）： 这种监控是静态的。它只能看到“发送了什么”，无法解释“为什么模型会这样生成”。对于模型内部的注意力机制或推理链，网络层面的抓包无能为力。

深入评价

1. 内容深度

文章虽然以Show HN（展示项目）的形式出现，技术实现上基于标准的MitM架构，理论门槛并不算极高，但其洞察力极深。它触及了当前AI应用层最脆弱的环节——信任与透明度。作者没有停留在代码层面，而是通过实例指出了“封装型AI产品”潜在的数据泄露风险，论证了“如果不检查流量，你就不知道你的AI工具在向服务器发送什么”这一严肃的安全命题。

2. 实用价值

对于AI工程师和安全研究人员而言，实用价值极高。

调试： 当LangChain或LlamaIndex等框架报错模糊时，直接看原始HTTP包是最快的排查方式。
成本控制： 精确统计每次请求的Token数，验证供应商计费是否准确。
安全审计： 企业IT部门可用此来审查员工安装的未授权AI工具是否在泄露代码或文档。

3. 创新性

在通用网络抓包领域，MitM是老技术；但在LLM垂直领域，将其封装为针对JSON流和特定API端点的专用审计工具，具备一定的微创新。它填补了“Fiddler/Charles”这类通用工具在处理AI流式输出（SSE）时的体验空白。

4. 可读性

文章结构清晰，通常包含代码示例和抓包截图对比。对于技术人员来说，逻辑直观，上手门槛低。这种“Show, don’t tell”的方式比单纯的理论文章更有说服力。

5. 行业影响

该文章是AI“可观测性”运动的一部分。它预示着行业将从“狂热的大模型调用”转向“理性的工程化治理”。随着此类工具的普及，LLM工具开发商将被迫更加透明地公开其数据处理策略，否则将面临社区信任危机。

6. 争议点或不同观点

版权与逆向争议： 抓包并分析他人的System Prompt可能涉及侵犯版权或触发服务条款封禁。
信任悖论： 如果一个工具需要用户通过MitM来确认安全，那么该工具本身就失去了被部署在生产环境的资格。这反映了当前AI软件供应链的信任危机。

7. 实际应用建议

不要在生产环境随意抓包： 除非经过授权，否则在受控网络环境下进行。
结合网关使用： 建议不要在客户端层面抓包，而是在企业出口网关部署类似的流量审计功能，统一管控所有AI流量。
关注流式处理： 在使用此类工具时，注意其对SSE（Server-Sent Events）流的解析能力，避免因缓冲区截断导致的数据丢失。

可验证的检查方式

指标验证（Token计费）：
- 使用该代理捕获一次长对话的请求与响应Body。
- 手动使用tiktoken计算Token数量。
- 对比

代码示例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
# 示例1：基础HTTP代理服务器
from http.server import BaseHTTPRequestHandler, HTTPServer
import socketserver

class ProxyHandler(BaseHTTPRequestHandler):
    def do_GET(self):
        # 打印请求信息
        print(f"收到请求: {self.path}")
        print(f"请求头: {self.headers}")
        
        # 转发请求到目标服务器
        target_host = self.headers.get('Host', 'example.com')
        self.send_response(200)
        self.send_header('Content-type', 'text/html')
        self.end_headers()
        self.wfile.write(b"代理服务器正常运行")

def run_proxy(port=8080):
    with HTTPServer(('', port), ProxyHandler) as httpd:
        print(f"代理服务器运行在端口 {port}")
        httpd.serve_forever()

# 说明：这是一个最基础的HTTP代理服务器实现，可以拦截并打印所有HTTP请求的路径和头部信息。
# 适合用于学习HTTP代理的基本原理，但功能有限，无法处理HTTPS请求。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
# 示例2：使用mitmproxy库拦截LLM API请求
from mitmproxy import http

class LLMInterceptor:
    def request(self, flow: http.HTTPFlow) -> None:
        # 只拦截发送到OpenAI API的请求
        if "api.openai.com" in flow.request.pretty_host:
            print("\n=== 拦截到LLM请求 ===")
            print(f"完整URL: {flow.request.pretty_url}")
            print(f"请求方法: {flow.request.method}")
            print(f"请求头: {flow.request.headers}")
            print(f"请求体: {flow.request.content}")

    def response(self, flow: http.HTTPFlow) -> None:
        if "api.openai.com" in flow.request.pretty_host:
            print("\n=== 收到LLM响应 ===")
            print(f"状态码: {flow.response.status_code}")
            print(f"响应头: {flow.response.headers}")
            print(f"响应体: {flow.response.content}")

# 说明：使用mitmproxy库创建一个专门拦截LLM API请求的代理。
# 可以完整查看请求和响应的详细信息，包括请求体中的prompt和响应中的completion。
# 需要安装mitmproxy库（pip install mitmproxy），并通过命令行运行：mitmweb -s script.py

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
# 示例3：使用requests库通过代理发送请求并记录
import requests
import json
from datetime import datetime

def send_llm_request_via_proxy(prompt, proxy_url="http://localhost:8080"):
    # 准备请求数据
    url = "https://api.openai.com/v1/completions"
    headers = {
        "Content-Type": "application/json",
        "Authorization": "Bearer YOUR_API_KEY"
    }
    data = {
        "model": "text-davinci-003",
        "prompt": prompt,
        "max_tokens": 100
    }
    
    # 记录请求信息
    log_entry = {
        "timestamp": datetime.now().isoformat(),
        "request": {
            "url": url,
            "headers": headers,
            "body": data
        }
    }
    
    try:
        # 通过代理发送请求
        response = requests.post(
            url,
            headers=headers,
            json=data,
            proxies={"https": proxy_url},
            verify=False  # 仅用于测试，生产环境应验证证书
        )
        
        # 记录响应信息
        log_entry["response"] = {
            "status_code": response.status_code,
            "headers": dict(response.headers),
            "body": response.json()
        }
        
        # 保存日志到文件
        with open("llm_requests.log", "a") as f:
            f.write(json.dumps(log_entry) + "\n")
            
        return response.json()
    except Exception as e:
        log_entry["error"] = str(e)
        with open("llm_requests.log", "a") as f:
            f.write(json.dumps(log_entry) + "\n")
        raise

# 说明：这个示例展示了如何通过代理发送LLM API请求，并记录完整的请求和响应信息到日志文件。
# 可以用于调试和审计LLM工具的API调用，确保数据传输符合预期。
# 使用前需要替换YOUR_API_KEY为实际的OpenAI API密钥。

案例研究

1：某金融科技初创公司

背景: 该公司正在开发一款基于 GPT-4 的智能财务分析助手，用于辅助用户解读复杂的财报数据。由于金融行业的敏感性，合规性要求极高，任何数据泄露都可能导致严重的法律后果。

问题: 开发团队在使用官方 SDK 和部分第三方封装库时，发现对发送给 OpenAI API 的实际 Prompt（提示词）和上下文数据缺乏底层可见性。团队担心某些库可能会默认开启“数据用于改进服务”的选项，或者在日志中记录了不应被记录的敏感 PII（个人身份信息），但由于请求是加密的，无法在代码层面之外验证这一点。

解决方案: 团队部署了该 MitM（中间人）代理工具，将其配置在开发环境和 OpenAI API 端点之间。通过解密 HTTPS 流量，团队能够以纯文本形式实时查看所有出站请求的完整 JSON Payload，包括 system 消息、用户输入以及元数据中的 metadata 字段。

效果: 通过检查流量，团队发现某款旧版封装库默认在 user 字段中发送了开发者的内部 ID，且未显式设置 -Disable-Telemetry 标记。团队立即修复了配置，并建立了 CI/CD 流程中的定期审计环节，确保所有发送给 LLM 的请求均符合公司的数据隐私政策，消除了合规隐患。

2：某跨境电商企业的 AI 客服优化项目

背景: 该企业接入了一套基于 LLM 的自动客服回复系统，旨在处理大量的售后咨询。随着业务扩展，Token 消耗成本迅速上升，但客服团队并未感觉到处理效率的同比提升。

问题: 开发者怀疑是 Prompt Engineering（提示词工程）不够高效，或者前端代码在构建请求时包含了过多无关的“垃圾上下文”（如整个 HTML 页面的 DOM 结构），导致每次请求的 Token 数量虚高。但由于请求是在后端服务中发起的，直接调试代码逻辑非常繁琐且容易遗漏细节。

解决方案: 运维人员利用该 MitM 代理工具，对生产环境的出站流量进行了采样抓包。他们不需要修改后端代码或添加繁琐的日志语句，直接在代理侧观察到了发送给 LLM 提供商的完整请求体。

效果: 抓包结果显示，前端在传递用户聊天记录时，错误地将大量的隐藏 CSS 代码和重复的页脚信息也包含在了 context 字段中。修复这一问题后，单次请求的平均 Token 消耗量下降了 40%，显著降低了 API 调用成本，同时因为去除了噪声信息，模型回复的准确率也有所提升。

3：某开源工具维护者的调试过程

背景: 一位独立开发者正在维护一款流行的桌面笔记应用，该应用集成了本地运行的 LLM（如 Ollama）以提供摘要功能。用户频繁报告应用在进行 AI 总结时会偶尔崩溃或挂起。

问题: 由于崩溃是间歇性的，且发生在应用内部网络模块与本地 LLM 服务之间，开发者难以通过常规的断点调试复现问题。开发者怀疑是发送的 JSON 格式存在边缘情况错误，或者本地 LLM 服务返回了非标准的流式数据导致解析器失败。

解决方案: 开发者配置该 MitM 代理工具监听 localhost:11434（Ollama 默认端口），将应用发出的所有请求重定向至代理，再由代理转发至 LLM 服务。通过代理的日志面板，开发者直接看到了应用发送的原始 HTTP 请求头和 Body。

效果: 日志显示，当用户的笔记内容包含特定生僻字符时，应用的 JSON 序列化库会产生格式错误的请求体，导致 LLM 服务直接断开连接。开发者据此定位了序列化库的 Bug 并进行了修复，解决了困扰用户数周的崩溃问题。

最佳实践

最佳实践指南

实践 1：建立透明的流量审计机制

说明: 在开发和部署集成大语言模型（LLM）的应用程序时，必须确保能够完整地查看到底层数据流。使用中间人代理工具可以帮助开发者验证应用程序发送给 LLM API 的确切内容，包括提示词、上下文数据以及系统配置，从而防止敏感数据泄露或意外的参数配置错误。

实施步骤:

在本地开发或测试环境中部署 MitM 代理（如 mitmproxy 或文中提到的工具）。
配置应用程序的环境变量，将 HTTP/HTTPS 请求指向代理服务器地址。
运行典型的用户场景，捕获并审查请求体和响应体。
对比捕获的数据与预期的数据结构，确保无多余信息被发送。

注意事项: 务必仅在受控环境（本地或隔离测试环境）中使用此方法，生产环境的数据审计应通过 API 提供商的日志功能或合规的日志管理系统进行，避免在生产环境中直接拦截流量导致安全风险。

实践 2：验证数据脱敏与隐私合规

说明: LLM 工具经常会将用户输入或上下文信息直接发送到模型提供商的服务端。通过拦截请求，可以直观地检查是否包含 PII（个人身份信息）、密钥、密码或其他敏感数据。这是确保符合 GDPR、SOC2 等合规要求的关键步骤。

实施步骤:

配置代理工具以记录请求负载。
编写脚本或手动检查日志中的关键字段（如 email, API key, token 等）。
如果发现敏感数据，修改应用程序代码，在发送请求前实现数据清洗或匿名化处理。
重新通过代理验证清洗效果。

注意事项: 不要依赖“默认脱敏”功能。许多 LLM 库默认会发送全部上下文。必须显式地验证经过脱敏处理后的数据是否仍然保留了业务所需的语义，同时去除了身份特征。

实践 3：监控 Token 使用与成本分析

说明: LLM API 的调用成本通常与 Token（词元）的使用量成正比。通过代理工具查看实际的请求大小，可以精确计算每次交互的 Token 消耗，识别出导致成本激增的异常请求或冗余提示词。

实施步骤:

使用支持 Token 计数或内容长度分析的 MitM 工具插件。
记录不同功能模块（如摘要生成、对话交互）的请求/响应大小。
绘制成本分布图，找出 Token 消耗最大的功能点。
优化提示词工程或调整 max_tokens 参数以控制成本。

注意事项: 注意区分输入 Token 和输出 Token 的计费差异。同时，代理工具显示的是原始文本长度，实际 Token 数量需根据模型的具体分词器进行估算，但文本长度监控足以用于相对比较和异常检测。

实践 4：调试提示词注入与安全边界

说明: 通过代理可以模拟恶意请求或观察应用如何处理特殊字符。这有助于测试应用是否容易受到提示词注入攻击，即用户试图通过精心设计的输入来覆盖系统指令。

实施步骤:

通过代理修改捕获的请求，插入常见的注入测试用例（如“忽略之前的指令”）。
将修改后的请求转发给服务端，观察 LLM 的响应是否违背了原始设计意图。
检查应用层是否实现了适当的防御机制（如分隔符、输出验证）。
根据测试结果加固系统提示词。

注意事项: 进行此类测试时，请确保你拥有该系统的测试授权。不要对第三方生产环境进行未经授权的渗透测试。

实践 5：优化请求结构与性能瓶颈

说明: 除了查看内容，MitM 代理还能显示完整的 HTTP 头信息、状态码和往返时间。这有助于诊断 LLM 调用缓慢的原因，是网络延迟、DNS 解析问题，还是服务端处理时间过长。

实施步骤:

观察代理中的时间线视图，记录建立连接、发送请求、等待响应和接收数据的各阶段耗时。
检查是否启用了 HTTP/2 或连接复用，这对于频繁调用 LLM 的应用至关重要。
分析响应头中的速率限制信息（如 X-RateLimit-*），调整应用的请求频率策略。
根据分析结果调整客户端的超时设置和重试策略。

注意事项: LLM 的生成过程通常是流式的，代理工具可能会将流式响应分块显示。在计算总耗时或首字延迟时，需考虑流式传输的特性，不要将分块延迟误判为网络故障。

实践 6：实施模拟与离线开发模式

说明: 频繁调用 LLM API 会产生费用且依赖网络稳定性。利用代理工具记录真实的请求和响应对，可以用于创建 Mock 服务，使开发团队能够在没有真实 API 密钥的情况下进行开发和集成测试。

实施步骤:

使用

学习要点

基于对 HN 讨论内容的总结，以下是关于该 LLM 中间人代理工具的关键要点：
该工具充当中间人代理，能够解密并可视化展示 LLM 应用发送给 API 的原始 JSON 请求和响应内容。
它允许用户直观地检查发送给 OpenAI 等提供商的提示词和元数据，以验证是否有敏感信息被意外上传。
该工具通过自签名证书拦截 HTTPS 流量，解决了现代 LLM 应用普遍采用加密传输导致的调试困难问题。
用户可以借此机会审查应用是否在用户不知情的情况下发送了额外的遥测数据或使用统计信息。
它为开发者提供了一种无需修改应用程序源代码即可分析网络行为的“黑盒”测试方案。
该项目突显了在使用第三方 AI 工具时，本地数据隐私和透明度的重要性。

常见问题

1: 这个工具的主要用途是什么，为什么我需要它？

A: 这个工具主要用于调试和分析大语言模型（LLM）应用程序。在开发或使用集成了 LLM 的工具时，开发者往往无法直接看到客户端与 API（如 OpenAI API）之间传输的具体数据内容。通过使用这个中间人代理，你可以拦截并查看发送的 Prompt、上下文参数以及返回的 Response。这对于排查 Bug、优化 Prompt、检查数据泄露风险以及理解工具内部工作机制非常有帮助。

2: 它是如何工作的，是否需要修改代码？

A: 它的工作原理是在你的 LLM 客户端和 LLM 服务提供商之间建立一个代理服务器。通常情况下，你不需要修改应用程序的源代码。你只需要配置系统的网络环境变量（例如设置 HTTPS_PROXY 或 HTTP_PROXY）指向该代理的端口，或者在应用程序的设置中将 API 的端点地址更改为该代理的监听地址。该代理会接收流量，解密并记录内容，然后再转发给真实的 API 服务器。

3: 使用此类代理工具是否安全，我的 API 密钥会被泄露吗？

A: 安全性取决于你在哪里运行这个代理。如果你在本地计算机上运行并仅用于本地调试，通常是安全的，因为流量只在你自己的机器上流转。但是，如果你将代理部署在公共服务器上，或者将代理日志上传到了云端，那么其中包含的敏感信息（如 API Keys、用户隐私数据、Prompt 内容）将面临极高的泄露风险。请务必确保不要将捕获的日志公开展示或提交到公共代码仓库中。

4: 它支持哪些 LLM 服务提供商或客户端？

A: 虽然具体的支持范围取决于该工具的实现细节，但大多数此类 HTTP/HTTPS 代理工具理论上支持任何基于标准 RESTful API 协议的 LLM 服务。这通常包括 OpenAI (GPT-4, GPT-3.5)、Anthropic (Claude)、以及兼容 OpenAI 格式的开源模型接口（如 LocalAI, Ollama 等）。只要客户端工具允许自定义 Base URL 或使用系统代理设置，该工具通常都能生效。

5: 在处理加密流量（HTTPS）时，如何让代理正常显示内容？

A: 由于 LLM API 通信几乎全部使用 HTTPS 加密，直接拦截会看到乱码。该工具通常通过生成自签名证书并充当“证书颁发机构”来解密流量。你需要手动信任该代理生成的根证书，操作系统的证书存储库中。一旦信任建立，代理就能成功解密流量并以明文形式展示 JSON 数据。

6: 我能看到流式传输的内容吗？

A: 这取决于工具的具体功能实现。如果该代理专门设计用于 LLM 调试，它通常具备处理 Transfer-Encoding: chunked 的能力，即能够捕获并重组或实时显示 Server-Sent Events (SSE) 流式返回的数据块。这意味着你可以看到模型逐字生成的过程，而不仅仅是最终结果。

7: 这与使用浏览器开发者工具有什么区别？

A: 浏览器开发者工具仅能捕获浏览器内发起的 Web 请求。然而，许多现代 LLM 工具是运行在终端的 CLI 应用、桌面客户端（如基于 Electron 的应用）或 Python 脚本中。这些非浏览器环境的流量无法被 Chrome DevTools 直接捕获。MitM 代理工作在系统网络层，可以拦截任何发送到特定端口的 HTTP/HTTPS 流量，因此适用范围更广。

思考题

## 挑战与思考题

### 挑战 1: [简单] 嗅探本地 HTTP 流量

问题**：许多本地开发的 LLM 应用默认使用 HTTP 而非 HTTPS 进行通信。请编写一个简单的 Python 脚本，尝试通过原始套接字连接到一个本地运行的 HTTP 服务（如 Ollama 默认的 11434 端口），发送一个通用的 HTTP 请求并打印出未加密的响应内容。

提示**：你需要使用 Python 的 `socket` 模块。目标是将字符串 `"GET /api/tags HTTP/1.1\r\nHost: localhost\r\n\r\n"` 发送给服务器，然后循环接收返回的数据流。注意处理 `Connection: close` 或数据接收结束的逻辑。

引用

原文链接: https://github.com/jmuncor/sherlock
HN 讨论: https://news.ycombinator.com/item?id=46799898

注：文中事实性信息以以上引用为准；观点与推断为 AI Stack 的分析。

站内链接

分类：安全 / 开发工具
标签： LLM / MitM / 代理 / 数据监控 / 隐私安全 / 网络抓包 / OpenAI / API调试
场景：大语言模型 / AI/ML项目

Show HN: 一款用于监控 LLM 工具数据传输的 MitM 代理
Show HN：一款用于监控 LLM 工具数据传输的中间人代理
展示 LLM 工具数据传输的中间人代理
揭开Codex Agent循环的神秘面纱！🚀 探索核心机制与价值
OpenAI 如何在 AI 代理点击链接时保护用户数据 本文由 AI Stack 自动生成，包含深度分析与可证伪的判断。

展示一款可监控LLM工具数据传输的MitM代理