zap-hosting ZAP-Hosting GmbH продаёт арендуемые мощности, которые по-прежнему зависят от стоек, транзита и ремонтных окон

Резюме

• У ZAP-Hosting GmbH есть конкретный юридический, продуктовый и маршрутный след. Ввыходных данныхуказана ZAP-Hosting GmbH по адресу Hafenweg 8, 48155 Мюнстер, Германия, с Марвином Клуком в качестве генерального директора и номером HRB 15672 в участковом суде Мюнстера, а записи RIPE связывают AS206996 с ZAP-Hosting GmbH.
• Компания продаёт широкий набор арендуемых мощностей:VPS-хостингс KVM, NVMe/SSD-накопителями, DDoS-защитой и заявленной связностью 40 Гбит/с;хостинг выделенных серверовна физическом «железе» с сетевыми картами 10 Гбит/с;серверный хостингдля сценариев VPS, root-серверов и игровых серверов; а также игровые и голосовые продукты в большем числе локаций, чем парк выделенных серверов.
• Публичная карта локаций — это не единое глобальное облако. Вдокументации по локациямуказано, что Франкфурт/Эйгелсховен — единственная локация, где одновременно доступны игровые серверы, TeamSpeak, VPS и выделенные серверы; Лос-Анджелес, Даллас и Ашберн поддерживают игровые серверы, TeamSpeak и VPS; Лондон, Монреаль, Сидней и Сингапур поддерживают игровые серверы и TeamSpeak, но в этой матрице — не VPS и не выделенные серверы.
• Сетевые свидетельства убедительны в части идентичности и активной маршрутизации.Обзор ASв RIPEstat определяет AS206996 как zap-hosting ZAP-Hosting GmbH, астатус маршрутизациина момент публикации 12 июля 2026 года показывал 85 префиксов IPv4, 21 760 IPv4-адресов и три префикса IPv6 с полной видимостью в RIPE RIS.
• Свидетельства об отказоустойчивости более ограничены.Условиягарантируют 99,5 % средней годовой доступности серверов, но исключают проблемы вне контроля ZAP, оставляют за компанией право блокировать или удалять сервисы после задержек оплаты и возлагают на клиента ответственность за сохранность данных.Документация по резервному хранилищуописывает полезное резервное хранилище, но это не то же самое, что проверенный план восстановления всего сервиса.

Обещание ZAP — скорость, но зависимость у неё физическая

ZAP-Hosting GmbH продаёт скорость как свойство продукта. Публичная навигация опирается на «сервер онлайн мгновенно»;страница VPSговорит, что виртуальный частный сервер на Linux или Windows можно развернуть в течение нескольких минут;страница серверного хостингастроит каталог вокруг VPS, root-серверов и игровых серверов; астраница выделенных серверовобещает физическое «железо» тем, кому нужен полноценный аппаратный сервер, а не виртуализированное разделение. Витрина рассчитана на рынок, который часто покупает быстро: игровые сообщества, группы FiveM, пользователи TeamSpeak, разработчики, небольшие веб-проекты, операторы ботов и клиенты, которым нужен root-доступ без переговоров о колокации.

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

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

Именно поэтому ZAP стоит рассматривать как провайдера арендуемых мощностей, а не только как веб-магазин.Выходные данныекомпании дают юридический якорь: ZAP-Hosting GmbH, Hafenweg 8, 48155 Мюнстер, Германия, с Марвином Клуком в качестве генерального директора, HRB 15672 в участковом суде Мюнстера, номером плательщика НДС DE 320366231 и контактами для жалоб и обращений в органы. Еёполитика конфиденциальностиповторяет тот же адрес компании и сообщает, что сайт собирает данные серверных логов — тип браузера, операционную систему, реферер, посещённые страницы, дату, время и IP-адрес — по техническим причинам. Эти страницы не доказывают отказоустойчивость инфраструктуры, но они устанавливают, что витрина, юридический оператор и поверхность данных аккаунта — часть одного немецкого коммерческого периметра.

Страницы продуктов превращают юридическую идентичность в вопрос об инфраструктуре.Страница выделенных серверовговорит, что выделенные серверы — это полностью физические машины, а не виртуальные серверы, делящие хост, с опциями класса Intel Xeon E5v2, до 256 ГБ RAM, SSD-накопителями и сетевыми картами 10 Гбит/с SFP+ в рекламируемых конфигурациях. На той же странице сказано, что выделенные серверы включают доступ ILO, аппаратный RAID, DDoS Manager, обратный DNS и управление IP, а также автоматическое управление отказами, которое уведомляет техников при аппаратных дефектах. Это не облачные лозунги. Это напоминание о том, что сервис зависит от конкретного оборудования и от людей, способных его отремонтировать.

Страница VPSуказывает в другом направлении. Она представляет виртуализацию KVM, AMD EPYC Milan, NVMe/SSD-накопители, DDoS-защиту, безлимитный трафик на условиях fair use, обратный DNS, опции удалённого рабочего стола и связность до 40 Гбит/с. Клиент, покупающий этот продукт, арендует не всю машину, а долю хоста, хранилища и сети, чья производительность зависит от плотности размещения на хосте, контроля «шумных соседей», конкуренции за хранилище, DDoS-фильтрации, программной автоматизации и объёма незадействованных мощностей в выбранной локации. ZAP может продавать и VPS, и выделенные серверы под одним брендом, потому что коммерческая витрина общая. Сценарии отказов — нет.

