# 5. bindとserverのオプション

> リスナー、server、default-server、DNS解決のオプション

---

LLMSインデックス: [llms.txt](/ja/llms.txt)

---

<!-- Generated by scripts/generate-haproxy-docs.py from pinned upstream text. -->

"bind"、"server"、"default-server"キーワードは、ビルドオプションやHAProxyをビルドしたシステムに応じた各種設定をサポートします。各設定は通常、単語一つと、その後に続く場合がある値で構成され、"bind"行または"server"行と同じ行に記述します。このセクションでは、これらのオプションをすべて説明します。

## 5.1. bindオプション {#section-5-1}

"bind"キーワードは、いくつかの設定をサポートし、すべて同じ行の引数として指定します。バインドするアドレスより後ろに記述すれば、引数の順序は問いません。すべてのパラメーターは省略可能です。単語一つのもの（真偽値）もあれば、その後ろに値が必要なものもあります。値が必要な場合は、設定名の直後に記述しなければなりません。

現在サポートされている設定は次のとおりです。

<a id="entry-5-1-accept-netscaler-cip"></a>

**`accept-netscaler-cip <magic number>`**

```haproxy
accept-netscaler-cip <magic number>
```

同じ行で宣言したいずれかのTCPソケットで受け入れるすべての接続に、NetScaler Client IP insertionプロトコルの使用を強制します。NetScaler Client IP insertionプロトコルで指定された受け入れた接続のレイヤー3/4のアドレスを、アドレスを使用するあらゆる箇所で使います。唯一の例外は"tcp-request connection"ルールで、実際の接続のアドレスだけを参照します。ログには、プロトコルで指定されたアドレスが記録されます。ただし、プロトコル違反がある場合には、実際のアドレスを使います。外部コンポーネントのサポートとこのキーワードを組み合わせると、常に信頼できるとは限らず、使用できない場合さえあるX-Forwarded-Forの仕組みに代わる、効率的で信頼できる方法として使用できます。このプロトコルを許可するクライアントをより細かく設定するには、"tcp-request connection expect-netscaler-cip"も参照してください。

<a id="entry-5-1-accept-proxy"></a>

**`accept-proxy`**

```haproxy
accept-proxy
```

同じ行で宣言したいずれかのソケットで受け入れるすべての接続に、PROXYプロトコルの使用を強制します。PROXYプロトコルのバージョン1と2をサポートし、正しく判別します。PROXYプロトコルで指定された受け入れた接続のレイヤー3/4のアドレスを、アドレスを使用するあらゆる箇所で使います。唯一の例外は"tcp-request connection"ルールで、実際の接続のアドレスだけを参照します。ログには、プロトコルで指定されたアドレスが記録されます。ただし、プロトコル違反がある場合には、実際のアドレスを使います。外部コンポーネントのサポートとこのキーワードを組み合わせると、常に信頼できるとは限らず、使用できない場合さえあるX-Forwarded-Forの仕組みに代わる、効率的で信頼できる方法として使用できます。このプロトコルを許可するクライアントをより細かく設定するには、"tcp-request connection expect-proxy"も参照してください。

<a id="entry-5-1-allow-0rtt"></a>

**`allow-0rtt`**

```haproxy
allow-0rtt
```

TLSv1.3を使う際、early dataの受信を許可します。セキュリティー上の理由から、デフォルトでは無効です。リプレイ攻撃に弱いため、安全に再実行できるリクエスト、つまり冪等なリクエストだけに許可することを推奨します。early dataで安全に扱えないリクエストには、"wait-for-handshake"アクションを使用できます。QUICでは、QuicTLS、OpenSSL \>= 3.5.2、AWS-LCで0rttをサポートしています。TCP/TLSでは、0rttをサポートするのはOpenSSLだけで、クライアントがALPNを送る必要があります。送らない場合、ハンドシェイクが行われるまでearly dataは処理の対象になりません。

<a id="entry-5-1-alpn"></a>

**`alpn <protocols>`**

```haproxy
alpn <protocols>
```

TLSのALPN拡張を有効にし、指定したプロトコルリストを、ALPNで選択できる上位プロトコルとして通知します。リストはプロトコル名をカンマで区切ったもので、たとえば"http/1.1,http/1.0"（引用符なし）です。SSLライブラリーを、TLS拡張のサポートを有効にしてビルドしている必要があります（haproxy -vvで確認できます）。ALPN拡張は、当初使われていたNPN拡張に代わるものです。プロトコル上、HTTPSフロントエンドでHTTP/2を有効にする場合と、QUICフロントエンドでHTTP/3を有効にする場合には、ALPNが必要です。ただし、これらのフロントエンドで"npn"、"alpn"、"no-alpn"のいずれも設定していない場合、通常のHTTPSフロントエンドでは"h2,http/1.1"、QUICフロントエンドでは"h3"をデフォルトとして使います。OpenSSL 1.0.2より前のバージョンはALPNをサポートしておらず、現在では廃止されたNPN拡張だけをサポートしていました。執筆時点では、ほとんどのブラウザーがHTTP/2でALPNとNPNの両方を引き続きサポートしているため、しばらくはNPNへのフォールバックが機能する可能性があります。ただし、可能な場合は必ずALPNを使用してください。通知していないプロトコルはネゴシエーションの対象になりません。たとえば、次の設定ではHTTP/2接続だけを受け入れられます。

```text
bind :443 ssl crt pub.pem alpn h2  # explicitly disable HTTP/1.1
```

QUICでサポートするALPNはh3とhq-interopだけです。h3はHTTP/3用で、hq-interopはhttp/0.9およびQUIC interop runnerで使用します（<https://interop.seemann.io>を参照）。各"alpn"ステートメントは、前の設定を置き換えます。削除するには"no-alpn"を使用してください。

Firefox 88などの古いブラウザーには、H2上のWebSocketで問題が発生するものがありました。このような構成では、"alpn"文字列を"http/1.1"または"no-alpn"に強制してHTTP/2を明示的に無効にするか、グローバルに"h2-workaround-bogus-websocket-clients"を有効にする必要がある場合があります。

<a id="entry-5-1-backlog"></a>

**`backlog <backlog>`**

```haproxy
backlog <backlog>
```

ソケットのバックログを指定値に設定します。未指定または0の場合、代わりにフロントエンドのバックログを使用します。そのデフォルトは通常、maxconnの値です。

<a id="entry-5-1-ca-file"></a>

**`ca-file <cafile>`**

```haproxy
ca-file <cafile>
```

この設定は、OpenSSLのサポートを組み込んでビルドした場合にのみ使用できます。クライアント証明書の検証に使うCA証明書を読み込むPEMファイルを指定します。複数のCAを含むディレクトリを読み込むこともできます。その場合、HAProxyはディレクトリ内のすべての".pem"、".crt"、".cer"、".crl"ファイルの読み込みを試みます。名前がドットで始まるファイルは無視されます。

警告： serverディレクティブと同様に、cafileの代わりに"@system-ca"パラメーターを使い、システムで信頼されているCAを使用することもできます。ただし、その意味を理解していない限り使用してはなりません。この設定では、実質的にシステム上のいずれかのCAが発行したクライアント証明書をbindがすべて受け入れることになるため、極めて危険です。

<a id="entry-5-1-ca-ignore-err"></a>

**`ca-ignore-err [all|<errorID>,...]`**

```haproxy
ca-ignore-err [all|<errorID>,...]
```

この設定は、OpenSSLのサポートを組み込んでビルドした場合だけ使用できます。検証時に深さ\> 0で無視するerrorIDを、カンマ区切りのリストで設定します。数値のIDか、OpenSSLのドキュメント<https://www.openssl.org/docs/manmaster/man3/X509_STORE_CTX_get_error.html#ERROR-CODES>に記載された定数名（X509_V_ERR）を指定できます。数値は新しいバージョンのOpenSSLで変わる可能性があるため、定数名の使用を推奨します。'all'を指定すると、すべてのエラーを無視します。エラーを無視した場合、SSLハンドシェイクは中断しません。

<a id="entry-5-1-ca-sign-file"></a>

**`ca-sign-file <cafile>`**

```haproxy
ca-sign-file <cafile>
```

この設定は、OpenSSLのサポートを組み込んでビルドした場合だけ使用できます。サーバー証明書の作成と署名に使うCA証明書とCA秘密鍵の両方を含むPEMファイルを指定します。証明書の動的生成を有効にする場合は必須です。詳細は'generate-certificates'を参照してください。

<a id="entry-5-1-ca-sign-pass"></a>

**`ca-sign-pass <passphrase>`**

```haproxy
ca-sign-pass <passphrase>
```

この設定は、OpenSSLのサポートを組み込んでビルドした場合だけ使用できます。CA秘密鍵のパスフレーズです。省略可能な設定で、証明書の動的生成を有効にする場合だけ使用します。詳細は'generate-certificates'を参照してください。

<a id="entry-5-1-ca-verify-file"></a>

**`ca-verify-file <cafile>`**

```haproxy
ca-verify-file <cafile>
```

この設定は、クライアント証明書の検証に使うCA証明書を読み込むPEMファイルを指定します。ここで指定するのは、server helloメッセージで送信するCA名に含めてはならないCA証明書です。通常、"ca-file"には中間証明書を、"ca-verify-file"にはルートCAのようにチェーンの終端となる証明書を定義する必要があります。

<a id="entry-5-1-cc"></a>

**`cc <algo>`**

```haproxy
cc <algo>
```

