Show HN：可查看LLM工具数据传输的MitM代理

Show HN：可查看LLM工具数据传输的MitM代理

基本信息

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

导语

随着大语言模型（LLM）工具的普及，了解其与 API 交互的具体内容已成为保障数据安全与调试应用的关键环节。本文介绍的一款中间人代理工具，能够帮助开发者直观地查看这些工具在后台发送的请求细节。通过阅读本文，你将掌握该工具的配置方法，从而更有效地监控数据流向并排查潜在问题。

评论

一句话总结中心观点： 该文章展示了一个中间人代理工具，旨在通过拦截网络流量来揭示LLM应用程序在后台实际发送的数据内容，从而解决AI工具使用中的“黑盒”透明度问题。

支撑理由与边界条件：

1. 数据隐私与合规的刚需（事实陈述）： 随着企业将ChatGPT、Copilot等工具引入工作流，员工可能会无意中泄露代码、PII（个人身份信息）或商业机密。该工具提供了一种技术手段来验证“发送了什么”，是数据防泄漏（DLP）策略的重要补充。

   • 边界条件/反例： 如果LLM工具启用了端到端加密（E2EE）或证书绑定，单纯的MitM代理将无法解密流量，必须结合系统级Hook（如Frida）或浏览器扩展取证才能生效。

2. 调试与Prompt工程的实用价值（作者观点）： 开发者常困惑为何LLM响应不如预期。该工具允许开发者查看原始请求，确认系统提示词是否被篡改、参数设置是否正确，或是否存在隐藏的上下文注入。

   • 边界条件/反例： 许多现代AI客户端（如Cursor或桌面版ChatGPT）可能使用本地模型推理或WebSocket长连接传输二进制流，MitM代理可能只能看到乱码或无法重组的片段，降低了可读性。

3. 技术实现的低门槛与高普适性（你的推断）： 基于MitM（Man-in-the-Middle）的方案利用了HTTP/HTTPS协议的普遍性，相比于逆向工程二进制文件，这是一种非侵入式、通用的审计方法。

   • 边界条件/反例： 配置MitM代理对非技术用户门槛较高（涉及信任证书安装），且可能会触发杀毒软件的警报或导致目标应用因证书校验失败而拒绝连接。

深度评价

1. 内容深度：从“黑盒”到“灰盒”的必要一跃

文章虽然是一个工具展示（Show HN），但触及了LLM应用栈中最敏感的环节——数据流出边界。

• 论证严谨性： 从技术角度看，利用MitM Proxy（如mitmproxy）拦截HTTPS流量是成熟的网络取证技术。文章不仅展示了工具，更隐含了一个深刻的论点：在AI时代，我们需要重新审视“客户端”与“云端”的信任模型。它打破了厂商“安全隐私承诺”与“实际数据传输”之间的信息不对称。
• 局限性： 文章可能未深入探讨对抗性场景。例如，恶意软件或间谍软件可能会检测到代理环境并静默失败，或者使用DNS隧道等隐蔽通道外发数据，此时简单的HTTP代理是无效的。

2. 实用价值：企业合规与个人探索的双刃剑

• 企业侧： 这是目前AI治理中最缺乏的工具之一。企业安全团队可以使用此工具进行“影子AI”审计，确认员工使用的非授权AI工具是否上传了敏感代码库。
• 开发者侧： 对于构建RAG（检索增强生成）应用的开发者，查看原始JSON负载有助于调试Token计费逻辑和上下文截断问题。
• 实际指导意义： 它提醒我们，不要盲目信任客户端UI显示的内容。很多AI工具会发送“遥测数据”（如用户ID、设备指纹、部分对话历史用于训练），该工具能直观地揭露这些“隐形”载荷。

3. 创新性：组合式创新而非底层突破

• 新方法： 将传统的Web调试技术应用于AI流量审计，这属于应用层的创新。它没有发明新协议，而是将现有的透明度工具迁移到了新的技术栈上。
• 观点： 它提出了“可观测性下沉”的观点——即对AI工具的可观测性不应仅依赖厂商提供的Dashboard，而应下沉到网络传输层进行独立验证。

4. 可读性与逻辑性

