リクエストマッチャー

リクエストマッチャーは、さまざまな基準でリクエストをフィルタリング（または分類）するために使用できます。

• 構文
  • 例
  • ワイルドカードマッチャー
  • パス マッチャー
  • 名前付きマッチャー
• 標準マッチャー
  • client_ip
  • expression
  • file
  • header
  • header_regexp
  • host
  • method
  • not
  • path
  • path_regexp
  • protocol
  • query
  • remote_ip
  • vars
  • vars_regexp

構文

Caddyfileでは、ディレクティブの直後に続くマッチャートークンは、そのディレクティブのスコープを制限できます。マッチャートークンは、次のいずれかの形式になります。

1. * すべてのリクエストに一致させる（ワイルドカード、デフォルト）。
2. /path スラッシュで始まるリクエストパスに一致させる。
3. @name *名前付きマッチャー*を指定する。

ディレクティブがマッチャーをサポートしている場合、その構文ドキュメントには[<matcher>]と表示されます。マッチャートークンは通常はオプションであり、[ ]で示されます。マッチャートークンが省略された場合は、ワイルドカードマッチャー（*）と同じです。

例

このディレクティブはすべてのHTTPリクエストに適用されます

reverse_proxy localhost:9000

そしてこれは同じです（*はここでは不要です）

reverse_proxy * localhost:9000

ただし、このディレクティブは、パスが/api/で始まるリクエストにのみ適用されます

