Eu tenho uma configuração de cron job em um servidor para executar um script de backup em PHP que está hospedado em outro servidor.
O comando que estou usando é
curl -sS http://www.example.com/backup.php
Ultimamente tenho recebido este erro quando o Cron é executado:
curl: (52) Empty reply from server
Se eu acessar o link diretamente em meu navegador, o script será executado bem e recebo meu pequeno arquivo ZIP de backup.
curltempo limite seja esgotado? Você já tentou aumentar as esperas de onda padrão para conectar --connect-timeout <seconds>e para toda a operação executar --max-time <seconds>?
Respostas:
Isso pode acontecer se curl for solicitado a fazer HTTP simples em um servidor que faz HTTPS.
Exemplo:
$ curl http://google.com:443
curl: (52) Empty reply from server
curl localhost:8443me deu o erro de resposta vazia. curl -k https://localhost:8443veiculou a página corretamente.
O Curl dá esse erro quando não há resposta de um servidor, pois é um erro do HTTP não responder nada a uma solicitação.
Suspeito que o problema que você tem é que existe alguma peça de infraestrutura de rede, como um firewall ou um proxy, entre você e o host em questão. Para que isso funcione, portanto, você precisará discutir o problema com as pessoas responsáveis por esse hardware.
No meu caso, foi o redirecionamento do servidor; curl -Lresolveu meu problema.
Isso pode acontecer quando o servidor não responde devido a 100% de utilização da CPU ou da memória.
Recebi este erro quando estava tentando acessar a API do sonarqube e o servidor não estava respondendo devido à utilização total da memória
Outro motivo comum para uma resposta vazia é o tempo limite. Verifique todos os saltos de onde o cron job está sendo executado para seu servidor PHP / de destino. Provavelmente existe um dispositivo / servidor / nginx / LB / proxy em algum lugar ao longo da linha que encerra a solicitação antes do esperado, resultando em uma resposta vazia.
No caso de conexões SSL, isso pode ser causado por problemas em versões mais antigas do servidor nginx que apresentam falha em segfault durante solicitações curl e Safari. Este bug foi corrigido na versão 1.10 do nginx, mas ainda existem muitas versões antigas do nginx na internet.
Para administradores nginx: adicionar ssl_session_cache shared:SSL:1m;ao httpbloco deve resolver o problema.
Estou ciente de que OP estava pedindo um caso não SSL, mas como esta é a página inicial do goole para o problema de "resposta vazia do servidor", estou deixando a resposta SSL aqui, pois fui um dos muitos que estava batendo a cabeça contra a parede com este problema.
No meu caso, isso foi causado por um problema de PHP APC. O primeiro lugar a ser examinado são os logs de erros do Apache (se você estiver usando o Apache).
Espero que isso ajude alguém.
esse erro também pode ocorrer se o servidor estiver processando os dados. Geralmente acontece comigo quando posto alguns arquivos em sites da API REST que têm muitas entradas e demoram muito para a criação e o retorno dos registros
você pode tentar este curl -sS " http://www.example.com/backup.php " colocando seu URL em "" que funcionou para mim. Não sei o motivo exato, mas suponho que colocar o url em " "conclui a solicitação ao servidor ou apenas conclui a solicitação de cabeçalho.
Eu já tive esse problema antes. Descobri que tinha outro aplicativo usando a mesma porta (3000).
Maneira fácil de descobrir isso:
No terminal, digite netstat -a -p TCP -n | grep 3000(substitua a porta que você está usando por '3000'). Se houver mais de um ouvindo, algo mais já está ocupando essa porta. Você deve interromper esse processo ou alterar a porta para seu novo processo.
No meu caso (curl 7.47.0), é porque eu configurei o cabeçalho content-lengthno comando curl manualmente com um valor que é calculado pelo postman (usei o postman para gerar parâmetros do comando curl e copiá-los para o shell). Depois de excluir o cabeçalho content-length, ele funciona normalmente.
Tente isto -> Em vez de usar o cURL, tente fazer o ping do site que está tentando acessar com o Telnet. A resposta que sua tentativa de conexão retorna será exatamente o que cURL vê quando ele tenta se conectar (mas que inutilmente ofusca de você). Agora, dependendo do que você vê aqui, você pode tirar uma das várias conclusões:
Você está tentando se conectar a um site que é um host virtual baseado em nome, o que significa que não pode ser alcançado por meio do endereço IP. Algo deu errado com o nome do host - você pode ter digitado algo errado. Observe que o uso de GET em vez de POST para parâmetros fornecerá uma resposta mais concreta.
O problema também pode estar relacionado ao cabeçalho de 100 continuações. Experimente correr curl_getinfo($ch, CURLINFO_HTTP_CODE)e verifique o resultado.
telnet hostnameeGET <url>
Eu encontrei esse erro esporadicamente e não conseguia entender. Googling não ajudou.
Eu finalmente descobri. Eu administro alguns contêineres docker, entre eles NGINXe Apache. O comando em questão endereça um contêiner específico, em execução Apache. Acontece que também tenho crontrabalho para fazer trabalho pesado, às vezes, no mesmo contêiner. Dependendo da carga que este crontrabalho coloca neste contêiner, ele não foi capaz de responder ao meu comando em tempo hábil, resultando em error 52 empty reply from serverou mesmo 502 Bad Gateway.
Eu descobri e verifiquei isso claramente curlquando percebi que o processo que investiguei levou menos de 2 segundos e de repente eu obtive um erro 52 e depois um erro 502 e novamente menos de 2 segundos - então definitivamente não era meu código que não foi alterado. Usando ps auxdentro do contêiner, vi o outro processo em execução e entendi.
Na verdade, eu estava incomodado 502 Bad Gatewaypela partir NGINXde trabalhos de execução longa e não pode corrigi-lo com os parâmetros apropriados, então eu finalmente desistiu e mudou essas coisas Apache. É por isso que fiquei ainda mais confuso com esses erros.
O remédio é simples. Eu apenas acionei mais algumas instâncias deste contêiner docker service scalee foi isso. dockerbalanços de carga por conta própria.
No meu caso, eu estava usando uwsgi, adicionei a propriedade http-timeout por mais de 60 segundos, mas ela não estava funcionando por causa de algum espaço extra e o arquivo de configuração não estava sendo carregado corretamente.
Acontece quando você está tentando acessar um site seguro como o Https.
Eu espero que você tenha perdido 's'
Tente alterar o URL para curl -sS -u "nome de usuário: senha" https://www.example.com/backup.php