JavaScript — TypeError: Failed to fetch

#Почему fetch не даёт код ответа

В отличие от ошибок 404 или 500, «Failed to fetch» появляется не при плохом ответе, а когда ответа нет совсем: fetch() отклоняет промис только при сетевом сбое или когда браузер сам запретил запрос. Поэтому текст ошибки мало что говорит, а причину надо искать в DevTools (F12 → вкладка Network) и в Console: рядом с этой ошибкой почти всегда есть красная строка с подробностью, например про CORS или блокировку расширением.

#Что чаще всего стоит за ошибкой

#Проверка по шагам

1. Различите сетевой сбой и ответ HTTPВ браузере откройте F12 → Network, обновите страницу и повторите действие. Найдите запрос fetch, запишите Request URL, статус и запись в Console. Ошибка TypeError: Failed to fetch обычно означает, что браузер не получил доступный ответ (сеть, TLS, блокировка CORS), тогда как HTTP 404/500 сам по себе не заставляет fetch() отклонить обещание — статус нужно проверять отдельно через response.ok.
2. Проверьте адрес запроса и сетевую доступностьСравните фактический адрес в Network с адресом своего API: протокол https, домен, порт, путь и отсутствие опечаток. Откройте URL безопасного GET-запроса в новой вкладке либо проверьте curl -I в терминале, если сервер поддерживает HEAD. Если curl показывает TLS/DNS-ошибку, решайте её до изменения JavaScript. Не обходите проверку сертификата через -k или режимы браузера без защиты.
3. Если ошибка только в браузере, проверьте CORSВ Console ищите «blocked by CORS policy», а в Network — запрос OPTIONS. Сервер API (не клиент) должен разрешать конкретный Origin, используемый метод и реальные заголовки. Если используются cookie с credentials: "include", требуются точный Origin и Access-Control-Allow-Credentials: true; * не подходит. Нельзя исправить CORS простым добавлением Access-Control-Allow-Origin в заголовки клиентского запроса.
4. Исключите блокировку и смешанный протоколЕсли страница загружена по HTTPS, а API вызывается по HTTP, браузер может блокировать небезопасный запрос. Переведите API на рабочий HTTPS с действительным сертификатом. При наличии ошибки ERR_BLOCKED_BY_CLIENT проверьте расширения и политики браузера на тестовом профиле, не отключая защиту на рабочем компьютере. Для корпоративной сети уточните правила прокси у администратора.
5. Обрабатывайте исключение и статусы раздельноВ коде оберните await fetch(url) в try/catch и покажите сообщение о проблеме соединения при исключении. После успешного fetch сначала проверьте response.ok и при ошибке сообщите response.status, а затем разбирайте тело через response.json(), если сервер действительно вернул JSON. Не пишите безусловное await response.json() для ответов 204 No Content.
6. Повторите запрос и убедитесь в результатеПосле устранения сетевой причины повторите действие. Успех — запрос виден в Network, ответ доступен JavaScript, нужные данные отображаются, в Console нет Failed to fetch. При повторении сохраните метод, адрес без секретных параметров, текст ошибки и результат вкладки Network для разработчика.
7. Команды для отдельных ситуацийВыберите только подходящий вариант. Это не одна последовательность: часть команд диагностирует проблему, а часть меняет настройки или данные.
   Выберите подходящий вариант — это не команды для последовательного выполнения

   Вариант 1Подставить реальный адрес API.

   Linux · Терминал (Bash)КомандаКопировать всёВыделить

   Подставить реальный адрес API. Метод HEAD поддерживается не каждым API: ответ 405 не доказывает недоступности сервера; тогда проверять допустимым GET без секретов.

   curl -I https://api.example.com/v1/items

   Вариант 2Запускать только для своего API либо разрешённого тестового адреса; вывод может содержать приватные заголов…

   Linux · Терминал (Bash)КомандаКопировать всёВыделить

   Запускать только для своего API либо разрешённого тестового адреса; вывод может содержать приватные заголовки и токены — перед отправкой в поддержку скрыть их.

   curl -v https://api.example.com/v1/items

   Вариант 3Имитация предзапроса CORS: в ответе ищите Access-Control-Allow-Origin и Access-Control-Allow-Methods

   Linux · Терминал (Bash)КомандаКопировать всёВыделить

   Имитация предзапроса CORS: в ответе ищите Access-Control-Allow-Origin и Access-Control-Allow-Methods

   curl -i -X OPTIONS https://api.example.com/v1/items -H "Origin: https://mysite.ru" -H "Access-Control-Request-Method: POST" -H "Access-Control-Request-Headers: content-type"

   Вариант 4Различаем сетевой сбой и ошибочный ответ сервера

   app.jsКопировать всёВыделить

   Различаем сетевой сбой и ошибочный ответ сервера

   try {
     const res = await fetch('/api/items', { headers: { 'Accept': 'application/json' } });
     if (!res.ok) throw new Error('HTTP ' + res.status);
     const data = await res.json();
   } catch (e) {
     console.error('Запрос не удался:', e.message);
   }

#Когда помогает режим no-cors

Параметр mode: 'no-cors' убирает ошибку, но превращает ответ в «непрозрачный»: прочитать тело нельзя. Он годится только для отправки данных вслепую (например, счётчик), а для чтения JSON нужен нормальный CORS на стороне сервера.