Практически каждое современное веб-приложение работает через Reverse Proxy. Именно он принимает входящие запросы, выполняет SSL-терминацию, балансировку нагрузки, маршрутизацию и защиту приложения. В такой архитектуре возникает важный вопрос: где лучше определять геолокацию пользователя? От правильного ответа зависит не только точность GeoIP, но и производительность всей системы.

На первый взгляд может показаться, что достаточно передать IP в GeoIP API из backend-приложения. Однако в реальности запрос может пройти через несколько балансировщиков, CDN и прокси-серверов, поэтому приложение рискует получить не адрес пользователя, а IP одного из промежуточных узлов.

В предыдущей статье мы рассмотрели использование GeoIP в архитектуре Zero Trust. Теперь разберем, как Reverse Proxy влияет на определение IP и где лучше выполнять GeoIP Lookup.

Содержание

Что такое Reverse Proxy
Почему возникают проблемы с GeoIP
Как Reverse Proxy передает IP клиента
Почему нельзя доверять любому X-Forwarded-For
Где лучше выполнять GeoIP Lookup
В самом Reverse Proxy
В API Gateway
В отдельном GeoIP-сервисе
В backend-приложении
Какой вариант лучше
Кеширование GeoIP
Использование совместно с WAF
Типичные ошибки
Использование внутреннего IP
Доверие любым заголовкам
Выполнение GeoIP каждым сервисом
Отсутствие кеширования
GeoIP от WildX
Полезно прочитать
Дополнительные материалы
Заключение

Что такое Reverse Proxy

Reverse Proxy — это сервер, который принимает запросы от клиентов и перенаправляет их внутренним сервисам.

Типичная схема выглядит следующим образом:

Пользователь
      │
      ▼
Reverse Proxy
      │
      ▼
Backend

В качестве Reverse Proxy чаще всего используются:

Nginx;
HAProxy;
Envoy;
Traefik;
Apache HTTP Server;
облачные балансировщики AWS, Azure и Google Cloud;
CDN, например Cloudflare.

В большинстве случаев именно Reverse Proxy первым получает реальный IP клиента.

Почему возникают проблемы с GeoIP

Если приложение определяет IP неправильно, GeoIP начинает работать некорректно.

Например:

Пользователь

203.0.113.15

        │

        ▼

Reverse Proxy

10.10.1.8

        │

        ▼

Backend

Если backend использует сетевой адрес соединения, он увидит:

10.10.1.8

Вместо:

203.0.113.15

Поскольку внутренний адрес не связан с пользователем, определить его географическое положение невозможно.

Как Reverse Proxy передает IP клиента

Обычно Reverse Proxy добавляет специальные HTTP-заголовки.

Наиболее распространенные:

X-Forwarded-For
X-Real-IP
Forwarded

Например:

X-Forwarded-For: 203.0.113.15
X-Real-IP: 203.0.113.15

Backend должен использовать именно эти значения, а не IP TCP-соединения.

Почему нельзя доверять любому X-Forwarded-For

Многие начинающие разработчики совершают одну и ту же ошибку.

Они принимают первый заголовок:

X-Forwarded-For

без проверки.

Однако пользователь способен самостоятельно отправить:

X-Forwarded-For: 1.2.3.4

Если приложение доверяет любому значению, злоумышленник сможет:

изменить определяемую страну;
обойти некоторые ограничения;
повлиять на Rate Limiting;
исказить аналитику.

Поэтому доверять следует только заголовкам, добавленным известным Reverse Proxy.

Где лучше выполнять GeoIP Lookup

Существует несколько популярных вариантов.

В самом Reverse Proxy

Это один из наиболее распространенных подходов.

Схема выглядит следующим образом:

Запрос
      │
      ▼
Reverse Proxy
      │
      ├── Определение IP
      ├── GeoIP
      └── Добавление заголовков
      │
      ▼
Backend

Например:

X-Geo-Country: DE
X-Geo-Region: HE
X-Geo-City: Frankfurt

Преимущества:

GeoIP определяется один раз;
backend становится проще;
все сервисы используют одинаковые данные;
уменьшается количество обращений к GeoIP API.

Такой подход особенно удобен в микросервисной архитектуре.

В API Gateway

Если инфраструктура использует Gateway, GeoIP можно выполнять именно там.

Пользователь
      │
      ▼
Gateway
      │
      ▼
GeoIP
      │
      ▼
Backend

