Valkoinen ruutu. Viisi numeroa: 500. Ei hallintapaneelia, ei sivustoa, ei vihjettä syystä. Kuulostaako tutulta?

WordPressin sisäinen palvelinvirhe 500 on kaikista virheistä hiljaisin. Se ei kerro, mikä tarkalleen hajosi, mikä vain pahentaa paniikkia. Mutta todellisuus on arkisempi: 9 tapauksessa 10:stä syyllinen on lisäosa, teema tai yksi väärin muotoiltu rivi .htaccess-tiedostossa. Palvelin ei ole mennyt sekaisin; se yksinkertaisesti kohtasi koodia, jota se ei pysty suorittamaan.

Puretaan kolme pääskenaariota ja korjataan jokainen askel askeleelta. Ei paniikkia, ei soittoa palveluntarjoajalle kolmelta aamuyöllä. Omin käsin, 15 minuutissa.

💡 Pikaopas:

• Poista kaikki lisäosat kerralla käytöstä nimeämällä plugins-kansio uudelleen FTP:n kautta; jos virhe katoaa, syyllinen on niiden joukossa
• Palauta .htaccess vakio-WordPress-pohjaan: rikkinäinen välimuisti- tai uudelleenohjausdirektiivi voi kaataa sivustosi välittömästi
• Ota WP_DEBUG käyttöön wp-config.php-tiedostossa nähdäksesi tarkan tiedoston ja rivin, jossa kohtalokas virhe tapahtuu
• Jos sivustosi on juuri siirretty uudelle palveluntarjoajalle, tarkista PHP-versio: WordPress vaatii vuodesta 2026 alkaen PHP 8.3:n tai uudemman, ja vanhat lisäosat ovat usein yhteensopimattomia

HTTP-vastauskoodit: mitä palvelin yrittää kertoa sinulle

Ennen kuin sukellat vianetsintään, auttaa ymmärtää HTTP-vastausten perusteet. Palvelin vastaa selaimelle aina kolminumeroisella koodilla, ja ensimmäinen numero kertoo jo, mistä ongelmaa kannattaa etsiä.

• 1xx, tiedottava: "yhteyttä muodostetaan, odota hetki." Näillä ei ole mitään tekemistä virheiden kanssa.
• 2xx, onnistuminen. Kuuluisa 200 OK tarkoittaa, että palvelin toimitti sivun ongelmitta.
• 3xx, uudelleenohjaukset. Esimerkiksi 301 (pysyvä uudelleenohjaus) tai 307 (väliaikainen). Selain siirtyy uuteen osoitteeseen äänettömästi; tämä on komento, ei virhe.
• 4xx, asiakaspään virhe. 404 Not Found tarkoittaa, että sivu on poistettu tai URL on kirjoitettu väärin. Palvelin on toiminnassa; sisältöä ei yksinkertaisesti ole olemassa.
• 5xx, palvelinpään virhe. Täältä meidän alueemme alkaa.

5xx-koodien joukossa on kolme pää"potilasta": 503 Service Unavailable (palvelin on ylikuormittunut; korjaa välimuistituksella tai päivittämällä tehokkaampaan palvelupakettiin), 502 Bad Gateway (PHP-FPM kaatui tai menetti yhteyden verkkopalvelimeen; konfiguraatio-ongelma) ja lopulta **500 **Internal Server Error, kaikkein yleisluontoisin ja siksi petollisin. Siitä me keskustelemme.

Kolme virheen 500 pääsyytä ja vaiheittaiset korjaukset

Virhe 500 ei ole mystinen; se on vain yleisluontoinen. Palvelin sanoo: "En pystynyt suorittamaan koodia, mutta en kerro mitä." Diagnoosi tarkoittaa kolmen vakioepäillyn järjestelmällistä läpikäyntiä.

1. PHP-version yhteensopimattomuus sivustoa siirrettäessä

Klassinen skenaario: siirsit sivustosi vanhalta palveluntarjoajalta, jossa oli PHP 7.4, uudelle, jossa on PHP 8.3 tai 8.4. Ja sait välittömästi valkoisen ruudun.

Syy on yksinkertainen: vanha lisäosa tai teema käyttää funktioita, jotka on poistettu käytöstä tai poistettu kokonaan uudemmissa PHP-versioissa. Tulkki kieltäytyy suorittamasta niitä, ja sivusto kaatuu.

Kuinka korjata. Tee täydellinen varmuuskopio wp-content/plugins/- ja wp-content/themes/-kansioista. Nimeä sitten plugins-kansio uudelleen muotoon plugins_old FTP:n tai palveluntarjoajasi tiedostonhallinnan kautta; tämä poistaa kaikki lisäosat välittömästi käytöstä kerralla. Katosiko virhe? Syyllinen on lisäosien joukossa. Palauta ne yksi kerrallaan ja tarkista sivusto joka kerta. Se, jonka jälkeen 500-virhe palaa, on ongelma.

