我正在 Charles Proxy 中拦截来自 iPhone 的 API 调用。我能够通过笔记本电脑上的 Charles Proxy 的“重复”功能重新运行这些 API 调用，并且它们成功了。但是，如果我将此 API 请求导出为 cURL 并运行 cURL，它将永远不会返回。如果我将 cURL 导入 Postman，请求不会成功。邮递员请求永远不会返回并最终超时。 Charles 代理请求是否有某些允许 API 调用成功但未包含在 cURL 中的功能？或者反之亦然？
所有 API 调用均从同一台笔记本电脑上的同一 IP 地址进行。
我尝试使用Postman的转换为代码功能在Python中运行请求，这也超时了。我还将 Charles Proxy 导出的 cURL 直接转换为 Python，完全绕过 Postman，这也超时了。我希望在 Charles Proxy 中工作的任何 API 调用都可以在其他地方工作，例如 Postman 和 Python 或作为 cURL。
这让我相信我在 Postman 和 Python 中进行的 API 调用一定有所不同，但我不确定它是如何不同的。我相信 Charles Proxy 生成的 cURL 一定有所不同。
更新：此问题仅发生在我的笔记本电脑上，无论我是否在 VPN 后面运行。尝试在不同位置的另一台计算机上复制这种情况会导致请求在 Charles Proxy 中工作并作为curl/python。
如果看不到具体代码，很难知道，但一种可能是 TLS 指纹识别。我已经在here写了对此的详细介绍（针对 Node.js，但概念在任何地方都是相同的）。
本质上：通过查看客户端如何建立初始 TLS 连接的小细节，在收到 HTTP 请求之前，服务器可以识别客户端的类型，因此它可以发现curl、Python、浏览器或其他客户端并处理不同。许多服务器使用它来尝试阻止自动机器人和抓取，通过阻止所有与某些已知指纹匹配的客户端。
在您的情况下，如果服务器专门阻止来自curl、Postman和Python的请求，但不阻止Charles，您会看到您所描述的行为。
您可以通过调整curl命令以通过Charles发送它来轻松确认这一点。如果相同的请求在通过 Charles 未经修改地发送时有效，但在直接发送时无效，那么差异几乎肯定是 TLS 指纹（唯一的其他可能性是 Charles 正在途中修改请求本身，但这几乎肯定是）是 Charles bug，我不知道有任何此类问题）。
当然还有其他可能性，特别是如果服务器行为异常，或者您的请求存在无效内容。客户端在收到不良数据时可以采取不同的行为方式，其中一些客户端会尽可能接受响应，而另一些客户端可能会超时或显式失败，这可以解释发生的情况。如果您想确定请求是否不同或者是否是由于客户端处理造成的，您需要使用像 Wireshark 这样的工具直接逐字节检查原始流量，看看是否有任何差异（请注意，对于 HTTPS 流量，您需要在客户端上使用 TLS 密钥日志记录选项才能解密 Wireshark 中的流量）