Späť na blog

HTTP status kódy: 200, 301, 404, 5xx a čo s nimi

· 6 min čítania

HTTP status kód je odpoveď servera: 2xx OK, 3xx redirect, 4xx chyba klienta, 5xx chyba servera. Čo znamenajú a ktoré sledovať pri monitoringu.

HTTP status kódy: 200, 301, 404, 5xx a čo s nimi

Kategórie odpovedí

  • 1xx Informational - prechodné odpovede, klient ich bežne nezachytí.
  • 2xx Success - request prebehol úspešne. 200 OK je predvolená odpoveď.
  • 3xx Redirection - klient má ísť inam. 301 permanentne, 302 dočasne.
  • 4xx Client errors - klient poslal niečo zlé. 404, 401, 403, 429.
  • 5xx Server errors - server zlyhal. 500, 502, 503, 504.

2xx: úspech

200 OK - štandardná OK odpoveď. Toto je "healthy" stav, ktorý monitorujete.

201 Created - typicky odpoveď na POST, ktorý vytvoril nový resource. API klienti ju očakávajú.

204 No Content - úspech, ale server nemá čo vrátiť. Často ho používajú DELETE endpointy.

206 Partial Content - server vrátil iba časť (range request). Pri streamovaní videa alebo resumable downloade.

3xx: presmerovanie

301 Moved Permanently - URL sa natrvalo zmenila. Google prenesie SEO equity na novú URL. Použite pri migrácii domény, prechode z HTTP na HTTPS alebo pri prechode na www/non-www.

302 Found / 307 Temporary Redirect - dočasné presmerovanie. Google nepresunie pozíciu (ranking). Použite pri A/B testovaní, údržbe alebo keď sa URL časom vráti.

308 Permanent Redirect - ako 301, ale zachová HTTP metódu (POST ostane POST). Pri 301 môže klient metódu zmeniť na GET.

304 Not Modified - klient má cache, server potvrdzuje, že sa obsah nezmenil. Šetrí bandwidth.

Pre monitoring: Pri kontrole 3xx odpovedí nakonfigurujte, či má monitor presmerovanie sledovať (follow), alebo ho považovať za chybu. Niektoré DNS hijack útoky sa prejavia ako neočakávané 302.

4xx: chyba na strane klienta

400 Bad Request - syntaktická chyba v requeste. Pokazený JSON, chýbajúca HTTP hlavička (header) a podobne.

401 Unauthorized - chýbajúce alebo zlé credentials. Klient sa musí autentifikovať.

403 Forbidden - klient je autentifikovaný, ale nemá oprávnenie. Pozor: niektoré servery vracajú 403 namiesto 401 z bezpečnostných dôvodov (nezverejnenie existencie resourcu).

404 Not Found - URL neexistuje. Pri uptime monitoringu sledovaných stránok je 404 alert (stránka zmizla); pri náhodných 404 od cudzích návštevníkov ide skôr o SEO problém (stráca sa odkazová sila, tzv. link equity).

405 Method Not Allowed - URL existuje, ale neakceptuje danú metódu (napr. POST na endpoint, ktorý očakáva GET).

408 Request Timeout - server čakal na požiadavku príliš dlho a ukončil spojenie.

409 Conflict - request je v konflikte s aktuálnym stavom (napr. update verzie, ktorá už nie je aktuálna).

410 Gone - resource bol natrvalo odstránený. Pre Google lepšie než 404 (signál, že sa nemusí pokúšať o reindexáciu).

422 Unprocessable Entity - request je syntakticky OK, ale obsahuje semanticky neplatné údaje (failed validation).

429 Too Many Requests - rate limit. Klient musí spomaliť. Server typicky pridáva hlavičku Retry-After.

5xx: chyba na strane servera

500 Internal Server Error - generická chyba. Backend vyhodil exception, ktorú aplikácia nezachytila. Vždy alarm pre monitoring.

501 Not Implemented - server nepozná danú HTTP metódu (napr. starý server nepodporuje PATCH).

502 Bad Gateway - reverse proxy (nginx, Cloudflare) nedostala odpoveď z backend servera. Typicky backend padol alebo timeoutol.

503 Service Unavailable - server je preťažený alebo v údržbe. Často s hlavičkou Retry-After. Toto je plánovaná odpoveď, nie crash.

504 Gateway Timeout - reverse proxy čakala na backend dlhšie ako timeout. Backend zvyčajne stále funguje, len odpovedá pomaly.

520-526 Cloudflare errors - špecifické pre Cloudflare. 520 = backend vrátil nečitateľnú odpoveď, 522 = backend nereagoval (connection timeout), 524 = backend odpovedal príliš pomaly (origin timeout), 525 = SSL handshake failed, 526 = invalid SSL certificate.

