Skip to content
このページは AI で翻訳されており、不正確な表現が含まれる場合があります。GitHub で改善にご協力ください。

Web サービス ​

ドメインごとにリバースプロキシ、リダイレクト、静的ファイル、固定テキストを提供する、Gately 共通の Web 入口です。メニューの場所:サイドバーの「Web → Web サービス」。

構成:リスナー、サイト、デフォルトサイト ​

設定は 3 層で構成されます。

  1. リスナー:待ち受けポート 1 つ。フィールドは、ネットワーク(tcp デュアルスタック、tcp4、tcp6)、待ち受けアドレス(空欄ですべてのアドレス)、ポート、HTTPS スイッチ、最低 TLS バージョン(1.0 / 1.1 / 1.2 / 1.3)、PROXY プロトコルを受信するかどうかです。
  2. サイト:リスナーの配下で、ドメインに一致する 1 つのサイト。ドメインには、完全一致のドメイン、*.example.com(任意の階層のサブドメインに一致)、*(すべてに一致)を指定できます。一致の優先順位は、完全一致、ワイルドカード、* の順です。
  3. デフォルトサイト:一致するサイトがないときに使われます。無効の場合は 404 を返します。

サイトまたはデフォルトサイトの変更を保存すると、サイトの一覧がその場で入れ替わります。リスナーは動き続け、開いている接続(WebSocket を含む)は維持され、各サイトの統計も引き継がれます。新しい設定が無効な場合は、以前のサイトが引き続き配信されます。リスナー自体の設定(ネットワーク、アドレス、ポート、HTTPS、最低 TLS バージョン、HTTP/3、PROXY プロトコル)を変更すると、そのリスナーが再起動します。

サイトの種類 ​

種類説明
リバースプロキシ1 つ以上のバックエンドに転送します。バックエンドのアドレス形式は http(s)://ホスト:ポート で、WebSocket に対応しています
リダイレクト完全な URL へ転送します。ステータスコードは 301 / 302 / 307 / 308(デフォルトは 302)で、元のパスとクエリ文字列を保持することもできます。URL には {host} を含められ、訪問者が使ったドメインに置き換えられます。https://{host} に「パスとパラメーターを保持」を組み合わせると、すべての HTTP リクエストを同じドメインの HTTPS に転送できます
静的ファイルディレクトリは絶対パスで指定します。「ディレクトリ一覧」を無効にすると、ディレクトリへのリクエストは index.html がある場合にのみ返されます。「拡張子なし URL」は、ファイルが見つからないときに パス.html と パス/index.html を試します(VitePress などの生成ツール向けで、nginx の try_files $uri $uri.html $uri/index.html に相当)。「404 ページ」はディレクトリ内のパス(例:404.html)で、ステータス 404 で返されます
固定テキスト任意の内容、Content-Type(デフォルトは text/plain; charset=utf-8)、ステータスコード(100-599、デフォルトは 200)を指定します

リバースプロキシサイトのその他のオプション:

  • Host にバックエンドのアドレスを使用:Host ヘッダーをバックエンドのアドレスに書き換えます。無効にすると、クライアントがリクエストした Host を保持します。
  • バックエンドの証明書検証をスキップ、Keep-Alive を無効化。
  • バックエンドへ PROXY プロトコルを送信(v2 ヘッダーで実際のクライアント IP を渡します。バックエンド側の対応が必要です)。
  • X-Forwarded-For / X-Forwarded-Proto / X-Forwarded-Host / X-Forwarded-Port と X-Real-IP を付与。
  • アクセス先ドメインを SNI に使う(HTTPS バックエンドのみ):ハンドシェイクで訪問者が使ったドメインを送り、そのドメインに対して証明書を検証します。nginx の proxy_ssl_server_name on; proxy_ssl_name $host に相当します。バックエンドが SNI で振り分ける場合(たとえば frp の vhost_https)にオンにしてください。バックエンドごとに独自の接続プールを持つため、ドメイン間で接続が再利用されることはありません。