この設定はTCP_CONGESTIONを定義しているシステムでのみ使用でき、LinuxとFreeBSDで検証されています。TCP輻輳制御アルゴリズムの名前を受け取り、このリスナーが受け入れるすべての接続でそのアルゴリズムを使うよう、リスナーを設定します。代表的な名前に"reno"や"cubic"がありますが、使用できるものはOSによって異なります。システムによっては、特定のアルゴリズムを設定するために特別な権限が必要な場合があります。Linuxでは、利用可能なアルゴリズムの一覧はsysctlの"net.ipv4.tcp_available_congestion_control"で、特権なしで使用を許可されているものは"net.ipv4.tcp_allowed_congestion_control"で確認できます。追加の権限が必要なアルゴリズムを使うには、"cap_net_admin"ケーパビリティーが必要な場合があります（globalセクションの"setcap"を参照）。指定した輻輳制御アルゴリズムを設定できない場合、デフォルトのアルゴリズムをそのまま使い、問題を知らせる警告を出します。serverキーワードの"cc"（[セクション5.2](/ja/docs/haproxy/bind-and-server-options/#section-5-2)）も参照してください。例：

```text
frontend public
    bind :443 cc bbr   # use the BBR algorithm for high bandwidths
```

<a id="entry-5-1-ciphers"></a>

**`ciphers <ciphers>`**

```haproxy
ciphers <ciphers>
```

この設定は、OpenSSLのサポートを組み込んでビルドした場合だけ使用できます。TLSv1.2までのSSL/TLSハンドシェイクでネゴシエーションする、暗号アルゴリズムの一覧（"cipher suite"）を記述した文字列を設定します。文字列の形式は、OpenSSLのマニュアルページ"man 1 ciphers"で定義されています。背景や推奨事項については、たとえば(<https://wiki.mozilla.org/Security/Server_Side_TLS>)と(<https://mozilla.github.io/server-side-tls/ssl-config-generator/>)を参照してください。TLSv1.3の暗号設定については、"ciphersuites"キーワードを参照してください。

<a id="entry-5-1-ciphersuites"></a>

**`ciphersuites <ciphersuites>`**

```haproxy
ciphersuites <ciphersuites>
```

この設定は、OpenSSLのサポートを組み込み、OpenSSL 1.1.1以降を使ってHAProxyをビルドした場合だけ使用できます。TLSv1.3ハンドシェイクでネゴシエーションする暗号アルゴリズムの一覧（"cipher suite"）を記述した文字列を設定します。文字列の形式は、OpenSSLのマニュアルページ"man 1 ciphers"の"ciphersuites"セクションで定義されています。TLSv1.2以前の暗号設定については、"ciphers"キーワードを参照してください。この設定はTLSv1.2の暗号スイートを受け付ける可能性もありますが、文書化されていない動作であり、動作が一貫しなかったり、不具合があったりする可能性があるため、推奨しません。OpenSSLのデフォルトのTLSv1.3暗号スイートは、"TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256"です。

TLSv1.3でサポートされる暗号スイートは5つのみです。

- TLS_AES_128_GCM_SHA256
- TLS_AES_256_GCM_SHA384
- TLS_CHACHA20_POLY1305_SHA256
- TLS_AES_128_CCM_SHA256
- TLS_AES_128_CCM_8_SHA256

例：

```text
ciphers ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256
ciphersuites TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256
```

<a id="entry-5-1-client-sigalgs"></a>

**`client-sigalgs <sigalgs>`**

```haproxy
client-sigalgs <sigalgs>
```

この設定は、OpenSSLのサポートを組み込んでビルドした場合にのみ使用できます。ネゴシエーションする、クライアント認証に関係する署名アルゴリズムのリストを表す文字列を設定します。文字列の形式は、OpenSSLのmanページ"man 3 SSL_CTX_set1_client_sigalgs"に定義されています。具体的な用途が明らかでない場合、この設定の使用は推奨しません。

<a id="entry-5-1-crl-file"></a>

**`crl-file <crlfile>`**

```haproxy
crl-file <crlfile>
```

この設定は、OpenSSLのサポートを組み込んでビルドした場合だけ使用できます。クライアント証明書の検証に使う証明書失効リストを読み込むPEMファイルを指定します。認証局チェーンの各証明書について、証明書失効リストを用意する必要があります。

<a id="entry-5-1-crt"></a>

**`crt <cert>`**

```haproxy
crt <cert>
```

この設定は、OpenSSLサポートを組み込んでビルドした場合にのみ使用できます。

HAProxyはキャッシュの仕組みを使い、ファイルを証明書ストレージに読み込むのは一度だけで、その後の各"crt"キーワードではキャッシュしたものを使用します。証明書を"crt-store"で宣言した場合、証明書ストレージはそこから内容を取得し、拡張子の検出による追加ファイルの読み込みは試みません。

必要な証明書と、それに対応する秘密鍵を含むPEMファイルを指定します。このファイルは、複数のPEMファイルを一つに連結して作成できます（例: cat cert.pem key.pem \> combined.pem）。CAが中間証明書を必要とする場合は、それもこのファイルに連結できます。中間証明書は、"issuers-chain-path"ディレクティブを使ってディレクトリ内で共有することもできます。

ファイルに秘密鍵が含まれていない場合、HAProxyは同じパスの末尾に".key"を付けたファイルから鍵の読み込みを試みます。

使用するOpenSSLがDiffie-Hellmanをサポートしている場合、このファイル内のパラメーターが読み込まれます。

PEMファイルの代わりにディレクトリ名を指定すると、そのディレクトリ内のすべてのファイルを名前のアルファベット順に読み込みます。ただし、名前の末尾が予約済みの拡張子'.key'、'.issuer'、'.ocsp'、'.sctl'であるファイルは除きます。ドットで始まるファイルも無視します。このディレクティブは複数回指定でき、複数のファイルやディレクトリから証明書を読み込めます。証明書のCNまたは代替サブジェクトのいずれかに一致する、有効なTLS Server Name Indicationフィールドを送ってきたクライアントに、その証明書を提示します。ホスト名の最初の要素をワイルドカード文字'\*'で置き換えることもできます（たとえば、\*.example.orgは[www.example.org](http://www.example.org)に一致しますが、[www.sub.example.org](http://www.sub.example.org)には一致しません）。空のディレクトリを指定した場合、"strict-sni"キーワードを使わなければHAProxyは起動しません。

クライアントがSNIを送らない場合、SSLライブラリーがTLS拡張をサポートしていない場合、またはクライアントのSNIホスト名に一致する証明書がない場合には、最初に読み込んだ証明書を提示します。そのため、ディレクトリから証明書を読み込むときは、デフォルトの証明書を先にファイルとして読み込むか、ディレクトリ内で必ず先頭になるようにすることを強く推奨します。複数のデフォルト証明書（rsaを1つ、ecdsaを1つ）を選ぶには、3つの方法があります。

- 複数証明書のバンドルを最初の証明書として設定できます（`foobar.pem.ecdsa`と`foobar.pem.rsa`が存在する構成では`crt foobar.pem`）。
- または、crt-list行の各証明書に'\*'フィルターを指定します。
- 'default-crt'キーワードを使用できます。

同じ証明書を複数回読み込んでも副作用はありません。

一部のCA（GoDaddyなど）では、証明書の取得時にサーバーの種類をドロップダウンリストから選びますが、そのリストにHAProxyが含まれていません。その場合は、中間CAが必要だとCAが判断するWebサーバーを必ず選択してください（GoDaddyではApache Tomcatを選ぶと正しいバンドルが得られますが、nginxなどほかの多くの種類では、一部のクライアントで機能しない誤ったバンドルになります）。

HAProxyは各PEMファイルについて、同じパスに".ocsp"を付けたファイルがあるかを確認します。見つかると、TLS Certificate Status Request拡張（"OCSP stapling"とも呼ばれます）のサポートを自動的に有効にします。このファイルの内容は任意です。空でない場合、DER形式の有効なOCSP Responseを含める必要があります。OCSP Responseが有効とみなされるには、次の規則を満たす必要があります。goodの状態を示していること、PEMファイル内の証明書に対する単一のレスポンスであること、追加した時点で有効であることです。これらを満たさない場合、OCSP Responseを無視して警告を出します。OCSP Responseがどの証明書に適用されるかを特定するには、発行者の証明書が必要です。PEMファイル内に発行者の証明書が見つからなければ、PEMファイルと同じパスに".issuer"を付けたファイルが存在する場合はそこから読み込み、存在しなければエラーになります。

HAProxyは各PEMファイルについて、同じパスの末尾に".sctl"を付けたファイルが存在するかどうかも確認します。そのファイルが見つかった場合、Certificate Transparency（RFC6962）TLS拡張のサポートが有効になります。ファイルには、RFCに記載された有効なSigned Certificate Timestamp Listが含まれていなければなりません。ファイルは基本的な構文を確認するために解析されますが、署名の検証は行われません。

クライアントに提示する暗号スイートで、RSAやECDSAなど複数の鍵の種類をサポートしたい場合があります。これにより、EC証明書をサポートするクライアントはEC暗号を使いながら、RSAだけに対応した古いクライアントも同時にサポートできます。

これにはOpenSSL 1.1.1が必要です。証明書の種類ごとに一つのcrtエントリーを指定するか、HAProxy 1.8より前で必要だった"cert bundle"を設定することで、この動作を構成できます。"ssl-load-extra-files"を参照してください。

<a id="entry-5-1-crt-ignore-err"></a>

**`crt-ignore-err <errors>`**

```haproxy
crt-ignore-err <errors>
```

この設定は、OpenSSLのサポートを組み込んでビルドした場合だけ使用できます。検証時に深さ== 0で無視するerrorIDを、カンマ区切りのリストで設定します。数値のIDか、OpenSSLのドキュメント<https://www.openssl.org/docs/manmaster/man3/X509_STORE_CTX_get_error.html#ERROR-CODES>に記載された定数名（X509_V_ERR）を指定できます。数値は新しいバージョンのOpenSSLで変わる可能性があるため、定数名の使用を推奨します。'all'を指定すると、すべてのエラーを無視します。エラーを無視した場合、SSLハンドシェイクは中断しません。

<a id="entry-5-1-crt-list"></a>

**`crt-list <file>`**

```haproxy
crt-list <file>
```

この設定は、OpenSSLのサポートを組み込んでビルドした場合だけ使用できます。証明書ごとに任意指定のSSL設定とSNIフィルターを付けた、PEMファイルのリストを指定します。各行は次の形式です。

```text
<crtfile> [\[<sslbindconf> ...\]] [[!]<snifilter> ...]
```

空行と、ハッシュ（'#'）で始まる行は無視されます。

crt-listは統計ソケット経由で動的に操作できます（管理ガイドの"add ssl crt-list"、"del ssl crt-list"、"show ssl crt-list"を参照）。

crt-listは通常、専用のファイルですが、"crt"ディレクティブで読み込んだディレクトリも、内部ではcrt-listとして表されます。フロントエンドの"ssl-f-use"ディレクティブも、そのフロントエンドに関連付けたcrt-listを宣言します。

crtfile:

```text
これは証明書のファイル名です。CLI経由や、crt-storeで別名を付けるなど、
別の場所で宣言した場合は、その識別子を指定します。

異なるオプションやフィルターを指定して、同じ<crtfile>を
複数の行で使うこともできます。

<crtfile>にベース名だけを指定すれば、crt-listでも複数の証明書を
まとめる機能（"ssl-load-extra-files"を参照）を使えます。HAProxyは、
ファイルを読み込むときにアルゴリズムの拡張子（.rsa、.ecdsa、.dsa）を
付け、crt-list行を内部で複製します。
```

sslbindconf:

```text
 <sslbindconf>は、bind行の次のキーワードをサポートします
 （セクション5.1「bindのオプション」を参照）。

 - allow-0rtt
 - alpn
 - ca-file
 - ca-verify-file
 - ciphers
 - ciphersuites
 - client-sigalgs
 - crl-file
 - curves
 - ecdhe
 - no-alpn
 - no-ca-names
 - npn
 - sigalgs
 - ssl-min-ver
 - ssl-max-ver
 - verify

 <sslbindconf>は、crt-storeのloadキーワードの次のキーワードも
 サポートします（セクション12.7.1「loadのオプション」を参照）。

 - crt
 - key
 - ocsp
 - issuer
 - sctl
 - ocsp-update

<sslbindconf>はbind行のパラメーターを継承し、何も指定されていない場合は
デフォルトのオプションを継承します。<sslbindconf>に指定したパラメーターは、
継承した設定を上書きします。
```

snifilter:

```text
crt-list行で<snifilter>パラメーターを使うと、ハンドシェイク中に
その行の証明書を選ぶ際、CNとSANの代わりに
<snifilter>を使います。

<snifilter>は、空白で区切ったエントリーの一覧です。ドメインまたは
ワイルドカードを含められます。ワイルドカードはDNSの形式に従い、
エントリーの先頭にアスタリスクを一つ置きます。単一のドメインの前に
'!'を付けた否定フィルターを指定すれば、ワイルドカードの対象から
そのドメインを除外できます。*の前の!は無視します。同じ行に
ワイルドカードがなく、否定フィルターだけがある指定もサポートしません。
特別なエントリー'*'は、どのドメインにも一致しない場合の
フォールバックとして使うデフォルトの証明書を指定します。

SNIフィルターのいずれか、または<crtfile>のCNとSANに一致する
有効なTLSのServer Name Indicationフィールドを送るクライアントに、
証明書を提示します。照合アルゴリズムは、まず一覧内で肯定のドメイン
エントリーを探し、見つからなければワイルドカードを探します。
ワイルドカードに一致すると、haproxyは同じ行の否定フィルターを確認し、
必要なら一致を取り消します。複数の鍵アルゴリズム（RSA,ECDSA,DSA）が
ある場合、HAProxyは種類ごとに証明書を一つ照合し、
クライアントの対応状況に応じて適切なものを選びます。

クライアントがSNIを提示しない場合や、一致する証明書がない場合は、
デフォルトの証明書のいずれかにフォールバックします。
このフォールバックは、'strict-sni'オプションで無効にできます。
デフォルトの証明書が複数ある場合、HAProxyはクライアントの対応状況に
応じて、適切なECDSAまたはRSAの証明書を選べます。

bind行で最初に宣言した証明書は、crtとcrt-listのどちらのオプションで
指定したかにかかわらず、デフォルトの証明書になります。
また、'*'フィルターを宣言して、その証明書をデフォルトの証明書一覧に
追加することもできます。設定を分かりやすくするには、一覧の先頭で
デフォルトの証明書を'*'フィルターにより明示し、それより前に
暗黙のデフォルトが追加されないようにできます。
複数証明書のバンドルはcrt-list内でアルゴリズムごとに複製されるため、
crt-listの先頭行を占めてデフォルトとみなされるのは、一つのアルゴリズム
だけです。フィルターに'*'を宣言するか、bind行で設定することで、
バンドル全体をデフォルトとして指定してください。

statsソケットの"show ssl sni"コマンドを使って、設定をデバッグできます。
（管理ガイドの"show ssl sni"を参照。）
```

例：

```shell
# comment
default.pem.rsa *
default.pem.ecdsa *
cert2.pem [alpn h2,http/1.1]
certW.pem *.domain.tld !secure.domain.tld
certS.pem [curves X25519:P-256 ciphers ECDHE-ECDSA-AES256-GCM-SHA384] secure.domain.tld
foo.crt [key bar.pem ocsp foo.ocsp ocsp-update on] foo.bar.com
```

<a id="entry-5-1-default-crt"></a>

**`default-crt <cert>`**

```haproxy
default-crt <cert>
```

このオプションは"crt"と同じ動作をしますが、その証明書をデフォルトの証明書としても使用する点が異なります。ECDSA用とRSA用を用意するため、複数のデフォルト証明書を追加できます。それ以上用意しても、あまり有用ではありません。

このオプションは、暗黙のデフォルト証明書を無効にしません。'default-crt'やほかの'crt'よりも先に'crt'証明書を宣言した場合、その証明書は引き続きデフォルト証明書として使用されます。

bind行で"strict-sni"オプションを使用していない場合、デフォルト証明書を使用します。クライアントがservername拡張を使わなかった場合や、servernameが設定済みのどの証明書にも一致しない場合に、デフォルト証明書を提示します。

例：

```shell
# this bind line has 2 default certificates
bind *:443 default-crt foobar.pem.rsa default-crt foobar.pem.ecdsa crt website.pem.rsa

# this bind line has 3 default certificates
bind *:443 crt website.pem.rsa default-crt foobar.pem.rsa default-crt foobar.pem.ecdsa
```

"crt"キーワードも参照してください。

<a id="entry-5-1-curves"></a>

**`curves <curves>`**

```haproxy
curves <curves>
```

この設定は、OpenSSLのサポートを組み込んでビルドした場合にのみ使用できます。ECDHEを使用するSSL/TLSハンドシェイク中にネゴシエーションする楕円曲線アルゴリズムのリスト（"curve suite"）を表す文字列を設定します。文字列の形式は、曲線名をコロンで区切ったリストです。例: "X25519:P-256"（引用符なし）。"curves"が設定されている場合、"ecdhe"パラメーターは無視されます。

<a id="entry-5-1-defer-accept"></a>

**`defer-accept`**

```haproxy
defer-accept
```

一部のLinuxカーネルでのみサポートする、省略可能なキーワードです。接続上に何らかのデータが到着するまで接続を受け入れず、遅くとも最初の再送後には受け入れることを指定します。クライアントが先に送信するプロトコル（HTTPなど）だけで使用することを推奨します。接続を受け入れた時点でリクエストの大半がすでに到着しているようにすることで、性能がわずかに改善する場合があります。一方、何も送信しない接続は検出できません。2.6.31までのすべてのカーネルではこのオプションが正しく動作せず、クライアントが送信するまで接続を受け入れないことに注意してください。そのため、手前のファイアウォールでは接続が確立済みに見えるのに、プロキシ側ではSYN_RECVのままに見えて、問題が起きることがあります。このオプションはTCPv4/TCPv6ソケットでのみサポートし、ほかのソケットでは無視します。

<a id="entry-5-1-ecdhe"></a>

**`ecdhe <named curve>`**

```haproxy
ecdhe <named curve>
```

この設定は、OpenSSLのサポートを組み込んでビルドした場合だけ使用できます。ECDHの一時鍵の生成に使う名前付き曲線（RFC 4492）を設定します。デフォルトで使用する名前付き曲線はprime256v1です。

<a id="entry-5-1-ech"></a>

**`ech <dir> [ EXPERIMENTAL ]`**

```haproxy
ech <dir> [ EXPERIMENTAL ]
```

`<dir>`内のすべてのECH鍵をbind行に適用します。ファイルの拡張子は.echでなければならず、ECH用のPEMファイル形式を使用する必要があります（<https://datatracker.ietf.org/doc/draft-farrell-tls-pemesni/>）。

このキーワードは共有モードでECHを有効にし、HAProxyがTLSエンドポイントとECHエンドポイントの両方として動作します。<https://datatracker.ietf.org/doc/draft-ietf-tls-esni/>を参照してください。

これは実験的な機能で、globalセクションの"expose-experimental-directives"オプションが必要です。ECHをサポートするOpenSSLのバージョン（<https://github.com/openssl/openssl/tree/feature/ech>）も必要で、HAProxyはUSE_ECH=1でコンパイルしなければなりません。AWS-LCのECH APIはサポートしていません。

例：

```shell
$ openssl ech -public_name foobar.com -out /etc/haproxy/echkeydir/foobar.com.ech

$ cat haproxy.cfg
[...]
bind :443 ech /etc/haproxy/echkeydir/ ssl crt example.com.pem

// Use the ECHCONFIG section of your .ech file
$ openssl s_client -tls1_3 -connect example.com:443 -servername example.com \
-ech_config_list AD3+DQA5cwAgACB6ybtgtFYoM5r8nJSotus4c7K0EG..9vYmFyLmNvbQAA
```

<a id="entry-5-1-expose-fd-listeners"></a>

**`expose-fd listeners`**

```haproxy
expose-fd listeners
```

このオプションは統計ソケットでのみ使用できます。統計ソケットから、別のHAProxyプロセスにリスナーのFDを渡せるようにします。master-workerモードでは、masterとworkerの間の内部socketpairを使ってリスナーを渡すため、この指定は不要です。管理ガイドの"-x"も参照してください。

<a id="entry-5-1-force-sslv3"></a>

**`force-sslv3`**

```haproxy
force-sslv3
```

このオプションは、このリスナーから作成するSSL接続で、SSLv3だけを使用するよう強制します。接続頻度が高い場合、SSLv3は通常、TLSよりも処理コストが低くなります。グローバル設定の"ssl-default-bind-options"でも使用できます。"ssl-min-ver"と"ssl-max-ver"も参照してください。

<a id="entry-5-1-force-tlsv10"></a>

**`force-tlsv10`**

```haproxy
force-tlsv10
```

このオプションは、このリスナーから作成するSSL接続で、TLSv1.0だけを使用するよう強制します。グローバル設定の"ssl-default-bind-options"でも使用できます。"ssl-min-ver"と"ssl-max-ver"も参照してください。

<a id="entry-5-1-force-tlsv11"></a>

**`force-tlsv11`**

```haproxy
force-tlsv11
```

このオプションは、このリスナーから作成するSSL接続で、TLSv1.1だけを使用するよう強制します。グローバル設定の"ssl-default-bind-options"でも使用できます。"ssl-min-ver"と"ssl-max-ver"も参照してください。

<a id="entry-5-1-force-tlsv12"></a>

**`force-tlsv12`**

```haproxy
force-tlsv12
```

このオプションは、このリスナーから作成するSSL接続で、TLSv1.2だけを使用するよう強制します。グローバル設定の"ssl-default-bind-options"でも使用できます。"ssl-min-ver"と"ssl-max-ver"も参照してください。

<a id="entry-5-1-force-tlsv13"></a>

**`force-tlsv13`**

```haproxy
force-tlsv13
```

このオプションは、このリスナーから作成するSSL接続で、TLSv1.3だけを使用するよう強制します。グローバル設定の"ssl-default-bind-options"でも使用できます。"ssl-min-ver"と"ssl-max-ver"も参照してください。

<a id="entry-5-1-generate-certificates"></a>

**`generate-certificates`**

```haproxy
generate-certificates
```

この設定は、OpenSSLのサポートを組み込んでビルドした場合だけ使用できます。SSL証明書の動的生成を有効にします。CA証明書とその秘密鍵が必要です（'ca-sign-file'を参照）。HAProxyを透過フォワードプロキシとして設定すると、クライアントに提示する証明書のCommon Nameが一致しないため、SSLリクエストでエラーが発生します。このオプションを有効にすると、クライアントがSNIで指定したホスト名を使い、HAProxyが証明書の生成を試みます。実行するのは、SNIのホスト名に一致する証明書がない場合だけです（'crt-list'を参照）。

証明書の生成時にエラーが起きた場合、接続ではデフォルト証明書にフォールバックします。'strict-sni'を使用している場合はデフォルト証明書を使用せず、ハンドシェイクの失敗になります。

HAProxyをリバースプロキシとして設定した場合に、多数のバックエンドを持つ構成の導入を容易にするためにも使用できます。

SSL証明書の作成はコストの高い処理なので、生成した証明書の保存にLRUキャッシュを使用します（'tune.ssl.ssl-ctx-cache-size'を参照）。HAProxyのメモリー使用量は増えますが、同じ証明書を何度も使用する場合の遅延を減らします。

<a id="entry-5-1-gid"></a>

**`gid <gid>`**

```haproxy
gid <gid>
```

UNIXソケットのグループを、指定したシステムのgidに設定します。globalセクションの"unix-bind"ステートメントでデフォルトを設定することもできます。一部のプラットフォームでは、単に無視されます。グループ名ではなくグループIDを使う点を除き、"group"設定と同じです。UNIX以外のソケットでは無視します。

<a id="entry-5-1-group"></a>

**`group <group>`**

```haproxy
group <group>
```

UNIXソケットのグループを、指定したシステムのグループに設定します。globalセクションの"unix-bind"ステートメントでデフォルトを設定することもできます。一部のプラットフォームでは、単に無視されます。gidではなくグループ名を使う点を除き、"gid"設定と同じです。UNIX以外のソケットでは無視します。

<a id="entry-5-1-guid-prefix"></a>

**`guid-prefix <string>`**

```haproxy
guid-prefix <string>
```

このbind行で割り当てる各リッスンソケットに、大文字と小文字を区別するグローバルで一意のIDを生成します。プレフィックスと、現在のbind行におけるリスナーの位置インデックスを、'-'を区切り文字として連結します。形式の詳細は、プロキシキーワード"guid"の説明を参照してください。"shm-stats-file"も参照してください。

<a id="entry-5-1-id"></a>

**`id <id>`**

```haproxy
id <id>
```

ソケットIDを固定します。デフォルトでは自動的に割り当てますが、監視を容易にするために固定した方が便利な場合があります。値は厳密に正であり、リスナーまたはフロントエンド内で一意でなければなりません。このオプションは、単一のソケットだけを定義する場合にのみ使用できます。

<a id="entry-5-1-idle-ping"></a>

**`idle-ping <delay>`**

```haproxy
idle-ping <delay>
```

使用可能なコンテキスト：tcp, http, log

アイドル状態のフロントエンド接続で、定期的に生存確認を行う間隔を定義します。次の確認予定時刻までに相手が応答できない場合、接続を閉じます。応答があれば、クライアントのタイムアウトを更新し、接続を維持します。http-requestとhttp-keep-aliveのタイマーは並行して動作し、idle-pingでは更新しません。

この機能には、基盤となるプロトコルの対応が必要です。現在、実装しているのはH2 muxだけです。ほかのプロトコルでは、idle-pingを単に無視します。

このオプションは、リバースHTTPを使用する場合に特に有用です。bind行に設定すると、能動的に接続を開始する役割を持ち、その接続を通じて着信トラフィックを受け取るピアに役立ちます。

<a id="entry-5-1-interface"></a>

**`interface <interface>`**

```haproxy
interface <interface>
```

ソケットの使用を特定のインターフェースに限定します。指定すると、そのインターフェースで受信したパケットだけをソケットが処理します。現在、Linuxでのみサポートしています。インターフェースには、別名のインターフェースではなく、システムのプライマリーインターフェースを指定する必要があります。異なるインターフェースにバインドする場合には、複数のフロントエンドを同じアドレスにバインドすることもできます。ネットワークインターフェースへのバインドにはroot権限が必要です。このパラメーターはTCPv4/TCPv6ソケットにのみ対応します。指定すると、別のインターフェースを通る明示的な経路が設定されていても、戻りのトラフィックは受信時と同じインターフェースと、それに対応するルーティングテーブルを使います。同じクライアントIPアドレスから、異なるインターフェース上のフロントエンドに到達する必要がある場合、非対称ルーティングの問題を解消するのに役立ちます。

<a id="entry-5-1-ktls"></a>

**`ktls <on|off> [ EXPERIMENTAL ]`**

```haproxy
ktls <on|off> [ EXPERIMENTAL ]
```

対象のソケットでktlsを有効または無効にします。有効にした場合、カーネルがサポートし、暗号にも互換性があれば、kTLSを使用します。Linuxカーネル4.17以降でのみ使用できます。ネットワークドライバーやTLSスタックによっては、kTLSの使用がTLS v1.2だけに制限される場合があります。"force-tlsv12"も参照してください。

<a id="entry-5-1-label"></a>

**`label <label>`**

```haproxy
label <label>
```

対象のソケットに任意のラベルを設定します。bind行を宣言した場所とは無関係に、ラベルでソケットをまとめるために使用できます。

<a id="entry-5-1-level"></a>

**`level <level>`**

```haproxy
level <level>
```

この設定は統計ソケットでのみ使用し、そのソケットで実行できるコマンドの種類を制限します。ほかのソケットでは無視します。`<level>`には次のいずれかを指定できます。

- "user"は、最も権限の低いレベルです。機密性のない統計情報だけを読み取ることができ、変更は一切許可しません。ソケットへのアクセスを簡単には制限できないシステムに適しています。
- "operator"はデフォルトのレベルで、一般的な用途の大半に適しています。すべてのデータを読み取れますが、影響の小さい変更だけを許可します（最大値カウンターのクリアなど）。
- "admin"は、すべての操作が許可されるため（すべてのカウンターのクリアなど）、慎重に使用することを推奨します。

<a id="entry-5-1-maxconn"></a>

**`maxconn <maxconn>`**

```haproxy
maxconn <maxconn>
```

ソケットの同時接続数を指定値に制限します。上限を超える接続は、接続が解放されるまで、システムのバックログに残ります。未指定の場合、上限はフロントエンドのmaxconnと同じです。ポート範囲や複数のアドレスを指定している場合、同じ値を各ソケットに適用します。この設定により、すべてのメモリーを消費しやすいSSLの入り口など、コストの高いソケットに異なる上限を設定できます。

<a id="entry-5-1-mode"></a>

**`mode <mode>`**

```haproxy
mode <mode>
```

UNIXソケットのアクセス権限を定義するモードを、八進数で設定します。globalセクションの"unix-bind"ステートメントでデフォルトを設定することもできます。一部のプラットフォームでは、単に無視されます。UNIX以外のソケットでは無視します。

<a id="entry-5-1-mss"></a>

**`mss <maxseg>`**

```haproxy
mss <maxseg>
```

受信接続に対して通知するTCPのMaximum Segment Size（MSS）を設定します。たとえばVPNを通過する接続など、特定のポートに対して小さいMSSを強制するために使えます。これはカーネルの機能に依存します。Linuxでは理論上サポートしていますが、2.6.28より前のすべてのバージョンには不具合がありました。ほかのOSでは、動作する場合もしない場合もあります。また、通知する値は変えず、送出するセグメントの実際のサイズだけを変える場合もあります。Ethernetネットワーク上のTCPv4で一般に通知される値は、1460 = 1500(MTU) - 40(IP+TCP)です。指定値が正の場合、その値をMSSとして通知します。負の場合、受信接続が通知したMSSから、送出セグメント用にどれだけ減らすかを示します。このパラメーターはTCP v4/v6ソケットにのみ対応します。

<a id="entry-5-1-name"></a>

**`name <name>`**

```haproxy
name <name>
```

これらのソケットに任意の名前を設定します。名前は統計ページに表示されます。

<a id="entry-5-1-namespace"></a>

**`namespace <name>`**

```haproxy
namespace <name>
```

Linuxでは、ソケットが属するネットワーク名前空間を指定できます。このディレクティブを使うと、デフォルト以外の名前空間にリスナーを明示的にバインドできます。ネットワーク名前空間の詳細は、OSのドキュメントを参照してください。

<a id="entry-5-1-nbconn"></a>

**`nbconn <nbconn> [ EXPERIMENTAL ]`**

```haproxy
nbconn <nbconn> [ EXPERIMENTAL ]
```

この設定は、リバースHTTPを使用するリスナーのインスタンスでのみ有効です。並列に確立する接続の数を定義します。指定しない場合、デフォルト値の1を使用します。

リバースHTTPは、現在も活発に開発されています。今後、設定の仕組みが変わる可能性があります。そのため、内部では実験的とされており、このディレクティブより前の行に"expose-experimental-directives"を指定しなければなりません。

<a id="entry-5-1-nice"></a>

**`nice <nice>`**

```haproxy
nice <nice>
```

ソケットから開始する接続の'niceness'を設定します。値は両端を含む-1024..1024の範囲でなければならず、デフォルトはゼロです。正の値の接続は、ほかの接続に配慮し、スケジューラー内で実行順を譲りやすくなります。反対に、負の値の接続は、ほかの接続よりも高い優先度で実行しようとします。違いが現れるのは、システムが飽和に近い高負荷時だけです。低遅延のサービスや管理用サービスには負の値が適しており、遅延の影響を受けにくいSSL処理や大量転送など、CPUを多く使う処理には一般に大きい値を推奨します。たとえば、SMTPソケットに正の値、RDPソケットに負の値を使うとよい場合があります。

<a id="entry-5-1-no-alpn"></a>

**`no-alpn`**

```haproxy
no-alpn
```

ALPNの処理を無効にします（技術的には、ALPN文字列を通知されない空文字列に設定します）。以前の"alpn"設定を取り消し、アプリケーションプロトコルのネゴシエーションを無効にできます。HTTPSまたはQUICのリスナーがクライアントとALPNをネゴシエーションするのを防ぐためにも使えます。デフォルトでは、HTTPSリスナーは"h2,http/1.1"を、QUICリスナーは"h3"を通知します。上記の"alpn"も参照してください。"crt-list"を使う場合、証明書によって"alpn"設定が上書きされ、処理が再び有効になることがある点に注意してください。

<a id="entry-5-1-no-ca-names"></a>

**`no-ca-names`**

```haproxy
no-ca-names
```

この設定は、OpenSSLのサポートを組み込んでビルドした場合だけ使用できます。ca-fileを使う場合、server helloメッセージでCA名を送信しないようにします。"no-ca-names"と"ca-file"を組み合わせる代わりに、"ca-verify-file"を使用してください。

<a id="entry-5-1-no-sslv3"></a>

**`no-sslv3`**

```haproxy
no-sslv3
```

この設定は、OpenSSLのサポートを組み込んでビルドした場合にのみ使用できます。SSLがサポートされている場合、リスナーから生成されるすべてのソケットでSSLv3のサポートを無効にします。SSLv2はコード内で強制的に無効にされており、どの設定オプションでも有効にはできません。このオプションは、globalの"ssl-default-bind-options"文でも指定できます。代わりに"ssl-min-ver"と"ssl-max-ver"を使用してください。

<a id="entry-5-1-no-strict-sni"></a>

**`no-strict-sni`**

```haproxy
no-strict-sni
```

この設定は、OpenSSLのサポートを組み込んでビルドした場合だけ使用できます。前の"strict-sni"ディレクティブによるstrict-sniの強制を無効にします。"ssl-default-bind-options"でグローバルに強制済みの場合、特定の"bind"行でstrict-sniの使用を無効にするために必要になることがあります。bindの"strict-sni"オプションも参照してください。

<a id="entry-5-1-no-tls-tickets"></a>

**`no-tls-tickets`**

```haproxy
no-tls-tickets
```

この設定は、OpenSSLのサポートを組み込んでビルドした場合だけ使用できます。ステートレスなセッション再開（RFC 5077 TLS Ticket拡張）を無効にし、ステートフルなセッション再開の使用を強制します。ステートレスなセッション再開は、CPU使用量がより多くなります。このオプションは、グローバル設定の"ssl-default-bind-options"でも使用できます。TLSチケットの仕組みを使用するのはTLS 1.2までです。チケットの鍵を定期的にローテーションしない限り（リロード、または"tls-ticket-keys"を使用）、TLSチケットによって前方秘匿性が損なわれます。

<a id="entry-5-1-no-tlsv10"></a>

**`no-tlsv10`**

```haproxy
no-tlsv10
```

この設定は、OpenSSLのサポートを組み込んでビルドした場合にのみ使用できます。SSLがサポートされている場合、リスナーから生成されるすべてのソケットでTLSv1.0のサポートを無効にします。SSLv2はコード内で強制的に無効にされており、どの設定オプションでも有効にはできません。このオプションは、globalの"ssl-default-bind-options"文でも指定できます。代わりに"ssl-min-ver"と"ssl-max-ver"を使用してください。

<a id="entry-5-1-no-tlsv11"></a>

**`no-tlsv11`**

```haproxy
no-tlsv11
```

この設定は、OpenSSLのサポートを組み込んでビルドした場合にのみ使用できます。SSLがサポートされている場合、リスナーから生成されるすべてのソケットでTLSv1.1のサポートを無効にします。SSLv2はコード内で強制的に無効にされており、どの設定オプションでも有効にはできません。このオプションは、globalの"ssl-default-bind-options"文でも指定できます。代わりに"ssl-min-ver"と"ssl-max-ver"を使用してください。

<a id="entry-5-1-no-tlsv12"></a>

**`no-tlsv12`**

```haproxy
no-tlsv12
```

この設定は、OpenSSLのサポートを組み込んでビルドした場合にのみ使用できます。SSLがサポートされている場合、リスナーから生成されるすべてのソケットでTLSv1.2のサポートを無効にします。SSLv2はコード内で強制的に無効にされており、どの設定オプションでも有効にはできません。このオプションは、globalの"ssl-default-bind-options"文でも指定できます。代わりに"ssl-min-ver"と"ssl-max-ver"を使用してください。

<a id="entry-5-1-no-tlsv13"></a>

**`no-tlsv13`**

```haproxy
no-tlsv13
```

この設定は、OpenSSLのサポートを組み込んでビルドした場合にのみ使用できます。SSLがサポートされている場合、リスナーから生成されるすべてのソケットでTLSv1.3のサポートを無効にします。SSLv2はコード内で強制的に無効にされており、どの設定オプションでも有効にはできません。このオプションは、globalの"ssl-default-bind-options"文でも指定できます。代わりに"ssl-min-ver"と"ssl-max-ver"を使用してください。

<a id="entry-5-1-npn"></a>

**`npn <protocols>`**

```haproxy
npn <protocols>
```

TLSのNPN拡張を有効にし、指定したプロトコルリストを、NPNで選択できる上位プロトコルとして通知します。リストはプロトコル名をカンマで区切ったもので、たとえば"http/1.1,http/1.0"（引用符なし）です。SSLライブラリーを、TLS拡張のサポートを有効にしてビルドしている必要があります（haproxy -vvで確認できます）。NPN拡張はALPN拡張に置き換えられています（"alpn"キーワードを参照）が、ALPNはOpenSSL 1.0.2以降でしか使用できません。古いバージョンのOpenSSLでHTTP/2を使いたい場合、執筆時点ではほとんどのクライアントがNPNを引き続きサポートしているため、NPNを使用できる可能性があります。NPNとALPNの両方を有効にすることもできますが、試験以外での意味はおそらくありません。

<a id="entry-5-1-prefer-client-ciphers"></a>

**`prefer-client-ciphers`**

```haproxy
prefer-client-ciphers
```

暗号スイートの選択時に、クライアントの優先順位を使用します。デフォルトでは、サーバーの優先順位を強制します。グローバル設定の"ssl-default-bind-options"でも使用できます。

OpenSSL \>= 1.1.1では、クライアントの暗号リストの先頭がChaCha20-Poly1305の場合、このオプションを設定しなくても、ChaCha20-Poly1305の優先順位が変更されます。

二つのアルゴリズム（RSA + ECDSA）を使う構成では、選択アルゴリズムはRSAとECDSAから選び、常にECDSAを優先します。適切な証明書を選択した後、暗号や曲線などの優先順位付けはSSLライブラリーに委ねます。つまり、このオプションでは、ECDSA証明書よりRSA証明書を優先できません。

<a id="entry-5-1-proto"></a>

**`proto <name>`**

```haproxy
proto <name>
```

受信接続に使用するマルチプレクサーのプロトコルを強制的に指定します。フロントエンドのモード（TCPまたはHTTP）と互換性がなければなりません。また、フロントエンド側で使用できる必要があります。利用可能なプロトコルの一覧はhaproxy -vvで表示されます。プロトコルの属性として、モード（TCP/HTTP）、使用側（FE/BE）、mux名、フラグが表示されます。

一部のプロトコルでは、サーバー側でヘッドオブラインブロッキングが起こります（flag=HOL_RISK）。また、アップグレードをサポートしないプロトコルもあります（flag=NO_UPG）。HTXとの互換性も表示します（flag=HTX）。

bind行の"proto"ディレクティブの引数に使用できるプロトコルは、次のとおりです。

```text
quic: mode=HTTP  side=FE|BE  mux=QUIC  flags=HTX|NO_UPG|FRAMED
 qmux: mode=HTTP  side=FE|BE  mux=QMUX  flags=HTX|NO_UPG
 h2  : mode=HTTP  side=FE|BE  mux=H2    flags=HTX|HOL_RISK|NO_UPG
 h1  : mode=HTTP  side=FE|BE  mux=H1    flags=HTX|NO_UPG
 none: mode=TCP   side=FE|BE  mux=PASS  flags=NO_UPG
```

このオプションの目的は、このリッスンソケットから作成するすべての接続について、最適なマルチプレクサーのプロトコルを選ぶ処理を迂回することです。たとえば、bind行に"proto h2"を指定すると、平文TCP上でhttp/2を強制できます。

ALPNまたはNPNの設定を行っている場合、問題を避けるため、指定するプロトコルはマルチプレクサーのプロトコルと互換性のあるものにすることを推奨します。たとえば、"proto h1"を設定した場合、ALPNを"h2"に設定することは推奨しません。

QMuxは、TCP上で動作するQUICのサブセットです。次のプロトコルのドラフトに対応します：<https://www.ietf.org/archive/id/draft-ietf-quic-qmux-01.html>。現在、haproxyでは実験的とみなされています。

<a id="entry-5-1-quic-cc-algo"></a>

**`quic-cc-algo { cubic | newreno | bbr | nocc }[(<args,...>)]`**

```haproxy
quic-cc-algo { cubic | newreno | bbr | nocc }[(<args,...>)]
```

これはQUIC専用の設定で、設定したQUICリスナーへの接続試行に使用する輻輳制御アルゴリズムを選びます。TCPで使うアルゴリズムに似ています。

パケット損失を減らし、スループットを向上させるため、輻輳制御アルゴリズムに加えてペーシングが有効になります。globalキーワード"tune.quic.fe.tx.pacing"で無効にできます。ほとんどの場合、ペーシングは有効にしておくべきです。特にBBRは、想定どおりに動作するためにペーシングに依存します。ペーシングなしでBBRを使うと、転送が遅くなったり、パケット損失率が高くなったりする可能性があります。

デフォルト値：cubic

さらに調整するため、アルゴリズムを示すトークンの後に、パラメーターのリストを指定できます。括弧で囲み、カンマで区切って記述する必要があります。各引数は省略可能で、必要に応じて空にできます。各パラメーターは、必ず次の順序にします。

- バイト単位の最大ウィンドウサイズです。10kを上回り、4gを下回る必要があります。デフォルトでは"tune.quic.fe.cc.max-win-size"の値を使用します。

例：

```shell
# newreno congestion control algorithm
quic-cc-algo newreno
# cubic congestion control algorithm with one megabytes as window
quic-cc-algo cubic(1m)
```

特別な値"nocc"を使うと、輻輳ウィンドウを常に最大サイズに固定できます。輻輳制御による副作用を取り除く、デバッグ用途専用です。高いパケット損失率などのネットワークの問題をすぐに引き起こす可能性があるため、本番環境で使用してはいけません。

<a id="entry-5-1-quic-force-retry"></a>

**`quic-force-retry`**

```haproxy
quic-force-retry
```

これはQUIC専用の設定で、設定したQUICリスナーへのすべての接続試行で、QUIC Retry機能の使用を強制します。新しい接続を開始したときに使ったトランスポートアドレスで、相手がパケットを受信できるかを確認します。そのために、トークンを含むRetryパケットを相手に送ります。相手は、このトークンをRetryパケットの送信者へ返す必要があります。トークンを検証できるのは、その送信者だけです。Retryのしきい値を設定していても、QUIC Retryは常に使用します（"tune.quic.fe.sec.retry-threshold"設定を参照）。

この設定にはクラスターシークレットの設定が必要で、設定されていない場合は起動時にエラーを報告します（"cluster-secret"を参照）。

QUIC Retryの詳細は、<https://www.rfc-editor.org/rfc/rfc9000.html#section-8.1.2>を参照してください。

<a id="entry-5-1-quic-socket"></a>

**`quic-socket [ connection | listener ]`**

```haproxy
quic-socket [ connection | listener ]
```

このQUIC専用の設定では、特定のリスナーのソケット割り当てモードを定義できます。各モードの長所と短所の詳しい説明は、"tune.quic.fe.sock-per-conn"を参照してください。

この設定は、globalの"tune.quic.fe.sock-per-conn"オプションと組み合わせて適用されます。グローバル設定で"default-on"モードが有効な場合（これが既定値）、"quic-socket listener"を指定したリスナーを除き、各QUIC接続は専用のソケットを使用します。ただし、グローバルモードが"force-off"に設定されている場合、個々のリスナーの設定は無視されます。

<a id="entry-5-1-severity-output"></a>

**`severity-output <format>`**

```haproxy
severity-output <format>
```

この設定は統計ソケット専用で、情報を返すフィードバックメッセージの先頭に付ける重大度の出力を設定します。メッセージの重大度は、syslog rfc5424に従う0から7の範囲です。データを要求する有効なソケットコマンド（"show map"、"get acl foo"など）が正常に実行された場合、その出力に重大度が付くことはありません。ほかのソケットでは無視されます。`<format>`には、次のいずれかを指定できます。

- "none"（デフォルト）：フィードバックメッセージの先頭に重大度を付けません。
- "number"：重大度を数値として先頭に付けます。
- "string"：rfc5424の規約に従った文字列として、重大度を先頭に付けます。

<a id="entry-5-1-shards"></a>

**`shards { <number> | by-thread | by-group }`**

```haproxy
shards { <number> | by-thread | by-group }
```

マルチスレッドモードで、同じIP:portに複数のリスナーを配置できるOSでは、同じ行に対して、指定した数の同一のリスナーを自動的に作成します。元のリスナーに割り当てたスレッドを均等に分けて、それぞれに割り当てます。スレッド数が非常に多く、単一ソケットに対するカーネル内のロックが大きなオーバーヘッドを生む場合に、役立つことがあります。この場合、受信トラフィックを複数のソケットに分散し、競合を減らします。ただし、多くのスレッドが少しずつ動くようになるため、CPU使用量が増えやすいことに注意してください。

シャード数が使用可能なスレッド数を超える場合、スレッド数まで自動的に減らします（つまり、スレッドごとに一つのシャードになります）。特殊な値"by-thread"も、"bind"行のスレッド数と同じ数のシャードを作成します。システムが受信トラフィックをすべてのシャードへ均等に分散するため、シャード数はスレッド数を割り切れる整数であることが重要です。別の特殊な値"by-group"を使うと、スレッドグループごとに一つのシャードを作成します。多数のスレッドを扱い、ソケットを増やしすぎたくない場合に役立ちます。負荷分散はやや最適さを欠きますが、競合（特にシステム内の競合）は、単一ソケットの場合よりも少なくなります。

同じアドレスへの複数ソケットのバインドをサポートしないOSでは、"by-thread"と"by-group"は、自動的に単一シャードへフォールバックします。"by-group"の場合、単一グループでは何も変わらず、どのみちグループごとにソケットが複製されるため、警告は出しません。一方、"by-thread"では、作成されるリスナー数が想定と異なるため、この状況になると診断用の警告を出します。

<a id="entry-5-1-sigalgs"></a>

**`sigalgs <sigalgs>`**

```haproxy
sigalgs <sigalgs>
```

この設定は、OpenSSLのサポートを組み込んでビルドした場合にのみ使用できます。TLSv1.2とTLSv1.3のハンドシェイク中にネゴシエーションする署名アルゴリズムのリストを表す文字列を設定します。文字列の形式は、OpenSSLのmanページ"man 3 SSL_CTX_set1_sigalgs"に定義されています。中間装置との互換性が必要な場合を除き、この設定の使用は推奨しません。

<a id="entry-5-1-ssl"></a>

**`ssl`**

```haproxy
ssl
```

この設定は、OpenSSLのサポートを組み込んでビルドした場合にのみ使用できます。このリスナーから生成される接続でSSLの復号を有効にします。証明書が必要です（前述の"crt"を参照）。バッファー内の内容はすべて平文になるため、ACLとHTTPの処理がアクセスするのは復号済みの内容だけです。SSLv3は既定では無効です。有効にするには"ssl-min-ver SSLv3"を使用してください。

<a id="entry-5-1-ssl-max-ver"></a>

**`ssl-max-ver [ SSLv3 | TLSv1.0 | TLSv1.1 | TLSv1.2 | TLSv1.3 ]`**

```haproxy
ssl-max-ver [ SSLv3 | TLSv1.0 | TLSv1.1 | TLSv1.2 | TLSv1.3 ]
```

このオプションは、このリスナーから作成するSSL接続で、`<version>`以下のバージョンを使用するよう強制します。今後のHAProxyではssl-min-verのデフォルト値が変わる可能性があるため、"ssl-min-ver"を伴わずにこの設定を使うと、意味が曖昧になることがあります。グローバル設定の"ssl-default-bind-options"でも使用できます。"ssl-min-ver"も参照してください。

<a id="entry-5-1-ssl-min-ver"></a>

**`ssl-min-ver [ SSLv3 | TLSv1.0 | TLSv1.1 | TLSv1.2 | TLSv1.3 ]`**

```haproxy
ssl-min-ver [ SSLv3 | TLSv1.0 | TLSv1.1 | TLSv1.2 | TLSv1.3 ]
```

このオプションは、このリスナーから作成するSSL接続で、`<version>`以上のバージョンを使用するよう強制します。デフォルト値は"TLSv1.2"です。グローバル設定の"ssl-default-bind-options"でも使用できます。"ssl-max-ver"も参照してください。

<a id="entry-5-1-strict-sni"></a>

**`strict-sni`**

```haproxy
strict-sni
```

この設定は、OpenSSLのサポートを組み込んでビルドした場合だけ使用できます。クライアントが証明書に一致するSNIを送った場合だけ、SSL/TLSのネゴシエーションを許可します。デフォルトの証明書は使用しません。このオプションを使うと、bind行に証明書がなくても起動できるため、空のディレクトリを指定し、後から統計ソケット経由で追加することができます。グローバル設定の"ssl-default-bind-options"でも使用でき、"bind"行の"no-strict-sni"で個別に無効にできます。詳細は"crt"オプションを参照してください。管理ガイドの"add ssl crt-list"コマンドも参照してください。

<a id="entry-5-1-tcp-md5sig"></a>

**`tcp-md5sig <password>`**

```haproxy
tcp-md5sig <password>
```

このリッスンソケットから作成するすべての受信接続で、TCP MD5署名（RFC 2385 Protection of BGP Sessions via the TCP MD5 Signature Option）を有効にします。このオプションはLinuxでのみ使用できます。有効にすると、`<password>`文字列を使い、すべてのTCPセグメントに16バイトのMD5ダイジェストで署名します。これにより、TCP接続をなりすましから保護します。主な用途は、偽造されたTCPセグメントが接続ストリームに挿入される攻撃から、BGPを保護することです。ただし、非常に長く存続するTCP接続全般で役立つ場合があります。

<a id="entry-5-1-tcp-ss"></a>

**`tcp-ss <mode>`**

```haproxy
tcp-ss <mode>
```

このリッスンソケットから作成するすべての受信接続に、TCP Save SYNオプションを設定します。このオプションはLinux 4.3以降で使用できます。TCPのSYNフラグを含む受信IPパケットのコピーの保持を試みるよう、カーネルに指示します。後で"fc_saved_syn"サンプル取得関数で調べるためです。このオプションには3つのモードがあります。- 0はSYNパケットの保存を無効にします。これがデフォルトです。- 1はSYNパケットの保存を有効にし、IPとTCPのヘッダーを含めます。- 2はSYNパケットの保存を有効にし、ETH、IP、TCPのヘッダーを含めます。

通常のTCP接続でのみ動作し、UNIXソケットなど、ほかのプロトコルでは無視します。"fc_saved_syn"も参照してください。

<a id="entry-5-1-tcp-ut"></a>

**`tcp-ut <delay>`**

```haproxy
tcp-ut <delay>
```

このリッスンソケットから作成するすべての受信接続に、TCP User Timeoutを設定します。このオプションはLinux 2.6.37以降で使用できます。指定した時間内に確認応答を受け取れないデータを含むソケットに対し、HAProxyがタイムアウトを設定できるようにします。リモート端末やデータベースの接続プールなど、長いアイドル期間のある長時間接続で特に役立ちます。そのような接続では、長いアイドル期間を許容するために、クライアントとサーバーのタイムアウトを長く保つ必要があります。一方、接続（およびサーバーのセッション）に関連するすべてのリソースを解放するため、クライアントが消失したことを検出するのも重要です。引数は時間で、デフォルトの単位はミリ秒です。通常のTCP接続だけに作用し、ほかのプロトコルでは無視します。

<a id="entry-5-1-tfo"></a>

**`tfo`**

```haproxy
tfo
```

Linuxカーネル\>= 3.7でのみサポートする、省略可能なキーワードです。リッスンソケットでTCP Fast Openを有効にします。この機能に対応したクライアントは、二回目の接続から、3ウェイハンドシェイク中にリクエストを送ってレスポンスを受け取れるようになります。そのため、初回接続後は一往復を省略できます。接続頻度が高く、一往復ごとの遅延が重要なプロトコルでのみ意味があります。SYNパケット上のデータを受け付けない多くのファイアウォールで問題が起きる可能性があるため、十分に試験してから有効にすることを推奨します。このオプションはTCPv4/TCPv6ソケットでのみサポートし、ほかのソケットでは無視します。libcがTCP_FASTOPENを定義していない場合、USE_TFO=1を指定してHAProxyをビルドする必要があるかもしれません。

<a id="entry-5-1-thread"></a>

**`thread [<thread-group>/]<thread-set>[,...]`**

```haproxy
thread [<thread-group>/]<thread-set>[,...]
```

このリスナーを実行できるスレッドのリストを制限します。特定のスレッドに強制するものではなく、一致しないスレッドを除外します。このリスナーへの受信接続を処理できるスレッドを制限します。

番号の指定方法は二種類あります。デフォルトでは、スレッド番号はプロセス内の絶対番号で、1からglobal.nbthreadの指定値までです。スレッドグループ番号を先に指定し、スラッシュ('/')と、そのグループ内での相対スレッド番号を続けることもできます。この場合も番号は1から始まり、プラットフォームに応じて32または64までです。絶対番号を指定した場合、スレッドグループが判明した時点で、自動的に相対番号へ変換します。通常、単純な設定では絶対番号が、CPU配置が性能に影響する複雑な設定では相対番号が適しています。

任意指定のスレッドグループ番号の後に続く"thread-set"は、次の形式で指定しなければなりません。

```text
"all" | "odd" | "even" | [number][-[number]]
```

名前のとおり、"all"は集合内のすべてのスレッドを有効にします（グループを指定していればグループ内のすべて、それ以外はプロセスのすべてのスレッド）。"odd"はプロセスまたはグループの奇数番号のスレッドすべて（1から始めて一つおき）を、"even"は偶数番号のスレッドすべて（2から始めて一つおき）を有効にします。代わりにスレッド番号の範囲を指定した場合は、最初から最後の番号まで、その範囲に含まれるすべてのスレッドを有効にします。番号は、スレッドグループ番号の有無に応じて、グループ内の相対番号または絶対番号になります。最初のスレッド番号を省略すると"1"になり、グループまたはプロセスの最初のスレッドを表します。最後のスレッド番号を省略すると、グループの最後の番号（32または64）、またはプロセスの最後の番号（global.nbthread）を使います。

これらの範囲はカンマで区切って繰り返し指定できるため、連続していないスレッドの集合も指定できます。グループを指定する場合は、新しい範囲ごとにグループを再指定しなければなりません。グループ内の相対指定と絶対指定を混在させることはできません。指定されていないものは解析の最後に解決されるため、"bind"行全体で絶対表記か相対表記のどちらかを使用する必要があります。

"bind"行で記述する各リスナーは、少なくとも一つのファイルディスクリプターで表される、少なくとも一つのソケットを作成する点を理解しておくことが重要です。ファイルディスクリプターは複数のスレッドグループをまたげないため、"bind"行のスレッド範囲が複数のグループにまたがる場合、グループごとに少なくとも一つずつになるよう、複数のファイルディスクリプターを自動的に作成します。技術的には、どれもカーネル内の同じソケットを参照していますが、haproxy内ではそれぞれ別の識別子を持ち、"option socket-stats"を使う場合は、個別の統計エントリーも持ちます。

主な目的は、リスナー内で、IP:portは同じでもスレッドが異なる複数のbind行を用意することです。これにより、システムが受信接続を複数のキューへ分配し、haproxy内部のキューの負荷分散を迂回できます。現在、Linux 3.9以降がこの機能をサポートすることが分かっています。"bind"行の複製と、複数のスレッド群への割り当てを自動化する、上記の"shards"キーワードも参照してください。

このキーワードはリバースHTTPのbindにも対応します。ただし、このようなリスナーでは、複数のスレッドグループにまたがるスレッド集合を指定することは禁止されています。"nbconn"が想定どおりに機能しなくなる可能性があるためです。

<a id="entry-5-1-tls-tickets"></a>

**`tls-tickets`**

```haproxy
tls-tickets
```

この設定は、OpenSSLのサポートを組み込んでビルドした場合にのみ使用できます。ステートレスなセッション再開（RFC 5077 TLS Ticket拡張）を有効にします。これは既定の動作ですが、"ssl-default-bind-options"に指定した"no-tls-tickets"で全体的に無効にした場合、特定の"bind"行でこの機能を再び有効にするために必要になることがあります。bindの"no-tls-tickets"キーワードも参照してください。

<a id="entry-5-1-tls-ticket-keys"></a>

**`tls-ticket-keys <keyfile>`**

```haproxy
tls-ticket-keys <keyfile>
```

TLSチケットの鍵を読み込むファイルを設定します。鍵の長さは、aes128とaes256のどちらを使うかに応じて48または80バイトでなければなりません。base64でエンコードし、一行に一つの鍵を記述します（例：openssl rand 80 \| openssl base64 -A \| xargs echo）。最初の鍵によって、それ以降の鍵に使う長さが決まります。aes128とaes256の鍵を混在させることはできません。鍵の数はビルドオプションTLS_TICKETS_NOで指定します（デフォルトは3）。ファイルには、少なくともその数の鍵が必要です。末尾のTLS_TICKETS_NO個の鍵を復号に使い、末尾から二番目の鍵を暗号化に使います。そのため、ファイルに新しい鍵を追加してプロセスをリロードするだけで、簡単に鍵をローテーションできます。鍵は定期的に（たとえば12hごとに）ローテーションしなければなりません。そうしないと、完全前方秘匿性が損なわれます。また、ハードドライブなどの永続ストレージには鍵を置かないことを推奨します（ヒント：tmpfsを使用し、これらのファイルをスワップアウトさせないでください）。有効期間のヒントはtune.ssl.timeoutで変更できます。

<a id="entry-5-1-transparent"></a>

**`transparent`**

```haproxy
transparent
```

一部のLinuxカーネルでのみサポートする、省略可能なキーワードです。ローカルマシンに属さないアドレスにもバインドし、それらのアドレス宛てのパケットを、ローカルに設定したアドレス宛てのパケットと同じように捕捉することを指定します。通常、IP転送が有効である必要があります。注意：デフォルトのアドレス'\*'と組み合わせないでください。指定ポート宛てのすべてのトラフィックをリダイレクトしてしまいます。このキーワードは、USE_LINUX_TPROXY=1でHAProxyをビルドした場合だけ使用できます。このパラメーターは、カーネルのバージョンに応じてTCPv4およびTCPv6ソケットにのみ対応します。一部のディストリビューションのカーネルには、この機能のバックポートが含まれているため、サポートの有無を提供元に確認してください。

<a id="entry-5-1-uid"></a>

**`uid <uid>`**

```haproxy
uid <uid>
```

UNIXソケットの所有者を、指定したシステムUIDに設定します。globalセクションの"unix-bind"文で既定値を設定することもできます。一部のプラットフォームでは、この設定は単に無視されます。ユーザー名の代わりに数値のユーザーIDを使うことを除けば、"user"設定と同じです。UNIX以外のソケットでは無視されます。

<a id="entry-5-1-user"></a>

**`user <user>`**

```haproxy
user <user>
```

UNIXソケットの所有者を、指定したシステムのユーザーに設定します。globalセクションの"unix-bind"ステートメントでデフォルトを設定することもできます。一部のプラットフォームでは、単に無視されます。uidではなくユーザー名を使う点を除き、"uid"設定と同じです。UNIX以外のソケットでは無視します。

<a id="entry-5-1-v4v6"></a>

**`v4v6`**

```haproxy
v4v6
```

Linuxカーネル \>= 2.4.21を含む最新のシステムでのみサポートされる、省略可能なキーワードです。既定のアドレスを使用する場合に、ソケットをIPv4とIPv6の両方にバインドするために使います。既定ではIPv6にのみバインドするシステムでは、この指定が必要になることがあります。IPv6以外のソケットには影響せず、"v6only"オプションが優先されます。

<a id="entry-5-1-v6only"></a>

**`v6only`**

```haproxy
v6only
```

Linuxカーネル\>= 2.4.21を含む最新のシステムでのみサポートされる、省略可能なキーワードです。デフォルトのアドレスを使用する場合に、ソケットをIPv6だけにバインドします。リスナーごとの設定なので、システム全体で設定するより望ましい場合があります。IPv6以外のソケットには効果がなく、"v4v6"オプションより優先されます。

<a id="entry-5-1-verify"></a>

**`verify [none|optional|required]`**

```haproxy
verify [none|optional|required]
```

この設定は、OpenSSLのサポートを組み込んでビルドした場合だけ使用できます。'none'の場合、クライアント証明書を要求しません。これがデフォルトです。それ以外の場合は、クライアント証明書を要求します。要求に対してクライアントが証明書を送らず、'verify'が'required'ならハンドシェイクを中断しますが、'optional'なら成功します。クライアントが送った証明書は、'ca-file'のCAと、任意指定の'crl-file'のCRLを使って常に検証します。検証に失敗すると、'verify'の値にかかわらずハンドシェイクを中断します。ただし、エラーコードが'ca-ignore-err'または'crt-ignore-err'に列挙したもののいずれかと完全に一致する場合は例外です。

## 5.2. serverとdefault-serverのオプション {#section-5-2}

"server"と"default-server"キーワードは、いくつかの設定をサポートし、すべてserver行の引数として指定します。引数の順序は問わず、どの引数も省略可能です。単語一つのもの（真偽値）もあれば、その後ろに一つ以上の値が必要なものもあります。値が必要な場合は、設定名の直後に記述しなければなりません。default-serverを除き、これらの設定を使う場合は、サーバーのアドレスより後ろに記述する必要があります。

```text
server <name> <address>[:port] [settings ...]
default-server [settings ...]
```

これらの設定はすべて、"server"と"default-server"の両方のキーワードでサポートされます。ただし、"id"は"server"でのみサポートされます。

現在サポートされている設定は次のとおりです。

<a id="entry-5-2-addr"></a>

**`addr <ipv4|ipv6>`**

```haproxy
addr <ipv4|ipv6>
```

使用可能なコンテキスト：tcp, http, log

"addr"パラメーターを使うと、ヘルスチェックの送信先やagent-checkの確認先に別のIPアドレスを使用できます。サーバーによっては、アプリケーション自体よりもヘルスチェックに適した複雑なテストを実行できる専用コンポーネントに、IPアドレスを割り当てることが望ましい場合があります。このパラメーターは、"check"パラメーターが設定されていない場合は無視されます。"port"パラメーターも参照してください。

<a id="entry-5-2-agent-check"></a>

**`agent-check`**

```haproxy
agent-check
```

使用可能なコンテキスト：tcp, http, log

通常のヘルスチェックとは独立して実行する、補助的なエージェントチェックを有効にします。エージェントによるヘルスチェックでは、"agent-port"パラメーターで設定したポートにTCP接続し、最初に現れた'&#92;r'または'&#92;n'で終わるASCII文字列を読み取ります。この文字列は、空白、タブ、カンマで区切られた単語を任意の順序で並べたものです。各単語は次のいずれかで構成されます。

- "75%"のように、正の整数の百分率をASCIIで表したもの。この形式の値は、HAProxyの起動時に設定したサーバーの初期の重みに対する割合として、重みを設定します。重みゼロは、サーバーに対して同じ効果（負荷分散対象から外すこと）があるため、統計ページでは"DRAIN"と表示します。これはサーバーの重みを設定する従来の方法です。"weight:"接頭辞を使う方法を推奨します。

- 文字列"weight:"の直後に、空白を入れずに正の整数または正の整数の百分率を続けたもの。値が'%'で終わる場合、新しい重みはサーバーの初期の重みに比例します。それ以外の場合、絶対的な重みとして扱い、0から256までの値でなければなりません。静的な負荷分散アルゴリズムを使うサーバー群に属するサーバーには、より厳しい制限があります。一度設定した重みを変更できないためです。このようなサーバーで受け付ける値は、0と100%（または0と初期の重み）だけです。変更はすぐに反映されますが、一部の負荷分散アルゴリズムでは、変更が反映されるまでに一定数のリクエストが必要です。重みゼロは、サーバーに対して同じ効果（負荷分散対象から外すこと）があるため、統計ページでは"DRAIN"と表示します。

- 文字列"maxconn:"の直後に整数を続けたもの（間に空白は入れません）。この形式の値は、サーバーのmaxconnを設定します。そのサーバーが受け入れる可能性のある接続の総数を求めるには、通知された最大接続数に、このヘルスチェックを使うロードバランサーと異なるバックエンドの数を掛ける必要があります。例: maxconn:30

- 単語"ready"。サーバーの管理状態をREADYモードにし、DRAINまたはMAINTの状態を取り消します。

- 単語"drain"。サーバーの管理状態をDRAINモードにします。その結果、永続性に基づいて受け入れるものを除き、新しい接続は受け入れません。

- 単語"maint"。サーバーの管理状態をMAINTモードにします。その結果、新しい接続を一切受け入れず、ヘルスチェックも停止します。

- 単語"down"、"fail"、"stopped"。必要に応じて、その後ろにシャープ('#')と説明文字列を続けられます。いずれもサーバーの稼働状態をDOWNにしますが、統計ページには単語そのものが表示されます。その違いにより、管理者は想定した状況かどうかを判断できます。サービスが意図的に停止されている場合、稼働しているように見えるものの何らかの妥当性の検査に失敗する場合、停止していると判断される場合（プロセスが存在しない、ポートが応答しないなど）を区別できます。

- 単語"up"は、ヘルスチェックでもサービスにアクセス可能と報告していれば、サーバーの稼働状態をUPに戻します。

エージェントが通知しないパラメーターは変更しません。たとえば、CPU使用率を監視し、相対的な重みだけを報告して、稼働状態には一切関与しないエージェントを作れます。同様に、管理者が管理状態だけを変更できる、3つのラジオボタンを持つ利用者向けインターフェースとして設計することもできます。ただし、エージェント自身が行った操作を元に戻せるのは、そのエージェントだけである点が重要です。エージェントでサーバーをDRAINモードやDOWN状態にした場合、サービスを再び稼働させるための、対応する逆の操作もエージェントに実装する必要があります。

接続性は"check"パラメーターで有効にする通常のヘルスチェックで調べるため、エージェントへの接続失敗はエラーとみなしません。ただし、"down"を報告した後にエージェントを停止することは推奨しません。サーバーを再び稼働状態にできるのは、"up"を報告するエージェントだけだからです。必要であれば、不具合のあるエージェントを回避するために、Unix統計ソケットのCLIでエージェントの結果を強制的に設定することもできます。

"agent-port"パラメーターを設定する必要があります。"agent-inter"と"no-agent-check"パラメーターも参照してください。

<a id="entry-5-2-agent-send"></a>

**`agent-send <string>`**

```haproxy
agent-send <string>
```

使用可能なコンテキスト：tcp, http, log

このオプションを指定すると、HAProxyは接続時に、指定された文字列をそのままエージェントサーバーに送信します。たとえば、文字列にバックエンド名を埋め込めば、エージェントがバックエンドに応じて異なる応答を返せます。リクエストを改行で終える場合は、必ず'&#92;n'を含めてください。

<a id="entry-5-2-agent-inter"></a>

**`agent-inter <delay>`**

```haproxy
agent-inter <delay>
```

使用可能なコンテキスト：tcp, http, log

"agent-inter"パラメーターは、エージェントチェックの間隔を`<delay>`ミリ秒に設定します。指定しない場合、間隔のデフォルトは2000 msです。

ほかの時間指定パラメーターと同様、{ us, ms, s, m, h, d }のいずれかの単位を明示して入力することもできます。"timeout check"を設定していない場合、"agent-inter"パラメーターはエージェントチェックのタイムアウトも兼ねます。同じハードウェア上で複数のサーバーを稼働させたときの「共振」の影響を減らすため、全サーバーのエージェントチェックとヘルスチェックは、開始時刻を少しずつずらしています。グローバルの"spread-checks"キーワードを使い、エージェントチェックとヘルスチェックの間隔にランダムな揺らぎを加えることもできます。たとえば、多数のバックエンドが同じサーバーを使う場合に有効です。

参照：パラメーター"agent-check"、"agent-port"。

<a id="entry-5-2-agent-addr"></a>

**`agent-addr <addr>`**

```haproxy
agent-addr <addr>
```

使用可能なコンテキスト：tcp, http, log

"agent-addr"パラメーターは、エージェントチェックのアドレスを設定します。

agent-checkを別の対象に委ねることができるため、自らを認識して管理するサービスを作成できない場合にも、HAProxyで定義したサーバーの状態や重みを一か所で管理できます。IPアドレスまたはホスト名を指定でき、ホスト名は名前解決されます。

<a id="entry-5-2-agent-port"></a>

**`agent-port <port>`**

```haproxy
agent-port <port>
```

使用可能なコンテキスト：tcp, http, log

"agent-port"パラメーターは、エージェントチェックに使用するTCPポートを設定します。

参照：パラメーター"agent-check"、"agent-inter"。

<a id="entry-5-2-allow-0rtt"></a>

**`allow-0rtt`**

```haproxy
allow-0rtt
```

使用可能なコンテキスト：tcp, http, log, peers, ring

TLS 1.3を使う場合に、サーバーへのearly dataの送信を許可します。送信するのは、クライアントがearly dataを使った場合、またはバックエンドで"retry-on"の"0rtt-rejected"キーワードを使っている場合だけです。QUICでは、QuicTLS、OpenSSL \>= 3.5.2、AWS-LCで0rttをサポートします。TCP/TLSで0rttをサポートするのはOpenSSLだけです。

<a id="entry-5-2-alpn"></a>

**`alpn <protocols>`**

```haproxy
alpn <protocols>
```

使用可能なコンテキスト：tcp, http

TLSのALPN拡張を有効にし、指定したプロトコルリストを、ALPNで選択できる上位プロトコルとして通知します。リストはプロトコル名をカンマで区切ったもので、たとえば"http/1.1,http/1.0"（引用符なし）です。SSLライブラリーを、TLS拡張のサポートを有効にしてビルドしている必要があります（haproxy -vvで確認できます）。ALPN拡張は、当初使われていたNPN拡張に代わるものです。HTTP/2サーバーへの接続にはALPNが必要です。QUICサーバー経由でHTTP/3を使うためにも必要で、"alpn"を設定していないQUICサーバーでは"h3"がデフォルト値です。OpenSSL 1.0.2より前のバージョンはALPNをサポートしておらず、現在では廃止されたNPN拡張だけをサポートしていました。HTTP/2とHTTP/1.1の両方をサポートする想定なら、次のように優先順に両方を通知できます。

```text
server 127.0.0.1:443 ssl crt pub.pem alpn h2,http/1.1
```

WebSocketストリームで別のALPNを使うには、"ws"も参照してください。

<a id="entry-5-2-backup"></a>

**`backup`**

```haproxy
backup
```

使用可能なコンテキスト：tcp, http, log

server行に"backup"がある場合、そのサーバーが負荷分散に使われるのは、ほかのバックアップではないサーバーがすべて利用できないときだけです。ただし、そのサーバーを参照する永続性Cookieを伴うリクエストは常に処理されます。既定では、backendに"allbackups"オプションが設定されていない限り、稼働中のバックアップサーバーのうち最初のものだけを使用します。"no-backup"と"allbackups"オプションも参照してください。

<a id="entry-5-2-ca-file"></a>

**`ca-file <cafile>`**

```haproxy
ca-file <cafile>
```

使用可能なコンテキスト：tcp, http, log, peers, ring

この設定は、OpenSSLのサポートを組み込んでビルドした場合にのみ使用できます。サーバー証明書の検証に使うCA証明書を読み込むPEMファイルを指定します。複数のCAを含むディレクトリを読み込むこともできます。その場合、HAProxyはディレクトリ内のすべての".pem"、".crt"、".cer"、".crl"ファイルの読み込みを試みます。名前がドットで始まるファイルは無視されます。

システムで信頼するCAを使うには、cafileの代わりに"@system-ca"パラメーターを使用できます。このディレクトリの場所は、SSL_CERT_DIR環境変数を設定して上書きできます。

<a id="entry-5-2-cc"></a>

**`cc <algo>`**

```haproxy
cc <algo>
```

使用可能なコンテキスト：tcp, http, log, peers, ring

この設定はTCP_CONGESTIONを定義しているシステムでのみ使用でき、LinuxとFreeBSDで検証されています。TCP輻輳制御アルゴリズムの名前を受け取り、発信接続でそのアルゴリズムを使うよう設定します。代表的な名前に"reno"や"cubic"がありますが、使用できるものはOSによって異なります。システムによっては、特定のアルゴリズムを設定するために特別な権限が必要な場合があります。Linuxでは、利用可能なアルゴリズムはsysctlの"net.ipv4.tcp_available_congestion_control"に、特権なしで使用を許可されているものは"net.ipv4.tcp_allowed_congestion_control"に一覧表示されます。追加の権限が必要なアルゴリズムを使うには、"cap_net_admin"ケーパビリティーが必要な場合があります（globalセクションの"setcap"を参照）。指定した輻輳制御アルゴリズムを設定できない場合、デフォルトのアルゴリズムをそのまま使います。bindキーワードの"cc"（[セクション5.1](/ja/docs/haproxy/bind-and-server-options/#section-5-1)）も参照してください。

<a id="entry-5-2-check"></a>

**`check`**

```haproxy
check
```

使用可能なコンテキスト：tcp, http, log

このオプションは、サーバーのヘルスチェックを有効にします。- 設定しない場合、ヘルスチェックは行わず、サーバーは常に利用可能とみなします。- 設定し、ほかのチェック方式を設定していない場合、設定されている最上位のトランスポート層で接続を確立できれば、サーバーは利用可能とみなします。デフォルトではTCP、"ssl"または"check-ssl"を設定した場合はSSL/TLSです。どちらの場合も、"send-proxy"や"check-send-proxy"を設定した際のPROXYプロトコルヘッダーなど、接続の接頭辞と組み合わせることができます。動的サーバーでは動作が少し異なります。詳細は後続の段落を参照してください。- 設定し、アプリケーション層のヘルスチェックを定義した場合、設定されたトランスポート層の上でアプリケーション層のやり取りを行い、そのすべてが成功すれば、サーバーは利用可能とみなします。

デフォルトでは、サーバーに設定したものと同じアドレスとポートで、同じカプセル化パラメーター（SSL/TLS、proxy-protocolヘッダーなど）を使ってヘルスチェックを行います。送信先アドレスは"addr"で、ポートは"port"で変更できます。変更した場合、サービス用ポートでのチェックではないとみなし、設定済みのカプセル化パラメーターは再利用しません。接続ヘッダーを送るには"check-send-proxy"を、SSL/TLSを使うには"check-ssl"を、明示的に設定する必要があります。

動的サーバーでは、sslとPROXYプロトコルの暗黙の設定は行いません。この場合、チェック用ポートを上書きしていなくても、必要な機能に応じて"check-ssl"と"check-send-proxy"を明示的に使用する必要があります。

server行に"sni"または"alpn"を設定しても、その値はヘルスチェックには使いません。"check-sni"または"check-alpn"を使用する必要があります。

ヘルスチェックのトラフィックのデフォルトの送信元アドレスは、バックエンドで定義したものと同じです。"source"キーワードで変更できます。

チェックの間隔は"inter"キーワードで設定でき、"rise"と"fall"で、サーバーを利用可能または利用不可と判断するために必要なヘルスチェックの成功回数や失敗回数を定義できます。

任意指定のアプリケーションレベルのヘルスチェックは、"option httpchk"、"option mysql-check"、"option smtpchk"、"option pgsql-check"、"option ldap-check"、"option redis-check"で設定できます。

例：

```shell
# simple tcp check
backend foo
  server s1 192.168.0.1:80 check
# this does a tcp connect + tls handshake
backend foo
  server s1 192.168.0.1:443 ssl check
# simple tcp check is enough for check success
backend foo
  option tcp-check
  tcp-check connect
  server s1 192.168.0.1:443 ssl check
```

<a id="entry-5-2-check-reuse-pool"></a>

**`check-reuse-pool`**

```haproxy
check-reuse-pool
```

使用可能なコンテキスト：tcp, http

利用可能なアイドル接続がある場合、チェック専用の接続を開く代わりに、その接続を再利用できるようにします。チェックが終わると、接続をプールに戻します。主な目的は、特定のサーバーに対する接続の開始と終了の回数を抑えることです。この機能はhttp-checkルールセットにのみ対応し、ほかのチェック方式では通知なしで無視します。また、チェックの試行ごとに専用セッションを使うため、バックエンドの再利用方針はaggressiveに設定することを推奨します。

設定を簡単にするため、server行または独自のtcp-check connectルールで、チェックの接続に固有のオプションを一つでも定義した場合、このオプションは通知なしで無視します。

パッシブなリバースHTTPゲートウェイとして動作するサーバーでは、再利用による接続だけをサポートするため、このオプションを自動的に有効にします。

参照："check-pool-conn-name"。

<a id="entry-5-2-check-send-proxy"></a>

**`check-send-proxy`**

```haproxy
check-send-proxy
```

使用可能なコンテキスト：tcp, http

サーバーが通常のトラフィックでsend-proxyを使うかどうかにかかわらず、送信するヘルスチェックにPROXYプロトコル行を付けるよう強制します。デフォルトでは、通常のトラフィックでPROXYプロトコルが有効になっており、"port"も"addr"も指定していなければ、ヘルスチェックでも有効になります。ただし、これらのディレクティブを指定している場合は、"check-send-proxy"オプションで使用を強制する必要があります。詳細は"send-proxy"オプションも参照してください。

<a id="entry-5-2-check-alpn"></a>

**`check-alpn <protocols>`**

```haproxy
check-alpn <protocols>
```

使用可能なコンテキスト：tcp, http

ALPNで通知するプロトコルを定義します。プロトコルのリストは、"http/1.1,http/1.0"（引用符なし）など、プロトコル名のカンマ区切りリストです。設定しない場合、サーバーのALPNを使用します。

<a id="entry-5-2-check-pool-conn-name"></a>

**`check-pool-conn-name <name>`**

```haproxy
check-pool-conn-name <name>
```

使用可能なコンテキスト：tcp, http

チェックで接続を再利用する場合、`<name>`を設定していれば接続の識別子として使用し、プール内の対応する接続を探します。serverキーワード"pool-conn-name"に相当します。このオプションを使用していない場合は、"check-sni"もフォールバックとして使用します。

参照："check-reuse-pool"。

<a id="entry-5-2-check-proto"></a>

**`check-proto <name>`**

```haproxy
check-proto <name>
```

使用可能なコンテキスト：tcp, http

サーバーのヘルスチェック接続に使用するマルチプレクサーのプロトコルを強制的に指定します。ヘルスチェックの種類（TCPまたはHTTP）と互換性がなければなりません。また、バックエンド側で使用できる必要があります。利用可能なプロトコルの一覧はhaproxy -vvで表示されます。プロトコルの属性として、モード（TCP/HTTP）、使用側（FE/BE）、mux名、フラグが表示されます。

一部のプロトコルでは、サーバー側でヘッドオブラインブロッキングが起こります（flag=HOL_RISK）。また、アップグレードをサポートしないプロトコルもあります（flag=NO_UPG）。HTXとの互換性も表示します（flag=HTX）。

server行の"check-proto"ディレクティブの引数に使用できるプロトコルは、次のとおりです。

```text
h2  : mode=HTTP  side=FE|BE  mux=H2    flags=HTX|HOL_RISK|NO_UPG
fcgi: mode=HTTP  side=BE     mux=FCGI  flags=HTX|HOL_RISK|NO_UPG
h1  : mode=HTTP  side=FE|BE  mux=H1    flags=HTX|NO_UPG
none: mode=TCP   side=FE|BE  mux=PASS  flags=NO_UPG
quic: mode=HTTP  side=FE|BE  mux=QUIC  flags=HTX|NO_UPG|FRAMED
spop: mode=SPOP  side=BE     mux=SPOP  flags=HOL_RISK|NO_UPG
```

このオプションの目的は、このサーバーに確立するヘルスチェック接続で、最適なマルチプレクサーのプロトコルを選ぶ処理を迂回することです。定義しない場合は、サーバー側の設定があれば、それを使用します。

ALPNまたはNPNの設定を行っている場合、問題を避けるため、指定するプロトコルはマルチプレクサーのプロトコルと互換性のあるものにすることを推奨します。たとえば、"proto h1"を設定した場合、ALPNを"h2"に設定することは推奨しません。

QUICのチェック設定は、まだ完全には実装されていません。まず、QUICチェックを行えるのはQUICサーバーだけです。また、QUICサーバーでチェックに固有の接続パラメーターを一つ以上指定すると、チェックのプロトコルはTCPの使用にフォールバックします。

<a id="entry-5-2-check-sni-auto"></a>

**`check-sni-auto`**

```haproxy
check-sni-auto
```

使用可能なコンテキスト：tcp, http, log

このオプションは、まだ値が設定されていなければ、SSLでヘルスチェックを行う際のSNIの自動選択を有効にします。デフォルトで有効ですが、"default-server"ディレクティブからデフォルト値として継承した"no-check-sni-auto"を取り消すため、"server"設定として使うこともできます。また、"default-server"設定として使い、以前の"default-server"の"no-check-sni-auto"設定を取り消すこともできます。

HTTPS接続では、"http-check connect"ルールがない場合に限り、SNIが自動的に選択されます。その場合、"option httpchk"ディレクティブまたは"http-check send"ルールで指定したHostヘッダーの値に基づいてSNIを選択します。"http-check connect"ルールでは自動選択は行われません。ほかのプロトコルでは、このオプションは無視されます。

ヘルスチェックでSNIの自動選択を使い、"check-reuse-pool"を設定している場合、選択した値を接続名に割り当てます。ただし、serverキーワード"check-pool-conn-name"で上書きした場合は除きます。

プロキシするトラフィックでSNIの自動選択を有効にするには、"sni-auto"オプションを参照してください。

<a id="entry-5-2-check-sni"></a>

**`check-sni <sni>`**

```haproxy
check-sni <sni>
```

使用可能なコンテキスト：tcp, http, log

SSL経由のヘルスチェックで使用するSNIを指定できます。`<sni>`を設定できるのは文字列だけです。プロキシするトラフィックのSNIを設定する場合は、"sni"を参照してください。

<a id="entry-5-2-check-ssl"></a>

**`check-ssl`**

```haproxy
check-ssl
```

使用可能なコンテキスト：tcp, http, log

サーバーが通常のトラフィックにSSLを使用するかどうかにかかわらず、すべてのヘルスチェックをSSLで暗号化するよう強制します。通常、"port"または"addr"ディレクティブを明示していて、SSLヘルスチェックが継承されない場合に使います。このオプションは、チェックの下にSSLトランスポート層を挿入する点を理解しておくことが重要です。そのため、単純なTCP接続チェックがSSL接続になり、従来のssl-hello-chkに代わるものになります。最も一般的な用途は、"httpchk"とSSLチェックを組み合わせてHTTPSのチェックを送ることです。暗号など、すべてのSSL設定はヘルスチェックとトラフィックに共通です。詳細は"ssl"オプションを、このオプションを無効にする方法は"no-check-ssl"を参照してください。

<a id="entry-5-2-check-via-socks4"></a>

**`check-via-socks4`**

```haproxy
check-via-socks4
```

使用可能なコンテキスト：tcp, http, log

アップストリームのsocks4プロキシを使う発信ヘルスチェックを有効にします。デフォルトでは、通常のトラフィックでsocksトンネルを有効にしていても、ヘルスチェックはトンネルを通りません。

<a id="entry-5-2-ciphers"></a>

**`ciphers <ciphers>`**

```haproxy
ciphers <ciphers>
```

使用可能なコンテキスト：tcp, http, log, peers, ring

この設定は、OpenSSLのサポートを組み込んでビルドした場合だけ使用できます。サーバーとのSSL/TLSハンドシェイクでネゴシエーションする、暗号アルゴリズムの一覧を記述した文字列を設定します。文字列の形式は、OpenSSLのマニュアルページ"man 1 ciphers"で定義されています。背景や推奨事項については、たとえば(<https://wiki.mozilla.org/Security/Server_Side_TLS>)と(<https://mozilla.github.io/server-side-tls/ssl-config-generator/>)を参照してください。TLSv1.3の暗号設定については、"ciphersuites"キーワードを参照してください。

<a id="entry-5-2-ciphersuites"></a>

**`ciphersuites <ciphersuites>`**

```haproxy
ciphersuites <ciphersuites>
```

使用可能なコンテキスト：tcp, http, log, peers, ring

この設定は、OpenSSLのサポートを組み込み、OpenSSL 1.1.1以降を使ってHAProxyをビルドした場合だけ使用できます。サーバーとのTLS 1.3ハンドシェイクでネゴシエーションする、暗号アルゴリズムの一覧を記述した文字列を設定します。文字列の形式は、OpenSSLのマニュアルページ"man 1 ciphers"の"ciphersuites"セクションで定義されています。TLSv1.2以前の暗号設定については、"ciphers"キーワードを参照してください。

<a id="entry-5-2-client-sigalgs"></a>

**`client-sigalgs <sigalgs>`**

```haproxy
client-sigalgs <sigalgs>
```

使用可能なコンテキスト：tcp, http, log, peers, ring

この設定は、OpenSSLのサポートを組み込んでビルドした場合にのみ使用できます。ネゴシエーションする、クライアント認証に関係する署名アルゴリズムのリストを表す文字列を設定します。文字列の形式は、OpenSSLのmanページ"man 3 SSL_CTX_set1_client_sigalgs"に定義されています。具体的な用途が明らかでない場合、この設定の使用は推奨しません。

<a id="entry-5-2-cookie"></a>

**`cookie <value>`**

```haproxy
cookie <value>
```

使用可能なコンテキスト: http

"cookie"パラメーターは、サーバーに割り当てるCookie値を`<value>`に設定します。受信リクエストでこの値を調べ、同じ値を持つ稼働中のサーバーのうち、最初のものを選びます。応答では、Cookieの挿入または書き換えモードの場合、クライアントに送るCookieにこの値を割り当てます。複数のサーバーが同じCookie値を共有しても問題はありません。実際、通常のサーバーとバックアップサーバーの間では、ある程度一般的な使い方です。backendセクションの"cookie"キーワードも参照してください。

<a id="entry-5-2-crl-file"></a>

**`crl-file <crlfile>`**

```haproxy
crl-file <crlfile>
```

使用可能なコンテキスト：tcp, http, log, peers, ring

この設定は、OpenSSLのサポートを組み込んでビルドした場合だけ使用できます。サーバー証明書の検証に使う証明書失効リストを読み込むPEMファイルを指定します。

<a id="entry-5-2-crt"></a>

**`crt <cert>`**

```haproxy
crt <cert>
```

使用可能なコンテキスト：tcp, http, log, peers, ring

この設定は、OpenSSLのサポートを組み込んでビルドした場合だけ使用できます。証明書と対応する秘密鍵の両方を読み込むPEMファイルを指定します。二つのPEMファイルを一つに連結して作成できます。サーバーがクライアント証明書を要求した場合、この証明書を送ります。

ファイルに秘密鍵が含まれていない場合、HAProxyは同じパスの末尾に".key"を付けたファイルから鍵の読み込みを試みます（"ssl-load-extra-files"オプションを適切に設定していることが条件です）。

<a id="entry-5-2-curves"></a>

**`curves <curves>`**

```haproxy
curves <curves>
```

使用可能なコンテキスト：tcp, http, log, peers, ring

この設定は、OpenSSLのサポートを組み込んでビルドした場合だけ使用できます。ECDHEを使うSSL/TLSハンドシェイクでネゴシエーションする、楕円曲線アルゴリズムの一覧（"curve suite"）を表す文字列を設定します。文字列の形式は、曲線名のコロン区切りリストです。例："X25519:P-256"（引用符なし）。

<a id="entry-5-2-disabled"></a>

**`disabled`**

```haproxy
disabled
```

使用可能なコンテキスト：tcp, http, log

"disabled"キーワードは、サーバーを"disabled"状態で起動します。これは、メンテナンスモードで停止扱いとなり、persistモードで許可された接続以外はサーバーに到達しないことを意味します。通常のトラフィックが到達することはなく、force-persistの仕組みを使えばサービスのテストはできるため、新しいサーバーの準備に適しています。"enabled"設定も参照してください。

<a id="entry-5-2-enabled"></a>

**`enabled`**

```haproxy
enabled
```

使用可能なコンテキスト：tcp, http, log

このオプションは、'default-server'ディレクティブからデフォルト値として継承した'disabled'設定を取り消すため、'server'設定として使用できます。また、'default-server'設定として使い、以前の'default-server'の'disabled'設定を取り消すこともできます。

<a id="entry-5-2-error-limit"></a>

**`error-limit <count>`**

```haproxy
error-limit <count>
```

使用可能なコンテキスト：tcp, http, log

正常性の監視を有効にしている場合、"error-limit"パラメーターは、"on-error"で選択したイベントを発生させる連続エラー数を指定します。デフォルトは、連続する10回のエラーです。

参照："check"、"error-limit"、"on-error"。

<a id="entry-5-2-fall"></a>

**`fall <count>`**

```haproxy
fall <count>
```

使用可能なコンテキスト：tcp, http, log

"fall"パラメーターは、ヘルスチェックが連続して`<count>`回失敗すると、サーバーを停止とみなすことを指定します。未指定の場合、デフォルトは3です。"check"、"inter"、"rise"パラメーターも参照してください。

<a id="entry-5-2-force-sslv3"></a>

**`force-sslv3`**

```haproxy
force-sslv3
```

使用可能なコンテキスト：tcp, http, log, peers, ring

このオプションは、サーバーとの通信でSSLを使用する場合に、SSLv3だけを使うよう強制します。接続頻度が高い場合、SSLv3は通常、TLSより処理コストが低くなります。グローバル設定の"ssl-default-server-options"でも使用できます。"ssl-min-ver"と"ssl-max-ver"も参照してください。

<a id="entry-5-2-force-tlsv10"></a>

**`force-tlsv10`**

```haproxy
force-tlsv10
```

使用可能なコンテキスト：tcp, http, log, peers, ring

このオプションは、サーバーとの通信でSSLを使用する場合に、TLSv1.0だけを使うよう強制します。グローバル設定の"ssl-default-server-options"でも使用できます。"ssl-min-ver"と"ssl-max-ver"も参照してください。

<a id="entry-5-2-force-tlsv11"></a>

**`force-tlsv11`**

```haproxy
force-tlsv11
```

使用可能なコンテキスト：tcp, http, log, peers, ring

このオプションは、サーバーとの通信でSSLを使用する場合に、TLSv1.1だけを使うよう強制します。グローバル設定の"ssl-default-server-options"でも使用できます。"ssl-min-ver"と"ssl-max-ver"も参照してください。

<a id="entry-5-2-force-tlsv12"></a>

**`force-tlsv12`**

```haproxy
force-tlsv12
```

使用可能なコンテキスト：tcp, http, log, peers, ring

このオプションは、サーバーとの通信でSSLを使用する場合に、TLSv1.2だけを使うよう強制します。グローバル設定の"ssl-default-server-options"でも使用できます。"ssl-min-ver"と"ssl-max-ver"も参照してください。

<a id="entry-5-2-force-tlsv13"></a>

**`force-tlsv13`**

```haproxy
force-tlsv13
```

使用可能なコンテキスト：tcp, http, log, peers, ring

このオプションは、サーバーとの通信でSSLを使用する場合に、TLSv1.3だけを使うよう強制します。グローバル設定の"ssl-default-server-options"でも使用できます。"ssl-min-ver"と"ssl-max-ver"も参照してください。

<a id="entry-5-2-guid"></a>

**`guid <string>`**

```haproxy
guid <string>
```

使用可能なコンテキスト：tcp, http, log

このサーバーに、大文字と小文字を区別するグローバルで一意のIDを指定します。すべてのオブジェクトの種類にわたり、HAProxyの設定全体で一意でなければなりません。形式の詳細は、プロキシキーワード"guid"の説明を参照してください。"shm-stats-file"も参照してください。

<a id="entry-5-2-hash-key"></a>

**`hash-key <key>`**

```haproxy
hash-key <key>
```

使用可能なコンテキスト：tcp, http, log

"hash-type consistent"のノードキーの計算方法を指定します。

引数：

```text
<key>   <key>には、次のいずれかを指定できます。

  id         ノードキーは、"id"で設定したサーバーの数値識別子から
             生成します。未設定の場合は、サーバー一覧での位置を使います。
             これがデフォルトです。IDの下位20ビットだけを使う
             （つまり(id % 1048576)）ため、重複を避けるには、
             1からこの値までの範囲の値だけを使うことを推奨します。

  id32       ノードキーは、"id"で設定したサーバーの数値識別子から
             生成します。未設定の場合は、サーバー一覧での位置を使います。
             ただし、IDの32ビットすべてを使うため、衝突しません。
             "id"のようなスケーリングは行いません。このため、常に
             ハッシュ関数と併用する（"hash-key"を参照）か、
             32ビットの空間全体に均等に分布するID値を明示的に
             割り当てて使うことを推奨します。

  guid       利用可能なら、ノードキーはサーバーのguidから生成します。
             利用できなければ、"id"にフォールバックします。
             順序にはまったく依存せず、多数のロードバランサーで複製できる
             安定した内部識別子だけに依存することが利点です。

  addr       利用可能なら、ノードキーはサーバーのアドレスから生成します。
             利用できなければ、"id"にフォールバックします。

  addr-port  利用可能なら、ノードキーはサーバーのアドレスとポートから
             生成します。利用できなければ、"id"にフォールバックします。
```

"addr"と"addr-port"オプションは、複数のHAProxyプロセスが同じサーバー群にトラフィックを分散する環境で役立つ場合があります。たとえばDNSレコードの解決順序が違うなどの理由で、プロセスごとにサーバーの順序が異なる場合でも、独立した各HAProxyプロセスでルーティングの判断を揃えられます。注意："balance random"も"hash-type consistent"を使用し、分布のよさはキーの品質に左右されます。

<a id="entry-5-2-healthcheck"></a>

**`healthcheck <name>`**

```haproxy
healthcheck <name>
```

使用可能なコンテキスト：tcp, http

サーバーのチェックに使用するhealth-checkセクションを指定します。

引数：

```text
<name>    health-checkセクションの名前です。
```

このオプションにより、プロキシの設定の代わりに、サーバーごとのヘルスチェック設定を使用できます。"healthcheck section"も参照してください。

<a id="entry-5-2-id"></a>

**`id <value>`**

```haproxy
id <value>
```

使用可能なコンテキスト：tcp, http, log

サーバーに固定のIDを設定します。IDは32ビットの正の数で、プロキシ内で一意でなければなりません。未指定の場合、未使用のIDを自動的に割り当てます。最初に割り当てる値は1です。現在、このIDが返されるのは統計だけです。また、コンシステントハッシュアルゴリズムを使い、"hash-key"が"id"（デフォルト）の場合に、負荷分散ノードの配置に使います。この場合、値の下位20ビットだけを使用するため（つまり(id % 1048576)）、重複を避けるには、1からこの値までの範囲に収めることを推奨します。

<a id="entry-5-2-idle-ping"></a>

**`idle-ping <delay>`**

```haproxy
idle-ping <delay>
```

使用可能なコンテキスト：tcp, http, log

アイドル状態のバックエンド接続で、生存確認を定期的に行う間隔を定義します。次の確認予定時刻までに相手が応答できない場合、接続は閉じられます。このキーワードはバックエンド側を対象とするため、アイドル状態の接続がまだ使用できるかを確認するのに役立ちます。ただし、アイドルプールのパージによって接続が破棄されることを防ぐものではありません。

この機能には、基盤となるプロトコルの対応が必要です。現在、実装しているのはH2 muxだけです。ほかのプロトコルでは、idle-pingを単に無視します。

このオプションは、リバースHTTPを使用する場合に特に有用です。server行に設定すると、受信接続を待ち受け、後でトラフィックの転送に再利用できるよう対応するサーバーに関連付けるピアに役立ちます。

<a id="entry-5-2-init-addr"></a>

**`init-addr {last | libc | none | <ip>},[...]*`**

```haproxy
init-addr {last | libc | none | <ip>},[...]*
```

使用可能なコンテキスト：tcp, http, log

サーバーにFQDNを使用する場合に、起動時にどの順序でアドレスを解決するかを指定します。カンマ区切りのリストに記載した方法を順番に適用して解決を試み、最初に成功した方法を使います。有効な方法が見つからないままリストの末尾に達すると、エラーになります。"last"は、状態ファイルにあるアドレスを選ぶ方法です（"server-state-file"を参照）。"libc"は、libc内部のリゾルバーを使います（OSやビルドオプションに応じてgethostbyname()またはgetaddrinfo()）。"none"は、有効なIPアドレスを持たず、停止状態でサーバーを起動することを明示します。起動時に一部のDNSの問題を無視し、後で解消されるのを待ちたい場合に役立ちます。最後に、IPv4またはIPv6アドレスを指定することもできます。現在判明しているサーバーのアドレス（設定生成ツールが書き込む場合など）でも、古いセッションを受け止めて適切なエラーメッセージを返すダミーサーバーのアドレスでもかまいません。"first"負荷分散アルゴリズムを使用する場合、このIPアドレスを、新しいインスタンスをその場で作成するきっかけとなる仮のサーバーに向けることもできます。このオプションのデフォルトは"last,libc"で、状態ファイルに以前のアドレスがあればそれを優先し、なければlibcのリゾルバーを使います。これにより従来の動作との互換性を維持します。内部リゾルバーを使用する場合、通常はlibcによる名前解決を無効にするか、明示的に指定することを推奨します（詳細は[セクション5.3](/ja/docs/haproxy/bind-and-server-options/#section-5-3)を参照）。

例1：

```text
defaults
    # never fail on address resolution
    default-server init-addr last,libc,none
```

例2：

```text
defaults
    # disable libc resolution in combination with resolvers
    default-server init-addr last,none
```

<a id="entry-5-2-inter"></a>

**`inter <delay>`**

```haproxy
inter <delay>
fastinter <delay>
downinter <delay>
```

使用可能なコンテキスト：tcp, http, log

"inter"パラメーターは、連続するヘルスチェックの間隔を`<delay>`ミリ秒に設定します。指定しない場合、間隔のデフォルトは2000 msです。"fastinter"と"downinter"を使い、サーバーの状態に応じてチェックの間隔を最適化することもできます。

```text
             サーバーの状態                 |         使用する間隔
    ----------------------------------------+----------------------------------
     UP 100%（移行状態ではない）             | "inter"
    ----------------------------------------+----------------------------------
     過渡的なUP（"fall"でダウンに移行中）、  | 設定されていれば"fastinter"、
     過渡的なDOWN（"rise"でアップに移行中）、| それ以外は"inter"。
     または未チェック。                     |
    ----------------------------------------+----------------------------------
     DOWN 100%（移行状態ではない）           | 設定されていれば"downinter"、
                                            | それ以外は"inter"。
    ----------------------------------------+----------------------------------
```

ほかの時間指定パラメーターと同様、{ us, ms, s, m, h, d }のいずれかの単位を明示して入力することもできます。"timeout check"を設定していない場合、"inter"パラメーターは、サーバーに送るヘルスチェックのタイムアウトも兼ねます。同じハードウェア上で複数のサーバーを稼働させたときの「共振」の影響を減らすため、全サーバーのエージェントチェックとヘルスチェックは、開始時刻を少しずつずらしています。グローバルの"spread-checks"キーワードを使い、エージェントチェックとヘルスチェックの間隔にランダムな揺らぎを加えることもできます。たとえば、多数のバックエンドが同じサーバーを使う場合に有効です。グローバル設定の"tune.max-checks-per-thread"をゼロ以外の値にすると、各スレッドで同時に実行するチェックの数を制限します。この制限に達したスレッドで開始しようとしているチェックは、別のチェックが終わるまでhaproxyがキューに入れて待機させます。その結果、実際のチェック間隔は長くなります。この場合、"inter"を短くしてもキューでの待機時間は短縮できないため、その効果はごく限られます。

<a id="entry-5-2-init-state"></a>

**`init-state { fully-up | up | down | fully-down | none }`**

```haproxy
init-state { fully-up | up | down | fully-down | none }
```

使用可能なコンテキスト：tcp, http

使用可能なセクション: defaults \| frontend \| listen \| backend 不可 \| 不可 \| 可 \| 可

"init-state"オプションは、サーバーの初期状態を設定します。- 'fully-up'の場合、サーバーはすぐに利用可能とみなされます。このサーバーのヘルスチェックが有効なら、すべてのヘルスチェックが失敗するとDOWN状態になります。- 'up'の場合、サーバーはすぐに利用可能とみなされます。このサーバーのヘルスチェックが有効なら、次のヘルスチェックが失敗すると直ちにDOWN状態になります。- 'down'の場合、サーバーは初めは利用できないとみなされます。このサーバーのヘルスチェックが有効なら、次のヘルスチェックが成功するとUP状態になることができます。- 'fully-down'の場合、サーバーは初めは利用できないとみなされます。このサーバーのヘルスチェックが有効なら、すべてのヘルスチェックが成功するとUP状態になります。- 'none'（デフォルト値）の場合、init-stateによる管理を無効にします。'default-server'ディレクティブからこのパラメーターを継承したとき、デフォルトの動作に戻すために使えます。

サーバーのinit-stateは、HAProxyインスタンスの起動や再起動、新しいサーバーの検出（サービスディスカバリーやDNS解決など）、動的サーバーの稼働開始、サーバーのメンテナンス終了などの際に考慮します。サーバーが別のサーバーを追跡している場合、このディレクティブは使用できません。

例：

```shell
# pass client traffic ONLY to Redis "master" node
backend redis-master
  mode tcp
  balance first
  option tcp-check
  tcp-check send role\r\n
  tcp-check expect string master
  server-template redis 3 _redis._tcp.redis-headless-service.sandbox.svc.cluster.local:6379 check ... init-state down

# pass traffic to the server only after 3 successful health checks
backend google-backend
  mode http
  server srv1 google.com:80 check init-state fully-down rise 3
  server srv2 google.com:80 check init-state fully-down rise 3
```

参照："option tcp-check"、"option httpchk"。

<a id="entry-5-2-ktls"></a>

**`ktls <on|off> [ EXPERIMENTAL ]`**

```haproxy
ktls <on|off> [ EXPERIMENTAL ]
```

使用可能なコンテキスト：tcp, http, log, peers, ring

対象のソケットでktlsを有効または無効にします。有効にした場合、カーネルがサポートし、暗号にも互換性があれば、kTLSを使用します。Linux 4.17以降でのみ使用できます。ネットワークドライバーやTLSスタックによっては、kTLSの使用がTLS v1.2だけに制限される場合があります。"force-tlsv12"も参照してください。

<a id="entry-5-2-log-bufsize"></a>

**`log-bufsize <bufsize>`**

```haproxy
log-bufsize <bufsize>
```

使用可能なコンテキスト：log

"log-bufsize"は、ログバックエンド内のログサーバーに関連付ける、暗黙のリングのバッファーサイズを指定します。未指定の場合はBUFSIZEです。値を大きくするとメモリー使用量は増えますが、バッファーにより多くの未処理メッセージを保持できるため、低速なサーバーでのログメッセージの損失を防ぐのに役立つ場合があります。このキーワードは、"mode log"を指定したログバックエンドセクションでのみ使用できます。

<a id="entry-5-2-log-proto"></a>

**`log-proto <logproto>`**

```haproxy
log-proto <logproto>
```

使用可能なコンテキスト：log, ring

"log-proto"は、logまたはringセクションに設定したサーバーへ、イベントメッセージを転送するプロトコルを指定します。指定できる値は"legacy"と"octet-count"で、rfc6587の"Non-transparent-framing"と"Octet counting"にそれぞれ対応します。デフォルトは"legacy"です。

<a id="entry-5-2-maxconn"></a>

**`maxconn <maxconn>`**

```haproxy
maxconn <maxconn>
```

使用可能なコンテキスト：tcp, http

"maxconn"パラメーターは、このサーバーに送る同時接続数の上限を指定します。受信する同時接続数がこの値を超えると、接続をキューに入れ、空きができるまで待機させます。極端な負荷がかかった際に、負荷に弱いサーバーが停止するのを防げるため、非常に重要なパラメーターです。"minconn"を指定すると、上限は動的になります。デフォルト値の"0"は無制限を意味します。"minconn"と"maxqueue"パラメーター、およびバックエンドの"fullconn"キーワードも参照してください。

HTTPモードでは、このパラメーターは接続数ではなく同時リクエスト数を制限します。サーバーへの単一のTCP接続上で、複数のリクエストを多重化する場合があります。たとえばmaxconnに50を指定すると、実際のサーバー接続数は1から50までとなることがありますが、同時リクエスト数は50を超えません。

<a id="entry-5-2-maxqueue"></a>

**`maxqueue <maxqueue>`**

```haproxy
maxqueue <maxqueue>
```

使用可能なコンテキスト：tcp, http

"maxqueue"パラメーターは、このサーバーのキューで待機する接続数の上限を指定します。上限に達すると、以降のリクエストは、処理されるまで無期限に待つ代わりに、ほかのサーバーへ再配分されます。永続性は失われますが、接続しようとしているサーバーが停止しかけている場合でも、利用者がすぐに再ログインできることがあります。leastconnなど一部の負荷分散アルゴリズムは、この値をゼロより大きい値に明示的に設定すると考慮し、この上限までサーバーのキューにリクエストを追加します。maxconnが一桁の値の場合、負荷をより均等にできることがよくあります。デフォルト値は"0"で、キューに制限はありません。"maxconn"と"minconn"パラメーター、および"balance leastconn"も参照してください。

<a id="entry-5-2-max-reuse"></a>

**`max-reuse <count>`**

```haproxy
max-reuse <count>
```

使用可能なコンテキスト：http, ring

httpコンテキストで使用する場合：

"max-reuse"引数は、HTTP接続を処理する側に対し、新しいリクエストを送るためにサーバー接続を再利用する回数を、この値までに抑えるよう指示します。指定できる値は、この制限を無効にする-1（デフォルト）か、正の値です。ゼロにすると、実質的にkeep-aliveを無効にします。これは、時間の経過とともにリソースがリークする、一部のサーバーの不具合を回避するためだけに使います。技術的な制限により強制できない場合があるため、下位層が必ずこの引数に従うとは限りません。少なくとも、サーバーへのHTTP/2接続ではこの値が守られます。

ringコンテキストで使用する場合：

"max-reuse"引数は、シンクのTCP接続を処理する側に対し、メッセージ送信のためにサーバー接続を再利用する回数を、この値までに抑えるよう指示します。同じ接続で少なくとも"max-reuse + 1"件のメッセージを処理すると、サーバーへの接続を強制的に破棄します。その後、サーバーへの接続は自動的に作り直されます。マルチスレッド環境で大量のメッセージを扱う場合、リングの負荷を複数のスレッドへ分散しやすくなります。各接続は、その存続期間を通して同じCPUスレッドに結び付いているためです。HTTPとは異なり、syslogにはトランザクションに相当するものがないため、サーバーが接続を閉じず、ネットワークエラーも起きなければ、サーバー接続は無期限に存続する可能性があります。ときどき接続を破棄すれば、ほかのスレッドも順番にメッセージを取得する機会を得られます。また、haproxyとログサーバーの間に別の負荷分散層がある環境では、ログサーバーを円滑に入れ替えるのにも役立つ場合があります。ただし、接続を作り直すたびに、送信元ポートがTIME_WAIT状態で残り、最近のOSでは約一分間再利用できなくなる点に注意してください。そのため、送信元ポートを急速に使い切らないよう、値を小さくしすぎないことが必要です。目安として、接続を閉じる回数を毎秒数回より多くしないでください。できれば、それよりはるかに低い頻度に抑えます。指定できる値は、この制限を無効にする-1（デフォルト）か、正の値です。HTTPの場合とは異なり、シンクサーバーでの"max-reuse"の適用はベストエフォートです。リングのメッセージをバッチで処理するため、上限はバッチの間で確認します。

<a id="entry-5-2-minconn"></a>

**`minconn <minconn>`**

```haproxy
minconn <minconn>
```

使用可能なコンテキスト：tcp, http

"minconn"パラメーターを設定すると、maxconnの上限はバックエンドの負荷に応じて変わる動的な上限になります。サーバーは常に少なくとも`<minconn>`接続を受け入れられ、`<maxconn>`を超えることはありません。バックエンドの同時接続数が`<fullconn>`未満の場合、上限は負荷に応じてこの二つの値の間で増加します。そのため、通常時はサーバーの負荷を抑え、高負荷時にはより多く処理させつつ、例外的に負荷が高くなっても過負荷を防げます。"maxconn"と"maxqueue"パラメーター、およびバックエンドの"fullconn"キーワードも参照してください。

<a id="entry-5-2-namespace"></a>

**`namespace <name>`**

```haproxy
namespace <name>
```

使用可能なコンテキスト：tcp, http, log, peers, ring

Linuxでは、ソケットが属するネットワーク名前空間を指定できます。このディレクティブを使うと、デフォルト以外の名前空間にサーバーを明示的にバインドできます。ネットワーク名前空間の詳細は、OSのドキュメントを参照してください。

<a id="entry-5-2-no-agent-check"></a>

**`no-agent-check`**

```haproxy
no-agent-check
```

使用可能なコンテキスト：tcp, http, log

このオプションは、"default-server"ディレクティブからデフォルト値として継承した"agent-check"設定を取り消すため、"server"設定として使用できます。また、"default-server"設定として使い、以前の"default-server"の"agent-check"設定を取り消すこともできます。

<a id="entry-5-2-no-backup"></a>

**`no-backup`**

```haproxy
no-backup
```

使用可能なコンテキスト：tcp, http, log

このオプションは、"default-server"ディレクティブからデフォルト値として継承した"backup"設定を取り消すため、"server"設定として使用できます。また、"default-server"設定として使い、以前の"default-server"の"backup"設定を取り消すこともできます。

<a id="entry-5-2-no-check"></a>

**`no-check`**

```haproxy
no-check
```

使用可能なコンテキスト：tcp, http, log

このオプションは、"default-server"ディレクティブからデフォルト値として継承した"check"設定を取り消すため、"server"設定として使用できます。また、"default-server"設定として使い、以前の"default-server"の"check"設定を取り消すこともできます。

<a id="entry-5-2-no-check-reuse-pool"></a>

**`no-check-reuse-pool`**

```haproxy
no-check-reuse-pool
```

使用可能なコンテキスト：tcp, http

"default-server"から継承した可能性のある、以前の"check-reuse-pool"設定を取り消します。すべてのチェックを、それぞれの専用接続で行います。

<a id="entry-5-2-no-check-sni-auto"></a>

**`no-check-sni-auto`**

```haproxy
no-check-sni-auto
```

使用可能なコンテキスト：tcp, http, log

このオプションは、デフォルトで有効なSSLヘルスチェックのSNI自動選択を無効にするため、"server"設定として使用できます。

プロキシするトラフィックでSNIの自動選択を無効にするには、"no-sni-auto"オプションを参照してください。

<a id="entry-5-2-no-check-ssl"></a>

**`no-check-ssl`**

```haproxy
no-check-ssl
```

使用可能なコンテキスト：tcp, http, log

このオプションは、"default-server"ディレクティブからデフォルト値として継承した"check-ssl"設定を取り消すため、"server"設定として使用できます。また、"default-server"設定として使い、以前の"default-server"の"check-ssl"設定を取り消すこともできます。

<a id="entry-5-2-no-renegotiate"></a>

**`no-renegotiate`**

```haproxy
no-renegotiate
```

使用可能なコンテキスト：tcp, http, log

この設定は、OpenSSLのサポートを組み込んでビルドした場合だけ使用できます。指定のSSLバックエンドで、従来の安全でない方式も、より新しい"secure renegotiation"（RFC 5746 TLS Renegotiation Indication Extension）も含め、再ネゴシエーションの仕組みを無効にします。このオプションは、グローバル設定の"ssl-default-server-options"でも使用できます。TLS 1.3では再ネゴシエーションはできません。"renegotiate"と"no-renegotiate"のどちらも指定しない場合、SSLライブラリーのデフォルト動作を維持します。たとえば、OpenSSLは安全な再ネゴシエーションをデフォルトで有効にしますが、AWS-LCは無効にします。"renegotiate"も参照してください。

<a id="entry-5-2-no-send-proxy"></a>

**`no-send-proxy`**

```haproxy
no-send-proxy
```

使用可能なコンテキスト：tcp, http

このオプションは、"default-server"ディレクティブからデフォルト値として継承した"send-proxy"設定を取り消すため、"server"設定として使用できます。また、"default-server"設定として使い、以前の"default-server"の"send-proxy"設定を取り消すこともできます。

<a id="entry-5-2-no-send-proxy-v2"></a>

**`no-send-proxy-v2`**

```haproxy
no-send-proxy-v2
```

使用可能なコンテキスト：tcp, http

このオプションは、"default-server"ディレクティブからデフォルト値として継承した"send-proxy-v2"設定を取り消すため、"server"設定として使用できます。また、"default-server"設定として使い、以前の"default-server"の"send-proxy-v2"設定を取り消すこともできます。

<a id="entry-5-2-no-send-proxy-v2-ssl"></a>

**`no-send-proxy-v2-ssl`**

```haproxy
no-send-proxy-v2-ssl
```

使用可能なコンテキスト：tcp, http

このオプションは、"default-server"ディレクティブからデフォルト値として継承した"send-proxy-v2-ssl"設定を取り消すため、"server"設定として使用できます。また、"default-server"設定として使い、以前の"default-server"の"send-proxy-v2-ssl"設定を取り消すこともできます。

<a id="entry-5-2-no-send-proxy-v2-ssl-cn"></a>

**`no-send-proxy-v2-ssl-cn`**

```haproxy
no-send-proxy-v2-ssl-cn
```

使用可能なコンテキスト：tcp, http

このオプションは、"default-server"ディレクティブからデフォルト値として継承した"send-proxy-v2-ssl-cn"設定を取り消すため、"server"設定として使用できます。また、"default-server"設定として使い、以前の"default-server"の"send-proxy-v2-ssl-cn"設定を取り消すこともできます。

<a id="entry-5-2-no-sni-auto"></a>

**`no-sni-auto`**

```haproxy
no-sni-auto
```

使用可能なコンテキスト：tcp, http, log, peers, ring

このオプションは、デフォルトで有効なSNIの自動選択を無効にするため、"server"設定として使用できます。

SSLヘルスチェックでSNIの自動選択を無効にするには、"no-check-sni-auto"オプションを参照してください。

<a id="entry-5-2-no-ssl"></a>

**`no-ssl`**

```haproxy
no-ssl
```

使用可能なコンテキスト：tcp, http, log, peers, ring

このオプションは、"default-server"ディレクティブからデフォルト値として継承した"ssl"設定を取り消すため、"server"設定として使用できます。また、"default-server"設定として使い、以前の"default-server"の"ssl"設定を取り消すこともできます。

`default-server ssl`設定とサーバーの`no-ssl`を併用した場合も、SSL接続は初期化します。このため、後でランタイムAPIから有効にできます。管理ドキュメントの`set server`コマンドを参照してください。

<a id="entry-5-2-no-ssl-reuse"></a>

**`no-ssl-reuse`**

```haproxy
no-ssl-reuse
```

使用可能なコンテキスト：tcp, http, log, peers, ring

このオプションは、サーバーとの通信でSSLを使用する場合に、SSLセッションの再利用を無効にします。新しい接続ごとに、サーバーが完全なハンドシェイクを行うよう強制します。おそらく、ベンチマーク、トラブルシューティング、または極めて慎重なユーザーにのみ役立ちます。

<a id="entry-5-2-no-sslv3"></a>

**`no-sslv3`**

```haproxy
no-sslv3
```

使用可能なコンテキスト：tcp, http, log, peers, ring

このオプションは、サーバーとの通信でSSLを使用する場合に、SSLv3のサポートを無効にします。SSLv2はコード内で無効にしているため、どの設定オプションを使っても有効にできません。代わりに"ssl-min-ver"と"ssl-max-ver"を使用してください。

default-serverでのサポート：なし

<a id="entry-5-2-no-tls-tickets"></a>

**`no-tls-tickets`**

```haproxy
no-tls-tickets
```

使用可能なコンテキスト：tcp, http, log, peers, ring

この設定は、OpenSSLのサポートを組み込んでビルドした場合だけ使用できます。ステートレスなセッション再開（RFC 5077 TLS Ticket拡張）を無効にし、ステートフルなセッション再開の使用を強制します。ステートレスなセッション再開は、サーバーのCPU使用量がより多くなります。このオプションは、グローバル設定の"ssl-default-server-options"でも使用できます。TLSチケットの仕組みを使用するのはTLS 1.2までです。チケットの鍵を定期的にローテーションしない限り（リロード、または"tls-ticket-keys"を使用）、TLSチケットによって前方秘匿性が損なわれます。"tls-tickets"も参照してください。

<a id="entry-5-2-no-tlsv10"></a>

**`no-tlsv10`**

```haproxy
no-tlsv10
```

使用可能なコンテキスト：tcp, http, log, peers, ring

このオプションは、サーバーとの通信にSSLを使用する場合にTLSv1.0のサポートを無効にします。SSLv2はコード内で無効にされており、どの設定オプションでも有効にはできません。TLSv1はSSLv3より処理コストが高いため、ローカルサーバーとの通信では無効にすることが適切な場合がよくあります。このオプションは、globalの"ssl-default-server-options"文でも指定できます。代わりに"ssl-min-ver"と"ssl-max-ver"を使用してください。

default-serverでのサポート：なし

<a id="entry-5-2-no-tlsv11"></a>

**`no-tlsv11`**

```haproxy
no-tlsv11
```

使用可能なコンテキスト：tcp, http, log, peers, ring

このオプションは、サーバーとの通信にSSLを使用する場合にTLSv1.1のサポートを無効にします。SSLv2はコード内で無効にされており、どの設定オプションでも有効にはできません。TLSv1はSSLv3より処理コストが高いため、ローカルサーバーとの通信では無効にすることが適切な場合がよくあります。このオプションは、globalの"ssl-default-server-options"文でも指定できます。代わりに"ssl-min-ver"と"ssl-max-ver"を使用してください。

default-serverでのサポート：なし

<a id="entry-5-2-no-tlsv12"></a>

**`no-tlsv12`**

```haproxy
no-tlsv12
```

使用可能なコンテキスト：tcp, http, log, peers, ring

このオプションは、サーバーとの通信にSSLを使用する場合にTLSv1.2のサポートを無効にします。SSLv2はコード内で無効にされており、どの設定オプションでも有効にはできません。TLSv1はSSLv3より処理コストが高いため、ローカルサーバーとの通信では無効にすることが適切な場合がよくあります。このオプションは、globalの"ssl-default-server-options"文でも指定できます。代わりに"ssl-min-ver"と"ssl-max-ver"を使用してください。

default-serverでのサポート：なし

<a id="entry-5-2-no-tlsv13"></a>

**`no-tlsv13`**

```haproxy
no-tlsv13
```

使用可能なコンテキスト：tcp, http, log, peers, ring

このオプションは、サーバーとの通信にSSLを使用する場合にTLSv1.3のサポートを無効にします。SSLv2はコード内で無効にされており、どの設定オプションでも有効にはできません。TLSv1はSSLv3より処理コストが高いため、ローカルサーバーとの通信では無効にすることが適切な場合がよくあります。このオプションは、globalの"ssl-default-server-options"文でも指定できます。代わりに"ssl-min-ver"と"ssl-max-ver"を使用してください。

default-serverでのサポート：なし

<a id="entry-5-2-no-verifyhost"></a>

**`no-verifyhost`**

```haproxy
no-verifyhost
```

使用可能なコンテキスト：tcp, http, log, peers, ring

このオプションは、"default-server"ディレクティブからデフォルト値として継承した"verifyhost"設定を取り消すため、"server"設定として使用できます。また、"default-server"設定として使い、以前の"default-server"の"verifyhost"設定を取り消すこともできます。

<a id="entry-5-2-no-tfo"></a>

**`no-tfo`**

```haproxy
no-tfo
```

使用可能なコンテキスト：tcp, http, log, peers, ring

このオプションは、"default-server"ディレクティブからデフォルト値として継承した"tfo"設定を取り消すため、"server"設定として使用できます。また、"default-server"設定として使い、以前の"default-server"の"tfo"設定を取り消すこともできます。

<a id="entry-5-2-non-stick"></a>

**`non-stick`**

```haproxy
non-stick
```

使用可能なコンテキスト：tcp, http

このサーバーに割り当てた接続を、スティックテーブルに決して追加しません。backupと併用すると、バックアップサーバーでスティックテーブルによる永続性を確実に無効にできます。

<a id="entry-5-2-npn"></a>

**`npn <protocols>`**

```haproxy
npn <protocols>
```

使用可能なコンテキスト：tcp, http

TLSのNPN拡張を有効にし、指定したプロトコルリストを、NPNで選択できる上位プロトコルとして通知します。リストはプロトコル名をカンマで区切ったもので、たとえば"http/1.1,http/1.0"（引用符なし）です。SSLライブラリーを、TLS拡張のサポートを有効にしてビルドしている必要があります（haproxy -vvで確認できます）。NPN拡張はALPN拡張に置き換えられています（"alpn"キーワードを参照）が、ALPNはOpenSSL 1.0.2以降でしか使用できません。

<a id="entry-5-2-observe"></a>

**`observe <mode>`**

```haproxy
observe <mode>
```

使用可能なコンテキスト：tcp, http

サーバーとの通信を監視し、その結果に応じて正常性を調整する機能を有効にします。デフォルトでは無効で、有効にするにはヘルスチェックも有効にする必要があります。サポートするモードは"layer4"と"layer7"の二つです。layer4モードでは、TCP接続の成功または失敗だけを考慮します。HTTPプロキシでのみ許可されるlayer7では、HTTPコードの正否、ヘッダーを解析できない状況、タイムアウトなど、サーバーから受信したレスポンスを検証します。有効なステータスコードは100から499まで、および501と505です。

参照："check"、"on-error"、"error-limit"。

<a id="entry-5-2-on-error"></a>

**`on-error <mode>`**

```haproxy
on-error <mode>
```

使用可能なコンテキスト：tcp, http, log

十分な回数の連続エラーを検出した場合の動作を選択します。現在、次の四つのモードを使用できます。

- fastinter：fastinterを強制します。
- fail-check：チェックの失敗を模擬し、fastinterも強制します（デフォルト）。
- sudden-death: 致命的になる直前のヘルスチェック失敗を模擬し、fastinterを強制します。さらに一度チェックが失敗すると、サーバーをダウンとマークします。
- mark-down：サーバーを直ちにダウンと判定し、fastinterを強制します。

参照："check"、"observe"、"error-limit"。

<a id="entry-5-2-on-marked-down"></a>

**`on-marked-down <action>`**

```haproxy
on-marked-down <action>
```

使用可能なコンテキスト：tcp, http, log

サーバーがダウンと判定されたときの動作を変更します。現在、使用可能なアクションは一つです。

- shutdown-sessions: 相手とのストリームを終了します。この設定を有効にすると、サーバーが停止した際、そのサーバーへのすべての接続を直ちに終了します。ヘルスチェックが単純な接続状態より複雑な状況を検出し、長いタイムアウトのためにサービスが長時間応答しないままになる場合に、使用できることがあります。たとえば、データベースが応答不能になり、既存の接続を再利用する見込みがないとヘルスチェックが検出した場合です。この方法で終了した接続は、'D'（"Down"）の終了コードでログに記録します。

アクションはデフォルトで無効です。

<a id="entry-5-2-on-marked-up"></a>

**`on-marked-up <action>`**

```haproxy
on-marked-up <action>
```

使用可能なコンテキスト：tcp, http, log

サーバーが稼働中と判定されたときの動作を変更します。現在、使用可能なアクションは一つです。

- shutdown-backup-sessions: すべてのバックアップサーバー上のストリームを終了します。対象のサーバーがバックアップ状態ではなく、無効でもない場合（有効な重みが\> 0である必要があります）だけ実行します。LDAPやSQLなどの長時間セッションを扱う場合、復旧した稼働系サーバーにすべてのトラフィックを強制的に戻すために使えることがあります。ただし、未完了のトランザクションなど、解消しようとしたものより大きな問題を引き起こす場合があるため、この機能の使用には細心の注意を払ってください。サーバーの稼働に伴って終了したストリームは、'U'（"Up"）の終了コードでログに記録します。

アクションはデフォルトで無効です。

<a id="entry-5-2-pool-conn-name"></a>

**`pool-conn-name <expr>`**

```haproxy
pool-conn-name <expr>
```

使用可能なコンテキスト: http

バックエンド接続を確立すると、この式を評価して接続名を生成します。この名前は、アイドル状態のサーバー接続プール内で、接続を識別する主要なプロパティの一つです。"http-reuse"キーワードを参照してください。リクエストが既存のアイドル接続を探す際には、この式を評価して同一の接続を照合します。

バックエンド接続でSSLのSNIを使用する場合、接続名には"sni"式の結果を自動的に割り当てます。これは最も一般的な使い方に適しています。より高度な設定では、"pool-conn-name"で上書きできます。

参照："http-reuse"、"sni"。

<a id="entry-5-2-pool-low-conn"></a>

**`pool-low-conn <max>`**

```haproxy
pool-low-conn <max>
```

使用可能なコンテキスト: http

サーバーのアイドル接続数の下限を設定します。接続数がこの値を下回ると、スレッドは別のスレッドから接続を取得しようとしません。非常に高速なサーバーを多数使う環境で、CPUの使われ方を改善するのに役立つ場合があります。一つのスレッドに接続が集まり、その後スレッド間を移動するのを防ぎ、すべてのスレッドが常にいくつかのアイドル接続を保持できるようにするためです。一般的にはスレッド数の二倍にすると、応答時間が一ミリ秒未満の場合でも、すでに非常によい性能が得られるようです。デフォルトはゼロで、どのアイドル接続もいつでも使用できます。通常の用途には、この設定を推奨します。"http-reuse"と同じ原則に従って共有できる接続だけが対象です。"tune.idle-pool.shared"でスレッド間の接続共有を無効にした場合、この設定を使って各スレッドに常にいくつかの接続を保持させることが非常に重要になる場合があります。そうしないと、スレッド数が増えるにつれて接続の再利用率が下がります。

<a id="entry-5-2-pool-max-conn"></a>

**`pool-max-conn <max>`**

```haproxy
pool-max-conn <max>
```

使用可能なコンテキスト: http

サーバーのアイドル接続数の上限を設定します。-1は無制限、0はアイドル接続を保持しないことを意味します。デフォルトは-1です。アイドル接続を有効にすると、どのクライアントセッションにも属さなくなったアイドル接続を専用プールへ移し、後から来るクライアントが使える状態に保ちます。"http-reuse"と同じ原則に従って共有できる接続だけが対象です。

<a id="entry-5-2-pool-purge-delay"></a>

**`pool-purge-delay <delay>`**

```haproxy
pool-purge-delay <delay>
```

使用可能なコンテキスト: http

アイドル接続の削除を開始するまでの時間を設定します。`<delay>`の間隔ごとに、アイドル接続の半分を閉じます。0は、アイドル接続を一切保持しないことを意味します。デフォルトは5sです。

<a id="entry-5-2-port"></a>

**`port <port>`**

```haproxy
port <port>
```

使用可能なコンテキスト：tcp, http, log

"port"パラメーターを使うと、ヘルスチェックやエージェントチェックを別のポートへ送ることができます。サーバーによっては、アプリケーションそのものよりもヘルスチェックに適した複雑な試験を行える、専用のコンポーネントにポートを割り当てたい場合があります。たとえば、inetdで単純なスクリプトを動かす構成は一般的です。"check"パラメーターを設定していない場合、このパラメーターは無視します。"addr"パラメーターも参照してください。

<a id="entry-5-2-proto"></a>

**`proto <name>`**

```haproxy
proto <name>
```

使用可能なコンテキスト：tcp, http

このサーバーへの送信接続に使用するマルチプレクサーのプロトコルを強制的に指定します。バックエンドのモード（TCPまたはHTTP）と互換性がなければなりません。また、バックエンド側で使用できる必要があります。利用可能なプロトコルの一覧はhaproxy -vvで表示されます。プロトコルの属性として、モード（TCP/HTTP）、使用側（FE/BE）、mux名、フラグが表示されます。

一部のプロトコルでは、サーバー側でヘッドオブラインブロッキングが起こります（flag=HOL_RISK）。また、アップグレードをサポートしないプロトコルもあります（flag=NO_UPG）。HTXとの互換性も表示します（flag=HTX）。

server行の"proto"ディレクティブの引数に使用できるプロトコルは、次のとおりです。

```text
quic: mode=HTTP  side=FE|BE  mux=QUIC  flags=HTX|NO_UPG|FRAMED
qmux: mode=HTTP  side=FE|BE  mux=QMUX  flags=HTX|NO_UPG
h2  : mode=HTTP  side=FE|BE  mux=H2    flags=HTX|HOL_RISK|NO_UPG
fcgi: mode=HTTP  side=BE     mux=FCGI  flags=HTX|HOL_RISK|NO_UPG
h1  : mode=HTTP  side=FE|BE  mux=H1    flags=HTX|NO_UPG
none: mode=TCP   side=FE|BE  mux=PASS  flags=NO_UPG
spop: mode=SPOP  side=BE     mux=SPOP  flags=HOL_RISK|NO_UPG
```

このオプションの目的は、このサーバーに確立するすべての接続で、最適なマルチプレクサーのプロトコルを選ぶ処理を迂回することです。

ALPNまたはNPNの設定を行っている場合、問題を避けるため、指定するプロトコルはマルチプレクサーのプロトコルと互換性のあるものにすることを推奨します。たとえば、"proto h1"を設定した場合、ALPNを"h2"に設定することは推奨しません。

WebSocketストリームで別のプロトコルを使用するには、"ws"も参照してください。

QMuxは、TCP上で動作するQUICのサブセットです。次のプロトコルのドラフトに対応します：<https://www.ietf.org/archive/id/draft-ietf-quic-qmux-01.html>。現在、haproxyでは実験的とみなされています。

<a id="entry-5-2-quic-cc-algo"></a>

**`quic-cc-algo { cubic | newreno | bbr | nocc }[(<args,...>)]`**

```haproxy
quic-cc-algo { cubic | newreno | bbr | nocc }[(<args,...>)]
```

このサーバーを宛先とするすべての接続の輻輳制御アルゴリズムを選択する、QUIC固有の設定です。アルゴリズムはTCPで使用するものと似ています。すべてのカスタマイズオプションの詳しい説明は、同様の名前のbindオプションを参照してください。

デフォルト値：cubic

参照："tune.quic.be.tx.pacing"、"tune.quic.be.cc.max-win-size"。

<a id="entry-5-2-redir"></a>

**`redir <prefix>`**

```haproxy
redir <prefix>
```

使用可能なコンテキスト: http

"redir"パラメーターは、このサーバー宛てのすべてのGETおよびHEADリクエストでリダイレクトモードを有効にします。HAProxyはリクエストをサーバーへ転送する代わりに、この接頭辞の直後に、要求されたURIのパス部分の先頭の'/'から始まる文字列を続けた"Location"ヘッダーを付けて、"HTTP 302"レスポンスを送ります。そのため、`<prefix>`の末尾にはスラッシュを付けないことを推奨します。不正なリクエストはすべて拒否し、GETまたはHEAD以外のリクエストはサーバーが通常どおり処理します。レスポンス全体を生成するため、レスポンスのヘッダーの書き換えやCookieの挿入はできません。ただし、リクエスト内のCookieは引き続き解析するので、ローカルで障害が起きた場合に、ユーザーを離れた場所へ誘導する方法として十分に使用できます。主な用途は、クライアントを静的コンテンツのサーバーへ直接接続させて、帯域幅を増やすことです。注意：ここでは絶対に相対的な場所を指定しないでください。クライアントとHAProxyの間でループが発生します。

例：server srv1 192.168.1.1:80 redir <http://image1.mydomain.com> check

<a id="entry-5-2-renegotiate"></a>

**`renegotiate`**

```haproxy
renegotiate
```

使用可能なコンテキスト：tcp, http, log

指定のSSLバックエンドで、安全な再ネゴシエーションの仕組み（RFC 5746 TLS Renegotiation Indication Extension）を有効にします。SSLクライアントが再ネゴシエーション要求を送るという意味ではなく、サーバーから要求された場合に、バックエンドが再ネゴシエーションできるようにするだけです。基盤となるSSLライブラリーが、実際に再ネゴシエーションをサポートしている必要もあります。このオプションは、グローバル設定の"ssl-default-server-options"でも使用できます。TLS 1.3では再ネゴシエーションはできません。"renegotiate"と"no-renegotiate"のどちらも指定しない場合、SSLライブラリーのデフォルト動作を維持します。たとえば、OpenSSLは安全な再ネゴシエーションをデフォルトで有効にしますが、AWS-LCは無効にします。

<a id="entry-5-2-rise"></a>

**`rise <count>`**

```haproxy
rise <count>
```

使用可能なコンテキスト：tcp, http, log

"rise"パラメーターは、ヘルスチェックが連続して`<count>`回成功すると、サーバーを稼働中とみなすことを指定します。未指定の場合、デフォルトは2です。"check"、"inter"、"fall"パラメーターも参照してください。

resolve-opts `<option>`,`<option>`,... 使用可能なコンテキスト: tcp, http, log

このサーバーに関連するDNS解決に適用するオプションのカンマ区切りリストです。

使用可能なオプション：

- allow-dup-ip既定では、実行時のDNS名前解決を使用している場合、HAProxyはバックエンド内でIPアドレスが重複しないようにします。ただし、同じバックエンド内で同じFQDNから名前解決される二つのサーバーが、同じIPアドレスを持つことが適切な場合もあります。その場合は、このオプションを有効にしてください。これはprevent-dup-ipの逆です。

- ignore-weight SRVレコード内で設定した重みをすべて無視します。"agent-check"やランタイムAPIなど、別の方法で重みを制御したい場合に役立ちます。

- prevent-dup-ip サーバーでHAProxyのデフォルトの動作を強制します。同じバックエンド内にあり、同じfqdnを共有するサーバーにすでに設定したIPアドレスの再利用を防ぎます。allow-dup-ipの逆です。

例：

```text
backend b_myapp
  default-server init-addr none resolvers dns
  server s1 myapp.example.com:80 check resolve-opts allow-dup-ip
  server s2 myapp.example.com:81 check resolve-opts allow-dup-ip
```

allow-dup-ipオプションを設定した場合：

- ネームサーバーが単一のIPアドレスを返した場合、両方のサーバーがそのアドレスを使用します。
- ネームサーバーが2個のIPアドレスを返した場合、各サーバーは異なるアドレスを選びます。

デフォルト値：未設定

<a id="entry-5-2-resolve-prefer"></a>

**`resolve-prefer <family>`**

```haproxy
resolve-prefer <family>
```

使用可能なコンテキスト：tcp, http, log

サーバーでDNS名前解決が有効になっており、異なるアドレスファミリーのIPアドレスが複数返された場合、HAProxyは"resolve-prefer"パラメーターで指定したファミリーのIPアドレスを優先して使用します。特定のファミリーの使用を厳密に強制するには、globalキーワード"dns-accept-family"も参照してください。指定できるファミリーは"ipv4"と"ipv6"です。

デフォルト値：ipv6

例：

```text
server s1 app1.domain.com:80 resolvers mydns resolve-prefer ipv6
```

<a id="entry-5-2-resolve-net"></a>

**`resolve-net <network>[,<network[,...]]`**

```haproxy
resolve-net <network>[,<network[,...]]
```

使用可能なコンテキスト：tcp, http, log

このオプションは、指定したネットワークに一致するIPアドレスを優先して選択します。クラウド環境でローカルIPアドレスを優先する場合に便利です。クラウドの高可用性サービスが、複数の異なるデータセンターにある多数のIPアドレスで公開される場合があります。データセンター間の遅延は無視できないため、このパッチによってローカルのデータセンターを優先できます。設定したネットワークに一致するアドレスがない場合は、別のアドレスを選択します。

例：

```text
server s1 app1.domain.com:80 resolvers mydns resolve-net 10.0.0.0/8
```

<a id="entry-5-2-resolvers"></a>

**`resolvers <id>`**

```haproxy
resolvers <id>
```

使用可能なコンテキスト：tcp, http, log

現在のサーバーのホスト名を解決するために、既存の"resolvers"セクションを指定します。resolversを使う場合は、libcによる名前解決を無効にすることが推奨されることが多いですが、例外もあります（[5.3.1節](/ja/docs/haproxy/bind-and-server-options/#section-5-3-1)を参照）。いずれの場合も、この点を見落とさないよう、resolversの使用時には"init-addr"を明示的に指定するのがよい方法です。

例：

```text
server s1 app1.domain.com:80 init-addr last,none check resolvers mydns
```

実装の詳細と注意すべき落とし穴は、[セクション5.3](/ja/docs/haproxy/bind-and-server-options/#section-5-3)も参照してください。

<a id="entry-5-2-send-proxy"></a>

**`send-proxy`**

```haproxy
send-proxy
```

使用可能なコンテキスト：tcp, http

"send-proxy"パラメーターは、このサーバーに確立するすべての接続でPROXYプロトコルを使用するよう強制します。PROXYプロトコルは、受け入れた接続のレイヤー3/4のアドレスを相手に通知するので、上位層のプロトコルにかかわらず、クライアントのアドレスや、クライアントがアクセスした公開アドレスを相手が把握できます。"accept-proxy"または"accept-netscaler-cip"を指定したリスナーで受け入れた接続では、通知されたアドレスを使います。サポートするアドレスファミリーはTCPv4とTCPv6だけです。Unixソケットなど、ほかのファミリーではUNKNOWNを報告します。このオプションを使うサーバーは、"accept-proxy"を設定してリッスンする別のHAProxyインスタンスに、そのまま連結できます。サーバーがこのプロトコルに対応していない場合、この設定を使用してはいけません。このオプションを設定すると、サーバーに送るヘルスチェックにも自動的にPROXYプロトコルを使います。ただし、"port"または"addr"ディレクティブを明示した場合は例外で、PROXYプロトコルを使うには"check-send-proxy"も明示する必要があります。このセクションの"no-send-proxy"オプションと、"bind"キーワードの"accept-proxy"および"accept-netscaler-cip"オプションも参照してください。

<a id="entry-5-2-send-proxy-v2"></a>

**`send-proxy-v2`**

```haproxy
send-proxy-v2
```

使用可能なコンテキスト：tcp, http

"send-proxy-v2"パラメーターは、このサーバーに確立するすべての接続でPROXYプロトコルのバージョン2を使用するよう強制します。PROXYプロトコルは、受け入れた接続のレイヤー3/4のアドレスを相手に通知するので、上位層のプロトコルにかかわらず、クライアントのアドレスや、クライアントがアクセスした公開アドレスを相手が把握できます。ALPNのネゴシエーションが済んでいれば、その情報も送ります。サーバーがこのバージョンのプロトコルに対応していない場合、この設定を使用してはいけません。このセクションの"no-send-proxy-v2"オプションと、"bind"キーワードのsend-proxyオプションも参照してください。

<a id="entry-5-2-set-proxy-v2-tlv-fmt"></a>

**`set-proxy-v2-tlv-fmt(<id>) <fmt>`**

```haproxy
set-proxy-v2-tlv-fmt(<id>) <fmt>
```

使用可能なコンテキスト：tcp, http

"set-proxy-v2-tlv-fmt"パラメーターは、PROXYプロトコルのバージョン2で任意のTLVを送るために使います。定義済みのTLV型の型番号（`<id>`）の範囲については、PROXYプロトコル仕様のセクション2.2.8.を参照してください。一方、値は最大長の65,535バイトを超えない限り、自由に選べます。"fc_pp_tlv"のサンプル取得でフロントエンドが受信したTLVを取り出し、転送するためにも使えます。serverまたはdefault-serverのオプションとして使用できます。PPv2のTLVを実際に送信するため、send-proxy-v2と組み合わせて使う必要があります。

例: server srv1 192.168.1.1:80 send-proxy-v2 set-proxy-v2-tlv-fmt(0x20) %[fc_pp_tlv(0x20)]

この場合、型が0x20のTLVを文字列として取得し、新たに作成する同じく型が0x20のTLVの値に設定します。

<a id="entry-5-2-proxy-v2-options"></a>

**`proxy-v2-options <option>[,<option>]*`**

```haproxy
proxy-v2-options <option>[,<option>]*
```

使用可能なコンテキスト：tcp, http

"proxy-v2-options"パラメーターは、"send-proxy-v2"を使用する場合に、PROXYプロトコルのバージョン2で送信するオプションを追加します。使用できるオプションは次のとおりです。

- ssl："send-proxy-v2-ssl"も参照してください。
- cert-cn："send-proxy-v2-ssl-cn"も参照してください。
- ssl-cipher：使用する暗号の名前です。
- cert-sig：使用する証明書の署名アルゴリズムです。
- cert-key：使用する証明書の鍵アルゴリズムです。
- authority: クライアントが渡したホスト名の値です（TLS接続のSNIのみサポートします）。
- crc32c：PROXYv2ヘッダーのチェックサムです。
- unique-id: フロントエンドの"unique-id-format"で生成した一意のIDを、PROXYv2ヘッダー内で送ります。この一意のIDは、主に"mode tcp"向けです。生成した一意のIDはKeep-Alive接続内の最初のHTTPリクエストにも使用するため、"mode http"では予期しない結果になることがあります。

<a id="entry-5-2-send-proxy-v2-ssl"></a>

**`send-proxy-v2-ssl`**

```haproxy
send-proxy-v2-ssl
```

使用可能なコンテキスト：tcp, http

"send-proxy-v2-ssl"パラメーターは、このサーバーに確立するすべての接続でPROXYプロトコルのバージョン2を使用するよう強制します。PROXYプロトコルは、受け入れた接続のレイヤー3/4のアドレスを相手に通知するので、上位層のプロトコルにかかわらず、クライアントのアドレスや、クライアントがアクセスした公開アドレスを相手が把握できます。さらに、PROXYプロトコルのSSL情報拡張を、PROXYプロトコルヘッダーに追加します。サーバーがこのバージョンのプロトコルに対応していない場合、この設定を使用してはいけません。このセクションの"no-send-proxy-v2-ssl"オプションと、"bind"キーワードの"send-proxy-v2"オプションも参照してください。

<a id="entry-5-2-send-proxy-v2-ssl-cn"></a>

**`send-proxy-v2-ssl-cn`**

```haproxy
send-proxy-v2-ssl-cn
```

使用可能なコンテキスト：tcp, http

"send-proxy-v2-ssl"パラメーターは、このサーバーに確立するすべての接続でPROXYプロトコルのバージョン2を使用するよう強制します。PROXYプロトコルは、受け入れた接続のレイヤー3/4のアドレスを相手に通知するので、上位層のプロトコルにかかわらず、クライアントのアドレスや、クライアントがアクセスした公開アドレスを相手が把握できます。さらに、PROXYプロトコルのSSL情報拡張と、クライアント証明書がある場合はそのsubjectのCommon Nameも、PROXYプロトコルヘッダーに追加します。サーバーがこのバージョンのプロトコルに対応していない場合、この設定を使用してはいけません。このセクションの"no-send-proxy-v2-ssl-cn"オプションと、"bind"キーワードの"send-proxy-v2"オプションも参照してください。

<a id="entry-5-2-shard"></a>

**`shard <shard>`**

```haproxy
shard <shard>
```

使用可能なコンテキスト：peers

このパラメーターは、peersプロトコルによるスティックテーブルの同期でのみ使用します。"shard"パラメーターは、分散用ハッシュ値がこのシャードに一致するキーについて、スティックテーブルの更新をすべて受け取るピアを指定します。指定できる値は0から、"peers"セクションの"shards"パラメーターの値までです。デフォルト値の0では、すべてのキーの更新をピアが受け取ります。"shards"より大きい値は無視します。ローカルピアに指定した値も、すべて無視します。

例：

```haproxy
peers mypeers
     shards 3
     peer A 127.0.0.1:40001 # local peer without shard value (0 internally)
     peer B 127.0.0.1:40002 shard 1
     peer C 127.0.0.1:40003 shard 2
     peer D 127.0.0.1:40004 shard 3
```

<a id="entry-5-2-sigalgs"></a>

**`sigalgs <sigalgs>`**

```haproxy
sigalgs <sigalgs>
```

使用可能なコンテキスト：tcp, http, log, peers, ring

この設定は、OpenSSLのサポートを組み込んでビルドした場合にのみ使用できます。TLSv1.2とTLSv1.3のハンドシェイク中にネゴシエーションする署名アルゴリズムのリストを表す文字列を設定します。文字列の形式は、OpenSSLのmanページ"man 3 SSL_CTX_set1_sigalgs"に定義されています。中間装置との互換性が必要な場合を除き、この設定の使用は推奨しません。

<a id="entry-5-2-slowstart"></a>

**`slowstart <start_time_in_ms>`**

```haproxy
slowstart <start_time_in_ms>
```

使用可能なコンテキスト：tcp, http

サーバーの"slowstart"パラメーターには、復旧したばかりのサーバーが最大速度で動作するまでの時間をミリ秒で指定します。ほかの時間パラメーターと同様に、{ us, ms, s, m, h, d } の別の単位を明示して入力することもできます。この期間中、速度は0から100%まで線形に増加します。この制限は、次の二つのパラメーターに適用されます。

- maxconn: サーバーが受け入れる接続数は、(minconn,maxconn,fullconn)で定義した通常の動的な上限の1から100%まで増加します。

- weight: バックエンドが動的な重み付きアルゴリズムを使用する場合、重みは1から100%まで線形に増加します。この場合、ヘルスチェックのたびに重みを更新します。このため、段階数を最大にするには、"inter"パラメーターを"slowstart"より小さくすることが重要です。

HAProxyの起動時にはslowstartを適用しません。適用すると、稼働中のサーバーに問題を引き起こすためです。以前に障害状態と認識したサーバーにのみ適用します。

<a id="entry-5-2-sni"></a>

**`sni <expression>`**

```haproxy
sni <expression>
```

使用可能なコンテキスト：tcp, http, log, peers, ring

"sni"パラメーターは、サンプル取得式を評価し、結果を文字列に変換して、サーバーへ送るTLSのSNI拡張のホスト名として使います。代表的な用途は、TCP/SSLを橋渡しする構成で、"ssl_fc_sni"サンプル取得を式に指定し、クライアントから受け取ったSNIを送ることです。HTTPSでは、この方法を使用してはいけません。代わりにreq.hdr(host)を使うことを推奨します。HTTPSのSNIは常にHostフィールドと一致する必要があり、クライアントは同じ接続上で異なるホスト名を使用できるためです。推奨設定の"verify required"を指定すると、結果の名前をサーバー証明書内の名前とも照合します。詳細は"verify"ディレクティブを参照してください。ヘルスチェック用のSNIを設定したい場合は、"check-sni"ディレクティブの説明を参照してください。

デフォルトでは、serverキーワード"pool-conn-name"で上書きしない限り、SNIを"http-reuse"の接続名に割り当てます。

<a id="entry-5-2-sni-auto"></a>

**`sni-auto`**

```haproxy
sni-auto
```

使用可能なコンテキスト：tcp, http, log, peers, ring

"sni-auto"パラメーターは、まだ値が設定されていなければ、SNIの自動選択を有効にします。"sni"式を"req.hdr(host),field(1,:)"に設定し、サーバーに送るリクエストのHost名からポート番号を除いたものを、SNIとして提示します。デフォルトで有効ですが、"default-server"ディレクティブからデフォルト値として継承した"no-sni-auto"を取り消すため、"server"設定として使うこともできます。また、"default-server"設定として使い、以前の"default-server"の"no-sni-auto"設定を取り消すこともできます。

HTTPS接続では、リクエストのhostヘッダーの値が見つかれば、それに基づいてSNIを選択します。見つからない場合は未設定のままです。他のプロトコルでは、このオプションは無視します。

SNIの自動選択を使用する場合、serverキーワード"pool-conn-name"で上書きしない限り、その値を"http-reuse"の接続名に割り当てます。

SSLヘルスチェックでSNIの自動選択を有効にするには、"check-sni-auto"オプションを参照してください。

<a id="entry-5-2-source"></a>

**`source <addr>[:<pl>[-<ph>]] [usesrc { <addr2>[:<port2>] | client | clientip } ]`**

```haproxy
source <addr>[:<pl>[-<ph>]] [usesrc { <addr2>[:<port2>] | client | clientip } ]
source <addr>[:<port>] [usesrc { <addr2>[:<port2>] | hdr_ip(<hdr>[,<occ>]) } ]
source <addr>[:<pl>[-<ph>]] [interface <name>] ...
```

使用可能なコンテキスト：tcp, http, log, peers, ring

"source"パラメーターは、サーバーへの接続時に使用する送信元アドレスを設定します。これを参照するサーバーにだけ適用する点を除き、バックエンドの"source"キーワードとまったく同じパラメーターと原理に従います。詳細は"source"キーワードを参照してください。

さらに、server行の"source"では、下限と上限をダッシュ('-')で区切り、送信元ポートの範囲を指定できます。OSによっては、送信元ポートの範囲を指定するときに、有効なIPアドレスが必要な場合があります。複数のサーバーに同じIPアドレスと範囲を指定してもかまいません。これにより、同時接続の総数64kという上限を回避でき、上限はサーバーごとに64k接続になります。

Linux 4.2/libc 2.23以降では、ポートを指定せずに送信元アドレスを指定する接続に、IP_BIND_ADDRESS_NO_PORTを設定します。

<a id="entry-5-2-ssl"></a>

**`ssl`**

```haproxy
ssl
```

使用可能なコンテキスト：tcp, http, log, peers, ring

サーバーへの発信接続でSSL暗号化を有効にします。SSLでサーバーに接続する場合、"verify"でサーバー証明書を検証することが極めて重要です。検証しないと、通信は容易な中間者攻撃を受けやすくなり、SSLが役に立たなくなります。このオプションを使うと、ヘルスチェックも自動的にSSLで送ります。ただし、"port"または"addr"ディレクティブで、別の場所へチェックを送るよう指定している場合は例外です。"ssl"オプションを無効にするには"no-ssl"を、SSLヘルスチェックを強制するには"check-ssl"を参照してください。

<a id="entry-5-2-ssl-max-ver"></a>

**`ssl-max-ver [ SSLv3 | TLSv1.0 | TLSv1.1 | TLSv1.2 | TLSv1.3 ]`**

```haproxy
ssl-max-ver [ SSLv3 | TLSv1.0 | TLSv1.1 | TLSv1.2 | TLSv1.3 ]
```

使用可能なコンテキスト：tcp, http, log, peers, ring

このオプションは、サーバーとの通信でSSLを使用する場合に、`<version>`以下のバージョンを使うよう強制します。グローバル設定の"ssl-default-server-options"でも使用できます。"ssl-min-ver"も参照してください。

<a id="entry-5-2-ssl-min-ver"></a>

**`ssl-min-ver [ SSLv3 | TLSv1.0 | TLSv1.1 | TLSv1.2 | TLSv1.3 ]`**

```haproxy
ssl-min-ver [ SSLv3 | TLSv1.0 | TLSv1.1 | TLSv1.2 | TLSv1.3 ]
```

使用可能なコンテキスト：tcp, http, log, peers, ring

このオプションは、サーバーとの通信でSSLを使用する場合に、`<version>`以上のバージョンを使うよう強制します。グローバル設定の"ssl-default-server-options"でも使用できます。"ssl-max-ver"も参照してください。

<a id="entry-5-2-ssl-reuse"></a>

**`ssl-reuse`**

```haproxy
ssl-reuse
```

使用可能なコンテキスト：tcp, http, log, peers, ring

このオプションは、"default-server"ディレクティブからデフォルト値として継承した"no-ssl-reuse"設定を取り消すため、"server"設定として使用できます。また、"default-server"設定として使い、以前の"default-server"の"no-ssl-reuse"設定を取り消すこともできます。

<a id="entry-5-2-stick"></a>

**`stick`**

```haproxy
stick
```

使用可能なコンテキスト：tcp, http

このオプションは、"default-server"ディレクティブからデフォルト値として継承した"non-stick"設定を取り消すため、"server"設定として使用できます。また、"default-server"設定として使い、以前の"default-server"の"non-stick"設定を取り消すこともできます。

<a id="entry-5-2-strict-maxconn"></a>

**`strict-maxconn`**

```haproxy
strict-maxconn
```

使用可能なコンテキスト：tcp, http

サーバーのmaxconnという名前は、実際の意味を十分には表していません。実際に設定するのは、サーバーに送るリクエスト数の上限であり、アイドル接続を含めると、サーバーへの接続の総数はそれを超える場合があります。サーバーへの接続数を厳密に制限する必要がある場合は、strict-maxconnを追加できます。指定すると、maxconnを超える数の接続をサーバーに確立することはなく、必要に応じて接続の再利用や終了を試みます。ただし、新しい接続を確立できず、利用可能なアイドル接続もない場合、リクエストが失敗することがあります。認証が行われたことで、特定のセッションだけに結び付いた"private"接続が確立されている場合などに起こり得ます。

<a id="entry-5-2-socks4"></a>

**`socks4 <addr>:<port>`**

```haproxy
socks4 <addr>:<port>
```

使用可能なコンテキスト：tcp, http, log, peers, ring

このオプションは、サーバーへの発信接続でアップストリームのsocks4トンネルを有効にします。使用しても、デフォルトではヘルスチェックがsocks4を経由するようにはなりません。有効にするには、"check-via-socks4"キーワードを使用する必要があります。

<a id="entry-5-2-tcp-md5sig"></a>

**`tcp-md5sig <password>`**

```haproxy
tcp-md5sig <password>
```

使用可能なコンテキスト：tcp, http, log, peers, ring

このサーバーへのすべての発信接続で、TCP MD5署名（RFC 2385 Protection of BGP Sessions via the TCP MD5 Signature Option）を有効にします。このオプションはLinuxでのみ使用できます。有効にすると、`<password>`文字列を使い、すべてのTCPセグメントに16バイトのMD5ダイジェストで署名します。これにより、TCP接続をなりすましから保護します。主な用途は、偽造されたTCPセグメントが接続ストリームに挿入される攻撃から、BGPを保護することです。ただし、非常に長く存続するTCP接続全般で役立つ場合があります。

<a id="entry-5-2-tcp-ut"></a>

**`tcp-ut <delay>`**

```haproxy
tcp-ut <delay>
```

使用可能なコンテキスト：tcp, http, log, peers, ring

このサーバーへのすべての発信接続にTCP User Timeoutを設定します。このオプションはLinux 2.6.37以降で使用できます。指定した時間内に確認応答を受け取れないデータを含むソケットに対し、HAProxyがタイムアウトを設定できるようにします。リモート端末やデータベースの接続プールなど、長いアイドル期間のある長時間接続で特に役立ちます。そのような接続では、長いアイドル期間を許容するために、クライアントとサーバーのタイムアウトを長く保つ必要があります。一方、接続（およびクライアントのセッション）に関連するすべてのリソースを解放するため、サーバーが消失したことを検出するのも重要です。ほかの代表的な用途として、ヘルスチェックが遅すぎる場合や、ヘルスチェックが無効になるソフトリロード中に、停止したサーバーへの接続を強制的に終了させることも挙げられます。引数は時間で、デフォルトの単位はミリ秒です。通常のTCP接続だけに作用し、ほかのプロトコルでは無視します。

<a id="entry-5-2-tfo"></a>

**`tfo`**

```haproxy
tfo
```

使用可能なコンテキスト：tcp, http, log, peers, ring

このオプションは、対応するシステム（現在はLinuxカーネル \>= 4.11のみ）で、サーバーへの接続時にTCP Fast Openを使用できるようにします。TCP Fast Openの詳細については、bindの"tfo"オプションを参照してください。tfoを使用する場合は、"retry-on"に"conn-failure"、"empty-response"、"response-timeout"キーワードも指定するべきです。そうしないと、障害時にHAProxyが接続を再試行できません。"no-tfo"も参照してください。

<a id="entry-5-2-track"></a>

**`track [<backend>/]<server>`**

```haproxy
track [<backend>/]<server>
```

使用可能なコンテキスト：tcp, http, log

このオプションを使うと、別のサーバーを追跡して、対象サーバーの現在の状態を設定できます。追跡の連鎖の最後にあるサーバーでヘルスチェックが有効になっていれば、別のサーバーを追跡しているサーバーを追跡することもできます。`<backend>`を省略した場合は、現在のバックエンドを使用します。disable-on-404を使う場合は、両方のプロキシで有効にする必要があります。

例：

```text
backend A
server a1 1.1.1.1:80 track B/b1
server a2 1.1.1.2:80 track B/b1

backend B
server b1 2.2.2.2:80 check
```

<a id="entry-5-2-tls-tickets"></a>

**`tls-tickets`**

```haproxy
tls-tickets
```

使用可能なコンテキスト：tcp, http, log, peers, ring

このオプションは、"default-server"ディレクティブからデフォルト値として継承した"no-tls-tickets"を取り消すため、"server"設定として使用できます。TLSチケットの仕組みを使用するのはTLS 1.2までです。チケットの鍵を定期的にローテーションしない限り（リロード、または"tls-ticket-keys"を使用）、TLSチケットによって前方秘匿性が損なわれます。また、"default-server"設定として使い、以前の"default-server"の"no-tls-tickets"設定を取り消すこともできます。

<a id="entry-5-2-verify"></a>

**`verify [none|required]`**

```haproxy
verify [none|required]
```

使用可能なコンテキスト：tcp, http, log, peers, ring

この設定は、OpenSSLのサポートを組み込んでビルドした場合だけ使用できます。'none'の場合、サーバー証明書を検証しません。それ以外の場合、まず証明書のsubjectおよびsubjectAlternateNames属性にある名前が、"sni"ディレクティブで渡した名前、またはそれを指定していなければ"verifyhost"ディレクティブで渡した静的なホスト名と一致することを確認します。その後、'ca-file'のCAと、任意指定の'crl-file'のCRLを使って、サーバーから渡された証明書を検証します。照合する名前が見つからない場合、証明書内の名前は無視します。このため、SNIを使わない場合には"verifyhost"の使用が重要です。検証に失敗すると、ハンドシェイクを中断します。SSLでサーバーに接続する際、サーバー証明書の検証は極めて重要です。検証しないと、通信は容易な中間者攻撃を受けやすくなり、SSLがまったく役に立たなくなります。globalセクションに"ssl_server_verify"がない限り、"verify"のデフォルトは"required"です。

<a id="entry-5-2-verifyhost"></a>

**`verifyhost <hostname>`**

```haproxy
verifyhost <hostname>
```

使用可能なコンテキスト：tcp, http, log, peers, ring

この設定は、OpenSSLのサポートを組み込んでビルドした場合だけ使用でき、'verify required'も指定した場合にだけ有効です。サーバーへの接続にSNIを使わなかった場合に、サーバー証明書との照合に使う、デフォルトの静的なホスト名を設定します。SNIを使わない場合、ホスト名の検証を有効にする唯一の方法です。この静的ホスト名を設定すると、SNI値を指定しないヘルスチェックにも使います。証明書内のどのホスト名も指定したホスト名と一致しない場合、ハンドシェイクを中断します。サーバーが提示する証明書内のホスト名には、ワイルドカードを含められます。"verify"、"sni"、"no-verifyhost"オプションも参照してください。

<a id="entry-5-2-weight"></a>

**`weight <weight>`**

```haproxy
weight <weight>
```

使用可能なコンテキスト：tcp, http

"weight"パラメーターは、ほかのサーバーに対する相対的な重みを調整します。各サーバーは、重みの合計に対する自身の重みの割合に応じた負荷を受け取るので、重みが大きいほど負荷も高くなります。デフォルトの重みは1、最大値は256です。0にすると、サーバーは負荷分散に参加しませんが、永続性に基づく接続は引き続き受け入れます。このパラメーターでサーバーの処理能力に応じて負荷を分散する場合、たとえば10から100までのように、後で上下どちらにも十分に調整できる値から始めることを推奨します。

<a id="entry-5-2-ws"></a>

**`ws { auto | h1 | h2 }`**

```haproxy
ws { auto | h1 | h2 }
```

使用可能なコンテキスト：http

このオプションは、WebSocketストリームを中継するときに使用するプロトコルを設定します。特に、RFC8441によるH2 WebSocketをサポートしていないHTTP/2バックエンドを使う場合に有用です。

デフォルトのモードは"auto"です。通常の通信と同じプロトコルを再利用します。ALPNを使う場合だけ動作が異なります。この場合、WebSocketストリームに限り、ALPNを"http/1.1"に下げることを試みます。ただし、設定されたサーバーのALPNにこの値が含まれている場合に限ります。

"h1"を指定すると、WebSocketストリームでHTTP/1.1を強制します。サーバーでSSL ALPNが有効なら、ALPNを通じて指定します。同様に、"h2"はHTTP/2.0 WebSocketを強制します。この値は慎重に使用してください。サーバーがRFC8441をサポートしている必要があり、そうでなければ、WebSocketの中継時にhaproxyがエラーを報告します。

NPNはALPN拡張への移行に伴い非推奨となっているため、考慮されません。

"alpn"と"proto"も参照してください。

## 5.3. DNSによるサーバーIPアドレスの解決 {#section-5-3}

HAProxyでは、server行にホスト名を指定し、ネームサーバーを使ってそのIPアドレスを取得できます。デフォルトでは、起動時に設定ファイルを解析するときに名前を解決し、プロセスの存続期間中は結果をキャッシュします。ただし、これだけでは不十分な場合があります。たとえばAmazonでは、再起動後にサーバーのIPが変わったり、現在の負荷に応じてELBの仮想IPが変わったりすることがあります。

この章では、実行時にサーバーの名前解決を行うようにHAProxyを設定する方法を説明します。

実行時のサーバー名解決を有効にしているかどうかにかかわらず、"init-addr"パラメーターで無効にしない限り、HAProxyはデフォルトで起動時の設定解析中にlibcを通じて最初の名前解決を行います。

### 5.3.1. 全体の概要 {#section-5-3-1}

はじめに説明したとおり、HAProxyの名前解決は、プロセスの存続期間中の異なる二つの段階で行われます。

```text
1. 起動時にHAProxyはserver行の定義を解析し、ホスト名を見つけます。
   libcの関数を使ってホスト名を解決します。
   この名前解決は/etc/resolv.confファイルに依存します。

2. 実行時にHAProxyは、DNSによる名前解決が必要なサーバーに対し、
   定期的に名前解決を行います。
```

実行時には、ほかのイベントによっても名前解決が開始されることがあります。

- サーバーのヘルスチェックが接続タイムアウトで終わった場合。サーバーのIPアドレスが変わった可能性があるため、新しいIPを知るには名前解決を開始する必要があります。

resolversを使う場合、サーバー名にはホスト名またはSRVラベルを指定できます。HAProxyは、アンダースコアで始まるものをすべてSRVラベルとみなします。SRVラベルを指定すると、対応するSRVレコードをDNSサーバーから取得し、そこに記載されたホスト名を使用します。SRVラベルは定期的に確認され、サーバーが追加または削除されると、HAProxyも自動的に同じ変更を行います。

次の点に注意してください。

- すべてのネームサーバーに同時に問い合わせます。HAProxyは最初の有効なレスポンスを処理します。

- すべてのサーバーがエラーを返すと、名前解決は無効（NX、timeout、refused）とみなされます。

- HAProxyに実装されたDNSクライアントは非常に基本的なもので、OSのリゾルバーが扱える多数のオプションや高度な構成は理解できません。そのため、FQDNで指定したサーバーが常にちょうど一つのIPアドレスだけを持ち、再起動時などにときどき更新するような極めて単純な構成を除き、libcによる初期化時の名前解決とDNSによる実行時の名前解決を混在させないことを強く推奨します。このような混在構成では、アドレス更新時に障害が起こることが知られています。したがって、自分が何をしているかを正確に理解している場合を除き、server行で"resolvers"を使うときは、常に"init-addr"から"libc"を除外することを推奨します。

### 5.3.2. resolversセクション {#section-5-3-2}

このセクションには、HAProxyの名前解決に関する情報を記述します。resolversセクションは必要なだけ作成でき、各セクションには複数のネームサーバーを含められます。

起動時に、設定内に"default"という名前のresolversセクションがなければ、HAProxyはそのセクションを生成しようとします。このセクションはhttpclientがデフォルトで使うもので、parse-resolv-confキーワードを使用します。自動生成に失敗しても、HAProxyはエラーや警告を出しません。

resolversセクションに複数のネームサーバーが設定されている場合、HAProxyは最初の有効なレスポンスを使います。無効なレスポンスの場合は、最後のものだけを処理します。これは、速いサーバーが誤った、または古いレスポンスを返しても、遅いサーバーに有効な回答を返す機会を与えるためです。

各サーバーが異なる種類のエラーを返す場合、HAProxyは最後のエラーだけを使います。そのエラーに対して次の処理を行います。

```text
1. HAProxyはクエリータイプを変更して同じDNSクエリーを再試行します。
   AクエリーはAAAAに、その逆も同様に切り替えます。
   SRVクエリーとタイムアウトエラーは対象外です。

2. クエリータイプの切り替えが済んだ場合（または適用できない場合）、
   HAProxyは優先するクエリータイプで元のDNSクエリーを再試行します。

3. HAProxyは以上の手順を<resolve_retries>回再試行します。
   それでも有効なレスポンスを受信できなければ、DNS解決を停止し、
   エラーを報告します。
```

たとえば、resolversセクションに2つのネームサーバーを設定している場合、次の状況が考えられます。

- 最初のレスポンスが有効なら、そのまま適用し、次のレスポンスは無視します。

- 最初のレスポンスが無効で次のレスポンスが有効なら、次のレスポンスを適用します。

- 最初のレスポンスがNX domainで次が切り詰められたレスポンスなら、HAProxyはクエリータイプを変更して再試行します。

- 最初のレスポンスがNX domainで次がタイムアウトなら、HAProxyはクエリータイプを変更して再試行します。

- 両方のネームサーバーへのクエリーがタイムアウトした場合、HAProxyは同じクエリータイプで再試行します。

DNSサーバーは、一度のDNSリクエストに対してすべてのIPを返すとは限らないため、HAProxyは以前の回答をキャッシュします。そのIPが返されないまま`<hold obsolete>`秒が経過すると、その回答は古くなったとみなされます。

<a id="entry-5-3-2-resolvers"></a>

**`resolvers <resolvers id>`**

```haproxy
resolvers <resolvers id>
```

`<resolvers id>`という名前の新しいネームサーバー一覧を作成します。前述のとおり、特別な名前"default"は常に存在し、明示的に宣言しなければ自動作成されます。httpclientなどの内部サービスはこれを使用します。"default"エントリーを宣言すると、これらのサービスの名前解決方法に影響します。

resolversセクションでは、次のパラメーターを指定できます。

<a id="entry-5-3-2-accepted-payload-size"></a>

**`accepted_payload_size <nb>`**

```haproxy
accepted_payload_size <nb>
```

HAProxyが受け付け、このresolversセクションで設定されたすべてのネームサーバーに通知する最大ペイロードサイズを定義します。`<nb>`の単位はバイトです。未設定の場合、HAProxyは512（RFC 6891で定義された最小値）を通知します。

注意：指定可能な最大値は65535です。UDPでの推奨値は4096です。システムとネットワークが処理できると確信できる場合を除き、8192を超える値は推奨しません（UDPの最大ペイロードサイズは65507なので、それを超えても意味はありません）。大きなDNSレスポンスを処理するためにTCPネームサーバーだけを使う場合は、最大値の65535に設定することを推奨します。

<a id="entry-5-3-2-nameserver"></a>

**`nameserver <name> <address>[:port] [param*]`**

```haproxy
nameserver <name> <address>[:port] [param*]
```

ネームサーバーを設定します。ネームサーバーの`<name>`は一意にすることを推奨します。デフォルトでは、`<address>`はデータグラム型とみなされます。つまり、特別なアドレス接頭辞（11項）を付けずにIPv4またはIPv6を設定すると、UDPプロトコルを使います。ストリームプロトコルのアドレス接頭辞を使うと、ネームサーバーはTCPなどのストリームサーバーとみなされ、5.2項の"server"パラメーターのうちDNS解決に関係するものが適用されます。注意：現在、TCPモードでは同じ接続上で4つのクエリーをパイプライン処理します。アイドル接続は5秒ごとにまとめて削除されます。"maxconn"を設定して同時接続数を制限できます。また、サーバーがサポートしていればTLSも使用できるはずです。

<a id="entry-5-3-2-parse-resolv-conf"></a>

**`parse-resolv-conf`**

```haproxy
parse-resolv-conf
```

/etc/resolv.confに記載されたすべてのネームサーバーを、このresolversのネームサーバー一覧に追加します。順序は、/etc/resolv.confの各ネームサーバーを、このディレクティブの位置でresolversセクションに個別に記述した場合と同じです。

<a id="entry-5-3-2-hold"></a>

**`hold <status> <period>`**

```haproxy
hold <status> <period>
```

DNSレスポンス`<status>`を受信すると、サーバーの状態をUPからDOWNに変更すべきか判断します。そのために、過去の`<period>`内に有効なステータスを受信しており、今回受信した無効なステータスを打ち消せるか確認します。

    `<status>`：最後の名前解決のステータス。
           nx        NXDOMAINステータスを受信した後、直近の指定期間内に
                     有効なステータスを受信したか確認します。

           refused   REFUSEDステータスを受信した後、直近の指定期間内に
                     有効なステータスを受信したか確認します。

           timeout   "timeout retry"が発生した後、直近の指定期間内に
                     有効なステータスを受信したか確認します。

           other     その他の無効なステータスを受信した後、直近の指定期間内に
                     有効なステータスを受信したか確認します。

           valid     "http-request do-resolve"と
                     "tcp-request content do-resolve"アクションにのみ適用します。
                     次の名前解決を開始するまで、サーバーが有効なレスポンスを
                     保持する期間を定義します。
                     サーバーの動的な名前解決には影響しません。

           obsolete  更新された回答レコードを受信した後、古いDNSレコードを
                     削除するまでの待機時間を定義します。
                     SRVレコードに適用します。

    `<period>`：有効なレスポンスを受信している必要がある、現在から遡った期間。
               HAProxyの時間形式に従い、
               デフォルトの単位はミリ秒です。

IPアドレスの特定を動的なDNS解決に依存するサーバーでは、NXDOMAINなどの無効なDNSレスポンスを受信すると、状態がUPからDOWNに変わります。holdディレクティブは、有効なレスポンスを確認するためにどこまで過去に遡るかを定義します。`<period>`内に有効なレスポンスを受信していれば、今回受信した無効なステータスは無視します。

直近の指定期間内に有効なレスポンスを受信していなければ、サーバーはDOWNとマークされます。たとえば、"hold nx 30s"を設定しており、最後に受信したDNSレスポンスがNXDOMAINの場合、過去30秒以内に有効なレスポンスを受信していなければ、サーバーはDOWNとマークされます。

DOWN状態のサーバーは、DNSサーバーから有効なステータスを受信すると直ちにUPとマークされます。

"hold valid"と"hold obsolete"には、それぞれ別の動作があります。

デフォルト値は、"valid"が10s、"obsolete"が0s、それ以外が30sです。

<a id="entry-5-3-2-resolve-retries"></a>

**`resolve_retries <nb>`**

```haproxy
resolve_retries <nb>
```

サーバー名の解決を断念するまでに送信するクエリーの数`<nb>`を定義します。デフォルト値は3です。

ネームサーバーがタイムアウトした場合、またはDNSクエリータイプを切り替える一連の処理がすべて終わり、デフォルトのANYクエリータイプからやり直す必要がある場合に、再試行します。

<a id="entry-5-3-2-timeout"></a>

**`timeout <event> <time>`**

```haproxy
timeout <event> <time>
```

名前解決に関するタイムアウトを定義します。`<event>`は`<time>`のタイムアウト期間を適用するイベントです。指定可能なイベント：- resolve：ほかの時間設定が適用されない場合に、名前解決を開始するデフォルトの時間。デフォルト値：1s - retry：有効なレスポンスを受信していない場合の、DNSクエリー間の時間。デフォルト値：1s `<time>`：イベントに関する時間。HAProxyの時間形式に従います。`<time>`はミリ秒で表します。

例：

```text
resolvers mydns
  nameserver dns1 10.0.0.1:53
  nameserver dns2 10.0.0.2:53
  nameserver dns3 tcp@10.0.0.3:53
  parse-resolv-conf
  resolve_retries       3
  timeout resolve       1s
  timeout retry         1s
  hold other           30s
  hold refused         30s
  hold nx              30s
  hold timeout         30s
  hold valid           10s
  hold obsolete        30s
```

---

逆リンク:

- [3. globalセクション](/ja/docs/haproxy/global/)
- [4. プロキシ](/ja/docs/haproxy/proxies/)
- [9. 統計情報とモニタリング](/ja/docs/haproxy/statistics-and-monitoring/)
- [11. スティックテーブルとピア](/ja/docs/haproxy/stick-tables-and-peers/)