Curl Error 52 Respuesta vacía del servidor

Tengo una configuración de trabajo cron en un servidor para ejecutar un script de respaldo en PHP que está alojado en otro servidor. El comando que he estado usando tiene el siguiente formato:

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

Últimamente he recibido este error cuando se ejecuta Cron

curl: (52) Empty reply from server

No tengo idea de lo que esto significa. Si voy al enlace directamente en mi navegador, el script se ejecuta bien y obtengo mi pequeño archivo zip de respaldo.

¿Alguien puede proporcionar alguna información al respecto?

Esto puede suceder si se le pide a curl que utilice HTTP simple en un servidor que utiliza HTTPS.

Ejemplo:

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

Curl da este error cuando no hay respuesta de un servidor, ya que es un error que HTTP no responda nada a una solicitud.

Sospecho que el problema que tiene es que hay una pieza de infraestructura de red, como un firewall o un proxy, entre usted y el host en cuestión. Conseguir que esto funcione, por lo tanto, requerirá que discuta el problema con las personas responsables de ese hardware.

En mi caso fue la redirección del servidor; curl -Lresolvió mi problema.

Puede suceder cuando el servidor no responde debido al 100% de la CPU o al uso de la memoria.

Recibí este error cuando intentaba acceder a la API de sonarqube y el servidor no respondía debido a la utilización total de la memoria.

Otra razón común para una respuesta vacía es el tiempo de espera. Verifique todos los saltos desde donde se ejecuta el trabajo cron hasta su servidor PHP / destino. Probablemente haya un dispositivo / servidor / nginx / LB / proxy en algún lugar de la línea que finaliza la solicitud antes de lo esperado, lo que da como resultado una respuesta vacía.

En el caso de las conexiones SSL, esto puede deberse a un problema en las versiones anteriores del servidor nginx que segregan durante las solicitudes de curl y Safari. Este error se solucionó en la versión 1.10 de nginx, pero todavía hay muchas versiones antiguas de nginx en Internet.

Para los administradores de nginx: agregar ssl_session_cache shared:SSL:1m;al httpbloque debería resolver el problema.

Soy consciente de que OP estaba solicitando un caso que no sea SSL, pero como esta es la página superior en goole para el problema de "respuesta vacía del servidor", dejo la respuesta SSL aquí, ya que era uno de los muchos que me golpeaban la cabeza. contra la pared con este problema.

En mi caso, esto fue causado por un problema de PHP APC. El primer lugar para buscar serían los registros de errores de Apache (si está utilizando Apache).

Espero que esto ayude a alguien.

este error también puede ocurrir si el servidor está procesando los datos. Por lo general, me sucede cuando publico algunos archivos en los sitios web de la API REST que tienen muchas entradas y tardan mucho en crearse y devolverse los registros.

puede probar este curl -sS " http://www.example.com/backup.php " poniendo su URL en "" que funcionó para mí, no sé la razón exacta, pero supongo que poniendo la URL en " "completa la solicitud al servidor o simplemente completa la solicitud de encabezado.

He tenido este problema antes. Descubrí que tenía otra aplicación usando el mismo puerto (3000).

Manera fácil de averiguar esto:

En la terminal, escriba netstat -a -p TCP -n | grep 3000(sustituya el puerto que está usando por el '3000'). Si hay más de uno escuchando, algo más ya está ocupando ese puerto. Debe detener ese proceso o cambiar el puerto para su nuevo proceso.

En mi caso (curl 7.47.0), se debe a que configuré el encabezado content-lengthen el comando curl manualmente con un valor que calcula el cartero (usé cartero para generar los parámetros del comando curl y copiarlos al shell). Después de eliminar el encabezado content-length, funciona normalmente.

Pruebe esto -> En lugar de pasar por cURL, intente hacer ping al sitio al que está tratando de llegar con Telnet. La respuesta que devuelve su intento de conexión será exactamente lo que ve cURL cuando intenta conectarse (pero que lo ofusca inútilmente). Ahora, dependiendo de lo que vea aquí, puede sacar una de varias conclusiones:

Está intentando conectarse a un sitio web que es un host virtual basado en nombre, lo que significa que no se puede acceder a él a través de la dirección IP. Algo salió mal con el nombre de host; es posible que haya escrito algo mal. Tenga en cuenta que usar GET en lugar de POST para los parámetros le dará una respuesta más concreta.

El problema también puede estar relacionado con el encabezado 100-continue. Intente ejecutar curl_getinfo($ch, CURLINFO_HTTP_CODE)y verifique el resultado.

Mi caso se debió a la caducidad del certificado SSL

En mi caso, estaba usando uwsgi, agregué la propiedad http-timeout durante más de 60 segundos, pero no funcionaba debido a un espacio adicional y el archivo de configuración no se cargaba correctamente.

Ocurre cuando intenta acceder a un sitio web seguro como Https.

Espero que te hayas perdido

Intente cambiar la URL a curl -sS -u "nombre de usuario: contraseña" https://www.example.com/backup.php