Что меняется, когда сайтов становится больше
У одного проекта сайт и API работают на одном сервере. У другого кабинет вынесен отдельно, а старые адреса должны перенаправлять посетителей на новые. Обратный прокси (reverse proxy) принимает запрос и передаёт его нужному приложению по правилам конфигурации. Когда проектов много, перед изменением приходится восстанавливать, какой файл за что отвечает и где он уже применён.
В Goose Edge настройка строится вокруг домена, приложений и маршрутов. В панели можно изменить адрес сервера, задать путь запроса, выбрать сертификат и опубликовать настройки на шлюзы. При этом Goose Edge управляет своими шлюзами: это не редактор любых установленных у Вас Nginx и не автоматический импортёр их конфигураций.
Пример: сайт, кабинет и API на одном домене
Рассмотрим условный проект project.example. Основные страницы обслуживает сайт, запросы к /api — отдельное приложение, а старый адрес кабинета должен перенаправлять на новый. Это учебный пример, а не история внедрения у клиента.
| Запрос | Правило в панели | Что проверить |
|---|---|---|
/api/orders | Маршрут по префиксу /api → приложение API | Ожидает ли приложение полный путь /api/orders или только /orders |
/old-account | Точный путь → перенаправление на новый кабинет | Верный адрес назначения и отсутствие цепочки перенаправлений |
| Остальные пути | Запасной маршрут → приложение сайта | Главная, внутренние страницы, изображения и страница ошибки |
Для проксирования можно сохранить исходный путь или убрать его префикс. Это небольшая настройка с заметным результатом: если API ждёт /orders, а получает /api/orders, соединение может работать, но приложение вернёт ошибку. Аналогичная разница есть у proxy_pass в Nginx: поведение зависит от указанного в нём URI. Описание в документации Nginx.
Реальный интерфейс с демонстрационными данными. Скриншот можно открыть крупнее; состав полей зависит от версии панели.
Как перенести настройки из Nginx
Начните с одного проекта и выпишите его действующее поведение. Сам файл конфигурации нужен инженеру, но для проверки удобнее таблица: адрес посетителя, приложение назначения, перенаправления и ожидаемый результат.
- Соберите доменные имена. Учтите основной адрес,
wwwи поддомены, которые действительно используются. Проверьте, какие имена покрывает сертификат. - Опишите приложения. Для каждого нужны адреса серверов, протокол и порт. Если серверов несколько, уточните способ распределения запросов и проверку их доступности.
- Разберите маршруты. Сопоставьте точные пути, префиксы и запасной маршрут. Отдельно проверьте порядок правил, сохранение пути и перенаправления.
- Выпишите особенности. Загрузка больших файлов, длительные запросы, WebSocket, нестандартные заголовки и дополнительные модули требуют отдельной проверки совместимости. Наличие функции в старой конфигурации не означает её автоматический перенос.
- Подготовьте сертификат и доступ к приложению. Шлюз должен подключаться к серверу по согласованной схеме. Открывать приложение всему интернету ради переноса не требуется по умолчанию.
Сохранение, публикация и работа сайта — три отдельные проверки
Сохранённые изменения ещё не означают, что их применили шлюзы. После редактирования проверьте настройки и состояние публикации. Затем выполните запросы через новую точку входа: успешная публикация не доказывает, что вход в кабинет или обработка заявки работают правильно.
Для примера выше проверка включает открытие страницы сайта, запрос к API, переход со старого адреса кабинета и обращение к несуществующей странице. Если сайт принимает файлы или получает обращения от внешних систем, эти сценарии тоже должны пройти до переключения посетителей.
Порядок проверки до изменения DNS и условия возврата разобраны в чек-листе подключения сайта к Goose Edge. Защиту WAF лучше настраивать отдельным этапом: сначала проверить обычные действия пользователей, затем разбирать срабатывания и включать блокировку.
Что остаётся в работе команды
После переключения в панели можно смотреть запросы, ошибки, задержки и инциденты. Это помогает отличить проблему конкретного маршрута от недоступности приложения. Если требуется узнать, почему приложение возвращает неверные данные, понадобятся его собственные журналы и диагностика.
Назначьте ответственного за публикацию, за приложение и за реакцию на уведомления. При следующем изменении проходите тот же короткий цикл: правка, проверка, публикация, пользовательский сценарий. Как организовать контроль доступности и сроков сертификатов, описано в отдельном материале.