
Leichter HTTP(S)-Edge-Server und Reverse-Proxy mit automatischem SSL, Docker/Consul-Erkennung, routenspezifischer Authentifizierung, Ratenbegrenzung und gesundheitscheckbasiertem Failover.
Reproxy ist ein einfacher Edge-HTTP(s)-Server/Reverse-Proxy, der verschiedene Anbieter unterstützt (Docker, statisch, Datei, Consul-Katalog). Ein oder mehrere Anbieter 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.
Der Server (Host) kann als FQDN, d.h. s.example.com, * (alle) oder ein Regex gesetzt werden. Eine exakte Übereinstimmung hat Priorität, sodass bei zwei Regeln mit Servern example.com und example\.(com|org) die Anfrage an example.com/some/url die erstere trifft. Die angeforderte URL kann ein Regex sein, z.B. ^/api/(.*), und die Ziel-URL kann Regex-Matching-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 nachgestelltem / und ohne Regex-Gruppen zu /(.*) erweitert und Ziele in diesen Fällen zu /$1 erweitert. D.h. /api/ -> http://127.0.0.1/service wird übersetzt zu ^/api/(.*) -> http://127.0.0.1/service/$1.
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.
Es werden sowohl HTTP als auch HTTPS unterstützt. Für HTTPS kann ein statisches Zertifikat sowie automatische ACME (Let's Encrypt) Zertifikate verwendet werden. Ein optionaler Asset-Server kann verwendet werden, um statische Dateien bereitzustellen. Das Starten von reproxy erfordert mindestens einen definierten Provider. Die restlichen Parameter sind streng optional und haben sinnvolle Standardwerte.
Beispiele:
reproxy --static.enabled --static.rule="*,example.com/api/(.*),https://api.example.com/$1"reproxy --docker.enabled --docker.autodocker up -p 80:8080 umputun/reproxy --docker.enabled --docker.autodocker up -p 80:8080 -p 443:8443 umputun/reproxy --docker.enabled --docker.auto --ssl.type=auto --ssl.fqdn=example.comReproxy wird als kleine eigenständige Binärdatei sowie als Docker-Image verteilt. Sowohl die Binärdatei als auch das Image unterstützen mehrere Architekturen und Betriebssysteme, einschließlich linux_x86_64, linux_arm64, linux_arm, macos_x86_64, macos_arm64, windows_x86_64 und windows_arm. Wir bieten auch sowohl arm64- als auch x86-deb- und rpm-Pakete an.
brew install umputun/apps/reproxydocker pull umputun/reproxy oder docker pull ghcr.io/umputun/reproxy.Die aktuelle stabile Version hat den Docker-Tag :vX.Y.Z (mit :latest Alias) und der aktuelle Master hat den Tag :master.
Proxy-Regeln werden von verschiedenen Anbietern bereitgestellt. Derzeit enthalten – datei, docker, statisch und consul-katalog. Jeder Anbieter kann mehrere Routing-Regeln sowohl für Proxy-Anfragen als auch für statische Assets definieren. Der Benutzer kann gleichzeitig mehrere Anbieter festlegen.
Siehe Beispiele für verschiedene Anbieter in examples
Dies ist der einfachste Anbieter, der alle Zuordnungsregeln 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 – proxy alle Anfragen an jeden Host/Server mit /api-Präfix an https://api.example.comexample.com,/foo/bar,https://api.example.com/zzz,https://api.example.com/ping – proxy alle Anfragen an example.com und mit /foo/bar-URL an https://api.example.com/zzz und es 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 auch /ping- und /health-Anfragen an das Backend weiter.example.com,^/upload/(.*),https://api.example.com/$1,,,5m – anfragebezogenes 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 – anfragebezogene Begrenzung von 2 req/s pro Benutzer (positionsabhängige Felder davor sind leer).Das 4. Element definiert eine optionale Ping-URL, die für die Gesundheitsberichterstattung verwendet wird. Das 5. Element aktiviert optional die Weiterleitung von Health-Check-Anfragen an das Backend (true, yes, 1). Siehe Abschnitt Health Check für weitere Details. Das 6. Element ist ein optionales anfragebezogenes Request-Timeout (Go-Dauer, z.B. 5m, 30s); 0 oder leer erbt die globale Einstellung --timeout.write. Das 7. Element ist eine optionale anfragebezogene Begrenzung der Anfragen pro Sekunde pro Benutzer; 0 oder leer erbt --throttle.user. Leere Positionsfelder sind erlaubt (z.B. ,, für die ungenutzten mittleren Felder).
Dieser Anbieter verwendet eine YAML-Datei mit Routing-Regeln.
reproxy --file.enabled --file.name=config.yml