Превью работает, а живой сайт падает: что проверить

Что на самом деле означает «в превью работает, а в продакшене — нет»

Ссылка превью — это временная версия вашего приложения в контролируемой среде билдера или хоста. Она часто использует стандартный домен, дефолтные настройки и «дружественную» конфигурацию, где меньше ограничений мешает работе.

Живой сайт — это ваш реальный домен с реальными продакшен-настройками. Браузеры обращаются с ним строже: куки привязаны к домену, правила HTTPS применяются, и приложению нужно общаться с правильным бэкендом с нужными правами.

Поэтому когда говорят «в превью всё работает, а на живом — нет», обычно имеют в виду: в демо интерфейс выглядит нормально, но на реальном домене что-то ломается из‑за правил происхождения.

Сбой проявляется по‑разному: пустая страница или бесконечный спиннер, петля входа (вход — и снова на страницу логина), кнопки, которые ничего не делают из‑за упавших API-вызовов, отсутствие данных при видимой загрузке UI или ошибки, которые возникают только на живом домене.

Также «работает» может вводить в заблуждение. Многие ИИ-созданные приложения «работают» в превью, потому что UI рендерится — но важные части тихо падают в продакшене: запросы к API, аутентификация, загрузки, платежи или чтение из базы.

Простой пример: в превью приложение обращается к API по тестовому URL и CORS настроен либерально, поэтому запросы проходят. На живом домене те же вызовы блокируются или приложение всё ещё указывает на localhost. Страница загружается, но данные не появляются.

Поэтому первый вопрос не «загружается ли страница?», а «удачны ли сетевые вызовы на живом домене?». Если вы унаследовали прототип, сгенерированный ИИ, быстрый аудит кода (как делает FixMyMess) часто быстро выявляет несоответствие: неверная переменная окружения, кука, привязанная к превью-домену, или правило HTTPS, которое превью не проверяло.

Различия доменов, которые меняют поведение приложения

Когда в превью всё работает, а в продакшене — нет, сразу подозревайте hostname. Браузеры считают app-preview.example и example.com разными местами, даже если код одинаков. Это меняет, какие куки отправляются, какие правила безопасности применяются и к каким URL приложение может обращаться.

Распространённая ошибка — перевод с временного превью-домена на реальный домен с предположением, что всё перенесётся само. На деле многие настройки привязаны к точному origin (схема + хост + порт). Одна лишняя или отсутствующая буква может превратить рабочую функцию в сломанную.

Субдомен против корневого домена: мелочь, большой эффект

Переход с app.example.com на example.com (или наоборот) может нарушить поведение, зависящее от области действия домена. Куки могут быть выставлены для одного хоста и никогда не появляться на другом. Некоторые настройки аутентификации тоже ожидают конкретный домен для callback-ов и разрешённых origin.

То же самое касается www против без www. Если ваш живой сайт делает редирект с www.example.com на example.com, приложение может загрузиться, но вход пройти не сможет, потому что провайдер аутентификации видит другой callback URL, чем указанный в настройках.

Частые несоответствия доменов, приводящие к мгновенным сбоям:

• www vs без www (редиректы меняют конечный URL)
• корневой домен vs субдомен (область куки и разрешённые origins отличаются)
• разные превью-хосты для разных деплоев (хардкоднутые URL перестают совпадать)
• staging vs production домены (настройки auth и API указывают не туда)
• лишний или отсутствующий слеш в callback URL (некоторые провайдеры считают их разными)

Быстрый пример: превью использует временный домен, и провайдер логина настроен на callback для него. Вы запускаете на www.yourapp.com, провайдер отклоняет callback, и пользователь видит пустую страницу или цикл входа. В UI об этом обычно не написано.

Это особенно часто встречается в ИИ-созданных приложениях, потому что домены могут быть захардкодены в нескольких местах (фронтенд, бэкенд, настройки auth). FixMyMess часто находит несколько мест, где один и тот же hostname нужно поправить, чтобы продакшен вел себя как превью.

Переменные окружения: тихий убийца продакшена

Превью-среды часто «просто работают», потому что платформа подставляет значения по умолчанию. На живом сайте таких подстановок обычно нет. Эта разница — одна из главных причин, почему в превью всё нормально, а в продакшене падает, даже при идентичном коде.

