Se il tuo sito web improvvisamente non è più raggiungibile, le cause possono essere molto diverse. Ad esempio, sono possibili problemi di DNS, un'associazione errata del dominio, problemi SSL, errori PHP, un malfunzionamento .htaccess, problemi di WordPress o limiti di risorse raggiunti.
È fondamentale quindi non modificare immediatamente gli atteggiamenti, ma stabilire prima, a quale livello tecnico si verifica l'errore.
Questa guida ti accompagna passo dopo passo attraverso le verifiche più importanti nel web hosting CURIAWEB e ti aiuta a circoscrivere la causa.
Importante: „Sito web non raggiungibile“ è inizialmente solo il sintomo visibile. Prendi nota del messaggio di errore esatto prima di apportare modifiche a DNS, PHP, WordPress o al tuo hosting.
Cosa significa esattamente „Sito web non raggiungibile“? #
Per i visitatori molti problemi tecnici sembrano simili: il sito web desiderato non viene visualizzato.
Tuttavia, dal punto di vista tecnico, dietro a ciò possono celarsi errori completamente diversi:
Il dominio non viene risolto
↓
Problema DNS
Il dominio punta al server errato
↓
Problema di DNS/configurazione
La connessione HTTPS non riesce
↓
Problema SSL/di certificato
403 Forbidden
↓
Accesso negato
404 Not Found
↓
Risorsa non trovata
500 Internal Server Error
↓
Elaborazione lato server non riuscita
503 Service Unavailable
↓
Servizio momentaneamente non disponibile
508 Resource Limit Is Reached
↓
Limite di risorse CloudLinux raggiuntoEcco perché non iniziamo la diagnosi con una riparazione, ma con una classificazione.
1. Prendere nota del messaggio di errore esatto #
Visita il sito web e annota esattamente ciò che viene mostrato.
Esempi:
Server non trovato
DNS_PROBE_FINISHED_NXDOMAIN
ERR_NAME_NOT_RESOLVED
ERR_CONNECTION_TIMED_OUT
ERR_CONNECTION_REFUSED
ERR_TOO_MANY_REDIRECTS
403 Accesso negato
404 Non trovato
500 Errore interno del server
503 Servizio non disponibile
508 Limite risorse raggiuntoNon dovresti nemmeno risemplicemente riassumere un avviso di certificato come „sito web offline“.
Più precisa è la segnalazione, più velocemente si può circoscrivere la causa.
2. Prendere nota dell'URL interessato #
Annota anche l'URL completo.
Per esempio:
o:
o:
Questo è importante perché è il dominio principale, www-l'hostname e i sottodomini possano utilizzare record DNS o configurazioni differenti.
3. Verificare se l'intero sito web è interessato #
Testa diverse aree del sito web.
Per esempio:
https://example.ch/
https://example.ch/kontakt/
https://example.ch/wp-admin/Verifica:
- Non è raggiungibile nessun URL?
- Funziona la pagina iniziale, ma una pagina secondaria no?
- Funziona il frontend, ma l'area amministrativa no?
- È interessata solo una sottodominio?
- È interessata solo una determinata funzione?
Se fallisce una sola pagina, un guasto completo dell'hosting è molto meno probabile.
4. Verifica se sei l'unico a essere interessato #
Testa il sito web in una finestra di navigazione in incognito e, se possibile, anche tramite un'altra connessione a Internet.
Un semplice confronto può apparire ad esempio così:
WLAN → Sito web non raggiungibile
Cellulare → Il sito web funzionaAllora dovresti considerare che il problema potrebbe riguardare solo la tua connessione, il tuo resolver DNS o il tuo indirizzo IP pubblico.
Consiglio pratico: Un test sulla rete mobile è particolarmente utile perché di solito consente di utilizzare una connessione a Internet e un indirizzo IP pubblico differenti.
5. Verificare se cPanel è raggiungibile #
Se il tuo sito web non funziona, ma cPanel è ancora accessibile, puoi iniziare immediatamente la diagnosi da lì.
Un accesso a cPanel funzionante non dimostra che il sito web sia configurato correttamente, ma mostra che il tuo account di hosting è fondamentalmente raggiungibile.
Questo aiuta a restringere il campo.
6. Verificare il dominio e il DNS come primo livello tecnico #
Prima che si possa accedere a un sito web, è necessario risolvere il nome di dominio.
In sintesi:
example.ch
↓
DNS
↓
Indirizzo IP
↓
Server web
↓
Sito webSe la risoluzione DNS fallisce già, la richiesta non raggiunge nemmeno il sito web.
Tipici indizi di un problema DNS #
Messaggi come:
DNS_PROBE_FINISHED_NXDOMAIN
ERR_NAME_NOT_RESOLVED
Server non trovatoindicano più la risoluzione dei nomi che PHP o WordPress.
In questo caso non dovresti disattivare prima i plugin o modificare le impostazioni PHP.
Prendere in considerazione le modifiche DNS recenti #
Se subito prima del problema sono stati modificati i record DNS o i nameserver, questa correlazione temporale è particolarmente importante.
Le modifiche ai DNS potrebbero non essere visibili ovunque contemporaneamente a causa dei cache.
Verifica quindi:
- Sono stati modificati i nameserver?
- È stato modificato un record A o AAAA?
- È stato modificato un CNAME?
- Il dominio è stato trasferito di recente su un altro hosting?
- È stata configurata una nuova sottodominio?
Spiegheremo come controllare i record DNS all'interno di cPanel su Utilizzare l'editor di zone DNS in cPanel.
8. Verificare se cPanel è effettivamente responsabile del DNS #
La zona DNS nel tuo cPanel è rilevante solo se il dominio utilizza effettivamente i relativi Nameserver autoritativi o questa infrastruttura DNS.
Se la gestione del DNS viene effettuata presso un provider esterno, devi apportare le modifiche lì.
Importante: Una modifica nell'editor di zona di cPanel non ha alcun effetto sulla risoluzione DNS pubblica se per il dominio è autorevole un'altra infrastruttura DNS.
9. Controllare l'associazione del dominio in cPanel #
Se il dominio punta correttamente al server di hosting, deve anche essere configurato correttamente all'interno dell'account di hosting.
Apri:
Domini → Domini
Verifica se il dominio interessato esiste e quale Document Root viene utilizzato.
Puoi trovare la guida completa su Aggiungere e gestire un dominio in cPanel.
10. Verifica della Document Root #
La document root stabilisce da quale directory il server web rende disponibile il sito web per un dominio.
Esempio:
Dominio:
example.ch
Document Root:
/public_html/example/Se il sito web effettivo si trova in un'altra directory, il dominio potrebbe restituire contenuti errati o nessun contenuto.
Verifica quindi se la Document Root configurata contiene effettivamente i file del sito web.
11. Controllare il file di avvio #
Apri:
File → Gestione file
Passa alla document root del dominio interessato.
Verifica se è presente un file di avvio adatto, ad esempio:
index.php
index.htmlSe i file del sito web mancano o si trovano in una sottodirectory errata, il server web non può pubblicare correttamente il sito web previsto.
Spiegheremo il funzionamento all'indirizzo Utilizzare il File Manager di cPanel.
12. Verificare se i file sono stati recentemente spostati o eliminati #
Se il sito web ha smesso di funzionare immediatamente dopo interventi nel file manager, verifica in particolare:
- Sono stati spostati dei file?
- È stata rinominata una directory?
- È stata una
index.phpeliminato? - È stato estratto un archivio nella directory errata?
- È stata
.htaccesscambiato?
Inizia sempre la ricerca guasti dall'ultima modifica effettuata.
13. Verificare HTTPS e SSL separatamente #
Se il dominio è fondamentalmente raggiungibile, ma il browser mostra un avviso di certificato, si tratta di una classe di errore diversa rispetto a un errore 500 o 503.
Tipici avvisi sono, ad esempio:
- Certificato scaduto
- Il certificato non corrisponde al nome host
- Il certificato non viene riconosciuto come attendibile
- Impossibile stabilire correttamente la connessione HTTPS
In questo caso, verifica in modo mirato la configurazione SSL e non PHP, WordPress o CloudLinux per sospetto.
14. Testare www e il dominio senza www separatamente #
Testine:
e
Se funziona solo una variante, dovresti controllare DNS, SSL e reindirizzamenti per il nome host interessato.
Un dominio principale funzionante non dimostra automaticamente che anche www configurato correttamente.
15. Rilevare cicli di reindirizzamento #
Quando il browser mostra un messaggio come:
ERR_TOO_MANY_REDIRECTS
viene visualizzato, la richiesta viene reindirizzata ripetutamente tra gli URL.
In sintesi:
URL A → URL B
↓
URL A
↓
URL B
↓
...In questo caso, controlla i reindirizzamenti in cPanel, il .htaccess e, se necessario, all'interno della tua applicazione web.
Spieghiamo come impostare i reindirizzamenti cPanel su Configurare il reindirizzamento di un dominio in cPanel.
Utilizzare il codice di stato HTTP come guida #
Se il dominio viene risolto e il web server restituisce un messaggio di errore HTTP specifico, dovresti orientare la diagnosi successiva in base al codice di stato.
| Stato | Ulteriore diagnosi |
|---|---|
403 | Diritti di accesso e norme di sicurezza |
404 | URL, file o configurazione di riscrittura/permalink |
500 | Log degli errori, PHP, applicazione e .htaccess |
503 | Servizio, applicazione, processi e risorse |
508 | Limiti delle risorse di CloudLinux |
17. 403 Proibito #
Uno 403 Proibito significa che l'accesso a una risorsa viene negato.
I settori di controllo tipici sono:
- Permessi dei file
.htaccess- Blocchi IP
- ModSecurity
- Funzioni di sicurezza
Usalo per Risolvere l'errore 403 Forbidden.
18. 404 Non Trovato #
Uno 404 Non Trovato significa fondamentalmente che la risorsa richiesta non è stata trovata.
Se la pagina iniziale funziona, ma singole pagine WordPress generano un errore 404, potrebbero essere coinvolte, ad esempio, le regole dei permalink o di rewrite.
Per WordPress trovi la guida adatta sotto Risolvere l'errore 404 di WordPress.
19. 500 Internal Server Error #
Uno Errore interno del server indica un errore nell'elaborazione lato server.
Il codice di stato in sé non indica ancora la causa.
Verifica in particolare:
- Registro degli errori di cPanel
- Errori Fatali di PHP
.htaccess- Versione PHP
- Estensioni PHP
- Plugin e temi
- Limiti PHP
La diagnosi completa si trova su Risolvere l'errore 500 Internal Server Error.
20. 503 Servizio non disponibile #
Uno 503 Servizio non disponibile significa che un servizio al momento non è in grado di elaborare con successo la richiesta.
Molto importanti in caso di errori 503 ricorrenti sono:
- Registro degli errori
- Risorse di CloudLinux
- Processi PHP
- Cronjob
- Attività in background di WordPress e WooCommerce
- Stati di manutenzione
Usalo per Risolvere l'errore 503 Service Unavailable.
21. Limite delle risorse raggiunto #
Se viene espressamente visualizzato un messaggio come:
Limite di risorse 508 raggiunto
viene visualizzato, dovresti esaminare l'utilizzo delle risorse di CloudLinux.
Le istruzioni adatte si trovano su Limite di risorse raggiunto: identificazione e risoluzione dei limiti di CloudLinux.
22. Controllare il registro degli errori di cPanel #
In caso di errori lato server, il log degli errori è uno dei punti di diagnosi più importanti.
Apri:
Valori misurati → Errore
Riproduci l'errore e successivamente confronta il timestamp con gli ultimi inserimenti pertinenti.
La nostra guida dettagliata è disponibile su Leggere il log degli errori di cPanel e trovare gli errori del sito web.
Consiglio pratico: L'ultimo inserimento nel log non deve necessariamente appartenere al tuo problema. Confronta data e ora, URL, percorso del file e messaggio di errore.
Utilizzare le ultime modifiche come ausilio diagnostico #
Se un sito web ha funzionato in precedenza, chiediti:
Cosa è stato modificato immediatamente prima del guasto?
Esempi:
- Aggiornamento di WordPress
- Plugin aggiornato
- Tema modificato
- Versione PHP cambiata
.htaccessmodificato- DNS modificato
- Dominio reindirizzato
- File spostati
- Sito web migrato
- Cronjob configurato
Una stretta correlazione temporale è spesso più preziosa di una lunga lista di cause teoricamente possibili.
24. Controllare .htaccess #
Un difettoso .htaccess può causare diversi problemi, tra cui cicli di reindirizzamento ed errori 403 o 500.
Se il problema è iniziato immediatamente dopo una modifica a questo file, controlla prima di tutto proprio quella modifica.
Ti spieghiamo come procedere in sicurezza su .htaccess spiegato e modificato in sicurezza.
25. Verifica i permessi dei file #
Se i file o le directory non dispongono di autorizzazioni adeguate, il server web potrebbe non essere in grado di accedervi correttamente.
Nei siti Web tipici si possono spesso trovare i seguenti valori:
File: 644
Directory: 755Questi valori tuttavia non dovrebbero essere applicati acriticamente a tutti i contenuti.
Puoi trovare la guida completa su Impostare correttamente i permessi dei file 644 e 755 in cPanel.
Attenzione: Non impostare indiscriminatamente file e directory su
777, solo perché il sito web non funziona. Questa non è una risoluzione pulita dei problemi e può causare rischi per la sicurezza.
26. Controllare la versione di PHP #
Se un sito web basato su PHP non funziona più dopo un cambio di versione di PHP, controlla la versione utilizzata e la compatibilità dell'applicazione.
Su CURIAWEB gestisci la versione di PHP fondamentalmente tramite:
Software → MultiPHP Manager
Le istruzioni si trovano su Modificare la versione di PHP in cPanel.
Non cambiare le versioni di PHP a caso. Controlla prima il log degli errori e i requisiti della tua applicazione.
27. Considerare le estensioni PHP #
Dopo un cambio di versione di PHP o una migrazione, un'applicazione potrebbe richiedere funzionalità che non sono disponibili nell'ambiente PHP utilizzato.
Messaggi di errore tipici sono, ad esempio:
Chiamata a funzione non definita ...
Classe ... non trovata
richiede ext-...Puoi trovare ulteriori informazioni su Attivare e gestire le estensioni PHP in cPanel.
Verifica dei limiti PHP #
Se un errore si verifica solo durante determinate operazioni complesse, i limiti di PHP potrebbero essere rilevanti.
Gli esempi sono:
memory_limit
upload_max_filesize
post_max_size
max_execution_time
max_input_timeSe, ad esempio, il registro degli errori:
Dimensione della memoria consentita esaurita
segnala, questo è un chiaro indizio del limite di memoria di PHP.
Spieghiamo le impostazioni su Imposta limite di memoria PHP, dimensione di caricamento e tempo di esecuzione.
29. Controllo delle risorse CloudLinux #
Se il sito web risulta irraggiungibile solo temporaneamente, dovresti verificare l'utilizzo delle risorse nello stesso momento.
Apri:
Valori misurati → Utilizzo delle risorse
Verifica in particolare la presenza di guasti o di valori anomali.
Spiegheremo come interpretare i dati su Comprendere l'utilizzo delle risorse di CloudLinux in cPanel.
30. Controllare lo spazio di archiviazione #
Un account di hosting completamente pieno può compromettere diverse operazioni di scrittura.
A seconda dell'applicazione, ciò può includere, ad esempio:
- Caricamenti
- Aggiornamenti
- File di cache
- file temporanei
- Registri
- Backup
- Archiviazione delle e-mail
Puoi verificare l'utilizzo dello spazio di archiviazione qui:
File → Utilizzo dello spazio di archiviazione
Puoi trovare ulteriori informazioni su Controllare lo spazio di archiviazione e la larghezza di banda in cPanel.
31. Isolare WordPress come potenziale fonte di errore #
Se altri contenuti o domini funzionano sull'hosting, ma una specifica installazione di WordPress no, dovresti esaminare l'applicazione stessa.
Le aree tipiche sono:
- Plugin
- Temi
- WordPress-Core
.htaccess- Compatibilità PHP
- Database
- codice individuale
32. Errore critico di WordPress #
Se WordPress segnala:
C'è stato un errore critico sul tuo sito web.
si verifica spesso un errore PHP all'interno di WordPress, di un plugin, di un tema o di un codice personalizzato.
Usalo per Risolvere l'errore critico o la pagina bianca di WordPress.
33. Verifica dei plugin e dei temi WordPress #
Se il problema è iniziato immediatamente dopo l'installazione, l'attivazione o l'aggiornamento di un plugin o di un tema, questa correlazione temporale è importante.
Controlla il log degli errori percorsi come:
/wp-content/plugins/...
/wp-content/themes/...Spieghiamo la diagnosi sistematica alla pagina Identificare e risolvere i conflitti tra plugin e temi WordPress.
34. Utilizzare il debug di WordPress #
Se il normale log degli errori non fornisce informazioni sufficienti, una registrazione di debug di WordPress controllata può fornire ulteriori indizi.
WordPress può mostrare errori, ad esempio, su:
wp-content/debug.log
registrare.
Spieghiamo la configurazione sicura su Utilizzare il debug di WordPress e i log degli errori.
Testare separatamente il login di WordPress #
Se solo la registrazione su:
rispettivamente
non funziona, ma il sito web pubblico è raggiungibile, non si tratta di un'interruzione totale del sito web.
Usa in questo caso Il login di WordPress non funziona.
36. Considerare i cronjob e le attività in background #
Se il sito web mostra problemi regolarmente alla stessa ora, dovresti controllare i processi programmati.
Apri:
Opzioni avanzate → Cronjob
Confronta il momento temporale con:
- Cronjob
- Importante
- Esporta
- Backup
- Sincronizzazioni
- Attività in background di WordPress
In caso di problemi con un cronjob, puoi trovare la guida corrispondente su Cronjob non funziona: cause e soluzioni.
Sito web temporaneamente non raggiungibile #
In caso di guasti sporadici, l'ora esatta è particolarmente importante.
Documenta più eventi:
09:14 → non raggiungibile
11:37 → non raggiungibile
15:02 → non raggiungibileConfronta successivamente questi momenti con:
- Registro degli errori
- Risorse di CloudLinux
- Cronjob
- Attività in background
- traffico insolito
Senza indicazioni temporali, i problemi sporadici sono decisamente più difficili da diagnosticare.
Sito web irraggiungibile sempre alla stessa ora #
Un modello temporale ricorrente indica spesso un processo pianificato o regolare.
Per esempio:
02:00 → Backup
02:00 → Importazione
02:00 → Sincronizzazione
02:01 → Il sito web non rispondeQuesto non dimostra ancora quale processo sia la causa, ma fornisce un punto di partenza concreto.
Sito web non raggiungibile dopo l'aggiornamento #
Se il problema inizia immediatamente dopo un aggiornamento, verifica prima il componente aggiornato.
Ciò vale in particolare per:
- WordPress
- Plugin
- Temi
- Versione PHP
- componenti applicativi individuali
Controlla inoltre il registro degli errori per individuare un errore corrispondente.
Sito web non raggiungibile dopo la migrazione #
Dopo una migrazione, diversi livelli possono essere la causa.
Verifica in un ordine logico:
Dominio
↓
DNS
↓
server corretto
↓
Dominio in cPanel
↓
Document Root
↓
File
↓
SSL
↓
Versione PHP
↓
Estensioni PHP
↓
Applicazione
↓
DatabaseNon passare direttamente ai plugin di WordPress se il dominio punta ancora sul vecchio server.
41. Verifica della connessione al database #
Molti sistemi di gestione dei contenuti e applicazioni Web richiedono un database.
Se l'applicazione segnala esplicitamente un errore di database, verifica:
- Nome del database
- Utente del database
- Assegnazione dell'utente al database
- Autorizzazioni
- File di configurazione dell'applicazione
Spieghiamo come unire utenti e database in cPanel su Creare un utente MySQL e assegnarlo a un database.
Non modificare il database alla cieca #
Un'interruzione generale del sito web non è un motivo per eliminare, svuotare o modificare manualmente le tabelle.
Modifica il database solo quando c'è un'indicazione concreta di un problema al database.
Verificare se è interessato un solo dominio #
Se più domini vengono gestiti nello stesso account dihosting, un confronto può essere molto utile.
Esempio:
domain-a.ch → funktioniert
domain-b.ch → funktioniert
domain-c.ch → non raggiungibilePertanto, un guasto completo dell'account di hosting è meno probabile.
Concentra la diagnosi su:
- DNS di domain-c.ch
- Assegnazione del dominio
- Document Root
- SSL
- File
- Applicazione di questo dominio
Verificare se tutti i domini sono interessati #
Se tutti i siti Web di un account di hosting non funzionano contemporaneamente, la diagnosi si estende.
Verifica quindi in particolare:
- se cPanel è raggiungibile
- quale messaggio di errore restituiscono i domini
- se tutti i domini utilizzano gli stessi nameserver
- Risorse di CloudLinux
- Spazio di archiviazione
- modifiche comuni a PHP o alle configurazioni
Se più siti web indipendenti mostrano contemporaneamente lo stesso tipo di errore, dovresti assolutamente menzionare questa circostanza in una richiesta di supporto.
44. Classificare correttamente il timeout di connessione #
Un messaggio come:
ERR_CONNECTION_TIMED_OUT
non è la stessa cosa di un HTTP 500.
In caso di errore HTTP 500 è già stata ricevuta una risposta HTTP dal server. In caso di timeout della connessione, invece, non è stato possibile completare la connessione o la richiesta in tempo utile.
Annota quindi l'errore esatto del browser.
45. Interpretare correttamente Connection Refused #
Un messaggio come:
ERR_CONNECTION_REFUSED
differisce inoltre da un normale errore di applicazione.
Il browser non è riuscito a stabilire la connessione desiderata come previsto.
Anche in questo caso vale la regola: non modificare i plugin di WordPress o le impostazioni PHP prima di aver verificato che la richiesta raggiunga effettivamente la relativa applicazione web.
46. Delimitare la cache del browser come fonte di errore #
Testa il sito web anche in una finestra di navigazione in incognito.
Se necessario, usa un secondo browser o un altro dispositivo.
Questo ti permette di escludere determinati effetti locali.
Tuttavia, una cache del browser non causa un vero errore fatale PHP lato server e non rimuove un blocco di accesso lato server.
Considerare la cache DNS locale #
Dopo le modifiche ai DNS, il tuo dispositivo o il resolver DNS potrebbe avere ancora memorizzato nella cache informazioni meno recenti.
Se il sito web tramite rete mobile raggiunge già il nuovo server, ma tramite la tua normale connessione Internet non ancora, una cache DNS potrebbe avere un ruolo.
In questo caso, non attendere automaticamente un numero fisso qualsiasi di ore. La durata effettiva della cache dipende, tra le altre cose, dal rispettivo record DNS e dal suo TTL.
Non modificare subito il DNS se viene visualizzato un errore HTTP #
Se il tuo sito web, ad esempio, già:
Errore interno del server
viene visualizzato, è stato raggiunto un server web.
Sebbene dopo una migrazione il DNS possa puntare al server sbagliato, un errore HTTP reale dovrebbe essere diagnosticato innanzitutto sul server effettivamente raggiunto.
49. Non modificare subito PHP se il DNS non funziona #
Viceversa, vale il contrario:
Se il dominio non viene risolto affatto, il passaggio da PHP 8.x a un'altra versione di PHP non avrà alcun influsso su questo problema DNS.
L'ordine della diagnosi fa quindi risparmiare molto tempo.
50. Non disattivare tutte le funzioni di sicurezza #
Se l'accesso viene negato, non dovresti disattivare ciecamente ModSecurity, plugin di sicurezza o altri meccanismi di protezione.
In caso di errore 403, si dovrebbe prima determinare quale regola specifica o controllo di accesso sia coinvolto.
51. Non cambiare più cose contemporaneamente #
Una tipica pessima ricerca degli errori si presenta così:
Sito web non raggiungibile
↓
Modificare i DNS
Cambiare PHP
Eliminare .htaccess
Disattivare i plugin
Modificare i permessi
Installare la cacheSe il sito web dovesse funzionare di nuovo dopo, non saprai quale modifica sia stata rilevante – e potresti aver creato nuovi problemi.
L'approccio migliore:
Determinare l'errore con precisione
↓
delimitare il livello tecnico
↓
controllare log e metriche
↓
formulare un'ipotesi concreta
↓
apportare una modifica
↓
testare nuovamenteRegola fondamentale: Lavora dall'esterno verso l'interno: prima il dominio e la connessione, poi il web server e lo stato HTTP, e infine PHP e l'applicazione. In questo modo eviti modifiche a un livello tecnico che non c'entrano nulla con il problema reale.
Sito web non raggiungibile: diagnosi nell'ordine corretto #
- Prendi nota dell'URL completo e del messaggio di errore esatto.
- Controlla più pagine o sezioni del sito web.
- Prova in una finestra di navigazione in incognito.
- Testa, se possibile, tramite una seconda connessione Internet.
- Verifica se cPanel è raggiungibile.
- Classifica un possibile errore DNS.
- Prendi in considerazione le modifiche recenti a DNS o nameserver.
- Verifica il dominio sotto Domini → Domini.
- Controlla la Document Root.
- Controlla nel gestore di file se i file del sito web sono presenti.
- Distingui i problemi SSL dagli errori HTTP.
- Verifica l'effettivo codice di stato HTTP.
- Apri in caso di errori del server Valori misurati → Errore.
- Confronta l'errore con le modifiche recenti.
- Verifica se necessario
.htaccesse permessi dei file. - Nelle applicazioni PHP, controlla la versione di PHP, le estensioni e i limiti.
- Controlla i plugin, i temi e i registri di debug di WordPress.
- In caso di problemi sporadici, controlla le risorse CloudLinux.
- Prendi in considerazione i cronjob e le attività in background.
- Controlla lo spazio di archiviazione.
- Modifica sempre una sola causa possibile alla volta.
- Testa poi esattamente lo stesso tipo di errore.
Diagnosi rapida: Da dove dovresti iniziare? #
| Anomalia | Primo punto di controllo |
|---|---|
DNS_PROBE_FINISHED_NXDOMAIN | Controlla dominio e DNS |
| Il sito web mostra contenuti errati dopo la modifica del DNS | Controllare la destinazione DNS e la document root |
| Avviso di sicurezza del certificato | Controllare il certificato SSL e il nome host |
ERR_TOO_MANY_REDIRECTS | Controllare reindirizzamenti e .htaccess |
403 Proibito | Controllare le autorizzazioni e le regole di sicurezza |
404 Non Trovato | Controlla URL, file o regole di riscrittura |
Errore interno del server | Verifica il registro degli errori e gli errori PHP/dell'applicazione |
503 Servizio non disponibile | Controllare il registro degli errori, l'applicazione e le risorse |
Limite di risorse 508 raggiunto | Controlla le risorse di CloudLinux |
| solo l'area di amministrazione di WordPress è difettosa | Controllare WordPress, i plugin e il registro degli errori |
| non raggiungibile solo in determinati orari | Controllo di risorse e attività in background |
| non raggiungibile solo tramite la propria connessione internet | controllare la rete locale, il DNS e un eventuale blocco IP |
Cosa non fare in caso di guasto del sito web #
Evita in particolare:
- Modificare i record DNS a titolo precauzionale
- Cambiare le versioni di PHP a caso
.htaccesselimina senza backup- Permessi dei file in blocco su
777mettere - disattivare tutte le funzioni di sicurezza
- eliminare più plugin contemporaneamente
- Modificare le tabelle del database per sospetto
- Riconfigurare i certificati SSL nonostante sia presente un errore PHP
- eseguire più modifiche tecniche contemporaneamente
Quali informazioni aiutano il supporto di CURIAWEB? #
Se non riesci a circoscrivere tu stesso la causa, informazioni il più possibile precise aiutano nell'analisi tecnica.
Nota:
- dominio interessato
- URL completa interessata
- messaggio di errore esatto
- Data e ora esatte
- se il sito web non è raggiungibile in modo permanente o sporadico
- se sia interessata una sola pagina o l'intero sito web
- se altri domini funzionano nello stesso hosting
- se il sito web è raggiungibile tramite un'altra connessione a Internet
- voci di registro degli errori rilevanti
- valori CloudLinux anomali o errori
- modifiche recenti
In caso di errore riproducibile, dovresti anche indicare i passaggi esatti con cui è possibile causare il problema.
Riepilogo #
Se un sito web non è raggiungibile, non dovresti modificare subito WordPress, PHP o DNS. Per prima cosa bisogna determinare a quale livello tecnico si verifica l'errore.
Inizia con l'esatto messaggio di errore e l'URL interessato. Verifica successivamente se solo tu, una singola pagina, un dominio o l'intero account di hosting sei interessato.
In caso di errori DNS, bisogna prima esaminare la risoluzione dei nomi. Se il server web viene raggiunto, i codici di stato HTTP come 403, 500, 503 o 508 servono da guida per un'ulteriore diagnosi.
In caso di problemi lato server, il registro degli errori di cPanel e – nel caso di errori sporadici – l'utilizzo delle risorse CloudLinux figurano tra i principali strumenti di diagnostica. Per le applicazioni PHP si aggiungono la versione di PHP, le estensioni e i limiti. Nel caso di WordPress, dovresti considerare inoltre plugin, temi e log di debug.
Particolarmente prezioso è sempre il contesto temporale: se il sito web si interrompe subito dopo una modifica del DNS, un cambio di PHP, un aggiornamento di un plugin o una modifica del .htaccess si è guastato, inizia l'indagine proprio lì.
La regola più importante è: Prima determinare dove fallisce la richiesta, poi esaminare esattamente quel livello tecnico.