Поэтому лучшее прочтение публичных материалов ZAP не циничное и не доверчивое. Реальные свидетельства об инфраструктуре есть. Названные места, модели оборудования, маршрутные записи, поставщики DDoS, инструменты резервного копирования и каналы поддержки. Но слово «хостинг» не говорит клиенту, защищён ли его сервис от отказа стойки, вышестоящего оператора, несостоявшегося продления оплаты, неудачного восстановления, переполненной локации или очереди поддержки после регионального инцидента. Эти вопросы нужно задавать на уровне продукта и локации.

Карта локаций — это карта продуктов, а не единое облако

Данные ZAP о локациях необычно конкретны для массового хостинг-провайдера, но их нужно читать как матрицу продуктов, а не как гарантию глобального дата-центра.Документация по локациямговорит, что ZAP расширяет сервисы с момента основания в 2010 году и поддерживает глобальную сеть, сформированную спросом клиентов. Затем указана доступность по продуктам: Франкфурт/Эйгелсховен, DE поддерживает игровые серверы, TeamSpeak, VPS и выделенные серверы; Лондон, UK поддерживает игровые серверы и TeamSpeak, но не VPS и не выделенные серверы; Лос-Анджелес, Даллас и Ашберн поддерживают игровые серверы, TeamSpeak и VPS, но не выделенные серверы; Монреаль, Сидней и Сингапур в таблице поддерживают игровые серверы и TeamSpeak, но не VPS и не выделенные серверы.

Это разделение меняет разговор об отказоустойчивости. Карта, которая говорит, что у ZAP есть локации в Германии, США, Великобритании, Канаде, Австралии и Сингапуре, — это не то же самое, что карта, где клиент может разместить один и тот же тип нагрузки в каждом регионе. Это значит, что игровое сообщество может выбрать регион с нужной задержкой, а клиент выделенного сервера — нет. Это значит, что VPS-клиент может выбрать регионы США, а клиент выделенного сервера — нет. Это значит, что у немецкого клиента выделенного сервера практических вариантов переезда внутри продуктового набора ZAP может быть меньше, чем у клиента игрового сервера.

Публичные страницы продуктов говорят о том же более конкретно. Настранице VPSZAP описывает Даллас, Ашберн и Лос-Анджелес как локации с собственным оборудованием и сетевой технологией внутри площадок Psychz, а также описывает франкфуртскую/эйгелсховенскую площадку как основную немецкую инфраструктуру ZAP. Настранице выделенных серверовраздел локаций сосредоточен на FFM/Эйгелсховене, Германия, с выделенным «железом», коммутаторами Juniper и основной локацией во Франкфурте-на-Майне. Это сильный немецкий сигнал, а не доказательство взаимозаменяемых глобальных выделенных мощностей.

Для клиентов матрицу локаций стоит превратить в заявление о размещении сервиса. Если заказан игровой сервер — какой регион на самом деле обслуживает игроков? Если VPS — какой из поддерживаемых регионов VPS используется и можно ли его перенести без переустановки или смены публичных адресов? Если выделенный сервер — является ли практическое размещение только Германией? Если root-сервер или пакет веб-пространства — какие страница и условия применяются? Если сервис рекламируется как «пожизненный» — что произойдёт, если он неактивен или локация изменена?

Матрица важна и для суверенитета данных. ZAP — немецкая компания, но не каждый сервис на хостинге ZAP обязательно находится в Германии. Игровой сервер в Сингапуре, сервис TeamSpeak в Лондоне, VPS в Далласе и выделенный сервер во Франкфурте/Эйгелсховене имеют разные юридические и операционные истории размещения.Политика конфиденциальностиполезна для данных сайта и аккаунта, но вопрос о размещении рабочей нагрузки требует доказательств по конкретному сервису: где лежат файлы, где хранятся резервные копии, где ведутся логи, где поддержка может получить доступ к системе и где фильтруется трафик.

Это первый практический урок. Клиенту стоит спрашивать не только «Есть ли у ZAP глобальные локации?», а «Какой продукт доступен в выбранной мной локации, какие мощности там установлены, какие функции там недоступны и что произойдёт, если мне нужно переехать?». Компания даёт достаточно публичной информации, чтобы начать такой запрос. Она не делает запрос ненужным.

Франкфурт/Эйгелсховен — главная история мощностей

Немецкая локация — центр публичной инфраструктурной истории ZAP.Страница VPSговорит, что ZAP предлагает собственную серверную инфраструктуру с собственной сетью и выделенным оборудованием в основной локации во Франкфурте-на-Майне, и что компания была основана в этой локации в 2010 году. Там также сказано, что дата-центр SkyLink уровня Tier III в Эйгелсховене, недалеко от Ахена и прямо на границе с Нидерландами, был открыт в марте 2020 года как филиал франкфуртского дата-центра, и что весь трафик идёт через Франкфурт, поэтому клиенты получают преимущества качества соединения и DDoS-защиты.Страница выделенных серверовповторяет ту же немецкую привязку и указывает франкфуртский адрес: Dieselstrasse 37, 60314 Франкфурт-на-Майне.

