418 Jestem czajnikiem

TL;DR — 418 I'm a teapot to najbardziej lubiany żartobliwy kod statusu w sieci. Pochodzi z RFC 2324, primaaprilisowego RFC o dzbankach do kawy, i nigdy nie otrzymał zwykłej semantyki HTTP — ale zgodnie z RFC 9110 i rejestrem IANA jest formalnie zarezerwowany, a nie nieprzypisany. Datowane wytyczne Google z 2023 r. traktują go jak każdy inny kod 4xx poza 429: adres URL nie zostaje zindeksowany. Sprawdź go na tej stronie: /coffee odpowiada prawdziwym 418 — zajrzyj do zakładki Network.

Skąd pochodzi 418

1 kwietnia 1998 roku IETF opublikował RFC 2324: Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0) — w pełni określony, całkowicie satyryczny protokół do sterowania dzbankami do kawy przez sieć. Wśród jego osiągnięć znalazły się metoda BREW, nagłówek Accept-Additions (mleko, syrop, whisky) oraz jeden nieśmiertelny kod statusu:

418 I’m a teapot — “Any attempt to brew coffee with a teapot should result in the error code ‘418 I’m a teapot’. The resulting entity body MAY be short and stout.” (tłumaczenie) „Każda próba zaparzenia kawy za pomocą czajnika powinna skutkować kodem błędu „418 I’m a teapot”. Zwracane ciało encji MOŻE być krótkie i krępe.”

Cały żart polega na tym, że poproszono czajnik o kawę. Nie może jej zrobić. To czajnik.

Szesnaście lat później RFC 7168 powrócił do tego pomysłu w kontekście urządzeń do parzenia herbaty — to kolejne RFC Informational i primaaprilisowy żart, tym razem rozróżniający urządzenie, któremu tymczasowo skończyła się kawa, od czajnika, któremu skończyła się ona na stałe. Żadne z tych RFC nie nadaje kodowi 418 zwykłej semantyki aplikacyjnej HTTP; oba opisują HTCPCP, satyryczny protokół, a nie podstawowy protokół HTTP.

Dlaczego nie stał się prawdziwym HTTP

Kod 418 nigdy nie otrzymał zwykłej semantyki HTTP — ale nie jest też „nieprzypisany”. RFC 9110, aktualna specyfikacja semantyki HTTP, formalnie rezerwuje ten kod (wskazując, jak często wdrażano go jako żart), a rejestr kodów statusu HTTP IANA wymienia 418 jako (Unused) i odwołuje się do RFC 9110 — kod nie jest dostępny do zwykłego ponownego użycia. Dowód potwierdzający to twierdzenie RFC 9110 reserves status code 418, citing how often it has been deployed as a joke, and leaves open the possibility of assigning it a different meaning in the future if circumstances require it. Zakres: Current HTTP Semantics reservation; RFC 9110 does not make 418 a normal production status, but does not permanently foreclose future reassignment. Poziom ufności: wysoki · Zweryfikowano: 2026-07-16 IETF: RFC 9110 §15.5.19 — 418 (Unused) W 2017 roku grupa robocza HTTP IETF zaproponowała uporządkowanie tej sytuacji, aby można było przypisać kod do czegoś użytecznego. Internet odpowiedział kampanią „Save 418”, a rezerwacja pozostała w mocy — RFC 9110 pozostawia też możliwość ponownego przypisania kodu w przyszłości, jeśli okoliczności kiedykolwiek tego wymagają.

Nie powstrzymało to twórców przed implementacją: zarówno net/http w Go, jak i moduł http w Pythonie udostępniają nazwany stały kodu 418 (StatusTeapot, HTTPStatus.IM_A_TEAPOT), a inne frameworki i platformy poszły w ich ślady jako easter egg — między innymi własne google.com/teapot Google. Dowód potwierdzający to twierdzenie Go's net/http and Python's http module both expose a named 418 status constant, showing implementation recognition without requiring servers to emit 418. Zakres: Named constants in two mainstream standard libraries; not evidence of a default response. Poziom ufności: wysoki · Zweryfikowano: 2026-07-16 Go: net/http status constants (StatusTeapot) Python docs: http.HTTPStatus.IM_A_TEAPOT Nazwana stała nie oznacza, że framework domyślnie emituje 418; oznacza, że kod jest rozpoznawany, a nie że ma przypisaną semantykę HTTP.

