Torna agli aggiornamenti
New releaseAug 20, 2026

reproxy v1.7.1

Server HTTP(S) leggero perimetrale e reverse proxy con SSL automatico, discovery Docker/Consul, autenticazione per route, limitazione del tasso e failover basato su health check.

Condividi
Reproxy | Simple Reverse Proxy

Reproxy è un semplice server HTTP(s) edge / reverse proxy che supporta vari provider (docker, static, file, consul catalog). Uno o più provider forniscono informazioni sul server richiesto, sull'URL richiesto, sull'URL di destinazione e sull'URL di health check. È distribuito come binario singolo o come container docker.

  • Terminazione SSL automatica con Let's Encrypt
  • Supporto per certificati SSL forniti dall'utente
  • Regole proxy semplici ma flessibili
  • Provider di regole proxy statico, da riga di comando
  • Provider di regole proxy dinamico, basato su file
  • Provider Docker con scoperta automatica
  • Provider Consul Catalog con scoperta tramite tag di servizio
  • Supporto per host multipli (virtuali)
  • Compressione del traffico opzionale
  • Controllo degli accessi basato su IP opzionale
  • Autenticazione di base per singola rotta
  • Limiti di dimensione e timeout definiti dall'utente
  • Distribuzione come binario singolo
  • Distribuzione come container Docker
  • Server di asset statici integrato con modalità "SPA friendly" opzionale
  • Supporto per regole di redirect
  • Limitatore opzionale per l'attività complessiva e per l'attività dell'utente
  • Health check live e fail-over/load-balancing
  • Server di gestione con informazioni sulle rotte e metriche prometheus
  • Supporto ai plugin tramite RPC per implementare funzionalità personalizzate
  • Logging opzionale con sia Apache Log Format che report semplificati su stdout.

build Coverage Status Go Report Card Docker Hub

Il server (host) può essere impostato come FQDN, ad esempio s.example.com, * (catch all) o una regex. La corrispondenza esatta ha la priorità, quindi se ci sono due regole con server example.com e example\.(com|org), una richiesta a example.com/some/url corrisponderà alla prima. L'URL richiesto può essere una regex, ad esempio ^/api/(.*), e l'URL di destinazione può contenere gruppi corrispondenti dalla regex, ad esempio http://d.example.com:8080/$1. Per l'esempio precedente http://s.example.com/api/something?foo=bar sarà inoltrato tramite proxy a http://d.example.com:8080/something?foo=bar.

Per comodità, le richieste con / finale e senza gruppi regex vengono espanse a /(.*), e le destinazioni in questi casi vengono espanse a /$1. Ad esempio, /api/ -> http://127.0.0.1/service sarà tradotto in ^/api/(.*) -> http://127.0.0.1/service/$1.

La sostituzione dell'host è supportata nell'URL di destinazione. Ad esempio, /files/${host} sarà sostituito con il nome dell'host corrispondente. È possibile utilizzare anche $host (senza parentesi graffe).

Sono supportati sia HTTP che HTTPS. Per HTTPS, è possibile utilizzare sia un certificato statico che certificati ACME automatici (Let's Encrypt). Un server di asset opzionale può essere utilizzato per servire file statici. L'avvio di reproxy richiede almeno un provider definito. Il resto dei parametri è strettamente opzionale e ha valori predefiniti ragionevoli.

Esempi:

  • con un provider statico: reproxy --static.enabled --static.rule="*,example.com/api/(.*),https://api.example.com/$1"
  • con scoperta automatica docker: reproxy --docker.enabled --docker.auto
  • come container docker: docker up -p 80:8080 umputun/reproxy --docker.enabled --docker.auto
  • con SSL automatico: docker up -p 80:8080 -p 443:8443 umputun/reproxy --docker.enabled --docker.auto --ssl.type=auto --ssl.fqdn=example.com

Install

Reproxy è distribuito come un piccolo binario autonomo e come immagine docker. Sia il binario che l'immagine supportano più architetture e più sistemi operativi, tra cui linux_x86_64, linux_arm64, linux_arm, macos_x86_64, macos_arm64, windows_x86_64 e windows_arm. Forniamo inoltre pacchetti deb e rpm sia per arm64 che per x86.

  • per una distribuzione binaria scarica il file appropriato nella sezione release
  • per gli utenti Homebrew: brew install umputun/apps/reproxy
  • container docker disponibile su Docker Hub così come su Github Container Registry. Ad esempio docker pull umputun/reproxy o docker pull ghcr.io/umputun/reproxy.

L'ultima versione stabile ha il tag docker :vX.Y.Z (con alias :latest) e il master corrente ha il tag :master.

Provider

Regole di proxy fornite da vari provider. Attualmente inclusi - file, docker, static e consul-catalog. Ogni provider può definire più regole di routing sia per le richieste proxate che per quelle statiche (asset). L'utente può impostare più provider contemporaneamente.

Consulta esempi di vari provider in examples

Provider static

Questo è il provider più semplice che definisce tutte le regole di mapping direttamente nella riga di comando (o nell'ambiente). Sono supportate più regole. Ogni regola è composta da 3 a 7 elementi separati da virgola server,sourceurl,destination[,ping-url[,forward-health-checks[,timeout[,throttle]]]]. Ad esempio:

  • *,^/api/(.*),https://api.example.com/$1 - inoltra tutte le richieste a qualsiasi host/server con prefisso /api verso https://api.example.com
  • example.com,/foo/bar,https://api.example.com/zzz,https://api.example.com/ping - inoltra tutte le richieste a example.com e con url /foo/bar verso https://api.example.com/zzz e usa https://api.example.com/ping per il controllo di integrità.
  • example.com,/foo/bar,https://api.example.com/zzz,https://api.example.com/ping,true - come sopra ma inoltra anche le richieste /ping e /health al backend.
  • example.com,^/upload/(.*),https://api.example.com/$1,,,5m - timeout della richiesta per rotta di 5 minuti (il 4° e il 5° campo lasciati vuoti per saltare ping-url e forward-health-checks).
  • example.com,^/login,https://api.example.com/login,,,,2 - throttle per rotta di 2 req/sec per utente (i campi posizionali precedenti sono lasciati vuoti).

Il 4° elemento definisce un ping url opzionale usato per la segnalazione dello stato di integrità. Il 5° elemento abilita opzionalmente l'inoltro delle richieste di controllo di integrità al backend (true, yes, 1). Consulta la sezione Controllo di integrità per maggiori dettagli. Il 6° elemento è un timeout opzionale della richiesta per rotta (durata Go, ad es. 5m, 30s); 0 o vuoto eredita l'impostazione globale --timeout.write. Il 7° elemento è un limite opzionale di req/sec per utente per rotta; 0 o vuoto eredita --throttle.user. I campi posizionali vuoti sono consentiti (ad es. ,, per i campi centrali non utilizzati).

Provider file

Questo provider usa un file yaml con le regole di routing.

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

Esempio di config.yml:

Categorie