reproxy v1.7.1 — Lightweight edge HTTP(S) server and reverse proxy with automatic SSL, Docker/Consul discovery, per-route authentication, rate limiting, and health-check-based failover.

Reproxy ist ein einfacher Edge-HTTP(s)-Server / Reverse-Proxy, der verschiedene Provider unterstützt (docker, static, file, consul catalog). Ein oder mehrere Provider liefern Informationen über den angeforderten Server, die angeforderte URL, die Ziel-URL und die Health-Check-URL. Es wird als einzelne Binärdatei oder als Docker-Container verteilt.

Automatische SSL-Terminierung mit Let's Encrypt
Unterstützung benutzerdefinierter SSL-Zertifikate
Einfache, aber flexible Proxy-Regeln
Statischer Proxy-Regel-Provider über die Kommandozeile
Dynamischer, dateibasierter Proxy-Regel-Provider
Docker-Provider mit automatischer Erkennung
Consul-Catalog-Provider mit Erkennung über Service-Tags
Unterstützung mehrerer (virtueller) Hosts
Optionale Traffic-Komprimierung
Optionale IP-basierte Zugriffskontrolle
Grundlegende Authentifizierung pro Route
Benutzerdefinierte Größenbeschränkungen und Timeouts
Verteilung als einzelne Binärdatei
Verteilung als Docker-Container
Integrierter Server für statische Assets mit optionalem „SPA-freundlichem" Modus
Unterstützung von Weiterleitungsregeln
Optionaler Limiter für die Gesamtaktivität sowie für die Aktivität einzelner Benutzer
Live-Health-Check und Failover/Load-Balancing
Verwaltungsserver mit Routeninformationen und Prometheus-Metriken
Plugin-Unterstützung über RPC zur Implementierung benutzerdefinierter Funktionalität
Optionales Logging sowohl im Apache-Log-Format als auch mit vereinfachten stdout-Berichten.

Der Server (Host) kann als FQDN, z. B. s.example.com, als * (Catch-all) oder als Regex festgelegt werden. Exakte Übereinstimmungen haben Vorrang. Wenn es also zwei Regeln mit den Servern example.com und example\.(com|org) gibt, wird eine Anfrage an example.com/some/url mit der ersteren übereinstimmen. Die angeforderte URL kann ein Regex sein, zum Beispiel ^/api/(.*), und die Ziel-URL kann durch Regex übereinstimmende Gruppen enthalten, z. B. http://d.example.com:8080/$1. Für das obige Beispiel wird http://s.example.com/api/something?foo=bar an http://d.example.com:8080/something?foo=bar weitergeleitet.

Der Einfachheit halber werden Anfragen mit abschließendem / und ohne Regex-Gruppen zu /(.*) erweitert, und Ziele in diesen Fällen zu /$1. D. h. /api/ -> http://127.0.0.1/service wird zu ^/api/(.*) -> http://127.0.0.1/service/$1 übersetzt.

Die Host-Substitution wird in der Ziel-URL unterstützt. Zum Beispiel wird /files/${host} durch den übereinstimmenden Hostnamen ersetzt. $host (ohne geschweifte Klammern) kann ebenfalls verwendet werden.

