umputun/reproxyLeichter 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).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
Beispiel für config.yml:```yaml
default: # the same as * (catch-all) server
Dies ist ein dynamischer Anbieter und Dateiänderungen werden automatisch übernommen.
**Mehrere statische Websites auf verschiedenen Domains** können bereitgestellt werden, indem Servernamen als Schlüssel mit `assets: true` verwendet werden:```yaml
site-en.example.com:
- { route: "/", dest: "/var/www/en", "assets": true }
site-ru.example.com:
- { route: "/", dest: "/var/www/ru", "assets": true }
Wichtig: das route-Feld für Asset-Regeln muss ein Pfad-Präfix sein (z.B. /, /web/), kein Regex. Regex-Muster wie ^/(.*) funktionieren nicht mit assets: true, da der statische Asset-Abgleich Pfad-Präfix-Vergleich verwendet, nicht Regex.
Der Docker-Provider unterstützt eine vollautomatische Erkennung (mit --docker.auto) ohne zusätzliche Konfiguration. Standardmäßig leitet er alle Anfragen wie http://<url>/<container name>/(.*) an die interne IP des angegebenen Containers und den freigegebenen Port weiter. Es werden nur aktive (laufende) Container erkannt.
Diese Standardeinstellung kann mit Labels geändert werden:
reproxy.server - Server (Hostname) zum Abgleichen. Kann auch eine Liste von kommagetrennten Servern sein.reproxy.route - Quell-Route (Ort)reproxy.dest - Zielpfad. Hinweis: Dies ist keine vollständige URL, sondern nur der Pfad, der an die IP:Port des Containers angehängt wird.reproxy.port - Zielport für den erkannten Containerreproxy.ping - Ping-Pfad für den Zielcontainer.reproxy.remote - Zugriff auf die Route auf eine Liste von kommagetrennten Subnetzen oder IPs beschränkenreproxy.auth - Basisauthentifizierung für die Route mit kommagetrennten user:bcrypt_hash-Paaren erfordern (generiert mit htpasswd -nbB)reproxy.assets - Asset-Zuordnung als web-root:location festlegen, z.B. reproxy.assets=/web:/var/wwwBitte beachten: Ohne --docker.auto muss der Zielcontainer mindestens eines der reproxy.*-Labels haben, um als potenzielles Ziel zu gelten.
Mit --docker.auto werden alle Container mit freigegebenem Port als Routing-Ziele betrachtet. Es gibt 3 Möglichkeiten, dies einzuschränken:
--docker.exclude ausschließen, z.B. --docker.exclude=c1 --docker.exclude=c2 ...--docker.network zulassenreproxy.enabled=false oder reproxy.enabled=no oder reproxy.enabled=0 setzenWenn kein reproxy.route definiert ist, lautet die Standardroute ^/<container_name>/(.*). Falls alle proxied Quellen das gleiche Präfix-Muster haben sollen, z.B. /api/(.*), kann der Benutzer das gemeinsame Präfix (in diesem Fall /api) für alle containerbasierten Routen definieren. Dies kann mit dem Parameter --docker.prefix erfolgen.
Der Docker-Provider erlaubt auch die Definition mehrerer Sätze von reproxy.N.something-Labels, um mehrere verschiedene Routen auf demselben Container abzugleichen. Dies ist nützlich, da ein einzelner Container in manchen Fällen mehrere Endpunkte bereitstellen kann, z.B. eine öffentliche API und eine Admin-API. Alle oben genannten Labels können mit "N-Index" verwendet werden, d.h. reproxy.1.server, reproxy.1.port usw. N sollte im Bereich 0 bis 9 liegen.
Dies ist ein dynamischer Provider, und jede Änderung des Container-Status wird automatisch übernommen.
Verwendung: reproxy --consul-catalog.enabled
Der Consul Catalog-Provider ruft periodisch (standardmäßig jede Sekunde) die Consul-API auf, um Dienste zu erhalten, die ein Tag mit dem Präfix reproxy. haben. Der Benutzer kann das Prüfintervall mit dem Befehlszeilenflag --consul-catalog.interval sowie die Consul-Adresse mit der Befehlszeilenoption --consul-catalog.address neu definieren. Die Standardadresse ist http://127.0.0.1:8500.
Zum Beispiel:``` reproxy --consul-catalog.enabled --consul-catalog.address=http://192.168.1.100:8500 --consul-catalog.interval=10s
Standardmäßig setzt der Provider Werte für jeden Dienst:
- enabled `false`
- server `*`
- route `^/(.*)`
- dest `http://<SERVICE_ADDRESS_FROM_CONSUL>/$1`
- ping `http://<SERVICE_ADDRESS_FROM_CONSUL>/ping`
Dieser Standard kann mit Tags geändert werden:
- `reproxy.server` - Server (Hostname) zum Abgleichen. Kann auch eine kommagetrennte Liste von Servern sein.
- `reproxy.route` - Quellroute (Ort)
- `reproxy.dest` - Zielpfad. Hinweis: Dies ist keine vollständige URL, sondern nur der Pfad, der an die IP:Port des Dienstes angehängt wird.
- `reproxy.port` - Zielport für den entdeckten Dienst
- `reproxy.remote` - Zugriff auf die Route mit einer kommagetrennten Liste von Subnetzen oder IPs einschränken
- `reproxy.auth` - Basic-Authentifizierung für die Route mit kommagetrennten `user:bcrypt_hash`-Paaren (generiert durch `htpasswd -nbB`) verlangen
- `reproxy.ping` - Ping-Pfad für den Zieldienst.
- `reproxy.forward-health-checks` - `/ping`- und `/health`-Anfragen an das Backend weiterleiten (`true`, `yes`, `1`).
- `reproxy.timeout` - Zeitüberschreitung pro Route als Go-Dauer (z.B. `5m`, `30s`). `0` oder nicht gesetzt erbt das globale `--timeout.write`. Ungültige Werte werden mit einer Warnung ignoriert.
- `reproxy.throttle` - Anfragen/Sekunde-Limit pro Route und Benutzer. `0` oder nicht gesetzt erbt `--throttle.user`. Ungültige oder negative Werte werden mit einer Warnung ignoriert.
- `reproxy.enabled` - Dienst für reproxy-Ziele aktivieren (`yes`, `true`, `1`) oder deaktivieren (`jeder andere Wert`).
### Compose-spezifische Details
Falls Regeln als Teil einer Docker-Compose-Umgebung gesetzt werden, gerät das Ziel mit der Regex-Gruppe mit der Compose-Syntax in Konflikt. D.h. der Versuch, `https://api.example.com/$1` in einer Compose-Umgebung zu verwenden, schlägt aufgrund eines Syntaxfehlers fehl. Die Standardlösung besteht darin, das `$`-Zeichen durch `$$` zu "escapen", also `https://api.example.com/$$1`. Diese Ersetzung wird von Docker Compose unterstützt und hat nichts mit reproxy selbst zu tun. Eine andere Möglichkeit ist die Verwendung von `@` anstelle von `$`, was auf reproxy-Ebene unterstützt wird, also `https://api.example.com/@1`_
## SSL-Unterstützung
Der SSL-Modus (standardmäßig none) kann auf `auto` (ACME/LE-Zertifikate), `static` (vorhandenes Zertifikat) oder `none` gesetzt werden. Wenn `auto` aktiviert ist, wird das SSL-Zertifikat automatisch für alle entdeckten Servernamen ausgestellt. Der Benutzer kann dies über die Einstellung von `--ssl.fqdn`-Wert(en) überschreiben. Im SSL-Modus `auto` und `static` fügt Reproxy automatisch die Header `X-Forwarded-Proto` und `X-Forwarded-Port` hinzu. Diese Header sind nützlich für Dienste hinter dem Proxy, um das ursprüngliche Protokoll (http oder https) und die vom Client verwendete Portnummer zu kennen.
Bei Verwendung von ACME mit Discovery-Providern (docker, file, consul) werden SSL-Zertifikate automatisch für neu entdeckte Server erworben, ohne dass ein Neustart von reproxy erforderlich ist.
### ACME-Challenges
Reproxy unterstützt zwei Arten von ACME-Challenges zur SSL-Zertifikatsvalidierung:
1. **HTTP-01-Challenge** (Standard): Validiert die Domaininhaberschaft durch Bereitstellung eines Tokens unter einer bestimmten HTTP-URL. Erfordert, dass Port 80 öffentlich erreichbar ist.
2. **DNS-01-Challenge**: Validiert die Domaininhaberschaft durch Erstellung von DNS-TXT-Einträgen. Diese Methode:
- Erfordert nicht, dass Port 80 erreichbar ist
- Funktioniert mit Wildcard-Zertifikaten
- Erfordert eine Konfiguration des unterstützten DNS-Anbieters
#### Auswahl der Challenge
Reproxy bestimmt automatisch, welche Challenge-Methode basierend auf Ihrer Konfiguration verwendet wird:
- **HTTP-01** (Standard): Wird verwendet, wenn kein DNS-Anbieter konfiguriert ist
- **DNS-01**: Wird verwendet, wenn ein DNS-Anbieter konfiguriert ist
Sie müssen den Challenge-Typ nicht explizit auswählen – konfigurieren Sie einfach einen DNS-Anbieter, wenn Sie DNS-01-Challenges verwenden möchten.
#### Derzeit unterstützte DNS-Anbieter
Reproxy bietet derzeit Unterstützung für die folgenden DNS-Anbieter:
- **Cloudflare**: `--ssl.dns.type=cloudflare --ssl.dns.cloudflare.api-token=TOKEN`
- **Route53 (AWS)**: `--ssl.dns.type=route53 --ssl.dns.route53.region=REGION --ssl.dns.route53.hosted-zone-id=ID`
- **Gandi**: `--ssl.dns.type=gandi --ssl.dns.gandi.bearer-token=TOKEN`
- **DigitalOcean**: `--ssl.dns.type=digitalocean --ssl.dns.digitalocean.api-token=TOKEN`
- **Hetzner**: `--ssl.dns.type=hetzner --ssl.dns.hetzner.api-token=TOKEN`
- **Linode**: `--ssl.dns.type=linode --ssl.dns.linode.api-token=TOKEN`
- **GoDaddy**: `--ssl.dns.type=godaddy --ssl.dns.godaddy.api-token=TOKEN`
- **Namecheap**: `--ssl.dns.type=namecheap --ssl.dns.namecheap.api-key=KEY --ssl.dns.namecheap.user=USER`
- **Scaleway**: `--ssl.dns.type=scaleway --ssl.dns.scaleway.secret-key=KEY --ssl.dns.scaleway.organization-id=ID`
- **Porkbun**: `--ssl.dns.type=porkbun --ssl.dns.porkbun.api-key=KEY --ssl.dns.porkbun.api-secret-key=SECRET`
- **DNSimple**: `--ssl.dns.type=dnsimple --ssl.dns.dnsimple.api-access-token=TOKEN --ssl.dns.dnsimple.account-id=ID`
- **DuckDNS**: `--ssl.dns.type=duckdns --ssl.dns.duckdns.api-token=TOKEN`
Beispiel mit Cloudflare als DNS-Anbieter:```
export CLOUDFLARE_API_TOKEN=your_api_token
reproxy --ssl.type=auto [email protected] --ssl.fqdn=example.com
Die DNS-01 Challenge ist besonders nützlich, wenn:
Reproxy ermöglicht es, eingehende Header zu bereinigen (entfernen), indem der Parameter --drop-header übergeben wird (kann wiederholt werden). Dieser Parameter kann nützlich sein, um sicherzustellen, dass einige der Header, die intern von den Diensten gesetzt werden, nicht vom Endbenutzer gesetzt/gefälscht werden können. Wenn beispielsweise einer der Dienste, die für die Authentifizierung zuständig sind, X-Auth-User und X-Auth-Token setzt, ist es wahrscheinlich sinnvoll, diese Header aus den eingehenden Anfragen zu entfernen, indem der Parameter --drop-header=X-Auth-User --drop-header=X-Auth-Token oder über die Umgebungsvariable DROP_HEADERS=X-Auth-User,X-Auth-Token übergeben wird.
Die umgekehrte Funktion, das Setzen von ausgehenden Headern, wird ebenfalls unterstützt. Dies kann in vielen Fällen nützlich sein, z. B. zur Durchsetzung benutzerdefinierter CORS-Regeln, sicherheitsrelevanter Header usw. Dies kann mit dem Parameter --header (kann wiederholt werden) oder der Umgebungsvariable HEADER erfolgen. So kann es beispielsweise mit Docker Compose gemacht werden:```yaml
environment:
- HEADER=
X-Frame-Options:SAMEORIGIN,
X-XSS-Protection:1; mode=block;,
Content-Security-Policy:default-src 'self'; style-src 'self' 'unsafe-inline';
## Logging
Standardmäßig wird kein Anfragenlog generiert. Dies kann durch Setzen von `--logger.enabled` aktiviert werden. Das Log (automatisch rotiert) hat das [Apache Combined Log Format](http://httpd.apache.org/docs/2.2/logs.html#combined)
Der Benutzer kann das stdout-Log auch mit `--logger.stdout` einschalten. Es beeinträchtigt nicht die Dateiprotokollierung oben, gibt aber einige minimale Informationen über verarbeitete Anfragen aus, etwa so:```
2021/04/16 01:17:25.601 [INFO] GET - /echo/image.png - xxx.xxx.xxx.xxx - 200 (155400) - 371.661251ms
2021/04/16 01:18:18.959 [INFO] GET - /api/v1/params - xxx.xxx.xxx.xxx - 200 (74) - 1.217669m
Benutzer können den Assets-Server aktivieren (standardmäßig deaktiviert), um statische Dateien bereitzustellen. Solange --assets.location gesetzt ist, behandelt er jede nicht-proxierte Anfrage unter assets.root als Anfrage nach statischen Dateien. Der Assets-Server kann ohne jegliche Proxy-Anbieter verwendet werden; in diesem Modus fungiert reproxy als einfacher Webserver für statische Inhalte. Der Assets-Server unterstützt auch den "SPA-Modus" mit --assets.spa, bei dem alle nicht gefundenen Anfragen an index.html weitergeleitet werden.
Zusätzlich zum allgemeinen Assets-Server werden mehrere benutzerdefinierte Assets-Server unterstützt. Jeder Anbieter hat eine andere Möglichkeit, eine solche statische Regel zu definieren, und einige Anbieter unterstützen dies möglicherweise gar nicht. Beispielsweise sind mehrere Assets-Server beim statischen (Befehlszeilenanbieter), Dateianbieter und sogar bei Docker-Anbietern sinnvoll, jedoch beim Consul-Katalog-Anbieter wenig sinnvoll.
assets: oder spa: beginnt, wird es als Dateiserver behandelt. Zum Beispiel wird *,assets:/web,/var/www, alle /web/*-Anfragen mit einem Dateiserver basierend auf dem Verzeichnis /var/www bedienen.assets: true oder spa: true. Hinweis: Das Feld route muss ein Pfad-Präfix sein (z.B. /, /web/), kein Regex-Muster.reproxy.assets=web-root:location, d.h. reproxy.assets=/web:/var/www. Das Umschalten in den SPA-Modus erfolgt durch Setzen von reproxy.spa auf oder Der Assets-Server unterstützt die Cache-Steuerung mit dem Parameter --assets.cache=<duration>. Eine Dauer von 0s (Standard) schaltet die Cache-Steuerung aus. Eine Dauer ist eine Folge von Dezimalzahlen, jeweils mit optionalem Bruchteil und einer Einheitssuffix, wie "300ms", "1.5h" oder "2h45m". Gültige Zeiteinheiten sind "ns", "us" (oder "µs"), "ms", "s", "m", "h" und "d".
Es gibt zwei Möglichkeiten, die Cache-Dauer festzulegen:
--assets.cache=48h.--assets.cache-Optionen aus, z.B. --assets.cache=48h --assets.cache=text/html:24h --assets.cache=image/png:2h. Umgebungsvariablen sollten durch Kommas getrennt sein, z.B. ASSETS_CACHE=48h,text/html:24h,image/png:2hEine benutzerdefinierte 404-Seite (nicht gefunden) kann mit dem Parameter --assets.not-found=<path> festgelegt werden. Der Pfad sollte relativ zum Assets-Root sein.
Das Bereitstellen rein statischer Inhalte ist einer der beliebtesten Anwendungsfälle. Normalerweise wird dies für einen separaten Frontend-Container verwendet, der nur die Benutzeroberfläche bereitstellt. Mit dem Assets-Server ist ein solcher Container nahezu trivial zu erstellen. Dies ist ein Beispiel aus dem Container, der reproxy.io bereitstellt.```docker FROM node:22-alpine as build
WORKDIR /build COPY site/ /build COPY README.md /build/src/index.md
RUN yarn --frozen-lockfile RUN yarn build RUN ls -la /build/public
FROM ghcr.io/umputun/reproxy COPY --from=build /build/public /srv/site EXPOSE 8080 USER app ENTRYPOINT ["/srv/reproxy", "--assets.location=/srv/site"]
Alles, was benötigt wird, ist, statische Assets an einen Speicherort zu kopieren und diesen Speicherort als `"--assets.location` an den reproxy-Einstiegspunkt zu übergeben.
## SPA-freundlicher Modus
Manche SPA-Anwendungen verlassen sich darauf, dass der Proxy 404-Fehler bei statischen Assets auf eine spezielle Weise behandelt, indem er auf "/index.html" umleitet. Dies ähnelt der nginx-Direktive `try_files $uri $uri/ …` und diese Funktionalität ist offenbar für moderne Web-Apps wichtig.
Dieser Modus ist standardmäßig deaktiviert und kann durch Setzen von `--assets.spa` oder der Umgebungsvariable `ASSETS_SPA=true` aktiviert werden.
## Weiterleitungen
Standardmäßig behandelt reproxy das Ziel als einen Proxy-Standort, d.h. es führt intern einen HTTP-Aufruf aus und gibt die Antwort an den Client zurück. Wenn der Ziel-URL jedoch `@code` vorangestellt wird, kann dieses Verhalten in eine permanente (Statuscode 301) oder temporäre (Statuscode 302) Weiterleitung geändert werden. D.h. ein Ziel, das auf `@301 https://example.com/something` gesetzt ist, verursacht eine permanente HTTP-Weiterleitung zu `Location: https://example.com/something`.
Unterstützte Codes:
- `@301`, `@perm` - permanente Weiterleitung
- `@302`, `@temp`, `@tmp` - temporäre Weiterleitung
## Weitere Optionen
- `--gzip` aktiviert die gzip-Komprimierung für Antworten.
- `--max=N` ermöglicht das Festlegen der maximalen Größe einer Anfrage (Standard 64k). Wenn es auf `0` gesetzt wird, wird die Größenprüfung deaktiviert.
- `--timeout.*` verschiedene Timeouts für den Server- und Proxy-Transport. Siehe Abschnitt `timeout` unter [Alle Anwendungsoptionen](#all-application-options). Ein Wert von Null oder negativ bedeutet, dass es kein Timeout gibt.
- `--insecure` deaktiviert die SSL-Überprüfung auf dem Zielhost. Dies ist nützlich für selbstsignierte Zertifikate.
## Standard-Ports
Um die Notwendigkeit zu vermeiden, benutzerdefinierte Parameter/Umgebungen zu übergeben, ist der Standard-`--listen` dynamisch und versucht, für die typischen Fälle sinnvoll und hilfreich zu sein:
- Wenn der Benutzer etwas für `--listen` gesetzt hat, wird die gesamte nachfolgende Logik ignoriert und der übergebene Host:Port direkt verwendet.
- Wenn der Benutzer nichts für `--listen` gesetzt hat und reproxy außerhalb des Docker-Containers läuft, ist der Standard `127.0.0.1:80` für den HTTP-Modus (`ssl.type=none`) und `127.0.0.1:443` für den SSL-Modus (`ssl.type=auto` oder `ssl.type=static`).
- Wenn der Benutzer nichts für `--listen` gesetzt hat und reproxy innerhalb des Docker-Containers läuft, ist der Standard `0.0.0.0:8080` für den HTTP-Modus und `0.0.0.0:8443` für den SSL-Modus.
Ein weiterer Standard, der auf ähnlich dynamische Weise gesetzt wird, ist `--ssl.http-port`. Für den Lauf innerhalb des Docker-Containers ist er auf `8080` gesetzt, ohne Container auf `80`.
## Ping, Gesundheitschecks und Fail-Over
reproxy bietet zwei Endpunkte für diesen Zweck:
- `/ping` antwortet mit `pong` und zeigt an, dass reproxy läuft und betriebsbereit ist.
- `/health` gibt den Status `200 OK` zurück, wenn alle Zielserver mit `200` auf ihre Ping-Anfrage geantwortet haben, oder `417 Expectation Failed`, wenn einer der Server mit einem Nicht-200-Code geantwortet hat. Es gibt auch einen JSON-Body mit Details zu bestandenen/fehlgeschlagenen Diensten zurück.
Zusätzlich zu den obigen Endpunkten unterstützt reproxy optionale Live-Gesundheitschecks. In diesem Fall (wenn aktiviert) wird jedes Ziel periodisch auf eine Ping-Antwort überprüft und fehlgeschlagene Zielrouten werden ausgeschlossen. Es ist möglich, mehrere identische Ziele von demselben oder verschiedenen Anbietern zurückzugeben, und nur das bestandene wird ausgewählt. Wenn mehrere Übereinstimmungen gefunden wurden und bestanden haben, wird die endgültige gemäß der `lb-type`-Strategie ausgewählt (standardmäßig zufällige Auswahl).
Um den Live-Gesundheitscheck zu aktivieren, sollte der Benutzer `--health-check.enabled` (oder die Umgebungsvariable `HEALTH_CHECK_ENABLED=true`) setzen. Zum Anpassen des Prüfintervalls kann `--health-check.interval=` verwendet werden.
## Management-API
Optional, kann mit `--mgmt.enabled` aktiviert werden. Stellt 2 Endpunkte auf `mgmt.listen` (Adresse:Port) bereit:
- `GET /routes` - Liste aller gefundenen Routen
- `GET /metrics` - Gibt Prometheus-Metriken zurück (`http_requests_total`, `response_status` und `http_response_time_seconds`)
Standardmäßig verwendet `http_response_time_seconds` rohe Anforderungspfade als Labels, was bei dynamischen URLs (z.B. `/api/users/123`, `/api/users/456`) zu einer hohen Kardinalität führen kann. Verwenden Sie `--mgmt.low-cardinality`, um stattdessen auf Routenmuster (z.B. `^/api/users/(.*)`) umzuschalten, was die Metrik-Kardinalität erheblich reduziert.
_siehe auch [examples/metrics](https://github.com/umputun/reproxy/tree/master/examples/metrics)_
## Fehlerberichterstattung
Reproxy gibt einen 502-Fehler (Bad Gateway) zurück, wenn eine Anfrage mit keiner der bereitgestellten Routen und Assets übereinstimmt. Falls ein unerwarteter, interner Fehler auftritt, wird 500 zurückgegeben. Standardmäßig rendert reproxy die einfachste Textversion des Fehlers - "Server error". Das Setzen von `--error.enabled` aktiviert die standardmäßige HTML-Fehlermeldung und mit `--error.template` kann der Benutzer eine beliebige benutzerdefinierte HTML-Vorlagendatei für die Fehlerdarstellung festlegen. Die Vorlage hat zwei Variablen: `{{.ErrCode}}` und `{{.ErrMessage}}`. Zum Beispiel wird diese Vorlage `oh my! {{.ErrCode}} - {{.ErrMessage}}` zu `oh my! 502 - Bad Gateway` gerendert.
## Drosselung
Reproxy ermöglicht es, einen systemweiten maximalen req/sec-Wert für die gesamte Systemaktivität sowie pro Benutzer zu definieren. Werte von 0 (Standard) werden als unbegrenzt behandelt.
Die Benutzeraktivität wird sowohl für passende als auch für nicht passende Routen begrenzt. Alle nicht passenden Routen werden als "eine einzelne Zielgruppe" betrachtet und erhalten einen gemeinsamen Begrenzer, der `rate*3` beträgt. Das bedeutet, wenn 10 (req/sec) mit `--throttle.user=10` definiert sind, kann der Endbenutzer bis zu 30 Anfragen pro Sekunde für statische Assets oder nicht passende Routen durchführen. Für passende Routen wird dieser Begrenzer pro Ziel (Route) verwaltet, d.h. Anfragen, die an s1.example.com/api weitergeleitet werden, erlauben 10 r/s, und Anfragen an s2.example.com erlauben weitere 10 r/s.
### Routenspezifisches Timeout und Drosselung
Einzelne Routen können die globalen Einstellungen `--timeout.write` und `--throttle.user` über anbieterspezifische `timeout`- und `throttle`-Felder überschreiben. Dies ist nützlich für langlebige Endpunkte (z.B. Uploads, Berichtsgenerierung), die eine höhere Frist als das globale Schreib-Timeout benötigen, und für die Verschärfung von Ratenbegrenzungen auf sensiblen Routen (z.B. Login), ohne die globale Obergrenze für alles andere anzuheben.
Die Priorität ist "Null erbt global, positiv überschreibt": Eine Route mit `timeout: 0` (oder ohne `timeout`-Feld) behält das globale `--timeout.write`; eine Route mit `timeout: 5m` überschreibt es nur für passende Anfragen. Die gleiche Regel gilt für `throttle`.
Das routenspezifische Timeout überschreibt die Lese- und Schreibfristen der Verbindung für passende Anfragen, sodass es das globale `--timeout.write` (Standard 30s) überschreiten kann. Routen ohne routenspezifisches Timeout respektieren weiterhin die globale Einstellung.
**Einschränkung — Transportebenen-Response-Header-Timeout:** Das routenspezifische `timeout` überschreibt NICHT `--timeout.resp-header` (Standard 5s). Dieses Timeout wird auf dem gemeinsam genutzten `http.Transport` gesetzt und gilt, bevor der Upstream beginnt, Antwort-Header zu senden. Wenn ein Upstream länger als `--timeout.resp-header` braucht, um seine Antwort zu starten (z.B. ein langsamer Berichts-Endpunkt), schlägt die Anfrage an dieser Grenze fehl, unabhängig vom routenspezifischen `timeout`. Um solche Routen zu unterstützen, erhöhen Sie `--timeout.resp-header` global auf das Maximum, das von einer langsamen Antwortroute benötigt wird. Die routenspezifische Überschreibung von Timeouts auf Transportebene ist bewusst nicht im Rahmen enthalten.
Anbietersyntax:
- **Datei-Anbieter** (YAML): `timeout: 5m`, `throttle: 2`
- **Statischer Anbieter** (CSV): 6. und 7. Positionsfeld, z.B. `*,^/upload/(.*),http://up:8080/$1,,,5m,2`
- **Docker-Anbieter**: `reproxy.timeout=5m`, `reproxy.throttle=2` (oder `reproxy.<n>.timeout` / `reproxy.<n>.throttle` für Multi-Routen-Container)
- **Consul Catalog-Anbieter**: `reproxy.timeout=5m`, `reproxy.throttle=2`
## Upstream-Verbindungsbegrenzungen
Reproxy ermöglicht die Konfiguration der Verbindungspool-Einstellungen für Upstreams, um zu steuern, wie viele Verbindungen zu Backend-Servern aufrechterhalten werden:
- `--upstream.max-idle-conns` - Maximale Anzahl von Leerlaufverbindungen über alle Upstream-Hosts hinweg. Standard: 100.
- `--upstream.max-conns` - Maximale Anzahl von Verbindungen pro Upstream-Host (0 = unbegrenzt). Standard: 0.
Das Setzen von `--upstream.max-conns` begrenzt gleichzeitige Verbindungen zu jedem Backend, was nützlich ist, wenn Upstream-Server eine begrenzte Kapazität haben oder um Verbindungserschöpfung zu verhindern.
## Basisauthentifizierung
Reproxy unterstützt die Basisauthentifizierung in zwei Modi: global (alle Routen) und routenspezifisch.
### Globale Basisauthentifizierung
Die globale Basisauthentifizierung schützt alle Routen. Dies ist nützlich, um Endpunkte während der Entwicklung und des Testens zu schützen. Zur Aktivierung setzen Sie die htpasswd-Datei mit `--basic-htpasswd=<Dateipfad>` oder der Umgebungsvariable `BASIC_HTPASSWD=<Dateipfad>`.
Reproxy erwartet die htpasswd-Datei im folgenden Format:```
username1:bcrypt(password1)
username2:bcrypt(password2)
...
Dies kann mit dem Befehl htpasswd -nbB generiert werden, z.B. htpasswd -nbB test passwd
Die Per-Route-Authentifizierung erlaubt unterschiedliche Anmeldeinformationen für verschiedene Routen. Wenn für eine Route eine Per-Route-Authentifizierung konfiguriert ist, wird die globale Authentifizierung für diese Route umgangen. Die Per-Route-Authentifizierung wird über anbieterspezifische Einstellungen konfiguriert:
auth-Feld in YAML, z.B. auth: "user1:$2y$..., user2:$2y$..."reproxy.authreproxy.authDas Format ist eine durch Kommas getrennte Liste von user:bcrypt_hash-Paaren (gleiches htpasswd-Format). Für dieselbe Route können mehrere Benutzer angegeben werden.
Beispiel mit Docker-Compose:```yaml services: admin-api: labels: - "reproxy.route=^/admin/(.*)" - "reproxy.dest=/$1" - "reproxy.auth=admin:$$2y$$05$$hashedpassword"
Hinweis: In docker-compose muss `$` als `$$` maskiert werden.
## IP-basierte Zugriffskontrolle
Reproxy erlaubt es, den Zugriff auf die Routen mit einer Liste von durch Komma getrennten Subnetzen oder IPs einzuschränken. Dies ist nützlich für die Entwicklung und das Testen, bevor der uneingeschränkte Zugriff ermöglicht wird. Es kann auch verwendet werden, um den Zugriff auf interne Dienste zu beschränken. Standardmäßig sind alle Routen für alle Clients offen.
Um den Zugriff auf die Routen einzuschränken, sollte der Benutzer die entsprechenden Schlüssel für die Routen setzen, d.h. `reproxy.remote` für Docker und Consul und `remote` für den Dateianbieter. Der Wert sollte eine Liste von durch Komma getrennten Subnetzen, IPs oder Subnetzen sein. Zum Beispiel `127.0.0.1, 192.168.1.0/24`. Weitere Einzelheiten finden Sie in den Abschnitten [Docker-Anbieter](#docker-provider) und [Consul-Katalog-Anbieter](#consul-catalog-provider).
Standardmäßig prüft Reprox die Remote-Adresse aus der Client-Anfrage. In einigen Fällen funktioniert dies jedoch nicht wie erwartet, z.B. hinter einem anderen Proxy oder mit einem Docker-Bridge-Netzwerk. Dies kann mit dem Parameter `--remote-lookup-headers` geändert werden, der es erlaubt, den Wert des Headers `X-Real-IP` oder `X-Forwarded-For` (in dieser Reihenfolge) zu prüfen und für die Überprüfung zu verwenden. Wenn der Header nicht gesetzt ist, wird die Prüfung gegen die Remote-Adresse des Clients durchgeführt. Diese Header werden vom Client bereitgestellt und können leicht gefälscht werden. Daher darf dieser Parameter nur aktiviert werden, wenn Reprox hinter einem vertrauenswürdigen Fronting-Proxy läuft, der diese Header immer setzt und überschreibt.
Die Überprüfung von Headern sollte mit Vorsicht verwendet werden, da sie gefälscht werden können. Wenn `--remote-lookup-headers` aktiviert ist, verlässt sich die IP-Zulassungsliste vollständig auf diese Vertrauensannahme: Ein Client, der `X-Real-IP` oder `X-Forwarded-For` mit einer erlaubten Adresse sendet, kann ansonsten die Einschränkung umgehen. Aktivieren Sie diese Option nur, wenn Reprox hinter einem vertrauenswürdigen Proxy läuft, der diese Header kontrolliert, und Sie garantieren können, dass sie nicht gefälscht sind.
## Plugin-Unterstützung
Die Kernfunktionalität von Reprox kann durch externe Plugins erweitert werden. Jedes Plugin ist ein unabhängiger Prozess/Container, der einen [RPC-Server](https://golang.org/pkg/net/rpc/) implementiert. Plugins werden beim Reprox-Conductor registriert und der Middleware-Kette hinzugefügt. Jedes Plugin erhält eine Anfrage mit der ursprünglichen URL, den Headern und allen passenden Routeninformationen und antwortet mit den Headern und dem Statuscode. Jeder Statuscode >= 400 wird als Fehlerantwort behandelt und beendet den Ablauf sofort mit dem Proxy-Fehler. Es gibt zwei Arten von Headern, die Plugins setzen können:
- `HeadersIn` - eingehende Header. Diese werden an die Proxy-URL gesendet
- `HeadersOut` - ausgehende Header. Werden zurück an den Client gesendet
Standardmäßig werden die von einem Plugin gesetzten Header mit den ursprünglichen Headern gemischt. Falls das Plugin alle Header kontrollieren muss, z.B. um einige zu entfernen, kann das Feld `OverrideHeaders*` von einem Plugin gesetzt werden, um dem Kernprozess von Reprox anzuzeigen, dass alle Header überschrieben werden müssen, anstatt sie zu mischen.
- `OverrideHeadersIn` - zeigt an, dass das Plugin für alle eingehenden Header verantwortlich ist.
- `OverrideHeadersOut` - zeigt an, dass das Plugin für alle ausgehenden Header verantwortlich ist
Um den Entwicklungsprozess zu vereinfachen, werden alle Bausteine bereitgestellt. Dazu gehören `lib.Plugin`, das die Registrierung, das Lauschen und das Verteilen von Aufrufen übernimmt, sowie `lib.Request` und `lib.Response`, die Eingabe und Ausgabe definieren. Plugin-Autoren sollten konkrete Handler implementieren, die der Signatur `func(req lib.Request, res *lib.HandlerResponse) (err error)` entsprechen. Jedes Plugin kann mehrere solche Handler enthalten.
_Siehe [examples/plugin](https://github.com/umputun/reproxy/tree/master/examples/plugin) für weitere Informationen_
## Containersicherheit
Standardmäßig läuft der Reprox-Container unter dem Root-Benutzer, um die anfängliche Einrichtung und den Zugriff auf den Docker-Socket zu vereinfachen. Dies ist erforderlich, damit der Docker-Anbieter die laufenden Container erkennen kann. Wenn eine solche Erkennung jedoch nicht erforderlich ist oder der Docker-Anbieter nicht verwendet wird, wird empfohlen, den Benutzer auf einen weniger privilegierten zu ändern. Dies kann auf der Docker-Compose-Ebene und auf Docker-Ebene mit der Option `user` erfolgen, siehe den folgenden Abschnitt für Details.
Manchmal ist es auch bei Inside-the-Docker-Routing sinnvoll, den Docker-Anbieter zu deaktivieren und Regeln mit einem statischen oder Dateianbieter einzurichten. Alle Container, die innerhalb einer Compose laufen, teilen sich dasselbe Netzwerk und sind über lokales DNS erreichbar. Der Benutzer kann eine Regel wie diese haben, um die Docker-Erkennung zu vermeiden: `- STATIC_RULES=*,/api/email/(.*),http://email-sender:8080/$$1`. Diese Regel erwartet einen `email-sender`-Container, der innerhalb derselben Compose definiert ist. Bitte beachten Sie: Benutzer können das gleiche Ergebnis erzielen, indem sie das Docker-Netzwerk verwenden, selbst wenn der Zieldienst in einer anderen Compose-Datei definiert wurde. Auf diese Weise kann die Reprox-Konfiguration getrennt von den eigentlichen Diensten bleiben.
Es befindet sich außer der Reprox-Binärdatei nichts im Reprox-Container, da er auf einem leeren (Scratch-)Image basiert.
### Ausführen mit einem Nicht-Root-Benutzer
Ein Benutzer mit der UID `1001` (der zu den Gruppen `1001` und `999` gehört) ist im Container vorerstellt und kann zum Ausführen von Reprox als Nicht-Root-Benutzer verwendet werden:```yaml
services:
reproxy:
user: 1001
image: umputun/reproxy:latest
# <...>
# see examples/ssl/docker-compose.yml for the full file example
Wenn Sie den Docker-Anbieter verwenden möchten, müssen Sie sicherstellen, dass dieser Benutzer die Berechtigung hat, auf den Docker-Socket auf dem Hostsystem zuzugreifen. Wie Sie diese Berechtigungen einrichten, hängt von Ihrer Hostsystemkonfiguration ab. Weitere Informationen zur Konfiguration von Docker-Socket-Berechtigungen finden Sie in der Docker-Dokumentation zur Sicherung des Docker-Daemon-Sockets.
Jede Option kann in zwei Formen bereitgestellt werden: als Befehlszeilen- oder als Umgebungsschlüssel-Wert-Paar. Einige Befehlszeilenoptionen haben eine Kurzform, wie -l localhost:8080, und alle haben die Langform, d. h. --listen=localhost:8080. Der Umgebungsschlüssel (Name) ist für jede Option als Suffix aufgeführt, z. B. [$LISTEN].
Alle Größenoptionen unterstützen Einheitssuffixe, z. B. 10K (oder 10k) für Kilobyte, 16M (oder 16m) für Megabyte, 10G (oder 10g) für Gigabyte. Das Fehlen eines Suffixes (z. B. 1024) bedeutet Bytes.
Einige Optionen sind wiederholbar; in diesem Fall kann der Benutzer sie mehrmals über die Befehlszeile oder durch Komma getrennt in der Umgebungsvariable übergeben. Zum Beispiel ist --ssl.fqdn eine solche Option und kann als --ssl.fqdn=a1.example.com --ssl.fqdn=a2.example.com oder als Umgebungsvariable SSL_ACME_FQDN=a1.example.com,a2.example.com übergeben werden.
Dies ist die Liste aller Optionen, die mehrere Elemente unterstützen:
ssl.fqdn (SSL_ACME_FQDN)assets.cache (ASSETS_CACHE)docker.exclude (DOCKER_EXCLUDE)static.rule ($STATIC_RULES)header ($HEADER)drop-header ($DROP_HEADERS)-l, --listen= listen on host:port (default: 0.0.0.0:8080/8443 under docker, 127.0.0.1:80/443 without) [$LISTEN]
-m, --max= max request size (default: 64K) [$MAX_SIZE]
-g, --gzip enable gz compression [$GZIP]
-x, --header= outgoing proxy headers to add [$HEADER]
--drop-header= incoming headers to drop [$DROP_HEADERS]
--basic-htpasswd= htpasswd file for basic auth [$BASIC_HTPASSWD]
--lb-type=[random|failover|roundrobin] load balancer type (default: random) [$LB_TYPE]
--signature enable reproxy signature headers [$SIGNATURE]
--remote-lookup-headers enable remote lookup headers, trust only behind a trusted proxy [$REMOTE_LOOKUP_HEADERS]
--keep-host keep original Host header as default when proxying [$KEEP_HOST]
--insecure skip SSL verification on destination host [$INSECURE]
--dbg debug mode [$DEBUG]
ssl: --ssl.type=[none|static|auto] ssl (auto) support (default: none) [$SSL_TYPE] --ssl.cert= path to cert.pem file [$SSL_CERT] --ssl.key= path to key.pem file [$SSL_KEY] --ssl.acme-location= dir where certificates will be stored by autocert manager (default: ./var/acme) [$SSL_ACME_LOCATION] --ssl.acme-email= admin email for certificate notifications [$SSL_ACME_EMAIL] --ssl.http-port= http port for redirect to https and acme challenge test (default: 8080 under docker, 80 without) [$SSL_HTTP_PORT] --ssl.fqdn= FQDN(s) for ACME certificates [$SSL_ACME_FQDN]
assets: -a, --assets.location= assets location [$ASSETS_LOCATION] --assets.root= assets web root (default: /) [$ASSETS_ROOT] --assets.spa spa treatment for assets [$ASSETS_SPA] --assets.cache= cache duration for assets [$ASSETS_CACHE] --assets.not-found= path to file to serve on 404, relative to location [$ASSETS_NOT_FOUND]
logger: --logger.stdout enable stdout logging [$LOGGER_STDOUT] --logger.enabled enable access and error rotated logs [$LOGGER_ENABLED] --logger.file= location of access log (default: access.log) [$LOGGER_FILE] --logger.max-size= maximum size before it gets rotated (default: 100M) [$LOGGER_MAX_SIZE] --logger.max-backups= maximum number of old log files to retain (default: 10) [$LOGGER_MAX_BACKUPS]
docker: --docker.enabled enable docker provider [$DOCKER_ENABLED] --docker.host= docker host (default: unix:///var/run/docker.sock) [$DOCKER_HOST] --docker.network= docker network [$DOCKER_NETWORK] --docker.exclude= excluded containers [$DOCKER_EXCLUDE] --docker.auto enable automatic routing (without labels) [$DOCKER_AUTO] --docker.prefix= prefix for docker source routes [$DOCKER_PREFIX] --docker.api-version= docker API version (default: 1.24) [$DOCKER_API_VERSION]
consul-catalog: --consul-catalog.enabled enable consul catalog provider [$CONSUL_CATALOG_ENABLED] --consul-catalog.address= consul address (default: http://127.0.0.1:8500) [$CONSUL_CATALOG_ADDRESS] --consul-catalog.interval= consul catalog check interval (default: 1s) [$CONSUL_CATALOG_INTERVAL]
file: --file.enabled enable file provider [$FILE_ENABLED] --file.name= file name (default: reproxy.yml) [$FILE_NAME] --file.interval= file check interval (default: 3s) [$FILE_INTERVAL] --file.delay= reload only after the file has been unchanged for this long (default: 500ms) [$FILE_DELAY]
static: --static.enabled enable static provider [$STATIC_ENABLED] --static.rule= routing rules [$STATIC_RULES]
timeout: --timeout.read-header= read header server timeout (default: 5s) [$TIMEOUT_READ_HEADER] --timeout.write= write server timeout (default: 30s) [$TIMEOUT_WRITE] --timeout.idle= idle server timeout (default: 30s) [$TIMEOUT_IDLE] --timeout.dial= dial transport timeout (default: 30s) [$TIMEOUT_DIAL] --timeout.keep-alive= keep-alive transport timeout (default: 30s) [$TIMEOUT_KEEP_ALIVE] --timeout.resp-header= response header transport timeout (default: 5s) [$TIMEOUT_RESP_HEADER] --timeout.idle-conn= idle connection transport timeout (default: 90s) [$TIMEOUT_IDLE_CONN] --timeout.tls= TLS hanshake transport timeout (default: 10s) [$TIMEOUT_TLS] --timeout.continue= expect continue transport timeout (default: 1s) [$TIMEOUT_CONTINUE]
mgmt: --mgmt.enabled enable management API [$MGMT_ENABLED] --mgmt.listen= listen on host:port (default: 0.0.0.0:8081) [$MGMT_LISTEN] --mgmt.low-cardinality use route patterns instead of raw paths for metrics labels [$MGMT_LOW_CARDINALITY]
error: --error.enabled enable html errors reporting [$ERROR_ENABLED] --error.template= error message template file [$ERROR_TEMPLATE]
health-check: --health-check.enabled enable automatic health-check [$HEALTH_CHECK_ENABLED] --health-check.interval= automatic health-check interval (default: 300s) [$HEALTH_CHECK_INTERVAL]
throttle: --throttle.system= throttle overall activity' (default: 0) [$THROTTLE_SYSTEM] --throttle.user= limit req/sec per user and per proxy destination (default: 0) [$THROTTLE_USER]
upstream: --upstream.max-idle-conns= max idle connections total (default: 100) [$UPSTREAM_MAX_IDLE_CONNS] --upstream.max-conns= max connections per upstream host (0=unlimited) (default: 0) [$UPSTREAM_MAX_CONNS]
plugin: --plugin.enabled enable plugin support [$PLUGIN_ENABLED] --plugin.listen= registration listen on host:port (default: 127.0.0.1:8081) [$PLUGIN_LISTEN]
Help Options: -h, --help Show this help message
## Status
Das Projekt befindet sich in aktiver Entwicklung und kann bis zur Veröffentlichung von `v1` bahnbrechende Änderungen enthalten. Wir bemühen uns jedoch nach Kräften, nichts zu ändern, es sei denn, es gibt einen guten Grund. Ab Version 0.4.x gilt reproxy als ausreichend für den Einsatz in der Praxis, und viele Setups laufen damit in der Produktion.
example.com,^/login,https://api.example.com/login,,,,2 – anfragebezogene Begrenzung von 2 req/s pro Benutzer (positionsabhängige Felder davor sind leer).reproxy.keep-host - Host-Header beibehalten (yes, true, 1) oder durch Ziel-Host ersetzen (no, false, 0)reproxy.forward-health-checks - /ping- und /health-Anfragen an das Backend weiterleiten, anstatt dass reproxy sie bearbeitet (yes, true, 1). Nützlich, wenn das Backend eigene Health-Check-Endpunkte mit anwendungsspezifischen Antworten hat.reproxy.timeout - Zeitüberschreitung pro Route als Go-Dauer (z.B. 5m, 30s). 0 oder nicht gesetzt übernimmt den globalen --timeout.write. Ungültige Werte werden mit einer Warnung ignoriert.reproxy.throttle - Anfragen/Sekunde-Limit pro Route und Benutzer. 0 oder nicht gesetzt übernimmt --throttle.user. Ungültige oder negative Werte werden mit einer Warnung ignoriert.reproxy.enabled - Container für reproxy-Ziele aktivieren (yes, true, 1) oder deaktivieren (no, false, 0).yestrue