Praktické pravidlá pre alerting

  • Alert okamžite: 500, 502, 503 (ak nejde naozaj o plánovanú údržbu), 504, akýkoľvek timeout
  • Alert pri opakovaní: jednorazové 5xx môže byť race condition (súbeh); alert spustite, ak rovnaký endpoint padá 2x po sebe
  • Sledovať vzostupný trend: dlhodobý rast 4xx môže znamenať broken link, scraper attack alebo rozbitý frontend
  • Ignorovať pre alerting: 200-399 v rámci očakávania (namiesto kódu sledujte čas odozvy)

Stavový kód + čas odozvy = kompletný obraz

Sledovať iba status kód nestačí - server môže vracať 200, ale za 30 sekúnd, čo je z pohľadu zákazníka výpadok. Kvalitný monitoring kombinuje:

  1. Očakávaný status kód (typicky 200)
  2. Maximálny čas odozvy (typicky 5-10 sekúnd)
  3. Zhoda kľúčového slova v obsahu (kľúčové slovo, ktoré musí byť v HTML)
  4. SSL platný a nie blízko konca platnosti

Výpadok ktoréhokoľvek z nich = alert.

1xx: kódy, ktoré vidíte len zriedka

Informačná trieda je väčšinou neviditeľná, lebo ju za vás riešia knižnice, no dva kódy stoja za to poznať: 100 Continue - klient pred veľkým telom poslal hlavičku Expect: 100-continue; server odpovie 100, čím hovorí "pokračuj, pošli to". Užitočné na vyhnutie sa zbytočnému uploadu, keby ho server odmietol už podľa hlavičiek. 101 Switching Protocols - odpoveď na úspešný WebSocket upgrade. Ak monitorujete WebSocket endpoint cez čisté HTTP a očakávate 200, dostanete mätúci výsledok: zdravý WS server odpovedá na handshake kódom 101, nie 200.

Čítanie kódu ako diagnózy

Status kód je východiskový bod, nie verdikt. Ten istý kód môže podľa kontextu znamenať veľmi rôzne veci:

Kód Čo skontrolovať ako prvé
502 Beží backend proces vôbec? Pozrite logy aplikácie, nie nginxu.
503 Plánovaná údržba, alebo autoscaleru došla kapacita?
504 Backend žije, ale je pomalý - hľadajte pomalý dotaz alebo zaseknuté volanie.
403 Skutočný problém s oprávneniami, alebo WAF/Cloudflare pravidlo blokujúce IP monitora?
429 Váš vlastný rate limit strieľa po monitore - dajte checker na allowlist.
404 na známej stránke Zlý deploy, ktorý zahodil route, alebo premenovaná URL bez presmerovania.

Keď vás kód prekvapí, zreprodukujte ho z príkazového riadku: curl -sS -o /dev/null -w "%{http_code} %{time_total}s\n" https://example.com/path. Vypíše kód aj celkový čas, čo spolu zvyčajne ukáže rovno na príčinu. Náš HTTP status checker robí to isté zvonku vašej siete, čím vylúči "u mňa to funguje".

HEAD vs GET pre monitoring

HEAD request vráti rovnaký status a hlavičky ako GET, ale bez tela, takže je lacnejší. Je lákavé monitorovať cez HEAD a šetriť bandwidth. Háčik: niektoré frameworky a CDN spracúvajú HEAD inak než GET (alebo ho neimplementujú vôbec a vrátia 405), takže HEAD kontrola môže prejsť, kým reálny GET traffic je rozbitý, alebo zlyhať na serveri, ktorý je pre prehliadače úplne zdravý. Pre uptime monitoring uprednostnite GET, aby ste prechádzali rovnakou cestou ako návštevníci, a pridajte kontrolu kľúčového slova v tele, ktorú vám HEAD nedá.

Reťazce presmerovaní a cena za SEO

Presmerovania sú samostatne správne, no v reťazcoch drahé. Request, ktorý ide http://site na https://site na https://www.site na https://www.site/, sú štyri kolá ešte predtým, než sa stránka vôbec začne načítavať, a každý skok je príležitosť, aby sa jeden článok zlomil. Google nasleduje obmedzený počet skokov, kým to vzdá. Osvedčený postup: - Stlačte reťazce na jediné 301, kdekoľvek sa dá (choďte rovno na finálnu kanonickú URL). - Pre trvalé presuny použite 301/308, aby sa preniesla pozícia; 302/307 si nechajte na naozaj dočasné prípady. - Po každej migrácii URL prejdite vlastné presmerovania a overte, že každé končí jediným 200, nie ďalším presmerovaním ani 404. Monitor nastavený tak, aby presmerovania nenasledoval, označí neočakávané 301 vo chvíli, keď sa objaví - čo je presne to, čo chcete, keď zle nakonfigurovaný deploy zrazu začne odrážať vašu homepage niekam inam.

Monitoring s presnou klasifikáciou chýb

ePulz.io rozlišuje status kód, čas odozvy, zhodu kľúčového slova aj SSL stav. K dispozícii sú podrobné logy pre každú kontrolu.

Spustiť monitoring →

Súvisiace

Zdieľať: Odkaz skopírovaný

Vyskúšajte ePulz.io zadarmo - na 7 dní bez potreby kreditnej karty.

Vytvoriť účet