Skip to main content

​
Übersicht

Das Open-Source-GoModel leitet einen Provider mit proxy_url über einen einzelnen Proxy. Das genügt für einen einzelnen geografisch eingeschränkten Provider, aber nicht für eine Flotte, die immer über eine freigegebene (allowlisted) Egress-IP ausgehen muss: Fällt dieser eine Proxy aus, schlägt jeder Request fehl, der über ihn läuft. Egress-Proxy-Pools ergänzen die fehlenden Bausteine:
  • Pools aus HTTP-, HTTPS-, SOCKS5- oder SOCKS5h-Proxys, ausgewählt per failover (der erste gesunde, in Reihenfolge) oder round_robin.
  • Health Checks, die jeden Proxy regelmäßig prüfen, fehlschlagende Mitglieder überspringen und sie wieder aufnehmen, sobald sie die Prüfung erneut bestehen.
  • Regeln, die Provider anhand eines Namensmusters oder des Provider-Typs Pools zuordnen, sodass ein neuer Provider abgedeckt ist, ohne seine eigene Konfiguration anzufassen.
Die eigene proxy_url eines Providers hat weiterhin Vorrang vor jeder Regel. Provider, auf die keine Regel zutrifft, behalten das gatewayweite Verhalten von HTTP_PROXY, HTTPS_PROXY und NO_PROXY.
Wie SSO schlägt auch aktiviertes Egress geschlossen fehl (fail closed): Der Start wird abgebrochen, wenn das egress-Entitlement fehlt oder die Konfiguration ungültig ist. Traffic, der über einen Proxy ausgehen sollte, verlässt das Gateway nie stillschweigend über dessen eigene Adresse.

​
Pools konfigurieren

Konfigurieren Sie die Pools unter extensions.egress in der zentralen YAML-Konfiguration von GoModel:
Regeln werden der Reihe nach ausgewertet, und der erste Treffer gewinnt. Ein Muster trifft auf den Provider-Namen zu (openai-eu, openai*); mit dem Präfix type: trifft es stattdessen auf den Provider-Typ zu (type:gemini). Bei einem einzigen Pool ohne Regeln verwendet jeder Provider diesen Pool. Dieselben Einstellungen sind auch als Umgebungsvariablen verfügbar, die die YAML-Werte überschreiben. Pro PRO_EGRESS_PROXY_<NAME> entsteht ein Pool; der Name wird zum Pool-Namen in Kleinbuchstaben, mit Bindestrichen statt Unterstrichen (aus EU_STATIC wird eu-static):

​
Health Checks und Failover

Jedes Mitglied wird geprüft, bevor das Gateway seinen ersten Request bedient, sodass ein bereits ausgefallener Proxy nie Traffic erhält. Ohne check_url ist eine Prüfung eine TCP-Verbindung zum Proxy-Port. Mit check_url ist sie ein HEAD-Request über den Proxy; jede weitergeleitete Response gilt als gesund, auch 401 oder 404 vom Ziel, während ein 5xx als Fehler zählt, weil Forward-Proxys selbst mit 502, 503 und 504 antworten, wenn sie das Ziel nicht erreichen. Nach der ersten Prüfung muss ein Mitglied failure_threshold aufeinanderfolgende Fehler aufweisen, um übersprungen zu werden, und einen Erfolg, um zurückzukehren. Sind alle Mitglieder eines Pools ungesund, wird der Pool trotzdem verwendet, beginnend mit seinem ersten Mitglied, und pro Ausfall wird einmal eine Warnung geloggt. Ein zugeordneter Pool fällt nie auf eine direkte Verbindung zurück.

​
Überwachen

Zustandswechsel werden mit dem Pool-Namen, der Position des Mitglieds und der Proxy-URL (mit maskiertem Passwort) geloggt. Prometheus stellt bereit:
  • gomodel_pro_egress_proxy_healthy{pool,member,proxy}: 1, solange das Mitglied in der Rotation ist.
  • gomodel_pro_egress_health_checks_total{pool,member,proxy,result}: Prüfungen nach Ergebnis.
  • gomodel_pro_egress_selections_total{pool,member,proxy}: Requests, für die das jeweilige Mitglied ausgewählt wurde.
Richten Sie einen Alert auf gomodel_pro_egress_proxy_healthy == 0 ein, um von einem ausgefallenen Proxy zu erfahren, bevor dem Pool die Mitglieder ausgehen.
Zuletzt geändert am 24. Oktober 2026