Proxy sieciowe Gemini: konfiguracja i diagnostyka połączenia klienta

Przeprowadzić google-genai przez proxy HTTP CONNECT, zostawić TLS włączone i odróżnić martwy przeskok od odmowy API, nie traktując tunelu jako dostępu do Google.

Ten przewodnik jest dla programistów, którzy potrzebują, żeby google-genai 2.30.1 wychodził przez proxy HTTP CONNECT. Sprawdzenia używały origin na loopback i atrapy przeskoku, nie konta Google. Top Proxy nie sprzedaje adresów IP i nie ma tu darmowych kluczy. Działający tunel to nie dostęp do API.

01Wybrać jednego klienta Gemini i przypiąć go#

Gemini to rodzina produktów. Konsumencka aplikacja WWW, Gemini Developer API, Vertex AI albo Gemini Enterprise Agent Platform i Gemini CLI nie dzielą jednego pokrętła proxy. Mieszanie ich to sposób, by debugować przeglądarkę, podczas gdy proces Pythona nadal idzie bezpośrednio. Ten opis zostaje przy jednym kliencie: Google Gen AI Python SDK rozmawiającym z Gemini Developer API.

Dokumentacja Gemini API, odczytana 15 października 2026, ostatnia aktualizacja 13 października 2026 UTC, opisuje to API jako ścieżkę od promptu do produkcji. Nie dokumentuje proxy. Okablowanie proxy siedzi w README SDK. Dostępne regiony, ostatnia aktualizacja 28 kwietnia 2026, to lista krajów dla AI Studio i API. Proxy nie dodaje brakującego regionu, zweryfikowanego wieku ani konta rozliczeniowego.

Przypiąć to, co się importuje. Ten przebieg używał Pythona 3.14.6, google-genai 2.30.1, httpx 0.28.1 i LibreSSL 3.3.6 jako binarki openssl dla laboratoryjnego CA. PyPI tego samego dnia wymieniało 2.30.1. Zainstalowany klient domyślnie kierował Gemini Developer API na https://generativelanguage.googleapis.com/ i v1beta. Vertex używa innego konstruktora i innego hosta. Tu zostawić go w spokoju.

1. Utworzyć venv na Pythonie, który naprawdę będzie uruchamiany. Ta maszyna używała /opt/homebrew/bin/python3.14.
2. Zainstalować google-genai==2.30.1. Nie pozwalać późniejszemu wheelowi przepisać stosu HTTP pod spodem.
3. Wypisać wersje, zanim ruszy się proxy. Zachować wiersze google-genai i httpx.

README, sekcja Proxy wokół domyślnego httpx, mówi, że SDK używa httpx zarówno dla klientów synchronicznych, jak i asynchronicznych. google-genai[aiohttp] to extra na szybszą ścieżkę async, z trust_env=True, żeby zgadzać się z httpx. Tego extra w tym przebiegu nie instalowano. Nie będę udawał, że aiohttp cokolwiek routowało. SOCKS5 jest udokumentowany dopiero po httpx[socks] i HttpOptions.client_args. Też tu nie testowany. HTTP CONNECT to ścieżka, która naprawdę ruszyła.

api_key przekazać do genai.Client albo ustawić GEMINI_API_KEY / GOOGLE_API_KEY przed init. Konfiguracja klucza API to praca na koncie. Laboratorium używało atrapy lab-not-a-google-key wobec origin na loopback. Ten klucz nigdy nie wyszedł z maszyny w stronę Google.

02Ustawić HTTPSPROXY przed konstrukcją Client#

README jest dosłowne. I httpx, i aiohttp czytają urllib.request.getproxies ze środowiska. Proxy ustawić przed konstrukcją klienta:

export HTTPS_PROXY='http://USER:PASS@PROXY_HOST:PROXY_PORT'
export SSL_CERT_FILE='/path/to/extra-ca.pem'

SSL_CERT_FILE jest opcjonalne. Produkcyjne Gemini na publicznych CA nie potrzebuje pliku prywatnego CA. Laboratorium potrzebowało go, bo certyfikat origin był wybity lokalnie. Zainstalowane 2.30.1 robi tu dodatkową pracę. _api_client.py buduje kontekst SSL przez ssl.create_default_context(cafile=os.environ.get('SSL_CERT_FILE', certifi.where())), bo, słowami autorów SDK, httpx samo nie ciągnie SSL_CERT_FILE. Zmienną wyeksportować przed Client(...). Eksport później nie przebuduje żywego klienta.

Userinfo w HTTPS_PROXY to uwierzytelnianie proxy. To nie klucz API Gemini. Klucz API wstawić w Client(api_key=...) albo w GEMINI_API_KEY. Jeśli URL proxy ląduje w logu, hasło zredagować. Listy procesów i tak przez chwilę widzą środowisko.

To samo README pokazuje SOCKS5 przez argumenty httpx, nie przez HTTPS_PROXY:

from google import genai
from google.genai import types

client = genai.Client(
    api_key="YOUR_API_KEY",
    http_options=types.HttpOptions(
        client_args={"proxy": "http://USER:PASS@PROXY_HOST:PROXY_PORT"},
        timeout=60000,
        retry_options=types.HttpRetryOptions(attempts=1),
    ),
)

HttpOptions.timeout jest w milisekundach. 2.30.1 przelicza je przez / 1000.0 przed httpx. retry_options=None na tej kompilacji znaczy, że tenacity zatrzymuje się po jednej próbie. Rozwiązywanie problemów nadal mówi, że Python SDK ponawia przejściowe błędy do czterech razy, z około 1 s, potem maksimum 60 s. Ta strona jest datowana 13 października 2026. Zainstalowany klient tego nie robi, chyba że przekazać HttpRetryOptions. Wolę ustawić attempts=1, gdy diagnozuję przeskok, niż oglądać, jak martwy port dostaje exponential backoff.

1. Eksportować tylko HTTPS_PROXY, jeśli cel jest HTTPS, a Gemini jest. Ten przebieg nie ustawił HTTP_PROXY. urllib.request.getproxies() zwróciło wtedy {'https': 'http://127.0.0.1:62748'}.
2. Zostawić NO_PROXY puste, gdy zamiarem jest, żeby proxy widziało loopback. Pozostałość NO_PROXY=localhost pominie przeskok i będzie wyglądać jak sukces.
3. Skonstruować genai.Client po ustawieniu środowiska. Zamknąć go, gdy skończy się praca.

Jawne client_args={'proxy': ...} to drugie udokumentowane drzwi. W tym przebiegu też wysłało CONNECT. Użyć ich, gdy powłoka już trzyma HTTPS_PROXY i nie chce się z nim kłócić.

03Udowodnić trasę na celu, który się kontroluje#

Status 200 to słaby świadek. Wywołania bezpośrednie i przez proxy mogą oba zwrócić 200. Potrzebny jest log przeskoku albo stempel origin. Laboratorium wskazało HttpOptions.base_url na https://127.0.0.1:PORT/, żeby google-genai nigdy nie otworzyło generativelanguage.googleapis.com. Origin odpowiadał JSON-em oznaczonym SIMULATED. To dowód routingu. To nie odpowiedź modelu, sprawdzenie limitu ani przejście regionu.

Własne sprawdzenie może być mniejsze niż publiczne laboratorium. Potrzebny jest zainstalowany klient, własne proxy i własny cel. Loopback wystarczy. Nie wyłączać verify. Nie kierować tego na Google, dopóki przeskok nie jest nudny.

import os
from google import genai
from google.genai import types

os.environ["HTTPS_PROXY"] = "http://USER:PASS@PROXY_HOST:PROXY_PORT"

client = genai.Client(
    api_key="YOUR_API_KEY",
    http_options=types.HttpOptions(
        timeout=60000,
        retry_options=types.HttpRetryOptions(attempts=1),
    ),
)
try:
    response = client.models.generate_content(
        model="gemini-flash-latest",
        contents="ping",
    )
    print(response.text)
finally:
    client.close()

Ten fragment rozmawia z Google, jeśli zostawić base_url nieustawione. Sprawdzenie na loopback tego nie robiło. Porty w zapisanych wynikach są martwe. Host i port kopiować z proxy, które nadal działa.

1. Wywołać raz bez środowiska proxy i bez proxy w client_args. Bezpośrednie zwróciło zasymulowany tekst. Atrapa proxy CONNECT pozostała bezczynna. proxy_events=0.
2. Wyeksportować HTTPS_PROXY na http://127.0.0.1:PROXY_PORT i wywołać ponownie. Proxy zapisało CONNECT 127.0.0.1:ORIGIN_PORT. Origin zwrócił ten sam tekst SIMULATED. getproxies pokazało tylko klucz https.
3. Powtórzyć z client_args={'proxy': 'http://127.0.0.1:PROXY_PORT'} i bez HTTPS_PROXY. CONNECT wydarzył się znowu. Dwoje drzwi, jeden typ tunelu.

Strona Jaki jest mój adres IP w przeglądarce pokazuje wyjście przeglądarki. Nie pokazuje tego procesu Pythona. Sprawdzanie proxy mówi, czy host odpowiada HTTP albo SOCKS5. Przydatne, zanim wklei się punkt końcowy. Nadal nie google-genai.

04Zostawić TLS włączone i dane logowania poza logami#

HTTPS przez proxy HTTP to CONNECT, potem TLS do origin przez ten tunel. URL proxy zostaje http://.... URL proxy https:// znaczyłby TLS do samego proxy. Ten przebieg tego nie mierzył.

Laboratoryjne CA to jednodniowy certyfikat z subject alternative name dla 127.0.0.1. SSL_CERT_FILE wskazywało na to CA. Weryfikacja została włączona. Gdy ten sam klient przez proxy poszedł bez SSL_CERT_FILE, CONNECT nadal się udał, a httpx rzuciło ConnectError owijające CERTIFICATE_VERIFY_FAILED: unable to get local issuer certificate. Przeskok był w porządku. Magazyn zaufania nie. To przypadek, który ludzie pomijają, a potem dodają verify=False i uważają sprawę za zamkniętą.

