Sito web non raggiungibile: diagnosticare sistematicamente gli errori di hosting

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 raggiunto

Ecco 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 raggiunto

Non 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:

https://example.ch

o:

https://www.example.ch

o:

https://shop.example.ch

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 funziona

Allora 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 web

Se 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 trovato

indicano 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.html

Se 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.php eliminato?
• È stato estratto un archivio nella directory errata?
• È stata .htaccess cambiato?

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:

https://example.ch

e

https://www.example.ch

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
• .htaccess modificato
• DNS modificato
• Dominio reindirizzato
• File spostati
• Sito web migrato
• Cronjob configurato

Ein enger zeitlicher Zusammenhang ist häufig wertvoller als eine lange Liste theoretisch möglicher Ursachen.

24. .htaccess überprüfen #

Eine fehlerhafte .htaccess kann unterschiedliche Probleme verursachen, darunter Weiterleitungsschleifen, 403- oder 500-Fehler.

Wenn das Problem unmittelbar nach einer Änderung dieser Datei begonnen hat, prüfe zuerst genau diese Änderung.

Wie du dabei sicher vorgehst, erklären wir unter .htaccess spiegato e modificato in sicurezza.

25. Dateiberechtigungen prüfen #

Wenn Dateien oder Verzeichnisse nicht mit geeigneten Berechtigungen versehen sind, kann der Webserver gegebenenfalls nicht korrekt darauf zugreifen.

Nei siti Web tipici si possono spesso trovare i seguenti valori:

File:       644
Directory: 755

Diese Werte sollten jedoch nicht blind auf sämtliche Inhalte angewendet werden.

Puoi trovare la guida completa su Impostare correttamente i permessi dei file 644 e 755 in cPanel.

Attenzione: Setze Dateien und Verzeichnisse nicht pauschal auf 777, nur weil die Website nicht funktioniert. Das ist keine saubere Fehlerbehebung und kann Sicherheitsrisiken verursachen.

26. PHP-Version kontrollieren #

Wenn eine PHP-basierte Website nach einem PHP-Wechsel nicht mehr funktioniert, kontrolliere die verwendete Version und die Kompatibilität der Anwendung.

Bei CURIAWEB verwaltest du die PHP-Version grundsätzlich über:

Software → MultiPHP Manager

Le istruzioni si trovano su Modificare la versione di PHP in cPanel.

Wechsle PHP-Versionen nicht wahllos. Prüfe zuerst das Error Log und die Anforderungen deiner Anwendung.

27. PHP-Erweiterungen berücksichtigen #

Nach einem PHP-Wechsel oder einer Migration kann eine Anwendung Funktionen benötigen, die in der verwendeten PHP-Umgebung nicht verfügbar sind.

Typische Fehlermeldungen sind beispielsweise:

Chiamata a funzione non definita ...

Classe ... non trovata

richiede ext-...

Puoi trovare ulteriori informazioni su Attivare e gestire le estensioni PHP in cPanel.

28. PHP-Limits prüfen #

Wenn ein Fehler nur bei bestimmten aufwendigen Aktionen auftritt, können PHP-Limits relevant sein.

Gli esempi sono:

memory_limit
upload_max_filesize
post_max_size
max_execution_time
max_input_time

Wenn das Error Log beispielsweise:

Dimensione della memoria consentita esaurita

meldet, ist das ein konkreter Hinweis auf das PHP Memory Limit.

Die Einstellungen erklären wir unter Imposta limite di memoria PHP, dimensione di caricamento e tempo di esecuzione.

29. CloudLinux-Ressourcen kontrollieren #

Wenn die Website nur zeitweise nicht erreichbar ist, solltest du die Ressourcennutzung zum gleichen Zeitpunkt überprüfen.

Apri:

Valori misurati → Utilizzo delle risorse

Prüfe insbesondere, ob Faults beziehungsweise auffällige Werte vorhanden sind.

Wie du die Daten interpretierst, erklären wir unter Comprendere l'utilizzo delle risorse di CloudLinux in cPanel.

30. Speicherplatz überprüfen #

Ein vollständig belegter Hosting-Account kann verschiedene Schreibvorgänge beeinträchtigen.

Dazu können je nach Anwendung beispielsweise gehören:

