Liigu peamise sisu juurde

500 Sisemine serveriviga: põhjused ja lahendused

· 4 min lugemine
Andres Saar
Customer Care Engineer

kuidas-parandada-500-sisemist-serveriviga-veebisaidi-veahaangamine

500 Sisemine serveriviga on üks levinumaid probleeme, millega veebisaidi omanikud ja administraatorid kokku puutuvad. See annab märku, et serveris läks midagi valesti, kuid ei paku täpseid diagnostilisi andmeid. See artikkel selgitab, mis tavaliselt 500 viga põhjustab ja kuidas seda lahendada.

500 vea võimalikud põhjused​

500 viga võib tekkida mitmel põhjusel. Kõige sagedasemad on:

  1. Serveripoolsed ressursiprobleemid

Sageli võib 500 viga olla põhjustatud tehnilistest probleemidest serveris, näiteks ressursside puudusest (RAM, CPU aeg).

  1. Veebisaidi koodi vead

Skriptid või veebisaidi kood võivad sisaldada vigu, mis põhjustavad tõrke. See võib juhtuda valede päringute, konfiguratsioonifailide vigade või saidi komponentide koosmõju probleemide tõttu.

  1. Probleemid .htaccess-failiga

.htaccess-faili kasutatakse veebiserveri konfigureerimiseks ja see võib sisaldada vigu, mis põhjustavad 500 viga. Näiteks võivad valed ümbersuunamisreeglid või valed parameetrid põhjustada tõrke.

  1. Hiljutised uuendused

Vead võivad ilmneda pärast veebisaidi või serverirakenduste värskendusi, kus muudatusi ei käsitletud õigesti.

Kuidas parandada 500 viga​

  1. Kontrollige veebiserveri logisid

500 vea põhjuste kindlaksmääramiseks on esmalt vaja kontrollida serveri logisid. Need logid sisaldavad tavaliselt teavet tõrke kohta – kas tegemist on koodivea, vale konfiguratsiooni või serveripoolse probleemiga. Siiski on oluline mõista, et veebiserveri logid (nagu Nginxi või Apache omad) salvestavad sageli ainult vea toimumist ja vastusekoodi, mitte juurpõhjust. See kehtib eriti Nginxi puhul, mis toimib tavaliselt vahendajana ja edastab vea taustaprogrammi rakendusest.

Olenevalt kasutatavast veebiserverist võivad logid asuda järgmistes kataloogides:

Apache:

  • Ubuntu/Debian: /var/log/apache2/error.log

  • CentOS/AlmaLinux/Rocky Linux: /var/log/httpd/error.log

Nginx:

  • /var/log/nginx/error.log

Kui teie serverit hallatakse juhtpaneeli kaudu, näiteks FASTPANEL, muutub logide vaatamine veelgi lihtsamaks. Selleks tehke järgmist:

  • Logige juhtpaneelile sisse.

  • Avage saidi kaart ja leidke jaotis „Logid“.

  • Vahekaart „Frontend Error Log“ sisaldab Nginxi veebiserveri vigu, samas kui vahekaart „Backend Error Log“ sisaldab Apache vigu.

Pidage meeles, et paljud CMS-id ja raamistikud (WordPress, Laravel, Joomla jne) hoiavad oma vealoge. Need logid pakuvad sageli täpsemat teavet 500 vea põhjuste kohta. Küsige oma platvormi dokumentatsioonist, kus neid logisid hoitakse.

Logid annavad teile suure tõenäosusega üksikasjaliku ülevaate sellest, mis valesti läks. Kui 500 viga on põhjustatud vale konfiguratsiooni või koodiprobleemide tõttu, näete faile – või isegi täpseid ridu –, mis tõrke põhjustavad.

  1. Lülitage sisse PHP-poolne vigade logimine

Täpsema diagnostika saamiseks lülitage PHP-s sisse logimine – see on eriti kasulik, kui viga pärineb koodist ega ilmu veebiserveri logidesse.

Selleks määrake failis php.ini järgmised väärtused:

display_errors = Off

log_errors = On

error_log = /var/log/php_errors.log

Siin:

  • display_errors – summutab veateate kuvamise brauseris

  • log_errors – kirjutab vead logifaili

  • error_log – logifaili tee (PHP-l peab olema kirjutamisõigus)

Tüüpilised php.ini asukohad:

  • Debian/Ubuntu: /etc/php/*/apache2/php.ini või /etc/php/*/cli/php.ini

  • CentOS/AlmaLinux: /etc/php.ini

Või leidke see järgmiselt:

php -i | grep "php.ini"

FASTPANEL-is: avage saidi kaart → „PHP seaded“, otsige üles muutujad nagu display_errors, muutke nende väärtusi ja klõpsake „Salvesta“

  1. Kontrollige .htaccess-faili