Эта формулировка полезна, потому что показывает клиентам, где находится очевидная немецкая зависимость. Это не просто «Германия» как ярлык страны. Это операционная пара Франкфурт/Эйгелсховен, где публичная страница говорит, что трафик Эйгелсховена маршрутизируется через Франкфурт. Если клиенту важны размещение, задержка, DDoS-фильтрация, окна обслуживания или разнообразие маршрутов, это имеет значение. Франкфурт может быть точкой концентрации трафика и защиты, даже если оборудование физически стоит в Эйгелсховене. Отказ филиального объекта — это не то же самое, что отказ на трафик-пути, от которого зависит филиал.

Аппаратные детали тоже конкретны. На продуктовых страницах ZAP описаны коммутаторы Juniper, блейд-системы HP C7000 G3 ProLiant, блейды HP G8/G9, процессоры E5-2690v2/v4, память ECC и коммутация 10G SFP+ для немецкой инфраструктуры. Эти утверждения не доказывают текущие запасы по каждой стойке, но показывают тип продаваемого парка: блейд-шасси, общая коммутация, выделенные машины, хост-серверы виртуализации и оборудование частной сети.

Отказ блейд-шасси, коммутатора верхнего уровня стойки, событие с давлением на хранилище или нехватка мощностей будут влиять на клиентов по-разному в зависимости от того, купили ли они VPS, игровой сервер или выделенный сервер.

Немецкая история DDoS — то место, где публичные страницы требуют аккуратного чтения.Страница VPSистраница выделенных серверовописывают DDoS-защиту Combahton с предварительной фильтрацией Corebackbone во Франкфурте и Эйгелсховене с декабря 2019 года. Более новаядокументация по DDoS-защитеговорит, что в разных локациях развёрнуты разные системы защиты, и перечисляет PletX для FFM/Эйгелсховена. Более подробнаястраница о DDoS-защите PletXговорит, что защита настраивается под каждую локацию дата-центра, а публичныйсайт PletXописывает DDoS-защиту для игровых серверов и корпоративных сетей.

Этот видимый сдвиг не стоит читать как скандал: провайдеры меняют поставщиков фильтрации, а документация может стареть неравномерно. Его стоит читать как вопрос об уверенности. Клиент, размещающий в Германии чувствительный к задержкам или подверженный атакам игровой сервис, должен спросить, какой DDoS-стек активен для заказанного сервиса сейчас, где происходит фильтрация, есть ли видимость атак в реальном времени в DDoS Manager, как обрабатываются ложные срабатывания и проходит ли трафик в Эйгелсховен по-прежнему через Франкфурт.

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

То же касается ремонта. На странице выделенных серверов ZAP упоминается автоматическое управление отказами, которое уведомляет техников после аппаратных дефектов. Это ценно для замены оборудования. Это не то же самое, что опубликованный норматив времени восстановления для каждого компонента. Замена блейда, диска, RAID-контроллера или коммутатора может быть быстрой только если сходятся запчасти, удалённые руки, права доступа и время персонала. Для клиентов, использующих дешёвые выделенные серверы как производственную инфраструктуру, ремонтное окно — часть цены.

Локации в США — это арендованная география, а не независимость собственной площадки

Американский след ZAP описан с другой границей.Страница VPSговорит, что в Далласе ZAP переехала в дата-центр Psychz в Техасе со своим оборудованием и сетевой технологией, коммутаторами Juniper EX3300 с аплинками 4x10G SFP+, серверами Dell R720 с процессорами Xeon, сильной DDoS-защитой и первой линией поддержки в дата-центре с техником круглосуточно. Указан далласский адрес: 1515 Round Table Dr, Dallas, TX 75247.

Для Ашберна та же страница описывает дата-центр Psychz в Вирджинии, оборудование и сетевую технологию ZAP, коммутаторы Juniper QFX5100 с аплинками 40G QSFP+, серверы HP C7000 Bladecenter и локальную первую линию поддержки с техниками круглосуточно. Указан адрес Psychz Network: 3873 Park Center Rd #75, Herndon, VA 20171. Для Лос-Анджелеса страница снова описывает дата-центр Psychz в Калифорнии, коммутаторы Juniper QFX5100 и серверы HP C7000 Bladecenter, с адресом на 700 Wilshire Boulevard.

Это сильные сигналы о локациях. Они говорят покупателю, что американский VPS-охват — не просто ярлык CDN или строка реселлера в панели. Страницы заявляют оборудование и сетевую технологию, принадлежащие ZAP, в названных площадках Psychz. В то же время они показывают границу оператора. Сама площадка, физический доступ, первая линия поддержки на месте и часть апстрим-условий — не просто внутреннее дело ZAP. Они зависят от хостера дата-центра, локального процесса remote hands, локального DDoS-пути, наличия запчастей или их доставки и любых договорённостей о кроссконнекте или апстриме в этой площадке.

