Праблемы з падзеннем сайта: памылкі сервера (500, 502, 504) і іх вырашэнне

Праблемы з падзеннем сайта звычайна ўзнікаюць, калі сервер не можа апрацаваць запыт, прамежкавыя ўзроўні не атрымліваюць карэктнага адказу або адбываецца перавышэнне часу чакання. Памылка 500 часцей за ўсё паказвае на агульную ўнутраную памылку, выкліканую праграмай або канфігурацыяй сервера; памылка 502 сігналізуе, што проксі-сервер або шлюз атрымаў несапраўдны адказ ад унутранага сэрвісу; а памылка 504 паведамляе, што ўнутраны сэрвіс не адказаў своечасова. Для доўгатэрміновага вырашэння неабходна правільна інтэрпрэтаваць код памылкі, аналізаваць серверныя логі, вымяраць спажыванне рэсурсаў, адладжваць памылкі PHP/прыкладання, ліквідаваць вузкія месцы ў базе дадзеных і маштабаваць інфраструктуру хостынгу ў адпаведнасці з патрэбамі трафіку.

Для наведвальніка гэтыя памылкі азначаюць толькі пустую старонку або недаступны сайт; для бізнесу ж гэта страчаныя продажы, падзенне даверу і паслабленне SEO-сігналаў. Асабліва ў праектах з нізкай талерантнасцю да прастояў, такіх як электронная камерцыя, карпаратыўныя сайты, навінавыя парталы або сістэмы браніравання, памылкі 5xx могуць ператварыцца ў страту прыбытку за лічаныя хвіліны. У гэтым кіраўніцтве мы крок за крокам разгледзім, як адрозніваць памылкі 500, 502 і 504, праводзіць хуткую дыягностыку і прымаць практычныя меры для прадухілення іх паўтарэння.

Чаму праблемы з падзеннем сайта трэба ўспрымаць сур'ёзна?

Падзенне сайта — гэта не проста тэхнічны збой. Яно напрамую ўплывае на карыстальніцкі досвед, каэфіцыент канверсіі, успрыманне брэнда і бачнасць у пошукавых сістэмах. Google звычайна памяркоўна ставіцца да кароткачасовых перабояў, але паўтаральныя памылкі 5xx могуць прывесці да марнавання краўлінгавага бюджэту, больш рэдкага сканавання важных старонак і ваганняў у рэйтынгу.

На практыцы памылкі 5xx варта разглядаць на двух розных узроўнях. Першы — гэта экстранае ўмяшанне: аднаўленне доступу да сайта. Другі — аналіз першапрычыны: высвятленне, чаму тая ж памылка паўтараецца падчас высокага трафіку, пры выкананні cron-задач, пасля абнаўлення плагіна або пры павелічэнні нагрузкі на базу дадзеных. Просты перазапуск сэрвісу часам дае часовае палягчэнне, але калі асноўная праблема не вырашана, памылка можа вярнуцца праз некалькі гадзін.

Напрыклад, калі ў момант акцыі ў інтэрнэт-краме на WooCommerce выкарыстанне працэсара дасягае 95%, чарга PHP-FPM перапаўняецца, а база дадзеных блакуецца з-за павольных запытаў, наведвальнікі могуць убачыць памылку 500 або 504. У такім выпадку простай усталёўкі плагіна кэшавання можа быць недастаткова; неабходны комплексны падыход: аптымізацыя запытаў, больш магутны тарыфны план хостынгу, CDN, аб'ектнае кэшаванне і перагляд лімітаў рэсурсаў. Вывучаючы прыдатныя варыянты размяшчэння для праектаў, якія растуць, можна параўнаць Hostragons пакеты веб-хостынгу і для праектаў з больш высокімі патрабаваннямі да рэсурсаў — Hostragons Серверныя рашэнні VPS.

Асноўныя адрозненні паміж памылкамі 500, 502 і 504

