Что такое прокси-сервер?

Прокси-сервер — это промежуточный сервер, который находится между клиентом (например, приложением) и конечным сервером (например, серверным API). Когда приложение отправляет запрос, прокси-сервер получает его сначала. Затем прокси-сервер может перенаправить запрос на целевой сервер, изменить его, заблокировать его или напрямую вернуть ответ.

Короче говоря, прокси-сервер действует от имени клиента или сервера для обмена данными.

Как работает прокси-сервер

Прокси-серверы работают на уровне HTTP (или других протоколах приложений), получая входящие запросы и выполняя одно или несколько следующих действий:

  • Переадресация запроса на целевой сервер, а затем ретрансляция ответа клиенту.
  • Изменение заголовков, URL-адресов или полезной нагрузки перед пересылкой.
  • Перехват и реагирование на запрос локально без обращения к целевому серверу.
  • Отклонение запроса на основе правил или политик доступа.

С точки зрения клиента, он просто отправляет запрос НА URL-адрес. Прокси-сервер обрабатывает все остальное за кулисами. Шаблон — это клиент к прокси к целевому серверу.

Этот шаблон представляет уровень управления и абстракции, который можно использовать для повышения безопасности, наблюдаемости, производительности и тестирования.

Типы прокси-серверов

Существуют различные типы прокси-серверов. Каждая из них подходит для определенных ролей в системной архитектуре.

Перенаправление прокси-сервера

Прямой прокси-сервер находится перед клиентом . Когда приложение выполняет запрос, он проходит через прокси-сервер, который решает, следует ли и как перенаправить его. Прямые прокси-серверы обычно используют для:

  • Управление доступом к внешним ресурсам.
  • Анонимизировать трафик клиента.
  • Журнал исходящего трафика для мониторинга.
  • Применение фильтрации содержимого или преобразования.

Обратный прокси-сервер

Обратный прокси-сервер находится перед сервером . Клиенты не знают о базовой внутренней инфраструктуре. Обратный прокси-сервер получает входящие запросы и пересылает их на один из нескольких внутренних серверов. Обратные прокси-серверы обычно используются для:

  • Балансировка нагрузки трафика между несколькими службами.
  • Используйте кэшированные ответы для уменьшения нагрузки на сервер.
  • Завершение подключений TLS/SSL.
  • Скрытие внутренних сведений о службе из общедоступного Интернета.

Прозрачный прокси-сервер

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

Почему прокси-серверы имеют значение для разработчиков приложений

Часто инфраструктура или сетевые команды управляют прокси-серверами. Однако прокси-серверы напрямую влияют на поведение приложения, особенно в средах разработки и тестирования. Ниже приведены некоторые практические способы, которые влияют на повседневную работу.

Отладка и наблюдаемость

Прокси-серверы могут записывать и проверять HTTP-трафик. Такие инструменты, как Dev Proxy, Fiddler, Proxyman, Charles Proxy или mitmproxy, действуют как локальные прокси-серверы пересылки. Вы можете запустить приложение с помощью них для анализа запросов и ответов, обнаружения ошибок и проверки заголовков или маркеров проверки подлинности.

Шлюз API и маршрутизация

Во многих рабочих системах трафик к серверной части приложения направляется через шлюз API или обратный прокси-сервер, например NGINX, или облачную службу, например управление API Azure. Эти прокси-серверы обрабатывают маршрутизацию, проверку подлинности, ограничение скорости и многое другое.

При разработке API или создании распределенных служб необходимо понять, как прокси-серверы влияют на заголовки (например X-Forwarded-For, время ожидания и ограничения размера запроса).

CORS и локальная разработка

Во время локальной разработки, особенно в веб-приложениях, при вызове API из браузера могут возникнуть ограничения общего доступа к ресурсам между источниками (CORS). Прокси-сервер разработки может пересылать запросы в целевой API, перезаписывая заголовки, чтобы обойти ограничения CORS. Распространенные примеры средств разработчика, которые переписывают запросы CORS, включают в себя vite, webpack-dev-serverили пользовательское промежуточное прокси-программное обеспечение в фреймворках, таких как Express или ASP.NET Core.