1. Zostawić domyślną ścieżkę weryfikacji. Plik CA przekazać tylko wtedy, gdy origin jest prywatny.
2. Potwierdzić CONNECT w logu proxy, zanim świętuje się traceback TLS. Traceback nie jest dowodem, że proxy zostało pominięte.
3. Zredagować Proxy-Authorization, x-goog-api-key i userinfo proxy. Laboratoryjne proxy zapisało has_proxy_authorization: false, bo atrapa nie miała Basic auth. Wasz przeskok sprzedawcy prawdopodobnie ma.

Nie kopiować laboratoryjnego CA do systemowego magazynu zaufania. Ten przebieg nigdy nie ruszał zaufania macOS. SSL_CERT_FILE w procesie dziecka wystarczyło.

05Odróżnić martwy przeskok od błędu wyglądającego na Google#

Rozwiązywanie problemów rozdziela problemy klienta SDK od problemów backendu. Ponawiać 429 i 503. Nie ponawiać 400, 402 ani 403. To niepoprawne klucze, puste środki przedpłacone albo zła składnia, nie kapryśne gniazdo. Nic z tego nie odpala, jeśli TCP nigdy się nie kończy.

Ten przebieg wymusił trzy porażki na tym samym zainstalowanym kliencie.

Zamknięty port loopback jako proxy w client_args rzucił ConnectError: [Errno 61] Connection refused w 0,001 s. Brak logu CONNECT. Origin nigdy nie zobaczył żądania. To martwy przeskok.

Zasymulowane origin 403 przez żywy przeskok CONNECT rzuciło ClientError: 403 PERMISSION_DENIED z ciałem, które mówiło SIMULATED. CONNECT był zalogowany. Origin naliczył trafienie. Transport zadziałał. Aplikacja odmówiła. Na prawdziwym Google ta klasa błędu to konto, rozliczenie albo polityka. To nie „kupcie inne proxy, a model się pojawi”.

Timeout HttpOptions.timeout 200 ms wobec 1,5 s snu origin rzucił ReadTimeout: The read operation timed out przy 0,205 s. CONNECT był zalogowany. Tunel stał. Budżet nie.

Strony katalogu mobilnego i datacenter nie uratują od tej tabeli. Proxy mobilne i proxy datacenter zmieniają IP, który prezentujecie. Nie przepisują klas błędów google-genai. HTTP to protokół, którego to SDK naprawdę użyło. SOCKS5 zostaje extra z README, dopóki nie zainstaluje się httpx[socks] i nie zmierzy.

06Dopasować HTTP CONNECT do punktu katalogu, który da się otworzyć#

Wybrać przeskok, który sprzedawca dokumentuje jako HTTP, z nazwą użytkownika i hasłem, które sprzedawca dokumentuje. Potem udowodnić google-genai wobec własnego stanowiska. Płatnych bram nie wywoływano.

Rezydenckie proxy Oxylabs, odczytane 15 października 2026, dokumentują wejście HTTP. Szybki start rezydencki Decodo, tego samego dnia, dokumentuje gate.decodo.com:7000 jako URL proxy HTTP. Angielski katalog nadal wymienia ten produkt jako smartproxy-com. Te kształty porównać z żywymi kartami Oxylabs i Smartproxy / Decodo. To dopasowanie katalogowe, nie test puli.

1. Dopasować schemat do tego, co 2.30.1 naprawdę wysłało: HTTP CONNECT. URL proxy HTTPS do samego proxy to inny produkt.
2. Prefiksy sprzedawcy kłaść na użytkownika proxy, nie na GEMINI_API_KEY.
3. Osiągalność sprawdzić sprawdzaniem proxy, jeśli potrzeba tylko HTTP kontra SOCKS na hoście. SDK udowodnić na własnym procesie.

Oxylabs — proxy rezydenckie i datacenter4.0771

Oxylabs sprzedaje proxy rezydenckie, mobilne, ISP i datacenter w jednej subskrypcji miesięcznej od $30. Płatności: karty, przelew, AliPay, PayPal.

10 krajów

0,45 USD

za 1 GB

Decodo (Smartproxy) — proxy rezydenckie i datacenter4.22118

Decodo (dawniej Smartproxy) sprzedaje proxy rezydenckie i datacenter. Rezydenckie: $4/GB bez planu miesięcznego albo pakiety miesięczne od $3.75/GB za 3 GB. Płatności: karty, PayPal, Alipay, Google/Apple Pay, krypto (z ograniczeniami).

83 kraje

0,38 USD

za 1 GB

Ten klient ma wychodzić przez przeskok, który da się nazwać, TLS zostawić włączone i przestać traktować tunel jako uprawnienie.