通常此类Show HN文章逻辑清晰，遵循“痛点（不知道发了什么）-> 解决方案（MitM代理）-> 实现细节（代码/配置）”的逻辑。对于技术人员来说，通过查看抓包截图（如JSON格式的Prompt）能直观理解工具价值。但非技术人员可能难以理解证书信任链的配置过程。

5. 行业影响：推动“透明AI”的社区标准

此类工具的流行会对AI厂商形成压力。如果越来越多的用户使用代理发现厂商在未经同意下上传数据，将迫使厂商在客户端提供更详细的“数据使用说明”或“隐私模式”（如本地屏蔽敏感数据）。它促进了AI生态的透明化和可审计性。

6. 争议点与不同观点

• 法律与道德边界： 在公司网络中拦截员工流量可能涉及法律风险（如《电子通信隐私法》）。如果用于监控他人而非审计自己的工具，则存在严重的道德争议。
• 安全风险： 为了安装代理证书，用户必须将根证书加入系统信任库。如果该代理工具本身存在漏洞或被恶意篡改，反而会导致更严重的中间人攻击（如拦截银行密码）。
• 不同观点： 厂商可能会辩称，某些加密数据是为了保护模型知识产权或防止提示词注入攻击，用户的全量可见性可能会破坏安全机制。

7. 实际应用建议

代码示例

 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

# 示例1：简单的HTTP代理服务器
from http.server import HTTPServer, BaseHTTPRequestHandler
import requests

class ProxyHandler(BaseHTTPRequestHandler):
    def do_GET(self):
        # 转发请求到目标服务器
        url = self.path
        response = requests.get(url)
        
        # 将响应返回给客户端
        self.send_response(response.status_code)
        for header, value in response.headers.items():
            self.send_header(header, value)
        self.end_headers()
        self.wfile.write(response.content)
        
        # 打印请求和响应信息
        print(f"请求: {self.command} {url}")
        print(f"响应状态: {response.status_code}")
        print(f"响应内容: {response.text[:200]}...")  # 只打印前200个字符

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

if __name__ == '__main__':
    run_proxy()

 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

# 示例2：拦截并修改LLM API请求
from http.server import HTTPServer, BaseHTTPRequestHandler
import json
import requests

class LLMProxyHandler(BaseHTTPRequestHandler):
    def do_POST(self):
        # 读取请求体
        content_length = int(self.headers['Content-Length'])
        post_data = self.rfile.read(content_length)
        
        # 解析JSON请求
        try:
            request_data = json.loads(post_data.decode('utf-8'))
            print("\n=== 拦截的LLM请求 ===")
            print(json.dumps(request_data, indent=2, ensure_ascii=False))
            
            # 修改请求（示例：添加自定义参数）
            if 'temperature' not in request_data:
                request_data['temperature'] = 0.7
                print("\n已添加temperature参数: 0.7")
            
            # 转发修改后的请求
            modified_data = json.dumps(request_data).encode('utf-8')
            response = requests.post(
                self.path,
                data=modified_data,
                headers={'Content-Type': 'application/json'}
            )
            
            # 返回响应
            self.send_response(response.status_code)
            self.send_header('Content-Type', 'application/json')
            self.end_headers()
            self.wfile.write(response.content)
            
            print("\n=== API响应 ===")
            print(response.text[:500] + "...")
            
        except Exception as e:
            print(f"处理请求时出错: {str(e)}")
            self.send_error(400, 'Bad Request')

def run_llm_proxy(port=8080):
    server_address = ('', port)
    httpd = HTTPServer(server_address, LLMProxyHandler)
    print(f"LLM代理服务器运行在端口 {port}")
    httpd.serve_forever()

if __name__ == '__main__':
    run_llm_proxy()

 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

# 示例3：记录所有请求和响应到文件
from http.server import HTTPServer, BaseHTTPRequestHandler
import requests
import json
from datetime import datetime

