Java Gemini API через прокси: как обойти блокировку Google из России

Зачем понадобился прокси и откуда взялось решение

Разработчик формата BDoc (Book Document, открытая альтернатива закрытым издательским форматам IDML, INDD и Scribus SLA) столкнулся с конкретной задачей: для работы с длинными документами нужна нейросеть с большим контекстным окном. Gemini с окном в миллион токенов подходил лучше всех, но Google заблокировала ряд регионов, и запросы оттуда не проходят.

Решение: написать на Java лёгкий прокси-сервер (ai-proxy), который разворачивается на разрешённом хостинге и прозрачно пробрасывает запросы к провайдерам ИИ. Один домен, одна точка входа, а дальше прокси сам направляет трафик к нужному сервису.

Что понадобится

• Java 17+ и сборщик Maven или Gradle
• Spring Boot с модулем WebFlux (реактивный веб-фреймворк)
• API-ключи от нужных провайдеров: Gemini, OpenAI или Anthropic
• VPS или облачный сервер вне заблокированного региона (подойдёт любой европейский или азиатский хостинг)
• Примерно 1,5 часа на первую настройку, если вы знакомы со Spring Boot

Как устроен прокси: от наивной версии к рабочей?

Автор прошёл две итерации, и разница между ними принципиальна для безопасности.

Версия 1: ключи зашиты на сервере. Первый вариант использовал Spring WebFlux и WebClient. Роутинг строился по первому сегменту пути: /gemini/..., /openai/..., /anthropic/.... Конфигурация хранила ключи прямо на сервере:

app:
  providers:
    gemini:
      base-url: https://generativelanguage.googleapis.com
      auth:
        type: query
        parameter: key
        value: ${GEMINI_API_KEY}
    openai:
      base-url: https://api.openai.com
      auth:
        type: bearer
        value: ${OPENAI_API_KEY:}
    anthropic:
      base-url: https://api.anthropic.com
      auth:
        type: header
        header: x-api-key
        value: ${ANTHROPIC_API_KEY:}

Прокси сам подставлял ключ в зависимости от типа авторизации: query-параметр для Gemini, заголовок Bearer для OpenAI, заголовок x-api-key для Anthropic.

Работало, но с двумя проблемами:

• Прокси хранил все секреты централизованно. Если через него ходят несколько клиентов с разными правами, разделить доступ нельзя без правки кода.
• Каждый новый тип авторизации требовал изменений в Java-коде: новый элемент enum, новая ветка switch, пересборка Docker-образа, повторный деплой.

Версия 2: прокси не знает ключей. Клиент сам подставляет нужный заголовок авторизации, а прокси прозрачно пробрасывает всё как есть. Это и безопаснее, и проще в поддержке.

Пошаговая инструкция

1. Создайте Spring Boot проект с зависимостью spring-boot-starter-webflux.

2. Настройте маршрутизацию. Первый сегмент пути (/gemini/, /openai/, /anthropic/) определяет, на какой базовый URL уходит запрос. Сервис UrlBuilderService собирает итоговый URI.

3. Реализуйте сервис проксирования. Центральный класс ProxyService принимает входящий запрос и пробрасывает его к провайдеру:

public Mono<ServerResponse> forward(ProxyRequest request) {
    URI uri = urlBuilderService.build(request);
    WebClient.RequestBodySpec requestBodySpec =
        webClient.method(request.method()).uri(uri);
    copyHeaders(request.headers(), requestBodySpec);

    WebClient.RequestHeadersSpec<?> clientRequest =
        hasBody(request.method())
            ? requestBodySpec.body(request.body(), DataBuffer.class)
            : requestBodySpec;

    return clientRequest.retrieve()
        .onStatus(status -> true, err -> Mono.empty())
        .toEntityFlux(DataBuffer.class)
        .flatMap(entity -> {
            HttpHeaders filtered = filterHeaders(entity.getHeaders());
            Flux<DataBuffer> body = entity.getBody() != null
                ? entity.getBody() : Flux.empty();
            return ServerResponse.status(entity.getStatusCode())
                .headers(h -> h.addAll(filtered))
                .body(BodyInserters.fromPublisher(body, DataBuffer.class));
        });
}

1. Фильтруйте служебные заголовки. При копировании заголовков из входящего запроса исключайте Host, Content-Length и Accept-Encoding. Из ответа провайдера удаляйте Content-Length, Transfer-Encoding и Content-Encoding, чтобы не сломать потоковую передачу.

2. Разверните на VPS вне заблокированного региона. Соберите Docker-образ, запустите на сервере, направьте свой домен на этот сервер.

3. В клиенте укажите адрес прокси вместо прямого URL провайдера. Ключ авторизации клиент подставляет сам, прокси его не хранит и не видит.

Кому это пригодится прямо сейчас?

Java-разработчикам в РФ и СНГ. Если вы строите продукт на Java Gemini API и столкнулись с географической блокировкой, этот прокси решает проблему за один вечер. Код минимален: один сервис, одна маршрутизация, никакой бизнес-логики.

Авторам и контент-командам. Если ваш ИИ-инструмент для генерации текстов опирается на Gemini из-за длинного контекста, попросите разработчика поднять такой прокси. Миллион токенов, это примерно 700 000 слов: можно скормить модели целую книгу и работать с ней в одном диалоге.

Предпринимателям, которые тестируют несколько ИИ-провайдеров. Единая точка входа для Gemini, OpenAI и Anthropic упрощает переключение между моделями. Не нужно менять инфраструктуру при смене провайдера.

Для тех, кто работает с Java Gemini API из России, этот прокси закрывает реальную боль: не нужно держать VPN на каждой машине, не нужно менять код клиента, не нужно хранить ключи в одном месте. Разверните, проверьте на тестовом запросе и забудьте о блокировке.