Site suspendat de furnizorul de hosting: cauzele posibile

Găsiți cauza

Pe o găzduire administrată cu cPanel, suspendarea înlocuiește site-ul cu o pagină care anunță că contul este suspendat, adesea în engleză („This Account has been suspended”). Blochează și conectarea la panou, accesul FTP și trimiterea de e-mailuri din cont; primirea depinde de configurarea serverului. Fișierele, în schimb, rămân la locul lor.

Cauza apare de obicei într-un mesaj al furnizorului de găzduire: căutați în căsuța de e-mail asociată contului, inclusiv în dosarul de spam, cuvintele „suspendare”, „abuse”, „malware” sau „factură”, apoi consultați contul de client și tichetele.

Dacă mesajul nu indică nicio cauză, cereți-o în scris, împreună cu clauza din condițiile de utilizare care se aplică: o suspendare se ridică mai repede când toată lumea vorbește despre aceeași problemă.

Mai întâi, recuperați o copie a site-ului

Condițiile furnizorului de găzduire fixează termenul după care datele unui cont suspendat pot fi șterse. Înainte de orice alt demers, puneți o copie la adăpost:

• Fișierele: prin SFTP, dacă accesul este încă deschis, altfel cerând o arhivă furnizorului de găzduire.
• Baza de date: prin exportul din phpMyAdmin sau cu wp db export, ori în aceeași cerere de arhivă.
• E-mailurile, dacă poșta electronică este găzduită în același cont: o copie a căsuțelor prin IMAP, dintr-un program de e-mail.
• Data de ștergere prevăzută, cerută în scris.

Păstrați această copie ca atare, chiar dacă site-ul este infectat: servește la curățare și la comparație.

Cauza 1: un site spart

Pe un server partajat, un site care distribuie un program malware, găzduiește pagini false de autentificare sau trimite spam pune în pericol celelalte conturi și reputația adreselor IP ale serverului. Furnizorul de găzduire suspendă deci contul și îl redeschide când problema este rezolvată.

1. Cereți lista fișierelor detectate și întrebați dacă furnizorul de găzduire poate redeschide accesul la fișiere pe durata curățării.
2. Ștergeți fișierele semnalate, apoi căutați ce le-a depus: fișiere PHP în wp-content/uploads, dosare necunoscute la rădăcină, scripturi de trimitere de e-mailuri, conturi de administrator adăugate.
3. Schimbați parolele contului de găzduire, FTP, bazei de date și administratorilor și reînnoiți cheile de securitate din wp-config.php.
4. Actualizați WordPress, tema și modulele, apoi ștergeți-le pe cele care nu mai sunt folosite.
5. Scrieți furnizorului de găzduire ce a fost găsit, șters și corectat, citând referința suspendării.

Mutarea la un alt furnizor de găzduire cu aceleași fișiere transportă infecția odată cu ele, iar odată cu ea riscul unei noi suspendări. Curățarea se face înainte de repunerea online, oriunde ar avea loc aceasta.

Cauza 2: resurse peste limite

O găzduire partajată plafonează ce consumă fiecare cont. Pe serverele care folosesc CloudLinux, limitele privesc procesorul, memoria fizică, operațiile de citire și scriere pe disc, numărul de procese și procesele de intrare (Entry Processes), adică conexiunile simultane la scripturile dinamice precum PHP. Numărul de fișiere se numără în inoduri (inodes): fiecare fișier și fiecare dosar consumă unul.

Când limita proceselor de intrare este atinsă, vizitatorii primesc o eroare 508 „Resource Limit Is Reached”. Depășirile repetate pot duce la suspendare. Panoul furnizorului de găzduire arată consumul în timp: identificați orele vârfurilor, apoi citiți jurnalele de acces de la acele ore.

Cauzele cele mai frecvente

• Roboți care încearcă autentificări în buclă pe wp-login.php sau xmlrpc.php.
• Module care consumă mult: statistici, jurnale, generatoare de imagini, copii de rezervă.
• Copii de rezervă stocate în cont, în wp-content, care umplu spațiul pe disc și inodurile.
• Sarcinile programate ale WordPress, declanșate la fiecare vizită.

du -sh wp-content/* | sort -h
find . -type f | wc -l

<Files "xmlrpc.php">
Require all denied
</Files>

Acest bloc refuză orice cerere către xmlrpc.php. Verificați mai întâi că niciun instrument nu îl folosește: Jetpack, de exemplu, trece prin XML-RPC. Dacă site-ul afișează apoi o eroare 500, furnizorul de găzduire nu permite această directivă în .htaccess: eliminați blocul și cereți-i echivalentul.

define( 'DISABLE_WP_CRON', true );

Sarcinile programate trebuie atunci apelate de planificatorul serverului: creați în panoul furnizorului de găzduire o sarcină cron care apelează https://www.site-ul-dumneavoastra.com/wp-cron.php la interval regulat, de exemplu la fiecare 15 minute.

Cauza 3: o factură neplătită

Plătiți factura din contul de client și verificați că cardul înregistrat este încă valabil. Reactivarea urmează plății, automat sau la cerere, după furnizor; dacă întârzie, deschideți un tichet cu referința plății.

Numele de domeniu se reînnoiește adesea separat de găzduire. Un domeniu ajuns la scadență face și el să dispară site-ul, dar pagina afișată este atunci cea a registrarului, nu cea a furnizorului de găzduire: sunt două facturi și două verificări.

Cauza 4: o reclamație sau o încălcare a condițiilor

• Drepturi de autor: o imagine sau un text folosit fără licență. Eliminați conținutul sau transmiteți dovada licenței, citând referința reclamației.
• Semnalare de abuz: o pagină falsă de autentificare sau un program malware descoperit pe site-ul dumneavoastră. Este o spargere, de tratat ca în cauza 1.
• Reclamații pentru spam: e-mailuri trimise din cont către destinatari care nu le așteptau, inclusiv un newsletter. Verificați cine trimite din cont și cum au fost colectate adresele.

Răspundeți în scris, în termenul indicat, descriind ce s-a făcut: acesta este documentul pe care furnizorul de găzduire îl adaugă la dosar pentru a ridica suspendarea.

Înainte de repunerea online

1. Cauza este identificată și corectată, iar furnizorul de găzduire a confirmat în scris ce așteaptă.
2. Parolele sunt schimbate, iar componentele site-ului sunt la zi.
3. Există o copie de rezervă automată, păstrată în afara contului de găzduire.
4. Cineva primește alertele furnizorului de găzduire: adresa de e-mail a contului este citită.