Хоць 500, 502 і 504 належаць да аднаго сямейства 5xx, яны абазначаюць розныя рэчы. Няправільная дыягностыка вядзе да няправільнага ўмяшання. Табліца ніжэй коратка абагульняе найбольш распаўсюджаныя адрозненні.

Гэтае размежаванне асабліва важнае ў канфігурацыях, дзе выкарыстоўваюцца Nginx, Apache, LiteSpeed, PHP-FPM, Node.js, зваротны проксі, CDN і балансіроўшчыкі нагрузкі. Калі карыстальнік бачыць у браўзеры памылку 502, рэальнай праблемай можа быць падзенне сэрвісу PHP-FPM. Аналагічна, памылка 504 можа быць выклікана не вэб-серверам, а тым, што знешні плацежны API адказвае больш за 30 секунд.

500 Internal Server Error: Прычыны і крокі па вырашэнні

Што азначае памылка 500?

500 Internal Server Error паказвае, што сервер не змог апрацаваць запыт, але не можа растлумачыць памылку больш канкрэтным кодам. Таму памылка 500 мае шырокі спектр патэнцыйных прычын. Яна можа ўзнікаць у розных асяроддзях — WordPress, Laravel, уласных PHP-распрацоўках, Python ці Node.js праектах — па розных прычынах. Паколькі паведамленне пра памылку дае карыстальніку абмежаваную інфармацыю, асноўныя падказкі змяшчаюцца ў лог-файлах.

Найбольш распаўсюджаныя прычыны памылкі 500

• Памылковыя правілы .htaccess: Няправільны RewriteRule, бясконцыя перанакіраванні або непадтрымліваныя дырэктывы могуць выклікаць памылку 500.
• Фатальная памылка PHP: Адсутная функцыя, несумяшчальная версія PHP, перавышэнне ліміту памяці або памылковая тэма/плагін могуць спыніць працу сайта.
• Правы доступу да файлаў і тэчак: Праца PHP-файлаў з небяспечнымі або няправільнымі правамі, такімі як 777, можа быць заблакавана серверам.
• Адсутныя залежнасці: Могуць быць адсутнымі пакеты Composer, модулі PHP або файлы кэша фрэймворка.
• Ліміты рэсурсаў сервера: Перавышэнне лімітаў CPU, RAM, entry process або I/O можа прывесці да перапынення апрацоўкі запыту.

Як выправіць памылку 500?

Перш за ўсё, без панікі складзіце храналогію змен. Калі памылка пачалася пасля абнаўлення плагіна, рэдагавання тэмы, змены версіі PHP, новага правіла .htaccess або перыяду высокага трафіку, кола пошуку першапрычыны звужаецца. Затым выканайце наступныя крокі:

• 1. Праверце логі: У cPanel, Plesk або вашай панэлі сервера вывучыце файл error_log. Радкі накшталт Fatal error, memory exhausted, permission denied або syntax error даюць прамую падказку.
• 2. Адкаціце апошнюю змену: Адключыце нядаўна ўсталяваны плагін, тэму або фрагмент кода. Для WordPress часовае перайменаванне тэчкі плагіна дазваляе хутка праверыць гіпотэзу.
• 3. Пратэстуйце файл .htaccess: Часова захавайце файл пад іншай назвай і стварыце правілы па змаўчанні. Калі памылка знікне, праблема была ў правілах перанакіравання або rewrite.
• 4. Праверце версію і ліміты PHP: Калі ваша прыкладанне несумяшчальнае з PHP 8.2, гэта можа выклікаць памылку 500. Збалансуйце значэнні memory_limit, max_execution_time і post_max_size ў адпаведнасці з патрэбамі праекта.
• 5. Выпраўце правы доступу: У якасці агульнай практыкі выкарыстоўваюцца правы 755 для тэчак і 644 для файлаў. Для спецыфічных патрэб прытрымлівайцеся інструкцый вашага хостынг-правайдэра.
• 6. Сплануйце вяртанне з рэзервовай копіі: Калі жывы сайт цалкам недаступны, вяртанне да апошняй спраўнай копіі можа аднавіць сэрвіс да правядзення аналізу першапрычыны. У гэты момант рэгулярнае рэзервовае капіраванне мае крытычнае значэнне.