• Uploads
• Aggiornamenti
• File di cache
• file temporanei
• Registri
• Backup
• E-Mail-Speicherung

Die Speicherplatznutzung prüfst du unter:

File → Utilizzo dello spazio di archiviazione

Puoi trovare ulteriori informazioni su Controllare lo spazio di archiviazione e la larghezza di banda in cPanel.

31. WordPress als eigene Fehlerquelle eingrenzen #

Wenn andere Inhalte oder Domains im Hosting funktionieren, aber eine bestimmte WordPress-Installation nicht, solltest du die Anwendung selbst untersuchen.

Typische Bereiche sind:

• Plugin
• Temi
• WordPress-Core
• .htaccess
• Compatibilità PHP
• Database
• individueller Code

32. WordPress kritischer Fehler #

Wenn WordPress meldet:

Es gab einen kritischen Fehler auf deiner Website.

liegt häufig ein PHP-Fehler innerhalb von WordPress, einem Plugin, Theme oder individuellem Code vor.

Usalo per WordPress kritischer Fehler oder weiße Seite beheben.

33. WordPress-Plugins und Themes prüfen #

Wenn das Problem unmittelbar nach Installation, Aktivierung oder Update eines Plugins beziehungsweise Themes begonnen hat, ist dieser zeitliche Zusammenhang wichtig.

Prüfe das Error Log auf Pfade wie:

/wp-content/plugins/...
/wp-content/themes/...

Die systematische Diagnose erklären wir unter Identificare e risolvere i conflitti tra plugin e temi WordPress.

34. WordPress-Debugging verwenden #

Se il normale log degli errori non fornisce informazioni sufficienti, una registrazione di debug di WordPress controllata può fornire ulteriori indizi.

WordPress kann Fehler beispielsweise unter:

wp-content/debug.log

registrare.

Die sichere Einrichtung erklären wir unter Utilizzare il debug di WordPress e i log degli errori.

35. WordPress-Login separat testen #

Wenn nur die Anmeldung unter:

https://example.ch/wp-admin

rispettivamente

https://example.ch/wp-login.php

nicht funktioniert, die öffentliche Website aber erreichbar ist, handelt es sich nicht um einen vollständigen Website-Ausfall.

Verwende in diesem Fall WordPress-Login funktioniert nicht.

36. Cronjobs und Hintergrundaufgaben berücksichtigen #

Wenn die Website regelmäßig zur gleichen Uhrzeit Probleme zeigt, solltest du geplante Prozesse prüfen.

Apri:

Opzioni avanzate → Cronjob

Vergleiche den Zeitpunkt mit:

• Cronjob
• Importen
• Exporten
• Backup
• Sincronizzazioni
• Attività in background di WordPress

Bei Problemen mit einem Cronjob findest du die passende Anleitung unter Cronjob non funziona: cause e soluzioni.

37. Website nur zeitweise nicht erreichbar #

Bei sporadischen Ausfällen ist die genaue Uhrzeit besonders wichtig.

Dokumentiere mehrere Ereignisse:

09:14 → nicht erreichbar
11:37 → nicht erreichbar
15:02 → nicht erreichbar

Vergleiche diese Zeitpunkte anschließend mit:

• Registro degli errori
• Risorse di CloudLinux
• Cronjob
• Attività in background
• ungewöhnlichem Traffic

Ohne Zeitangaben sind sporadische Probleme deutlich schwieriger zu diagnostizieren.

38. Website immer zur gleichen Uhrzeit nicht erreichbar #

Ein wiederkehrendes Zeitmuster deutet häufig auf einen geplanten oder regelmäßig auftretenden Vorgang hin.

Per esempio:

02:00 → Backup
02:00 → Import
02:00 → Synchronisation
02:01 → Website reagiert nicht

Das beweist noch nicht, welcher Prozess die Ursache ist, liefert aber einen konkreten Ausgangspunkt.

39. Website nach Update nicht erreichbar #

Wenn das Problem unmittelbar nach einem Update beginnt, prüfe die aktualisierte Komponente zuerst.

Ciò vale in particolare per:

• WordPress
• Plugin
• Temi
• Versione PHP
• individuelle Anwendungskomponenten

Kontrolliere zusätzlich das Error Log auf einen passenden Fehler.