Эта граница нормальна для хостинга. Небольшие и средние провайдеры часто размещают собственные серверы и коммутаторы в чужих дата-центрах. Риск клиента не в том, что эта модель нелегитимна. Риск в том, чтобы принять «собственное оборудование» за полную операционную независимость. Если у площадки Psychz проблема с питанием, доступом, безопасностью, remote hands или апстримом, клиент ZAP может пережить это как инцидент сервиса ZAP, даже если ключевой шаг ремонта находится вне прямых рук ZAP.

Документация по DDoS добавляет ещё одну границу.Основная документация по DDoSговорит, что ZAP использует разные системы защиты в зависимости от локации дата-центра и сетевой инфраструктуры. Сейчас на странице сравнения она перечисляет PletX для FFM/Эйгелсховена и OVH для Лондона/Сингапура, а текст страницы продукта для Ашберна описывает собственное фильтрующее оборудование с программным обеспечением aurologic, доработанным во Франкфурте. Такая смесь должна заставить клиентов спросить, какой путь фильтрации использует конкретная американская локация сегодня. Игровой сервер под атакой не потерпит расплывчатого ответа о «сильной DDoS-защите».

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

Игровой и голосовой охват не стоит путать с глубиной серверного парка

Самое широкое географическое обещание ZAP — в игровом и голосовом хостинге.Документация по локациямперечисляет Лондон, Монреаль, Сидней и Сингапур для игровых серверов и TeamSpeak, даже там, где доступность VPS и выделенных серверов отмечена как недоступная. Это логично для рынка. Игровые и голосовые сообщества сильно зависят от задержки, и провайдер может поддерживать эти продукты в регионах, где не предлагает полный каталог VPS или физических серверов.

Ошибкой было бы принимать этот охват за общую облачную избыточность. Клиент не может сделать вывод из сингапурской игровой локации, что сможет разместить выделенный сервер ZAP в Сингапуре. Лондонская опция TeamSpeak не доказывает существование лондонского VPS-продукта. Монреальская игровая локация не доказывает наличие контролируемого клиентом root-доступа, кастомных сетей, выделенных машин или вариантов миграции для веб-нагрузки. Матрица продуктов для нескольких регионов говорит обратное.

DDoS-страницы показывают тот же нюанс.Страница DDoS-защиты OVHговорит, что OVH управляет постоянно включённой анти-DDoS-инфраструктурой, мониторит трафик в реальном времени, перенаправляет атаки в scrubbing-сеть и предлагает игровые слои фильтрации для UDP и чувствительных к задержке сервисов.Основное сравнение DDoSговорит, что OVH используется для Лондона и Сингапура в перечисленных локациях, а далее описывает покрытие OVH для локаций в Великобритании, Азии и Австралии. Это полезное заявление для игровых и голосовых сервисов. Оно всё ещё не доказывает мощности, поведение при потере пакетов или обработку ложных срабатываний для каждой игры и каждого типа атак.

Игровой хостинг также создаёт другие пути отказов. Веб-приложение может отказать, потому что пропало хранилище или база данных недоступна. Игровой сервис может оставаться «в сети», пока опыт использования непригоден: UDP-фильтрация слишком агрессивна, частота CPU недостаточна для сервера с модами, хранилище подвисает при сохранении мира или игроки направляются через дальний scrubbing-путь. Сервис TeamSpeak может быть технически доступен, но качество плохое, потому что джиттер или потери пакетов слишком высоки для сообщества. Для рынка ZAP это не второстепенные детали; это и есть продукт.

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

Различие локаций важно и для миграции. Если сообщество переезжает из Лондона во Франкфурт или из Сингапура к другому провайдеру, техническая работа — не только копирование файлов. Она включает смену публичных адресов, DNS или SRV-записей, конфигурацию игры, моды, данные игроков, права, тайминги резервного копирования, изменения профиля анти-DDoS и уведомление пользователей. Чем проще запустить игровой сервер, тем легче забыть, сколько элементов приходится переносить во время простоя.

AS206996 — реальная публичная маршрутная поверхность

Самое сильное независимое инфраструктурное свидетельство — маршрутная запись.Обзор ASв RIPEstat для AS206996 определяет владельца как zap-hosting ZAP-Hosting GmbH и помечает ASN как анонсируемый.Статус маршрутизациипоказывал AS206996 видимым у 327 из 327 пиров с полной таблицей маршрутов IPv4 RIPE RIS и 322 из 322 пиров IPv6, с последним замеченным маршрутом в этом представлении 12 июля 2026 года. Тот же снимок сообщал о 85 префиксах IPv4, покрывающих 21 760 адресов IPv4, и трёх префиксах IPv6, покрывающих 12 288 /48.

Это не тонкая маршрутная запись.Представление announced-prefixesв том же окне проверки перечисляло 88 текущих записей префиксов, включая IPv4 /24, такие как 147.189.171.0/24, 5.249.160.0/24, 194.62.1.0/24, и IPv6-маршруты 2a0c:3580:1000::/36, 2a0c:3580:2000::/36 и 2a0c:3580:3000::/36. Проверкиобзора префиксав RIPEstat по репрезентативным префиксам связывали эти анонсы с AS206996 и строкой владельца ZAP-Hosting.