Калі памылка 500 часта паўтараецца, недастаткова засяродзіцца толькі на ўзроўні прыкладання. Неабходна вывучыць такія паказчыкі, як колькасць адначасова запушчаных працэсаў PHP, сярэдняе спажыванне памяці, колькасць злучэнняў з базай дадзеных, наяўнасць затрымак дыскавага I/O. Асабліва ў асяроддзях агульнага хостынгу ліміты рэсурсаў могуць не паспяваць за хуткасцю росту сайта. У такіх сітуацыях варта разгледзець Hostragons WordPress хостынг або пакеты, якія прапануюць больш ізаляваныя рэсурсы.

502 Bad Gateway: Разуменне памылак проксі і ўнутраных сэрвісаў

Што азначае памылка 502?

502 Bad Gateway паказвае, што шлюз або проксі-ўзровень паміж кліентам і ўнутраным сэрвісам не атрымаў сапраўднага адказу. У сучасных архітэктурах хостынгу Nginx часта працуе як зваротны проксі, накіроўваючы PHP-запыты да PHP-FPM, а запыты Node.js — да порта прыкладання або іншага ўнутранага сэрвісу. Калі любы з сэрвісаў у гэтым ланцужку не працуе, перагружаны або накіраваны на няправільны порт, можа ўзнікнуць памылка 502.

Тыповыя прычыны памылкі 502

• Спыненне сэрвісу PHP-FPM або немагчымасць доступу да файла сокета.
• Прыкладанне Node.js, Python або Java не запушчана на чаканым порце.
• Выкарыстанне памылковага IP-адрасу, порта або шляху да сокета ў канфігурацыі upstream Nginx.
• CDN або брандмаўэр не могуць атрымаць чаканы адказ ад сервера-крыніцы.
• Запаўненне аператыўнай памяці сервера і прымусовае завяршэнне працэсаў, што прыводзіць да падзення ўнутраных сэрвісаў.

Практычны план вырашэння памылкі 502

Пры памылцы 502 першачарговая мэта — вызначыць, які ўзровень у ланцужку не адказвае. Наступная паслядоўнасць з'яўляецца адным з падыходаў, які дае найхутчэйшы вынік у рэальных працэсах падтрымкі:

• Праверце стан сэрвісаў: Пераканайцеся, што PHP-FPM, вэб-сервер, база дадзеных і сэрвісы прыкладання запушчаны. На VPS або выдзеленым серверы можна выкарыстоўваць каманды systemctl status.
• Параўнайце логі upstream: Вывучыце лог памылак Nginx і логі PHP-FPM або прыкладання за адзін і той жа часавы прамежак. Фразы накшталт Connection refused, upstream prematurely closed connection або no live upstreams з'яўляюцца крытычнымі падказкамі.
• Праверце выкарыстанне рэсурсаў: Калі RAM запаўняецца больш чым на 90% і інтэнсіўна выкарыстоўваецца swap, сэрвісы могуць не адказваць. Значэнне нагрузкі на працэсар (load average), якое значна перавышае колькасць ядраў, таксама стварае чаргу.
• Праверце налады сокетаў і партоў: Калі канфігурацыя Nginx накіравана на адрас 127.0.0.1:9000, а PHP-FPM слухае іншы сокет, памылка 502 непазбежная.
• Пратэстуйце ўзровень CDN: Часова абмініце CDN і звярніцеся напрамую да сервера-крыніцы. Калі праблема бачная толькі праз CDN, варта праверыць налады DNS, SSL або злучэння з крыніцай.

Часам на памылку 502 уплывае канфігурацыя SSL. Калі паміж CDN і серверам-крыніцай выкарыстоўваецца HTTPS, але сертыфікат крыніцы пратэрмінаваны або выдадзены на няправільнае даменнае імя, могуць узнікаць памылкі шлюза. Для бяспечнай і правільнай канфігурацыі ўзроўню SSL можна азнаёміцца з варыянтамі на старонцы Hostragons SSL сертыфікаты і Кіраўніцтва па ўсталёўцы сертыфіката SSL.

504 Gateway Timeout: Канчатковае вырашэнне праблем з тайм-аўтам

Што азначае памылка 504?

504 Gateway Timeout паказвае, што проксі або шлюз не атрымаў адказ ад унутранага сэрвісу на працягу вызначанага часу. У гэтым выпадку сэрвіс не абавязкова цалкам не працуе; ён можа проста адказваць вельмі павольна. Такім чынам, памылка 504 часцей за ўсё паказвае на праблемы з прадукцыйнасцю, базай дадзеных, знешнімі API або працяглымі аперацыямі.

Частыя прычыны памылкі 504

• Павольныя запыты да базы дадзеных: Адсутнасць індэксаў, поўнае сканаванне вялікіх табліц або блакіроўкі павялічваюць час водгуку.
• Затрымкі знешніх API: Калі плацежныя, кур'ерскія, CRM або складскія сэрвісы адказваюць павольна, вэб-запыт можа заставацца ў чаканні.
• Сеткавая затрымка: Калі прыкладанне і база дадзеных размешчаны ў розных лакацыях, затрымка становіцца крытычнай.
• Працяглыя cron-задачы або імпарт: Імпарт CSV, масавая рассылка імэйлаў або працэсы фарміравання справаздач могуць запавольваць апрацоўку жывых запытаў.
• Неадэкватныя налады тайм-аўтаў: Значэнні тайм-аўтаў у Nginx, Apache, PHP-FPM і прыкладанні могуць быць несумяшчальнымі адно з адным.

Як ліквідаваць памылку 504?

Пры памылцы 504 простае павелічэнне значэнняў тайм-аўтаў часта толькі хавае сімптом. Напрыклад, калі дазволіць запыту, які не выконваецца за 30 секунд, чакаць 120 секунд, гэта можа паменшыць колькасць памылак, але не палепшыць карыстальніцкі досвед. Правільны падыход — вымераць вузкае месца і паскорыць яго.

• 1. Прааналізуйце расклад часу водгуку: Асобна вымерайце час выканання прыкладання, час запыту да базы дадзеных, час знешняга API і час чакання сервера.
• 2. Уключыце лог павольных запытаў: У MySQL або MariaDB запісвайце запыты, якія выконваюцца даўжэй за 1 секунду. Дадайце індэксы да часта паўтаральных павольных запытаў або змяніце структуру запыту.
• 3. Перанясіце цяжкія задачы ў фонавы рэжым: Такія задачы, як генерацыя справаздач, апрацоўка відарысаў, адпраўка пошты і сінхранізацыя склада, павінны выконвацца ў фонавым рэжыме праз сістэму чэргаў.
• 4. Выкарыстоўвайце кэшаванне: Кэшаванне старонак, аб'ектнае кэшаванне і OPcache значна зніжаюць вылічальную нагрузку ў дынамічных прыкладаннях.
• 5. Узгодніце значэнні тайм-аўтаў: Значэнні proxy_read_timeout, fastcgi_read_timeout, max_execution_time і тайм-аўты прыкладання не павінны супярэчыць адно аднаму.
• 6. Усталюйце абмежаванні для знешніх API: Не прымушайце запыт карыстальніка чакаць бясконца, калі адказ ад API не прыходзіць. Выкарыстоўвайце стратэгіі паўторных спроб, fallback і кароткіх тайм-аўтаў.

