Дополнительный IPv4 на VPS не всегда начинает работать автоматически после покупки. Провайдер может выдать адрес в панели биллинга, привязать его к серверу на своей стороне, но внутри операционной системы IP все равно нужно добавить вручную. Из-за этого многие клиенты боятся покупать дополнительные IPv4: кажется, что после оплаты адрес будет непонятно как включать.

На практике настройка обычно занимает несколько минут, если понимать три вещи: какой сетевой интерфейс используется на сервере, какой менеджер сети управляет конфигурацией и в каком виде провайдер маршрутизирует дополнительный IP. В большинстве VPS-сценариев дополнительный IPv4 добавляется на основной сетевой интерфейс с маской /32 и без отдельного gateway.

Эта инструкция подходит для Ubuntu и Debian на VPS. Она закрывает базовые сценарии: временно проверить дополнительный IPv4, сделать постоянную настройку через Netplan, через /etc/network/interfaces и через systemd-networkd, а также понять, почему IP может не пинговаться после настройки.

Что важно понять перед настройкой

Дополнительный IPv4 — это не отдельный сервер и не обязательно отдельная сетевая карта. Чаще всего это еще один адрес, который нужно добавить на уже существующий интерфейс, например ens3, eth0, enp1s0 или ens18.

Основной IPv4 сервера обычно уже настроен автоматически при выдаче VPS. Его трогать не нужно, если сервер работает и SSH доступен. Главная задача — добавить новый адрес рядом с основным, не ломая текущий gateway, DNS и существующую маршрутизацию.

Самая частая ошибка — полностью заменить текущий сетевой конфиг примером из инструкции. Так делать нельзя. Нужно сначала посмотреть, как сеть настроена сейчас, сделать резервную копию файла и только потом добавить новый IPv4.

Что понадобится

• Доступ к VPS по SSH.
• Дополнительный IPv4, выданный провайдером.
• Основной сетевой интерфейс сервера.
• Доступ к VNC/HTML5 console в панели провайдера, если есть риск потерять SSH.
• Понимание, какой способ настройки сети используется: Netplan, ifupdown или systemd-networkd.

Если вы используете VPS HSTQ и не хотите настраивать сеть вручную, можно обратиться в поддержку. Для клиентов с дополнительными IPv4 мы можем помочь с базовой привязкой адресов к серверу и проверкой маршрутизации, если это предусмотрено вашим тарифом и условиями услуги.

Безопасный порядок настройки

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

• Сначала определите основной интерфейс.
• Потом временно добавьте дополнительный IPv4 командой ip addr add.
• Проверьте, отвечает ли адрес.
• Только после этого внесите настройку постоянно.
• Не добавляйте второй default gateway для дополнительного IPv4.
• Не удаляйте текущий основной IP.
• Не перезагружайте сервер до проверки конфига.

Шаг 1. Узнать имя сетевого интерфейса

Выполните команду:

ip -br addr

Пример вывода:

lo               UNKNOWN        127.0.0.1/8 ::1/128
ens3             UP             185.000.000.10/24

В этом примере основной интерфейс — ens3. У вас он может называться eth0, enp1s0, ens18 или иначе.

Еще один полезный способ определить интерфейс, через который сервер выходит в интернет:

ip route get 1.1.1.1

Пример:

1.1.1.1 via 185.000.000.1 dev ens3 src 185.000.000.10

Здесь видно, что внешний трафик идет через интерфейс ens3. Именно на него обычно нужно добавлять дополнительный IPv4.

Шаг 2. Проверить текущую сетевую систему

На Ubuntu Server чаще всего используется Netplan. На Debian часто встречается /etc/network/interfaces. На некоторых VPS может использоваться systemd-networkd. Иногда конфигурацию сети генерирует cloud-init.

Проверьте Netplan:

ls -la /etc/netplan/

Если в каталоге есть YAML-файлы, например 50-cloud-init.yaml или 00-installer-config.yaml, вероятно, сеть управляется через Netplan.

Проверьте классический Debian ifupdown:

cat /etc/network/interfaces

Если там описан основной интерфейс, например iface ens3 inet static или iface ens3 inet dhcp, значит сеть может управляться через /etc/network/interfaces.

Проверьте systemd-networkd:

systemctl is-active systemd-networkd
networkctl status

Если systemd-networkd активен и интерфейс отображается как managed, конфигурация может находиться в /etc/systemd/network/.

Шаг 3. Временно добавить дополнительный IPv4

Перед постоянной настройкой лучше проверить IP временно. Эта команда добавит адрес до перезагрузки или до перезапуска сети.

Замените ADDITIONAL_IP на ваш новый IPv4, а ens3 на имя вашего интерфейса:

sudo ip addr add ADDITIONAL_IP/32 dev ens3

Пример:

sudo ip addr add 203.0.113.50/32 dev ens3

Проверьте, появился ли IP на интерфейсе:

ip -br addr show ens3

Проверьте исходящий запрос именно с дополнительного IPv4:

curl --interface ADDITIONAL_IP https://ifconfig.me

Если в ответе отображается ваш дополнительный IPv4, адрес работает для исходящего трафика.

Проверить пинг с дополнительного IPv4 можно так:

ping -I ADDITIONAL_IP -c 4 1.1.1.1

Если временная настройка работает, можно переходить к постоянной конфигурации.

Важный момент про входящий и исходящий трафик

То, что IP добавлен на интерфейс, еще не означает, что все сервисы автоматически начнут использовать его как исходящий адрес. Многие приложения используют основной IP сервера, если явно не указать bind/listen на дополнительный адрес.

Например, proxy-сервер, VPN-панель, nginx, Xray, 3X-UI, Marzban, Docker-контейнер или другой сервис может требовать отдельной настройки bind address. Если сервис должен слушать именно дополнительный IPv4, это нужно указать в настройках самого сервиса.

Проверить, какие адреса слушают сервисы, можно так:

ss -lntup

Если сервис слушает 0.0.0.0, он принимает подключения на всех IPv4 сервера. Если он слушает только основной IP или 127.0.0.1, дополнительный IPv4 нужно указать в конфиге сервиса отдельно.

Вариант 1. Ubuntu с Netplan

На Ubuntu Server сеть часто управляется через Netplan. Конфиги находятся в /etc/netplan/ и имеют расширение .yaml.

Сначала сделайте резервную копию текущего конфига:

sudo cp -a /etc/netplan /etc/netplan.backup.$(date +%F-%H%M%S)

Откройте текущий YAML-файл:

ls -la /etc/netplan/
sudo nano /etc/netplan/50-cloud-init.yaml

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

Netplan: если основной IP получен по DHCP

Если основной IPv4 сервер получает по DHCP, а дополнительный IPv4 нужно добавить вручную, пример может выглядеть так:

network:
  version: 2
  ethernets:
    ens3:
      dhcp4: true
      addresses:
        - 203.0.113.50/32

Если дополнительных IPv4 несколько:

network:
  version: 2
  ethernets:
    ens3:
      dhcp4: true
      addresses:
        - 203.0.113.50/32
        - 203.0.113.51/32
        - 203.0.113.52/32

После изменения проверьте конфиг:

sudo netplan generate

Затем примените безопасно через netplan try:

sudo netplan try

Если связь не пропала и все работает, подтвердите применение. Если что-то пошло не так, Netplan откатит изменения.

Если netplan try недоступен или не подходит, используйте:

sudo netplan apply

Netplan: если основной IP настроен статически

Если основной IP уже прописан статически, не удаляйте его. Нужно добавить дополнительный IPv4 в список addresses.

Пример:

network:
  version: 2
  ethernets:
    ens3:
      addresses:
        - 185.000.000.10/24
        - 203.0.113.50/32
        - 203.0.113.51/32
      routes:
        - to: default
          via: 185.000.000.1
      nameservers:
        addresses:
          - 1.1.1.1
          - 8.8.8.8

В этом примере 185.000.000.10 — основной IP сервера, 185.000.000.1 — основной gateway, а 203.0.113.50 и 203.0.113.51 — дополнительные IPv4.

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

Вариант 2. Debian через /etc/network/interfaces

На Debian часто используется классическая настройка через /etc/network/interfaces. Сначала сделайте резервную копию:

sudo cp -a /etc/network/interfaces /etc/network/interfaces.backup.$(date +%F-%H%M%S)

Откройте файл:

sudo nano /etc/network/interfaces

Debian: если основной IP настроен через DHCP

Пример для DHCP и одного дополнительного IPv4:

auto lo
iface lo inet loopback

auto ens3
iface ens3 inet dhcp
    post-up ip addr add 203.0.113.50/32 dev $IFACE || true
    pre-down ip addr del 203.0.113.50/32 dev $IFACE || true

Для нескольких дополнительных IPv4:

auto lo
iface lo inet loopback

auto ens3
iface ens3 inet dhcp
    post-up ip addr add 203.0.113.50/32 dev $IFACE || true
    post-up ip addr add 203.0.113.51/32 dev $IFACE || true
    post-up ip addr add 203.0.113.52/32 dev $IFACE || true
    pre-down ip addr del 203.0.113.50/32 dev $IFACE || true
    pre-down ip addr del 203.0.113.51/32 dev $IFACE || true
    pre-down ip addr del 203.0.113.52/32 dev $IFACE || true

Debian: если основной IP настроен статически

Пример статической настройки:

auto lo
iface lo inet loopback

auto ens3
iface ens3 inet static
    address 185.000.000.10
    netmask 255.255.255.0
    gateway 185.000.000.1
    dns-nameservers 1.1.1.1 8.8.8.8
    post-up ip addr add 203.0.113.50/32 dev $IFACE || true
    post-up ip addr add 203.0.113.51/32 dev $IFACE || true
    pre-down ip addr del 203.0.113.50/32 dev $IFACE || true
    pre-down ip addr del 203.0.113.51/32 dev $IFACE || true

После изменения можно перезапустить интерфейс, но на удаленном VPS это рискованно. Безопаснее иметь открытую VNC/console-сессию в панели провайдера.

Применение через ifreload доступно не всегда. Если установлен пакет ifupdown2, можно использовать:

sudo ifreload -a

Если ifreload нет, перезапуск сети может оборвать SSH:

sudo systemctl restart networking

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

Вариант 3. systemd-networkd

Некоторые VPS используют systemd-networkd. Конфиги обычно находятся в /etc/systemd/network/.

Проверьте файлы:

ls -la /etc/systemd/network/

Пример DHCP-конфига с дополнительными IPv4:

[Match]
Name=ens3

[Network]
DHCP=yes
Address=203.0.113.50/32
Address=203.0.113.51/32

Пример статического конфига:

[Match]
Name=ens3

[Network]
Address=185.000.000.10/24
Address=203.0.113.50/32
Address=203.0.113.51/32
Gateway=185.000.000.1
DNS=1.1.1.1
DNS=8.8.8.8

Применить изменения можно так:

sudo networkctl reload
sudo networkctl reconfigure ens3

Если изменения не применились, может потребоваться перезапуск systemd-networkd:

sudo systemctl restart systemd-networkd

На удаленном VPS перезапуск сетевого сервиса лучше делать только при наличии консоли, потому что ошибка в конфиге может оборвать SSH.

Что делать, если cloud-init перезаписывает сеть

На некоторых VPS сетевой конфиг генерируется cloud-init. В Ubuntu это часто видно по файлу /etc/netplan/50-cloud-init.yaml. Иногда ручные изменения могут быть перезаписаны после пересоздания сервера, смены конфигурации или повторной инициализации cloud-init.

Проверьте cloud-init:

cloud-init status
ls -la /etc/cloud/cloud.cfg.d/

Если cloud-init управляет сетью, не удаляйте его вслепую. Сначала убедитесь, что у вас есть рабочий постоянный Netplan-конфиг. Только после этого можно отключать управление сетью через cloud-init.

Типовой файл для отключения сетевой конфигурации cloud-init:

sudo nano /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg

Содержимое:

network: {config: disabled}

После этого нужно убедиться, что Netplan-конфиг полностью описывает рабочую сеть сервера. Если отключить cloud-init без корректного сетевого конфига, после перезагрузки можно потерять доступ к VPS.

Как проверить, что дополнительный IPv4 работает

Проверьте, что IP добавлен на интерфейс:

ip addr show dev ens3

Проверьте маршруты:

ip route

Проверьте исходящий трафик с дополнительного IPv4:

curl --interface 203.0.113.50 https://ifconfig.me