Свидетельства из реестра RIPE тоже согласованы.Данные whoisв RIPEstat для AS206996 иобъект aut-numв RIPE REST показывают as-name zap-hosting, org ORG-ZHG2-RIPE, статус assigned и строки политики со ссылками на AS49581, AS62403 и AS44592.Объект организациив RIPE REST перечисляет ZAP-Hosting GmbH как DE LIR по адресу Hafenweg 8, 48155 Мюнстер, Германия, с датой создания 2019 год и датой последнего изменения 2026 в проверенной записи. Эти записи не доказывают качество сервиса, но они доказывают живые отношения с реестром.

Независимые агрегаторы маршрутов в целом согласны с картиной.BGP.toolsдля AS206996 определяет сеть как ZAP-Hosting GmbH, активную в RIPE, с большим набором префиксов IPv4 и тремя префиксами IPv6.BGP Toolkit Hurricane Electricперечисляет AS206996 как ZAP-Hosting GmbH и показывает анонсируемые IPv4- и IPv6-маршруты.Страница IPinfoдля AS206996 называет ZAP-Hosting GmbH и относит ASN к хостингу.Cloudflare Radarпредоставляет ещё одну публичную линзу маршрутизации для этого ASN.

Оценка маршрутизации, таким образом, сильна в части идентичности и активного присутствия. Это не чек на отказоустойчивость. Количество префиксов не говорит покупателю, находится ли его сервис в одной стойке или в нескольких, стоят ли все игровые локации за одним DDoS-провайдером, есть ли у локального маршрута достаточно резервной мощности под атакой, и обладает ли каждый префикс сопоставимой операционной зрелостью. Маршрутные свидетельства говорят, что у ZAP есть значимая публичная сетевая поверхность. Архитектурные свидетельства должны оставаться привязанными к продукту.

Свидетельства о транзите и пиринге неполны

Публичная картина транзита уже, чем количество префиксов.Представление ASN neighboursв RIPEstat показало в снимке двух наблюдаемых соседей: AS40676 и AS62403.Обзор ASв RIPEstat определяет AS40676 как Psychz Networks, аAS62403как PletX GmbH. Строки политики aut-num в RIPE, тем временем, ссылаются наAS49581Tube-Hosting, AS62403 PletX иAS44592SkyLink Дата-центр BV.

Эти имена логично сочетаются с публичными страницами продуктов: Psychz фигурирует в описаниях американских локаций, PletX — в документации по DDoS, SkyLink — в описании дата-центра в Эйгелсховене. Но наблюдаемые BGP-соседи и строки политики импорта/экспорта в RIPE — не одно и то же. Наблюдаемые маршруты могут меняться вместе с точками измерений, трафик-инжинирингом и временными путями. Строки политики в реестре могут быть устаревшими, широкими или не полностью отражать живую маршрутизацию. Статья может использовать их как свидетельство правдоподобной карты зависимостей; не стоит относиться к ним как к живому реестру контрактов.

PeeringDB в этом случае мало что добавляет.API-запрос к PeeringDBдля AS206996 не вернул ни одной сетевой сущности в проверенном ответе.Страница о PeeringDBописывает сервис как поддерживаемую пользователями базу данных о сетях, точках обмена, площадках и пиринге. Отсутствие в PeeringDB не означает, что у ZAP нет площадок или присутствия на биржах. Это значит, что публичные читатели не могут использовать эту базу для подтверждения точек обмена, списков площадок, уровней трафика, политики пиринга или контактов сетевых операций.

Валидация происхождения маршрутов в выборочных проверках более обнадёживающая.Проверка RPKIв RIPEstat для репрезентативного текущего IPv4-префикса 147.189.171.0/24 вернула статус valid, и проверки для 5.249.160.0/24, 194.62.1.0/24 и 2a0c:3580:1000::/36 тоже вернули valid в ходе проверки. Это полезный признак гигиены происхождения маршрутов. Это всё ещё выборочный признак, если только каждый текущий маршрут не проверяется непрерывно, а валидация происхождения RPKI не защищает от любой проблемы маршрутизации.

Практический клиентский вопрос уже, чем «Кто транзит у ZAP?». Он такой: для именно этого сервиса и локации, какой провайдер несёт входящий и исходящий трафик, где применяется DDoS-фильтрация, что произойдёт, если наблюдаемый апстрим нарушен, и какой объём трафика может быть поглощён после отказа одного пути? Клиент игрового сервера в Ашберне, VPS-клиент во Франкфурте/Эйгелсховене и клиент TeamSpeak в Сингапуре могут получить разные ответы.

DDoS-защита — это зависимость продукта, а не дополнительная опция

DDoS-защита центральна для рынка ZAP. Игровые серверы, голосовые серверы и дешёвые VPS-продукты привлекают злоупотребления, бот-трафик, UDP-флуды, атаки конкурентов и неправильно настроенные сканеры.Документация ZAP по DDoS-защитеговорит, что компания использует проверенные решения защиты, адаптированные к локации дата-центра, работающие автоматически и в реальном времени, чтобы отфильтровывать вредоносный трафик до того, как он повлияет на производительность или доступность. Таблица сравнения перечисляет постоянную защиту, базовую защиту, фильтрацию на уровне сети и приложений, игровую фильтрацию и отсутствие даунтайма при митигации для категорий PletX и OVH, тогда как визуализация мониторинга в реальном времени в DDoS Manager перечислена для PletX, но не для OVH.

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

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