Типичная ситуация: в превью подставляют fallback URL API, демонстрационную БД или либеральный режим аутентификации. В продакшене требуются реальные значения. Когда их нет, приложение продолжает работать внешне, но ведёт себя странно: кнопки ничего не делают, страницы показывают пустые состояния или все запросы отвечают ошибками.

Частые проблемы с переменными окружения в продакшене:

• отсутствует обязательная переменная (BASE URL API, секрет аутентификации, URL базы данных, ключи платежей);
• переменная есть, но неправильная (эндпоинт dev, тестовый ключ, старый staging-домен);
• переменные установлены в одном месте, а читаются из другого (настроено в панели хоста, а сборка ожидает .env во время билда);
• имена не совпадают точно (NEXT_PUBLIC_API_URL vs NEXT_PUBLIC_API_BASE);
• значение имеет тонкую опечатку (лишний слеш, неправильный регион, неверный client ID).

Ещё одна ловушка — где именно используется переменная. Клиентские переменные попадают в браузер, поэтому их нужно безопасно раскрывать. Серверные переменные остаются на сервере, но только если код действительно выполняется сервер-side. В ИИ-созданных приложениях иногда секреты случайно попадают в фронтенд. Это может сработать в превью, а в продакшене провалиться при ротации ключей или встраивании строгих правил безопасности — и это реальная угроза.

Чтобы быстро заметить проблему с env, посмотрите логи продакшена и консоль браузера на предмет:

• ошибок про undefined или null;
• ответов 401/403 (плохой ключ, неверная audience, неправильный issuer);
• запросов к неправильному хосту (dev-домены в продакшене);
• ошибок сборки/старта вроде «Missing required env var».

Пример: вход работает в превью, потому что используется callback превью-домена, а в продакшене всё ещё указывает на превью-домен. Провайдер отклоняет запрос, и пользователи видят 401 или цикл входа.

Если вы приняли в наследство ИИ-созданный репозиторий и не понимаете, откуда берётся значение, FixMyMess может выполнить бесплатный аудит кода и перечислить, что отсутствует или настроено неверно, прежде чем вы что‑то менять.

HTTPS, редиректы и проблемы со смешанным контентом

Превью может работать, потому что платформа даёт корректную конфигурацию. При переносе на ваш домен браузер становится строже. Небольшие ошибки конфигурации могут помешать загрузке приложения, входу или вызовам API.

HTTPS строже, чем многие превью-настройки

HTTPS — это не просто значок замка. Он меняет то, что браузер допускает. Запросы могут блокироваться, куки вести себя иначе, а редиректы — создавать петли, которые не проявлялись в превью.

Типичный пример: живой сайт загружается по https://, а приложение всё ещё обращается к API по http://api.example.com. В превью вы могли не заметить этого, потому что всё работало на том же платформенном домене или предупреждения легче пропустить.

Смешанный контент: тихий блокировщик

Смешанный контент возникает, когда HTTPS-страница загружает что-то по HTTP (API, изображения, скрипты). Современные браузеры часто блокируют такие запросы — приложение будет выглядеть «сломавшимся» без явной ошибки на экране.

Проверьте быстро:

• Откройте живой сайт (не превью).
• Включите консоль браузера и перезагрузите.
• Ищите ошибки «Blocked mixed content» или похожие.
• Посмотрите в Network на запросы, которые блокируются, отменяются или застревают в редиректах.

Редиректы, HSTS и петли

Петли редиректов часто возникают, когда несколько слоёв конфликтуют. Например:

• приложение форсит HTTPS, но платформа хоста уже делает это;
• CDN форсит www, а приложение — без www;
• включён HSTS, и браузер отказывается пробовать HTTP снова.

В таких случаях страница может мигать, бесконечно перезагружаться или не доходить до выполнения вашего кода.

Сертификаты тоже важны. Если сертификат недействителен или ещё не выписан для кастомного домена, некоторые браузеры будут блокировать запросы или мешать корректной работе потоков входа.

Если консоль полна предупреждений о смешанном контенте и ошибок редиректов, FixMyMess обычно начинает с картирования каждого запроса, который приложение делает в продакшене, затем правит HTTPS-URL и правила редиректов, чтобы продакшен вел себя как превью.

Куки и аутентификация: почему логин ломается на живом сайте

