На сервере уже работает сайт, а вы хотите добавить магазин, API и ещё несколько проектов. Покупать IP для каждого из них обычно не требуется: один публичный IPv4-адрес может обслуживать несколько сайтов, HTTPS-сертификатов и приложений. Дополнительные адреса нужны, когда сервисам действительно требуется отдельный адрес для подключения или выхода в интернет.

Какие адреса мы считаем

Публичные IP используются для подключения через интернет. Частные адреса, например 10.0.0.10 и 192.168.1.20, работают внутри сети. У десятка контейнеров могут быть разные внутренние IP, но наружу они будут выходить через один публичный адрес. Это позволяет NAT — преобразование сетевых адресов.

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

IPv4 и IPv6 — разные версии протокола. IPv6 позволяет давать сервисам собственные адреса, но сам по себе не обеспечивает доступ клиентам, у которых есть только IPv4. Поэтому наличие одного IPv4 и одного IPv6 не означает, что вы получили два взаимозаменяемых адреса.

Когда хватает одного IP, а когда нужны дополнительные

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

Как разместить несколько сайтов на одном IP

DNS связывает домен с адресом сервера. Несколько доменов могут указывать на один IPv4. Дальше веб-сервер выбирает нужный сайт по имени в запросе: для этого в Nginx настраивают отдельные блоки server с server_name, в Apache — виртуальные хосты.

Для HTTPS используется SNI: клиент сообщает доменное имя ещё при установлении защищённого соединения. Сервер выбирает сертификат для этого имени. Современные браузеры поддерживают SNI; обязательного требования покупать IP под каждый сертификат нет. Можно использовать отдельные сертификаты для доменов или один сертификат, покрывающий несколько имён.

Если приложения работают на разных внутренних портах, перед ними ставят reverse proxy — сервер, который принимает внешние запросы и передаёт их нужному приложению. Например, запросы к shop.example идут в магазин, а к api.example — в API. Снаружи оба доступны по обычному HTTPS-порту 443.

Для такой схемы нужны доступ к DNS, настройкам веб-сервера или панели управления и сертификаты для всех используемых имён. В панели добавляйте самостоятельный сайт, если нужен другой проект: добавление домена как псевдонима существующего сайта может лишь открыть прежний сайт под новым именем.

После настройки проверьте каждый домен. Для прямого подключения к серверу его DNS-запись A должна указывать на выбранный IPv4. Если используется CDN или внешний прокси, публичный DNS может показывать адреса этого сервиса — это нормально.

Проверить сайт на конкретном IP до изменения DNS можно с компьютера вне сервера, где установлен curl. Ниже условный пример: замените домен и адрес своими.

curl --noproxy '*' --connect-timeout 10 -v --resolve shop.example:443:203.0.113.10 https://shop.example/

Команда направляет запрос на указанный IP, сохраняя доменное имя для HTTPS и выбора сайта. Адрес 203.0.113.10 зарезервирован для примеров и не подходит для реального подключения.

• Вернулся нужный сайт, сертификат прошёл проверку: этот домен работает на выбранном IP. Повторите проверку для остальных доменов, затем проверьте обычное открытие через DNS.
• Открылся другой сайт: проверьте соответствие домена виртуальному хосту и настройку сайта по умолчанию. Новый IP обычно не требуется.
• Сертификат выдан для другого домена: проверьте, покрывает ли сертификат запрошенный домен и назначен ли нужному сайту. Отключение проверки через -k не исправляет HTTPS.
• Нет соединения: проверьте доступность порта 443, правила межсетевого экрана и адрес, на котором слушает веб-сервер. При намеренном запрете прямого доступа к серверу выполняйте проверку через разрешённый путь.

Открытие голого IP в браузере не заменяет эту проверку: сервер может показать сайт по умолчанию, отклонить запрос или выдать сертификат, предназначенный для доменного имени.

Что делать, если сервисам нужен одинаковый порт

Разные приложения могут работать на одном IP, если используют разные порты. Но два независимых сервиса обычно не могут одновременно занять одинаковую комбинацию адреса, порта и протокола. Номер порта TCP и такой же номер UDP при этом относятся к разным протоколам.

Сначала выясните, умеет ли клиент подключаться к нестандартному порту. Если умеет, можно назначить одному сервису другой внешний порт. Для сайтов удобнее общий reverse proxy. Для игровых серверов, VPN и других протоколов возможность такого разделения нужно проверять отдельно: добавление второго домена в DNS само по себе не направит соединение в другое приложение.

Если оба сервиса должны использовать одинаковый порт и подходящего прокси нет, назначьте им разные IP и привяжите каждый к своему адресу. Перед изменением посмотрите текущие привязки. На Linux это можно сделать так:

sudo ss -lntup

В колонке Local Address:Port запись 0.0.0.0:443 означает прослушивание порта 443 на всех локальных IPv4-адресах. Такая привязка может мешать второму сервису даже после добавления IP. В настройках первого приложения потребуется указать конкретный адрес, затем запустить второй сервис на другом и проверить оба с внешнего клиента.

