What is the curl error 52 "empty reply from server"?

I have a cron job setup on one server to run a backup script in PHP that is hosted on another server.

The command I've been using is

curl -sS http://www.example.com/backup.php

Lately I've been getting this error when the Cron runs:

curl: (52) Empty reply from server

If I go to the link directly in my browser the script runs fine and I get my little backup ZIP file.

This can happen if curl is asked to do plain HTTP on a server that does HTTPS.

Example:

$ curl http://google.com:443
curl: (52) Empty reply from server

Curl gives this error when there is no reply from a server, since it is an error for HTTP not to respond anything to a request.

I suspect the problem you have is that there is some piece of network infrastructure, like a firewall or a proxy, between you and the host in question. Getting this to work, therefore, will require you to discuss the issue with the people responsible for that hardware.

It can happen when server does not respond due to 100% CPU or Memory utilization.

I got this error when I was trying to access sonarqube API and the server was not responding due to full memory utilization

In my case it was server redirection; curl -L solved my problem.

Another common reason for an empty reply is timeout. Check all the hops from where the cron job is running from to your PHP/target server. There's probably a device/server/nginx/LB/proxy somewhere along the line that terminates the request earlier than you expected, resulting in an empty response.

In case of SSL connections this may be caused by issue in older versions of nginx server that segfault during curl and Safari requests. This bug was fixed around version 1.10 of nginx but there is still a lot of older versions of nginx on the internet.

For nginx admins: adding ssl_session_cache shared:SSL:1m; to http block should solve the problem.

I'm aware that OP was asking for non-SSL case but since this is the top page in goole for "empty reply from server" issue, I'm leaving the SSL answer here as I was one of many that was banging my head against the wall with this issue.

In my case this was caused by a PHP APC problem. First place to look would be the Apache error logs (if you are using Apache).

this error also can happen if the server is processing the data. It usually happens to me when I do post some files to REST API websites that have many entries and take long for the records creation and return

I ran into this error sporadically and could not understand. Googling did not help.

I finally found out. I run a couple of docker containers, among them NGINX and Apache. The command at hand addresses a specific container, running Apache. As it turned out, I also have a cron job doing some heavy lifting at times running on the same container. Depending on the load this cron job puts on this container, it was not able to answer my command in a timely manner, resulting in error 52 empty reply from server or even 502 Bad Gateway.

I discovered and verified this by plain curl when I noticed that the process I investigated took less than 2 seconds and all of a sudden I got a 52 error and then a 502 error and then again less than 2 seconds - so it was definitely not my code which was unchanged. Using ps aux within the container I saw the other process running and understood.

Actually, I was bothered by 502 Bad Gateway from NGINX with long running jobs and could not fix it with the appropriate parameters, so I finally gave up and switched these things to Apache. That's why I was puzzled even more about these errors.

The remedy is simple. I just fired up some more instances of this container with docker service scale and that was it. docker load balances on its own.

---

Well, there is more to this as another example showed. This time I did some repetitious jobs.

I found out that after some time I ran out of memory used by PHP which cannot be reclaimed, so the process died.

Why? Having more than a dozen containers on a 8GB RAM machine, I initially thought it would be a good idea to limit RAM usage on PHP containers to 50MB.

Stupid! I forgot about it, but swarmpit gave me a hint. I call ini_set("memory_limit",-1); in the constructor of my class, but that only went as far as those 50MB.

So I removed those restrictions from my compose file. Now those containers may use up to 8GB. The process runs with Apache for hours now and it looks like the problem is solved, memory usage rising to well beyond 100MB.

---

Another caveat: To easily get and read debug messages, I started said process in Opera under Windows. That is fine with errors appearing soon.

However, if the last one is cared for, quite naturally the process runs and runs and memory usage in the browser builds up, eventually making my local machine unusable. So if that happens, kill this tab and the process keeps running fine.

To turn @TechWisdom's comment into an answer: with Docker + Uvicorn (FastAPI) you need to bind to the Docker host with the Uvicorn command line option --host 0.0.0.0 (The default is 127.0.0.1).

Try this -> Instead of going through cURL, try pinging the site you’re trying to reach with Telnet. The response that your connection attempt returns will be exactly what cURL sees when it tries to connect (but which it unhelpfully obfuscates from you). Now, depending on what what you see here, you might draw one of several conclusions:

You’re attempting to connect to a website that’s a name-based virtual host, meaning it cannot be reached via IP address. Something’s gone wrong with the hostname—you may have mistyped something. Note that using GET instead of POST for parameters will give you a more concrete answer.

The issue may also be tied to the 100-continue header. Try running curl_getinfo($ch, CURLINFO_HTTP_CODE), and check the result.

you can try this curl -sS "http://www.example.com/backup.php" by putting your URL into "" that worked for me I don't know the exact reason but I suppose that putting the url into "" completes the request to the server or just completes the header request.

I've had this problem before. Figured out I had another application using the same port (3000).

Easy way to find this out:

In the terminal, type netstat -a -p TCP -n | grep 3000 (substitute the port you're using for the '3000'). If there is more than one listening, something else is already occupying that port. You should stop that process or change the port for your new process.

In my case (curl 7.47.0), it is because I set the header content-length on curl command manually with a value which is calculated by postman (I used postman to generate curl command parameters and copy them to shell). After I delete header content-length, it works normally.

My case was due to SSL certificate expiration

The question is very open in my opinion. I will share exactly what I was trying to achieve and how I resolved the problem

Context

Java app running on ports 8999 and 8990. App is running as a docker-compose stack in an AWS EC2 Ubuntu 20 server.

I added a Network Load Balancer that must receive traffic on TLS port 443 under an AWS ACM cert. The forwarding mechanism must be as it follows

1. port TLS 443 from NLB --> TCP port 8990 in the EC2 instance
2. port TCP 22 from NLB --> TCP port 8999 in the EC2 instance

I was getting the error from the curl CLI

Solution

I realized that there is a private AWS VPC that handles the traffic. The AWS EC2 instance runs in a private subnet. The AWS EC2 instance had security group rules that were blocking the traffic. The solution was to open all traffic 0.0.0.0/0 to the EC2 instance on ports 8990 and 8999

within AWS Load balancers i saw my target groups with healthy checks and after some client reboots and clearing of DNS cache I was able to access the application through HTTPS.

I faced this while making a request to my flask application which was using gunicorn for concurrency. The reason was that I set a timeout which was smaller than the time required for the server to process and give response to a single request. The following bash script shows how to set timeout in gunicorn.

#!/bin/bash

# Start Gunicorn processes
echo Starting Gunicorn.
exec $PWD/venv/bin/gunicorn server:app --worker-class sync --timeout 100000 --keep-alive 60 --error-logfile error.log --capture-output --log-level debug \
    --bind 0.0.0.0:9999

According to Gunicorn | timeout:

> Workers silent for more than this many seconds are killed and restarted. Value is a positive number or 0. Setting it to 0 has the effect of infinite timeouts by disabling timeouts for all workers entirely. Generally, the default of thirty seconds should suffice. Only set this noticeably higher if you’re sure of the repercussions for sync workers. For the non sync workers it just means that the worker process is still communicating and is not tied to the length of time required to handle a single request.

In my case I was using uwsgi, added the property http-timeout for more then 60 seconds but it was not working because of some extra space and config file was not getting loaded properly.

In my case, Reverse Proxy Nginx was on the way, the server directly sent the 500 code, via NGINX curl: (52) Empty reply from server

It happens when you are trying to access secure Website like Https.

I hope you missed 's'

Try Changing URL to curl -sS -u "username:password" https://www.example.com/backup.php