40. Website nach Migration nicht erreichbar #

Nach einer Migration kommen mehrere Ebenen als Ursache infrage.

Prüfe in sinnvoller Reihenfolge:

Domain
  ↓
DNS
  ↓
richtiger Server
  ↓
Domain in cPanel
  ↓
Document Root
  ↓
Dateien
  ↓
SSL
  ↓
PHP-Version
  ↓
PHP-Erweiterungen
  ↓
Anwendung
  ↓
Datenbank

Springe nicht direkt zu WordPress-Plugins, wenn die Domain noch auf den alten Server zeigt.

41. Datenbankverbindung prüfen #

Viele Content-Management-Systeme und Webanwendungen benötigen eine Datenbank.

Wenn die Anwendung ausdrücklich einen Datenbankfehler meldet, prüfe:

• Nome del database
• Utente del database
• Assegnazione dell'utente al database
• Berechtigungen
• Konfigurationsdatei der Anwendung

Wie Benutzer und Datenbanken in cPanel zusammengeführt werden, erklären wir unter Creare un utente MySQL e assegnarlo a un database.

Datenbank nicht auf Verdacht verändern #

Ein allgemeiner Website-Ausfall ist kein Grund, Tabellen zu löschen, zu leeren oder manuell zu verändern.

Bearbeite die Datenbank erst, wenn ein konkreter Hinweis auf ein Datenbankproblem vorliegt.

42. Prüfen, ob nur eine einzelne Domain betroffen ist #

Wenn mehrere Domains im gleichen Hosting-Account betrieben werden, kann ein Vergleich sehr hilfreich sein.

Esempio:

domain-a.ch → funktioniert
domain-b.ch → funktioniert
domain-c.ch → nicht erreichbar

Dann ist ein vollständiger Ausfall des Hosting-Accounts weniger wahrscheinlich.

Konzentriere die Diagnose auf:

• DNS von domain-c.ch
• Domain-Zuordnung
• Document Root
• SSL
• File
• Anwendung dieser Domain

43. Prüfen, ob alle Domains betroffen sind #

Wenn sämtliche Websites eines Hosting-Accounts gleichzeitig nicht funktionieren, erweitert sich die Diagnose.

Verifica quindi in particolare:

• ob cPanel erreichbar ist
• welche Fehlermeldung die Domains liefern
• ob alle Domains dieselben Nameserver verwenden
• Risorse di CloudLinux
• Spazio di archiviazione
• gemeinsame Änderungen an PHP oder Konfigurationen

Wenn mehrere unabhängige Websites gleichzeitig dasselbe Fehlerbild zeigen, solltest du diesen Umstand bei einer Supportanfrage unbedingt angeben.

44. Verbindungstimeout richtig einordnen #

Un messaggio come:

ERR_CONNECTION_TIMED_OUT

ist nicht dasselbe wie ein HTTP-500.

Bei einem HTTP-500 wurde bereits eine HTTP-Antwort vom Server empfangen. Bei einem Verbindungstimeout konnte die Verbindung beziehungsweise Anfrage dagegen nicht rechtzeitig abgeschlossen werden.

Notiere deshalb den exakten Browserfehler.

45. Connection Refused richtig einordnen #

Un messaggio come:

ERR_CONNECTION_REFUSED

unterscheidet sich ebenfalls von einem normalen Anwendungsfehler.

Der Browser konnte die gewünschte Verbindung nicht wie erwartet herstellen.

Auch hier gilt: Ändere nicht WordPress-Plugins oder PHP-Einstellungen, bevor klar ist, dass die Anfrage überhaupt die entsprechende Webanwendung erreicht.

46. Browser-Cache als Fehlerquelle eingrenzen #

Teste die Website zusätzlich in einem privaten Browserfenster.

Wenn nötig, verwende einen zweiten Browser oder ein anderes Gerät.

Damit kannst du bestimmte lokale Effekte ausschließen.

Ein Browser-Cache verursacht allerdings keinen echten serverseitigen PHP Fatal Error und hebt keine serverseitige Zugriffssperre auf.

47. Lokalen DNS-Cache berücksichtigen #

Nach DNS-Änderungen kann dein Gerät oder DNS-Resolver noch ältere Informationen zwischengespeichert haben.