Для Docker дополнительно проверьте публикацию портов:

docker ps --format "table {{.Names}}\t{{.Ports}}"

Публикация без выбранного IP обычно действует на всех адресах хоста. Уточните привязку в ports файла Compose или параметре -p. Это также помогает не открыть внутренний сервис через новый публичный адрес.

Почему новый IP не меняет адрес исходящих запросов

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

Если проекту нужен конкретный исходящий IP, настройте выбор адреса в приложении либо правило SNAT — замену адреса отправителя на сетевом шлюзе. Например, в Postfix исходящий IPv4 задаётся параметром smtp_bind_address: в main.cf для SMTP-клиентов экземпляра или в master.cf для конкретного транспорта. У контейнеров нужно учитывать настройки сети Docker, а не только публикацию входящего порта.

В обсуждении на Server Fault в 2025 году пользователь описал именно такую ситуацию: дополнительный IP и отдельный SMTP-сервер в IIS не изменили адрес отправки. Установка hMailServer также не решила задачу. Позже автор сообщил о рабочем варианте с Postfix и управлением исходящими адресами. Этот случай показывает, почему покупку IP нужно сопровождать настройкой программы, которая будет его использовать.

Проверяйте результат со стороны получателя. Выполните запрос из самого приложения или контейнера и посмотрите IP в журнале принимающего сервиса. Если там остался основной адрес, проверяйте настройку исходящего соединения и правила NAT по пути. Запрос из терминала хоста не подтверждает, что контейнер или почтовый процесс использует тот же маршрут.

Нужен ли отдельный IP для почты

Количество почтовых доменов само по себе не определяет число IP. Разделение адресов имеет смысл, когда требуется отдельно управлять исходящими потоками, например транзакционными письмами и подписными рассылками. При этом репутация домена и IP — разные составляющие доставки: новый адрес не гарантирует попадание во «Входящие».

У каждого исходящего адреса должна быть корректная обратная DNS-запись PTR: она связывает IP с именем почтового сервера. Это имя должно разрешаться обратно в тот же IP. Также настройте SPF — список разрешённых отправителей домена, DKIM — подпись писем, и DMARC — политику проверки домена отправителя. Эти настройки описаны, например, в требованиях Gmail к отправителям. Проверяйте тестовое письмо на стороне получателя: фактический IP отправки, результаты проверки подлинности и причину отказа, если письмо отклонено.

Если сайт отправляет только редкие уведомления и письма восстановления пароля, сравните собственную почтовую инфраструктуру с внешним SMTP-сервисом. Выделенные адреса требуют работы с репутацией; распределение небольшого объёма по множеству IP может усложнить доставку. Например, Amazon SES рекомендует общий пул для небольших объёмов. Это рекомендация для его сервиса, а не универсальная числовая граница для любой почтовой системы.

Чего дополнительные IP не дают

Больше ресурсов. Второй IP не добавляет процессор, память или пропускную способность. Если серверу не хватает мощности, нужно менять конфигурацию, оптимизировать приложение или распределять нагрузку между машинами.

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

Изоляцию приложений. Разные IP помогают разделить подключения и сетевые правила, но процессы всё равно могут использовать общую ОС, данные и ресурсы. Для изоляции нужны отдельные права доступа, настройки безопасности, а при необходимости — контейнеры или виртуальные машины.

Что уточнить перед заказом и подключением

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

1. Посчитайте доступные клиенту адреса. Общее число IP в подсети может отличаться от количества, которое разрешено назначить сервисам: это зависит от схемы подключения и резервирования служебных адресов.
2. Получите параметры подключения. Нужны точные адреса, маска или префикс, шлюз либо маршруты, а для виртуализации — правила подключения гостевых машин. Нельзя брать произвольный соседний IP: он может принадлежать другому клиенту.
3. Уточните ограничения под задачу. Для почты — возможность настройки PTR и условия исходящих SMTP-соединений; для резервирования — условия переноса адреса; для виртуальных машин — требования к маршрутизации и сетевым интерфейсам.
4. Сравните полную стоимость. Учитывайте ежемесячную плату за адреса, возможную плату за подключение и время на настройку. Сравните это с использованием одного IP, прокси или внешнего почтового сервиса.

Перед изменением сетевых настроек сохраните рабочую конфигурацию и проверьте доступ к консоли сервера через панель провайдера. Используйте его инструкцию для вашей ОС, сохраняйте основной адрес до проверки нового. Если после применения настроек пропадёт SSH, через консоль восстановите сохранённую конфигурацию. После подключения проверьте сервис извне и убедитесь, что адрес прописан в постоянной конфигурации, а не добавлен только до перезагрузки.

Если нужен один дополнительный адрес, сначала уточните возможность его подключения к существующему серверу. Для проектов с обоснованной потребностью в пуле адресов можно рассмотреть аренду IPv4 в HSTQ. До заказа согласуйте число используемых IP, площадку, схему подключения и PTR: на странице услуги возможности небольших блоков и подсетей от /24 различаются.