Коди статусу 5xx пояснено: коли проблема - ваш сервер
Код статусу 5xx означає, що провалилася ваша інфраструктура, а не запит відвідувача. Сервер прийняв запит, зрозумів його, а тоді не зміг видати дійсну відповідь, тож кожен 5xx на вашому сайті - інцидент, за який відповідаєте ви.
Що відрізняє 5xx від 4xx
RFC 9110 визначає 5xx як "Server Error": сервер усвідомлює, що помилився чи не здатен виконати запитаний метод. Це і є вся різниця. 404 каже "тут нічого немає". 500 каже "тут щось є, і я зламався, поки це виробляв".
З цього випливають два наслідки. По-перше, 5xx зазвичай можна повторити, бо той самий запит цілком може вдатися секундою пізніше, щойно проблемний компонент відновиться. По-друге, пошукові системи трактують 5xx як тимчасовий сигнал і уповільнюють сканування, а не деіндексують негайно, тоді як стійкий 5xx протягом днів зрештою коштує вам проіндексованих сторінок.
Який стрибок провалився
Читайте код 5xx як карту того, де запит загинув. Майже кожен сучасний сайт ставить принаймні один проксі перед застосунком, тож код каже вам, який бік цієї межі провалився.
| Код | Хто його видав | Що сталося |
|---|---|---|
| 500 Internal Server Error | Сам застосунок | Необроблений виняток чи неочікувана умова всередині застосунку |
| 501 Not Implemented | Сервер | Метод запиту взагалі не підтримується |
| 502 Bad Gateway | Проксі, CDN чи балансувальник навантаження | Бекенд відповів, але чимось недійсним, чи закрив з'єднання |
| 503 Service Unavailable | Сервер чи проксі, навмисно | Перевантажений чи на обслуговуванні, і навмисно відмовляє в роботі |
| 504 Gateway Timeout | Проксі, CDN чи балансувальник навантаження | Бекенд так і не відповів вчасно |
| 505 HTTP Version Not Supported | Сервер | Версія протоколу в запиті не підтримується |
502, 503 і 504 несуть найбільшу діагностичну цінність, бо кожен називає іншу відмову того самого бекенда: недійсна відповідь, відмова у відповіді, відсутність відповіді. Посібник із 502 Bad Gateway детально розглядає перший з них, включно з рядками логу проксі, що визначають точну несправність.
Поширені причини відповідей 5xx
- Краш застосунку. Необроблений виняток, невдале з'єднання з базою даних чи значення null у неочікуваному місці видає 500 на всіх маршрутах, що торкаються зламаного шляху коду.
- Процес бекенда не працює. Зупинений сервер застосунку, мертвий пул PHP-FPM чи контейнер, що провалив перевірку здоров'я, не лишає проксі з ким говорити, що проявляється як 502.
- Вичерпання ресурсів. Закінчилася пам'ять, закінчилися дескриптори файлів, закінчилися робочі потоки чи з'єднання бази даних. Зазвичай починається як періодичні помилки під навантаженням, перш ніж стати постійними.
- Повільні залежності. Повільний запит, повільний сторонній API чи холодний старт зсуває час відповіді за тайм-аут проксі й перетворюється на 504.
- Деплої й перезапуски. Будь-яке вікно, де старий процес зупинився, а новий ще не почав обслуговувати, дає сплеск 502 чи 503.
- Помилки конфігурації. Неправильна адреса вищого рівня, погане налаштування TLS між проксі й бекендом, чи невідповідність протоколу, як-от розмова по HTTP з портом HTTPS.
- Заповнений диск. Недооцінена причина. Логи чи тимчасові файли заповнюють том, сесії чи кеші перестають писатися, і застосунок починає провалюватися способами, що виглядають випадковими.
Як розбиратися з 5xx
- Підтвердьте код і його джерело. Отримайте заголовки напряму й подивіться, який компонент підписав відповідь:
Заголовокcurl -sS -o /dev/null -D - https://example.com/Server:чи CDN на помилці каже вам, чи згенерував її край мережі, чи джерело. - Протестуйте джерело напряму, оминувши проксі. Якщо бекенд відповідає 200 на власному порту, поки публічний URL відповідає 502, несправність у шарі проксі чи в лінку між ними.
- Далі читайте лог помилок проксі, а не лог застосунку. Зворотні проксі точно називають відмову, наприклад
connect() failed (111: Connection refused)чиupstream timed out, що одразу відділяє "бекенд не працює" від "бекенд повільний". - Тоді читайте лог застосунку. Для 500 трасування стека - відповідь. Для 502 і 504 застосунок часто взагалі нічого не логує, і сама ця відсутність інформативна.
- Перевірте ресурси на хості. Пам'ять, диск, кількість з'єднань і насиченість воркерів. Періодичний 5xx під трафіком - майже завжди досягнення ліміту.
- Погляньте, що змінилося. Деплої, поштовхи конфігурації, оновлення сертифікатів і оновлення залежностей пояснюють велику частку раптових спалахів 5xx.
Виявити періодичні помилки 5xx
Помилки 5xx часто періодичні, і саме це ускладнює їх виявлення вручну: сторінка, яку ви перезавантажуєте, працює, а та, яку завантажив ваш клієнт, - ні. Запланована HTTP-перевірка працює безперервно й опитує сайт значно частіше, ніж могли б ви, тож серія помилок стає видимою як патерн, а не як розрізнені скарги. Перевірка з багатьох локацій також відділяє справжню несправність сервера від проблеми маршрутизації чи краю мережі, що зачіпає лише частину світу, і саме тому розподілений моніторинг доступності використовує контрольні точки, розкидані по регіонах, а не одну точку спостереження. Якщо ж проблемний код виявиться 403, 404 чи 429, запит ніколи не дійшов до зламаного бекенда, і правильна відправна точка - посібник із родини 4xx.