Co 418 oznacza dla SEO

Nic szczególnego — i właśnie to warto wiedzieć. Google nie interpretuje żartu; wskazany z datą wpis Google Search Central z lutego 2023 roku mówi, że wszystkie odpowiedzi 4xx poza 429 są traktowane tak samo w Search: wcześniej zindeksowane adresy URL są z czasem usuwane, a treść strony nie jest wykorzystywana. Dowód potwierdzający to twierdzenie Google's Search Central blog states that all 4xx responses except 429 receive the same treatment for Search: content isn't used and previously indexed URLs are removed over time. Zakres: Google Search's dated, named statement on 4xx handling (not 418-specific). Poziom ufności: wysoki · Zweryfikowano: 2026-07-16 Google Search Central Blog (Feb 2023): Don't use 403s or 404s for rate limiting To ogólna zasada dotycząca kodów 4xx, a nie reguła dotycząca czajnika — aktualna ogólna strona Google o statusach crawlera wyraźnie mówi, że egzotyczne statusy, takie jak 418, nie są objęte jej tabelą. Dowód potwierdzający to twierdzenie Google's current generic crawler-status-code page states that exotic statuses such as 418 are not covered by its table. Zakres: Scope note limiting Google's generic HTTP-status guidance to common codes. Poziom ufności: wysoki · Zweryfikowano: 2026-07-16 Google: How HTTP status codes affect Google's crawlers W praktyce, jeśli chodzi o indeksowanie, 418 zachowuje się jak każdy inny kod 4xx poza 429; nie ma szczególnej reguły rankingowej dla czajnika, harmonogramu deindeksacji ani gwarancji odzyskania poza tą ogólną zasadą.

Tu kończy się zabawa: niektóre konfiguracje WAF i ochrony przed botami używają 418 jako odpowiedzi „zablokowane żądanie”, ponieważ jest charakterystyczna i łatwa do znalezienia w logach. Jeśli taka reguła zadziała błędnie dla Googlebota, prawdziwe strony zaczną odpowiadać kodem 418 — i będą traktowane dokładnie tak jak strony, które nie istnieją.

Jeśli w logach serwera lub raportach crawlowania widzisz kody 418 przy ważnych adresach URL, sam kod statusu nie mówi, która warstwa go wygenerowała — może to zrobić kod aplikacji, domyślne ustawienie frameworka, reguła WAF lub ochrony przed botami, CDN albo serwer źródłowy, a odpowiedź może przechodzić przez kilka z tych warstw w drodze do klienta. Sprawdź konfigurację, nagłówki odpowiedzi i logi ścieżki żądania na każdej warstwie, aby znaleźć rzeczywiste źródło, a następnie napraw problem jak każdy inny niepożądany kod 4xx dla adresu URL przeznaczonego do indeksowania.

Użyj tej minimalnej sekwencji diagnostycznej:

1. Zapisz surowy status i nagłówki odpowiedzi dotyczące danego adresu URL.
2. Porównaj logi aplikacji, WAF, CDN i serwera źródłowego dla tej samej ścieżki żądania i czasu.
3. Popraw warstwę emitującą 418, a następnie powtórz surowe żądanie i test crawlera.

Ten kod na tej stronie

Zgodnie z duchem RFC adres /coffee w tym serwisie zwraca prawdziwy 418, krótki i krępy, prosto z edge’a. Ta strona istnieje, aby ten easter egg miał kanoniczne wyjaśnienie — i aby klaster http-status-codes obejmował jedyny kod statusu, który naprawdę wywołuje uśmiech.

TL;DR — Traktuj nieoczekiwane 418 jak zwykły błąd 4xx inny niż 429, wysłany przez nietypową warstwę. Zachowaj surową odpowiedź, ustal czy pochodzi z aplikacji, WAF, CDN czy origin i sprawdzaj tę samą ścieżkę crawlera, aż ważne adresy wrócą do zamierzonego stanu.

Zinterpretuj sygnał przed zmianą