Wenn die Website über Mobilfunk bereits den neuen Server erreicht, über deine normale Internetverbindung aber noch nicht, kann ein DNS-Cache eine Rolle spielen.

Warte in diesem Fall nicht automatisch auf eine beliebige feste Anzahl Stunden. Die tatsächliche Cache-Dauer hängt unter anderem vom jeweiligen DNS-Eintrag und dessen TTL ab.

48. Nicht sofort DNS ändern, wenn ein HTTP-Fehler angezeigt wird #

Wenn deine Website beispielsweise bereits:

Errore interno del server

anzeigt, wurde ein Webserver erreicht.

DNS kann nach einer Migration zwar auf den falschen Server zeigen, aber ein echter HTTP-Fehler sollte zunächst auf dem tatsächlich erreichten Server diagnostiziert werden.

49. Nicht sofort PHP ändern, wenn DNS nicht funktioniert #

Umgekehrt gilt:

Wenn die Domain überhaupt nicht aufgelöst wird, hat ein Wechsel von PHP 8.x auf eine andere PHP-Version keinen Einfluss auf dieses DNS-Problem.

Die Reihenfolge der Diagnose spart deshalb viel Zeit.

50. Nicht alle Sicherheitsfunktionen deaktivieren #

Wenn ein Zugriff verweigert wird, solltest du nicht pauschal ModSecurity, Sicherheitsplugins oder andere Schutzmechanismen deaktivieren.

Bei einem 403 sollte zuerst festgestellt werden, welche konkrete Regel beziehungsweise Zugriffskontrolle beteiligt ist.

51. Nicht mehrere Dinge gleichzeitig ändern #

Eine typische schlechte Fehlersuche sieht so aus:

Website nicht erreichbar
        ↓
DNS ändern
PHP wechseln
.htaccess löschen
Plugins deaktivieren
Berechtigungen ändern
Cache installieren

Wenn die Website danach wieder funktioniert, weißt du nicht, welche Änderung relevant war – und möglicherweise hast du neue Probleme geschaffen.

Die bessere Vorgehensweise:

Fehler exakt bestimmen
        ↓
technische Ebene eingrenzen
        ↓
Logs und Messwerte prüfen
        ↓
eine konkrete Hypothese bilden
        ↓
eine Änderung durchführen
        ↓
erneut testen

Regola fondamentale: Arbeite von außen nach innen: zuerst Domain und Verbindung, danach Webserver und HTTP-Status, anschließend PHP und Anwendung. So vermeidest du Änderungen auf einer technischen Ebene, die mit dem eigentlichen Problem gar nichts zu tun hat.

Website nicht erreichbar: Diagnose in der richtigen Reihenfolge #

1. Notiere die vollständige URL und exakte Fehlermeldung.
2. Prüfe mehrere Seiten beziehungsweise Bereiche der Website.
3. Teste über ein privates Browserfenster.
4. Teste nach Möglichkeit über eine zweite Internetverbindung.
5. Prüfe, ob cPanel erreichbar ist.
6. Ordne einen möglichen DNS-Fehler ein.
7. Berücksichtige kürzlich vorgenommene DNS- oder Nameserver-Änderungen.
8. Prüfe die Domain unter Domini → Domini.
9. Kontrolliere den Document Root.
10. Prüfe im Dateimanager, ob die Website-Dateien vorhanden sind.
11. Unterscheide SSL-Probleme von HTTP-Fehlern.
12. Prüfe den tatsächlichen HTTP-Statuscode.
13. Öffne bei serverseitigen Fehlern Valori misurati → Errore.
14. Vergleiche den Fehler mit kürzlich vorgenommenen Änderungen.
15. Prüfe gegebenenfalls .htaccess und Dateiberechtigungen.
16. Kontrolliere bei PHP-Anwendungen PHP-Version, Erweiterungen und Limits.
17. Prüfe bei WordPress Plugins, Themes und Debug-Protokolle.
18. Kontrolliere bei sporadischen Problemen die CloudLinux-Ressourcen.
19. Berücksichtige Cronjobs und Hintergrundaufgaben.
20. Prüfe den Speicherplatz.
21. Ändere immer nur eine mögliche Ursache gleichzeitig.
22. Teste anschließend exakt dasselbe Fehlerbild erneut.

