Skip to content
KitploitKITPLOIT
ToolsExploitsBlog
Log in
Einreichen
ToolsExploitsBlog
Einreichen

Hacking-, PenTest- und Cybersicherheits-Tools für Ihr Sicherheitsarsenal!

Kitploit ist ein Verzeichnis von Hacking-, Cybersicherheits- und Pentesting-Tools. Entdecken Sie die neuesten Projekt-Updates, um Schwachstellen zu finden, Systeme zu analysieren, Tests zu automatisieren und Ihre Sicherheit zu stärken.

··Feeds·Kontakt·Datenschutz·© 2026 Kitploit

Tool-Verzeichnis

Kategorien

Alle Kategorien anzeigen
Loading categories
reproxy — Leichter HTTP(S)-Edge-Server und Reverse-Proxy mit automatischem SSL, Docker/Consul-Erkennung, routenspezifischer Authentifizierung, Ratenbegrenzung und gesundheitscheckbasiertem Failover. | Kitploit
Tools/GitHubGitHub/umputun/reproxy
Authentifizierung & AutorisierungAllgemeine DienstprogrammeWebsicherheitNetzwerksicherheitAPI-Sicherheit
GitHubumputun/reproxy

reproxy

Leichter HTTP(S)-Edge-Server und Reverse-Proxy mit automatischem SSL, Docker/Consul-Erkennung, routenspezifischer Authentifizierung, Ratenbegrenzung und gesundheitscheckbasiertem Failover.

Repository anzeigen
1.3k9630vor 23 TagenVon Kitploit geprüft

Beliebteste

Alle anzeigen →

Entdecken Sie die meistgenutzten Tools unserer Community.

Alle Tools erkunden

Durchsuchen Sie unsere Tool-Sammlung

Alle Tools anzeigen →
Teilen
Webseite
Reproxy | Einfacher Reverse Proxy

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.

  • Automatische SSL-Terminierung mit Let's Encrypt
  • Unterstützung von benutzerbereitgestellten SSL-Zertifikaten
  • Einfache aber flexible Proxy-Regeln
  • Statischer, befehlszeilenbasierter Proxy-Regelanbieter
  • Dynamischer, dateibasierter Proxy-Regelanbieter
  • Docker-Anbieter mit automatischer Erkennung
  • Consul-Catalog-Anbieter mit Erkennung über Service-Tags
  • Unterstützung für mehrere (virtuelle) Hosts
  • Optionale Datenverkehrskomprimierung
  • Optionale IP-basierte Zugriffskontrolle
  • Routenbezogene Basisauthentifizierung
  • Benutzerdefinierte Größenbeschränkungen und Timeouts
  • Einzelne Binärdateiverteilung
  • Docker-Container-Verteilung
  • Integrierter statischer Asset-Server mit optionalem SPA-freundlichem Modus
  • Unterstützung für Weiterleitungsregeln
  • Optionaler Begrenzer für die Gesamtaktivität sowie für die Benutzeraktivität
  • Live-Health-Check und Failover/Load-Balancing
  • Management-Server mit Routeninformationen und Prometheus-Metriken
  • Plugin-Unterstützung über RPC zur Implementierung benutzerdefinierter Funktionen
  • Optionales Logging mit sowohl Apache-Log-Format als auch vereinfachten stdout-Berichten.

build Coverage Status Go Report Card Docker Hub

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:

  • mit einem statischen Anbieter: 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 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.

  • für eine Binärverteilung laden Sie die entsprechende Datei im Release-Bereich herunter
  • für Homebrew-Benutzer: brew install umputun/apps/reproxy
  • Docker-Container verfügbar auf Docker Hub sowie auf Github Container Registry. D.h. docker 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.

Anbieter

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

Statischer Anbieter

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.com
  • example.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).

Datei-Anbieter

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

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

Tool herunterladen