Как диагностировать ошибка в ghloc-web?

По формулировке “ошибка в ghloc-web” без текста ошибки нельзя точно сказать причину, поэтому диагностировать нужно от окружения и сетевого слоя к приложению. Начните с того, где именно проявляется проблема: страница не открывается, ошибка в консоли браузера, 500 на сервере, CORS, авторизация или некорректная работа интерфейса.

Минимальная проверка в браузере: откройте DevTools, вкладки Console и Network, обновите страницу с отключённым кэшем. Посмотрите первый красный запрос: статус, URL, тело ответа и заголовки. Часто “ошибка приложения” оказывается обычным 404 на JS-файл, 500 на API или блокировкой CORS.

curl -I https://example.com/
curl -I https://example.com/api/health
curl -v https://example.com/api/endpoint

Если приложение запускается локально или на сервере, проверьте логи процесса и веб-сервера. Для Node/Python/PHP причины будут разными, но общий принцип одинаковый: ошибка в браузере показывает симптом, а настоящая причина почти всегда в server log.

• 404 на assets — неверный public path/base url;
• 500 на API — ошибка backend или базы;
• CORS — фронт и API на разных доменах без разрешающих headers;
• 401/403 — неверная авторизация или cookie domain;
• mixed content — сайт на HTTPS, а API/ресурсы на HTTP.

Если после деплоя ломается только production, сравните переменные окружения: API URL, домен, порт, режим HTTPS, ключи, путь до статики. Для SPA-проектов отдельно проверьте настройку fallback на index.html, иначе прямые переходы по внутренним маршрутам дают 404.

Хороший порядок действий: зафиксировать точный текст ошибки, найти первый failing request, открыть его response, сверить server log по времени запроса, затем проверять конфиг. Без этого можно долго менять код вслепую. Если пришлёте конкретный текст ошибки или скрин Network, можно будет сузить причину до одного-двух мест.