Статический IP-адрес: когда он нужен, а когда нет

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

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

Статический, выделенный и общий - три разные вещи#

Эти слова используют как взаимозаменяемые, а описывают они разные свойства. Стоит их разделить, и примерно половина путаницы исчезнет сама.

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

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

Что решает имя хоста и чего оно не решает#

DNS-запись превращает адрес в имя, а имена можно менять свободно. play.example.com может указывать сегодня на один адрес, а на следующей неделе на другой, и единственная цена перемены - TTL, то есть число секунд, в течение которых резолверу разрешено хранить старый ответ.

Это решает ту проблему, с которой люди обычно приходят за статическим адресом:

• Игроки и пользователи вводят запоминаемое имя, а не цифры.
• Переезд сервера - правка одной строки, а не сообщение всем.
• Вы можете запускать несколько служб на собственных именах и переносить их независимо.
• Сертификаты выпускаются для имён, а именно это на самом деле требуется для HTTPS.

Чего оно не решает:

• Всего, что проверяет адрес, а не имя. Белый список в банке, сервер лицензий, правило корпоративного файрвола: все они видят адрес, и имя хоста в решении не участвует.
• Всего, что происходит до появления DNS. Устройство, которое нужно настраивать адресом, например некоторые VPN-клиенты и промышленное оборудование.
• Кэширования. Запись с TTL в час устаревает на час после того, как вы её изменили. Снизьте TTL за сутки до запланированного изменения и верните после. Тайминги разобраны в статье DNS-записи простыми словами, а как привязать домен к игровому серверу - это десятиминутная версия настройки.

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

Когда выделенный адрес действительно необходим#

Вот эти случаи. Если вы ни в одном из них, вы покупаете спокойствие.

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

Вам нужен общеизвестный порт, который уже занят. Порты - механизм, позволяющий нескольким арендаторам делить адрес, и этот механизм не срабатывает, когда номер порта не обсуждается. Порт 25 для входящей почты, порт 53 для публичного DNS-сервера, порт 443 для протокола, который не HTTP и потому не может быть маршрутизирован по SNI. Если ваша служба должна быть на порту по умолчанию, а порт по умолчанию занят, вам нужен адрес, где он свободен.

Вы отправляете почту, и вам нужна репутация адреса и rDNS. Почтовые серверы оценивают IP отправителя и проверяют, что его обратный DNS соответствует имени, которым он представляется. Для записи PTR нужен контроль над адресом, который даёт только выделенный. Это самая законная причина его купить - и стоит прямо сказать, что RE:NODE почту не хостит, так что если у вас такой случай, то он не для нас. Остальные настройки описаны в статье SPF, DKIM и DMARC простыми словами.

Вы запускаете собственные неймсерверы. Glue-записи у регистратора - это адреса, и они должны быть стабильны.

Лицензия или устройство привязаны к адресу. Некоторое коммерческое ПО привязывает лицензию к IP, а некоторые аппаратные конфигурации VPN написаны адресами, а не именами.

Вот и весь список. Заметьте, что ни один пункт не звучит как «игровой сервер».

Когда это не имеет значения#

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

Игровой сервер, к которому подключаются по имени хоста. Игроки вводят play.example.com:25565 или используют запись SRV и никогда не видят адрес. Строка подключения уже содержит порт, поэтому общий адрес с другими арендаторами ничего не стоит. Как устроено распределение портов и почему порт запросов - часть того же вопроса, рассказано в статье порты игрового сервера.

Сайт за обратным прокси. Раньше это был самый сильный довод за выделенный адрес, и SNI его закрыл. Поскольку каждый используемый браузер передаёт имя хоста в TLS-рукопожатии, один адрес обслуживает любое число сертификатов. В 2026 году выделенный адрес для HTTPS ничего не даёт. Механизм описан в статье что делает обратный прокси.

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

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

Сокрытие адреса вашего сервера. Выделенный адрес легче опознать, а не труднее. Если цель - скрыться, ответом будет прокси перед службой, а для игры на UDP даже это серьёзное предприятие.

Динамические адреса дома и динамический DNS#

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

Стандартный ответ - динамический DNS: небольшой клиент в вашей сети замечает смену и обновляет DNS-запись через API. TTL записи задан низким - 60 секунд нормально, - чтобы резолверы быстро подхватывали новый ответ.

# What is my current public address, from two independent sources$ curl -4 https://ifconfig.co203.0.113.42$ dig +short myip.opendns.com @resolver1.opendns.com203.0.113.42# What does my hostname currently resolve to$ dig +short A home.example.com203.0.113.42

Во многие домашние роутеры клиент DDNS встроен, под названием вроде Dynamic DNS или DDNS, с заранее перечисленными провайдерами. Если в вашем его нет, ту же работу делает ddclient или inadyn на сервере, а у нескольких DNS-провайдеров есть документированное API обновления, которое можно вызвать пятистрочным скриптом в cron.

Чего DDNS вам стоит, если честно:

• Разрыв при каждой смене. Между изменением адреса и обновлением записи имя указывает на чужое подключение. Обычно это минута-две, дольше, если клиент опрашивает только раз в пятнадцать минут.
• Сеансы за адресом не идут. Уже подключённые игроки разговаривают с адресом, а не с именем. Когда он меняется, все отваливаются и должны зайти заново. DNS этого не предотвращает.
• Устаревший кэш где-то в цепочке. Резолвер, игнорирующий короткие TTL, или игрок, у которого клиент закэшировал адрес, будет продолжать ходить по старому.

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

CGNAT: как распознать и что делать#

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

Диагностика занимает тридцать секунд. Найдите WAN-адрес на странице состояния роутера и сравните его с тем, что показывает сайт вроде ifconfig.co. Если они различаются, между вами и интернетом есть NAT, которым вы не управляете. Окончательный признак - WAN-адрес внутри 100.64.0.0/10: этот диапазон зарезервирован именно для такой цели. Адреса из 10.0.0.0/8 или 192.168.0.0/16 на WAN-интерфейсе означают то же самое.

# The address your router holds, from a machine on the LAN$ ip route get 1.1.1.1$ traceroute -n 1.1.1.1 | head -3

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

Варианты, примерно в порядке того, насколько хорошо они работают:

1. Попросите у провайдера публичный адрес. Многие предоставят его по запросу, иногда бесплатно, иногда за небольшую ежемесячную плату или на бизнес-тарифе. Это чистое решение, и звонок того стоит.
2. Используйте IPv6. CGNAT - проблема нехватки IPv4, а в IPv6 её нет. Загвоздка в том, что IPv6 нужен и вашим игрокам, а у многих его всё ещё нет, так что сервер только на IPv6 молча исключает людей. Как далеко это заведёт сегодня, описано в статье IPv6 и игровые серверы.
3. Ретранслируйте через машину, у которой публичный адрес есть. Небольшой арендованный сервер с туннелем WireGuard и пробросом порта понесёт игровой трафик. Это работает, добавляет задержку на один хоп и означает вторую машину, которую надо обслуживать. Туннельные сервисы делают то же самое для HTTP с меньшими усилиями и обычно UDP не переносят.
4. Арендуйте сервер. У размещённого на хостинге сервера публичный адрес есть по умолчанию, и именно поэтому эта проблема не возникает.

Жизнь на общем адресе#

Если вы на общем хостинге, из этого следуют некоторые практические последствия, и ни одно из них не драматично.

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

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

Обратный DNS не ваш. dig -x 203.0.113.10 вернёт то, что задал хостинг, если он что-то задал. Изменить это вы не можете, а важно это для почты и больше почти ни для чего из того, что делают люди.

Соседи - проблема меньшая, чем принято думать. На правильно организованном хосте один контейнер не видит трафика другого, CPU ограничен купленной долей, а контейнер, у которого закончилась память, останавливается, а не тянет машину за собой. Чему общий адрес действительно подвергает вас - побочному ущербу от потока, направленного на кого-то другого, а это свойство канала, а не адреса.

На RE:NODE адрес и порт каждого сервера показаны на его странице в панели, порты добавляются и убираются на вкладке Network, причём порты запросов и RCON входят в счёт, а каждый сервер - отдельный контейнер со своим жёстким лимитом CPU. Выделенного адреса в каталоге нет, поэтому если ваш случай - один из настоящих, описанных выше, сначала спросите, а не заказывайте и не надейтесь: ответ вполне может быть в том, что он вам не нужен, а может быть и в том, что мы не тот хостинг для именно этого требования.

Переезд и почему имя важнее числа#

В день, когда вы меняете хост или меняете тариф так, что сервер переезжает, адрес меняется. Всё, что знало число, ломается; всё, что знало имя, следует за одной правкой DNS.

Порядок действий:

1. Снизьте TTL записи до 300 секунд за сутки до переезда.
2. Дождитесь истечения старого TTL, чтобы каждый кэш подхватил короткий.
3. Перенесите данные при остановленных обоих серверах.
4. Измените запись и оставьте старый сервер доступным ещё на несколько часов для тех, у кого устаревший ответ или сохранённый адрес.
5. Верните TTL обратно, когда всё уляжется.

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

FAQ#

Нужен ли статический IP для игрового сервера?

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

Чем статический IP отличается от выделенного?

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

Как понять, что я за CGNAT?

Сравните WAN-адрес на странице состояния роутера с тем, что публичный сайт показывает как ваш адрес. Если они различаются или если WAN-адрес роутера лежит в 100.64.0.0/10, вы за carrier-grade NAT, и проброс портов не сработает.

Можно ли использовать динамический DNS вместо статического адреса?

Да, и для домашнего сервера это обычный ответ. Клиент обновляет DNS-запись при каждой смене адреса, с коротким TTL, чтобы это вступало в силу быстро. Ждите краткого разрыва при каждой смене и отключения для всех, кто подключён в этот момент.

Нужен ли выделенный IP для SSL-сертификата?

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

Подвергает ли общий адрес мой сервер риску со стороны других клиентов?

Не так, как ожидают люди. Контейнеры изолированы, а CPU ограничен на каждый сервер. Единственная реальная общая уязвимость - объёмная атака на канал, которая затрагивает всех на нём независимо от того, как распределены адреса.