cURL - ... sometimes fails with cryptic messages


curl: (35) error:0A00010B:SSL routines::wrong version number


curl -x -o /etc/yum.repos.d/docker-ce.repo
curl: (35) error:0A00010B:SSL routines::wrong version number


As already seen here and here, the https:// in the proxy value (-x parameter) is wrong and should be http://.
The proxy itself is accessed by HTTP (not HTTPS) even though the target URL is HTTPS. The proxy will nevertheless properly handle HTTPS connection and keep the end-to-end encryption. See HTTP CONNECT method for details.


Replay the same command with http in the proxy value :
curl -x http://

TLSv1.2 (IN), TLS alert, close notify (256):

This message notifies the recipient that the sender will not send any more messages on this connection. Note that as of TLS 1.1, failure to properly close a connection no longer requires that a session not be resumed. This is a change from TLS 1.0 to conform with widespread implementation practice.

Expire in 0 ms for 1 (transfer 0x559d3dcc1bb0)

This is actually a debug message forgotten in the code and removed in february 2019.

curl: (52) Empty reply from server

Many reasons can cause this reply.

Reason 1 : you're doing it wrong :

curl: (52) Empty reply from server
curl: (35) Unknown SSL protocol error in connection to
When you want to use HTTPS (i.e. SSL / TLS over HTTP), you'll have to specify it in the scheme part of the URL, not with a trailing :443 (source) :
  • DO : curl
  • DON'T : curl
This is why commands using :443 fail : they're sending HTTP requests to the port 443 of the remote host, whereas this one is actually expecting HTTPS requests.

Let's have a look at this in more details :

One of the causes of this curl: (52) Empty reply from server error message would then be trying to use HTTP on a host only serving HTTPS. Let's check it :
curl: (7) couldn't connect to host
(UNKNOWN) [] 80 (http) : Connection timed out
(UNKNOWN) [] 443 (https) open
Confirmed !

Reason 2 : nobody's listening :

Once you've confirmed you're using cURL the right way, the reason why nobody replies is probably because nobody is listening (or you're not talking to the right guy ). To debug this, make sure :
  1. you get a similar empty response, no data sent from server, or something like that with an other tool such as wget or the Web Developer Firefox extension
  2. DNS resolution works as expected (and you're actually sending requests to the right server )
  3. you're contacting the right virtualhost (if any). Have a look at the access.log / error.log
  4. some process is actually listening on the specified IP+port
  5. the network configuration (route, firewall, forward + reverse proxy, NAT, ...) actually leads requests to this listening socket.
    Don't hesitate to sketch the desired vs observed setup : the bug is on one of those arrows

curl: (35) error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol


This is often caused by improperly setting the HTTP / HTTPS proxy value.



What does additional stuff not fine transfer.c:1037: 0 0 mean ?


A curl query returns a 141 exit code, and the message :
* additional stuff not fine transfer.c:1037: 0 0
* SSL read: error:00000000:lib(0):func(0):reason(0), errno 104
* Closing connection #0
What does that mean ?
Looks like this errno 104 is an SSL error, and is unrelated to cURL.


From Daniel Stenberg, the author of cURL :

About the 141 exit code (source) :

It usually means curl crashed (segfaulted) or similar.

About additional stuff not fine transfer.c:1037: 0 0 (source) :

> Under what circumstances will cURL print the following message:
> * additional stuff not fine transfer.c:1037: 0 0

That's a debug output I put there once to aid me debugging a transfer case I
had problems with and I then left it there. It is only present in debug builds
and basically if you need to ask about it, the message is not for you...



curl: (56) Recv failure: Connection reset by peer

Failure with receiving network data

curl: (7) Unsupported proxy scheme for ''

cURL doesn't support HTTPS proxy so you'll get this message to make you aware of that so that you don't think you're actually using a HTTPS proxy. You can workaround this by resetting the https_proxy environment variable, then retrying your cURL request :

https_proxy=; curl