У рэальным сцэнары, калі старонка спісу тавараў фільтруе 60 тысяч запісаў, а ў полі катэгорыі няма індэкса, падчас высокага акцыйнага трафіку могуць узнікаць памылкі 504. Даданне індэкса, кэшаванне вынікаў фільтрацыі і аптымізацыя цяжкіх запытаў могуць вырашыць праблему нават без павелічэння рэсурсаў. Аднак калі рост трафіку мае пастаянны характар, можа спатрэбіцца маштабаванне рэсурсаў.

Кантрольны спіс з 10 крокаў для хуткай дыягностыкі

Калі сайт раптам падае, хаатычнае ўмяшанне прыводзіць да страты часу. Наступны кантрольны спіс можна выкарыстоўваць для сістэматычнага вырашэння памылак 500, 502 і 504:

• 1. Праверце, ці закранае памылка ўсіх ці толькі вас: Пратэстуйце з розных сетак, праз мабільнае злучэнне і з дапамогай знешніх інструментаў маніторынгу даступнасці.
• 2. Праверце HTTP-код стану: Выкарыстоўвайце інструменты распрацоўшчыка браўзера або каманду накшталт curl -I https://vashdomen.by, каб убачыць рэальны код.
• 3. Складзіце спіс апошніх змен: Ці было разгортванне кода, абнаўленне плагіна, змена DNS, абнаўленне SSL, змена версіі PHP або налад сервера?
• 4. Праверце логі вэб-сервера: Логі памылак Apache, Nginx або LiteSpeed — гэта першая крыніца для аналізу.
• 5. Вывучыце логі прыкладання: Лог адладкі WordPress, логі сховішча Laravel або логі працэсаў Node.js паказваюць на крыніцу памылкі.
• 6. Вымярайце рэсурсы сервера: Неабходна адначасова ацаніць CPU, RAM, дыскавую прастору, inode, дыскавы I/O і колькасць злучэнняў.
• 7. Праверце базу дадзеных: Ці вычарпаны ліміт злучэнняў, ці ёсць заблакіраваныя запыты, ці павялічылася колькасць павольных запытаў?
• 8. Пратэстуйце брандмаўэр і CDN: Правілы WAF, бот-фільтры або злучэнне CDN з серверам-крыніцай могуць працаваць няправільна.
• 9. Трымайце рэзервовую копію напагатове: Калі крытычны файл пашкоджаны або абнаўленне прайшло з памылкай, у вас павінен быць план хуткага аднаўлення.
• 10. Стварыце справаздачу аб першапрычыне: Пасля ліквідацыі памылкі задакументуйце час, уплыў, прычыну, рашэнне і крокі для прадухілення паўтарэння.

Гэты спіс асабліва каштоўны для размеркавання адказнасці ўнутры каманды. Калі вы звяртаецеся да вашага хостынг-правайдэра, паведамленне часу ўзнікнення памылкі, прыкладу URL, кода памылкі, пераліку апошніх змен і, па магчымасці, скрыншота скарачае час вырашэння. Для праблем з доступам, звязаных з даменным імем, DNS і маршрутызацыяй, такія рэсурсы, як Hostragons праверка дамена і рэгістрацыя і Паводле кіраўніцтва па кіраванню DNS, таксама дапамагаюць у працэсе дыягностыкі.

Правільны аналіз рэсурсаў сервера

Значная частка памылак 5xx звязана з вузкімі месцамі ў рэсурсах. Аднак высокае выкарыстанне CPU не заўсёды азначае дрэнны код; часам сістэму перагружаюць непрадбачана высокі арганічны трафік, бот-атака, памылковыя cron-задачы або працэс рэзервовага капіравання. Таму важна аналізаваць паказчыкі не асобна, а ў прывязцы да часавай шкалы.

Асноўныя паказчыкі для маніторынгу

