--- title: "Napraw błąd Failed to fetch i odróżnij jego 3 przyczyny" description: "TypeError: Failed to fetch oznacza, że żądanie nie dostało odpowiedzi HTTP. Brak nagłówka CORS, wyłączony serwer i nieistniejący host dają ten sam komunikat." canonical: "https://logbrew.co/pl/errors/failed-to-fetch" last_updated: "2026-11-10" --- # Napraw błąd Failed to fetch i odróżnij jego 3 przyczyny `TypeError: Failed to fetch` oznacza, że żądanie nie dostało odpowiedzi HTTP. Brak nagłówka CORS, wyłączony serwer i nieistniejący host dają ten sam komunikat. Przetestowane 10 listopada 2026 z użyciem Chromium 152, @logbrew/browser 0.1.21 i @logbrew/sdk 0.1.44 Autor [Furkan Erday](https://github.com/furkanerday). Furkan Erday jest założycielem LogBrew. Codziennie rozwija LogBrew z pomocą Claude Code i Codex. Canonical: https://logbrew.co/pl/errors/failed-to-fetch ## Co nazywa przyczynę nieudanego `fetch()` | Co poszło nie tak | `error.message` | Konsola | | --- | --- | --- | | Brak nagłówka `Access-Control-Allow-Origin` | `Failed to fetch` | Polityka CORS | | Nic nie nasłuchuje na porcie | `Failed to fetch` | `ERR_CONNECTION_REFUSED` | | Host nie ma rekordu DNS | `Failed to fetch` | `ERR_NAME_NOT_RESOLVED` | | Serwer odpowiedział 500 | Brak odrzucenia | `500` | 4 żądania do API w innym źródle. Pełny kubek oznacza, że tekst nazywa przyczynę. ## Ustal, którą przyczynę masz ### Otwórz konsolę przeglądarki `fetch()` odrzuca z tym samym `TypeError: Failed to fetch` przy każdym błędzie sieci. Linia konsoli obok nazywa prawdziwą przyczynę. ### API odpowiedziało bez nagłówka CORS Konsola mówi `blocked by CORS policy`. Serwer odpowiedział, ale źródło strony nie może czytać odpowiedzi, więc przeglądarka ją odrzuca. Wynik ```text Access to fetch at 'http://127.0.0.1:4874/api/closed' from origin 'http://127.0.0.1:4873' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. ``` ### Nic nie nasłuchuje na tym hoście i porcie Konsola mówi `net::ERR_CONNECTION_REFUSED`. API nie działa albo port w URL jest zły. Uruchom API, potem sprawdź port. Wynik ```text Failed to load resource: net::ERR_CONNECTION_REFUSED ``` ### Nazwa hosta nie rozwiązuje się Konsola mówi `net::ERR_NAME_NOT_RESOLVED`. DNS nie ma rekordu dla tego hosta. Sprawdź literówkę w nazwie hosta i zmienną środowiskową, która trzyma URL API w tym wdrożeniu. Wynik ```text Failed to load resource: net::ERR_NAME_NOT_RESOLVED ``` ## Napraw to w kodzie ### Wyślij nagłówek CORS z API Odpowiadaj z `Access-Control-Allow-Origin` ustawionym na źródło Twojej strony albo na `*` dla publicznego API. W naszym teście ten sam endpoint przeszedł z `Failed to fetch` do `HTTP 200` po dodaniu samego tego nagłówka. ```bash Access-Control-Allow-Origin: https://app.example.com ``` ### Sprawdź status, bo 500 nie odrzuca `fetch()` kończy się odpowiedzią przy każdej odpowiedzi HTTP, także 404 i 500. W naszym teście 500 z treścią `{"error":"tap jammed"}` trafiło do gałęzi `then`, nie `catch`. Sprawdź `response.ok`, zanim odczytasz treść. ```bash const response = await fetch(url); if (!response.ok) throw new Error(`HTTP ${response.status} for ${url}`); ``` ### Zapisz URL razem z błędem Odrzucony `fetch()` nie ma odpowiedzi, a jego ślad stosu wskazuje Twój kod, nie przyczynę. Złap go tam, gdzie wywołujesz `fetch()`, i zachowaj metodę oraz URL razem z błędem, aby śledzenie błędów pokazało, które żądanie zawiodło. ```bash try { return await fetch(url); } catch (error) { console.error("fetch failed", url, error); throw error; } ``` ## Co zobaczyliśmy podczas testu Strona działała pod `http://127.0.0.1:4873` w Chromium 152 z `@logbrew/browser` 0.1.21 i jego instrumentacją fetch. API pod `http://127.0.0.1:4874` odpowiadało na 3 ścieżki, a my wysłaliśmy 5 żądań bez `catch`, więc każde odrzucenie dotarło do SDK jako nieobsłużone odrzucenie. `/api/closed` odpowiedziało 200 bez nagłówka CORS, a żądanie zostało odrzucone z `TypeError: Failed to fetch`. Żądanie na port 4875, gdzie nic nie nasłuchiwało, i żądanie do `http://keg.invalid/api` zostały odrzucone z tym samym błędem. We wszystkich 3 przypadkach `error.message` to `Failed to fetch`, `error.name` to `TypeError`, a ślad stosu wskazywał nasze własne wywołanie `fetch()`. Konsola je rozróżniła. Pierwsze mówiło `blocked by CORS policy`, drugie `net::ERR_CONNECTION_REFUSED`, trzecie `net::ERR_NAME_NOT_RESOLVED`. `/api/broken`, które odpowiedziało 500 z nagłówkiem, w ogóle nie odrzuciło, a `/api/open`, które odpowiedziało 200 z nagłówkiem, dało `HTTP 200 {"ok":true}`. ## Dlaczego każda przyczyna ma ten sam komunikat Standard Fetch zamienia każde niepowodzenie przed odpowiedzią w 1 rzecz, błąd sieci, czyli odpowiedź typu `error` ze statusem 0. Błąd CORS też nią jest. W trybie `cors` zasób, który nie rozumie protokołu CORS, daje błąd sieci. Metoda `fetch()` odrzuca swój obiekt Promise z `TypeError` przy błędzie sieci i przy niczym innym. MDN ujmuje to tak samo. Promise jest odrzucany tylko wtedy, gdy żądanie się nie powiedzie, na przykład przy źle sformułowanym URL albo błędzie sieci, a nie przy statusie HTTP takim jak 404 czy 504. Strona MDN o błędach CORS mówi, że szczegóły nieudanego żądania CORS nie są dostępne dla JavaScript ze względów bezpieczeństwa i że konsola to jedyne miejsce, gdzie można je znaleźć. Zgłoszenie whatwg/fetch#526 prosi o bardziej informacyjne typy błędów od 2017 roku i jest nadal otwarte. ## Co zapisuje LogBrew Każde odrzucenie dotarło jako 1 problem o nazwie `Unhandled promise rejection: TypeError`, z ramkami stosu w naszym bundlu i kluczem grupowania `browser.unhandledrejection:TypeError:/app.js`. To mówi, gdzie wywołano `fetch()`, a nie co zawiodło. Instrumentacja fetch dodała span w tym samym śladzie, `browser.fetch GET /api/closed`, ze statusem `error`, metodą, ścieżką żądania i `errorType` `TypeError`. Span nazywa żądanie, które zawiodło, choć błąd tego nie robi. Odpowiedź 500 nie dała problemu, tylko span ze statusem `error` i `statusCode` 500. Odpowiedź 200 dała span ze statusem `ok`. W LogBrew 500 i błąd sieci to więc 2 różne spany, a w Twoim kodzie tylko ten drugi trafia do `catch`. ## Najczęściej zadawane pytania ### Co oznacza TypeError Failed to fetch? Przeglądarka nie dostała odpowiedzi HTTP na wywołanie `fetch()`. Serwer był nieosiągalny, host się nie rozwiązał albo CORS zablokował odpowiedź. Komunikat jest ten sam we wszystkich 3 przypadkach. ### Czy Failed to fetch to zawsze błąd CORS? Nie. W naszym teście brak nagłówka CORS, port bez serwera i host bez rekordu DNS dały ten sam komunikat. Tylko linia konsoli obok nazywa przyczynę. ### Dlaczego fetch nie odrzuca przy 404 albo 500? Standard Fetch odrzuca tylko przy błędzie sieci. Odpowiedź HTTP z dowolnym statusem to odpowiedź, więc `fetch()` ją zwraca, a `response.ok` sprawdzasz we własnym kodzie. ### Jak złapać Failed to fetch w JavaScript? Opakuj wywołanie w `try` i `catch` albo dodaj `.catch()` do obiektu Promise. Błąd to `TypeError` bez odpowiedzi, więc URL i metodę zapisz we własnym kodzie. ### Czy Failed to fetch oznacza, że serwer nie działa? Czasem. Wyłączony serwer daje w konsoli `net::ERR_CONNECTION_REFUSED`. Ten sam `Failed to fetch` pochodzi też z braku nagłówka CORS albo z nazwy hosta bez rekordu DNS. ## Zobacz, które żądanie zawiodło i dlaczego SDK LogBrew dla przeglądarki zapisuje każdy `fetch()` jako span z metodą, ścieżką i statusem, w tym samym śladzie co błąd, który wywołał. Zacznij od hojnego darmowego planu, bez karty. [Zacznij za darmo](https://logbrew.co/pl) ## Źródła - [MDN, Window: fetch() method](https://developer.mozilla.org/en-US/docs/Web/API/Window/fetch) - [MDN, CORS errors](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CORS/Errors) - [Fetch Standard, The fetch() method](https://fetch.spec.whatwg.org/#fetch-method) - [whatwg/fetch#526](https://github.com/whatwg/fetch/issues/526) ## Więcej napraw błędów JavaScript - [Napraw błąd Script error, który ukrywa komunikat, plik i wiersz](https://logbrew.co/pl/errors/script-error) - [Błędy JavaScript, które odtworzyliśmy, i jak naprawić każdy z nich](https://logbrew.co/pl/errors)