Sama logiikka pätee teemoihin: vaihda vakio-WordPress-teemaan (Twenty Twenty-Five tai uudempi). Heräsikö sivusto henkiin? Ongelma on teemassasi; päivitä tai vaihda se.

Tämä skenaario ilmenee useimmiten siirrettäessä sivustoa palveluntarjoajien välillä, joilla on eri PHP-versiot. Useimmat palveluntarjoajat eivät enää tarjoa PHP 7.x:ää hallintapaneeleissaan, ja WordPressin vähimmäisvaatimukset vuodesta 2026 alkaen alkavat PHP 8.3:sta. Vanha koodi ilman päivityksiä on tuhoon tuomittu siinä ympäristössä.

2. Vioittunut.htaccess, näkymätön tappaja

Määritit välimuistilisäosan, otit uudelleenohjaukset käyttöön tai lisäsit omia sääntöjäsi .htaccess-tiedostoon, ja sivusto meni nurin. Välittömästi ja ilman varoitusta.

.htaccess-tiedosto (Apache) ohjaa verkkopalvelinta lennosta: direktiivi kirjoitetaan, direktiivi suoritetaan. Yksi syntaksivirhe, väärä lippu tai sääntöristiriita, ja koko sivusto vastaa 500:lla.

Kuinka korjata. Yhdistä sivustollesi FTP:n kautta tai palveluntarjoajasi tiedostonhallinnan kautta. Etsi .htaccess juurikansiosta (public_html, www tai htdocs). Kopioi sen sisältö tekstitiedostoon varmuuskopioksi. Korvaa sitten kaikki vakio-WordPress-pohjalla:

1
 # BEGIN WordPress
2
 
3
<IfModule mod_rewrite.c>
4
RewriteEngine On
5
RewriteBase /
6
RewriteRule ^index\.php$ - [L]
7
RewriteCond %{REQUEST_FILENAME} !-f
8
RewriteCond %{REQUEST_FILENAME} !-d
9
RewriteRule . /index.php [L]
10
</IfModule>
11
 
12
 # END WordPress

Tämä koodi palauttaa vakio-URL-uudelleenkirjoitussäännöt (kauniit permalinkit) ja poistaa kaiken ylimääräisen. Sivuston pitäisi herätä henkiin välittömästi. Voit määrittää lisäosasi uudelleen jälkikäteen, mutta nyt tiedät, mistä etsiä, jos jokin menee pieleen.

Eikö auttanut? Palauta vanha .htaccess varmuuskopiostasi ja siirry seuraavaan vaiheeseen. Nginx-palvelimella .htaccess ei toimi; tarkista lokit osoitteesta /var/log/nginx/error.log, ongelma on palvelinlohkon konfiguraatiossa.

3. Kohtalokas virhe PHP-koodissa

Lisäosa tai teema kutsuu funktiota, jota ei ole olemassa, antaa väärän argumenttityypin tai viittaa olemattomaan luokkaan. PHP pysäyttää suorituksen, ja kohtaat saman 500:n.

Ilman virheenkorjaustietoja arvaat sokkona. Onneksi WordPress voi näyttää virheet; sinun tarvitsee vain ottaa virheenkorjaustila käyttöön.

WP_DEBUGin käyttöönotto

Avaa wp-config.php-tiedosto sivustosi juuressa. Etsi rivi:

1
define( 'WP_DEBUG', false );

Korvaa false arvolla true. Jos tätä riviä ei ole, lisää se ennen /* That's all, stop editing! */:

1
define( 'WP_DEBUG', true );

Tallennuksen jälkeen päivitä sivu. Valkoisen ruudun sijaan näet viestin, kuten:

1
Fatal error: Call to undefined function wpsupercache_gc() in
2
/home/user/public_html/wp-content/plugins/wp-super-cache/wp-cache.php on line 342

Virhe näyttää: ongelman tyypin (undefined function), virheen aiheuttaneen tiedoston (wp-cache.php) ja rivin (342). Tämä on suora osoitus lisäosaan, joka aiheutti kaatumisen. Poista se käytöstä nimeämällä lisäosan kansio uudelleen, ja sivusto toimii taas. Päivitä sitten lisäosa, etsi korvaava tai ota yhteyttä kehittäjään.

Muista asettaa WP_DEBUG takaisin arvoon false diagnoosin jälkeen. Julkisella sivustolla virheiden näyttäminen kävijöille on tarpeetonta ja voi paljastaa palvelimen sisäisiä polkuja. Jos haluat kerätä lokeja näyttämättä niitä ruudulla, lisää nämä rivit wp-config.php-tiedostoon: define( 'WP_DEBUG_LOG', true ); ja define( 'WP_DEBUG_DISPLAY', false );. Virheet kirjoitetaan tiedostoon wp-content/debug.log.

