Как подключить домен к AI-агенту: DNS, HTTPS и reverse proxy без боли
Подключить домен к AI-агенту можно за 30–60 минут: привязываете A-запись домена к IP вашего VPS, ставите reverse proxy (чаще Caddy или Nginx), выпускаете SSL-сертификат, а затем проверяете, что агент отвечает по HTTPS на нужном домене или поддомене. Если сделать это аккуратно, вы получаете не просто «ссылку покрасивее», а нормальный прод-сценарий: свой бренд, предсказуемый доступ, контроль над данными и меньше хаоса при масштабировании.
На практике люди ломаются не на «сложном DevOps», а на мелочах: забыли про AAAA-запись, не открыли 80/443, включили Cloudflare proxy слишком рано, перепутали localhost и внешний IP в конфиге reverse proxy. Ниже — пошаговый маршрут без священного страдания у терминала.
🌐 Зачем вообще подключать домен к AI-агенту?
Если агент живёт на адресе вроде http://123.123.123.123:8000, это тестовый стенд, а не рабочий сервис. Домен решает сразу несколько задач:
- 🏷️ Бренд и доверие. Ссылка вида
agent.company.ruвыглядит как продукт, а не как случайный контейнер на VPS. - 🔒 HTTPS по-человечески. Нормальный SSL поднимается на домене, а не на голом IP.
- 🧩 Гибкая архитектура. Можно повесить агента на поддомен, а API — на отдельный.
- 📈 Масштабирование. Через reverse proxy проще разруливать несколько сервисов на одном сервере.
- 🛡️ Безопасность. Проще ограничить доступ, настроить headers, rate limits и отдельные правила на API.
Особенно это важно для self-hosted AI agent, когда агент крутится у вас на VPS, в Docker или на Ubuntu-сервере, а не в SaaS-сервисе, где половину инфраструктуры скрыли за красивой кнопкой Deploy.
🧭 Что нужно подготовить заранее?
Перед настройкой проверьте базовый набор. Без него статья превращается в древний ритуал «почему не работает».
| Что нужно | Зачем | Минимум |
|---|---|---|
| Домен | Чтобы привязать понятный адрес | Доступ к DNS-записям |
| VPS / сервер | Где живёт агент | Публичный IP, Linux, открытый SSH |
| AI-агент | Сервис, который уже запущен | Например, на localhost:8000 или localhost:3000 |
| Reverse proxy | Маршрутизация и SSL | Caddy или Nginx |
Если агент ещё не запущен локально, сначала поднимите его и убедитесь, что он отвечает по внутреннему адресу. Привязывать домен к мёртвому приложению — занятие для людей с крепкой психикой.
⚙️ Как подключить домен к AI-агенту пошагово?
Вот рабочий порядок для большинства сценариев: Docker, Ubuntu, self-hosted AI agent, OpenClaw-подобные сервисы, кастомные API и веб-интерфейсы.
- 🔹 Проверьте, что агент живой локально. Откройте
curl http://localhost:8000или нужный порт. Пока тут 502/timeout — к домену рано. - 🔹 Создайте DNS A-запись. Укажите домен или поддомен на IPv4-адрес VPS. Пример:
agent.example.ru → 77.73.238.77. - 🔹 При наличии IPv6 настройте AAAA осознанно. Если у сервера нет корректного IPv6, лучше не добавлять AAAA вообще. Иначе часть запросов будет улетать в пустоту.
- 🔹 Откройте порты 80 и 443. Без этого Let’s Encrypt не сможет выпустить сертификат, а HTTPS не поднимется.
- 🔹 Поставьте reverse proxy. Для новичков удобнее Caddy: он сам получает и обновляет SSL. Для более кастомных схем подойдёт Nginx.
- 🔹 Проксируйте домен на локальный порт агента. Reverse proxy должен смотреть на
127.0.0.1:8000,localhost:3000или имя docker-сервиса, если вы внутри compose-сети. - 🔹 Проверьте HTTPS и редирект с HTTP. Сайт должен открываться по
https://, а старыйhttp://— уводить на защищённую версию.
Для Caddy минимальный конфиг выглядит так:
agent.example.ru {
reverse_proxy 127.0.0.1:8000
}Для Nginx логика та же: домен принимает запрос, серверный блок слушает 80/443 и отдаёт трафик приложению. Если агент запущен в Docker, используйте либо проброс порта на localhost, либо внутреннюю docker-сеть с проксированием по имени сервиса.
🛡️ Какие ошибки чаще всего ломают подключение?
Самые частые причины, почему «домен не работает», на самом деле довольно земные:
- 🔹 A-запись уже есть, но указывает не туда. Проверяйте IP через
dig,nslookupили сервисы вроде WhatsMyDNS. - 🔹 AAAA-запись включена зря. Браузер идёт по IPv6, а сервер там не отвечает.
- 🔹 Cloudflare proxy включили до отладки. Сначала добейтесь, чтобы домен работал в режиме DNS only. Потом уже добавляйте оранжевые облачка и правила.
- 🔹 Reverse proxy смотрит не на тот хост. Частая путаница: приложение слушает только внутри контейнера, а Nginx ищет его на внешнем IP.
- 🔹 Порты 80/443 закрыты фаерволом. Сертификат не выпускается, HTTP challenge не проходит, начинается маленькая трагедия.
- 🔹 Смешанный контент. Фронтенд по HTTPS, а API-запросы уходят на HTTP. Браузер это не любит. Совсем.
Отдельно проверьте CORS и webhooks. Если агент общается с Telegram, CRM, формами на сайте или внешними API, домен должен быть прописан согласованно везде: в приложении, reverse proxy и внешних интеграциях.
📊 Что выбрать: поддомен, корень домена или отдельный API-домен?
Тут нет одной святой истины. Есть удобство и поддерживаемость.
| Схема | Когда подходит | Минус |
|---|---|---|
agent.example.ru |
Лучший старт для отдельного AI-агента | Нужно управлять поддоменом отдельно |
example.ru/agent |
Когда всё должно жить на одном сайте | Больше возни с route/path rewrite |
api.example.ru |
Если нужен отдельный API для фронтенда или интеграций | Нужно следить за CORS и auth |
Для большинства компаний разумный старт — поддомен. Он чище, легче отлаживается и не мешает основному сайту.
Если у вас уже есть сайт на основном домене, не пытайтесь в первый же день запихнуть AI-агента в корень через сложные rewrite-правила. Поддомен даёт более чистую диагностику: легче отделить проблемы DNS, приложения и reverse proxy, а ещё проще подключить мониторинг и отдельные правила безопасности.
✅ Какой чеклист пройти перед запуском?
- 🔹 Домен резолвится в нужный IP
- 🔹 Агент отвечает локально без домена
- 🔹 Порты 80 и 443 открыты
- 🔹 HTTPS поднимается без ошибок сертификата
- 🔹 Reverse proxy проксирует на правильный порт
- 🔹 API и веб-интерфейс работают по новому URL
- 🔹 Cloudflare, CDN и кэш включаются только после базовой проверки
Если пройтись по этому списку, подключение домена к AI-агенту обычно перестаёт быть «инфраструктурной магией» и становится обычной инженерной задачей. А это уже куда приятнее. 😏
❓FAQ: что ещё важно знать?
1. Можно ли подключить домен к AI-агенту без Docker?
Да. Docker тут не обязателен. Если агент запущен как systemd-сервис на Ubuntu и слушает локальный порт, домен подключается точно так же через Caddy или Nginx.
2. Что лучше для AI-агента: Caddy или Nginx?
Если нужен быстрый и простой старт — Caddy. Если требуется тонкая настройка rate limit, кастомные upstream-правила и нестандартная логика — Nginx.
3. Нужен ли отдельный домен или хватит поддомена?
Для первого запуска почти всегда хватает поддомена, например agent.company.ru. Это проще и дешевле в поддержке.
4. Почему домен уже добавлен, но сайт всё ещё не открывается?
Скорее всего, DNS ещё не распространился, порт 80/443 закрыт или reverse proxy смотрит не на тот порт приложения.
5. Можно ли использовать Cloudflare перед AI-агентом?
Да, но включайте proxy только после базовой отладки. И отдельно исключайте API-роуты из агрессивного кэширования.
6. Что делать, если агент работает локально, но не открывается по домену?
Проверить DNS, firewall, конфиг reverse proxy и выпуск SSL-сертификата. В 80% случаев проблема именно там, а не в самом AI-агенте.
7. Какой следующий шаг после подключения домена?
Добавить мониторинг доступности, резервные копии конфига и базовую защиту: fail2ban, firewall, ограничение доступа к админке и логирование ошибок.
Если вы разворачиваете self-hosted AI agent для бизнеса, домен — это не косметика, а фундамент. С него начинается нормальная эксплуатация: понятный доступ, HTTPS, интеграции, мониторинг и безопасность. А дальше уже можно спорить о мультиагентности, RAG и прочих красивых словах. Сначала пусть сервис просто работает как взрослый. 🦞
Хотите собрать AI-агента без лишнего хаоса? Подписывайтесь на Telegram: https://t.me/aaakalsin