Поддомен для API и личного кабинета: как не смешать роли

API и кабинет решают разные задачи

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

Обычная схема вроде `app.example.com` и `api.example.com` полезна не ради красоты, а ради контроля. Для каждого имени можно настроить отдельный SSL, CORS, cookies, лимиты, логи, мониторинг и правила reverse proxy. Если проект уже использует несколько зон — сайт, кабинет, API, help и status — стоит свериться со старым материалом про структуру доменов и поддоменов для VPN-сайта.

Где ломаются cookies и CORS

Кабинет часто работает в браузере и зависит от cookies. API может жить рядом, но браузерные правила всё равно требуют аккуратной настройки домена, SameSite, Secure, CORS и заголовков. Если API и кабинет размещены без ясной границы, можно получить странные ошибки: форма входа работает в одном браузере, запросы API падают в другом, а мобильное приложение получает ответ, который предназначался только для веба.

Разделение поддоменов помогает сделать правила явными. Например, `account.example.com` обслуживает интерфейс, а `api.example.com` принимает запросы приложения. При этом CORS должен разрешать только нужные источники, а cookies не должны распространяться шире, чем требуется. Здесь важно понимать, когда поддомены действительно нужны, а когда они только увеличивают число точек отказа.

SSL и мониторинг должны видеть оба имени

Если кабинет открывается по HTTPS, это ещё не значит, что API тоже в порядке. У каждого поддомена должен быть сертификат, правильная цепочка, ожидаемый SNI и мониторинг. Ошибка API может не проявиться на главной странице, но сломать оплату, авторизацию или выдачу подписки.

Для API полезно мониторить не только код 200, но и конкретный health-check. Для кабинета — вход, загрузку статики, редиректы и истечение сессии. Если используется wildcard-сертификат, всё равно нужно знать, какие имена реально существуют и обслуживаются. Иначе wildcard закрывает не архитектуру, а хаос.

Как разложить роли перед запуском

Практическая схема:

1. выписать все публичные имена: сайт, кабинет, API, help, status;

2. назначить владельца для каждого имени: frontend, backend, support, infrastructure;

3. указать DNS-запись и целевой сервис;

4. проверить SSL и CORS отдельно;

5. настроить мониторинг не только главной страницы;

6. зафиксировать, какие cookies и заголовки относятся к кабинету, а какие — к API.

Если поддомены создаются через wildcard, к ним добавляют явный список разрешённых имён. Подробно риски широкого wildcard разобраны в статье про wildcard DNS и поддомены.

Кейс: API скрывался за кабинетом

У проекта был кабинет на `panel.example.com`, а API временно повесили на путь `/api` внутри того же домена. Позже мобильное приложение начало обращаться к этому API напрямую. Когда включили новые cookies для веб-кабинета, часть запросов приложения стала возвращать неожиданные ответы. Разделение на `panel` и `api` помогло развести правила: браузерная сессия осталась в кабинете, а API получил отдельные CORS, лимиты и мониторинг.

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

Разделение ролей перед релизом

API и кабинет имеют разные роли;
cookies не уходят шире нужного домена;
CORS настроен под реальные источники;
SSL проверен на каждом поддомене;
мониторинг проверяет API отдельно от интерфейса;
в документации указано, кто отвечает за каждое имя.

Почему путь `/api` иногда хуже отдельного имени

Путь внутри того же домена кажется проще: не нужно создавать поддомен, выпускать отдельный сертификат или настраивать CORS. Но эта простота быстро заканчивается, когда API начинает жить своим циклом. Ему нужны отдельные лимиты, health-check, логи ошибок, версия, правила кэша и иногда другой backend. Если всё спрятано за путём кабинета, сложнее понять, что именно сломалось: интерфейс, авторизация, API или маршрутизация reverse proxy.

Отдельный поддомен не решает архитектуру сам по себе, но заставляет описать границу. Для команды это полезно: у API появляется собственная проверка доступности, а у кабинета — собственный пользовательский сценарий. Такой подход особенно важен перед включением CDN или WAF, потому что правила для HTML-страницы и API-запросов обычно различаются.

Как развести API и кабинет по разным адресам

Роли имён

Домен для VPN остаётся общей точкой владения, но поддомены VPN распределяют роли. Сайт VPN сервиса обслуживает веб-часть, а домен для VPN сервера — подключение. Адрес VPN сервера не следует использовать как адрес кабинета только ради простоты.

DNS и доступ

DNS для VPN должен указывать на готовый компонент. DNS сервер для VPN в клиенте означает другой уровень настройки. DNS через VPN проверяют после соединения. VPN подписка может обновляться через отдельное имя, поэтому запись API нельзя удалять вместе с ненужной страницей.

TLS и права

Сертификат для VPN выпускают под фактическое имя. Сертификат VPN сервера проверяют в клиенте. Профиль VPN должен ссылаться на нужный адрес. Корпоративный VPN требует отдельных прав для API и администрирования, даже если имена находятся в одной зоне.

Проверка

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

В этой схеме серверная часть — vpn сервер; рядом разобраны vpn подписка и клиентские шаги для vpn для android и vpn для windows.

FAQ о поддоменах API и кабинета

Можно ли держать API и кабинет на одном домене?

Можно, если правила сессий, путей, CORS и мониторинга понятны. Но для зрелого проекта отдельные поддомены обычно удобнее.

Нужно ли API отдельный SSL-сертификат?

Имя API должно быть покрыто сертификатом. Это может быть отдельный сертификат, SAN или wildcard — главное, чтобы имя реально входило в покрытие.

Почему CORS часто всплывает после разделения поддоменов?

Потому что браузер начинает видеть разные origin. API должен явно разрешать нужный источник, а не отвечать всем подряд.

Как понять, что поддомен лишний?

Если у него нет отдельной роли, владельца, мониторинга и правил доступа, возможно, это не поддомен, а лишняя сложность.

Можно ли закрыть API кабинета, оставив доступ только через корпоративный VPN?

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

Можно ли разместить VPN сервер и кабинет на одном поддомене?

Техническая схема зависит от протоколов и маршрутизации, но одинаковое имя не должно смешивать права доступа. Сначала распределите роли: поддомены VPN для кабинета, API и подписки можно обслуживать по-разному. Затем проверьте, как DNS для VPN обрабатывает неизвестные имена, чтобы они не получали лишний доступ по умолчанию.

Источники

---