浏览器可正常访问的云端Serverless API在curl/Postman中调用失败求助

1. TCP连接行为差异 #

• 浏览器一般会复用已建立的TCP连接（HTTP/1.1的Keep-Alive或HTTP/2多路复用），但默认情况下curl/Postman每次请求可能新建连接。部分云端网关或防火墙会拦截短生命周期的连接，尤其是Serverless环境下，冷启动或连接池策略容易触发这类限制。
• 浏览器发起跨域请求前会先发送OPTIONS预检请求，有些网关会校验连接时序——必须先过预检再发主请求，而curl直接发主请求会被直接中断连接，哪怕你复制了浏览器的请求头也没用。

2. TLS/SSL握手细节差异 #

• 浏览器用的是系统默认CA证书池，还支持更多TLS扩展（比如ALPN、SNI的特定实现），但curl/Postman可能因版本或配置问题，TLS握手时的加密套件、协议版本和浏览器不匹配，网关的TLS校验失败后直接断连。
• 不少云端网关会校验客户端的JA3指纹（TLS握手时的特征组合），浏览器和curl/Postman的JA3指纹完全不同，网关可能直接基于指纹做了拦截规则。

3. 请求环境的元数据差异 #

• 浏览器请求会携带系统层面的元数据，比如Windows下浏览器用WinHTTP栈，可能继承系统代理配置；但单独运行的curl/Postman可能用不同的网络栈或代理设置，导致请求走了不同路径被拦截。
• 部分防火墙会校验请求的进程标识或网络上下文，比如判断请求是否来自浏览器进程（通过系统调用痕迹），curl/Postman作为独立进程，这些痕迹不匹配就会被拦。

4. Cookie与会话上下文差异 #

• 浏览器里可能有之前交互留下的Cookie，哪怕你复制curl命令时带上了Cookie，有些网关会校验Cookie的生成上下文——比如是否来自同域的浏览器会话，curl直接带Cookie的话，缺少会话绑定的隐式标识（比如浏览器Storage相关的关联信息），照样被拒绝。

实用排查建议 #

• 用Wireshark抓包对比浏览器和curl的请求全流程，重点看TCP连接建立、TLS握手阶段的差异。
• 给curl指定和浏览器一致的TLS版本与加密套件，比如：curl --tlsv1.2 --ciphers ECDHE-ECDSA-AES128-GCM-SHA256 [你的API地址]
• 模拟浏览器的连接复用，用curl的--keepalive-time参数维持连接后再发请求。

内容的提问来源于stack exchange，提问作者iyaya lc