Может ли ошибка 404 означать проблему на бэке

Что проверяют

Умеете ли вы локализовать дефект, а не угадывать слой по коду ответа. Следом обычно спрашивают, как именно вы поймёте, кто вернул 404: приложение, прокси или CDN, и что напишете в баг-репорте.

Как отвечать

Да, может. Класс 4xx значит, что сервер счёл запрос некорректным, а не что виноват фронтенд. Причины на стороне бэкенда:

• маршрутизация: эндпоинт не зарегистрирован, опечатка в пути, сменилась версия API (/v1 на /v2), а старый путь убрали без редиректа;
• деплой и конфигурация: сервис выкатили без новой ручки, в nginx или API-шлюзе нет нужного location или правила проксирования;
• данные: запись есть, но запрос в базу её не находит из-за мягкого удаления, фильтра по тенанту или неверного маппинга ID;
• осознанный 404 вместо 403: часть API так скрывает само существование ресурса от пользователя без прав;
• SPA без фолбэка: сервер отдаёт 404 на прямой заход по /orders/15, потому что для клиентских маршрутов не настроена отдача index.html.

Порядок проверки. Во вкладке Network в DevTools смотрите точный URL, метод и параметры. Затем тело и заголовки ответа: JSON с кодом ошибки приложения и стандартная HTML-страница nginx указывают на разные слои. Повторите запрос в Postman или curl, сначала через шлюз, потом напрямую в сервис. Сверьтесь с контрактом в Swagger/OpenAPI и найдите запрос в логах сервиса: если его там нет, до приложения он не дошёл.

Где спотыкаются

Отвечают «404 всегда клиентская ошибка» и закрывают тему. Неверная ссылка на фронте и потерянный маршрут на сервере выглядят в браузере одинаково.

Не проверяют метод. Некоторые фреймворки на POST в путь, где есть только GET, отвечают 404 вместо правильного 405, и это само по себе дефект.

Не тестируют негативный сценарий: запрос несуществующего ID должен вернуть 404, а не 500 со стектрейсом или 200 с null. И наоборот, пустой результат фильтра это 200 с [], а не 404.