Страница OVH DDoSописывает постоянный мониторинг, автоматическое перенаправление в scrubbing-сеть и дополнительную игровую фильтрацию для UDP-протоколов.Страница PletX DDoSописывает фильтрацию вокруг локаций дата-центра ZAP и системы PletX. Публичныйсайт PletXописывает митигацию с использованием ПО, построенного на XDP/eBPF, и трассировки соединений. Эти страницы — полезный контекст, но не измеренный отчёт об атаке на конкретный сервис ZAP.

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

Для ZAP правильная публичная оценка — не «DDoS не доказан». Компания публикует о митигации больше, чем многие небольшие хостинг-провайдеры, и её маршрутная таблица активна. Правильная оценка — «DDoS-защита специфична для сервиса». Защитный путь — центральная часть купленного сервиса, и клиентам следует относиться к поставщику DDoS, локации, видимости и эскалации как к части хостинг-контракта.

Резервное хранилище полезно, но восстановление остаётся за клиентом

Документация ZAP о резервном копировании практична и скромна.Страница резервного хранилищаговорит, что каждый аккаунт включает 10 ГБ бесплатного резервного хранилища, расширяемого до 200 ГБ за плату. Там сказано, что резервные копии создаются из веб-интерфейса соответствующего сервиса, хранятся централизованно, восстанавливаются напрямую через функцию резервного копирования сервиса или скачиваются для локального хранения, и доступны по FTP с учётными данными, показанными в веб-интерфейсе. Также сказано, что раздел сообщений логирует действия с резервными копиями.

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

Резервное хранилище может существовать, пока пропускная способность восстановления, целевые мощности, изменения DNS или ремонт приложений остаются непроверенными.

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

Для покупателя операционный вопрос не «Есть ли у ZAP резервные копии?», а «Что именно резервируется, как часто, где хранится, какого размера может быть, можно ли скачать без здорового сервера и сколько времени занимает полное восстановление?». Администратор игрового сервера должен проверить, включает ли резервная копия файлы мира, моды, конфиги, права и файлы базы данных. VPS-администратор не должен предполагать, что резервная копия из веб-интерфейса — это полный образ физической машины, если продукт об этом не говорит.

Клиенту выделенного сервера стоит помнить, что восстановление физической машины может потребовать переустановки ОС, пересборки RAID, загрузки резервной копии и пересборки приложения.

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

Поддержка — это очередь, а не волшебный слой починки

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

Это позитивные сигналы. Провайдер, который открывает статус и сетевые тесты, даёт клиентам больше, чем чёрный ящик. Документация также просит клиентов предоставлять диагностическую информацию, что может сократить время решения, когда неисправность находится внутри операционной системы клиента, игровой конфигурации, стека плагинов или IP-настроек.Документация по VPS-дашбордуиVNC-консолипоказывает, что клиенты могут получить доступ к консоли сервера через веб-интерфейс, аруководство по VPS без интернетаобъясняет, как VNC помогает исправить сетевую конфигурацию, когда RDP не работает.

Но у поддержки есть пределы пропускной способности. Когда один клиент неправильно настроил Windows VPS, тикет и VNC-консоль могут решить проблему. Когда нарушена локация дата-центра, провайдер митигации, апстрим или компонент платформы, многие клиенты могут открыть тикеты одновременно. Очередь поддержки тогда становится частью простоя. Опыт клиента зависит от правил триажа, штата, полномочий менять сетевую политику, доступности remote hands и от того, отражает ли страница статуса именно затронутый компонент.

У поддержки есть и пределы объёма. Если ZAP предоставляет сервер, но клиент устанавливает сторонние моды, игровые плагины, базы данных, веб-приложения или кастомные firewall, не каждый сбой является виной провайдера. Просьба руководства по поддержке предоставить логи и шаги диагностики отражает эту границу. Поэтому клиент, эксплуатирующий производственную инфраструктуру на дешёвом VPS, должен вести собственный ранбук, учётные данные, резервные копии и мониторинг, а не ждать, что очередь тикетов провайдера заменит команду эксплуатации.

Условия усиливают эту границу. Они ограничивают сервис ZAP предоставлением серверных ресурсов и связности до точки передачи собственной сети связи и говорят, что ZAP не может влиять на трафик данных за пределами собственной сети связи. Это обычная договорная формулировка, но она означает, что клиент должен различать сбой провайдера, сбой апстрима, проблему интернет-пути, проблему локального ISP, проблему DDoS-фильтрации и неверную конфигурацию клиента. Поддержка ZAP может помочь с некоторыми из них; она не может отвечать за все.

Биллинг и изменения продуктов могут стать инфраструктурными сбоями

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

