ReproxyはシンプルなエッジHTTP(s)サーバー/リバースプロキシであり、さまざまなプロバイダー（docker、static、file、consul catalog）をサポートしています。1つ以上のプロバイダーが、要求されたサーバー、要求されたURL、宛先URL、およびヘルスチェックURLに関する情報を提供します。単一のバイナリまたはDockerコンテナとして配布されます。
サーバー（ホスト）はFQDN（例：s.example.com）、*（キャッチオール）、または正規表現で設定できます。完全一致が優先されるため、example.com と example\.(com|org) の2つのルールがある場合、example.com/some/url へのリクエストは前者に一致します。要求されたURLは正規表現にでき、例えば ^/api/(.*) のように、宛先URLには正規表現でマッチしたグループを含めることができます（例：http://d.example.com:8080/$1）。上記の例では、http://s.example.com/api/something?foo=bar は http://d.example.com:8080/something?foo=bar にプロキシされます。
便宜上、末尾に / が付き、正規表現グループがないリクエストは /(.*) に展開され、その場合の宛先は /$1 に展開されます。つまり、/api/ -> http://127.0.0.1/service は ^/api/(.*) -> http://127.0.0.1/service/$1 と解釈されます。
宛先URLではホスト置換がサポートされています。例えば、/files/${host} はマッチしたホスト名に置き換えられます。$host（中括弧なし）も使用できます。
HTTPとHTTPSの両方をサポートしています。HTTPSでは、静的証明書の他に、自動ACME（Let's Encrypt）証明書を使用できます。オプションのアセットサーバーを使用して静的ファイルを提供することもできます。Reproxyを起動するには、少なくとも1つのプロバイダーを定義する必要があります。残りのパラメーターは厳密にはオプションであり、妥当なデフォルト値があります。
例：
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は、小さな自己完結型バイナリとDockerイメージとして配布されています。バイナリとイメージの両方が複数のアーキテクチャと複数のオペレーティングシステム（linux_x86_64、linux_arm64、linux_arm、macos_x86_64、macos_arm64、windows_x86_64、windows_armなど）をサポートしています。また、arm64とx86の両方のdebおよびrpmパッケージも提供しています。
brew install umputun/apps/reproxydocker pull umputun/reproxy または docker pull ghcr.io/umputun/reproxy。最新の安定版には :vX.Y.Z のDockerタグ（:latest エイリアス付き）が付いており、現在のmasterには :master タグが付いています。
プロキシルールはさまざまなプロバイダーによって提供されます。現在含まれているのは、file、docker、static、consul-catalog です。各プロバイダーは、プロキシリクエストと静的（アセット）の両方に対して複数のルーティングルールを定義できます。ユーザーは同時に複数のプロバイダーを設定できます。
各種プロバイダーの例については、examplesを参照してください。
これは、すべてのマッピングルールをコマンドライン（または環境変数）で直接定義する最もシンプルなプロバイダーです。複数のルールをサポートしています。各ルールは、カンマ区切りの3～7要素 server,sourceurl,destination[,ping-url[,forward-health-checks[,timeout[,throttle]]]] です。例：
*,^/api/(.*),https://api.example.com/$1 – /api プレフィックスを持つ任意のホスト/サーバーへのすべてのリクエストを https://api.example.com にプロキシします。example.com,/foo/bar,https://api.example.com/zzz,https://api.example.com/ping – example.com へのすべてのリクエストで、/foo/bar のURLを https://api.example.com/zzz にプロキシし、ヘルスチェックには https://api.example.com/ping を使用します。example.com,/foo/bar,https://api.example.com/zzz,https://api.example.com/ping,true – 上記と同じですが、/ping および /health リクエストもバックエンドに転送します。example.com,^/upload/(.*),https://api.example.com/$1,,,5m – ルートごとのリクエストタイムアウトを5分に設定します（4番目と5番目のフィールドは空欄で、ping-urlとforward-health-checksをスキップします）。example.com,^/login,https://api.example.com/login,,,,2 – ルートごとのユーザーあたりのスロットルを2 req/secに設定します（前の位置フィールドは空欄）。4番目の要素は、ヘルスレポートに使用されるオプションのping URLを定義します。5番目の要素は、ヘルスチェックリクエストをバックエンドに転送することをオプションで有効にします（true、yes、1）。詳細はヘルスチェックセクションを参照してください。6番目の要素は、ルートごとのオプションのリクエストタイムアウト（Goの期間。例：5m、30s）です。0 または空の場合はグローバルな --timeout.write 設定を継承します。7番目の要素は、ルートごとのユーザーあたりのオプションの req/sec 制限です。0 または空の場合は --throttle.user を継承します。空の位置フィールドは許可されています（未使用の中間フィールドには ,, を使用できます）。
このプロバイダーは、ルーティングルールを含むyamlファイルを使用します。
reproxy --file.enabled --file.name=config.yml
config.yml の例：```yaml
default: # the same as * (catch-all) server
これは動的プロバイダーであり、ファイルの変更は自動的に適用されます。
**異なるドメイン上の複数の静的サイト**は、サーバー名をキーとして`assets: true`を使用することで提供できます。```yaml
site-en.example.com:
- { route: "/", dest: "/var/www/en", "assets": true }
site-ru.example.com:
- { route: "/", dest: "/var/www/ru", "assets": true }
重要: アセットルールの route フィールドはパスプレフィックス（例: /、/web/）でなければならず、正規表現ではありません。^/(.*) のような正規表現パターンは、静的アセットのマッチングがパスプレフィックス比較を使用するため、assets: true では機能しません。
Dockerプロバイダーは、追加設定なしで完全自動検出（--docker.auto）をサポートしています。デフォルトでは、http://<url>/<コンテナ名>/(.*) のようなすべてのリクエストを、指定されたコンテナの内部IPと公開ポートにリダイレクトします。アクティブ（実行中）なコンテナのみが検出されます。
このデフォルトはラベルで変更できます：