Вы находитесь в Шанхае, а запрос IP показывает другой город; на двух сайтах один и тот же адрес определяется в США и в Канаде. При виде таких результатов интуитивно кажется, что «одна из баз данных ошибается». Но прежде чем сравнивать базы, стоит убедиться: сравниваете ли вы один и тот же адрес, один и тот же тип местоположения, или несколько полей с похожими названиями, но разным смыслом?
IP-геолокация — это оценка расположения сетевого адреса, а не устройства. Разные платформы могут использовать разные источники данных, время обновления и степень детализации; если местоположение не совпадает, сначала сверьте адрес и поля, а затем решайте, нужно ли исправление.
Этот порядок важен. Иначе вы можете принять расположение сетевого выхода за собственное, или возражать против городской геолокации, ссылаясь на место регистрации организации, и в итоге отправить запрос на исправление не туда.
Под словом «принадлежность» могут скрываться четыре разных типа информации
На многих страницах поиска указаны только «страна», «регион» или «принадлежность», без пояснения, что именно значат эти данные. На самом деле перечисленные ниже сведения не взаимозаменяемы.
Что вы видите | Какой объект описывается | На что обращать внимание при сравнении |
|---|---|---|
Геолокация IP-адреса | База данных оценивает адрес по месту использования или точке выхода сети | Есть ли диапазон определения местоположения, степень уверенности и время обновления |
Информация о регистрации ресурсов | Регистрационные записи IP-адресных ресурсов и связанных организаций | Регистрационная информация не является доказательством местоположения конечного устройства |
Геолокация браузера или устройства | Местоположение устройства, полученное после предоставления соответствующих разрешений | Могут использоваться возможности устройства, такие как GPS, а не только проверка IP |
Локальный контент сайта | Региональный контент, выбранный сервисом по собственной логике | На это также могут влиять настройки учетной записи, язык или предыдущие предпочтения |
Введение ARIN в Whois/RDAP объясняет назначение запросов регистрационной информации. Это иной уровень данных, чем оценка географической базой данных того, «где этот адрес используется сейчас».
Документация MDN по Geolocation API поясняет, что сайт после получения согласия пользователя может получить местоположение через доступные устройству возможности позиционирования. Поэтому то, что картографическое приложение знает, на какой вы улице, не означает, что другой сайт запроса IP должен давать такую же точность.
Почему один и тот же адрес может давать разные результаты определения местоположения?
Условия использования адреса изменились, а база данных не всегда обновляется одновременно
Адресные ресурсы могут быть перераспределены, переданы в субаренду или использованы для новых сетевых выходов. Службам геолокации требуются отдельные процессы, чтобы обнаружить изменения, проверить их и опубликовать обновления; сайтам, использующим офлайн-базы данных, также необходимо фактически развернуть новые версии в своих системах.
Поэтому «поставщик данных уже исправил» и «все сайты, использующие эти данные, уже обновились» — это разные вещи. Если старые результаты продолжают отображаться, проблема может быть как на стороне поставщика данных, так и в локальной базе данных или кэше на стороне потребителя.
Здесь нет единого фиксированного времени обновления для всех платформ. Нельзя утверждать, что отправка была бесполезной, только потому что через день ничего не изменилось; также нельзя обещать, что после исправления в одном месте другие платформы синхронизируются одновременно.
Сетевой выход не обязательно находится рядом с пользователем
В мобильных и корпоративных сетях, VPN и подобных средах физическое местоположение устройства может отличаться от местоположения публичной точки выхода в интернет. База геолокации иногда достаточно точно определяет расположение этой точки, но это не позволяет установить, где находится человек, который ею пользуется.
Документация по точности геолокации MaxMind специально рассматривает использование мобильных сетей и сервисов защиты конфиденциальности, таких как VPN и прокси и четко указывает, что данных IP-геолокации недостаточно для идентификации конкретного дома, человека или уличного адреса.
Поэтому, если человек находится в городе A, а выход геолоцируется в городе B, это не обязательно означает аномалию соединения. Сначала следует выяснить, что вы хотите узнать: местоположение устройства или сетевое местоположение, видимое внешним сервисам.
Две платформы предоставляют разную точность
То, что одна платформа указывает страну, а другая — город, не означает, что последняя обязательно точнее. Более детальное поле может быть лишь репрезентативной точкой в пределах диапазона; отсутствие отображения радиуса геолокации на странице не означает, что этого радиуса не существует.
Даже если маркер на карте, кажется, попадает на какое-то здание, нельзя делать вывод, что сервер или пользователь находится именно в этом здании. Большее количество десятичных знаков в координатах лишь увеличивает точность отображения, но не повышает автоматически точность данных.
Если источник данных предоставляет диапазон геолокации, точку и диапазон следует читать вместе. В противном случае следует избегать интерпретации названия города как местоположения, подтвержденного проверкой на месте.
Одинаковое название сети не означает, что все адреса используются одинаково и находятся в одном месте
Одна операционная организация может вести деятельность в нескольких местах. Под одним ASN также могут находиться диапазоны адресов из разных регионов и с разным назначением.
Название организации и ASN помогают проверить сетевой контекст, но нельзя на основе только этого геолоцировать все адреса сети в один город. Наличие аббревиатуры города в обратном DNS может служить лишь подсказкой; имена хостов могут сохраняться по старой схеме именования и не могут заменить другие доказательства.
Прежде чем проводить проверку, убедитесь, что «один и тот же IP» действительно один и тот же
Самая распространенная ошибка сравнения часто кроется не в базах данных, а в объекте запроса.
Сначала скопируйте полный публичный адрес, не ограничиваясь только страной и оператором. Обязательно проверьте, показывают ли две страницы IPv4 и IPv6 соответственно: это разные адреса, и их не следует напрямую использовать для оценки согласованности двух баз данных.
Также фиксируйте время запроса и убедитесь, что сетевые настройки не менялись в процессе. Автоматический выбор маршрута прокси, переподключение мобильной сети или использование разных правил прокси браузером и другими приложениями могут изменить наблюдаемый сетевой выход.
Можно сначала записать текущий результат через Проверка IP-адреса, а затем использовать тот же адрес как явный объект запроса для сравнения. Если вы вводите доменное имя, учтите, что оно может разрешаться в несколько адресов; сравнение разных серверов, возвращаемых доменом, не равносильно сравнению одного и того же IP.
Как превратить расхождения геолокации в вопрос, с которым можно работать?
Говорить «у вас неточно», нагромождая скриншоты, обычно менее полезно, чем предоставить следующую информацию.
Полный запрашиваемый IP-адрес и его тип: IPv4 или IPv6.
Время запроса и часовой пояс, чтобы не принимать результаты, полученные в разное время, за одновременные наблюдения.
Названия полей каждого результата: страна регистрации, страна геолокации, город или другое местоположение.
Источник данных, версия или время обновления; если их невозможно получить, честно укажите, что не предоставлено.
Что именно вы считаете ошибочным и материалы, подтверждающие это суждение.
Например, «две платформы дают разные страны геолокации для одного и того же IPv4» более конкретно, чем «на двух сайтах разное местоположение»; а «сегмент, недавно выделенный нам, все еще показывает прежний город» — это вопрос, который скорее могут проверить поставщик сети и сопровождающий данных.
Материалы также различаются по убедительности. Регион доставки, указанный в договоре на обслуживание, пояснения сетевого оператора и проверяемая информация об использовании ресурсов обычно более показательны, чем часовой пояс, установленный в операционной системе сервера. Часовой пояс можно изменить, поэтому он не может служить доказательством физического местоположения.
К кому обращаться за исправлением, а не повторно отправлять запросы на все сайты
Вы обычный пользователь широкополосного или мобильного интернета
Сначала спросите у оператора, есть ли централизованный выход, межрегиональный шлюз или недавние изменения в распределении адресов. Если сетевой выход на самом деле находится в другом регионе, изменение геобазы не сможет превратить фактический маршрут в локальный выход.
Если только контент в одном приложении отображается с несоответствующим регионом, а результаты нескольких IP-баз совпадают, дополнительно проверьте разрешения на определение местоположения и региональные настройки аккаунта в этом приложении. В таком случае проблема не обязательно в IP-базе.
Вы арендовали прокси, VPS или фиксированный публичный адрес
Попросите поставщика объяснить фактический способ предоставления и регион, а также проверьте, не был ли адрес недавно перенесён или перераспределён. Не считайте регион, указанный на странице продажи, окончательным доказательством местоположения.
Если исправление касается всего префикса, обычно лучше, чтобы сетевым оператором, контролирующим этот ресурс, была проведена единая обработка. Geofeed может помочь сетевым операторам публиковать географическую информацию о префиксах, но RFC 8805 также явно оставляет пространство для проверки авторитетности и точности со стороны использующих; публикация файла не является принудительным указанием на обновление для всех баз данных.
Вы точно знаете источник данных, в котором обнаружена ошибка
Используйте официальные каналы этого источника данных. Например, MaxMind в своей документации предоставляет портал для исправления геоданных. Подайте заявку с фактами, которые можно проверить, а не требуйте изменить адрес на регион, который вы хотите видеть.
Исправление — это приведение данных в соответствие с реальным использованием, а не создание ложной принадлежности к какой-либо стране или городу. При подаче заявки не нужно раскрывать точный домашний адрес, пароли от аккаунтов или скриншоты админ-панелей; предоставляйте только необходимые материалы доверенным принимающим сторонам.
Как подтвердить, что проблема действительно решена после исправления?
Сохраните записи до подачи заявки, дождитесь подтверждения обработки от обслуживающей стороны, затем снова запросите тот же адрес и то же поле и проверьте, применил ли исходно затронутый веб-сайт новый результат. Они могут не синхронизироваться.
Если IP-данные уже изменились, но какой-то сервис всё ещё показывает старый регион, переключите внимание на использующую сервис сторону: использует ли она другой источник данных, сохранила ли кэш, есть ли региональные настройки на уровне аккаунта? Продолжать изменять уже корректные данные часто бесполезно.
Что касается доступности сервиса, её нужно проверять отдельно с помощью Проверка доступности сервисов и обычного фактического доступа. Корректная геолокация не означает, что сервис обязательно открыт; доступность сервиса, в свою очередь, не доказывает правильность определения города.
Геоинформация об IP помогает понять сетевой контекст, обнаружить очевидные отклонения и инициировать исправление. Относитесь к ней как к суждению с границами источника и точности, а не как к свидетельству адреса с точностью до улицы — это ближе к её реальному назначению.
Транснациональные сети с разными странами геолокации: страна регистрации, Anycast и расположение выхода
Рассмотрим гипотетический сценарий: транснациональный провайдер регистрирует адресные ресурсы в Канаде, фактически развёртывает сервисы в США, поэтому коммерческая база геолокации и регистрационные запросы показывают разные страны. Здесь не нужно предполагать Anycast, и нельзя определять Anycast только на основе различия стран. Сначала следует различать, что вы читаете: страну регистрации, коммерческую оценку местоположения или узел обслуживания, фактически наблюдаемый в конкретном запросе; они описывают разные факты, и нельзя судить, кто ошибся, лишь по «несовпадению двух стран».
Страна регистрации берётся из регистрационных записей ресурсов в RDAP или Whois и описывает административную принадлежность адресного блока, а не регион, где находится конечное устройство. Например, для диапазона адресов, зарегистрированного в Канаде, но долгое время используемого дата-центром в США, геобаза может указать американский город; при этом страна регистрации по-прежнему будет Канадой. Это разные поля, их не следует сравнивать напрямую. При просмотре нескольких результатов запроса сначала уточните, что указано на странице: «страна» (country), «страна регистрации» (registered country) или «местоположение» (location).
Anycast — это ещё одна возможность, требующая независимых доказательств. Один и тот же адрес сервиса может обслуживаться из нескольких мест, и политика маршрутизации определяет, к какому экземпляру попадёт текущий запрос, но не гарантирует выбор физически ближайшего узла. Обсуждать влияние Anycast на геолокацию уместно только при наличии подтверждений от оператора, измерений из нескольких точек или идентификации экземпляров. То, что две коммерческие базы показывают разные страны, само по себе не доказывает Anycast и не исключает устаревание базы, изменение распределения или обычное транснациональное развёртывание.
При сверке сначала посмотрите организацию, диапазоны и события в RDAP, а затем используйте наблюдения BGP как контекст маршрутизации. Один ASN может охватывать несколько стран, а появление нескольких исходных ASN для одного префикса имеет разные объяснения, и ни одно из них не позволяет однозначно определить город обслуживания. Если удастся получить региональное описание от оператора, поддерживаемый Geofeed или измерения из нескольких точек, укажите время и охват каждого из них и постепенно сужайте оценку, а не отвергайте коммерческую геолокацию только на основе страны регистрации.
При диагностике сначала запишите полный адрес IPv4/IPv6, время запроса и названия полей, которые показывает каждая платформа. Если адрес относится к Anycast или транснациональной облачной сети, не спешите подавать исправление, а посмотрите анонсы маршрутов для этого префикса и публичную документацию сетевого оператора. Любое суждение «здесь точно ошибка» должно формироваться с учётом регистрационной информации, наблюдений BGP и фактических доказательств выхода. Подробнее о связи RDAP, ASN, BGP и доказательств местоположения читайте в RDAP, ASN, BGP и RPKI: что показывают данные об IP.
Заявка на исправление: уровни доказательств, фиксация времени и границы распространения
Материалы для исправления должны соответствовать конкретному полю. Описание развёртывания оператором для этого диапазона адресов, поддерживаемый Geofeed и регион предоставления сервиса могут дать подсказки о местоположении использования; задержка, traceroute, обратный DNS предоставляют вспомогательные наблюдения. Записи плоскости управления BGP не дают напрямую физического расположения сервера, их нельзя приводить как доказательство точного местоположения ЦОДа. Все материалы следует проверять на подлинность, дату обновления, охват и применимость к текущему адресу, а не устанавливать универсальную иерархию авторитетности.
Более слабые, но допустимые материалы: отчёты пользователей, настройка часового пояса операционной системы сервера, язык контента веб-сайта. Часовой пояс ОС можно изменить произвольно, он не доказывает физическое местоположение устройства; язык сайта или региональные настройки аккаунта скорее отражают предпочтения контента, а не принадлежность IP. При подаче исправления не загружайте точный домашний адрес, пароли от аккаунтов или скриншоты админ-панели; предоставьте достаточно публичных или операционных данных, чтобы обслуживающая сторона могла определить местоположение использования адреса.
Для каждого запроса сохраняйте дату, время и часовой пояс. Рассмотрим условный пример: в марте 2024 года адрес перераспределили в другой регион, но в мае база геолокации всё ещё не обновлена. Скриншот за январь в таком случае может оказаться устаревшим доказательством для запроса на исправление. Результаты проверки одного адреса в разные даты помогают отличить разовое обновление одного источника от постепенного распространения изменений между несколькими источниками. Приложите хронологию старых и новых записей и укажите источник каждого результата. Это поможет ответственному специалисту проверить данные, но не гарантирует ни принятия исправления, ни определённого срока обработки.
Поставщик данных и сайт, использующий эти данные, — это разные этапы обновления. Такие источники, как MaxMind, IP2Location, могут сначала обновить собственные базы, но сайтам, которые используют эти данные, необходимо их скачать, развернуть и, возможно, настроить кэширование. Поэтому, если источник показывает новый результат, а конкретный сайт всё ещё старый, это не обязательно означает, что источник не внёс исправление. В такой ситуации следует по отдельности проверить: исправил ли источник данные; какую версию использует сайт; настроил ли сайт собственный кэш или логику отката.
Ни один канал исправления не должен обещать, что «после внесения правок другие платформы синхронизируются в определённые сроки». Публикация Geofeed или официальное исправление — это лишь начало цепочки обновления данных. Некоторые офлайн-базы могут выпускать обновления раз в несколько месяцев, а некоторые сайты могут использовать собственные или сторонние данные вместо прямой подписки на источник. Нельзя ожидать, что одна заявка одновременно изменит результаты во всех сервисах. После успешной отправки следует дождаться выхода новой версии, затем снова запросить тот же адрес и то же поле и проверить как минимум в два независимых момента времени. Если какая-то платформа действительно долго не обновляется, стоит задать вопрос о том, как она использует данные, а не повторять отправку уже корректных данных.
Наконец, цель исправления — сделать данные ближе к реальной картине использования сети, а не изменить адрес на страну или город, которые вам хотелось бы видеть. Если доказательств ошибки недостаточно или источник уже указал, что адрес относится к Anycast или динамическому выходному узлу, продолжение подачи заявок может не дать результата. Вы можете дополнительно разобраться, как геобазы обновляются и проверяются, с помощью Источники данных и методика.
