blocks|key|1693035|text|如果curl被要求在执行HTTPS的服务器上执行纯HTTP，就会发生这种情况。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1693036|示例：|1693037|$+curl+http://google.com:443
curl:+(52)+Empty+reply+from+server|code-block|syntax|javascript|1693038|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|L|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|M|8|@]|9|@]|A|$G|H]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

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

Example:

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

blocks|key|3803527|text|当没有来自服务器的响应时，Curl会给出这个错误，因为HTTP不响应请求是一个错误。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3803528|我怀疑您的问题是在您和有问题的主机之间有一些网络基础设施，比如防火墙或代理。因此，要使其正常工作，您需要与负责该硬件的人员讨论该问题。|3803529|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

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.

blocks|key|5219823|text|当服务器由于100%25的CPU或内存使用率而没有响应时，可能会发生这种情况。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|5219824|当我试图访问sonarqube+API时，服务器由于内存使用率已满而没有响应时，我得到了这个错误|5219825|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

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

blocks|key|1464820|text|在我的例子中，它是服务器重定向；curl+-L解决了我的问题。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1464821|entityMap^0|G|7|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|K|8|@]|D|@]|E|$]]]|G|$]]

In my case it was server redirection; <code>curl -L</code> solved my problem.

blocks|key|1469542|text|空回复的另一个常见原因是超时。检查从运行cron作业的位置到PHP/目标服务器的所有跃点。可能有一个设备/服务器/nginx/LB/proxy在某处终止请求，这比您预期的要早，从而导致一个空响应。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1469543|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

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.

blocks|key|5219888|text|在SSL连接的情况下，这可能是由于较早版本的nginx服务器在curl和Safari请求期间出现段故障而导致的。This+bug在nginx的版本1.10左右得到了修复，但在互联网上仍然有很多旧版本的nginx。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|5219889|对于nginx管理员:在http块中添加ssl_session_cache+shared:SSL:1m;应该可以解决这个问题。|style|CODE|5219890|我知道OP要求的是非SSL情况，但由于这是goole中“服务器的空回复”问题的首页，我将SSL的答案留在这里，因为我是许多人中的一个，这个问题让我的头撞到墙上。|5219891|entityMap|0|LINK|mutability|MUTABLE|url|https://trac.nginx.org/nginx/ticket/235^0|1K|8|0|0|C|4|K|W|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@$A|S|B|T|1|U]]|C|$]]|$1|D|3|E|5|6|7|V|8|@$A|W|B|X|F|G]|$A|Y|B|Z|F|G]]|9|@]|C|$]]|$1|H|3|I|5|6|7|10|8|@]|9|@]|C|$]]|$1|J|3|-4|5|6|7|11|8|@]|9|@]|C|$]]]|K|$L|$5|M|N|O|C|$P|Q]]]]

In case of SSL connections this may be caused by issue in older versions of nginx server that segfault during curl and Safari requests. <a href="https://trac.nginx.org/nginx/ticket/235" rel="noreferrer">This bug</a> 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 <code>ssl_session_cache shared:SSL:1m;</code> to <code>http</code> 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.

blocks|key|3803563|text|在我的例子中，这是由PHP+APC问题引起的。首先要查看的是Apache错误日志(如果您使用的是Apache)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3803564|希望这对某些人有帮助。|3803565|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

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).

Hope this helps somebody.

blocks|key|1693213|text|如果服务器正在处理数据，也可能发生此错误。当我在REST+API网站上发布一些文件时，通常会发生这种情况，因为这些网站有很多条目，并且记录的创建和返回需要很长时间|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1693214|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

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