Это позволяет централизовать обработку всех входящих запросов.

В отдельном GeoIP-сервисе

Еще один популярный вариант — выделить GeoIP в самостоятельный сервис.

Reverse Proxy
      │
      ▼
Backend
      │
      ▼
GeoIP Service
      │
      ▼
GeoIP API

Такое решение хорошо подходит для крупных микросервисных систем.

Преимущества:

централизованная логика;
общий кеш;
независимое масштабирование;
простая замена поставщика GeoIP.

В backend-приложении

Самый простой вариант.

Backend самостоятельно:

получает IP;
вызывает GeoIP API;
использует результат.

Такой подход подходит небольшим проектам, однако при росте инфраструктуры появляется дублирование кода и увеличивается количество одинаковых запросов.

Какой вариант лучше

Все зависит от масштаба системы.

Для небольшого проекта:

Reverse Proxy
      │
      ▼
Backend
      │
      ▼
GeoIP

Для микросервисной архитектуры:

Reverse Proxy
      │
      ▼
Gateway
      │
      ▼
GeoIP Service
      │
      ▼
Backend

Именно второй вариант сегодня используется значительно чаще в крупных инфраструктурах.

Кеширование GeoIP

Даже если GeoIP определяется на уровне Reverse Proxy, выполнять запрос к API при каждом обращении нецелесообразно.

Лучше использовать кеш.

Например:

IP
      │
      ▼
Redis
      │
      ├── найден
      │
      ▼
Ответ

или

IP
      │
      ▼
Redis
      │
      └── отсутствует
              │
              ▼
         GeoIP API
              │
              ▼
         Сохранить в кеш

Это позволяет существенно снизить нагрузку и ускорить обработку запросов.

Использование совместно с WAF

Во многих инфраструктурах Reverse Proxy одновременно выполняет функции WAF.

Тогда последовательность обработки выглядит так:

Интернет
      │
      ▼
Reverse Proxy
      │
      ├── WAF
      ├── GeoIP
      ├── Rate Limiting
      ├── Bot Detection
      └── Routing
      │
      ▼
Backend

Такой подход уменьшает нагрузку на приложение и позволяет блокировать часть вредоносного трафика еще до передачи запроса backend-сервисам.

Типичные ошибки

Использование внутреннего IP

Самая распространенная проблема.

Backend определяет:

10.x.x.x

вместо публичного адреса пользователя.

В результате GeoIP становится бесполезным.

Доверие любым заголовкам

Использовать X-Forwarded-For без списка доверенных прокси опасно.

Необходимо принимать во внимание только те заголовки, которые добавлены собственным Reverse Proxy.

Выполнение GeoIP каждым сервисом

Если десятки микросервисов самостоятельно обращаются к GeoIP API, возникают:

лишняя нагрузка;
повторные запросы;
усложнение сопровождения;
разные реализации обработки ошибок.

Лучше централизовать интеграцию.

Отсутствие кеширования

Даже один и тот же пользователь может выполнить сотни запросов за короткое время.

Повторное определение GeoIP при каждом обращении значительно увеличивает нагрузку на инфраструктуру.

GeoIP от WildX

Для определения географического положения пользователей можно использовать GeoIP от WildX.

Сервис предоставляет информацию о стране, регионе, городе, часовом поясе, ASN и интернет-провайдере. Эти данные можно использовать на уровне Reverse Proxy, API Gateway или выделенного GeoIP-сервиса для централизованной обработки входящего трафика.

Полезно прочитать

Рекомендуем также ознакомиться:

Дополнительные материалы

Подробную информацию о работе Reverse Proxy, заголовках X-Forwarded-For, Forwarded и безопасной передаче клиентского IP можно найти в документации:

Nginx — https://nginx.org/
HAProxy — https://www.haproxy.org/
Envoy Proxy — https://www.envoyproxy.io/

Заключение

GeoIP Reverse Proxy позволяет определять местоположение пользователя еще до передачи запроса приложению и избежать множества типичных ошибок, связанных с внутренними IP-адресами и промежуточными прокси. Для небольших проектов достаточно выполнять GeoIP в backend, однако в современных распределенных системах чаще используют централизованную обработку на уровне Reverse Proxy, API Gateway или отдельного GeoIP-сервиса. В сочетании с кешированием, WAF и корректной передачей доверенных заголовков такой подход обеспечивает высокую производительность, точность определения геолокации и упрощает сопровождение инфраструктуры.