• Выкарыстанне CPU: Пастаянная нагрузка вышэй за 80% павялічвае рызыку чэргаў і затрымак.
• RAM і swap: Калі выкарыстанне swap расце, працэсы запавольваюцца, што можа справакаваць памылкі 502 і 504.
• Дыскавы I/O: Асабліва інтэнсіўны запіс логаў, вялікія рэзервовыя копіі або аперацыі з базай дадзеных могуць выклікаць чаканне I/O.
• Entry process і concurrent connection: У асяроддзях агульнага хостынгу ліміты адначасовых працэсаў могуць прыводзіць да памылкі 500.
• Злучэнні з базай дадзеных: Набліжэнне да ліміту max_connections павялічвае колькасць памылак прыкладання.
• TTFB: Рэгулярнае павелічэнне часу да першага байта з'яўляецца раннім папярэджаннем перад узнікненнем памылкі 504.

Вы можаце выкарыстоўваць просты парогавы падыход: калі ў звычайны час TTFB знаходзіцца ў дыяпазоне 300-600 мс, а падчас акцыі павялічваецца да 5-10 секунд, варта планаваць павелічэнне магутнасці да таго, як з'явяцца памылкі. Сумеснае выкарыстанне маніторынгу даступнасці, аналізу логаў і замеру прадукцыйнасці дазваляе выявіць праблему да яе ўскладнення.

Пастаянныя меры на ўзроўні прыкладання, базы дадзеных і хостынгу

Што рабіць на баку прыкладання

Якасць кода і яго актуальнасць — гэта самы магутны ўзровень абароны ад праблем з падзеннем сайта. Выдаляйце нявыкарыстоўваемыя плагіны, выбірайце тэмы і плагіны з надзейных крыніц, правярайце сумяшчальнасць з версіяй PHP у тэставым асяроддзі. Выкарыстанне асяроддзя для тэсціравання (staging) замест унясення змен непасрэдна на жывы сайт дазваляе злавіць памылкі 500 да таго, як яны паўплываюць на карыстальнікаў.

• Не паказвайце адладачную інфармацыю карыстальнікам на жывым сайце, а пішыце яе ў лог-файл.
• Рабіце поўную рэзервовую копію файлаў і базы дадзеных перад любым абнаўленнем.
• Аддзяляйце працяглыя аперацыі ад запытаў карыстальнікаў.
• Аптымізуйце відарысы і памяншайце нагрузку ад непатрэбных скрыптоў.
• Аналізуйце бот-трафік; абмяжоўвайце шкоднасных або празмерна актыўных ботаў з дапамогай WAF.

Што рабіць на баку базы дадзеных

Прадукцыйнасць базы дадзеных адыгрывае крытычную ролю, асабліва ў сістэмах на базе WordPress, WooCommerce, форумаў і сайтаў з членствам. На сайтах з тысячамі тавараў, заказаў, каментароў або лог-запісаў разрастанне табліц можа павялічыць колькасць павольных запытаў. Рэгулярнае абслугоўванне, кантроль індэксаў і ачыстка непатрэбных запісаў зніжаюць рызыку ўзнікнення памылкі 504.

• Знаходзьце самыя "дарагія" запыты з дапамогай лога павольных запытаў.
• Дадавайце правільныя індэксы да слупкоў, па якіх часта адбываецца фільтрацыя.
• Ачышчайце аўтаматычна загружаныя непатрэбныя опцыі.
• Перыядычна архівуйце старыя рэвізіі, часовыя запісы і лог-табліцы.
• Запускайце рэзервовае капіраванне базы дадзеных у гадзіны нізкай прадукцыйнасці.

Што рабіць на баку хостынгу

Калі інфраструктура хостынгу выбрана няправільна, нават добра аптымізаваны сайт можа не вытрымаць высокага трафіку. Патрэбы ў рэсурсах у пачатковага карпаратыўнага сайта і ў высоканагружанага інтэрнэт-магазіна неаднолькавыя. Трафік, колькасць транзакцый, доля дынамічных старонак, выкарыстанне электроннай пошты, памер базы дадзеных і патрэбы бяспекі павінны ацэньвацца комплексна.