Проверьте пинг с дополнительного IPv4:

ping -I 203.0.113.50 -c 4 1.1.1.1

Проверьте входящую доступность с другого сервера или локального компьютера:

ping 203.0.113.50

Если на IP должен отвечать веб-сервер, проверьте:

curl -I http://203.0.113.50

Если на IP должен работать proxy/VPN/панель, проверьте, что сервис слушает нужный адрес и порт:

ss -lntup

Почему IP добавлен, но не работает

Если дополнительный IPv4 добавлен в систему, но не работает, причина не всегда в Ubuntu или Debian. Нужно проверить несколько уровней: маршрутизацию у провайдера, локальную сеть сервера, firewall, настройки сервиса и bind address.

• IP не привязан к VPS на стороне провайдера.
• IP добавлен не на тот интерфейс.
• В конфиге указан неправильный prefix, например /24 вместо /32 или наоборот.
• Добавлен лишний default gateway.
• Netplan YAML содержит ошибку в отступах.
• Firewall блокирует входящий трафик.
• Сервис слушает только основной IP или 127.0.0.1.
• cloud-init перезаписал конфигурацию после reboot.
• Провайдер использует нестандартную схему маршрутизации для дополнительных IP.
• В панели провайдера для дополнительного IP требуется отдельная привязка, virtual MAC или route-настройка.

Проверка firewall

Если IP пингуется с сервера, но не доступен снаружи, проверьте firewall.

Для UFW:

sudo ufw status verbose

Для nftables:

sudo nft list ruleset

Для iptables:

sudo iptables -S

Если вы используете панель управления, например HestiaCP, 3X-UI, Marzban, Docker или другую систему, у нее могут быть свои правила firewall. В таком случае нужно проверять не только системный firewall, но и правила самой панели.

Как использовать дополнительный IPv4 для конкретного сайта в nginx

Если nginx должен слушать сайт на дополнительном IPv4, укажите этот IP в listen.

server {
    listen 203.0.113.50:80;
    server_name example.com;

    root /var/www/example.com;
    index index.html index.php;
}

Для HTTPS:

server {
    listen 203.0.113.50:443 ssl http2;
    server_name example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    root /var/www/example.com;
    index index.html index.php;
}

Если nginx слушает 0.0.0.0:80 и 0.0.0.0:443, он принимает подключения на всех IPv4 сервера. Но для отдельных сайтов, клиентов или панелей часто удобнее явно указывать нужный IP.

Как использовать дополнительный IPv4 для исходящих запросов

Для разовой проверки можно использовать curl:

curl --interface 203.0.113.50 https://ifconfig.me

Для приложений лучше настраивать исходящий IP внутри самого приложения, если оно поддерживает bind address. Это правильнее, чем ломать системную маршрутизацию ради одного сервиса.

Если нужно, чтобы весь трафик от конкретного дополнительного IP шел с ним же как source address, может потребоваться policy routing. Это уже более продвинутая настройка и она зависит от схемы провайдера. Без понимания gateway и маршрутизации лучше не применять такие правила вслепую.

Пример временного policy routing

Этот пример подходит не для всех VPS. Используйте его только если понимаете, какой gateway должен использовать сервер.

sudo ip rule add from 203.0.113.50/32 table 100
sudo ip route add default via 185.000.000.1 dev ens3 src 203.0.113.50 table 100

Проверить:

ip rule
ip route show table 100
curl --interface 203.0.113.50 https://ifconfig.me

Удалить временные правила:

sudo ip rule del from 203.0.113.50/32 table 100
sudo ip route flush table 100

Если вам просто нужно, чтобы proxy, nginx, VPN или другой сервис работал на отдельном IP, чаще всего policy routing не нужен. Достаточно добавить IP на интерфейс и настроить bind/listen в приложении.

Нужно ли перезагружать VPS

Обычно перезагружать VPS не нужно. После изменения Netplan, interfaces или systemd-networkd достаточно применить сетевой конфиг. Но после постоянной настройки полезно сделать controlled reboot в момент, когда у вас есть доступ к консоли, чтобы убедиться, что дополнительный IPv4 сохраняется после перезагрузки.

Проверка после reboot:

ip -br addr
ip route
curl --interface 203.0.113.50 https://ifconfig.me

Частые ошибки

• Редактировать сетевой конфиг без резервной копии.
• Не проверить имя интерфейса и добавить IP на неправильный dev.
• Скопировать чужой Netplan-конфиг целиком и потерять основной IP.
• Сделать ошибку в YAML-отступах.
• Добавить отдельный gateway для каждого дополнительного IP.
• Использовать старый формат eth0:0 вместо нормального добавления адреса.
• Не проверить, что IP привязан к VPS на стороне провайдера.
• Не проверить firewall.
• Ожидать, что сервис автоматически начнет использовать новый IP без bind-настройки.
• Отключить cloud-init до создания рабочего постоянного сетевого конфига.

Как быстро восстановить доступ, если сеть сломалась

Если после изменения сети SSH пропал, используйте VNC/console в панели провайдера. Дальше откатите конфигурацию из резервной копии.

Для Netplan:

sudo rm -rf /etc/netplan
sudo cp -a /etc/netplan.backup.YYYY-MM-DD-HHMMSS /etc/netplan
sudo netplan apply

Для Debian /etc/network/interfaces:

sudo cp -a /etc/network/interfaces.backup.YYYY-MM-DD-HHMMSS /etc/network/interfaces
sudo systemctl restart networking

Если сеть была сломана временной командой ip addr add, достаточно удалить адрес:

sudo ip addr del 203.0.113.50/32 dev ens3

Если вы не уверены, какой файл сломан, сначала посмотрите текущие адреса и маршруты:

ip -br addr
ip route
systemctl status systemd-networkd
systemctl status networking

Когда лучше не настраивать вручную

Если у вас production-сервер, нет VNC/console, нет опыта с Netplan или вы не уверены в схеме маршрутизации провайдера, лучше не экспериментировать на рабочей машине. Ошибка в сетевом конфиге может отрезать SSH и остановить сервисы.

Также не стоит вручную настраивать десятки или сотни IP по одному без нормального плана. Если вам нужно много IPv4, лучше заранее обсудить подсеть, /24, IP-rent, dedicated server или BYOIP/BGP. Для крупных проектов адреса нужно планировать как сетевую инфраструктуру, а не как случайный список IP в конфиге.

Что написать в поддержку, если IP не работает

Чтобы поддержка быстро проверила проблему, не пишите просто “IP не работает”. Лучше сразу отправить технические данные.

• Основной IP сервера.
• Дополнительный IPv4, который не работает.
• Операционная система: Ubuntu или Debian, версия.
• Вывод команды ip -br addr.
• Вывод команды ip route.
• Какой способ настройки используется: Netplan, interfaces или systemd-networkd.
• Проверяли ли curl --interface ADDITIONAL_IP https://ifconfig.me.
• Проверяли ли firewall.
• Нужен ли IP для входящего трафика, исходящего трафика или конкретного сервиса.

Пример нормального обращения:

Hello. I added additional IPv4 203.0.113.50 to VPS 185.000.000.10 on interface ens3 as /32. The address is visible in ip addr, but curl --interface 203.0.113.50 https://ifconfig.me does not work. Please check if this IPv4 is routed to my VPS from your side.

Минимальный рабочий чеклист

• Узнать интерфейс через ip -br addr.
• Временно добавить IP через ip addr add ADDITIONAL_IP/32 dev INTERFACE.
• Проверить curl --interface ADDITIONAL_IP https://ifconfig.me.
• Определить сетевой менеджер: Netplan, interfaces или systemd-networkd.
• Сделать резервную копию текущего конфига.
• Добавить IP в постоянный конфиг.
• Применить изменения безопасным способом.
• Проверить IP после перезагрузки.
• Настроить bind/listen в нужном сервисе.
• Проверить firewall и внешнюю доступность.

Дополнительные IPv4 на VPS не являются сложной задачей, если не трогать основной IP, не добавлять лишний gateway и сначала проверять адрес временно. Для одного или нескольких IP обычно достаточно добавить адреса на основной интерфейс. Для десятков и сотен IPv4 лучше заранее планировать подсеть, dedicated server, IP-rent или BYOIP/BGP, чтобы не превращать рабочую инфраструктуру в набор ручных правок.

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