class LoggingProxyHandler(BaseHTTPRequestHandler):
    def log_message(self, format, *args):
        # 记录到文件
        with open('proxy_log.txt', 'a', encoding='utf-8') as f:
            timestamp = datetime.now().strftime('%Y-%m-%d %H:%M:%S')
            f.write(f"[{timestamp}] {format % args}\n")
    
    def do_GET(self):
        url = self.path
        self.log_request(url)
        
        response = requests.get(url)
        self.log_response(response)
        
        self.send_response(response.status_code)
        for header, value in response.headers.items():
            self.send_header(header, value)
        self.end_headers()
        self.wfile.write(response.content)
    
    def log_request(self, url):
        with open('proxy_log.txt', 'a', encoding='utf-8') as f:
            timestamp = datetime.now().strftime('%Y-%m-%d %H:%M:%S')
            f.write(f"\n[{timestamp}] 请求: GET {url}\n")
    
    def log_response(self, response):
        with open('proxy_log.txt', 'a', encoding='utf-8') as f:
            timestamp = datetime.now().strftime('%Y-%m-%d %H:%M:%S')
            f.write(f"[{timestamp}] 响应: {response.status_code}\n")
            try:
                f.write(f"内容: {json.dumps(response.json(), indent=2, ensure_ascii=False)}\n")
            except:
                f.write(f"内容: {response.text[:200]}...\n")

def run_logging_proxy(port=8080):
    server_address = ('', port)
    httpd = HTTPServer(server_address, LoggingProxyHandler)
    print(f"带日志记录的代理服务器运行在端口 {port}")
    httpd.serve_forever()

if __name__ == '__main__':
    run_logging_proxy()

案例研究

1：某金融科技公司的智能客服合规审计

1：某金融科技公司的智能客服合规审计

背景: 该公司在核心的移动端APP中集成了大模型（LLM）功能，用于辅助客户进行理财咨询和合同条款解读。由于金融行业受到严格的监管（如GDPR或国内的《个人信息保护法》），任何传输给第三方API的数据都必须经过严格审查，以确保没有泄露用户的PII（个人身份信息）或敏感交易数据。

问题: 开发团队直接使用了LLM SDK进行开发，但在上线前的安全审计中发现，客户端代码中可能存在由于逻辑错误导致意外泄露上下文信息的风险。此外，合规部门需要验证实际发送给OpenAI或其他API的Prompt是否真的按照“数据脱敏”策略的要求移除了敏感字段，但现有的日志系统无法直接查看加密的HTTPS流量。

解决方案: 安全团队部署了该MitM代理工具，将其配置在测试环境的网关节点。通过让测试手机安装该代理的CA证书，团队成功解密并查看了客户端LLM SDK发出的所有HTTPS请求。他们详细检查了JSON请求体，确认了Prompt中是否包含用户ID、银行卡号或具体的交易金额。

效果: 通过代理抓包，团队发现了一处严重的逻辑漏洞：在某些长对话场景下，系统错误地将用户的全名历史记录包含在了新的API请求中。团队在正式上线前修复了此问题，避免了潜在的合规罚款和声誉损失。

2：一家AI驱动SaaS初创公司的成本与性能优化

2：一家AI驱动SaaS初创公司的成本与性能优化

背景: 这是一家专注于自动化文档生成的SaaS初创公司。他们的核心产品允许用户上传PDF并让AI重写摘要。为了优化用户体验，他们在客户端和后端之间构建了一个复杂的AI编排层，调用不同的模型（如GPT-4用于总结，GPT-3.5用于草稿）。

问题: 近期公司API成本飙升，但后台的计费日志与实际的业务量并不完全匹配。开发团队怀疑是某个特定模型的Token使用量异常，或者是由于重试机制导致的大量重复请求。由于请求链路经过了多个内部微服务，单纯通过代码逻辑很难定位到底是哪一步发送了冗余数据。

解决方案: 工程师利用该MitM代理工具，对本地开发环境的应用流量进行了拦截。他们不需要在代码的各个角落添加繁琐的打印日志，而是直接通过代理界面查看了所有流出的HTTP请求。这使得他们能够直观地看到每个请求的完整Prompt长度、响应时间以及具体的请求频率。

效果: 通过流量分析，团队发现客户端的一个UI组件存在Bug，导致在用户快速点击时会在毫秒级内发送三次完全相同的“Generate”请求。修复这个Bug后，公司的API账单在次月直接下降了约20%，同时也减轻了下游API的速率限制压力。

3：开源开发者的本地Prompt工程调试

3：开源开发者的本地Prompt工程调试

背景: 一位独立开发者正在构建一款基于Electron的桌面端写作助手，旨在帮助用户润色邮件。为了保护隐私，该应用设计为直接从用户的电脑连接到大模型提供商的API，而不经过开发者自己的服务器。

问题: 在开发过程中，开发者遇到了一个棘手的Bug：应用偶尔会返回格式错误的JSON，导致解析失败。由于错误是间歇性的，且涉及到底层库的自动重试和流式传输逻辑，仅靠IDE的调试器很难复现网络层面的具体交互过程。开发者不确定是自己的Prompt构建有问题，还是LLM返回的内容被截断了。

解决方案: 开发者启动了该MitM代理工具，并将Electron应用的代理设置指向本地端口。通过查看代理的实时日志，他清晰地看到了应用发送给LLM的完整System Prompt和User Prompt，以及LLM返回的原始流式响应块。

效果: 通过检查原始流量，开发者发现自己在构建System Prompt时遗漏了一个关键的格式约束指令，导致模型在某些特定输入下返回了Markdown而非JSON。他在代理中直接复制了请求体，在独立的API调试工具中验证了修复后的Prompt，极大地缩短了调试周期。

最佳实践

最佳实践指南

实践 1：建立透明的流量监控机制

说明：在开发和调试集成大语言模型（LLM）的应用时，网络请求的透明度至关重要。通过部署中间人代理，可以完整地查看客户端发送给 LLM API 的原始 Prompt、上下文数据以及返回的响应内容。这有助于验证数据是否符合预期，以及排查格式错误。

实施步骤：

1. 选择或搭建一个支持 HTTPS 解密的 MitM 代理工具（如 mitmproxy）。
2. 配置客户端或应用环境，将网络代理指向该工具的监听端口。
3. 安装并信任代理的自签名证书，以确保能够解密 HTTPS 流量。
4. 发起测试请求，在代理界面中检查请求体和响应体的 JSON 结构。

注意事项：确保仅在受控的开发或测试环境中启用此监控，避免在生产环境泄露敏感数据。

实践 2：严格审查敏感数据泄露

说明：LLM 应用很容易无意中将个人身份信息（PII）、API 密钥或内部机密发送给外部提供商。使用代理工具可以实时拦截并检查出站流量，确保没有违反数据隐私策略或合规性要求。

实施步骤：

1. 在代理工具中设置过滤规则，仅关注 POST 请求或特定的 API 端点。
2. 检查请求体中的 messages、prompt 或 system 字段，查找硬编码的密码、邮箱地址或内部 Token。
3. 利用代理的脚本功能编写自动化检查脚本，对特定关键词（如 “secret”, “key”, “password”）进行高亮或拦截。

注意事项：如果在日志中发现敏感数据，应立即追溯代码源头，并使用数据脱敏技术或环境变量来修复问题。

实践 3：验证 Token 消耗与成本预估

说明：LLM 服务通常基于 Token 数量计费。通过代理捕获请求和响应，可以手动或自动计算实际消耗的 Token 数量，并与提供商的账单进行比对，防止因意外的长上下文请求或无限循环导致的成本爆炸。

实施步骤：

1. 在代理日志中查看请求头或响应元数据中的 usage 字段（通常包含 prompt_tokens, completion_tokens, total_tokens）。
2. 记录不同类型 Prompt 的 Token 消耗基准，建立成本预估模型。
3. 设置异常报警，如果单次请求的 Token 数超过预设阈值（如 4k 或 8k），则发出警告。

注意事项：注意区分输入 Token 和输出 Token 的价格差异，某些模型对这两者的收费标准不同。

实践 4：监控响应质量与异常处理

说明：网络层面的监控不仅能看数据，还能看状态。通过代理可以观察到 LLM 返回的 HTTP 状态码、超时情况或流式传输（SSE）的中断情况。这对于评估服务的稳定性和优化重试逻辑非常有帮助。

实施步骤：

1. 观察代理中的响应时间，识别延迟过高的请求。
2. 检查 HTTP 状态码，除了 200 OK，还要特别关注 429 (Too Many Requests) 或 500 系列错误。
3. 如果使用流式响应，检查数据块是否完整传输，是否存在连接意外重置。

注意事项：结合应用层的日志，区分是网络问题（如代理连接断开）还是 API 服务本身的问题。

实践 5：模拟 API 故障与限流测试

说明：利用 MitM 代理的修改请求/响应功能，可以模拟 LLM 服务不可用、返回错误信息或限流的情况。这是测试应用容错能力的最佳实践，确保在真实 API 出现问题时，客户端能够优雅降级。

实施步骤：

1. 配置代理的断点或重写规则。
2. 模拟返回 429 状态码，检查应用是否正确实施了退避重试策略。
3. 模拟返回格式错误的 JSON 或超长的响应文本，测试应用的解析器是否会崩溃。
4. 模拟极高的网络延迟，验证用户界面是否正确显示加载状态。

注意事项：测试完成后，务必移除代理中的修改规则，以免影响正常的开发流程。

实践 6：确保环境隔离与权限控制

说明：能够拦截流量意味着拥有巨大的权限。必须严格区分生产环境和开发/测试环境的网络配置，确保生产环境的流量不会被意外重定向到本地代理，同时也防止代理工具成为安全漏洞。

实施步骤：

1. 使用环境变量（如 HTTP_PROXY 和 HTTPS_PROXY）来控制代理设置，并确保这些变量不会在生产环境的配置脚本中启用。
2. 为代理工具设置访问控制列表（ACL）或绑定到 localhost，不对外开放监听端口。
3. 定期清理代理的日志文件，防止硬盘空间耗尽或历史数据泄露。

注意事项：如果必须在生产服务器上抓包以排查问题，请确保操作有审计日志，并在排查结束后立即关闭代理服务。

学习要点

• 该工具通过充当中间人代理（MitM），解密并可视化大语言模型（LLM）应用与 API 之间传输的 JSON 数据，揭示了隐藏在加密流量背后的真实请求内容。
• 它能帮助用户验证应用是否将敏感数据（如 API Key、个人身份信息或内部代码）发送到了第三方服务器，从而识别潜在的数据泄露风险。
• 通过分析具体的 Prompt 构造和发送的参数，开发者可以学习如何优化提示词或调整模型参数（如 temperature），以获得更好的输出效果。
• 该工具支持对流量进行拦截和修改，允许安全研究人员在不修改应用源代码的情况下，测试 LLM 对恶意输入或异常参数的响应。
• 它解决了 LLM 应用生态中普遍存在的“黑盒”问题，让用户能够看清工具实际消耗了多少 Token 以及具体的计费依据。
• 这种方法为审查 AI 工具的隐私政策和合规性提供了技术手段，确保软件行为与其声明的数据处理规范一致。
• 相比于直接阅读源代码，抓包分析能够更直观地展示应用在运行时的真实网络行为，发现隐藏的后台连接或遥测数据上报。

常见问题

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

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

A: 这个工具是一个中间人代理，主要用于调试和分析大语言模型（LLM）应用。当你使用基于 LLM 的第三方工具或客户端时，你无法直接看到它们发送给 OpenAI 或 Anthropic 等 API 的具体数据。通过使用这个代理，你可以拦截并查看这些请求的原始内容，包括完整的 Prompt（提示词）、系统指令以及发送的元数据。这对于开发者调试 Prompt、监控数据隐私以及理解工具背后的工作机制非常有帮助。

2: 如何配置我的 LLM 应用程序或脚本来使用这个代理？

2: 如何配置我的 LLM 应用程序或脚本来使用这个代理？

A: 配置方法通常与配置标准的 HTTP 代理类似。大多数 LLM 库（如 LangChain、LlamaIndex 或 OpenAI 的 Python/JS 库）都允许通过环境变量或初始化参数来设置自定义的端点或代理。具体来说，你需要将原本发送给 api.openai.com 的流量指向该代理运行的本地地址（例如 http://localhost:8080）。该代理会负责接收请求、记录日志，并将其转发给真实的 API 服务器，最后再将响应返回给你的应用程序。

3: 使用这种代理工具会拦截或泄露我的 API Key 和敏感数据吗？