Sowohl HTTP als auch HTTPS werden unterstützt. Für HTTPS kann sowohl ein statisches Zertifikat als auch automatische ACME-Zertifikate (Let's Encrypt) verwendet werden. Ein optionaler Assets-Server kann zum Ausliefern statischer Dateien verwendet werden. Der Start von reproxy erfordert mindestens einen definierten Provider. Die übrigen Parameter sind streng optional und haben sinnvolle Standardwerte.

Beispiele:

mit einem statischen Provider: reproxy --static.enabled --static.rule="*,example.com/api/(.*),https://api.example.com/$1"
mit automatischer Docker-Erkennung: reproxy --docker.enabled --docker.auto
als Docker-Container: docker up -p 80:8080 umputun/reproxy --docker.enabled --docker.auto
mit automatischem SSL: docker up -p 80:8080 -p 443:8443 umputun/reproxy --docker.enabled --docker.auto --ssl.type=auto --ssl.fqdn=example.com

Installation

Reproxy wird als kleine eigenständige Binärdatei sowie als Docker-Image vertrieben. Sowohl die Binärdatei als auch das Image unterstützen mehrere Architekturen und mehrere Betriebssysteme, darunter linux_x86_64, linux_arm64, linux_arm, macos_x86_64, macos_arm64, windows_x86_64 und windows_arm. Wir stellen außerdem sowohl arm64- als auch x86-deb- und rpm-Pakete bereit.

für eine Binärverteilung laden Sie die passende Datei im Release-Bereich herunter
für Homebrew-Nutzer: brew install umputun/apps/reproxy
Docker-Container verfügbar auf Docker Hub sowie in der Github Container Registry. D. h. docker pull umputun/reproxy oder docker pull ghcr.io/umputun/reproxy.

Die neueste stabile Version hat das Docker-Tag :vX.Y.Z (mit dem Alias :latest) und der aktuelle Master hat das Tag :master.

Provider

Proxy-Regeln werden von verschiedenen Providern bereitgestellt. Derzeit enthalten – file, docker, static und consul-catalog. Jeder Provider kann mehrere Routing-Regeln sowohl für proxied Requests als auch für statische (Assets) definieren. Der Benutzer kann mehrere Provider gleichzeitig festlegen.

Beispiele für verschiedene Provider finden Sie unter examples

Static-Provider

Dies ist der einfachste Provider, der alle Mapping-Regeln direkt in der Befehlszeile (oder Umgebung) definiert. Mehrere Regeln werden unterstützt. Jede Regel besteht aus 3 bis 7 durch Kommas getrennten Elementen server,sourceurl,destination[,ping-url[,forward-health-checks[,timeout[,throttle]]]]. Zum Beispiel:

*,^/api/(.*),https://api.example.com/$1 – leitet alle Anfragen an einen beliebigen Host/Server mit dem Präfix /api an https://api.example.com weiter
example.com,/foo/bar,https://api.example.com/zzz,https://api.example.com/ping – leitet alle Anfragen an example.com und mit der URL /foo/bar an https://api.example.com/zzz weiter und verwendet https://api.example.com/ping für den Health-Check.
example.com,/foo/bar,https://api.example.com/zzz,https://api.example.com/ping,true – wie oben, leitet aber zusätzlich /ping- und /health-Anfragen an das Backend weiter.
example.com,^/upload/(.*),https://api.example.com/$1,,,5m – routenspezifisches Request-Timeout von 5 Minuten (4. und 5. Feld leer gelassen, um ping-url und forward-health-checks zu überspringen).
example.com,^/login,https://api.example.com/login,,,,2 – routenspezifische Drosselung von 2 Anfragen/Sekunde pro Benutzer (die davorliegenden Positionsfelder bleiben leer).

Das 4. Element definiert eine optionale Ping-URL, die für die Health-Berichterstattung verwendet wird. Das 5. Element aktiviert optional die Weiterleitung von Health-Check-Anfragen an das Backend (true, yes, 1). Weitere Details finden Sie im Abschnitt Health check. Das 6. Element ist ein optionales routenspezifisches Request-Timeout (Go-Duration, z. B. 5m, 30s); 0 oder leer erbt die globale Einstellung --timeout.write. Das 7. Element ist ein optionales routenspezifisches Limit von Anfragen/Sekunde pro Benutzer; 0 oder leer erbt --throttle.user. Leere Positionsfelder sind zulässig (z. B. ,, für die ungenutzten mittleren Felder).

File-Provider

Dieser Provider verwendet eine YAML-Datei mit Routing-Regeln.

reproxy --file.enabled --file.name=config.yml

Beispiel für config.yml: