reproxy v1.7.0 — Lightweight edge HTTP(S) server and reverse proxy with automatic SSL, Docker/Consul discovery, per-route authentication, rate limiting, and health-check-based failover.

ReproxyはシンプルなエッジHTTP(s)サーバー/リバースプロキシであり、さまざまなプロバイダー（docker、static、file、consul catalog）をサポートしています。1つ以上のプロバイダーが、要求されたサーバー、要求されたURL、宛先URL、およびヘルスチェックURLに関する情報を提供します。単一のバイナリまたはDockerコンテナとして配布されます。

Let's Encryptによる自動SSL終端
ユーザー提供のSSL証明書のサポート
シンプルかつ柔軟なプロキシルール
静的コマンドラインプロキシルールプロバイダー
動的ファイルベースのプロキシルールプロバイダー
自動検出機能付きDockerプロバイダー
サービスタグによる検出機能付きConsul Catalogプロバイダー
複数（仮想）ホストのサポート
オプションのトラフィック圧縮
オプションのIPベースアクセス制御
ルートごとの基本認証
ユーザー定義のサイズ制限とタイムアウト
単一バイナリ配布
Dockerコンテナ配布
オプションの「SPAフレンドリー」モードを備えた組み込み静的アセットサーバー
リダイレクトルールのサポート
全体的なアクティビティとユーザーアクティビティのオプション制限機能
ライブヘルスチェックとフェイルオーバー/ロードバランシング
ルート情報とPrometheusメトリクスを提供する管理サーバー
RPCを介したプラグインサポートによるカスタム機能の実装
Apacheログ形式と簡略化されたstdoutレポートによるオプションのロギング。

サーバー（ホスト）は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"
自動Docker検出の場合：reproxy --docker.enabled --docker.auto
Dockerコンテナとして：docker up -p 80:8080 umputun/reproxy --docker.enabled --docker.auto
自動SSLの場合：docker up -p 80:8080 -p 443:8443 umputun/reproxy --docker.enabled --docker.auto --ssl.type=auto --ssl.fqdn=example.com

インストール

Reproxyは、小さな自己完結型バイナリとDockerイメージとして配布されています。バイナリとイメージの両方が複数のアーキテクチャと複数のオペレーティングシステム（linux_x86_64、linux_arm64、linux_arm、macos_x86_64、macos_arm64、windows_x86_64、windows_armなど）をサポートしています。また、arm64とx86の両方のdebおよびrpmパッケージも提供しています。

バイナリ配布の場合は、リリースセクションから適切なファイルをダウンロードしてください。
Homebrewユーザー向け：brew install umputun/apps/reproxy
DockerコンテナはDocker HubおよびGithub Container Registryで入手できます。例：docker 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

{ route: "^/api/svc1/(.*)", dest: "http://127.0.0.1:8080/blah1/$1" }
{ route: "/api/svc3/xyz", dest: "http://127.0.0.3:8080/blah3/xyz", ping: "http://127.0.0.3:8080/ping", remote: "192.168.1.0/24, 127.0.0.1", # optional, restrict access to the route forward-health-checks: true # optional, forward /ping and /health to backend }
{ route: "^/admin/(.*)", dest: "http://127.0.0.4:8080/$1", auth: "admin:$2y$05$..." # optional, per-route basic auth (htpasswd bcrypt format) }
{ route: "^/upload/(.*)", dest: "http://127.0.0.5:8080/$1", timeout: 5m # optional, per-route request timeout (Go duration). 0 or omitted inherits --timeout.write }
{ route: "^/login", dest: "http://127.0.0.6:8080/login", throttle: 2 # optional, per-route req/sec per user. 0 or omitted inherits --throttle.user } srv.example.com:
{ route: "^/api/svc2/(.*)", dest: "http://127.0.0.2:8080/blah2/$1/abc" }
{ route: "/web/", dest: "/var/www", "assets": true } "*.files.example.com":
{ route: "^/files/(.*)", dest: "http://123.123.200.200:8080/$host/$1" }

これは動的プロバイダーであり、ファイルの変更は自動的に適用されます。

**異なるドメイン上の複数の静的サイト**は、サーバー名をキーとして`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プロバイダーは、追加設定なしで完全自動検出（--docker.auto）をサポートしています。デフォルトでは、http://<url>/<コンテナ名>/(.*) のようなすべてのリクエストを、指定されたコンテナの内部IPと公開ポートにリダイレクトします。アクティブ（実行中）なコンテナのみが検出されます。

このデフォルトはラベルで変更できます：