Proxy API для ИИ — не всякий шлюз является сетевым прокси

Если ты проектируешь посредника перед платными моделями ИИ, эта разница не косметическая. Контроль, скопированный с сетевого прокси на LLM-шлюз по одному лишь названию, оставляет дыры именно там, где у шлюза появляются новые полномочия: он читает тело запроса, выбирает провайдера и пишет содержательные логи. provod.ai в этом смысле корректнее называть сервисным API-маршрутом, а не сетевым прокси: дело не в формулировке, а в том, какую модель угроз к нему применять.

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

Термин proxy удобен именно потому, что он верхнеуровневый: и там, и там есть клиент, посредник и апстрим. За вывеской скрываются разные запросы: кто-то ищет транспортный компонент как proxy api или прокси api, кто-то ищет посредника специально для моделей и пишет proxy api ai, а кто-то имеет в виду облачный сервис целиком и пишет cloud ai api. Удобство общего слова здесь оплачивается скрытой архитектурной разницей.

MDN описывает две структурные роли прокси. Forward proxy действует от имени клиента: скрывает его личность, форвардит и контролирует трафик группы (DNS, веб-запросы). Reverse proxy действует от имени сервера: балансировка, кэш, терминация TLS, сокрытие адресов бэкенда. По документации MDN ни та ни другая роль не подразумевает понимания смысла тела запроса: прокси работает с транспортом.

Документация NGINX подтверждает это на уровне механики: proxy_pass пересылает запрос на бэкенд, переписывая только транспортные поля вроде заголовков Host и Connection. Модуль оперирует HTTP-обвязкой, а не значением содержимого. Это документированная позиция по умолчанию, а не жёсткий технический потолок: тот же reverse proxy можно поставить с WAF-модулем, и тогда он начнёт заглядывать в тело. Но по умолчанию посредник не знает, что внутри: платёжка, промпт или картинка.

Возьми для контраста Cloudflare AI Gateway. По документации Cloudflare это слой между приложением и несколькими названными LLM-провайдерами (OpenAI, Anthropic, Google, Workers AI, Replicate), который отдаёт аналитику по запросам, числу токенов и стоимости на запрос. Чтобы посчитать токены и цену, нужно понимать полезную нагрузку LLM, а это уже не транспорт. Вот первое расхождение, которое ломает эквивалентность: сетевой прокси по умолчанию слеп к смыслу запроса, а LLM-gateway зряч по определению своих функций. Дальше это расхождение проявляется в каждом из четырёх потоков.

Чтобы не спорить о словах, разложим посредника на четыре наблюдаемых потока и по каждому спросим одно и то же: где он живёт, кто им владеет, кто его видит.

Поток ключа. В документации LiteLLM описаны виртуальные ключи с префиксом sk-..., которые прокси выдаёт вызывающим. Это не настоящие ключи вышестоящего провайдера: они остаются скрытыми за прокси, пока тот обеспечивает лимиты по ключу, пользователю и команде и считает расход. У LLM-шлюза появляется собственная сущность доступа, свой ai proxy api key, отдельная от апстрим-ключа, со своим жизненным циклом, отзывом и квотой. У сетевого прокси такой сущности в документированном дефолте нет: он форвардит то, что пришло, и ключ провайдера, если он есть в заголовке, проходит через него обычным байтовым потоком.

Поток запроса. По документации архитектуры LiteLLM вызов в формате OpenAI переводится в нативную схему конкретного провайдера. Значит, шлюз не только читает тело, но и переписывает его под целевую модель. NGINX тело по смыслу не трогает, только транспортную обвязку.

Поток логов. По документации Cloudflare каждый логируемый запрос фиксирует модель, провайдера, использование токенов, стоимость и длительность, а хранение самого тела (сырой запрос и ответ) включается отдельно, заголовком cf-aig-collect-log-payload, отдельно от метаданных. У шлюза есть встроенное различие между метаданными и содержимым, и содержимое здесь управляемая опция. LiteLLM пишет пост-ответные логи в observability-бэкенды асинхронно. У сетевого прокси логи, как правило, это строки доступа: адрес, статус, размер, а не смысл диалога. Кто-то ищет такой посредник как прокси апи именно из-за этой функции: нужен не транспорт, а понятный лог того, что произошло с запросом.

Поток маршрутизации. Здесь разница самая резкая. Dynamic Routing у Cloudflare, по документации, переключает и распределяет запросы между провайдерами и моделями по латентности, стоимости или доступности. LiteLLM документирует маршрутизацию и балансировку внутри группы моделей с ретраями и фолбэками, пересекающими группы. Решение, какая модель ответит, принимает посредник. Сетевой прокси выбирает апстрим-сервер, но не подменяет саму модель как продукт.

Сетевой прокси решает задачи транспортного уровня, и его модель угроз про транспорт: терминация TLS, форвардинг IP, сокрытие адресов, балансировка. Это вопрос того, кто с кем соединяется и как проходит трафик.

OWASP API Security Top 10 (редакция 2023 года упоминается как ориентир) — таксономия рисков уровня API и приложения: сломанная авторизация на уровне объектов и функций и подобные проблемы. Она намеренно отделена от сетевых забот прокси вроде терминации TLS или форвардинга IP. Здесь она нужна не как сравнительный документ прокси против шлюза, а как словарь угроз прикладного уровня, без которого разговор про LLM-шлюз получается беспредметным.