blocks|key|3803976|text|我偶尔遇到这个错误，无法理解。谷歌搜索也无济于事。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3803977|我终于发现了。我运行了几个docker容器，其中包括NGINX和Apache。手边的命令处理一个特定的容器，运行Apache。事实证明，我也有一个cron工作，有时在同一个容器上运行一些繁重的提升。根据这个cron作业对容器的负载，它不能及时响应我的命令，从而导致error+52+empty+reply+from+server甚至502+Bad+Gateway。|offset|length|style|CODE|3803978|我通过普通的curl发现并验证了这一点，当我注意到我调查的过程只用了不到2秒，突然我得到了一个52错误，然后是502错误，然后又是不到2秒-所以绝对不是我的代码没有改变。在容器中使用ps+aux时，我看到了另一个进程正在运行，并理解了这一点。|3803979|实际上，我被来自NGINX的长时间运行作业的502+Bad+Gateway所困扰，并且不能用适当的参数修复它，所以我最终放弃了，并将这些东西切换到Apache。这就是为什么我对这些错误更加困惑的原因。|3803980|补救办法很简单。我只是用docker+service+scale启动了这个容器的更多实例，仅此而已。docker可自行实现负载均衡。|3803981|3803982|好吧，正如另一个例子所示，还有更多的东西。这一次我做了一些重复的工作。|3803983|我发现一段时间后，我用完了PHP使用的内存，无法回收，所以进程死了。|3803984|为什么？在一台8+8GB的RAM机器上有十几个容器，我最初认为将PHP容器上的RAM使用量限制在50MB是个好主意。|3803985|太愚蠢了！我忘了，但是swarmpit给了我一个提示。我在我的类的构造函数中调用了ini_set("memory_limit",-1);，但这只能达到50MB。|3803986|因此，我从我的撰写文件中删除了这些限制。现在，这些容器可以使用高达8+8GB的空间。这个进程现在已经在Apache上运行了几个小时，看起来问题已经解决了，内存使用量上升到100MB以上。|3803987|3803988|另一个警告:为了方便地获取和读取调试消息，我在Windows下的Opera中启动了上述进程。这很好，因为很快就会出现错误。|3803989|但是，如果处理最后一个，很自然地，进程会不断运行，浏览器中的内存使用量会增加，最终导致我的本地计算机不可用。因此，如果发生这种情况，取消此选项卡，该进程将继续正常运行。|3803990|entityMap^0|0|Q|5|W|6|1K|6|21|4|2V|4|3O|W|4M|F|0|6|4|2J|6|0|8|5|M|F|21|6|0|C|K|1E|6|0|0|0|0|0|B|8|15|R|0|0|0|N|7|W|5|0|0^^$0|@$1|2|3|4|5|6|7|15|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|16|8|@$D|17|E|18|F|G]|$D|19|E|1A|F|G]|$D|1B|E|1C|F|G]|$D|1D|E|1E|F|G]|$D|1F|E|1G|F|G]|$D|1H|E|1I|F|G]|$D|1J|E|1K|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|1L|8|@$D|1M|E|1N|F|G]|$D|1O|E|1P|F|G]]|9|@]|A|$]]|$1|J|3|K|5|6|7|1Q|8|@$D|1R|E|1S|F|G]|$D|1T|E|1U|F|G]|$D|1V|E|1W|F|G]]|9|@]|A|$]]|$1|L|3|M|5|6|7|1X|8|@$D|1Y|E|1Z|F|G]|$D|20|E|21|F|G]]|9|@]|A|$]]|$1|N|3|-4|5|6|7|22|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|23|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|24|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|25|8|@]|9|@]|A|$]]|$1|U|3|V|5|6|7|26|8|@$D|27|E|28|F|G]|$D|29|E|2A|F|G]]|9|@]|A|$]]|$1|W|3|X|5|6|7|2B|8|@]|9|@]|A|$]]|$1|Y|3|-4|5|6|7|2C|8|@]|9|@]|A|$]]|$1|Z|3|10|5|6|7|2D|8|@$D|2E|E|2F|F|G]|$D|2G|E|2H|F|G]]|9|@]|A|$]]|$1|11|3|12|5|6|7|2I|8|@]|9|@]|A|$]]|$1|13|3|-4|5|6|7|2J|8|@]|9|@]|A|$]]]|14|$]]

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 <code>NGINX</code> and <code>Apache</code>. The command at hand addresses a specific container, running <code>Apache</code>. As it turned out, I also have a <code>cron</code> job doing some heavy lifting at times running on the same container. Depending on the load this <code>cron</code> job puts on this container, it was not able to answer my command in a timely manner, resulting in <code>error 52 empty reply from server</code> or even <code>502 Bad Gateway</code>.
I discovered and verified this by plain <code>curl</code> 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 <code>ps aux</code> within the container I saw the other process running and understood.
Actually, I was bothered by <code>502 Bad Gateway</code> from <code>NGINX</code> with long running jobs and could not fix it with the appropriate parameters, so I finally gave up and switched these things to <code>Apache</code>. 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 <code>docker service scale</code> and that was it. <code>docker</code> load balances on its own.
<hr />
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 <code>swarmpit</code> gave me a hint. I call <code>ini_set(&quot;memory_limit&quot;,-1);</code> 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.
<hr />
Another caveat: To easily get and read debug messages, I started said process in <code>Opera</code> under <code>Windows</code>. 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.