• Для невялікіх і сярэдніх сайтаў можа быць дастаткова простых у кіраванні пакетаў хостынгу.
• Для сайтаў з інтэнсіўнымі дынамічнымі аперацыямі больш стабільнай будзе праца на VPS з ізаляванымі CPU/RAM.
• У карпаратыўных праектах рэгулярнае рэзервовае капіраванне, SSL, WAF і маніторынг даступнасці павінны быць стандартам.
• DNS-запісы павінны быць простымі, варта пазбаўляцца ад непатрэбных ланцужкоў перанакіраванняў.
• Калі выкарыстоўваецца CDN, правілы кэшавання, сервер-крыніца і SSL павінны быць наладжаны правільна.

Пры гэтай ацэнцы арыентавацца толькі на аб'ём дыскавай прасторы памылкова. Сайт, які выкарыстоўвае 2 ГБ дыска, можа спажываць больш CPU, чым іншы сайт з 20 ГБ дадзеных, з-за высокай колькасці адначасовых карыстальнікаў. Таму выбар пакета павінен грунтавацца на рэальным трафіку і вылічальнай нагрузцы.

Што рабіць з SEO-пункту гледжання пры памылках 5xx?

Пошукавыя сістэмы не караюць адразу за часовыя памылкі 5xx, але паўтаральныя перабоі ўплываюць на эфектыўнасць сканавання і індэксацыі. Калі Googlebot часта атрымлівае адказы 500, 502 або 504 на важных старонках, ён можа знізіць частату іх наведвання. Акрамя таго, калі карыстальнікі пераходзяць на сайт з арганічнай выдачы і бачаць памылку, гэта прыводзіць да страты даверу і канверсіі.

Каб мінімізаваць SEO-рызыкі, выкарыстоўвайце маніторынг даступнасці для крытычных старонак, правярайце статыстыку сканавання ў Search Console, аналізуйце коды стану запытаў Googlebot у серверных логах. Калі плануецца тэхнічнае абслугоўванне, лепш выкарыстоўваць кароткачасовы і правільна наладжаны адказ 503 Service Unavailable, чым дапускаць незапланаваную памылку 500. Выкарыстанне загалоўка Retry-After на старонцы абслугоўвання дае пошукавым сістэмам зразумець, калі варта паўтарыць спробу.

Асабліва пры пераносе сайта, змене дамена або пераходзе на SSL памылковыя перанакіраванні і праблемы з сертыфікатамі могуць выклікаць праблемы з доступам, падобныя да 5xx. Зніжэнне DNS TTL перад пераносам, стварэнне рэзервовай копіі, тэсціраванне на тэставым дамене і маніторынг логаў пасля пераходу — гэта добрая стандартная працэдура.

Калі варта звяртацца ў падтрымку хостынгу?

Некаторыя памылкі можна вырашыць сіламі адміністратара сайта, але іншыя патрабуюць доступу да сервера і спецыяльных ведаў. У наступных сітуацыях варта неадкладна звярнуцца ў службу падтрымкі хостынгу:

• Памылка закранае ўвесь сайт, і доступ да панэлі кіравання таксама немагчымы.
• У логах бачныя радкі "permission denied", "upstream failed" або "resource limit exceeded".
• Сэрвісы PHP-FPM, вэб-сервер або база дадзеных пастаянна падаюць.
• Пры адключаным CDN сайт адкрываецца, а пры ўключаным узнікае памылка 502 або 504.
• Ліміты рэсурсаў часта вычэрпваюцца, і незразумела, які пакет абраць.
• Доступ парушыўся пасля змены SSL, DNS або брандмаўэра.

Дадаючы наступную інфармацыю пры стварэнні запыту ў падтрымку, вы значна скароціце час вырашэння: час пачатку памылкі, закранутыя URL-адрасы, бачны код памылкі, апошнія ўнесеныя змены, скрыншот, па магчымасці - радкі з логаў, а таксама інфармацыя аб тым, ці з'яўляецца памылка пастаяннай або перыядычнай. Гэтыя дадзеныя дапамагаюць тэхнічнай камандзе лягчэй узнавіць тую ж праблему і прааналізаваць патрэбны ўзровень.

