Yandex Cloud
Поиск
Связаться с намиПодключиться
  • Истории успеха
  • Документация
  • Блог
  • Все сервисы
  • Статус работы сервисов
    • Популярные
    • Инфраструктура и сеть
    • Платформа данных
    • Контейнеры
    • Инструменты разработчика
    • Бессерверные вычисления
    • Безопасность
    • Мониторинг и управление ресурсами
    • ИИ для бизнеса
    • Бизнес-инструменты
  • Все решения
    • По отраслям
    • По типу задач
    • Экономика платформы
    • Безопасность
    • Техническая поддержка
    • Каталог партнёров
    • Обучение и сертификация
    • Облако для стартапов
    • Облако для крупного бизнеса
    • Центр технологий для общества
    • Облако для интеграторов
    • Поддержка IT-бизнеса
    • Облако для фрилансеров
    • Обучение и сертификация
    • Блог
    • Документация
    • Контент-программа
    • Мероприятия и вебинары
    • Контакты, чаты и сообщества
    • Идеи
    • Тарифы Yandex Cloud
    • Промоакции и free tier
    • Правила тарификации
  • Истории успеха
  • Документация
  • Блог
Проект Яндекса
© 2025 ООО «Яндекс.Облако»
Все решения
    • Все решения для Application Load Balancer
    • Устранение ошибки `no_route` при открытии адреса
    • Устранение сложностей с добавлением маршрута
    • Как получить реальный IP-адрес источника в заголовках запросов

В этой статье:

  • Описание задачи
  • Решение
  1. Application Load Balancer
  2. Как получить реальный IP-адрес источника в заголовках запросов

Как получить реальный IP-адрес источника в заголовках запросов

Статья создана
Yandex Cloud
Обновлена 17 октября 2025 г.
  • Описание задачи
  • Решение

Описание задачиОписание задачи

Необходимо журналировать внешние IP-адреса клиентов, устанавливающих соединения с балансировщиком.

РешениеРешение

Когда трафик перехватывается между клиентами и серверами, журналы доступа к серверу содержат только IP-адрес прокси-сервера или балансировки нагрузки.

В Yandex Network Load Balancer IP-адрес удаленного хоста, инициирующего запрос, виден по умолчанию без дополнительных настроек, если не используется Ingress Controller для Kubernetes. При его использовании для сохранения реальных адресов запросов необходимо вручную настроить политику TrafficPolicy: local по инструкции.

При использовании Yandex Application Load Balancer IP-адрес источника запроса фигурирует в заголовке X-forwarded-for.
Заголовок X-Forwarded-For необходим для идентификации происхождения IP-адреса пользователя, подключающегося к веб-серверу через HTTP-прокси или балансировщик нагрузки.

Если необходимо журналировать внешние адреса в журнал веб-сервера, потребуется изменить его конфигурацию.

Nginx
Apache

Если в качестве бэкенда используется веб-сервер Nginx, то в конфигурации службы Nginx внутри блока log_format должна содержаться переменная http_x_forwarded_for:

log_format main '$remote_addr - $http_x_forwarded_for - $remote_user [$time_local] "$request" '
                '$status $body_bytes_sent "$http_referer" '
                '"$http_user_agent" $request_time';

Если в качестве бэкенда используется веб-сервер Apache, в конфигурации службы Apache должна содержаться переменная %{X-Forwarded-For}:

Log format config

LogFormat "%{X-Forwarded-For}i %l %u %t "%r" %>s %b "%{Referer}i" "%{User-Agent}i"" common
SetEnvIf X-Forwarded-For "^......." forwarded
CustomLog "logs/access_log" common env=forwarded

После изменения конфигурации веб-сервера и его перезапуска вы увидите в журналах внешние IP-адреса клиентов.
Например, если на Ingress приходит запрос с IP 123.34.56.67:

kubectl logs nginx-ingress-nginx-ingress-*****
123.34.56.67 - - [28/Jun/2022:09:11:32 +0000] "GET / HTTP/1.1" 200 615 "-" "curl/7.68.0" "-"

В логах пода с бэкендом этот адрес будет фигурировтаь внутри заголовка X-Forwarded-For:

kubectl logs -n demo-ns pod/nginx
10.20.129.8 - - [28/Jun/2022:09:11:32 +0000] "GET / HTTP/1.1" 200 615 "-" "curl/7.68.0" "123.34.56.67"

Была ли статья полезна?

Предыдущая
Устранение сложностей с добавлением маршрута
Следующая
Все решения для Yandex Cloud Billing
Проект Яндекса
© 2025 ООО «Яндекс.Облако»