Большинство методов геолокации по IP вполне обоснованно предполагают, что адрес соответствует примерно фиксированному физическому местоположению или стабильной идентифицируемой сети. Адресация anycast нарушает это предположение особым и интересным образом, и в этом стоит разобраться, если вам доводится определять местоположение трафика, идущего из сети доставки контента или крупного распределённого сервиса, а не из обычного подключения конечного пользователя.
При anycast один и тот же IP-адрес анонсируется одновременно из нескольких физических мест, и интернет-маршрутизация доставляет каждый запрос в то место анонса, которое в данный момент ближе всего или лучше всего расположено с точки зрения отправителя запроса. Именно так многие сети доставки контента достигают низкой задержки в глобальном масштабе: один и тот же адрес отвечает пользователям локально повсюду, а не направляет каждый запрос на один центральный сервер. Практическое следствие для геолокации в том, что один и тот же IP-адрес действительно может соответствовать разным физическим местоположениям серверов в зависимости от того, кто и откуда спрашивает, а это принципиально иная ситуация, чем обычный IP, привязанный к одному фиксированному месту.
Это значит, что результат геолокации для адреса anycast лучше понимать как описание оператора этой сети anycast, а иногда как репрезентативную или часто используемую точку в пределах её распределённой инфраструктуры, а не как одно фиксированное физическое местоположение, как было бы при определении обычного домашнего или корпоративного IP. Считать возвращённое местоположение «точным местом, откуда физически обслуживается трафик» для одних целей разумное приближение, а для других это может быть существенной ошибкой, в зависимости от того, как именно маршрутизация anycast этой сети ведёт себя для конкретного запроса.
Это важнее всего для тех, кто пытается определить источник трафика, проходящего через CDN или аналогичный крупный распределённый сервис или исходящего от него. Если вы пытаетесь определить посетителя сайта по IP, но его запрос прошёл через пограничный сервер CDN, прежде чем попасть в ваш слой журналирования или приложения, и вы определяете местоположение IP пограничного сервера CDN, а не исходного посетителя, то вы определяете местоположение инфраструктуры CDN, а не того человека, который вам на самом деле интересен. Правильная запись реального IP посетителя в журналы, обычно через заголовок forwarded-for, корректно настроенный на уровне CDN, здесь гораздо важнее любых улучшений самого сервиса геолокации, поскольку никакое определение местоположения не восстановит данные, которые слой обработки запросов изначально не сохранил.
Поля asn и organization дают самый явный сигнал того, что перед вами инфраструктура CDN или anycast, а не обычное подключение конечного пользователя. Их стоит проверять каждый раз, когда результаты геолокации для известного сервиса или платформы неожиданно сосредоточены в небольшом числе мест независимо от того, где находятся её реальные пользователи. Наши эндпоинты IPv4 и определения IPv6 возвращают эти поля именно для такой диагностики.