---
type: "blog"
id: 33
url: "https://prestadev.pl/it/blog/news/errore-500-522-prestashop-preparazione-della-diagnosi"
markdown_url: "https://prestadev.pl/it/markdown/blog/33.md"
title: "Errore 500 o 522 in PrestaShop: quali dati preparare per la diagnosi?"
description: "Annota l’indirizzo, l’orario, il messaggio e l’ambito del guasto di PrestaShop. Verifica cosa distingue il 500 dal 522 e scarica il modello di segnalazione per la diagnosi."
language: "it"
published: "2026-09-26 20:07:36"
updated: "2026-09-26 20:07:36"
author: "Patryk Marek"
category: "News"
---

# Errore 500 o 522 in PrestaShop: quali dati preparare per la diagnosi?

Indirizzo, ora, messaggio e portata del problema aiutano a collegare la segnalazione ai log. Scarica il modulo di descrizione del guasto e scopri cosa non dimostra il solo codice 500 o 522.

Annota l’indirizzo esatto, l’ora con il fuso orario e l’azione dopo la quale è comparso l’errore. Queste tre informazioni permettono di cercare lo stesso evento nei log. Il solo numero 500 o 522 non indica ancora il modulo da modificare.

 Questa guida aiuta a preparare una segnalazione per la diagnosi. Non descrive la riparazione di un negozio specifico né presenta cause di esempio come risultato accertato.

 ## Cosa annotare durante il guasto?

 1. **Indirizzo e azione:** ad es. apertura del prodotto, salvataggio di un’impostazione nel pannello oppure passaggio dal carrello alla consegna. Non annotare in una segnalazione pubblica i token presenti nell’indirizzo del pannello.
2. **Ora:** data, ora e fuso, ad es. `2026-09-26 14:32 Europe/Warsaw`. Se il problema si ripresenta, annota due o tre occorrenze concrete.
3. **Risposta:** codice HTTP, messaggio visibile e identificatore della richiesta, se la pagina di errore lo fornisce. Completa lo screenshot con il testo del messaggio.
4. **Ambito:** un solo indirizzo o l’intero negozio, frontend o pannello, utente autenticato o ospite, una rete o anche un’altra.
5. **Ultima modifica:** aggiornamento, installazione di un modulo, importazione, modifica di un’impostazione dell’hosting. Indica la data; il solo ordine degli eventi non dimostra la causa.

 ## Errore 500 ed errore 522 richiedono punti di partenza diversi

 | Risposta | Da dove iniziare | Cosa non si sa ancora |
| --- | --- | --- |
| HTTP 500 | Confronta l’ora e il percorso con il log dell’applicazione e del server che gestisce la richiesta. | Il codice non identifica da solo il modulo, la query o l’impostazione PHP. Guasti diversi possono restituire lo stesso stato. |
| Cloudflare 522 | Verifica la connessione tra Cloudflare e il server di origine. Annota il Ray ID, se è visibile, e comunica l’orario all’hosting. | Il solo codice non conferma un errore di PrestaShop. L’origine può essere, tra l’altro, l’indisponibilità o il sovraccarico del server oppure il blocco delle connessioni. |
| Pagina vuota senza stato registrato | Verifica la risposta del documento principale negli strumenti del browser; conserva l’indirizzo e l’ora. | Non è ancora chiaro se il problema riguardi la risposta del server, uno script nel browser o una risorsa necessaria per visualizzare la pagina. |

 Descrizione del 522 e raccomandazioni per la connessione con il server di origine: [documentazione Cloudflare](https://developers.cloudflare.com/support/troubleshooting/http-status-codes/cloudflare-5xx-errors/error-522/). Significato generale dello stato 500: [HTTP Semantics, RFC 9110](https://www.rfc-editor.org/rfc/rfc9110.html#name-500-internal-server-error).

 ## Come preparare una semplice prova di riproduzione?

 Esempio dimostrativo di segnalazione: “Alle 14:32 apro la scheda prodotto come ospite. Il documento ha stato 500. La home page nello stesso browser funziona. Alle 14:35 lo stesso prodotto funziona da un’altra rete”. Una nota di questo tipo non diagnostica la causa, ma indica richieste concrete da confrontare.

 A ogni ripetizione cambia una sola condizione e annota il risultato. Se contemporaneamente svuoti la cache, cambi PHP e disattivi diversi moduli, sarà difficile stabilire quale modifica abbia influito sul comportamento del negozio.

 ## Quali log trasmettere alla persona che effettua la diagnosi?

 Chiedi di verificare un breve intervallo di tempo attorno all’evento: il log dell’applicazione, gli errori PHP e del server WWW e, in presenza di un livello intermedio, anche i suoi eventi. La posizione di salvataggio dei log dipende dalla versione del negozio e dalla configurazione dell’hosting. Invece di presumere un percorso, fornisci all’amministratore l’ora esatta, l’indirizzo e il metodo della richiesta, se lo conosci.

 I frammenti di log possono contenere indirizzi e-mail, identificatori di sessione e dati degli ordini. Trasmetti l’estratto necessario tramite un canale concordato e rimuovi i segreti. Anche un file HAR completo può contenere tali informazioni; non pubblicarlo come semplice allegato su un forum.

 ## Come confrontare i livelli senza modificare la protezione dell’intero negozio?

 Il confronto delle risposte tramite CDN e direttamente dal server dovrebbe essere preparato da un amministratore che conosca la configurazione del dominio, del TLS e dell’accesso all’origin. La differenza tra le risposte è un’indicazione per ulteriori test, non una prova automatica della responsabilità del WAF o di PrestaShop.

 Usa la modalità di debug su una copia di lavoro o in un accesso controllato. La disattivazione globale della protezione oppure la visualizzazione di eccezioni dettagliate a tutti i visitatori non è necessaria per redigere una segnalazione utile.

 ## Modello di segnalazione pronto da scaricare

 [Scarica il modulo di descrizione del guasto — TXT](https://prestadev.pl/themes/warehouse/assets/img/pdseo-20260926-awaria-zgloszenie.txt). Compila i campi e contrassegna l’informazione mancante con “non verificato”. Il modulo non richiede password né chiavi API.

 ## Cosa verificare dopo la correzione?

 Ripeti i passaggi annotati nelle stesse condizioni, verifica il risultato dell’operazione e le nuove voci nei log. In caso di problema sporadico, una sola apertura corretta della pagina conferma solo quel tentativo. Concorda con l’esecutore il periodo di osservazione, l’ambito dei test e il segnale per una nuova segnalazione.

 Se il problema è comparso durante un cambio di versione, utilizza anche la [lista di preparazione all’aggiornamento di PrestaShop](https://prestadev.pl/pl/blog/baza-wiedzy/aktualizacja-prestashop-przygotowanie-do-wyceny). Una guida separata spiega [il ruolo delle intestazioni di sicurezza HTTP](https://prestadev.pl/pl/blog/baza-wiedzy/naglowki-bezpieczenstwa-http-w-sklepie-prestashop-co-daja-i-dlaczego-warto-je-wdrozyc).

 ## Hai bisogno di aiuto per la diagnosi?

Invia la descrizione del guasto con l’ora di comparsa e i passaggi di riproduzione nell’ambito dell’[assistenza tecnica PrestaShop](https://prestadev.pl/pl/content/11-naprawa-pomoc-techniczna-prestashop). L’ambito concreto e la modalità di accesso possono essere definiti sulla base della segnalazione.