reverse_proxy /api/* localhost:9000

パス以外のもので一致させるには、名前付きマッチャーを定義し、@nameを使用して参照します

@postfoo {
	method POST
	path /foo/*
}
reverse_proxy @postfoo localhost:9000

ワイルドカードマッチャー

ワイルドカード（または「キャッチオール」）マッチャー*はすべてのリクエストに一致します。マッチャートークンが必要な場合にのみ必要です。たとえば、ディレクティブに指定したい最初の引数がパスでもある場合、パス マッチャーとまったく同じように見えます！そのため、たとえば、ワイルドカードマッチャーを使用してあいまいさを解消できます

root * /home/www/mysite

それ以外の場合、このマッチャーはあまり使用されません。構文で必要ない場合は、省略することをお勧めします。

パス マッチャー

URIパスによる一致は、リクエストを一致させる最も一般的な方法であるため、マッチャーは次のようにインライン化できます

redir /old.html /new.html

パス マッチャートークンは、スラッシュ/で始まる必要があります。

パス マッチングは、デフォルトではプレフィックス一致ではなく、完全一致です。高速プレフィックス一致の場合は、*を追加する必要があります。/foo*は/fooと/foo/、そして`foobar`に一致します。実際には`/foo/*`が必要になる場合があります。

名前付きマッチャー

パスまたはワイルドカードマッチャーではないすべてマッチャーは、名前付きマッチャーである必要があります。これは、特定のディレクティブの外側で定義され、再利用できるマッチャーです。

一意の名前でマッチャーを定義すると、柔軟性が高まり、使用可能なマッチャーをセットに組み合わせることができます

@name {
	...
}

または、セットにマッチャーが1つしかない場合は、同じ行に配置できます

@name ...

その後、ディレクティブの最初の引数として指定することにより、次のようにマッチャーを使用できます

directive @name

たとえば、これはwebsocketリクエストをlocalhost:6001に、他のリクエストをlocalhost:8080にプロキシします。 Connectionという名前のヘッダーフィールドにUpgradeが*含まれ*、かつUpgradeという名前の別のフィールドに正確にwebsocketが含まれるリクエストに一致します

example.com {
	@websockets {
		header Connection *Upgrade*
		header Upgrade    websocket
	}
	reverse_proxy @websockets localhost:6001

	reverse_proxy localhost:8080
}

マッチャーセットが1つのマッチャーのみで構成されている場合は、1行の構文も機能します

@post method POST
reverse_proxy @post localhost:6001

特別な場合として、expression マッチャーは、1つの引用符で囲まれた引数（CEL式自体）がマッチャー名の後に続く限り、名前を指定せずに使用できます

@not-found `{err.status_code} == 404`

ディレクティブと同様に、名前付きマッチャー定義は、それらを使用するサイトブロック内になければなりません。

名前付きマッチャー定義は、*マッチャーセット*を構成します。セット内のマッチャーはANDで結合されます。つまり、すべてが一致する必要があります。たとえば、セットにheaderとpathマッチャーの両方がある場合、両方が一致する必要があります。

同じタイプの複数のマッチャーは、以下のそれぞれのセクションで説明されているように、ブール代数（AND / OR）を使用してマージできます（たとえば、同じセット内の複数のpathマッチャー）。

より複雑なブール一致ロジックの場合は、and &&、or ||、および括弧 ( )をサポートするCEL式を記述するために、expression マッチャーを使用することをお勧めします。

標準マッチャー

マッチャーの完全なドキュメントは、各マッチャモジュールのドキュメントにあります。

リクエストは次の方法で一致させることができます

client_ip

client_ip <ranges...>

expression client_ip('<ranges...>')

クライアントIPアドレス別。正確なIPまたはCIDR範囲を受け入れます。 IPv6ゾーンがサポートされています。

このマッチャーは、trusted_proxiesグローバルオプションが設定されている場合に最適です。そうでない場合は、remote_ipマッチャーと同じように動作します。信頼できるプロキシからのリクエストのみがリクエストの開始時にクライアントIPを解析します。信頼できないリクエストは、直近のピアのリモートIPアドレスを使用します。

ショートカットとして、 `private_ranges`を使用してすべてのプライベートIPv4およびIPv6範囲に一致させることができます。これは、次のすべての範囲を指定するのと同じです。 `192.168.0.0/16 172.16.0.0/12 10.0.0.0/8 127.0.0.1/8 fd00::/8 ::1`

名前付きマッチャーごとに複数の`client_ip`マッチャーを指定でき、それらの範囲はマージされ、ORで結合されます。

例

プライベートIPv4アドレスからのリクエストを一致させる

@private-ipv4 client_ip 192.168.0.0/16 172.16.0.0/12 10.0.0.0/8 127.0.0.1/8

このマッチャーは、notマッチャーと組み合わせて一致を反転させることがよくあります。たとえば、*パブリック* IPv4およびIPv6アドレス（すべてのプライベート範囲の逆）からのすべての接続を中止するには

example.com {
	@denied not client_ip private_ranges
	abort @denied

	respond "Hello, you must be from a private network!"
}

CEL式では、次のようになります

@my-friends `client_ip('12.23.34.45', '23.34.45.56')`

expression

expression <cel...>

trueまたはfalseを返すCEL（Common Expression Language）式を使用します。

Caddy プレースホルダー（またはCaddyfileショートハンド）は、CEL環境によって解釈される前に前処理されて通常のCEL関数呼び出しに変換されるため、これらのCEL式で使用できます。

他のほとんどのリクエストマッチャーも式で関数として使用できます。これにより、式外よりもブールロジックの柔軟性が高まります。 CEL式内でサポートされている構文については、各マッチャーのドキュメントを参照してください。

便宜上、CEL式のみで構成される名前付きマッチャーを定義する場合、マッチャー名を省略できます。 CEL式は引用符で囲む必要があります（バックティックまたはヒアドキュメントを推奨）。これは非常に読みやすいです

@mutable `{method}.startsWith("P")`

この場合、CELマッチャーが想定されます。

例

メソッドが`P`で始まるリクエスト、たとえば`PUT`または`POST`を一致させる

@methods expression {method}.startsWith("P")

ハンドラーがエラー状態コード`404`を返したリクエストを一致させる、handle_errorsディレクティブと組み合わせて使用​​されます

@404 expression {err.status_code} == 404

パスが2つの異なる正規表現のいずれかに一致するリクエストを一致させる。これは、path_regexpマッチャーは通常、名前付きマッチャーごとに1つしか存在できないため、式を使用してのみ記述できます。

@user expression path_regexp('^/user/(\w*)') || path_regexp('^/(\w*)')

または、マッチャー名を省略し、バックティックで囲んで単一トークンとして解析されるようにします

@user `path_regexp('^/user/(\w*)') || path_regexp('^/(\w*)')`

複数行のCEL式を記述するためにヒアドキュメント構文を使用できます

@api <<CEL
	{method} == "GET"
	&& {path}.startsWith("/api/")
	CEL
respond @api "Hello, API!"

file

file {
	root       <path>
	try_files  <files...>
	try_policy first_exist|smallest_size|largest_size|most_recently_modified
	split_path <delims...>
}
file <files...>

expression `file({
	'root': '<path>',
	'try_files': ['<files...>'],
	'try_policy': 'first_exist|smallest_size|largest_size|most_recently_modified',
	'split_path': ['<delims...>']
})`
expression file('<files...>')

ファイル別。

• rootは、ファイルを検索するディレクトリを定義します。デフォルトは、現在の作業ディレクトリ、または設定されている場合はroot 変数（{http.vars.root}）です（rootディレクティブで設定できます）。

• `try_files`は、リスト内の`try_policy`に一致するファイルをチェックします。

  ディレクトリを一致させるには、パスの末尾にスラッシュ` / `を追加します。すべてのファイルパスはサイトルートからの相対パスであり、globパターンが展開されます。

  `try_policy`が`first_exist`（デフォルト）の場合、リストの最後の項目は` = `が前に付いた数値（例： `= 404`）にすることができます。これはフォールバックとして、そのコードでエラーを発生させます。エラーは`handle_errors`でキャッチして処理できます。

• `try_policy`は、ファイルの選択方法を指定します。デフォルトは`first_exist`です。

  • `first_exist`はファイルの存在をチェックします。存在する最初のファイルが選択されます。

  • `smallest_size`は、サイズが最も小さいファイルを選択します。

  • `largest_size`は、サイズが最も大きいファイルを選択します。

  • `most_recently_modified`は、最後に変更されたファイルを選択します。

• `split_path`は、試行する各ファイルパスで見つかったリストの最初の区切り文字でパスを分割します。分割された各値について、区切り文字自体を含む分割の左側は、試行されるファイルパスになります。たとえば、区切り文字`.php`を使用した`/remote.php/dav/`は、ファイル`/remote.php`を試します。各区切り文字は、分割区切り文字として使用するには、URIパスコンポーネントの最後に表示される必要があります。これはニッチな設定であり、主にPHPサイトを提供する場合に使用されます。

`first_exist`のポリシーを持つ`try_files`は非常に一般的であるため、それに対する1行のショートカットがあります

file <files...>

空の file マッチャー（後にファイルがリストされていないもの）は、リクエストされたファイル（URI から逐語的に、サイトルート から相対的に）が存在するかどうかを確認します。これは事実上 file {path} と同じです。

一致すると、4つの新しいプレースホルダーが利用可能になります

• {file_match.relative} ファイルのルート相対パス。これはリクエストを書き換える際に役立ちます。
• {file_match.absolute} 一致したファイルの絶対パス（ルートを含む）。
• {file_match.type} ファイルの種類、file または directory。
• {file_match.remainder} ファイルパスを分割した後に残る部分（split_path が設定されている場合）

例

パスが存在するファイルであるリクエストに一致する

@file file

パスに .html を付けたものが存在するファイルであるリクエスト、またはそうでない場合はパスが存在するファイルであるリクエストに一致する

@html file {
	try_files {path}.html {path} 
}

上記と同じですが、1行のショートカットを使用し、ファイルが見からない場合は404エラーを返す

@html-or-error file {path}.html {path} =404

CEL式 を使用した例をいくつか示します。プレースホルダーはCEL環境によって解釈される前に前処理され、通常のCEL関数呼び出しに変換されるため、ここでは連結が使用されていることに注意してください。さらに、現在の解析の制限により、プレースホルダーと連結する場合は長い形式を使用する必要があります

@file `file()`
@first `file({'try_files': [{path}, {path} + '/', 'index.html']})`
@smallest `file({'try_policy': 'smallest_size', 'try_files': ['a.txt', 'b.txt']})`

header

header <field> [<value>]

expression header({'<field>': '<value>'})

リクエストヘッダーフィールドによる。

• <field> は、チェックするHTTPヘッダーフィールドの名前です。
  • ! が前に付いている場合、フィールドが存在しない場合に一致します（値の引数を省略）。
• <value> は、一致するためにフィールドが持つ必要がある値です。
  • * が前に付いている場合、高速なサフィックスマッチ（末尾に出現）を実行します。
  • * が後ろに付いている場合、高速なプレフィックスマッチ（先頭に出現）を実行します。
  • * で囲まれている場合、高速な部分文字列マッチ（どこにでも出現）を実行します。
  • それ以外の場合、高速な完全一致です。

同じセット内の異なるヘッダーフィールドはAND条件で結合されます。フィールドごとに複数の値はOR条件で結合されます。

ヘッダーフィールドは繰り返される可能性があり、異なる値を持つことに注意してください。バックエンドアプリケーションは、ヘッダーフィールドの値が単一の値ではなく配列であることを考慮する必要があり、Caddyはそのようなあいまいな状況で意味を解釈しません。

例

Connection ヘッダーに Upgrade が含まれるリクエストに一致する

@upgrade header Connection *Upgrade*

Foo ヘッダーに bar または baz が含まれるリクエストに一致する

@foo {
	header Foo bar
	header Foo baz
}

Foo ヘッダーフィールドがまったくないリクエストに一致する

@not_foo header !Foo

CEL式 を使用して、Connection ヘッダーに Upgrade が含まれ、Upgrade ヘッダーが websocket と等しいことをチェックすることにより、WebSocketリクエストに一致させる

@websockets `header({'Connection':'*Upgrade*','Upgrade':'websocket'})`

header_regexp

header_regexp [<name>] <field> <regexp>

expression header_regexp('<name>', '<field>', '<regexp>')
expression header_regexp('<field>', '<regexp>')

header と似ていますが、正規表現をサポートしています。キャプチャグループには、{re.name.capture_group} のような プレースホルダー を介してアクセスできます。ここで、name は正規表現の名前（オプションですが推奨）であり、capture_group は式内のキャプチャグループの名前または番号です。キャプチャグループ 0 は完全な正規表現の一致、1 は最初のキャプチャグループ、2 は2番目のキャプチャグループなどです。

使用される正規表現言語は、Goに含まれるRE2です。RE2構文リファレンス と Go正規表現構文の概要 を参照してください。

ヘッダーフィールドごとに1つの正規表現のみがサポートされています。複数の異なるフィールドはAND条件で結合されます。

例

Cookieヘッダーに login_ の後に16進文字列が含まれ、{re.login.1} でアクセスできるキャプチャグループがあるリクエストに一致する。

@login header_regexp login Cookie login_([a-f0-9]+)

または、CEL式 を使用した同じ例

@login `header_regexp('login', 'Cookie', 'login_([a-f0-9]+)')`

host

host <hosts...>

expression host('<hosts...>')

リクエストの Host ヘッダーフィールドによってリクエストに一致します。

ほとんどのサイトブロックはすでにサイトのアドレスにホストを示しているため、このマッチャーはワイルドカードホスト名を使用するサイトブロック（ワイルドカード証明書パターン を参照）で、ホスト名固有のロジックが必要な場合に、より一般的に使用されます。

複数の host マッチャーはOR条件で結合されます。

例

1つのサブドメインに一致させる

@sub host sub.example.com

Apexドメインとサブドメインに一致させる

@site host example.com www.example.com

CEL式 を使用した複数のサブドメイン

@app `host('app1.example.com', 'app2.example.com')`

method

method <verbs...>

expression method('<verbs...>')

HTTPリクエストのメソッド（動詞）による。動詞は大文字にする必要があります（例：POST）。1つまたは複数のメソッドに一致させることができます。

複数の method マッチャーはOR条件で結合されます。

例

GET メソッドのリクエストに一致する

@get method GET

PUT または DELETE メソッドのリクエストに一致する

@put-delete method PUT DELETE

CEL式 を使用して読み取り専用メソッドに一致させる

@read `method('GET', 'HEAD', 'OPTIONS')`

not

not <matcher>

または、AND条件で結合される複数のマッチャーを否定するには、ブロックを開きます

not {
	<matchers...>
}

囲まれたマッチャーの結果は否定されます。

例

パスが /css/ または /js/ で始まらないリクエストに一致する。

@not-assets {
	not path /css/* /js/*
}

どちらも含まないリクエストに一致する

• /api/ パスプレフィックス、または
• POST リクエストメソッド

つまり、一致するにはこれらのいずれも存在してはなりません

@with-neither {
	not path /api/*
	not method POST
}

両方がないリクエストに一致する

• /api/ パスプレフィックス、かつ
• POST リクエストメソッド

つまり、一致するにはこれらのいずれも存在してはならず、どちらか一方または両方存在してもいけません

@without-both {
	not {
		path /api/*
		method POST
	}
}

このマッチャーには CEL式 がありません。代わりに否定には ! 演算子を使用できるためです。例えば

@without-both `!path('/api*') && !method('POST')`

これは、括弧を使用した場合と同じです

@without-both `!(path('/api*') || method('POST'))`

path

path <paths...>

expression path('<paths...>')

リクエストパス（リクエストURIのパスコンポーネント）による。パスの一致は大文字と小文字を区別しますが、ワイルドカード * を使用できます

• 末尾のみ、プレフィックスマッチ（/prefix/*）の場合
• 先頭のみ、サフィックスマッチ（*.suffix）の場合
• 両側のみ、部分文字列マッチ（*/contains/*）の場合
• 中央のみ、グロブマッチ（/accounts/*/info）の場合