Виртуализация и тестирование служб

Прокси-серверы могут имитировать интерфейсы API серверной части. Эта возможность полезна, если реальная служба недоступна, нестабильная или дорогостоящая для использования во время тестирования. Перехватывая и имитируя ответы, вы можете тестировать поведение приложения в различных сценариях, таких как тайм-ауты, ошибки или некорректно сформированные данные.

Средства, такие как Прокси-сервер разработки или пользовательские реализации прокси-сервера, обычно используются для этой цели в интеграции и сквозных тестах.

Проверка подлинности и безопасность

Прокси-серверы часто являются фронтом защиты в защите приложений. Они могут применять элементы управления доступом, внедрять заголовки проверки подлинности или завершать подключения TLS/SSL. В качестве разработчика важно знать, как работает ваше приложение, когда оно находится за прокси-сервером и как получить доступ к заголовкам, которые несут проверку подлинности или сведения о удостоверении.

Общие рекомендации по заголовкам и прокси-серверам

Когда запрос проходит через прокси-сервер, некоторые заголовки добавляются или изменяются, чтобы сохранить важные метаданные. Например:

  • X-Forwarded-For: указывает исходный IP-адрес клиента.
  • X-Forwarded-Proto: указывает исходный протокол (HTTP или HTTPS).
  • X-Forwarded-Host: указывает на тот исходный хост, запрошенный клиентом.

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

Использование прокси-сервера для проверки того, как приложение обрабатывает сбои API

Так как прокси-сервер пересылки видит каждый запрос, отправляемый приложением, он также может вернуть некоторые из них с ошибкой вместо их пересылки: 500, 429 Too Many Requests с заголовком Retry-After или ответ, который приходит через 8 секунд. Приложение продолжает вызывать реальные URL-адреса API, поэтому вы тестируете приложение так, как оно работает в production, включая его HTTP-клиент, пакет SDK и политику повторных попыток.

По сравнению с другими способами тестирования сбоев API:

Approach Что вы найдете Чего вам не хватает
Ожидание продакшна Реальные сбои Всё, пока пользователь не нажмёт на неё
Создайте мок API в своих тестах или позвольте агенту для написания кода написать мок Запускаются ли ветви обработки ошибок Реальные коды состояния, заголовки и тела ошибок вашего API, а также политика повторных попыток вашего SDK. Приложению также требуется переключатель только для тестирования, чтобы достичь mock-объекта.
Вызовите реальный API и надейтесь, что он завершится ошибкой Реальное поведение Невозможно вызвать сбой по требованию
Запустите приложение через прокси-сервер, который имитирует сбои Ошибки, троттлинг и задержка в реальных URL-адресах по запросу Ваш код в изоляции. Оставьте это для модульных тестов.

Dev Proxy в качестве прямого прокси для разработки и тестирования

Dev Proxy — это прокси-сервер пересылки, который вы запускаете на компьютере или в CI, чтобы перехватывать и изменять запросы из приложения к выбранным API. С помощью прокси-сервера разработки можно:

  • Узнайте, как приложение реагирует на ошибки API.
  • Проверьте, как приложение обрабатывает ограничения скорости API и троттлинг.
  • Узнайте, как приложение обрабатывает медленные API.
  • Разверните mock API без написания ни строки кода.
  • Получите контекстное руководство по использованию API.

Чтобы опробовать это на API, которые вызывает ваше приложение, скачайте предустановку и запустите прокси-сервер разработки с ним. Например, для GitHub:

devproxy config get github-rate-limiting
devproxy --config-file "~dataFolder/configs/github-rate-limiting/.devproxy/devproxyrc.json"

Предварительные наборы также доступны для конечных точек OpenAI (openai-throttling), Anthropic (anthropic-throttling), Microsoft Graph OneDrive и SharePoint конечных точек (microsoft-graph-rate-limiting).

Попробуйте самостоятельно

Выберите сценарий, соответствующий тому, что вы создаёте:

Следующий шаг

Начало работы

  • Последнее обновление: