Геолокация на IP адреси: как работят базите данни и как да ги коригирате

Базите данни за местоположение предполагат къде се използва IP адрес, въз основа на маршрутизацията, измерванията, записите в регистрите и това, което мрежовите оператори им казват, а сайтовете, стрийминг услугите и проверките за измами действат според тези предположения. Блок, който сменя държателя си, често запазва старото си местоположение седмици наред. Решението е geofeed, малък файл, който казва къде се използва всеки префикс, посочен от записа на блока в регистъра, след това искания към базите данни, които имат значение, и търпение: предвидете шест седмици или повече.

Кой я използва и защо грешките вредят

• Стрийминг и права върху съдържание, където местоположението е свързано с лицензи, така че грешна държава или флаг за хостинг направо блокира услугата.
• Търсене и реклама, за езика, валутата и местните резултати.
• Проверки за измами и сигурност, които маркират влизания от неочаквани места.
• Данъци, хазарт и друго съответствие, както и мрежи за доставка на съдържание, които избират сървър.

Семинарът на IAB за геолокация на IP адреси от 2025 г. оцени точността на ниво държава в geofeed на над 95%, установи много по-ниска точност на ниво град и не намери стандартен начин мрежите да коригират данни на трети страни. Докладът му посочва пазара на употребявани IPv4 като причина: блоковете се местят и „the addresses may remain 'located' in Asia in some databases for weeks or months“ (превод: „в някои бази данни адресите може да останат ‚разположени‘ в Азия седмици или месеци“) след преместването им в Европа.

Откъде базите данни вземат данните си

• Записите в регистрите, на които повечето дават най-малка тежест. Собствената документация на базата данни на RIPE казва, че атрибутът ѝ country: „cannot be used in any reliable way to map IP addresses to countries“ (превод: „не може да се използва по никакъв надежден начин за съпоставяне на IP адреси с държави“): обикновено това е държавата на държателя, а не на потребителя.
• Маршрутизацията: кои мрежи анонсират и пренасят префикса.
• Измерванията: латентност и traceroute от собствените сонди на доставчиците.
• Имената в обратния DNS и мрежовите пътища.
• Geofeed файлове, които операторите публикуват, и корекции, които подават.
• Сигнали от устройства и браузъри, при някои доставчици.

Отделно от местоположението повечето доставчици класифицират адресите: хостинг, VPN, прокси, Tor. Тези флагове често решават повече от държавата (вижте по-долу).

Файлът geofeed: RFC 8805

RFC 8805 определя CSV файл, по един ред на префикс:

# prefix,country,region,city,postal code
192.0.2.0/24,NL,NL-NH,Amsterdam,
198.51.100.0/24,DE,DE-HE,Frankfurt am Main,
203.0.113.0/24,,,,

• Префиксът е задължителен; държавата е код по ISO 3166-1, регионът е код по ISO 3166-2 като NL-NH, а градът е обикновен текст.
• Без пощенски кодове: полето е остаряло и „new feeds SHOULD NOT include“ it (превод: „новите файлове НЕ ТРЯБВА да го съдържат“).
• Празните полета означават липса на местоположение, за адресно пространство, което още не се използва, вместо предположение.
• Целият набор всеки път, а не само промените; един и същ префикс два пъти е грешка.
• UTF-8, редове, завършващи с CRLF, предоставени през HTTPS.
• Подсказка, а не заповед: доставчиците сверяват файла със собствените си данни и може да предпочетат други източници.

Посочване на файла: RFC 9632

RFC 9632, който замени RFC 9092 през август 2024 г., казва как доставчикът намира файла и кои части от него може да използва:

• От записа в регистъра: атрибут geofeed: с един HTTPS адрес или, където регистърът няма такъв, ред точно във формата remarks: Geofeed https://....
• Най-специфичният запис печели: присвояване /24 със собствена препратка има предимство пред препратката на /22 над него.
• Броят се само редовете в обхвата на записа; останалата част от файла се пренебрегва за този запис.
• Собствените подсказки за местоположение на регистъра се пренебрегват, щом за диапазона съществува geofeed.
• Събирачите изтеглят най-много веднъж седмично, от масовите данни на регистрите.
• Подписването на файла е по избор и на практика не се използва: RPKI валидаторът rpki-client премахна поддръжката за проверка на подписани файлове през януари 2026 г., тъй като никой не планираше да я използва.

Във всеки регистър

Базите данни и платформите

Проверено на 16 октомври 2026 г. Корекцията в една база данни не коригира останалите, а няколко големи платформи поддържат свои собствени.

Флагове за хостинг, VPN и прокси

Блок може да е в правилната държава и все пак да бъде отказан, защото е обозначен като хостинг или VPN пространство. Списъкът Anonymous IP на AWS WAF, управлявана група правила, която сайтът може да включи, блокира „IP addresses from web hosting and cloud providers“ (превод: „IP адреси от доставчици на уеб хостинг и облачни услуги“), освен ако сайтът не я замени; MaxMind, IP2Location и други маркират диапазони за хостинг, VPN, прокси и Tor. Тези етикети имат собствени канали за преглед, като формуляра на екипа за корекции на MaxMind и формуляра за фалшиви положителни резултати на IPQualityScore, отделно от корекциите на местоположението.

Преместен или нает блок, стъпка по стъпка

1. Проверете го, преди да го вземете: основните бази данни, флаговете им за хостинг и прокси и всеки запис в регистъра, който покрива блока, за стари препратки към geofeed или подсказки за местоположение от предишни държатели (първо проверете блока).
2. Определете истинското местоположение за всеки префикс: винаги държавата, регионът и градът, когато сте сигурни, без пощенски код, и празни полета за адресно пространство, което още не се използва.
3. Публикувайте файла през HTTPS и го проверете с валидатор като geofeed-finder или mm-geofeed-verifier на MaxMind.
4. Посочете го от най-специфичния запис в регистъра. При наем това прави държателят: той включва Вашия префикс в собствения си файл или дава на Вашето присвояване собствена препратка към Вашия файл. И двата начина работят; попитайте наемодателя кой използва и го уведомете, преди да преместите адресното пространство в друга държава.
5. Премахнете противоречащите подсказки, като остарели препратки към geofeed и грешни редове geoloc:.
6. Съгласувайте маршрутизацията: анонсирайте точния префикс там, където са потребителите му, с валиден ROA и route обект. Адресно пространство през тунел се поставя в точката на присъствие на тунела.
7. Подайте към доставчиците, които имат значение, с адреса на файла, и поискайте отделно преглед на грешни флагове за хостинг или VPN.
8. Проверете отново след една, две и шест седмици. В края на наема премахнете или изпразнете редовете на блока, за да не ги наследи следващият потребител.

Как да проверите къде се показва блокът

RIPEstat отговаря с безплатните данни GeoLite на MaxMind за всеки префикс:

curl -s "https://stat.ripe.net/data/maxmind-geo-lite/data.json?resource=203.0.113.0/24"

Заменете 203.0.113.0/24, диапазон, запазен за документация, с Вашия блок. MaxMind нарича безплатните си данни GeoLite City „considerably less accurate“ (превод: „значително по-малко точни“) от платените, а платформите със собствена база данни, като Google, не са в тях. Проверете и няколко адреса в услугите, на които потребителите Ви разчитат.

Колко време отнема

Промяната в регистъра влиза в сила веднага. Събирачите изтеглят седмично, доставчиците преглеждат и публикуват по собствен график, а много сайтове използват изтеглено копие, което актуализират, когато решат. Собствените насоки на Cloudflare за нови адреси са, че „IP geolocation will take at least six weeks to update across databases“ (превод: „актуализирането на геолокацията на IP адресите в базите данни ще отнеме поне шест седмици“). Нито един доставчик не гарантира приемане или срок.

Къде се вписва RTM Networks

При всеки наем от нас корекциите на геолокацията се правят при поискване: кажете ни къде се използват адресите и ние посочваме geofeed за блока от записа му в регистъра, наш или Ваш, и искаме от основните бази данни за местоположение да коригират своите. Колко бързо ще последва всяка от тях, зависи от нея.