⁉️🤔 Usein kysytyt kysymykset

Voinko vain käynnistää palvelimen uudelleen poistaakseni virheen 500?

Et. Toisin kuin 503, joka usein häviää uudelleenkäynnistyksen jälkeen (kun kuormitushuippu helpottaa), virheen 500 aiheuttaa ongelma koodissa. Palvelimen uudelleenkäynnistys ei korjaa sitä: käynnistyksen jälkeen sivusto törmää samaan rikkinäiseen koodiin ja kaatuu uudelleen.

Kuinka määritän, onko syyllinen lisäosa vai teema, jos hallintapaneeliin ei pääse?

Yhdistä FTP:n kautta tai palveluntarjoajasi tiedostonhallinnan kautta. Nimeä wp-content/plugins-kansio uudelleen; tämä poistaa kaikki lisäosat välittömästi käytöstä. Heräsikö sivusto henkiin? Ongelma on lisäosissa. Jos ei, nimeä aktiivisen teeman kansio uudelleen wp-content/themes-kansiossa. WordPress vaihtaa automaattisesti oletusteemaan. Heräsikö henkiin? Ongelma on teemassa.

Täytyykö WP_DEBUG ottaa käyttöön julkisella sivustolla?

Ei, toimivalla sivustolla WP_DEBUG tulisi olla pois päältä (false). Ota se käyttöön vain diagnoosin aikana ja sammuta se välittömästi sen jälkeen. Jatkuvaan virheiden keräämiseen näyttämättä niitä kävijöille käytä yhdistelmää WP_DEBUG_LOG (kirjoittaa tiedostoon wp-content/debug.log) ja WP_DEBUG_DISPLAY (poistaa ruututulostuksen käytöstä).

Entä jos mikään kolmesta menetelmästä ei auttanut?

Tarkista PHP:n muistiraja (memory_limit php.ini-tiedostossa). Joskus skripteillä ei ole tarpeeksi varattuja megatavuja ja ne kaatuvat 500:lla. Nosta se arvoon 256M tai 512M. Jos sekään ei auta, ota yhteyttä palveluntarjoajasi tukeen: pyydä heitä tarkistamaan palvelimen virhelokit (error_log Apachelle/Nginxille). Tarkka syy löytyy sieltä, mitä et näe WordPressin puolelta.

Sivustoni on Nginx-palvelimella; mitä teen.htaccessille?

Nginx ei käytä .htaccess-tiedostoa. Uudelleenkirjoitussäännöt määritetään palvelinlohkon konfiguraatiossa (nginx.conf tai sites-available/your-site). Jos olet Nginx-palvelimella ja sait 500:n, tarkista lokit osoitteesta /var/log/nginx/error.log. Virheellinen .htaccess Nginx-palvelimella ei aiheuta ongelmia; se yksinkertaisesti ohitetaan.

Kuinka estän virheen 500 tulevaisuudessa?

Kolme sääntöä ennaltaehkäisyyn. Ensimmäinen: päivitä lisäosat, teemat ja WordPress-ydin säännöllisesti (joka kuukausi, ei kerran vuodessa). Toinen: älä roiku hylätyissä laajennuksissa; jos lisäosaa ei ole päivitetty yli vuoteen, etsi elävä korvaaja. Kolmas: ennen minkään lisäosan asentamista tarkista viimeisin päivityspäivämäärä ja yhteensopivuus PHP-versiosi kanssa lisäosan sivulla WordPress-hakemistossa. Kymmenen minuuttia ylläpitoa kuukaudessa säästää tunteja hätädebuggausta.

Mitä tehdä juuri nyt, jos sivustosi on nurin 500:n takia

Virhe 500 on palapeli, jolla on ennustettava ratkaisu. Valtaosassa tapauksista korjaat sivuston viidessätoista minuutissa käymällä läpi kolme vaihetta oikeassa järjestyksessä: poista lisäosat käytöstä, nollaa .htaccess, ota WP_DEBUG käyttöön. Järjestyksellä on väliä: todennäköisimmästä ja nopeimmasta yksityiskohtaisimpaan.

Jos siirsit sivuston uudelle palveluntarjoajalle, aloita PHP:n tarkistamisesta. Jos määritit välimuistituksen tai uudelleenohjaukset, aloita .htaccess-tiedostosta. Jos päivitit lisäosia ja sivusto kaatui, aloita WP_DEBUG-tilasta. Ja jos et tehnyt vielä mitään, mutta 500 ilmestyi itsestään, käy kaikki kolme vaihetta läpi järjestyksessä; yksi niistä melkein varmasti toimii.

Älä viivyttele diagnoosin kanssa: jokainen minuutti sivuston käyttökatkosta tarkoittaa menetettyjä kävijöitä ja hakusijoituksia. Avaa FTP, tee varmuuskopio ja aloita.