VPS без IPv4 может стоить дешевле, но экономия легко исчезает после первой несовместимой интеграции. Сервер запускается, сайт открывается с вашего телефона, а из офисной сети к нему уже не подключиться. Или приложение работает, пока ему не понадобится скачать обновление с ресурса, доступного только по IPv4.
IPv6-only подходит для задач, у которых проверены все нужные соединения. Для публичного сайта можно организовать доступ через прокси, для нескольких внутренних серверов — использовать общий шлюз. Если же нужен один VPS для разных приложений и неизвестного заранее круга пользователей, двойной стек часто оказывается проще в обслуживании.
Чтобы выбрать подходящую схему, нужно ответить на два вопроса: кто будет подключаться к серверу и куда будет обращаться сам сервер. После этого можно считать экономию.
За что вы платите и уменьшится ли счёт без IPv4
IPv4 обычно оплачивается как выделенный публичный адрес. Но у провайдеров разная тарификация: где-то это отдельная строка, где-то адрес включён в стоимость VPS, а где-то есть отдельная линейка серверов без IPv4.
Если отключить IPv4 в операционной системе, платёж автоматически не исчезнет. Нужно, чтобы провайдер действительно снял платную услугу или перевёл сервер на подходящий тариф. Даже отвязанный от сервера адрес может оставаться отдельным оплачиваемым ресурсом.
Сравнивайте предложения с одинаковыми CPU, памятью, диском и трафиком. Разница между двумя тарифами не обязательно целиком связана с IP.
Полезная формула:
Экономия за месяц = стоимость убранных IPv4 − дополнительные расходы на шлюзы, прокси, трафик и обслуживание.
Допустим, отказ от одного IPv4 уменьшает счёт на $2 в месяц. Отдельный сервер, который будет соединять вашу инфраструктуру с IPv4-сетью, стоит $5 вместе с адресом. Цифры условные: в расчёт нужно подставить своё предложение.
| Сценарий | Экономия на адресах | Новые расходы | Разница за месяц |
|---|---|---|---|
| Один VPS и новый отдельный шлюз | $2 | $5 | Расходы вырастут на $3 |
| Десять VPS и один общий шлюз | $20 | $5 | Экономия $15 |
| Десять VPS и два шлюза для резервирования | $20 | $10 | Экономия $10 |
Здесь ещё не учтена работа администратора. Если настройка обойдётся в $60, при экономии $15 в месяц она окупится за четыре месяца, без учёта дальнейшего обслуживания. При этом наличие двух шлюзов само по себе не создаёт резервирование: переключение между ними тоже нужно настроить и проверить.
Если подходящий шлюз или прокси уже работает, дополнительные расходы могут быть меньше. Но проверьте запас производительности, стоимость трафика и последствия его отказа для остальных серверов.
IPv6-only, общий IPv4 и двойной стек — разные варианты
В описании тарифа важно различать следующие схемы:
- Двойной стек, или dual stack. Сервер имеет подключение по IPv4 и IPv6. Он может напрямую взаимодействовать с сетями обоих типов.
- IPv6-only без шлюза в IPv4. Публичное подключение сервера работает по IPv6. Для связи с IPv4-only узлами нужен дополнительный посредник.
- IPv6-only с NAT64. Сервер отправляет IPv6-трафик на шлюз, который обеспечивает соединение с IPv4-сервисами. Возможности зависят от настройки сети и приложения.
- VPS с общим IPv4 через NAT. У сервера может быть внутренний IPv4, а наружу несколько клиентов выходят через общий публичный адрес. Входящие порты предоставляются по условиям тарифа.
Поэтому фраза «без выделенного IPv4» ещё не описывает всю сеть. Спросите, доступен ли исходящий IPv4-трафик, как он организован и можно ли принимать входящие соединения.
Если ваша цель — сократить количество платных публичных адресов, полный переход на IPv6 может вообще не понадобиться. Несколько серверов можно соединить частной IPv4-сетью и оставить публичный адрес только на общем шлюзе или балансировщике. Это стоит сравнить с IPv6-only, если провайдер поддерживает такую архитектуру.
Кому подходит VPS только с IPv6
| Задача | Когда IPv6-only подходит | Что может помешать |
|---|---|---|
| Тестовая среда, учебный сервер | У вас есть IPv6-доступ и возможность восстановить сервер через консоль. | Недоступные репозитории, установщики и отсутствие IPv6 в сети, из которой вы администрируете VPS. |
| Внутренний сервис, база данных, обработчик заданий | Все участники системы связаны по IPv6 либо через заранее настроенную внутреннюю сеть. | Внешнее хранилище, мониторинг или другой обязательный компонент работает только по IPv4. |
| Публичный сайт | Перед сервером есть прокси или CDN, принимающий посетителей по IPv4 и IPv6 и умеющий обращаться к серверу по IPv6. | Прямые подключения, неподдерживаемые протоколы, ограничения прокси и его доступность для аудитории. |
| Бот, n8n, интеграция с API | Проверены все внешние API, получение событий, отправка сообщений и обновление приложения. | Хотя бы один обязательный сервис или программный компонент требует IPv4. |
| VPN, удалённый рабочий стол, игровой сервер | Клиенты имеют IPv6 либо используется подходящий шлюз, который поддерживает нужный протокол. | Пользователь подключается из IPv4-only сети и не имеет пути до сервера. |
| Собственный почтовый сервер | Продумана совместимость с отправителями и получателями, включая обмен с IPv4-only почтовыми системами. | Неполная доступность почтовых узлов, ограничения SMTP и требования к репутации отправителя. |
Для одного рабочего VPS с почтой, VPN и несколькими интеграциями разумно сначала посчитать стоимость IPv4 на весь год. Если она меньше стоимости настройки и сопровождения обходных путей, двойной стек будет практичнее.
Как подключаться к серверу, если дома или в офисе нет IPv6
Поддержка IPv6 в Windows, Linux или телефоне не означает, что IPv6 предоставляет ваш оператор. Нужны работающий маршрут, настройки оборудования и доступность конкретного адреса VPS.
Первую проверку можно выполнить на компьютере, с которого вы будете работать:
curl -6 --connect-timeout 10 --max-time 20 https://api6.ipify.orgВ Windows PowerShell при необходимости используйте curl.exe. Если сервис вернул IPv6-адрес, соединение по IPv6 до этой точки прошло. Затем проверьте сам VPS:
ssh -6 user@server.exampleЗамените пользователя и домен своими значениями. У домена должна быть корректная AAAA-запись с адресом сервера. Успешный тест одного внешнего сайта не заменяет проверку маршрута до вашего хостинга.
Если IPv6 в вашей сети отсутствует, возможны промежуточный сервер с двойным стеком, корпоративный шлюз или VPN-сервис, который принимает ваше подключение по IPv4 и предоставляет путь к IPv6-сети. У каждого варианта есть стоимость и настройка.
Установка VPN на тот же недоступный IPv6-only VPS не решает проблему первого подключения: сначала клиент должен суметь добраться до VPN-сервера.
До отказа от IPv4 проверьте консоль в панели провайдера. Она пригодится при ошибке маршрута или firewall. При этом консоль для аварийного восстановления не заменяет удобный рабочий доступ по SSH или RDP.
Будет ли сайт доступен посетителям без IPv6
Если домен указывает только на IPv6-адрес VPS и соединение идёт напрямую, посетитель без IPv6 не сможет открыть сайт. DNS сообщает адрес, но не преобразует один сетевой протокол в другой.
Для публичного сайта можно использовать такую схему:
Посетитель по IPv4 → прокси с IPv4 и IPv6 → VPS по IPv6
Посетитель соединяется с прокси, а тот устанавливает отдельное соединение с вашим сервером. Такая архитектура позволяет обслуживать IPv4-клиентов без собственного IPv4 на каждом сервере приложения.
Проверьте, поддерживает ли выбранный CDN или обратный прокси IPv6-серверы, нужные порты, WebSocket, размеры загрузок и длительность запросов. Если используете Cloudflare, отличайте режим проксирования от DNS-only: во втором случае посетитель получает адрес сервера и подключается напрямую.
Обычное веб-проксирование не обеспечивает автоматически доступ к SSH, почте, RDP или произвольному UDP-сервису. Для них требуется отдельная подходящая схема.
После настройки откройте сайт из IPv4-only сети и проверьте вход, формы, загрузку файлов и другие рабочие действия. Если сайт принимает вебхуки от платёжной системы или CRM, отправьте тестовое событие из самой системы. Открытая главная страница ещё не подтверждает, что уведомления доходят и обрабатываются.
Обратный прокси решает входящий доступ к сайту. Если приложение на VPS само должно обратиться к IPv4-only API, для этого понадобится отдельный исходящий путь.
Можно ли получить HTTPS-сертификат без IPv4
Да. Например, Let’s Encrypt поддерживает IPv6 и для обращения к API выпуска сертификатов, и для проверки домена.
Для HTTP-01 должны работать правильная AAAA-запись и доступ к проверочному файлу по HTTP на порту 80. При DNS-01 подтверждение выполняется через TXT-запись; проверьте, что ваш ACME-клиент может обращаться к API DNS-провайдера из выбранной сети.
Проверьте также автоматическое продление. При двойном стеке неправильная AAAA-запись может ломать проверку домена, даже если сайт по IPv4 открывается нормально.
Как IPv6-only серверу обращаться к IPv4-only сервисам
Распространённый вариант — DNS64 вместе с NAT64. Они выполняют разные функции:
- DNS64 создаёт синтетический IPv6-ответ для домена, у которого есть IPv4-адрес, но нет собственного IPv6-адреса.
- NAT64 принимает соединение к этому адресу и преобразует трафик для связи с IPv4-сервисом.
VPS по IPv6 → NAT64-шлюз → внешний сервис по IPv4
Просто прописать DNS64 недостаточно. Из вашей сети должен быть доступен подходящий NAT64-шлюз, а используемый DNS64 должен соответствовать его настройке. Публичный DNS64-сервис сам по себе не предоставляет такой шлюз.
До заказа уточните у провайдера, входит ли NAT64 в услугу, какие протоколы и порты поддерживаются, есть ли ограничения трафика и соединений. Для рабочих интеграций также важен исходящий IPv4 шлюза: именно его увидит внешний сервис.
Если этот адрес общий, ограничения по IP и его репутация могут зависеть от других пользователей. Если партнёр разрешает подключения только с заранее указанного IPv4, нужно согласовать постоянный исходящий адрес. После этого экономию следует пересчитать.
DNS64 не исправляет все приложения. Программа, которая обращается к IPv4-адресу напрямую или умеет создавать только IPv4-соединения, может продолжить выдавать ошибку. Для таких случаев существуют дополнительные механизмы, включая CLAT и 464XLAT, но их поддержку на конкретном VPS нужно проверять отдельно.
Обычная схема DNS64 и NAT64 предназначена для соединений, которые начинает ваш сервер. Она не создаёт автоматически публичный IPv4, по которому клиенты смогут подключаться к нему снаружи.
Почему бот работает, а установка или обновление не проходит
У приложения обычно больше сетевых зависимостей, чем кажется. Сам API может поддерживать IPv6, а сервер авторизации, файловое хранилище, репозиторий пакетов или адрес скачивания обновления — требовать другого пути.
Поэтому проверяйте весь цикл: установку с нуля, получение ключей и токенов, рабочие запросы, скачивание файлов, обновление и восстановление из резервной копии. Развёртывание из локального кеша не подтверждает, что сервер сможет заново скачать нужные компоненты.
Для бота различайте два сценария. При опросе API соединение начинает VPS. При получении вебхука внешний сервис сам обращается к вашему адресу. Для второго сценария нужно отдельно проверить входящую доступность.
В n8n также недостаточно открыть редактор. Запустите реальные сценарии: авторизацию интеграций, получение событий и отправку данных. Одна несовместимая обязательная интеграция может сделать IPv6-only неудобным для всего проекта.
Docker нужно проверять отдельно от самого VPS
Работающий IPv6 на хосте не гарантирует такого же подключения внутри контейнера. Сеть Docker, DNS контейнера, маршрутизация и публикация портов имеют собственные настройки.
Выполните сетевую проверку из рабочего контейнера и проверьте приложение через опубликованный порт. Если запрос проходит на VPS, но не проходит в контейнере, сначала исследуйте контейнерную сеть.
Не копируйте в конфигурацию чужой IPv6-диапазон из инструкции. Адреса и схема маршрутизации должны соответствовать вашей инфраструктуре. После изменений проверьте повторный запуск контейнеров и восстановление проекта на чистом сервере.
Для почты важны оба направления
Почтовый сервер только с IPv6 не сможет напрямую обмениваться почтой с IPv4-only узлами. Это касается и отправки, и приёма: если MX указывает на сервер, имеющий только AAAA, IPv4-only отправителю нужен дополнительный путь доставки.
Для уведомлений приложения можно использовать внешний SMTP-сервис, доступный по IPv6 или через согласованный шлюз. При собственном почтовом сервере дополнительно нужны PTR, корректные прямые DNS-записи, SPF, DKIM, DMARC и проверка доставки.
Отсутствие платы за IPv4 не отменяет обслуживание почты. Для небольшого проекта внешний почтовый сервис часто стоит сравнить с самостоятельной настройкой всей этой схемы.
Как проверить совместимость до переноса проекта
Лучше поднять отдельный тестовый VPS в той сетевой конфигурации, которую собираетесь использовать. Эксперимент с отключением IPv4 на единственном рабочем сервере может одновременно лишить вас приложения и доступа для исправления.
-
Проверьте доступ администратора. Подключитесь из офиса, дома и резервной сети. Убедитесь, что консоль провайдера действительно открывается.
-
Составьте список внешних зависимостей. Включите API, OAuth, репозитории, контейнерные образы, SMTP, хранилище резервных копий, мониторинг и лицензирование ПО.
-
Посмотрите DNS нужных сервисов. Если установлен dig, выполните:
dig +short api.example A dig +short api.example AAAAЗамените домен своим. Наличие только A-записи означает, что для этой точки нужен доступ к IPv4. Наличие AAAA позволяет перейти к проверке соединения, но ещё не доказывает работу приложения. При использовании DNS64 ответ AAAA может быть синтетическим.
-
Выполните запрос из среды приложения. Например:
curl -6 -v --connect-timeout 10 --max-time 30 https://api.example/Network is unreachableуказывает на отсутствие подходящего маршрута в этой среде. Ошибка разрешения имени требует проверки DNS. Тайм-аут не позволяет сразу назвать причину: нужно проверить маршрут, firewall и доступность другой стороны. Если получен HTTP 401 или 403, HTTP-ответ уже пришёл — дальше разбирайте авторизацию и правила сервиса. -
Проведите рабочие операции. Установите приложение с нуля, отправьте запросы к API, получите вебхук, загрузите файл и отправьте уведомление. Проверяйте содержимое результата, а не только код HTTP 200.
-
Проверьте обслуживание. Перезагрузите тестовый сервер, заново запустите приложения, создайте резервную копию и восстановите её. Убедитесь, что мониторинг видит именно нужные службы.
Зафиксируйте для каждой зависимости: работает напрямую по IPv6, работает через конкретный шлюз или пока не работает. Если обязательный компонент остался в последней категории, переносить рабочую систему рано.
Что меняется в настройке и безопасности
Для IPv6 нужны корректные адрес, маршрут, DNS и правила доступа. Шлюз и способ настройки берите из документации своей площадки: рабочая конфигурация одного провайдера может не подходить другому.
Проверьте, что приложение слушает IPv6. Например, запись 0.0.0.0:443 обозначает IPv4-прослушивание; одного такого слушателя недостаточно для прямого HTTPS-доступа по IPv6.
Правила firewall, которые относятся только к IPv4, не защищают IPv6. Проверьте фильтрацию в операционной системе, панели провайдера и контейнерной сети.
При этом нельзя без разбора блокировать весь ICMPv6. Его сообщения нужны для нормальной работы IPv6, включая обнаружение соседних узлов и определение допустимого размера пакетов. Ошибочная фильтрация может проявляться как зависание отдельных соединений или передачи файлов.
Двойной стек требует проверки обеих сетевых конфигураций. Это не два независимых канала связи: IPv4 и IPv6 могут зависеть от одного сервера, оборудования и оператора. IPv6 также не гарантирует большей скорости — сравнивайте реальные маршруты и работу приложения.
Как перейти и сохранить возможность отката
Начните с тестовой копии или одного некритичного сервиса. Подключите выбранные шлюзы и прокси, проверьте доступ пользователей и исходящие запросы. Только после этого переносите рабочую нагрузку.
Если начинаете с двойного стека, успешная работа приложения ещё не подтверждает готовность к отказу от IPv4: оно могло незаметно использовать именно его. Нужна проверка в среде, где доступна только запланированная схема соединений.
До освобождения старого IPv4 уточните, можно ли сохранить его на время перехода и вернуть при откате. После отмены адрес может стать недоступен для повторного назначения. Также выясните, потребуется ли остановка VPS при последующем добавлении IPv4.
При переносе сайта учитывайте кеширование DNS. Старый адрес нельзя отдавать другому пользователю, пока часть клиентов ещё может обращаться к нему по действующим записям.
Что спросить у хостинга перед заказом
Запрос лучше строить вокруг приложения и соединений:
Планирую разместить [приложение] на [количество] VPS. Входящие подключения будут от [пользователи и сервисы], исходящие — к [API, репозитории, SMTP и хранилища]. Прошу сравнить стоимость двойного стека и варианта без выделенного IPv4. Уточните доступность IPv6 на выбранной площадке, наличие NAT64 или общего исходящего IPv4, ограничения портов и трафика, доступ к консоли и возможность добавить IPv4 позднее. Настройку шлюза и сопровождение прошу указать отдельными строками.
При подборе VPS в HSTQ передайте этот список зависимостей вместе с требованиями к ресурсам. Возможность конкретной сетевой схемы и изменение цены при отказе от IPv4 нужно подтвердить для выбранной площадки. Настройка приложений и постоянное администрирование согласуются отдельно от базовой аренды.
Переход имеет смысл, когда после проверки у вас остаётся измеримая экономия, все обязательные соединения работают и понятно, кто обслуживает новую схему. Если ради одного адреса приходится покупать несколько дополнительных услуг, сохранение IPv4 может обойтись дешевле.