Kod klasyfikuje odpowiedź, ale nie wskazuje systemu, który go wybrał. Cytowane wytyczne Google traktują 418 jak pozostałe błędy 4xx inne niż 429: treść nie służy do indeksowania, a wcześniej zindeksowany URL może z czasem zostać usunięty. Nie ma osobnej procedury odzyskiwania dla teapot.

Zacznij od jednego URL i zachowaj czas, ścieżkę, status, nagłówki oraz treść. Sprawdź zależność od user-agenta, IP, uwierzytelnienia, częstotliwości i lokalizacji.

Wyizoluj warstwę odpowiedzi

Pracuj od publicznej odpowiedzi do środka:

1. Odtwórz odpowiedź surowym żądaniem i zapisz nagłówki oraz treść.
2. Skoreluj ścieżkę i czas w logach CDN, WAF, origin, frameworka i aplikacji.
3. Porównaj przeglądarkę z crawlerem; tekst strony błędu nie dowodzi źródła.
4. Zmień tylko potwierdzoną regułę lub kod; nazwana stała nie oznacza, że framework domyślnie wysyła 418.

Zweryfikuj odzyskanie

Ponownie przetestuj URL ścieżką, która zawodziła. Powinien zwrócić stan właściwy dla zasobu, zwykle 200 dla aktywnej strony możliwej do indeksowania. Sprawdź też sąsiednie URL objęte tą samą regułą.

Monitoruj nowe 418 na indeksowalnych URL. /coffee pozostaje celową kontrolą 418; strony produkcyjne nie mogą dziedziczyć tego zachowania.

Narzędzia do wykrywania nieoczekiwanego 418

• Bulk HTTP Status Code Checker: przeskanuj zestaw adresów URL pod kątem odpowiedzi 418 i odróżnij zamierzony easter egg od prawdziwych stron blokowanych przez WAF lub regułę ochrony przed botami.
• HTTP Header Checker: sprawdź nagłówki CDN i zabezpieczeń w poszukiwaniu wskazówek, która warstwa wygenerowała odpowiedź.
• Panel Network w narzędziach deweloperskich przeglądarki: zweryfikuj surowy status żądania zamiast polegać na widocznym tekście strony błędu.
• curl: uruchom curl -i https://example.com/path, aby zapisać status, nagłówki i ewentualne ciało odpowiedzi bez zalogowanej sesji przeglądarki.
• Zdarzenia bezpieczeństwa CDN/WAF: jeśli 418 pojawia się na stronie, która powinna być indeksowana, zestaw czas żądania i adres URL z regułą, która zadziałała, zanim ją zmienisz.

• 418 I'm a teapot pochodzi z RFC 2324 (HTCPCP), primaaprilisowego RFC z 1998 roku; sygnalizuje, że czajnik został poproszony o zaparzenie kawy. RFC 7168 powrócił do niego w 2014 roku w kontekście urządzeń do parzenia herbaty.
• To nie jest „unassigned”: RFC 9110 formalnie rezerwuje 418, a rejestr IANA wymienia go jako (Unused) — jest to status, którego internet bronił, a nie taki, którego nikt nie zgłosił. Próba odzyskania kodu w 2017 roku została porzucona po kampanii „Save 418”.
• Go i Python udostępniają nazwane stałe kodu 418; inne frameworki i platformy implementują go jako easter egg (Google ma własny pod adresem google.com/teapot) — ale stała nie oznacza, że framework domyślnie emituje 418.
• Wpływ na SEO: wskazany z datą wpis Google Search Central z lutego 2023 roku traktuje każdy kod 4xx poza 429 tak samo w Search — adres URL odpowiadający kodem 418 nie jest indeksowany, podobnie jak 404; aktualna ogólna strona Google o statusach crawlera w ogóle nie obejmuje egzotycznych kodów takich jak 418.
• Ryzyko praktyczne: nieoczekiwany 418 może pochodzić z aplikacji, domyślnego ustawienia frameworka, reguły WAF/ochrony przed botami, CDN-u albo serwera źródłowego — sprawdź nagłówki i logi na każdej warstwie, aby znaleźć źródło, zanim naprawisz go jak każdy inny kod 4xx.
• Ten serwis zwraca prawdziwy 418 pod adresem /coffee.

Dziennik zmian