Когда превью работает, а продакшн — нет, чаще всего первым ломается вход. Превью кажется нормальным, но живой домен меняет, как браузер обращается с куками, редиректами и хранилищем сессий.

Куки привязаны к домену. Если превью работает на платформенном домене, а живой сайт — на вашем custom-домене, браузер может перестать отправлять сессионную куку, даже если код не менялся.

Флаги куки, которые чаще всего удивляют

Три настройки решают, выживет ли ваша кука при переносе на живой сайт:

• Domain scope: кука, выставленная для preview.example-host.com, не будет отправляться на www.yourdomain.com. Жёстко заданный домен куки может работать в превью и тихо провалиться в продакшене.
• SameSite: логины с редиректами (Google, GitHub, magic links) могут ломаться, если SameSite=Strict блокирует куку при возврате. Часто Lax безопаснее для простых флоу.
• Secure: Secure-куки отправляются только по HTTPS. Если ваш живой сайт делает шаг по HTTP (или есть запутанная цепочка редиректов), кука может не сохраниться.

Типичные симптомы:

• вход «удачный», но вы попадаете обратно на страницу логина;
• возникает цикл: вход — редирект — снова вход;
• работает в инкогнито один раз, потом ломается;
• работает в превью, но только на реальном домене — нет.

OAuth и хостed auth: разрешённые origins и redirect URI

Провайдеры аутентификации не всегда автоматически доверяют вашему кастомному домену. Превью-среды иногда беллистятся по умолчанию, а ваш реальный домен — нет. Провайдер может отклонить callback, либо приложение получит callback, но не пройдёт обмен кодом, потому что origin не совпадает.

Пример: превью использует https://random-preview-host.com, а провайдер настроен для него. Вы переходите на https://app.yourdomain.com, но провайдер всё ещё разрешает только превью-origin. Редирект вроде бы проходит, но вы попадаете на пустую страницу, видите уведомление об ошибке или возвращаетесь на страницу логина.

Перед изменением кода проверьте в DevTools:

• что живой сайт полностью на HTTPS и нет шагов по HTTP;
• заголовок Set-Cookie (Domain, SameSite, Secure, срок действия`);
• что кука появляется в хранилище живого домена и отправляется при следующем запросе;
• для OAuth — что живой домен указан в разрешённых origins и redirect/callback URL.

Сломанная аутентификация — частая задача для FixMyMess. Мы трассируем куку и путь редиректов от начала до конца и исправляем несоответствия, чтобы вход надёжно работал на живом домене.

CORS и API-вызовы, которые блокируются только на живом сайте

Иногда интерфейс загружается, но все запросы за данными падают, потому что браузер запрещает фронтенду обращаться к вашему API. Это и есть CORS (Cross-Origin Resource Sharing). Проще говоря: браузер блокирует сайт, который пытается отправить запрос на другой домен, если сервер явно не разрешил это.

Это чаще происходит в продакшене, потому что хосты превью иногда обрабатывают такие запросы по‑особому. Ваш API мог разрешать вызовы с превью-домена, но не с реального домена.

Как выглядят ошибки CORS

В консоли или во вкладке Network вы увидите «blocked by CORS policy» или неудачную preflight-запрос OPTIONS. Preflight выполняется чаще, чем думают: при отправке JSON с кастомными заголовками, при методах POST/PUT или при включённых креденшелах (куки) браузер сначала спрашивает, «разрешено ли это?». Если сервер не отвечает на OPTIONS правильно, браузер блокирует основной запрос, даже если API работает в инструментах вроде curl.

На стороне API (или serverless-функции) проверьте самое важное:

• разрешайте точный origin живого сайта (схема + домен + порт);
• если отправляете куки/заголовки авторизации, разрешайте credentials и не используйте wildcard-оригин;
• разрешайте фактические заголовки, которые вы отправляете (часто Content-Type, Authorization);
• разрешайте используемые методы и корректно отвечайте на OPTIONS;
• проверьте, что ваш reverse proxy/CDN не удаляет заголовки CORS в продакшене.

Обычная ситуация: ИИ-созданное приложение вызывает api.myapp.com с preview.mytool.app — и всё работает. После релиза фронтенд запускается на myapp.com, но API по‑прежнему разрешает только preview.mytool.app, поэтому в браузере падают логин и сохранения.

Если вы застряли, FixMyMess часто находит CORS-ошибки вместе с сопутствующими проблемами (например, куки не отправляются из‑за настроек credentials) и проверяет исправление реальными браузерными тестами перед релизом.

Кэширование, service worker и устаревшие деплои

Иногда в коде ничего не сломано. Просто живой домен отдаёт старую версию. Превью-серверы часто обходят кеширующие слои, которые используются на реальном домене.

Когда кеши отдают неправильную версию

CDN или браузерный кэш могут хранить старые js-бандлы после деплоя. Если сборка создаёт файлы вроде app.123.js, а HTML всё ещё ссылается на app.122.js, пользователь загрузит смесь старого и нового кода. Результат непредсказуем: кнопки перестают работать, страницы пусты или появляются ошибки, которые нельзя воспроизвести локально.

Признаки кэшированных или устаревших ассетов:

• UI выглядит как старая версия после деплоя;
• в Network возвращаются 404 для JS или CSS файлов;
• ошибки про отсутствующие чанки или «unexpected token» в JS;
• проблема видна не у всех пользователей (часто на мобильных);
• обновление страницы меняет поведение.

Service worker: один плохой вариант может закрепиться

Если у приложения есть service worker (обычно в PWA-шаблонах), он может продолжать отдавать закешированную «оболочку» сайта. Одна плохая версия может установиться и продолжать загружаться даже после исправления. Пользователям иногда нужно закрыть все вкладки, либо нужно поправить логику обновления service worker.

Ещё одна частая ловушка — изменение базового URL. Если вы перешли с превью-субдомена на реальный домен или поменяли путь хоста, пути к статике могут сломаться. В Network вы увидите 404 для файлов, которые физически существуют, но не по тому пути, который запрашивает браузер.

Быстрые тесты без угадываний:

• открыть приватное окно и проверить живой сайт;
• сделать хард-обновление (Ctrl/Cmd + Shift + R);
• в DevTools отключить кеш и перезагрузить;
• искать ответы 304/404 для JS и CSS;
• если есть service worker — зарегистрировать его заново или удалить и перезагрузить.

Если живой сайт продолжает отдавать неправильную сборку, FixMyMess может быстро определить: это кэширование, сервис-воркер или проблема вывода сборки, прежде чем вы будете часами гоняться за «призрачными» багами.

Пошагово: диагностировать за 20 минут

Начните с того, чтобы точно назвать симптом на живом сайте. Это пустая страница (ошибка загрузки), страница загружается, но данные не появляются (проблема с API), или вход, который в превью работает, а в продакшене — нет (auth/куки)? Неправильно выбранный симптом — потерянный час на поиски не той проблемы.

Откройте живой сайт в чистом приватном окне, затем DevTools. Держите открытыми Console и Network. Console показывает громкие ошибки (красные). Network показывает первый запрос, который реально ломается.

1) Найдите первую реальную ошибку

В Console ищите ошибки про заблокированные запросы, CORS, смешанный контент, редирект‑петли или отсутствующие переменные окружения. Игнорируйте предупреждения, пока не объясните первую красную ошибку.

Затем в Network обновите страницу и кликните по первому упавшему запросу (часто первый XHR/fetch). Обратите внимание на URL, статус и тело ответа:

• 401/403 обычно указывает на аутентификацию, куки или несовпадающий ключ/issuer;
• 404 чаще про неверный URL, отсутствующий роут или сломанный путь к ассету;
• 500 — про логику сервера или неверную конфигурацию;
• Запросы, которые никогда не завершаются могут быть про DNS, HTTPS или блокировку браузером.

2) Сравните превью и продакшен «как одно целое»

Откройте превью и продакшен рядом и выполните одно и то же действие (загрузить страницу, кликнуть логин, получить данные). Сравните детали упавшего запроса:

• различия в URL (http vs https, домен, путь);
• заголовки (отсутствует Authorization, другой Origin);
• куки (не установлены, не отправляются, неправильный домен);
• тело ответа (разные сообщения об ошибке в превью и в продакшене).

Если в превью вызывается api.preview-host.com, а в продакшене — localhost, скорее всего это проблема переменной окружения, а не случайный баг в продакшене.

Наконец, проверьте переменные окружения в панели вашего хостинга (не только в репозитории), затем сделайте чистую пересборку и деплой. Многие ИИ-созданные приложения держат старые значения до полной пересборки и деплоя.

Если вы застряли после этих проверок, FixMyMess может выполнить бесплатный аудит кода и выяснить: env vars, домен/CORS, HTTPS или auth — что именно ломает продакшен.

Самые частые ошибки, которые отнимают больше всего времени

Когда говорят «в превью работает, а в живом — нет», причина редко в глубокой ошибке. Это чаще простое несовпадение настроек между средами, которое упускают из вида.

Главные тайм‑мордоры

Большинство времени уходит на погоню за симптомами (пустой экран, упавший логин, 401), тогда как корень проблемы — базовая конфигурация:

• Callback URL для auth не обновлён под реальный домен. Провайдер разрешает только превью-хост, поэтому в продакшене входы отскакивают или идут в петлю.
• Хардкоднутые превью-URL во фронтенде. Один оставшийся https://preview-xyz... в вызовах API, OAuth или websocket-ах ломает всё на живом домене.
• Секреты попали в браузер. ИИ-созданные приложения иногда помещают приватные ключи в клиентские env-переменные или бандлы. Это ломает продакшен и создаёт уязвимость.
• Превью и продакшен используют разные базы данных. В превью могут быть тестовые данные, а в продакшене — пусто или другая схема.
• Фикс внесён, но не задеплоен. Кэшы сборки, неверная цель деплоя или пропущенные env‑обновления создают видимость, что исправление не сработало.

Реалистичный сценарий: вы исправили несоответствие OAuth callback, но живой сайт всё ещё ломается, потому что фронтенд продолжает звонить на превью API. Две мелкие ошибки, одно запутывающее проявление.

Как не вляпаться в кроличью нору

Прежде чем переписывать код, сделайте эти проверки:

1. Убедитесь, что продакшен-домен указан везде, где ожидает провайдер аутентификации.
2. Поиск по коду на превью-хост и замените его на конфигурацию для продакшена.
3. Разделите переменные окружения на те, что только на сервере, и те, что безопасны для браузера.
4. Убедитесь, что продакшен‑подключение к базе и миграции совпадают с тем, что было в превью.
5. Пересоберите и сбросьте релевантные CDN/кэш, чтобы живой сайт отдавал новую сборку.

В FixMyMess это первые вещи, которые мы смотрим при диагностике — они часто встречаются в ИИ-созданных прототипах и легко пропускаются.

Быстрый чеклист и следующие шаги

Если в превью всё работает, а живой сайт падает, относитесь к проблеме как к несоответствию конфигураций до тех пор, пока не доказано обратное. Чаще всего вы не ищете загадочную ошибку, а разницу между средами.

Начните с базовой проверки на живом домене:

• Убедитесь, что живой домен указывает на нужный деплой (правильный проект, ветка, последняя сборка).
• Сравните prod env vars с превью (API base URL, ключи auth, callback URL, DB URL).
• Откройте живой сайт с консолью и ищите предупреждения HTTPS, петли редиректов и ошибки смешанного контента.
• Протестируйте полный цикл аутентификации на живом сайте (регистрация, вход, выход, обновление). «Работает до обновления» часто указывает на куки или доменные настройки.
• Повторите тесты в приватном окне и на мобильном. Старые куки, закешированные ассеты и service worker могут скрывать реальную проблему.

Простой пример: в превью приложение обращается к http://api.myapp.local (подходяще для dev), а в продакшене страница на HTTPS и API — по HTTP. Браузер блокирует запрос. UI выглядит нормально до клика по кнопке, а затем всё падает.

Если вы не можете локализовать проблему, прекратите гадать и закажите целевой аудит. Быстрые исправления обычно приходят после совместного обзора трёх областей: auth и куки, открытые секреты и общая архитектура (ИИ-сгенерированные прототипы часто содержат спутанные зависимости, которые ломаются при переходе в продакшен).

Если ваш проект был создан с помощью инструментов вроде Lovable, Bolt, v0, Cursor или Replit и теперь ломается на реальном домене, FixMyMess (fixmymess.ai) предназначен именно для таких случаев: мы диагностируем различия между превью и продакшеном и ремонтируем кодовую базу, чтобы она выдержала работу в продакшене.