В тех же условиях сказано, что ZAP может заменить сервис на другой продукт, если исходный сервис больше не может быть предложен, и может изменять или расширять сервисы там, где этого требует или позволяет техническое развитие, в разумных пределах для клиентов. Опять же, это не редкость. Провайдерам нужно пространство для замены старого оборудования, снятия продуктов с продажи и управления запасами. Но клиенту стоит рассматривать жизненный цикл продукта как часть риска. «Пожизненная» покупка — это не владение стойко-местом и не бессрочное использование одного аппаратного поколения.

Страницы конфигурации продуктов ZAP показывают ещё одну связку коммерческого и технического.Страница конфигурации VPSописывает выбор CPU, памяти, хранилища, IP-адресов и пропускной способности и предупреждает на некоторых изменениях, что значение апгрейда или даунгрейда нельзя легко изменить и может потребоваться новая установка. Это важно для миграции и масштабирования. Если во время инцидента клиент обнаружит, что ему нужно больше CPU, памяти, адресов или хранилища, требуемое изменение может оказаться не простым живым слайдером.

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

Такова хостинговая экономика под низкими входными ценами. Клиенты получают скорость, предоплатную гибкость, выбор продуктов и сравнительно дешёвые мощности. Взамен они принимают условия об оплате, изменении продуктов, объёме поддержки, ответственности за данные и доступности локаций. Лучший клиент проектирует под эту сделку. Он следит за продлением, экспортирует резервные копии, документирует шаги пересборки, проверяет, требует ли масштабирование переустановки, и не предполагает, что дешёвый сервер можно чинить как корпоративную управляемую платформу.

Локализация данных — это выбранное размещение, а не брендовый ярлык

Немецкая юридическая идентичность ZAP ясна.Выходные данныеиполитика конфиденциальностипомещают компанию в Мюнстер и описывают немецкий контекст защиты данных для сайта и поверхности аккаунта.Объект организациив RIPE определяет ZAP-Hosting GmbH как DE LIR. Эти факты полезны для договорной работы и управления на уровне аккаунта.

Они не делают каждую рабочую нагрузку немецкой. Матрица локаций и страницы продуктов ZAP показывают продуктовый след в Германии, США, Великобритании, Канаде, Австралии и Сингапуре.Страница VPSпрямо называет американские площадки Psychz.Документация по локациямпоказывает игровые сервисы и TeamSpeak в нескольких не немецких регионах. Клиент, которому нужно размещение данных в ЕС, не должен полагаться только на штаб-квартиру компании. Он должен выбрать немецкую локацию, подтвердить, где находятся резервные копии и логи, и избегать использования не входящих в ЕС локаций, если ответственный за соответствие их не принимает.

То же верно в обратную сторону. Американское игровое сообщество может предпочесть Даллас, Ашберн или Лос-Анджелес ради задержки, даже если провайдер немецкий. Это может быть хорошим операционным выбором. Это также означает, что данные аккаунта, платёжные данные, переписка с поддержкой, серверные логи и данные размещённой нагрузки могут не иметь единую юридическую географию. Клиент должен знать, какие категории данных находятся в Германии, какие — в выбранном регионе хостинга и какие сторонние системы обрабатывают данные аккаунта или платежей.

Локализация данных влияет и на реагирование на инциденты. Если размещённый в Германии сервис отказывает и резервная копия находится в том же аккаунте или регионе, путь восстановления может остаться внутри Германии. Если размещённому в США сервису нужна поддержка из Германии, действия площадки в США и DDoS-фильтрация через другого провайдера, инцидент пересекает часовые пояса, поставщиков и юридические контексты. Пользователь может видеть только статус в панели управления. Реальная цепочка ремонта может быть значительно длиннее.

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

Установленная мощность — это не то же самое, что доступная мощность

Публичный след ZAP показывает значимую установленную мощность: живой ASN с десятками анонсов IPv4, анонсами IPv6, статусом немецкого LIR, страницами продуктов с аппаратными деталями, названными партнёрами по площадкам в США, страницей статуса, документацией по DDoS и резервным хранилищем. Более сложный вопрос — какая доля этих мощностей останется доступной после сбоя. Установленная мощность — это то, что существует, когда всё здорово. Доступная мощность — это то, что может провести клиентов через отказ.

Различие важнее всего в немецкой конфигурации. Если Эйгелсховен — филиал, чей трафик идёт через Франкфурт, то совокупный сервис зависит от франкфуртского трафик-пути и пути защиты. Если немецкая DDoS-защита переходит от одного поставщика к другому, допущения о маршруте и поддержке могут измениться. Если отказывает блейд-шасси, коммутатор, цепь питания или профиль митигации, затронутые клиенты могут не суметь мгновенно переехать в удалённый игровой регион или американский VPS-регион без смены продукта, задержки или соответствия.

Это важно и для американского VPS. Даллас, Ашберн и Лос-Анджелес — отдельные локации, но каждая несёт собственную зависимость от площадки и remote hands. Клиент не должен предполагать, что VPS можно живой миграцией перенести между этими локациями без пересборки, смены адресов или работы поддержки. Публичная документация показывает локации и оборудование; она не рекламирует мультисайтовый продукт с автоматическим переключением. Клиенту, которому нужна непрерывность между регионами, нужно проектировать собственную репликацию, DNS-фейловер, резервные копии и развёртывание приложений.

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

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

