<div align="center">
<img class="logo" src="https://raw.githubusercontent.com/umputun/reproxy/master/site/logo-bg.svg" width="355px" height="142px" alt="Reproxy | Simple Reverse Proxy"/>
</div>
Reproxyは、さまざまなプロバイダ（docker、static、file、consul catalog）をサポートするシンプルなエッジHTTP(s)サーバー / リバースプロキシです。1つ以上のプロバイダが、リクエストされたサーバー、リクエストURL、宛先URL、ヘルスチェックURLに関する情報を提供します。単一のバイナリまたはdockerコンテナとして配布されます。
- <a href="https://letsencrypt.org/" rel="nofollow noopener noreferrer" target="_blank">Let's Encrypt</a>による自動SSL終端
- ユーザー提供のSSL証明書のサポート
- シンプルかつ柔軟なプロキシルール
- 静的、コマンドラインによるプロキシルールプロバイダ
- 動的なファイルベースのプロキシルールプロバイダ
- 自動検出を備えたDockerプロバイダ
- サービスタグによる検出を備えたConsul Catalogプロバイダ
- 複数の（仮想）ホストのサポート
- オプションのトラフィック圧縮
- オプションのIPベースのアクセス制御
- ルートごとのBasic認証
- ユーザー定義のサイズ制限とタイムアウト
- 単一バイナリ配布
- Dockerコンテナ配布
- オプションの「SPAフレンドリー」モードを備えた組み込み静的アセットサーバー
- リダイレクトルールのサポート
- 全体のアクティビティおよびユーザーのアクティビティに対するオプションのリミッター
- ライブヘルスチェックとフェイルオーバー/ロードバランシング
- ルート情報とprometheusメトリクスを備えた管理サーバー
- RPC経由のプラグインサポートによるカスタム機能の実装
- Apache Log Formatと簡易stdoutレポートの両方によるオプションのログ出力
---
<div align="center">
[](https://github.com/umputun/reproxy/actions/workflows/ci.yml) [](https://coveralls.io/github/umputun/reproxy?branch=master) [](https://goreportcard.com/report/github.com/umputun/reproxy) [](https://hub.docker.com/r/umputun/reproxy)
</div>
サーバー（ホスト）は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パッケージも提供しています。
- バイナリ配布の場合、[リリースセクション](https://github.com/umputun/reproxy/releases)から適切なファイルをダウンロードしてください
- Homebrewユーザーの場合: `brew install umputun/apps/reproxy`
- Dockerコンテナは[Docker Hub](https://hub.docker.com/r/umputun/reproxy)および[Github Container Registry](https://github.com/users/umputun/packages/container/reproxy/versions)で利用可能です。つまり、`docker pull umputun/reproxy`または`docker pull ghcr.io/umputun/reproxy`です。
最新の安定版には`:vX.Y.Z`というDockerタグ(`:latest`エイリアス付き)が付いており、現在のmasterには`:master`タグが付いています。
## プロバイダー
プロキシルールはさまざまなプロバイダーから提供されます。現在含まれているのは`file`、`docker`、`static`、`consul-catalog`です。各プロバイダーは、プロキシされるリクエストと静的(アセット)の両方に対して複数のルーティングルールを定義できます。ユーザーは複数のプロバイダーを同時に設定できます。
_さまざまなプロバイダーの例は[examples](https://github.com/umputun/reproxy/tree/master/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リクエスト/秒に設定します(それより前の位置フィールドは空のままにします)。
4番目の要素は、ヘルスレポートに使用されるオプションのping URLを定義します。5番目の要素は、ヘルスチェックリクエストのバックエンドへの転送をオプションで有効にします(`true`、`yes`、`1`)。詳細は[ヘルスチェック](#ping-and-health-checks)セクションを参照してください。6番目の要素は、オプションのルートごとのリクエストタイムアウト(Goのduration、例: `5m`、`30s`)です。`0`または空の場合はグローバルな`--timeout.write`設定を継承します。7番目の要素は、オプションのルートごとのユーザーあたりのリクエスト/秒制限です。`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>/<container name>/(.*)` のようなすべてのリクエストを、指定されたコンテナの内部 IP と公開ポートにリダイレクトします。アクティブ（実行中）なコンテナのみが検出されます。
このデフォルトはラベルで変更できます:
- `reproxy.server` - マッチするサーバー（ホスト名）。カンマ区切りのサーバーリストも指定可能です。
- `reproxy.route` - ソースルート（ロケーション）
- `reproxy.dest` - 宛先パス。注意: これは完全な URL ではなく、コンテナの ip:port に追加されるパスのみです
- `reproxy.port` - 検出されたコンテナの宛先ポート
- `reproxy.ping` - 宛先コンテナの ping パス。
- `reproxy.remote` - カンマ区切りのサブネットまたは IP のリストでルートへのアクセスを制限
- `reproxy.auth` - カンマ区切りの `user:bcrypt_hash` ペア（`htpasswd -nbB` で生成）でルートに Basic 認証を要求
- `reproxy.assets` - アセットマッピングを `web-root:location` として設定。例: `reproxy.assets=/web:/var/www`
- `reproxy.keep-host` - ホストヘッダーをそのまま保持（`yes`、`true`、`1`）するか、宛先ホストに置き換え（`no`、`false`、`0`）
- `reproxy.forward-health-checks` - reproxy が処理する代わりに `/ping` および `/health` リクエストをバックエンドに転送（`yes`、`true`、`1`）。バックエンドがアプリケーション固有のレスポンスを持つ独自のヘルスチェックエンドポイントを持っている場合に便利です。
- `reproxy.timeout` - Go の duration 形式でのルートごとのリクエストタイムアウト（例: `5m`、`30s`）。`0` または未設定の場合はグローバルの `--timeout.write` を継承します。無効な値は警告付きで無視されます。
- `reproxy.throttle` - ユーザーごとのルートごとの req/sec 制限。`0` または未設定の場合は `--throttle.user` を継承します。無効または負の値は警告付きで無視されます。
- `reproxy.enabled` - コンテナを reproxy の宛先として有効化（`yes`、`true`、`1`）または無効化（`no`、`false`、`0`）
注意: `--docker.auto` なしの場合、宛先コンテナは潜在的な宛先と見なされるために少なくとも 1 つの `reproxy.*` ラベルを持つ必要があります。
`--docker.auto` 付きの場合、公開ポートを持つすべてのコンテナがルーティング宛先と見なされます。これを制限する方法は 3 つあります:
- `--docker.exclude` で一部のコンテナを明示的に除外する。例: `--docker.exclude=c1 --docker.exclude=c2 ...`
- `--docker.network` で特定の Docker ネットワークのみを許可する
- ラベル `reproxy.enabled=false` または `reproxy.enabled=no` または `reproxy.enabled=0` を設定する
`reproxy.route` が定義されていない場合、デフォルトルートは `^/<container_name>/(.*)` です。プロキシされるすべてのソースが同じプレフィックスパターンを持つ必要がある場合、例えば `/api/(.*)` の場合、ユーザーはすべてのコンテナベースのルートに対して共通プレフィックス（この場合は `/api`）を定義できます。これは `--docker.prefix` パラメータで行えます。
Docker プロバイダーは、同じコンテナ上で複数の異なるルートにマッチするために、複数セットの `reproxy.N.something` ラベルを定義することもできます。これは、単一のコンテナが複数のエンドポイント（例えば、パブリック API と管理 API）を公開する場合に便利です。上記のすべてのラベルは「N インデックス」付きで使用できます。つまり、`reproxy.1.server`、`reproxy.1.port` などです。N は 0 から 9 の範囲である必要があります。
これは動的プロバイダーであり、コンテナのステータスの変更は自動的に適用されます。
### Consul Catalog プロバイダー
使用法: `reproxy --consul-catalog.enabled`
Consul Catalog プロバイダーは、`reproxy.` プレフィックスを持つタグを持つサービスを取得するために、Consul API を定期的（デフォルトでは毎秒）に呼び出します。ユーザーは `--consul-catalog.interval` コマンドラインフラグでチェック間隔を、`--consul-catalog.address` コマンドラインオプションで Consul アドレスを再定義できます。デフォルトのアドレスは `http://127.0.0.1:8500` です。
例:
```
reproxy --consul-catalog.enabled --consul-catalog.address=http://192.168.1.100:8500 --consul-catalog.interval=10s
```
デフォルトでは、プロバイダーはすべてのサービスに以下の値を設定します:
- enabled `false`
- server `*`
- route `^/(.*)`
- dest `http://<SERVICE_ADDRESS_FROM_CONSUL>/$1`
- ping `http://<SERVICE_ADDRESS_FROM_CONSUL>/ping`
このデフォルト値はタグで変更できます:
- `reproxy.server` - マッチするサーバー (ホスト名)。カンマ区切りのサーバーリストも指定可能です。
- `reproxy.route` - ソースルート (ロケーション)
- `reproxy.dest` - 宛先パス。注意: これは完全な URL ではなく、サービスの ip:port に追加されるパスのみです
- `reproxy.port` - 検出されたサービスの宛先ポート
- `reproxy.remote` - カンマ区切りのサブネットまたは IP のリストでルートへのアクセスを制限します
- `reproxy.auth` - カンマ区切りの `user:bcrypt_hash` ペア (`htpasswd -nbB` で生成) でルートにベーシック認証を要求します
- `reproxy.ping` - 宛先サービスの ping パス。
- `reproxy.forward-health-checks` - `/ping` および `/health` リクエストをバックエンドに転送します (`true`、`yes`、`1`)。
- `reproxy.timeout` - ルートごとのリクエストタイムアウトを Go の duration で指定します (例: `5m`、`30s`)。`0` または未設定の場合はグローバルの `--timeout.write` を継承します。無効な値は警告とともに無視されます。
- `reproxy.throttle` - ルートごとのユーザーあたりの req/sec 制限。`0` または未設定の場合は `--throttle.user` を継承します。無効または負の値は警告とともに無視されます。
- `reproxy.enabled` - reproxy の宛先に対してサービスを有効化 (`yes`、`true`、`1`) または無効化 (`その他の値`) します。
### Compose 固有の詳細
docker compose の環境の一部としてルールを設定する場合、正規表現グループを含む宛先は compose の構文と競合します。つまり、compose 環境で `https://api.example.com/$1` を使用しようとすると、構文エラーにより失敗します。ここでの標準的な解決策は、`$` 記号を `$$` に置き換えて「エスケープ」することです。つまり `https://api.example.com/$$1` とします。この置換は docker compose によってサポートされており、reproxy 自体とは関係ありません。もう一つの方法は、reproxy レベルでサポートされている `$` の代わりに `@` を使用することです。つまり `https://api.example.com/@1`_
## SSL サポート
SSL モード (デフォルトは none) は、`auto` (ACME/LE 証明書)、`static` (既存の証明書)、または `none` に設定できます。`auto` が有効な場合、検出されたすべてのサーバー名に対して SSL 証明書が自動的に発行されます。ユーザーは `--ssl.fqdn` の値を設定することでこれを上書きできます。`auto` および `static` SSL モードでは、Reproxy は自動的に `X-Forwarded-Proto` および `X-Forwarded-Port` ヘッダーを追加します。これらのヘッダーは、プロキシの背後にあるサービスが、クライアントが使用した元のプロトコル (http または https) とポート番号を認識するのに役立ちます。
検出プロバイダー (docker、file、consul) で ACME を使用する場合、SSL 証明書は reproxy の再起動を必要とせずに、新しく検出されたサーバーに対して自動的に取得されます。
### ACME チャレンジ
Reproxy は SSL 証明書の検証のために 2 種類の ACME チャレンジをサポートしています:
1. **HTTP-01 チャレンジ** (デフォルト): 特定の HTTP URL でトークンを提供することでドメインの所有権を検証します。ポート 80 が公開アクセス可能である必要があります。
2. **DNS-01 チャレンジ**: DNS TXT レコードを作成することでドメインの所有権を検証します。この方法は:
- ポート 80 へのアクセスを必要としません
- ワイルドカード証明書で動作します
- サポートされている DNS プロバイダーの設定が必要です
#### チャレンジの選択
Reproxy は設定に基づいて使用するチャレンジ方法を自動的に決定します:
- **HTTP-01** (デフォルト): DNS プロバイダーが設定されていない場合に使用されます
- **DNS-01**: DNS プロバイダーが設定されている場合に使用されます
チャレンジタイプを明示的に選択する必要はありません。DNS-01 チャレンジを使用したい場合は、DNS プロバイダーを設定するだけです。
DNS 伝播チェックはデフォルトで 2 分後にタイムアウトします。チャレンジレコードの公開が遅いゾーンでは、`--ssl.dns.propagation-timeout=5m` でこの時間を延長してください。`--ssl.dns.ttl` オプションはレコードの TTL を制御するものであり、伝播タイムアウトを変更するものではありません。
#### 現在サポートされている DNS プロバイダー
Reproxy は現在、以下の DNS プロバイダーをサポートしています:
- **Cloudflare**: `--ssl.dns.type=cloudflare --ssl.dns.cloudflare.api-token=TOKEN`
- **Route53 (AWS)**: `--ssl.dns.type=route53 --ssl.dns.route53.region=REGION --ssl.dns.route53.hosted-zone-id=ID`
- **Gandi**: `--ssl.dns.type=gandi --ssl.dns.gandi.bearer-token=TOKEN`
- **DigitalOcean**: `--ssl.dns.type=digitalocean --ssl.dns.digitalocean.api-token=TOKEN`
- **Hetzner**: `--ssl.dns.type=hetzner --ssl.dns.hetzner.api-token=TOKEN`
- **Linode**: `--ssl.dns.type=linode --ssl.dns.linode.api-token=TOKEN`
- **GoDaddy**: `--ssl.dns.type=godaddy --ssl.dns.godaddy.api-token=TOKEN`
- **Namecheap**: `--ssl.dns.type=namecheap --ssl.dns.namecheap.api-key=KEY --ssl.dns.namecheap.user=USER`
- **Scaleway**: `--ssl.dns.type=scaleway --ssl.dns.scaleway.secret-key=KEY --ssl.dns.scaleway.organization-id=ID`
- **Porkbun**: `--ssl.dns.type=porkbun --ssl.dns.porkbun.api-key=KEY --ssl.dns.porkbun.api-secret-key=SECRET`
- **DNSimple**: `--ssl.dns.type=dnsimple --ssl.dns.dnsimple.api-access-token=TOKEN --ssl.dns.dnsimple.account-id=ID`
- **DuckDNS**: `--ssl.dns.type=duckdns --ssl.dns.duckdns.api-token=TOKEN`
DNSプロバイダーとしてCloudflareを使用する例:
```
export CLOUDFLARE_API_TOKEN=your_api_token
reproxy --ssl.type=auto [email protected] --ssl.fqdn=example.com
```
DNS-01 チャレンジは、次のような場合に特に有用です：
- サーバーがポート 80 を公開していない場合
- ワイルドカード証明書（例：*.example.com）が必要な場合
- 制限の厳しいファイアウォールの内側にある場合
## ヘッダー
Reproxy では、`--drop-header` パラメータ（繰り返し指定可能）を渡すことで、受信ヘッダーをサニタイズ（削除）できます。このパラメータは、サービスが内部的に設定する一部のヘッダーがエンドユーザーによって設定・偽装されないようにするために役立ちます。例えば、認証を担当するサービスが `X-Auth-User` と `X-Auth-Token` を設定している場合、`--drop-header=X-Auth-User --drop-header=X-Auth-Token` パラメータを渡すか、環境変数 `DROP_HEADERS=X-Auth-User,X-Auth-Token` を介して、受信リクエストからこれらのヘッダーを削除するのが理にかなっている可能性が高いです。
逆の機能として、送信ヘッダーの設定もサポートされています。これは多くの場合に役立ち、例えばカスタム CORS ルールやセキュリティ関連のヘッダーなどを強制するのに使えます。これは `--header` パラメータ（繰り返し指定可能）または環境変数 `HEADER` で行えます。例えば、docker compose を使った場合は次のように行えます：
```yaml
environment:
- HEADER=
X-Frame-Options:SAMEORIGIN,
X-XSS-Protection:1; mode=block;,
Content-Security-Policy:default-src 'self'; style-src 'self' 'unsafe-inline';
```
## ログ記録
デフォルトではリクエストログは生成されません。これは `--logger.enabled` を設定することで有効にできます。ログ（自動ローテーション）は [Apache Combined Log Format](http://httpd.apache.org/docs/2.2/logs.html#combined) です。
ユーザーは `--logger.stdout` で標準出力ログも有効にできます。これは上記のファイルログには影響しませんが、処理されたリクエストに関する最小限の情報を出力します。例えば次のようになります:
```
2021/04/16 01:17:25.601 [INFO] GET - /echo/image.png - xxx.xxx.xxx.xxx - 200 (155400) - 371.661251ms
2021/04/16 01:18:18.959 [INFO] GET - /api/v1/params - xxx.xxx.xxx.xxx - 200 (74) - 1.217669m
```
## アセットサーバー
ユーザーは静的ファイルを配信するためにアセットサーバーを有効にできます（デフォルトではオフ）。`--assets.location` が設定されている限り、`assets.root` 配下のプロキシされないすべてのリクエストを静的ファイルへのリクエストとして扱います。アセットサーバーはプロキシプロバイダーなしでも使用できます。このモードでは、reproxy は静的コンテンツのためのシンプルな Web サーバーとして動作します。アセットサーバーは「spa モード」もサポートしており、`--assets.spa` を指定すると、見つからないすべてのリクエストが `index.html` に転送されます。
共通のアセットサーバーに加えて、複数のカスタムアセットサーバーがサポートされています。各プロバイダーはこのような静的ルールを定義する方法が異なり、プロバイダーによってはまったくサポートしていない場合もあります。たとえば、複数のアセットサーバーは static（コマンドラインプロバイダー）、file プロバイダーで意味があり、docker プロバイダーでも有用ですが、consul catalog プロバイダーではほとんど意味がありません。
1. static プロバイダー - ソース要素の先頭に `assets:` または `spa:` が付いている場合、ファイルサーバーとして扱われます。たとえば `*,assets:/web,/var/www,` は、`/web/*` へのすべてのリクエストを `/var/www` ディレクトリ上のファイルサーバーで配信します。
2. file プロバイダー - オプションフィールド `assets: true` または `spa: true` を設定します。注意: `route` フィールドはパスプレフィックス（例: `/`、`/web/`）である必要があり、正規表現パターンではありません。
3. docker プロバイダー - `reproxy.assets=web-root:location`、つまり `reproxy.assets=/web:/var/www`。spa モードへの切り替えは `reproxy.spa` を `yes` または `true` に設定することで行います。
### キャッシュ
アセットサーバーは `--assets.cache=<duration>` パラメーターでキャッシュ制御をサポートしています。`0s` の期間（デフォルト）はキャッシュ制御をオフにします。期間は 10 進数のシーケンスで、それぞれにオプションの小数部と単位の接尾辞が付きます（例: "300ms"、"1.5h"、"2h45m"）。有効な時間単位は "ns"、"us"（または "µs"）、"ms"、"s"、"m"、"h"、"d" です。
キャッシュ期間を設定する方法は 2 つあります:
1. すべての静的アセットに単一の値。これは `--assets.cache=48h` のように簡単です。
2. 異なる MIME タイプごとのカスタム期間。これには 2 つの部分が含まれます - デフォルト値と mime:duration のペアです。コマンドラインでは複数の `--assets.cache` オプションとして指定します（例: `--assets.cache=48h --assets.cache=text/html:24h --assets.cache=image/png:2h`）。環境変数の値はカンマ区切りにする必要があります（例: `ASSETS_CACHE=48h,text/html:24h,image/png:2h`）。
カスタム 404（not found）ページは `--assets.not-found=<path>` パラメーターで設定できます。パスはアセットルートからの相対パスである必要があります。
## reproxy をベースイメージとして使用する
純粋に静的コンテンツを配信することは、人気のあるユースケースの 1 つです。通常、これは UI のみを提供する独立したフロントエンドコンテナに使用されます。アセットサーバーを使えば、そのようなコンテナはほぼ簡単に作成できます。これは [reproxy.io](http://reproxy.io) を配信するコンテナの例です
```docker
FROM node:22-alpine as build
WORKDIR /build
COPY site/ /build
COPY README.md /build/src/index.md
RUN yarn --frozen-lockfile
RUN yarn build
RUN ls -la /build/public
FROM ghcr.io/umputun/reproxy
COPY --from=build /build/public /srv/site
EXPOSE 8080
USER app
ENTRYPOINT ["/srv/reproxy", "--assets.location=/srv/site"]
```
必要なのは、静的アセットを任意の場所にコピーし、その場所を `"--assets.location` として reproxy のエントリポイントに渡すだけです。
## SPA フレンドリーモード
一部の SPA アプリケーションは、静的アセットの 404 をプロキシが特別な方法で処理し、"/index.html" にリダイレクトすることを前提としています。これは nginx の `try_files $uri $uri/ …` ディレクティブに似ており、どうやらこの機能はモダンな Web アプリにとってある程度重要なようです。
このモードはデフォルトでオフであり、`--assets.spa` を設定するか、環境変数 `ASSETS_SPA=true` を指定することで有効にできます。
## リダイレクト
デフォルトでは、reproxy は宛先をプロキシのロケーションとして扱います。つまり、内部的に http 呼び出しを行い、レスポンスをクライアントに返します。しかし、宛先 URL の先頭に `@code` を付けることで、この動作を恒久的なリダイレクト（ステータスコード 301）または一時的なリダイレクト（ステータスコード 302）に変更できます。つまり、宛先を `@301 https://example.com/something` に設定すると、`Location: https://example.com/something` への恒久的な http リダイレクトが発生します。
サポートされているコード:
- `@301`、`@perm` - 恒久的なリダイレクト
- `@302`、`@temp`、`@tmp` - 一時的なリダイレクト
## その他のオプション
- `--gzip` レスポンスの gzip（または deflate）圧縮を有効にします。判定はレスポンスごとに、その最終的なヘッダーに基づいて行われます:
- `--gzip-exclude` に一致するメディアタイプはそのまま送信されます。値は完全な型（`image/png`）またはプレフィックス（`audio/*`）のカンマ区切りリストです。デフォルトではオーディオ、ビデオ、圧縮画像（jpeg、png、gif、webp、avif）、woff フォント、一般的なアーカイブをスキップします。カスタムリストはデフォルトを置き換え、空の値（`--gzip-exclude=`）は除外を無効にします。
- 部分レスポンス（`206`、または `Content-Range` を持つレスポンス）は決して圧縮されないため、`Range` リクエストは引き続き機能します。
---
[Read more](https://github.com/umputun/reproxy)