どの種類のサイトでも、アクセスログ、クロスオリジン(CORS)、カスタムのリクエストヘッダーとレスポンスヘッダー(1 行に Key: Value。Value を空にするとそのヘッダーを削除)を設定でき、WAF ファイアウォール のインスタンスを 1 つ参照することもできます(インスタンスが存在しない、または無効の場合はそのまま通します)。

トランスポートとプロトコル ​

  • HTTPS:SSL 証明書 モジュールで、そのドメインをカバーする証明書が使われます。
  • HTTP/3(QUIC):HTTPS を有効にしたリスナーでオンにすると、同じポート番号の UDP でも HTTP/3 を提供し、Alt-Svc レスポンスヘッダーでブラウザに通知します。ファイアウォールとポートマッピングでその UDP ポートを許可する必要があります。
  • WebSocket:リバースプロキシで自動的に対応します。
  • PROXY プロトコル:リスナーは上流(haproxy、frp など)から送られる PROXY ヘッダーを受信できます。信頼するのは「全体設定 → 信頼する PROXY 送信元」に挙げた IP またはセグメントだけで、空欄の場合はどの送信元も信頼しません。リバースプロキシはバックエンドへ PROXY ヘッダーを送信することもできます。

認証 ​

サイト編集ダイアログの「セキュリティ」タブで設定します。

  • Web 認証:ブラウザにログインページを表示します。
  • Basic 認証:HTTP Basic。
  • ユーザー:1 行に ユーザー名:パスワード。パスワードには bcrypt ハッシュも指定できます。Basic 認証を有効にするには少なくとも 1 人のユーザーが必要で、Web 認証を有効にするには少なくとも 1 人のユーザーまたは外部ログインの ID が必要です。
  • 外部ログイン:GitHub、Google、QQ、OIDC に対応し、自分の OAuth アプリを使います。許可する ID は 1 行に 1 件、形式は プロバイダー識別子:アカウント で、たとえば github:octocat、google:me@gmail.com のように書き、行末に # に続けてメモを付けられます。github:* はそのプロバイダーの任意のアカウントを表します。

外部ログインのプロバイダーは「全体設定」で設定します。自分の Client ID / Secret を入力して有効にし、同時にコールバックアドレスを設定してください(Gately のいずれかのリスナーで提供される必要があります。例:https://auth.example.com)。GitHub / Google / QQ に登録するコールバック URL は次のとおりです。

text
https://auth.example.com/__gately_auth/oauth/callback

管理画面自体の外部ログインは、「設定 → アカウントとセキュリティ」で別途設定します。

フォワード認証(Authelia など) ​

認証を外部サービスに任せます。nginx の auth_request や Traefik の forwardAuth と同じ仕組みです。「セキュリティ」タブで「フォワード認証」にチェックを入れます。同じサイトで Basic 認証や Web 認証と併用することはできません。

フィールド説明
urlチェック用のエンドポイント。Authelia の http://127.0.0.1:9091/api/authz/auth-request など
loginUrlエンドポイントが 401 を返したときに訪問者を送る先。例:https://auth.example.com/?rd={url}&rm={method}。{url} は元のアドレス(URL エンコード済み)、{method} はリクエストメソッドです。空の場合は、エンドポイントの応答をそのまま返します
copyHeadersエンドポイントの応答からバックエンドへのリクエストにコピーする ID ヘッダー。デフォルトは Remote-User、Remote-Groups、Remote-Email、Remote-Name

仕組み:

  • すべてのリクエストは、まず url に本文なしの GET として送られます。訪問者のヘッダー(Cookie、Authorization など)に加えて、X-Original-Method、X-Original-URL、X-Forwarded-Method、X-Forwarded-Proto、X-Forwarded-Host、X-Forwarded-Uri、X-Forwarded-For、X-Real-Ip が付きます。タイムアウトは 10 秒です。
  • 2xx の応答ならリクエストを通し、ID ヘッダーを付与します。401 は loginUrl へリダイレクトします(ステータス 302)。403 やリダイレクトなどそれ以外の応答は訪問者にそのまま返し、サービスに到達できない場合は 502 になります。
  • 訪問者が送った ID ヘッダーは常に削除されるため、偽装できません。
  • パスルールと「認証の対象範囲」に対応しているため、一部のパス(例:/admin)だけログインを必須にできます。一時共有リンクとも併用できます。

共有ユーザー:TOTP とシングルサインオン ​

アカウントを一度定義すれば複数のサイトで使え、TOTP による 2 段階認証も任意で追加できます。多くの人が Authelia を使う目的をカバーします。

「全体設定 → 共有ユーザー」で次を設定します。

  • ユーザーを追加するには、ユーザー名とパスワードを入力します。パスワードは bcrypt ハッシュで保存され、API から返されることはありません。TOTP を追加するには、「TOTP を有効化」を押し、認証アプリ(Google Authenticator、1Password など)で QR コードを読み取って保存します。キーを再生成すると、古いキーは無効になります。
  • SSO ドメイン(例:example.com):そのドメインまたはサブドメインのいずれかのサイトでログインすると、そこにある他のサイトでは再ログインが不要になります。親ドメインの Cookie(gately_sso、有効期間 7 日)を使い、この Cookie はバックエンドには転送されません。空にすると、サイトごとに個別にログインします。

サイトでは、Web 認証または Basic 認証の横にある「共有ユーザーを使う」にチェックを入れます。サイト独自のユーザーも引き続き使えます。

動作:

  • 共有ユーザーのいずれかが TOTP を使っている場合、ログインページに認証コードの入力欄が表示されます。各コードは 1 回だけ使えます。
  • ユーザーのパスワードまたは TOTP キーを変更すると、そのユーザーのセッションは終了します。
  • Basic 認証で使えるのは、TOTP のない共有ユーザーだけです。ブラウザのパスワード入力画面にはコードを入力する場所がないためです。
  • 失敗した試行は、他のログインと同じレート制限と自動ブロックの対象になります。

アクセス制御 ​

IP のブラックリスト・ホワイトリスト ​

サイトの「セキュリティ」タブにある「IP アクセス制御」では、オフ、許可リスト、拒否リストを選べます。リストは 1 行に 1 つの IP またはセグメント(例:192.168.1.0/24)を書きます。購読 IP リストもあわせて参照できます。

購読 IP リスト ​

「全体設定 → 購読 IP リスト」でリストを追加します。ダウンロード URL と更新間隔(既定は 24 時間)を入力すると、Gately が定期的にダウンロードして設定ディレクトリにキャッシュするため、再起動後もネットワークに接続せずに使えます。内容は 1 行に 1 つの IP、CIDR、または 開始-終了 の範囲で、#、;、// 以降はコメントです。たとえば中国の省・市の IP 範囲には metowolf/iplist の https://metowolf.github.io/iplist/data/cncity/440000.txt(広東省)が使えます。

  • サイトとパスルールの許可リスト・拒否リストは複数のリストを参照でき、手入力した IP 範囲と合わせて判定し、いずれかに一致すればリスト内とみなします。
  • ダウンロードした内容を解析できない場合(エラーページが返された場合など)は前回のリストを保持し、リストに理由を表示して 1 時間後に再試行します。
  • ダウンロードが成功するまでは空のリストとして扱います。そのため許可リストではアクセスが拒否され、拒否リストでは追加のブロックは行われません。
  • サイトから参照されているリストは削除できません。

パスルール ​

「セキュリティ」タブの「パスルール」では、パスの接頭辞ごとにサイトの認証と IP の設定を上書きできます。

フィールド値
prefix/ で始まるパスの接頭辞。例:/admin
authサイトの設定を引き継ぐ(空)、off(認証不要)、on(認証必須)
ipMode / ipListサイトの設定を引き継ぐ(空)、whitelist、blacklist。あわせて IP またはセグメントのリストを指定

一致のルール:

  • 最も長い接頭辞が優先されます。
  • パスセグメントの境界で照合されます。/admin は /admin と /admin/x に一致し、/administrator には一致しません。
  • リクエストパスは先に正規化(.、..、重複したスラッシュを除去)してから照合され、/public/../admin は /admin として扱われます。
  • 同じ接頭辞には 1 つのルールしか設定できません。

「認証範囲」オプション(authOptional):チェックを入れると、認証は「認証必須」とされたルールのパスにのみ適用され、それ以外のパスは公開されます。このオプションを使うには、先に Basic 認証または Web 認証を有効にする必要があります。

一時共有リンク ​

Basic 認証または Web 認証を有効にすると、サイトに共有リンクを作成して、アカウントのないゲストにアクセスさせることができます。

フィールド説明
名前メモ用の名前。例:「張さん用」
有効期限空欄で無期限
利用回数 maxUses引き換えられる最大回数。0 で無制限。再起動するとカウントはリセットされます
パス制限 pathPrefix空でない場合、リンクはこの接頭辞配下のパスにしかアクセスできません。/ で始める必要があります

ゲストが https://ドメイン/任意のパス?_gs=トークン にアクセスすると、セッションに引き換えられます。引き換えに成功すると、サーバーはログイン不要の Cookie を設定し、_gs パラメーターを除いたアドレスへリダイレクトします。セッションは最長 24 時間で、リンクの有効期限を超えることはありません。トークンが無効な場合は通常のアクセスとして扱われ、失敗の理由は明かされません。リンクを削除すると、発行済みのセッションは直ちに無効になります。トークンは保存後に生成され(16 文字以上)、画面から完全なリンクをコピーできます。

認証失敗のレート制限と自動ブロック ​

  • 同じ送信元 IP が 15 分間に 10 回認証に失敗すると、しばらく試行が拒否されます。
  • 「全体設定 → 自動ブロック → 認証失敗によるブロック」に分数(0 〜 43200)を入力すると、10 回失敗した時点で送信元 IP をブロックします。0 の場合はブロックせず、レート制限のみです。
  • 自動ブロックが発動すると AuthBanned イベントが発行され、通知センター から通知できます。
  • IPv6 アドレスは /64 セグメント単位で集計・ブロックされます。

ブロックリスト ​

「全体設定」のブロックリストには、現在ブロックされている IP、理由(認証の連続失敗または手動ブロック)、期限が表示され、「解除」を押せます。手動でブロックすることもでき、IP と時間数(1 〜 720、最長 30 日)を入力します。API のデフォルトは 24 時間です。

ブロック一覧は侵入防御と共通です。侵入防御モジュールが有効な場合、ここにはブロック件数だけが表示され、侵入防御のページで管理します。ブロックはポート転送や STUN などにも適用され、ファイアウォール同期がオンならシステムファイアウォールで破棄されます。「LAN アドレスを無視」がオンなら LAN のアドレスは自動でブロックされません。

GeoIP による国フィルター ​

サイトの「国フィルター」には、オフ、許可のみ、拒否の 3 つのモードがあり、2 文字の ISO 国コードをカンマ区切りで入力します(例:CN, HK, US)。有効にするには少なくとも 1 か国を入力します。

  • フィルターは GeoIP データベースに依存するため、先に「全体設定 → GeoIP データベース」でインポートします。.mmdb ファイルをアップロードするか、ダウンロード URL を入力してください。MaxMind GeoLite2、DB-IP などの国データベースまたは都市データベースに対応しており、アップロードの上限は 129 MB です。
  • データベースが読み込まれていない場合、フィルターは機能せず(すべての訪問者を通します)、画面に通知が表示されます。
  • LAN 内のアドレスは常に通します。
  • 「拒否」モードでは、データベースで国が引けないアドレスは通します。

パス別バックエンド ​

リバースプロキシサイトで、パスの接頭辞ごとに別のバックエンドへリクエストを振り分けます。nginx の location /api/ { proxy_pass ...; } に相当します。サイト編集ダイアログの「基本」タブにある「パス別バックエンド」で追加します。

フィールド説明
prefix/api/ のようなパスの接頭辞。パスセグメントの境界で照合され、/api と /api/ はどちらも /api と /api/x に一致し、/apix には一致しません
targetsこのパスのバックエンド。サイトのバックエンドと同じ書き方です。空の場合はサイトのバックエンドを使い、下のヘッダーだけを追加します
requestHeadersこのパスで追加するリクエストヘッダー。1 行に Key: Value。サイトのヘッダーの後に適用され、同名のヘッダーはサイトの設定を上書きします
  • 最も長い接頭辞が優先され、パスはそのまま転送されます(接頭辞は取り除かれません)。
  • Host オプション、証明書の検証、転送ヘッダー、PROXY プロトコル、負荷分散ポリシー、ヘルスチェックなど、サイトのその他の設定はすべてのパス別バックエンドに適用されます。
  • 圧縮、レート制限、キャッシュ、書き換えはサイト全体に適用されます。

リバースプロキシの拡張機能 ​

以下のオプションは、サイト編集ダイアログの「トラフィック」タブにあります。

バックエンド、重み、バックアップ ​

バックエンドのリストは 1 行に 1 アドレスで、アドレスの後ろにパラメーターを付けられます。

text
http://10.0.0.2:8080 weight=3
http://10.0.0.3:8080 backup
  • weight=N:重み。1 〜 100 の整数で、デフォルトは 1 です。
  • backup:バックアップのバックエンド。バックアップ以外のバックエンドがすべて利用できないときにのみ使われます。すべてのバックエンドが利用できない場合は、バックアップ以外のすべてのバックエンドに戻って試行を続けます。

ロードバランシングポリシー ​

画面のオプションlbPolicy説明
ラウンドロビン(重み付き)空デフォルト
ランダム(重み付き)random
IP ハッシュ(セッション維持)ip_hash同じクライアント IP は同じバックエンドに振り分けられます
最小接続数least_conn「接続数 / 重み」が最小のものを選びます

ヘルスチェック ​

アクティブチェックのスイッチはデフォルトでオフです。有効にしたときのフィールドとデフォルト値:

フィールドデフォルト値範囲
方式 modehttphttp(チェックパスにリクエストし、ステータスコードが 400 未満なら正常とみなす)または tcp(接続のみテスト)
パス path// で始まる。http 方式のみ
間隔 interval10 秒1 〜 3600
タイムアウト timeout3 秒1 〜 60
連続失敗 fails3 回で利用不可と判定1 〜 20
連続成功 passes2 回で復帰1 〜 20

バックエンドへの PROXY プロトコル送信を有効にしている場合、HTTP チェックは自動的に TCP に切り替わります。

パッシブチェックは常に有効です。複数のバックエンドのうち、接続に 3 回連続で失敗したものは 30 秒間停止してから再度試されます(バックエンドが 1 つだけでアクティブチェックを有効にしていない場合は切り離しません)。アクティブチェックを有効にすると、復帰はチェック結果のみで決まります。バックエンドの状態が変化すると、上流の利用不可 / 復帰イベントが発行され、通知センター から通知できます。

圧縮 ​

リバースプロキシ、静的ファイル、固定テキストのサイトで圧縮を有効にできます(リダイレクトサイトを除く)。Accept-Encoding に応じて br を優先し、次に gzip を選びます。

  • 圧縮の対象はテキスト系のコンテンツのみです:text/*、JSON、JavaScript、XML、XHTML、RSS / Atom、WebAssembly、SVG。text/event-stream は除外されます。
  • 宣言された Content-Length が 256 バイト未満のレスポンスは、そのまま返します。
  • すでに Content-Encoding があるレスポンスは、そのまま返します。WebSocket のアップグレードリクエストはそのまま通します。
  • 圧縮後は、強い ETag が弱い ETag に変更されます。

IP 単位のレート制限 ​

クライアント IP ごとのトークンバケット方式のレート制限です。フィールド:

フィールド説明
rate1 秒あたりに許可するリクエスト数
burstバースト容量。rate を設定して burst が 0 の場合は、rate を整数に丸めて 1 を足した値が自動で使われます
maxConns1 つの IP の同時リクエスト数の上限。0 で無制限

レート制限を有効にする場合、rate と maxConns の少なくとも一方を設定する必要があります。

メモリ上のレスポンスキャッシュ ​

リバースプロキシサイトにのみ適用されます。キャッシュはメモリ上に置かれ、LRU で追い出されます。

フィールドデフォルト値範囲
ttl デフォルトの保持時間00 〜 30 日(秒単位)。上流がキャッシュ指示を宣言していない場合に、200 レスポンスをこの時間だけキャッシュします。0 は、上流が明示的に許可したレスポンスのみキャッシュすることを意味します
maxMb キャッシュ容量641 〜 4096 MB

キャッシュのルール:

  • GET リクエストのみキャッシュされ、リクエストに Authorization、Cookie、Range ヘッダーや Cache-Control: no-cache が含まれていないことが条件です。
  • ステータスコード 200 のレスポンスのみキャッシュされます。レスポンスに Set-Cookie や Vary: * が含まれる場合、または Cache-Control が no-store / private / no-cache の場合は対象外です。
  • s-maxage に従い、次に max-age に従います。
  • 1 エントリーの上限は 4 MB で、かつ総容量の 4 分の 1 を超えません。
  • ヒット時は X-Cache: HIT と Age ヘッダーを返し、ミス時は X-Cache: MISS になります。
  • キャッシュキーには Host、完全なリクエスト URI、Accept-Encoding が含まれます。

パスの書き換えとリダイレクト ​

ルールは順に照合され、最初に一致したものでそれ以降は停止します。

フィールド説明
patternリクエストパスに一致する正規表現。例:^/old/(.*)$
to置換結果。$1 でグループを参照できます
redirectオフは内部書き換え(書き換え後のパスがバックエンドに送られ、宛先は / で始める必要があります)、オンはリダイレクト
codeリダイレクトのステータスコード 301 / 302 / 307 / 308。デフォルトは 302

リダイレクトでは元のクエリパラメーターが保持されます。リダイレクト先には、訪問者が使ったドメインを表す {host} を含められます。リダイレクトのルールは認証より前に実行されます(nginx の location = / { return 302 ...; } と同様)。そのため / のようなパスでは、ログインを求めずに訪問者を別の場所へ送れます。

アクセス統計とモニタリング ​

サイト統計 ​

稼働中のリスナーでは、サイトの行の「統計」を押すと統計ウィンドウが開き、直近 1 時間、6 時間、24 時間を選べます。

  • 分単位のアクセス統計:1 分ごとに 1 点で、直近 24 時間分を保持し、リクエスト数のグラフと 4xx / 5xx エラーのグラフを含みます。
  • ステータスコードの分布(2xx / 3xx / 4xx / 5xx)と、累計のレスポンストラフィック。
  • 送信元 IP のトップ 10 と国別のトップ 10(国別の統計には GeoIP データベースのインポートが必要です)。
  • リバースプロキシサイトでは、各バックエンドのヘルス状態、重み、バックアップかどうか、現在の接続数を表示します。

統計はメモリ上に保持され、再起動またはリスナー自体の設定を変更した後に再集計されます。サイトを編集してもカウンターは維持されます。ランキングは最大 5000 件の異なる送信元まで集計します。

Prometheus メトリクス ​

グローバルなメトリクスのエンドポイント GET /api/metrics はすべてのモジュールのメトリクスを集約しています。監視メトリクス を参照してください。以下のモジュール用エンドポイントには Web サービスのメトリクスのみが含まれます。

メトリクスのエンドポイントは GET /api/webservice/metrics で、Prometheus のテキスト形式です。ログイン認証情報または API トークン が必要です。

bash
curl -H "Authorization: Bearer gtl_xxxx" http://localhost:16680/api/webservice/metrics
メトリクス種類説明
gately_site_requests_totalcounterサイトの累計リクエスト数
gately_site_errors_totalcounterサイトのバックエンドエラー数
gately_site_active_requestsgauge処理中のリクエスト数
gately_site_response_bytes_totalcounter累計レスポンスバイト数
gately_site_responses_totalcounterステータスのクラス(ラベル class:2xx 〜 5xx)別のレスポンス数
gately_upstream_upgaugeバックエンドが正常か。1 が正常、0 が利用不可(ラベル upstream 付き)

すべてのメトリクスにはラベル listener(リスナー名#リスナーの key)と site(サイト名。名前がない場合は最初のドメイン)が付きます。

nginx 設定のインポート ​

ページ上部の「nginx をインポート」で、既存の nginx サイトを Gately のリスナーとサイトに変換できます。nginx のホストで nginx -T を実行し、その出力全体を貼り付けることをおすすめします。出力には include されたすべてのファイルが含まれ、Gately は nginx と同じように include を展開します。

  • まずプレビュー:待ち受けポートごとにグループ化して、各サイトの種類、バックエンドまたはディレクトリ、元のファイルと行番号、注意が必要な点(変数を使ったディレクティブ、正規表現の location、証明書のないドメインなど)を一覧表示します。変換できないサイトにはその理由が表示されます。
  • 同じポートのサイトは既存のリスナーに追加し、それ以外は新しいリスナーを作成します。既存のドメインはスキップされるため、繰り返しインポートできます。
  • 既定では無効の状態でインポートされるため、nginx と並行して 1 つずつ確認してから有効にできます。「インポート後すぐに有効化」にチェックを入れるとすぐに有効になります(nginx が同じポートを使用中の場合、新しいリスナーは起動に失敗します)。
  • 変換できる内容:proxy_pass(upstream の重み、バックアップ、ロードバランシングポリシーを含む)、root / alias の静的ディレクトリ(autoindex、try_files $uri.html、error_page 404)、return によるリダイレクトと固定内容、サイト全体の rewrite リダイレクト、add_header、proxy_set_header、gzip、allow / deny、location 単位のパス別バックエンド・アクセス制御・リダイレクト、listen ... proxy_protocol と quic。
  • auth_request はフォワード認証に変換されます。認証 URL は認証サブリクエストの location の proxy_pass(set 変数に対応)から、ログインのリダイレクト先は error_page 401 =302 から取得するため、Authelia のよくある書き方はそのまま変換できます。一部の location でのみ有効な場合は「認証必須」にしたパスのみ認証する設定に変換されます。
  • auth_basic は共有ユーザーを使う Basic 認証に変換されます。nginx のユーザーファイルは読み込まれないため、ユーザーを追加するまでは誰も認証を通過できません。
  • stream 内の TCP/UDP 転送は ポート転送 で設定してください。証明書はインポートされません。HTTPS サイトに証明書がない場合、プレビューには nginx が使っている証明書ファイルが表示されるので、SSL 証明書 ページでファイルパスから追加できます。

haproxy と nginx の置き換え ​

ポート転送と Web サービスを組み合わせると、haproxy + nginx の構成を置き換えられます。よくある構成は、443 番ポートに SNI 振り分け のルールを 1 つ置き、VPN などの TLS サービスは直接バックエンドへ、それ以外はすべて PROXY プロトコルを受信する Web サービスのリスナーへ送るものです。これに加えて、80 番ポートにリダイレクトサイト(https://{host})を持つ Web サービスのリスナーを置きます。

nginx の設定の置き換え方:

nginxGately
server_name を持つ serverそのドメインを指定したサイト
proxy_pass が異なる locationパス別バックエンド
auth_request(Authelia)フォワード認証、または TOTP 付きの共有ユーザー
proxy_ssl_name $hostアクセス先ドメインを SNI に使う
return 301 https://$host$request_urihttps://{host} と「パスとパラメーターを保持」を指定したリダイレクトサイト
location = / の return 302 /admin「リダイレクト」をオンにした書き換え、パターン ^/$
try_files $uri $uri.html $uri/index.html と error_page 404拡張子なし URL と 404 ページを設定した静的ファイル
add_headerレスポンスヘッダー

デプロイのヒント ​

Web サービスはホストの 80 / 443 などのポートを待ち受ける必要があるため、Docker でデプロイする場合は --network host を推奨します。

Apache-2.0 ライセンスで公開されています。