Геолокация IP — почему ваш VPS может «показывать» не ту страну

IP-адрес — это просто 32-битное (IPv4) или 128-битное (IPv6) число. В нём нет никакой географической информации. В битах нет кода страны, в структуре нет города, в формате нет координат. Географическая привязка, которую вы видите в Speedtest, Google, YouTube или виджете погоды — целиком сторонняя. Кто-то где-то решил, что это число вероятно принадлежит вот этой стране, и выпустил базу данных, в которой так и написано.

У IP-адреса нет встроенной страны

Сравните с телефонным номером. У телефонного номера география действительно зашита в структуру: +49 — Германия, +1 — США/Канада, +7 — Россия, следующие цифры идентифицируют оператора и часто город. Эта информация заложена в номер международным стандартом, распределяется регулятором и обновляется через публичный реестр. По одному номеру можно с уверенностью определить страну и оператора.

У IP-адреса ничего этого нет. Когда IANA делегирует блок в RIPE, ARIN, APNIC или другой региональный реестр — этот реестр потом раздаёт его тому, кто попросит: хостеру, ISP, корпорации, государству — в любую точку своего огромного географического покрытия (один RIPE покрывает Европу, Россию, Центральную Азию и Ближний Восток). Блок 87.76.179.0/24 и соседний 87.76.180.0/24 могут оказаться в совершенно разных странах, у совершенно разных организаций. Само число не говорит ничего.

Как геолокация работает на самом деле (это сторонние догадки)

Каждая база IP-геолокации строится комбинацией нескольких сигналов, каждый из которых неидеален, в одну лучшую догадку:

• WHOIS-записи — зарегистрированный владелец блока с почтовым адресом. Часто корректен для головного офиса компании, но не для дата-центра, где IP физически живут.
• BGP-анонсы — какая сеть (автономная система) анонсирует префикс в глобальную таблицу маршрутизации. Говорит про оператора, но не про город.
• Triangulation по latency — измеряют RTT с множества точек по миру (например через RIPE Atlas) до IP, по этому выводят географическую дистанцию.
• Reverse DNS — имена вида vps-fra-23.example.com подсказывают, что IP во Франкфурте.
• Прямые submission от сетевых операторов — мы как провайдер можем сообщить каждой базе: «этот /24 теперь во Франкфурте».
• Web-логи и crawl-данные — если сайт видит, что с IP отправляют форму с немецким индексом, это слабый сигнал.

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

Тысячи баз данных, все рассинхронизированы

Авторитетных IP-геолокационных баз — примерно дюжина. Под ними — тысячи вторичных сервисов, которые в основном лицензируют или скрапят данные у крупных и затем выпускают по своему (обычно более медленному) графику. Часть этих вторичных баз не обновлялась месяцами. Некоторые тихо заброшены годами. Ни один провайдер на планете — ни мы, ни Google, ни Cloudflare — не может заставить чужую базу быть актуальной.

Частота обновлений основных баз (типичная):

Что мы делаем при каждом новом блоке IP

Когда новый /24 заходит в одну из наших локаций — мы не сидим и не ждём, пока базы нас обнаружат. В тот же день мы отправляем корректную геолокацию во все авторитетные базы. У каждой из них есть публичная форма коррекции:

• Форма коррекции MaxMind GeoIP
• Корректировки IPinfo
• DB-IP
• Форма обновления IP2Location
• Ipregistry
• IPGeolocation.io
• GeoMyIP

Почему «неправильная» геолокация обычно не является реальной проблемой

Если ваш VPS физически во Франкфурте, но Speedtest, Google, YouTube или виджет погоды показывают Амстердам — или Гонконг, или Сан-Паулу — почти всегда это значит ровно одно: какая-то конкретная база ещё не подхватила нашу submission. Сервер ровно там, где вы его заказали. Номер на сетевом интерфейсе тот же самый. Просто чей-то один CSV-файл устарел.

Что может выглядеть как «сломалось» из-за устаревшей базы:

• Speedtest автоматически выбирает тестовый сервер в другой стране (он выбирает по геолокации IP, а не по реальной задержке), поэтому результат выглядит хуже реального.
• Поисковая выдача Google, рекомендации YouTube или таргетинг рекламы локализуются для не той страны.
• Виджеты погоды, новостей или спорта показывают не тот город.
• Стриминговые сервисы с гео-блокировкой (Netflix, BBC iPlayer и т.д.) ведут себя непоследовательно.
• Платёжные процессоры могут флагать IP как «необычный регион» для держателя карты.

Ни одно из этого не вызвано чем-то неправильным с нашей стороны. Сервер в той стране, в которой вы его заказали. Решение — подождать, пока база подтянется — в чужих руках. Мы уже сделали единственное полезное, что можем — отправили корректировку в день, когда блок зашёл онлайн.

Как самостоятельно проверить реальную физическую локацию

Если хотите подтвердить, где сервер реально стоит, не полагайтесь на один GeoIP-сервис. Перепроверьте:

1. Сделайте traceroute до вашего VPS из 2–3 разных городов. Последние несколько хопов будут внутри транзита и города нашего ДЦ — эти точки физически закреплены, ни одна GeoIP-база их не подделает.
2. Сравните 3 разных геолокационных сервиса (например ipinfo.io, db-ip.com, MaxMind). Если два из трёх согласны — это и есть ответ; если все три расходятся — это вопрос распространения.
3. Измерьте RTT до публичного iperf-эндпоинта или известного сервиса в ожидаемом городе. ~5 мс до франкфуртского iperf-сервера с «франкфуртского» VPS — это реальность подтверждает.
4. Спросите нас. У нас есть жёсткие данные о том, какой /24 живёт в какой физической стойке — это надёжнее любого внешнего lookup-а.

Смежный контекст: как порт-скорость и end-to-end интернет-скорость связаны со всем этим — описано в статье про общий порт 1 Гбит/с и более глубокой статье про скорость интернета. Точность геолокации и пропускная способность — независимые проблемы, но в тикетах их удивительно часто путают.