对于使用旧SSL协议的站点，Linux上的CURL可能会出现此错误。根据SSL/TLS协议规范，原因可能是客户端hello使用了对等方不支持的支持组选项。解决方案是使用sslscan进行探测，并获取对等方支持的协议版本和密码套件。SSLscan (Github)

当在虚拟机中使用Docker时，问题也可能是由HTTP服务器路径中不一致的MTU-s引起的。

{
  "mtu": 1450
}

进入/etc/docker/daemon.json
(make确保运行systemctl restart docker以使更改生效）
在我的例子中，有一个OpenStack VM在其接口上使用1450的MTU，但是Docker映像仍然创建了MTU为1500的虚拟接口。
如果curl在客户端hello之后挂起，则会出现MTU问题：
https://unix.stackexchange.com/questions/252977/curl-hangs-after-client-hello

我最近在连接到服务器上的微服务时遇到了这个问题。一切似乎都很好，它应该工作，但没有。错误代码是：

curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to ...

找到了根本原因。
这几乎可以肯定是其他人遇到的相同问题。一点背景知识......服务器是一个自定义服务器，它使用SSL SNI信息来推断它应该将TLS连接路由到哪个微服务。事件的顺序是：

1. TCP连接。
2. SSL握手开始。
   1.检查SNI，未启动TLS会话。
   1.已打开新套接字以侦听微服务。
   1.原始握手包作为TCP/TLS连接转发到微服务。
   在我的例子中，由于错误的SNI信息和错误配置的后端的组合错误，代理服务器无法找到正确的端点。因此，代理在握手过程中关闭了套接字，您会得到错误35。
   我怀疑这种情况会发生在HAProxy非终止连接中，例如：前端拾取、检查SNI，TCP后端未配置、找不到，或者后端服务未运行且无法连接。
   对于那些有这个问题，请确保上述所有设置都正确。在我的情况下，这是一个单一的字符输入错误导致的悲伤。想必其他问题，如一个坏的证书也可能导致类似的错误。我已经得到了28，35，和其他一些。所有相关的，一旦配置正确就解决了。
   希望这个有用。

问题是站点只支持不再被视为安全的密码，即基于3DES和RC 4的密码。出于安全原因，ssl库中的默认密码不包括这些密码。
要添加对这些密码的支持，您可以手动设置默认密码套件。下一行将DES-CBC 3-SHA设置为建议的密码。
curl --cipher DES-CBC3-SHA <your parameters>

**对所有站点使用此选项并不安全。**请注意，此选项应仅用于此旧站点。

我在尝试 curl git url时也遇到过类似的问题。
我查的是这个。

C:\Users\AWSAmazonCntAppIDDEV>"C:\Users\AWSAmazonCntAppIDDEV\Desktop\curl-7.78.0-win64-mingw\curl-7.78.0-win64-mingw\bin\curl.exe" -v https://gitlab.ff.xxxx-dns.com/users/sign_in
* Uses proxy env variable no_proxy == '*.xx.ffff-dns.com'
* Uses proxy env variable https_proxy == 'web-proxyapp.xx.ffff-dns.com:3128'
*   Trying 100.424.xxx.xx:3128...
* Connected to web-proxyapp.xx.ffff-dns.com:3128 (192.168.216.93) port 3128 (#0)
* allocate connect buffer!
* Establish HTTP proxy tunnel to gitlab.xx.ffff-dns.com:443
> CONNECT gitlab.us.bank-dns.com:443 HTTP/1.1
> Host: gitlab.xx.ffff-dns.com:443
> User-Agent: curl/7.78.0
> Proxy-Connection: Keep-Alive
>
< HTTP/1.1 200 Connection established
<
* Proxy replied 200 to CONNECT request
* CONNECT phase completed!
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: C:\Users\AWSAmazonCntAppIDDEV\Desktop\curl-7.78.0-win64-mingw\curl-7.78.0-win64-mingw\bin\curl-ca-bundle.crt
*  CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to gitlab.xx.ffff-dns.com:443
* Closing connection 0
curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to gitlab.xx.ffff-dns.com:443

在与网络团队交谈后，他们说，由于这是一个本地Intranet URL，因此没有必要通过代理将其隧道化。
所以从计算机上的环境变量中删除代理解决了这个问题。如果你需要更多的澄清，让我知道。

如果你从一个nginx服务器上请求，而该服务器希望在反向代理（使用proxy_protocol）之后，你应该在curl命令中添加--haproxy-protocol