Часта задаваныя пытанні

Ці азначае памылка 500, што мой сайт узламалі?

Не, сама па сабе памылка 500 не з'яўляецца прыкметай узлому. Часцей за ўсё яна выклікана памылкай PHP, канфліктам плагінаў, няправільным правілам .htaccess, правамі доступу да файла або лімітам рэсурсаў. Аднак калі памылка суправаджаецца нечаканымі зменамі файлаў, падазронымі перанакіраваннямі або невядомымі ўліковымі запісамі карыстальнікаў, варта правесці праверку бяспекі.

Ці можа памылка 502 Bad Gateway быць выклікана карыстальнікам?

Звычайна не. Памылка 502 часцей за ўсё паказвае на праблему ўзаемадзеяння на ўзроўні сервера, проксі, CDN або ўнутранага сэрвісу. Карыстальнік можа ачысціць кэш браўзера і праверыць з іншай сеткі, але калі памылка бачная ўсім, рашэнне трэба шукаць на баку сервера.

Ці дастаткова павялічыць значэнне тайм-аўту для памылкі 504 Gateway Timeout?

Часам гэта дае часовае палягчэнне, але не з'яўляецца канчатковым рашэннем. Пры памылцы 504 асноўная мэта — знайсці першапрычыну, такую як павольны запыт, затрымка знешняга API, інтэнсіўнае выкарыстанне CPU або працяглая аперацыя. Павелічэнне тайм-аўту павінна прымяняцца асцярожна і толькі ў спалучэнні з аптымізацыяй прадукцыйнасці.

Ці прывядуць памылкі 5xx да неадкладнага падзення маіх SEO-пазіцый?

Кароткачасовыя і рэдкія перабоі звычайна не выклікаюць пастаяннай страты пазіцый. Аднак калі памылкі 5xx часта паўтараюцца, важныя старонкі застаюцца недаступнымі на працяглы час, або Googlebot рэгулярна атрымлівае памылку сервера, гэта можа негатыўна паўплываць на частату сканавання і арганічную эфектыўнасць.

Якая самая важная звычка для прадухілення праблем з падзеннем сайта?

Самая важная звычка — гэта рэгулярны маніторынг і кіраванне зменамі. Сумеснае прымяненне адсочвання даступнасці, рэзервовага капіравання, праверкі логаў, тэсціравання ў staging-асяроддзі, выкарыстання актуальнага праграмнага забеспячэння і маніторынгу рэсурсных паказчыкаў дазваляе прадухіліць большасць памылак 500, 502 і 504 да таго, як яны стануць крытычнымі.

Кароткі вынік і наступны крок

Хоць памылкі 500, 502 і 504 належаць да аднаго сямейства, яны паказваюць на розныя ўзроўні: 500 — часцей за ўсё памылка прыкладання або канфігурацыі, 502 — праблема ўзаемадзеяння проксі і ўнутранага сэрвісу, 504 — тайм-аўт і вузкае месца прадукцыйнасці. Правільнае рашэнне заключаецца ў праверцы кода памылкі, чытанні логаў, вымярэнні рэсурсаў, аналізе апошніх змен і правядзенні пастаяннай аптымізацыі.

Калі на вашым сайце часта ўзнікаюць праблемы з падзеннем, будзе карысна комплексна ацаніць вашы бягучыя рэсурсы хостынгу, канфігурацыю SSL і DNS, а таксама прадукцыйнасць прыкладання. Каб вывучыць прыдатную для вашых патрэб інфраструктуру размяшчэння або ацаніць варыянты з тэхнічнай камандай, вы можаце звярнуцца да рашэнняў Hostragons; мэта — стварыць больш хуткі, бяспечны і ўстойлівы да перабояў вэб-досвед.