未使用--bg参数时TLSv1.3测试失败，API调用却通过的原因排查

核心差异：nscurl的会话模式区别 #

• 不带-bg的nscurl --ats-diagnostics使用前台会话（Foreground Session），严格遵循系统默认的ATS（App Transport Security）配置与全局代理设置。如果你的系统配置了全局代理（如企业网关、VPN代理）且该代理不支持TLSv1.3，就会触发SSL握手失败（错误码-1200）。
• 添加-bg参数后，nscurl切换为后台会话（Background Session），这类会话的ATS规则更宽松，且默认会绕过系统全局代理（多数场景下），因此能直接与LinkedIn服务器完成TLSv1.3握手。
• 直接通过API发起请求时，多数网络库（如URLSession、Alamofire）默认的会话策略与后台会话类似，或支持自定义代理配置，因此也能避开不支持TLSv1.3的系统代理，成功建立TLSv1.3连接。

是否由终止SSL的代理导致？ #

是的，该现象大概率说明你处于**终止SSL的中间人代理（SSL Terminating Proxy）**之后：

• 这类代理会拦截客户端的SSL请求，先与客户端建立连接，再自行向目标服务器发起请求。若代理本身不支持TLSv1.3，就无法与客户端完成TLSv1.3握手，导致前台会话测试失败。
• 后台会话或自定义API请求绕过了该代理，直接与LinkedIn服务器建立TLSv1.3连接，因此测试正常通过。

内容的提问来源于stack exchange，提问作者Laith Rafid