Самый безопасный подход клиента — записать отказ, который он хочет пережить. Одна стойка? Один хост? Один диск? Один DDoS-поставщик? Один регион? Один апстрим? Одна проблема с аккаунтом? Одна очередь поддержки? Затем стоит спросить, переживает ли купленный продукт ZAP именно этот отказ. Без такого сопоставления «DDoS защищён», «мгновенно онлайн», «40 Гбит/с» и «собственное оборудование» могут быть правдой, пока план восстановления клиента остаётся слабым.

Что спросить серьёзному покупателю, прежде чем полагаться на ZAP

Серьёзному покупателю стоит начать с идентичности и объёма сервиса. Заключается ли договор с ZAP-Hosting GmbH по мюнстерскому адресу извыходных данных? Какое семейство продуктов покупается: игровой сервер, TeamSpeak, VPS, root-сервер, веб-пространство или выделенный сервер? Какие публичные условия применяются? Сервис предоплатный, помесячный или «пожизненный»? Какие функции включены и какие требуют отдельной платной мощности?

Затем нужно проверить размещение. Для немецких сервисов — нагрузка во Франкфурте, в Эйгелсховене или в обоих? Если трафик Эйгелсховена идёт через Франкфурт, что откажет, когда у Франкфурта будет инцидент в сети или на DDoS-пути? Для американского VPS — какая площадка Psychz задействована? Для игровых и голосовых сервисов — поддерживает ли выбранная локация только этот продукт или клиент может переехать на VPS или выделенный сервер в том же регионе, если понадобится?

Затем нужно проверить сетевую зависимость. Использует ли сервис адреса AS206996? Какие текущие префиксы несут сервис? Какой апстрим или провайдер митигации находится на пути? Подтверждают ли ROA RPKI происхождение маршрута для релевантного префикса? Есть ли у клиента доступ к телеметрии DDoS Manager? Соответствует ли карта компонентовстраницы статусазаказанному сервису? Совпадают ли результатыSmokepingс пользовательской базой клиента?

Затем нужно проверить резервные копии и выход. Достаточен ли объём резервного хранилища? Резервные копии создаются автоматически или по запросу клиента для этого продукта? Может ли клиент скачать полную резервную копию по FTP, пока исходный сервис нездоров? Включает ли резервная копия базы данных, плагины, файлы модов, права, запланированные задачи и конфигурацию? Если продукт заблокирован после задержки оплаты, можно ли всё ещё экспортировать резервные копии? Каково время пересборки на новом продукте или провайдере?

Наконец, нужно проверить поддержку и ремонт. Какие свидетельства клиент должен включить в тикет? Какой путь поддержки применяется к проблемам аккаунта, DDoS-проблемам, аппаратным дефектам и неверной конфигурации клиента? Кто может менять митигацию? Кто может запросить remote hands в стороннем дата-центре? Что происходит вне немецких рабочих часов? Включена ли замена оборудования в базовый продукт или она зависит от наличия запчастей и действий площадки?

Эти вопросы не делают ZAP необычно рискованным провайдером. Они приводят видимый риск в соответствие с реальным сервисом. Публичный след ZAP достаточно силён, чтобы покупатель мог задавать точные вопросы. Опасность только в том, чтобы позволить витрине с низким трением превратиться в допущение о низком трении в отказоустойчивости.

Оценка доказательной базы

Итоговая оценка сетевых доказательств для zap-hosting ZAP-Hosting GmbH — Strong (убедительная), с оговоркой об отказоустойчивости сервиса. Свидетельства идентичности сильны:выходные данные,политика конфиденциальности,объект организациив RIPE,объект aut-numв RIPE иобзор ASв RIPEstat сходятся на ZAP-Hosting GmbH и AS206996. Маршрутные свидетельства тоже сильны: RIPEstat видел AS206996 анонсируемым с 85 префиксами IPv4, 21 760 адресами IPv4 и тремя префиксами IPv6 в окне публикации, а независимые страницы, такие какBGP.tools,Hurricane Electric,IPinfoиCloudflare Radar, дают в целом согласованные публичные картины.

Продуктовые свидетельства сильнее, чем можно было бы ожидать при «тонком следе». ZAP публикует матрицы локаций, описания оборудования, документацию по DDoS, процедуры поддержки, инструкции по резервному хранилищу, статусные поверхности и условия договора. Этого достаточно, чтобы сказать, что компания — реальный оператор арендуемых мощностей со значимым сетевым следом и конкретным немецким операционным центром.

Оговорка в том, что отказоустойчивость всё ещё заказывается, а не предполагается. Публичные страницы не доказывают резервные мощности по стойкам, активно-активный фейловер между регионами, актуального DDoS-провайдера в каждой локации, измеренное время восстановления, присутствие площадок в PeeringDB, пропускную способность поддержки во время широкого инцидента или качество миграции под нагрузкой. Самый сильный публичный вывод — не «ZAP автоматически отказоустойчив». Это «у ZAP достаточно видимой инфраструктуры, чтобы клиенты проверяли именно ту цепочку зависимостей, которую покупают». Для дешёвого VPS эта цепочка может быть приемлемой.

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