blocks|key|5219739|text|尝试使用this+->而不是通过cURL，尝试使用远程登录来going您要访问的站点。您的连接尝试返回的响应将与cURL在尝试连接时所看到的完全相同(但它无助地混淆了您的信息)。现在，根据您在这里看到的内容，您可能会得出以下几个结论之一：|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|5219740|您正在尝试连接到基于名称的虚拟主机的网站，这意味着无法通过IP地址访问该网站。主机名有问题-您可能输入了错误的内容。请注意，对参数使用GET而不是POST会给出更具体的答案。|5219741|这个问题也可能与100-continue标头有关。尝试运行curl_getinfo($ch,+CURLINFO_HTTP_CODE)，并检查结果。|style|CODE|5219742|entityMap|0|LINK|mutability|MUTABLE|url|https://www.libertycenterone.com/blog/how-to-troubleshoot-connectivity-when-curl-gets-an-empty-response/^0|4|4|0|0|0|T|11|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@$A|S|B|T|1|U]]|C|$]]|$1|D|3|E|5|6|7|V|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|W|8|@$A|X|B|Y|H|I]]|9|@]|C|$]]|$1|J|3|-4|5|6|7|Z|8|@]|9|@]|C|$]]]|K|$L|$5|M|N|O|C|$P|Q]]]]

Try <a href="https://www.libertycenterone.com/blog/how-to-troubleshoot-connectivity-when-curl-gets-an-empty-response/" rel="nofollow">this</a> -> 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 <code>curl_getinfo($ch, CURLINFO_HTTP_CODE)</code>, and check the result.

blocks|key|5219769|text|你可以尝试这个curl+-sS+"http://www.example.com/backup.php“，方法是把你的URL放到"”里面，我不知道确切的原因，但是我想把url放到"“里就完成了对服务器的请求，或者只是完成了头请求。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|5219770|entityMap|0|LINK|mutability|MUTABLE|url|http://www.example.com/backup.php^0|H|X|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

you can try this curl -sS "<a href="http://www.example.com/backup.php" rel="nofollow">http://www.example.com/backup.php</a>"
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.

blocks|key|1469533|text|我以前遇到过这个问题。我计算出我有另一个应用程序使用相同的端口(3000)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1469534|找出这一点的简单方法：|1469535|在终端中，输入netstat+-a+-p+TCP+-n+%7C+grep+3000+(用您正在使用的端口替换'3000')。如果有多个监听，则其他端口已在占用该端口。您应该停止该进程或更改新进程的端口。|offset|length|style|CODE|1469536|entityMap^0|0|0|7|W|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|N|8|@$F|O|G|P|H|I]]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

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 <code>netstat -a -p TCP -n | grep 3000</code> (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.

blocks|key|3803822|text|在我的例子(curl+7.47.0)中，这是因为我用postman计算的值手动设置了curl命令的头content-length+(我使用postman生成curl命令参数并将它们复制到shell)。删除header+content-length后，它可以正常工作。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|3803823|entityMap^0|1E|E|31|E|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]|$9|K|A|L|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|M|8|@]|D|@]|E|$]]]|G|$]]

In my case (curl 7.47.0), it is because I set the header <code>content-length</code> 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 <code>content-length</code>, it works normally.

blocks|key|1693175|text|我的案例是由于SSL证书过期|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1693176|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

My case was due to SSL certificate expiration

blocks|key|1693332|text|这个问题在我看来是非常开放的。我将确切地分享我试图实现的目标以及我是如何解决这个问题的|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1693333|上下文|1693334|在端口8999和8990上运行的Java应用程序。App在亚马逊EC2+Ubuntu20服务器上作为docker-compose堆栈运行。|1693335|我添加了一个网络负载均衡器，它必须在AWS+ACM证书下的TLS端口443上接收流量。转发机制必须如下所示|1693336|来自NLB的|1693337|端口tls443+-->+EC2实例中的TCP端口8990+|ordered-list-item|1693338|1693339|端口TCP+22+-->+EC2实例|1693340|中的TCP端口8999|1693341|我收到来自curl命令行界面的错误|offset|length|style|CODE|1693342|解决方案|1693343|我意识到有一个私有的AWS+VPC来处理流量。亚马逊网络服务EC2实例在私有子网中运行。亚马逊网络服务EC2实例具有阻止流量的安全组规则。解决方案是在端口8990和8999上向EC2实例开放所有流量0.0.0.0/0|1693344|在AWS负载均衡器中，我看到我的目标组进行了健康检查，在一些客户端重新启动并清除DNS缓存后，我能够通过HTTPS访问应用程序。|1693345|entityMap^0|0|0|0|0|0|0|0|0|0|5|4|0|0|25|4|2A|4|2R|9|0|0^^$0|@$1|2|3|4|5|6|7|15|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|16|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|17|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|18|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|19|8|@]|9|@]|A|$]]|$1|J|3|K|5|L|7|1A|8|@]|9|@]|A|$]]|$1|M|3|I|5|6|7|1B|8|@]|9|@]|A|$]]|$1|N|3|O|5|L|7|1C|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|1D|8|@]|9|@]|A|$]]|$1|R|3|S|5|6|7|1E|8|@$T|1F|U|1G|V|W]]|9|@]|A|$]]|$1|X|3|Y|5|6|7|1H|8|@]|9|@]|A|$]]|$1|Z|3|10|5|6|7|1I|8|@$T|1J|U|1K|V|W]|$T|1L|U|1M|V|W]|$T|1N|U|1O|V|W]]|9|@]|A|$]]|$1|11|3|12|5|6|7|1P|8|@]|9|@]|A|$]]|$1|13|3|-4|5|6|7|1Q|8|@]|9|@]|A|$]]]|14|$]]

The question is very open in my opinion. I will share exactly what I was trying to achieve and how I resolved the problem
<h2>Context</h2>
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
<ol>
<li>port TLS 443 from NLB --&gt; TCP port 8990 in the EC2 instance</li>
<li>port TCP 22 from NLB --&gt; TCP port 8999 in the EC2 instance</li>
</ol>
I was getting the error from the <code>curl</code> CLI
<h2>Solution</h2>
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 <code>0.0.0.0/0</code> to the EC2 instance on ports <code>8990</code> and <code>8999</code>
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.

blocks|key|1693415|text|要将@TechWisdom的comment转换为答案:使用Docker+%2B+Uvicorn+(FastAPI)，您需要使用Uvicorn命令行选项--host+0.0.0.0+(默认值为127.0.0.1)绑定到Docker主机。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1693416|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/users/3140273/techwisdom|1|https://stackoverflow.com/questions/1924434/what-is-the-curl-error-52-empty-reply-from-server/70783337#comment108881056_1924434^0|21|E|2|B|0|E|7|1|0^^$0|@$1|2|3|4|5|6|7|P|8|@$9|Q|A|R|B|C]]|D|@$9|S|A|T|1|U]|$9|V|A|W|1|X]]|E|$]]|$1|F|3|-4|5|6|7|Y|8|@]|D|@]|E|$]]]|G|$H|$5|I|J|K|E|$L|M]]|N|$5|I|J|K|E|$L|O]]]]

To turn <a href="https://stackoverflow.com/users/3140273/techwisdom">@TechWisdom</a>'s <a href="https://stackoverflow.com/questions/1924434/what-is-the-curl-error-52-empty-reply-from-server/70783337#comment108881056_1924434">comment</a> into an answer: with Docker + Uvicorn (FastAPI) you need to bind to the Docker host with the Uvicorn command line option <code>--host 0.0.0.0</code> (The default is 127.0.0.1).