Schnelldiagnose: Wo solltest du anfangen? #

Anomalia	Primo punto di controllo
DNS_PROBE_FINISHED_NXDOMAIN	Domain und DNS prüfen
Website zeigt nach DNS-Änderung falschen Inhalt	DNS-Ziel und Document Root prüfen
Avviso di sicurezza del certificato	SSL-Zertifikat und Hostname prüfen
ERR_TOO_MANY_REDIRECTS	Weiterleitungen und .htaccess prüfen
403 Proibito	Berechtigungen und Sicherheitsregeln prüfen
404 Non Trovato	URL, Dateien oder Rewrite-Regeln prüfen
Errore interno del server	Error Log und PHP-/Anwendungsfehler prüfen
503 Servizio non disponibile	Error Log, Anwendung und Ressourcen prüfen
Limite di risorse 508 raggiunto	CloudLinux-Ressourcen prüfen
nur WordPress-Adminbereich defekt	WordPress, Plugins und Error Log prüfen
nur zu bestimmten Uhrzeiten nicht erreichbar	Ressourcen und Hintergrundaufgaben prüfen
nur über eigene Internetverbindung nicht erreichbar	lokales Netzwerk, DNS und mögliche IP-Sperre prüfen

Was du bei einem Website-Ausfall nicht tun solltest #

Evita in particolare:

• DNS-Einträge auf Verdacht ändern
• Cambiare le versioni di PHP a caso
• .htaccess ohne Sicherung löschen
• Dateiberechtigungen pauschal auf 777 setzen
• alle Sicherheitsfunktionen deaktivieren
• eliminare più plugin contemporaneamente
• Modificare le tabelle del database per sospetto
• SSL-Zertifikate neu konfigurieren, obwohl ein PHP-Fehler vorliegt
• eseguire più modifiche tecniche contemporaneamente

Quali informazioni aiutano il supporto di CURIAWEB? #

Wenn du die Ursache nicht selbst eingrenzen kannst, helfen möglichst genaue Angaben bei der technischen Analyse.

Nota:

• dominio interessato
• vollständige betroffene URL
• exakte Fehlermeldung
• Data e ora esatte
• ob die Website dauerhaft oder sporadisch nicht erreichbar ist
• ob nur eine Seite oder die gesamte Website betroffen ist
• ob andere Domains im gleichen Hosting funktionieren
• ob die Website über eine andere Internetverbindung erreichbar ist
• voci di registro degli errori rilevanti
• auffällige CloudLinux-Werte beziehungsweise Faults
• modifiche recenti

Bei einem reproduzierbaren Fehler solltest du zusätzlich die genauen Schritte angeben, mit denen das Problem ausgelöst werden kann.

Riepilogo #

Wenn eine Website nicht erreichbar ist, solltest du nicht sofort WordPress, PHP oder DNS verändern. Zuerst muss festgestellt werden, auf welcher technischen Ebene der Fehler entsteht.

Beginne mit der exakten Fehlermeldung und der betroffenen URL. Prüfe anschließend, ob nur du, eine einzelne Seite, eine Domain oder der gesamte Hosting-Account betroffen ist.

Bei DNS-Fehlern muss zuerst die Namensauflösung untersucht werden. Wird der Webserver erreicht, dienen HTTP-Statuscodes wie 403, 500, 503 oder 508 als Wegweiser für die weitere Diagnose.

Bei serverseitigen Problemen gehören das cPanel Error Log und – bei sporadischen Fehlern – die CloudLinux-Ressourcennutzung zu den wichtigsten Diagnosewerkzeugen. Bei PHP-Anwendungen kommen PHP-Version, Erweiterungen und Limits hinzu. Bei WordPress solltest du zusätzlich Plugins, Themes und Debug-Protokolle berücksichtigen.

Besonders wertvoll ist immer der zeitliche Zusammenhang: Wenn die Website direkt nach einer DNS-Änderung, einem PHP-Wechsel, Plugin-Update oder einer Änderung der .htaccess ausgefallen ist, beginne die Untersuchung genau dort.

La regola più importante è: Erst bestimmen, wo die Anfrage scheitert – dann genau diese technische Ebene untersuchen.