Kui viga ilmnes pärast .htaccess-faili redigeerimist, taastage faili eelmine olek.

Kui te pole kindlad, mis täpselt muutus, nimetage .htaccess-fail ajutiselt ümber (näiteks .htaccess.bak) – kui viga kaob, siis probleem on selles failis.

Sel juhul proovige taastada .htaccess-fail varukoopiast, kui see on saadaval, või kasutage oma CMS-i jaoks vaikimisi .htaccess-faili, mille saate siit.

  1. Kontrollige faili õigusi ja omanikku

Valed õigused võivad põhjustada 500**-vea**. Veenduge, et saidi juurkaustal ja kõigil alamfailidel oleksid õiged õigused ja omanik:

ls -laR /path/to/your/site/root

Soovitatavad õigused:

  • Kataloogide jaoks: 755 – lugemine, kirjutamine ja täitmine omanikule; lugemine ja täitmine kõigile teistele.

  • Failide jaoks: 644 – lugemine ja kirjutamine omanikule; ainult lugemine kõigile teistele.

Omanik:

Failid ja kaustad peaksid kuuluma veebiserveri kasutajale (nt www-data või apache).

Vajadusel saate õigusi ja omanikku muuta järgmiste käskude abil:

  • Siirduge oma saidi juurkataloogi:
cd /path/to/root/directory/site
  • Määrake õiged omanikud ja õigused:
sudo chown -R yoursiteuser:yoursiteuser . && sudo chmod 644 . -R && sudo chmod +X . -R

Palun asendage yoursiteuser tegeliku kasutaja ja grupiga, kes on teie saidi omanikud.

  1. Keelake pistikprogrammid ja teemad.

CMS-põhistel saitidel nagu WordPress ilmneb 500 viga sageli pistikprogrammide või teemade konfliktide tõttu. Keelake kõik pistikprogrammid ja lülitage vaiketeemale, et näha, kas see lahendab probleemi.

  1. Veenduge, et serveril oleks teie saitide jaoks piisavalt vabu ressursse.
  • Kontrollige, kas teil on piisavalt vaba kettaruumi:
sudo df -h
  • Kontrollige, kas serveril pole inoodid otsa lõppenud:
sudo df -ih
  • Kontrollige, kas serveril on piisavalt RAM-i:
sudo free -mh
  • Kontrollige praegust CPU koormust:
sudo ps -eo pid,ppid,cmd,%mem,%cpu --sort=-%cpu | head
  • Alternatiivina avage protsessomonitor käsuga:
sudo top

Kui teil on kettaruum või inoodid otsa lõppenud, saate kindlaks teha, millised failid ja kataloogid kulutavad kõige rohkem ruumi, järgides vastava artikli juhiseid artiklis.

Kui RAM või CPU koormus on liiga kõrge, võivad põhjused olla erinevad. Alustage uurimisega, blokeerides otsingumootori robotid, kuna need on sageli suure koormuse allikaks.

  1. Veenduge, et DBMS oleks terve.

Enamasti on see MySQL; allpool on mõned kiired sammud, et kontrollida, kas teie andmebaasid on korras

  • Veenduge, et MySQL-i teenus töötab:
sudo systemctl status mysql
  • Kontrollige MySQL-i vealogi:
sudo grep -i error /var/log/mysql/error.log
  • Kontrollige kõiki andmebaase vigade osas:
mysqlcheck -A -c

Kui vead leitakse, veenduge esmalt täielikult, et teil oleks mõjutatud andmebaasidest varukoopiad. Vajadusel looge dump käsuga:

mysqldump -u [user] -p [database_name] > /path/to/file/dump.sql

  • Asendage [user] MySQLi kasutajanimega.

  • Asendage [database_name] eksporditava andmebaasi nimega.

  • /path/to/dump.sql on tee, kuhu dump-fail salvestatakse

Pärast seda käivitage veaparandusprotseduur mysqlcheck-iga:

mysqlcheck -A --auto-repair -c
  1. Võtke ühendust oma hostingu pakkuja toega.

Kui te ei suuda probleemi tuvastada, tasub ühendust võtta oma hostingu pakkuja toega. See võib aidata tuvastada serveripoolseid probleeme, mis pole kasutaja tasandil nähtavad. Selles artiklis saate teada, kuidas valida õige hostingu pakkuja.

Kokkuvõte​

500 viga ei ole teie veebisaidi lõpparve. Põhiliste diagnostikatööriistade abil saate kiiresti tuvastada põhjuse ja probleemi lahendada. Kui te pole oma võimetes kindel, võite alati pöörduda spetsialistide poole. Oluline on meeles pidada, et õigeaegselt leitud ja parandatud 500 viga aitab teil tulevikus vältida tõsisemaid probleeme.