blocks|key|3804111|text|在向使用gunicorn进行并发的flask应用程序发出请求时，我遇到了这个问题。原因是我设置了一个timeout，它比服务器处理和响应单个请求所需的时间短。下面的bash脚本展示了如何在gunicorn中设置timeout。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|3804112|#!/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|code-block|syntax|javascript|3804113|根据Gunicorn+%7C+timeout的说法|3804114|静默超过此秒数的|3804115|工作进程将被杀死并重新启动。值为正数或0。将其设置为0会完全禁用所有工作进程的超时，从而产生无限超时的效果。通常，30秒的默认值应该足够了。仅当您确定对同步工作者的影响时，才将此值设置得明显更高。对于非同步工作进程，这仅仅意味着工作进程仍在通信，并且与处理单请求所需的时间长度无关。|blockquote|BOLD|3804116|3804117|entityMap|0|LINK|mutability|MUTABLE|url|https://docs.gunicorn.org/en/stable/settings.html#timeout^0|4|8|H|5|1E|7|2M|8|2X|7|0|0|2|I|0|0|0|3K|3|0|0^^$0|@$1|2|3|4|5|6|7|11|8|@$9|12|A|13|B|C]|$9|14|A|15|B|C]|$9|16|A|17|B|C]|$9|18|A|19|B|C]|$9|1A|A|1B|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|1C|8|@]|D|@]|E|$I|J]]|$1|K|3|L|5|6|7|1D|8|@]|D|@$9|1E|A|1F|1|1G]]|E|$]]|$1|M|3|N|5|6|7|1H|8|@]|D|@]|E|$]]|$1|O|3|P|5|Q|7|1I|8|@$9|1J|A|1K|B|R]]|D|@]|E|$]]|$1|S|3|-4|5|6|7|1L|8|@]|D|@]|E|$]]|$1|T|3|-4|5|6|7|1M|8|@]|D|@]|E|$]]]|U|$V|$5|W|X|Y|E|$Z|10]]]]

I faced this while making a request to my <code>flask</code> application which was using <code>gunicorn</code> for concurrency. The reason was that I set a <code>timeout</code> 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 <code>timeout</code> in <code>gunicorn</code>.
<pre><code>#!/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
</code></pre>
According to <a href="https://docs.gunicorn.org/en/stable/settings.html#timeout" rel="nofollow noreferrer">Gunicorn | timeout</a>:
<blockquote>
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.
</blockquote>

blocks|key|5219914|text|在我的例子中，我使用uwsgi，添加了超过60秒的属性http-timeout，但由于一些额外的空间和配置文件没有正确加载，它无法工作。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|5219915|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

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.

blocks|key|3804063|text|在我的例子中，反向代理Nginx在路上，服务器直接发送500代码，通过NGINX+curl：(52)服务器的空回复|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3804064|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

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

blocks|key|1469466|text|当你试图访问像Https这样的安全网站时，就会发生这种情况。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1469467|我希望你错过了“%25s”|1469468|尝试将URL改为curl+-sS+-u+"username:password“https://www.example.com/backup.php|offset|length|1469469|entityMap|0|LINK|mutability|MUTABLE|url|https://www.example.com/backup.php^0|0|0|13|Y|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@$F|S|G|T|1|U]]|A|$]]|$1|H|3|-4|5|6|7|V|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|O]]]]

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" <a href="https://www.example.com/backup.php" rel="nofollow">https://www.example.com/backup.php</a>

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
<pre><code>curl -sS http://www.example.com/backup.php
</code></pre>
Lately I've been getting this error when the Cron runs:
<pre><code>curl: (52) Empty reply from server
</code></pre>
If I go to the link directly in my browser the script runs fine and I get my little backup ZIP file.

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

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋 

腾讯云代码助手

CODING DevOps

Cloud Studio

SDK中心

API中心

命令行工具

我在一台服务器上设置了一个cron作业，以便在另一台服务器上用PHP运行备份脚本。我一直使用的命令是curl -sS http://www.example.com/backup.php最近，当Cron运行时，我得到了这个错误：curl: (52) Empty reply from server如果我直接在浏览器中转到这个链接，脚本运行得很好，并且我得到了我的小备份ZIP文件。

问curl错误52“来自服务器的空回复”是什么？
EN

回答 20

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问curl错误52“来自服务器的空回复”是什么？EN

回答 20

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问curl错误52“来自服务器的空回复”是什么？
EN