スラッシュは重要です. 例えば、/foo* は /foo、/foobar、/foo/、/foo/bar に一致しますが、/foo/* は /foo や /foobar には一致しません.

リクエストパスは、一致する前にディレクトリトラバーサルドットを解決するためにクリーンアップされます。さらに、一致パターンに複数のスラッシュがない限り、複数のスラッシュはマージされます。つまり、/foo は /foo と //foo に一致しますが、//foo は //foo にのみ一致します.

特定のURIには複数のエスケープ形式があるため、リクエストパスは正規化されます（URLデコード、エスケープ解除）。ただし、一致パターンにもエスケープシーケンスが存在する位置にあるエスケープシーケンスは除きます。たとえば、/foo/bar は /foo/bar と /foo%2Fbar の両方に一致しますが、/foo%2Fbar は /foo%2Fbar にのみ一致します。これは、エスケープシーケンスが設定で明示的に指定されているためです.

特別なワイルドカードエスケープ %* は、一致するスパンをエスケープしたままにするために * の代わりに使用することもできます。たとえば、/bands/*/* は /bands/AC%2FDC/T.N.T に一致しません。パスは /bands/AC/DC/T.N.T のように見える正規化された空間で比較されるため、パターンと一致しないためです。ただし、/bands/%*/* は /bands/AC%2FDC/T.N.T に一致します。これは、%* で表されるスパンがエスケープシーケンスをデコードせずに比較されるためです.

複数のパスはOR条件で結合されます。

例

複数のディレクトリとその内容に一致させる

@assets path /js/* /css/* /images/*

特定のファイルに一致させる

@favicon path /favicon.ico

ファイル拡張子に一致させる

@extensions path *.js *.css

CEL式 を使用

@assets `path('/js/*', '/css/*', '/images/*')`

path_regexp

path_regexp [<name>] <regexp>

expression path_regexp('<name>', '<regexp>')
expression path_regexp('<regexp>')

path と似ていますが、正規表現をサポートしています。パスのURIデコード/エスケープ解除された形式でパターンを記述します。

使用される正規表現言語は、Goに含まれるRE2です。RE2構文リファレンス と Go正規表現構文の概要 を参照してください。

キャプチャグループには、{re.name.capture_group} のような プレースホルダー を介してアクセスできます。ここで、name は正規表現の名前（オプションですが推奨）であり、capture_group は式内のキャプチャグループの名前または番号です。キャプチャグループ 0 は完全な正規表現の一致、1 は最初のキャプチャグループ、2 は2番目のキャプチャグループなどです。

名前付きマッチャーごとに1つの path_regexp パターンのみ使用できます。

例

パスが6文字の16進文字列で終わり、ファイル拡張子が .css または .js であるリクエストに一致し、( ) で囲まれた各部分に {re.static.1} と {re.static.2} でアクセスできるキャプチャグループを持つ

@static path_regexp static \.([a-f0-9]{6})\.(css|js)$

または、CEL式 を使用した同じ例。また、file がディスク上に存在することを検証する

@static `path_regexp('static', '\.([a-f0-9]{6})\.(css|js)$') && file()`

protocol

protocol http|https|grpc|http/<version>[+]

expression protocol('http|https|grpc|http/<version>[+]')

リクエストプロトコルによる。http、https、grpc などの広範なプロトコル名を使用できます。または、http/1.1 や http/2+ などの特定のまたは最小限のHTTPバージョンを使用できます。

名前付きマッチャーごとに1つの protocol マッチャーのみ使用できます。

例

HTTP/2を使用するリクエストに一致する

@http2 protocol http/2+

CEL式 を使用

@http2 `protocol('http/2+')`

query

query <key>=<val>...

expression query({'<key>': '<val>'})
expression query({'<key>': ['<vals...>']})

クエリ文字列パラメータによる。key=value ペアのシーケンスにする必要があります。キーは完全一致（大文字と小文字を区別）しますが、任意の値に一致させるために * もサポートしています。値はプレースホルダーを使用できます。

名前付きマッチャーごとに複数の query マッチャーを使用でき、同じキーを持つペアはOR条件で結合されます.

不正なクエリ文字列（構文エラー、エスケープされていないセミコロンなど）は解析に失敗するため、一致しません。

**注意：**クエリ文字列パラメータは単一の値ではなく配列です. これは、クエリ文字列では繰り返されるキーが有効であり、それぞれが異なる値を持つ可能性があるためです。このマッチャーは、設定された値のいずれかがクエリ文字列に割り当てられている場合、キーに一致します。クエリ文字列を使用するバックエンドアプリケーションは、クエリ文字列の値が配列であり、複数の値を持つ可能性があることを考慮する必要があります。

例

任意の値を持つ q クエリパラメータに一致させる

@search query q=*

値が asc または desc である sort クエリパラメータに一致させる

@sorted query sort=asc sort=desc

CEL式 を使用して q と sort の両方に一致させる

@search-sort `query({'sort': ['asc', 'desc'], 'q': '*'})`

remote_ip

remote_ip [forwarded] <ranges...>

expression remote_ip('<ranges...>')
expression remote_ip('forwarded', '<ranges...>')

リモートIPアドレス（つまり、直接接続されているピアのIPアドレス）による。正確なIPまたはCIDR範囲を受け入れます。IPv6ゾーンがサポートされています。

ショートカットとして、 `private_ranges`を使用してすべてのプライベートIPv4およびIPv6範囲に一致させることができます。これは、次のすべての範囲を指定するのと同じです。 `192.168.0.0/16 172.16.0.0/12 10.0.0.0/8 127.0.0.1/8 fd00::/8 ::1`

⚠️ forwarded オプションは非推奨であり、将来のバージョンで削除されます. 実装は安全ではありません. 代わりに client_ip マッチャーを使用してください. これにより、HTTPヘッダーから解析された場合、実際のクライアントIPを安全に一致させることができます. 有効になっている場合、X-Forwarded-For リクエストヘッダーの最初のIP（存在する場合）が、デフォルトである直接接続されているピアのIPではなく、参照IPとして優先されます。

名前付きマッチャーごとに複数の remote_ip マッチャーを使用でき、それらの範囲はマージされ、OR条件で結合されます。

例

プライベートIPv4アドレスからのリクエストを一致させる

@private-ipv4 remote_ip 192.168.0.0/16 172.16.0.0/12 10.0.0.0/8 127.0.0.1/8

このマッチャーは、notマッチャーと組み合わせて一致を反転させることがよくあります。たとえば、*パブリック* IPv4およびIPv6アドレス（すべてのプライベート範囲の逆）からのすべての接続を中止するには

example.com {
	@denied not remote_ip private_ranges
	abort @denied

	respond "Hello, you must be from a private network!"
}

CEL式では、次のようになります

@my-friends `remote_ip('12.23.34.45', '23.34.45.56')`

vars

vars <variable> <values...>

リクエストコンテキスト内の変数の値、またはプレースホルダーの値による。複数の値を指定して、これらの可能な値のいずれかに一致させることができます（OR条件）。

**<variable>** 引数は、変数名または中括弧 { } で囲まれたプレースホルダーのいずれかです。（プレースホルダーは最初のパラメーターでは展開されません。）

このマッチャーは、出力を設定する map ディレクティブ、またはリクエストコンテキストに情報を設定するプラグインと組み合わせて使用​​すると最も効果的です。

例

値が 3 または 5 である magic_number という名前の map ディレクティブ の出力に一致させる

vars {magic_number} 3 5

vars_regexp

vars_regexp [<name>] <variable> <regexp>

vars と似ていますが、正規表現をサポートしています。キャプチャグループには、{re.name.capture_group} のような プレースホルダー を介してアクセスできます。ここで、name は正規表現の名前（オプションですが推奨）であり、capture_group は式内のキャプチャグループの名前または番号です。キャプチャグループ 0 は完全な正規表現の一致、1 は最初のキャプチャグループ、2 は2番目のキャプチャグループなどです。

使用される正規表現言語は、Goに含まれるRE2です。RE2構文リファレンス と Go正規表現構文の概要 を参照してください。

名前付きマッチャーごとに1つの vars_regexp マッチャーのみ使用できます。

例

magic_number という名前の map ディレクティブ の出力結果のうち、4 で始まる値にマッチさせ、その値をキャプチャグループにキャプチャします。

vars_regexp magic {magic_number} ^(4.*)