Отсюда следует граница ответственности. Если ты защищаешь сетевой прокси, ты закрываешь транспорт: сертификаты, заголовки, доступ по IP, защиту от переполнения соединений. Спрашивать с него авторизацию на уровне объекта запроса бессмысленно: по умолчанию он не знает, что это за объект. И наоборот, если ты повесил на него ожидание посчитать токены или отрезать дорогую модель, ты повесил задачу не на тот слой.

LLM-шлюз, его ещё называют ai api gateway, берёт на себя прикладной слой поверх транспорта. Именно этот слой порождает новые угрозы, которых у сетевого прокси нет.

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

Здесь же полезная развилка в терминологии. Многие приходят к такому посреднику как к router ai api: им нужен один вход к разным моделям. Другие ищут его как ллм роутер, рассчитывая на более дешёвый доступ и автоматический фолбэк. Третьи формулируют запрос предметно, вроде дипсик опен роутер, когда хотят вызвать конкретную модель через агрегатор, который сам решает, какой апстрим использовать. Всё это законные сценарии, но каждый про прикладной слой: маршрутизация по стоимости и доступности — решение шлюза, а не свойство транспорта. Называя это «прокси», разработчик теряет из виду, что делегирует посреднику выбор модели.

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

Простота подмены base_url создаёт иллюзию, будто перед клиентом прозрачный прокси, который просто прокидывает вызов. По документации LiteLLM ключ sk-... в этой строке виртуальный, он не равен ключу апстрим-провайдера. Даже в одну строку разработчик уже соглашается на то, что посредник владеет отдельной сущностью доступа и, возможно, транслирует и логирует тело запроса. Один и тот же интерфейс OpenAI SDK не гарантирует одинаковую границу доверия за ним.

Практически эта строка работает, если клиент поддерживает протокол OpenAI: тогда подключение к каталогу моделей provod.ai сводится к замене base_url и ключа, а состав каталога остаётся тем, что сейчас доступно через платформу. Именно поэтому совет «просто поставь прокси перед моделью» без разбора потоков вредный: название «прокси» здесь описывает совместимость интерфейса, а не роль компонента и не набор его полномочий.

Нормативная позиция здесь простая: контроль выбирается по фактической роли компонента, а не по слову в его названии. Из карты потоков это следует прямо.

Ниже решающая таблица. Она отвечает на вопрос, что реально защищать для каждого потока и куда падает ответственность.

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

Формулировка прокси апи для ии обычно означает именно прикладного посредника из правой колонки, а не транспортный слой слева: ищут не терминацию TLS, а понятный доступ к моделям. Ещё точнее это видно в развёрнутой формулировке прокси сервера для ии платный апи: если у посредника есть биллинг, лимиты и понятная цена запроса, речь уже о LLM-gateway, а не о сетевом прокси, и угрозы нужно закрывать из правой колонки таблицы. Похожая логика стоит за запросом api дешево для ai: обычно это поиск маршрута без наценки поверх официальной цены провайдера, то есть вопрос биллинга, который тоже живёт в прикладном слое, а не в транспорте.

Карта потоков не аудит конкретной реализации. Она показывает, какие полномочия у компонента по документации, но не проверяет, как именно их реализовал конкретный посредник: фактические гарантии любого шлюза без проверки его кода и конфигурации остаются неизвестными. И «слепота к телу» у reverse proxy по умолчанию (MDN, NGINX) не жёсткий потолок: конкретный деплой с WAF-модулем может заглядывать в тело, и тогда его роль меняется, а вместе с ней и модель угроз.

Прокси API и LLM-gateway— синонимы? Нет. По документации это компоненты с разными потоками, и общий термин лишь скрывает разницу границ доверия.

Reverse proxy никогда не видит тело запроса? По умолчанию, согласно глоссарию MDN, нет, но с WAF-модулем может. Тогда это уже другая роль, и модель угроз меняется.

Где хранится настоящий ключ провайдера у LLM-шлюза? По документации LiteLLM апстрим-ключ скрыт за прокси, а вызывающим выдаётся виртуальный sk-.... Это два разных секрета с разным жизненным циклом.

Кто решает, какая модель ответит на запрос? На LLM-шлюзе решает сам шлюз: Cloudflare и LiteLLM документируют маршрутизацию по латентности, стоимости и доступности. Сетевой прокси выбирает сервер, но не подменяет модель.

Не строй защиту API на слове. Построй её на карте четырёх потоков (ключ, запрос, логи, маршрутизация) и выбери контроль по фактической роли посредника. Сетевой прокси и LLM-gateway расходятся по каждому из них, и список угроз у них разный. Если компонент читает тело, считает токены и выбирает модель, он живёт по правилам прикладного слоя, как бы его ни называли в чате.

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

Собери свой сервисный API-маршрут по правильной модели угроз: подключи единый API provod.ai, поменяв ключ и base_url, и распредели контроли по ролям потоков, а не по названию компонента.

Работайте без VPN и зарубежной банковской карты: модели доступны через единый API и веб-интерфейс, а баланс пополняется в рублях.

В одном каталоге — актуальные модели для текста и медиа: GPT от OpenAI, Claude от Anthropic, Gemini от Google, Grok от xAI, DeepSeek, Qwen, GLM, Kimi и MiniMax; для изображений — Nano Banana 2 Pro и GPT Image; для видео — последние версии Seedance, Kling, Veo и Google Omni. Также доступны модели для reasoning, поиска, документов, эмбеддингов, музыки и аудио.

Доступ из России не означает более дорогие токены: цена остаётся 1:1 с официальной ценой модели, без собственной наценки provod.ai; для бизнеса есть договор и закрывающие документы.

Подключите нужную модель через provod.ai: форма регистрации · цены на модели · защита данных по 152-ФЗ · реквизиты для бизнеса