3: 使用这种代理工具会拦截或泄露我的 API Key 和敏感数据吗？

A: 这是一个合法的安全隐患，必须谨慎对待。由于该工具是一个中间人代理，它确实会看到经过它的所有数据，包括你的 API Key、Prompt 内容以及生成的回复。因此，绝对不要在不可信的环境或公共服务器上运行此类代理并将其暴露给公网。最佳实践是仅在本地主机运行此工具，用于离线调试或个人开发环境。如果你使用的是别人的代理服务，请务必意识到你的数据正在被第三方服务器处理。

4: 这个工具支持哪些 LLM 提供商（如 OpenAI, Claude, 本地模型）？

4: 这个工具支持哪些 LLM 提供商（如 OpenAI, Claude, 本地模型）？

A: 虽然具体支持范围取决于工具的实现细节，但大多数此类 MITM 代理旨在兼容通用的 HTTP API 结构。通常，它们支持 OpenAI 格式的 API（这是目前许多 LLM 提供商遵循的标准）。这意味着它不仅支持 OpenAI (GPT-4, GPT-3.5)，通常也支持像 Anthropic (Claude) 这样兼容 OpenAI SDK 的服务，或者任何允许自定义 Base URL 的本地托管模型（如 Ollama, LocalAI）。你需要查看该项目的具体文档以确认兼容性列表。

5: 它与 Charles Proxy 或 Fiddler 等传统抓包工具有什么区别？

5: 它与 Charles Proxy 或 Fiddler 等传统抓包工具有什么区别？

A: 虽然传统的抓包工具（如 Charles 或 Fiddler）也能做到这一点，但它们是通用的网络调试工具，配置起来可能比较繁琐，特别是处理 HTTPS 证书安装和 SSL Pinning 绕过时。专门针对 LLM 的 MITM 代理通常针对 JSON 数据进行了优化，提供了更友好的界面来查看请求体，可能还具备高亮显示 JSON 结构、计算 Token 数量或自动格式化 Markdown 等特定功能，使得调试 Prompt 比在原始的抓包工具中查看文本流更加直观高效。

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

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

A: 这取决于工具的具体实现，但现代 LLM 交互通常使用 Server-Sent Events (SSE) 进行流式传输。一个设计良好的 MITM 代理应该能够处理流式响应。它可能会选择缓冲整个响应以供查看，或者实时显示接收到的数据块。如果该工具专门用于调试，它通常会将流式事件重新组合或以易于阅读的方式展示，以便你能看到模型生成的完整过程。

7: 使用此工具会影响我的应用程序性能或增加 API 延迟吗？

7: 使用此工具会影响我的应用程序性能或增加 API 延迟吗？

A: 会有轻微的影响，但在本地开发环境中通常可以忽略不计。因为请求需要经过一个额外的中间层（代理），这会增加极少量的网络跳转延迟和处理时间（用于日志记录和数据显示）。对于非实时性要求极高的调试场景，这种延迟是完全可接受的。然而，不建议在生产环境或高并发的实时应用中通过此类代理来路由流量，因为它可能成为性能瓶颈并增加故障点。

思考题

## 挑战与思考题

### 挑战 1: [简单]

问题**: 许多 LLM 应用（如桌面客户端或 IDE 插件）并不提供简单的设置面板来配置 HTTP 代理。假设你有一个运行在 localhost:8080 的 MitM 代理，请列出至少两种在操作系统层面强制将目标应用程序的流量路由到该代理的方法。

提示**: 考虑操作系统的环境变量设置（如 HTTP_PROXY）以及针对特定进程的网络命名空间或工具（如 Linux 下的 proxychains 或 Windows 系统代理设置）。

引用

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

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

站内链接

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

相关文章

• Show HN: 一款用于监控 LLM 工具数据传输的 MitM 代理
• 展示一款可监控LLM工具数据传输的MitM代理
• 展示 LLM 工具数据传输的中间人代理
• Show HN: 可视化 LLM 工具数据传输的 MitM 代理
• Show HN：一款用于监控 LLM 工具数据传输的中间人代理 本文由 AI Stack 自动生成，包含深度分析与可证伪的判断。