Retour aux mises à jour
New releaseJul 15, 2026

reproxy v1.7.0

Serveur HTTP(S) de périphérie léger et proxy inverse avec SSL automatique, découverte Docker/Consul, authentification par route, limitation de débit, et basculement basé sur les vérifications de santé.

Partager
Reproxy | Simple Reverse Proxy

Reproxy est un simple serveur HTTP(s) de périphérie / proxy inverse prenant en charge divers fournisseurs (docker, statique, fichier, catalogue consul). Un ou plusieurs fournisseurs fournissent des informations sur le serveur demandé, l'URL demandée, l'URL de destination et l'URL de vérification de l'état. Il est distribué sous forme de binaire unique ou de conteneur docker.

  • Terminaison SSL automatique avec Let's Encrypt
  • Prise en charge des certificats SSL fournis par l'utilisateur
  • Règles de proxy simples mais flexibles
  • Fournisseur de règles de proxy statiques, en ligne de commande
  • Fournisseur de règles de proxy dynamiques, basé sur des fichiers
  • Fournisseur Docker avec découverte automatique
  • Fournisseur Consul Catalog avec découverte par tags de service
  • Prise en charge de plusieurs hôtes (virtuels)
  • Compression du trafic en option
  • Contrôle d'accès basé sur l'IP en option
  • Authentification basique par route
  • Limites de taille et délais d'attente définis par l'utilisateur
  • Distribution sous forme de binaire unique
  • Distribution sous forme de conteneur Docker
  • Serveur d'actifs statiques intégré avec mode « compatible SPA » en option
  • Prise en charge des règles de redirection
  • Limiteur optionnel pour l'activité globale ainsi que pour l'activité de l'utilisateur
  • Vérification de l'état en direct et basculement/répartition de charge
  • Serveur de gestion avec informations sur les routes et métriques prometheus
  • Prise en charge de plugins via RPC pour implémenter des fonctionnalités personnalisées
  • Journalisation en option avec à la fois le format de journal Apache et des rapports stdout simplifiés.

build Coverage Status Go Report Card Docker Hub

Le serveur (hôte) peut être défini comme un FQDN, c'est-à-dire s.example.com, * (attrape-tout) ou une regex. La correspondance exacte est prioritaire, donc s'il existe deux règles avec les serveurs example.com et example\.(com|org), une requête vers example.com/some/url correspondra à la première. L'URL demandée peut être une regex, par exemple ^/api/(.*), et l'URL de destination peut contenir des groupes correspondants à la regex, c'est-à-dire http://d.example.com:8080/$1. Pour l'exemple ci-dessus, http://s.example.com/api/something?foo=bar sera proxifié vers http://d.example.com:8080/something?foo=bar.

Pour plus de commodité, les requêtes avec un / final et sans groupes regex sont étendues en /(.*), et les destinations dans ces cas sont étendues en /$1. C'est-à-dire que /api/ -> http://127.0.0.1/service sera traduit en ^/api/(.*) -> http://127.0.0.1/service/$1.

La substitution d'hôte est prise en charge dans l'URL de destination. Par exemple, /files/${host} sera remplacé par le nom d'hôte correspondant. $host (sans accolades) peut également être utilisé.

HTTP et HTTPS sont pris en charge. Pour HTTPS, un certificat statique peut être utilisé ainsi que des certificats ACME automatisés (Let's Encrypt). Un serveur d'actifs optionnel peut être utilisé pour servir des fichiers statiques. Le démarrage de reproxy nécessite au moins un fournisseur défini. Le reste des paramètres est strictement optionnel et dispose de valeurs par défaut raisonnables.

Exemples :

  • avec un fournisseur statique : reproxy --static.enabled --static.rule="*,example.com/api/(.*),https://api.example.com/$1"
  • avec une découverte automatique docker : reproxy --docker.enabled --docker.auto
  • en tant que conteneur docker : docker up -p 80:8080 umputun/reproxy --docker.enabled --docker.auto
  • avec SSL automatique : docker up -p 80:8080 -p 443:8443 umputun/reproxy --docker.enabled --docker.auto --ssl.type=auto --ssl.fqdn=example.com

Install

Reproxy est distribué sous forme d'un petit binaire autonome ainsi que d'une image docker. Le binaire et l'image prennent en charge plusieurs architectures et plusieurs systèmes d'exploitation, notamment linux_x86_64, linux_arm64, linux_arm, macos_x86_64, macos_arm64, windows_x86_64 et windows_arm. Nous fournissons également des paquets deb et rpm pour arm64 et x86.

  • pour une distribution binaire, téléchargez le fichier approprié dans la section des versions
  • pour les utilisateurs de Homebrew : brew install umputun/apps/reproxy
  • conteneur docker disponible sur Docker Hub ainsi que sur Github Container Registry. C'est-à-dire docker pull umputun/reproxy ou docker pull ghcr.io/umputun/reproxy.

La dernière version stable possède le tag docker :vX.Y.Z (avec l'alias :latest) et le master actuel possède le tag :master.

Fournisseurs

Règles de proxy fournies par divers fournisseurs. Actuellement inclus - file, docker, static et consul-catalog. Chaque fournisseur peut définir plusieurs règles de routage pour les requêtes proxifiées et les fichiers statiques (assets). L'utilisateur peut définir plusieurs fournisseurs en même temps.

Voir des exemples de divers fournisseurs dans examples

Fournisseur static

C'est le fournisseur le plus simple, définissant toutes les règles de mappage directement en ligne de commande (ou via l'environnement). Plusieurs règles sont prises en charge. Chaque règle est composée de 3 à 7 éléments séparés par des virgules server,sourceurl,destination[,ping-url[,forward-health-checks[,timeout[,throttle]]]]. Par exemple :

  • *,^/api/(.*),https://api.example.com/$1 - proxifie toutes les requêtes vers n'importe quel hôte/serveur avec le préfixe /api vers https://api.example.com
  • example.com,/foo/bar,https://api.example.com/zzz,https://api.example.com/ping - proxifie toutes les requêtes vers example.com et avec l'url /foo/bar vers https://api.example.com/zzz et utilise https://api.example.com/ping pour le contrôle de santé.
  • example.com,/foo/bar,https://api.example.com/zzz,https://api.example.com/ping,true - identique au précédent mais transfère également les requêtes /ping et /health au backend.
  • example.com,^/upload/(.*),https://api.example.com/$1,,,5m - délai d'expiration des requêtes de 5 minutes par route (les 4e et 5e champs sont laissés vides pour ignorer ping-url et forward-health-checks).
  • example.com,^/login,https://api.example.com/login,,,,2 - limitation de débit de 2 req/sec par utilisateur pour cette route (les champs positionnels précédents sont laissés vides).

Catégories