proxyman-https-capture

Proxyman HTTPS 抓包

为用户的具体设备、运行时、网络和 Proxyman 平台选择干预最少且可用的抓包方式。常规代理抓包有三个相互独立的要求：将流量路由到 Proxyman、信任 Proxyman CA，以及为目标主机启用 SSL Proxying。Atlantis 是一种插桩替代方案，可将检查到的流量转发到 Proxyman，无需经过代理／CA／SSL Proxying 流程；使用时请遵守其单独的限制并进行验证。

工具缺失时使用 proxyman-mcp-setup；检查已捕获流量时使用 proxyman-traffic-debugging；处理主机 Mac 生成或自定义根证书的生命周期，或自定义服务器／客户端身份时使用 proxyman-certificates-recovery；若需要 setup 流程之外的最新官方文档，则使用 proxyman-debugging-tools。

收集最少必要信息

确认：

• 运行 Proxyman 的主机操作系统和应用版本；
• 目标类型、操作系统／运行时版本、实体设备还是模拟器／仿真器，以及调试版还是生产版；
• 目标如何连接到主机，以及是否存在 VPN、MDM、防火墙、代理或证书固定；
• 目标主机名，以及 HTTP 是否可见而 HTTPS 内容不可见，还是完全没有流量；
• 用户需要 GUI 操作步骤、MCP 引导的自动化，还是手动命令。

未经用户批准，不要安装证书、对仿真器获取 root 权限、更改系统代理、注入 shell／应用，或重启目标设备。

通用抓包模型

按以下顺序诊断：

1. **可达性：**目标可以访问运行 Proxyman 的主机。
2. **路由：**目标将 HTTP／HTTPS 发送到 Proxyman 当前的代理主机和端口。
3. **记录：**Proxyman 正在记录，且可以看到来源／客户端。
4. **信任：**目标信任相关存储中的正确 Proxyman 根 CA。
5. **SSL Proxying：**已包含目标主机，且未将其排除。
6. **应用行为：**库绕过代理、本地主机特殊处理、VPN、证书固定、QUIC／HTTP3 或自定义信任存储。

不要把证书安装视为路由正常的证明，也不要把启用 SSL Proxying 视为目标信任 CA 的证明。

选择一种方式

查看抓包方式，了解决策矩阵和官方页面链接。用户询问 Atlantis 是什么、需要在 VPN 阻止常规代理时抓包，或希望将 Atlantis 集成到应用中时，查看 Atlantis 抓包。

• 遵循系统代理设置的桌面浏览器／应用：使用系统代理并信任主机证书。
• iOS／iPadOS／Vision Pro 设备：使用 Wi-Fi 手动代理并在设备上信任证书；对于支持插入插桩库的应用，如果不希望配置代理／证书，或 VPN 阻止常规路径，可考虑使用 Atlantis。
• Apple 模拟器：将 CA 安装到已启动的模拟器中，并使用模拟器代理路径。
• tvOS／watchOS：遵循针对实体设备／模拟器的官方方式。
• Android 实体设备：使用 Wi-Fi 手动代理，并根据操作系统和应用策略选择用户 CA／系统 CA 方案。
• Android 仿真器：对于当前运行且兼容的 AVD，优先使用 Proxyman 的引导式自动化；查看 Android 仿真器安全注意事项。
• 终端运行时或浏览器：支持时优先使用 Automatic Setup／注入；否则使用明确指定的代理变量／选项，以及 运行时抓包中介绍的运行时 CA 证书包／存储。
• 本地主机：使用明确的代理配置或 Reverse Proxy；许多客户端会有意绕过系统代理。
• Docker／VM／子系统：使用可从该网络命名空间访问的主机地址，不要盲目使用 127.0.0.1。

MCP 引导式工作流

1. 执行 get_version 和 get_proxy_status。
2. 使用确切的目标、平台、运行时、VPN 和症状调用 answer_setup_question。
3. 阅读返回的引用；目标不明确时，使用 list_setup_workflows。
4. 对于常规代理路径，检查 get_certificate_status 和 get_ssl_proxying_list。对于 Atlantis，阅读 docs://setup/atlantis，不要强行进行证书或 SSL Proxying 设置。
5. 使用相关的内置资源或提示词。设置资源列于捕获路径参考中。
6. 说明自动化会如何更改状态，并征求同意。
7. 仅当运行中的服务提供所需操作且用户已批准时，才使用 run_guided_setup、inject_terminal、inject_electron、set_system_proxy、install_certificate 或 SSL 工具。
8. 从目标发起一个已知的 HTTPS 请求。
9. 使用 filter_flows 按主机查找请求，并在适用时指定 client；使用 get_flow_detail 检查请求。
10. 验证 HTTPS 正文是否可见、TLS/证书摘要以及目标身份。

如果 MCP 设置索引中没有完全匹配的条目，请通过 proxyman-debugging-tools 获取当前官方页面，而不要强行采用通用回退结果。

GUI 工作流

1. 对于常规代理目标，打开 Proxyman 的设置或证书指南。对于 Atlantis，请改为遵循专用集成参考。
2. 使用运行中应用显示的代理主机/端口；不要硬编码常见端口。
3. 按照当前官方页面中针对目标的路由和证书步骤操作。
4. 仅对所需主机或通配符启用 SSL Proxying。
5. 发起一个可确定复现的请求，并在 Proxyman 中验证。
6. 记录如何恢复代理、信任设置、模拟器启动映像或注入的环境。

故障排查

• **没有任何内容出现：**录制、路由、可达性或客户端来源问题。
• **出现 HTTP，但没有 HTTPS：**路由正常；检查目标信任、SSL Proxying、证书固定、HTTP3/QUIC 或自定义 CA 存储。
• **TLS 错误：**验证 CA 是否正确、是否完全信任、主机包含/排除规则、应用证书固定以及日期/时间。不要默认通过禁用 TLS 验证来解决问题。
• **仅缺少部分库的流量：**相关库可能绕过环境/系统代理，或使用独立的信任存储。
• **设备无法连接：**验证是否处于同一网络，或主机地址是否可路由；检查防火墙/访问控制、当前端口以及 VPN/Private Relay 的行为。
• **缺少 localhost 流量：**使用 Reverse Proxy，或通过显式代理设置指定非环回目标地址。
• **iOS 上的 VPN 冲突：**如果用户控制该构建，请阅读 Atlantis 决策路径，不要反复更改设备代理。
• **Android 应用拒绝用户 CA：**使用调试版网络安全配置，或采用受控且兼容的模拟器系统 CA 路径。不要建议在生产应用中绕过证书固定。

验证清单

仅当满足以下条件时，设置才算完成：

• 可以识别预期的目标/客户端；
• 测试请求和响应均已出现；
• 可通过预期路径读取 HTTPS 标头/正文：常规代理捕获路径下已解密，或由预期的 Atlantis 来源转发；
• 使用常规代理路径时，没有不必要地为无关主机启用 SSL Proxying；
• 用户了解回滚方法；
• 已说明证书固定、生产构建、VPN、root/Magisk 或不受支持的自动化等限制。