In breve: WordPress cURL error 61 — indica che libcurl rifiuta la risposta perché la codifica dichiarata negli header di trasferimento o contenuto non è riconosciuta oppure non coincide con i dati effettivamente ricevuti.
Indice dei contenuti
WordPress cURL error 61: significato
Le prime ipotesi da verificare per “WordPress cURL error 61” sono server remoto che dichiara una codifica non supportata dalla build libcurl disponibile; CDN o reverse proxy che modifica Content-Encoding senza trasformare correttamente il corpo.
Sintomi e cause probabili
Sintomi da verificare
- Il messaggio “WordPress cURL error 61” compare durante un’operazione ripetibile.
- La funzione coinvolta in WordPress REST API non raggiunge il risultato previsto.
- Il log dell’area WordPress REST API registra un evento nello stesso minuto della prova.
- Il comportamento osservato in WordPress REST API cambia in base a utente, rete, file o configurazione.
Cause probabili
- Server remoto che dichiara una codifica non supportata dalla build libcurl disponibile
- CDN o reverse proxy che modifica Content-Encoding senza trasformare correttamente il corpo
- Compressione applicata due volte tra applicazione, web server e proxy
- Risposta compressa troncata o corrotta durante il trasferimento
Diagnosi passo per passo
- Registrare header e corpo della risposta fallita senza esporre token o dati personali
- Confrontare la richiesta passando dalla CDN e raggiungendo direttamente l’origin quando autorizzato
- Verificare Accept-Encoding Content-Encoding e Transfer-Encoding su ogni livello
- Controllare versione e caratteristiche della libreria cURL caricata da PHP
- Ripetere il test disabilitando una sola funzione di compressione in staging e confrontare il risultato
Log e dati da controllare
- DevTools o risposta REST completa
- WordPress debug.log ed error_log
- log WAF, proxy e server web
Correzioni sicure
- Servire una codifica supportata e dichiararla correttamente negli header
- Allineare CDN reverse proxy e origin affinché un solo livello gestisca la compressione
- Rimuovere header Content-Encoding aggiunti manualmente quando non corrispondono al corpo
- Correggere la risposta troncata o corrotta prima di riattivare la cache
- Aggiornare PHP o libcurl tramite il percorso supportato dal server quando manca una funzione realmente necessaria
Verifica finale
- L’endpoint restituisce JSON valido
- Il codice HTTP corrisponde all’esito
- Autorizzazione e nonce arrivano correttamente
- Site Health non segnala lo stesso errore
Errori da evitare
- Non disattivare globalmente WAF, ModSecurity, antispam o verifica TLS per aggirare il sintomo
- Non impostare permessi 777 e non cambiare proprietari in modo ricorsivo senza conoscere la struttura dell’account
- Non cancellare database, chiavi Redis, cache o file di sistema senza backup e senza aver identificato l’oggetto coinvolto
- Non ripetere pagamenti, import o webhook reali finché non hai verificato l’idempotenza
Guide Xlogic correlate
- WordPress cURL error 52: Empty reply from server
- WordPress cURL error 18: transfer closed with outstanding data
- WordPress cURL error 92: HTTP/2 stream error
Fonti tecniche
Domande frequenti
Che cosa significa “WordPress cURL error 61”?
WordPress cURL error 61 — indica che libcurl rifiuta la risposta perché la codifica dichiarata negli header di trasferimento o contenuto non è riconosciuta oppure non coincide con i dati effettivamente ricevuti.
Da cosa può dipendere “WordPress cURL error 61”?
Le cause da verificare per “WordPress cURL error 61” sono: server remoto che dichiara una codifica non supportata dalla build libcurl disponibile; CDN o reverse proxy che modifica Content-Encoding senza trasformare correttamente il corpo; compressione applicata due volte tra applicazione, web server e proxy.
Quali controlli eseguire per “WordPress cURL error 61”?
Per diagnosticare “WordPress cURL error 61”, controlla nell’ordine: registrare header e corpo della risposta fallita senza esporre token o dati personali; confrontare la richiesta passando dalla CDN e raggiungendo direttamente l’origin quando autorizzato; verificare Accept-Encoding Content-Encoding e Transfer-Encoding su ogni livello. La soluzione è confermata quando L’endpoint restituisce JSON valido; il codice HTTP corrisponde all’esito.