# 5. Bind- und Server-Optionen
> Listener, Server, default-server und DNS-Auflösungsoptionen
---
LLMS-Index: [llms.txt](/de/llms.txt)
---
Die Schlüsselwörter "bind", "server" und "default-server" unterstützen je nach Build-Optionen und der Systemumgebung, auf der HAProxy gebaut wurde, eine Reihe von Einstellungen. Diese Einstellungen bestehen in der Regel aus einem Wort, gegebenenfalls gefolgt von einem Wert, und werden in derselben Zeile wie die "bind"- oder "server"-Zeile angegeben. Alle diese Optionen werden in diesem Abschnitt beschrieben.
## 5.1. Bind-Optionen {#section-5-1}
Das Schlüsselwort "bind" unterstützt eine bestimmte Anzahl von Einstellungen, die alle als Argumente in derselben Zeile übergeben werden. Die Reihenfolge, in der diese Argumente erscheinen, ist ohne Bedeutung, solange sie nach der Bind-Adresse stehen. Alle diese Parameter sind optional. Einige bestehen aus einem einzelnen Wort (Boolescher Wert), während andere danach einen Wert erwarten. In diesem Fall muss der Wert unmittelbar nach dem Einstellungsnamen angegeben werden.
Die derzeit unterstützten Einstellungen sind die folgenden.
`**
```haproxy
accept-netscaler-cip
```
Erzwingt die Verwendung des NetScaler Client IP Insertion-Protokolls für jede Verbindung, die von einem der auf derselben Zeile deklarierten TCP-Sockets akzeptiert wird. Das NetScaler Client IP Insertion-Protokoll legt die Layer-3/4-Adressen der eingehenden Verbindung fest, die überall dort verwendet werden, wo eine Adresse benötigt wird, mit der Ausnahme von „tcp-request connection“-Regeln, die nur die echte Verbindungsadresse sehen. Die Protokollausgaben spiegeln die in diesem Protokoll angegebenen Adressen wider, sofern das Protokoll nicht verletzt wird; in diesem Fall wird weiterhin die echte Adresse verwendet. Dieses Schlüsselwort, kombiniert mit Unterstützung durch externe Komponenten, kann als effizienter und zuverlässiger Ersatz für das X-Forwarded-For-Verfahren dienen, das nicht immer zuverlässig ist und nicht einmal immer verwendbar ist. Siehe auch „tcp-request connection expect-netscaler-cip“ für eine feinere Einstellung, welche Clients das Protokoll nutzen dürfen.
`**
```haproxy
alpn
```
Aktiviert die TLS-ALPN-Erweiterung und meldet die angegebene Protokollliste als unterstützte Protokolle über ALPN. Die Protokollliste besteht aus einer durch Kommas getrennten Liste von Protokollnamen, beispielsweise: "http/1.1,http/1.0" (ohne Anführungszeichen). Dies erfordert, dass die SSL-Bibliothek mit Unterstützung für TLS-Erweiterungen gebaut wurde (überprüfen Sie mit haproxy -vv). Die ALPN-Erweiterung ersetzt die ursprüngliche NPN-Erweiterung. Auf Protokollebene ist ALPN erforderlich, um HTTP/2 auf einem HTTPS-Frontend und HTTP/3 auf einem QUIC-Frontend zu aktivieren. Wenn bei solchen Frontends keine der Einstellungen "npn", "alpn" und "no-alpn" gesetzt ist, wird für ein reguläres HTTPS-Frontend standardmäßig "h2,http/1.1" und für ein QUIC-Frontend "h3" verwendet. Versionen von OpenSSL vor 1.0.2 unterstützten ALPN nicht und unterstützten lediglich die mittlerweile veraltete NPN-Erweiterung. Zum Zeitpunkt der Erstellung dieses Dokuments unterstützen die meisten Browser weiterhin sowohl ALPN als auch NPN für HTTP/2, sodass ein Fallback auf NPN noch eine Weile funktionieren könnte. ALPN muss jedoch, wann immer möglich, verwendet werden. Protokolle, die nicht angeboten werden, werden nicht verhandelt. Es ist beispielsweise möglich, nur HTTP/2-Verbindungen zu akzeptieren:
```text
bind :443 ssl crt pub.pem alpn h2 # explicitly disable HTTP/1.1
```
QUIC unterstützt nur h3 und hq-interop als ALPN. h3 steht für HTTP/3 und hq-interop wird für http/0.9 und den QUIC-Interop-Runner verwendet (siehe ). Jede "alpn"-Anweisung ersetzt die vorherige. Um sie zu entfernen, verwenden Sie "no-alpn".
Beachten Sie, dass einige ältere Browser wie Firefox 88 Probleme mit WebSocket über H2 hatten. Falls ein solcher Einsatz vorliegt, kann es erforderlich sein, entweder HTTP/2 in der "alpn"-Zeichenkette explizit zu deaktivieren, indem Sie es auf "http/1.1" oder "no-alpn" setzen, oder "h2-workaround-bogus-websocket-clients" global zu aktivieren.
`**
```haproxy
backlog
```
Legt die Backlog-Einstellung des Sockets auf diesen Wert fest. Wenn nicht angegeben oder 0, wird stattdessen der Backlog des Frontends verwendet, der in der Regel auf den Wert von maxconn festgelegt ist.
`**
```haproxy
ca-file
```
Diese Einstellung ist nur verfügbar, wenn Unterstützung für OpenSSL einkompiliert wurde. Sie legt eine PEM-Datei fest, aus der CA-Zertifikate geladen werden, die zur Überprüfung des Clientzertifikats verwendet werden. Es ist möglich, ein Verzeichnis mit mehreren CAs zu laden; in diesem Fall versucht HAProxy, jede Datei mit den Endungen ".pem", ".crt", ".cer" und .crl" im Verzeichnis zu laden. Dateien, die mit einem Punkt beginnen, werden ignoriert.
Warnung: Der Parameter "@system-ca" kann anstelle von cafile verwendet werden, um die vertrauenswürdigen CAs Ihres Systems zu nutzen, wie dies bei der server-Anweisung geschieht. Sie dürfen ihn jedoch nur verwenden, wenn Sie wissen, was Sie tun. Die Konfiguration auf diese Weise bedeutet im Wesentlichen, dass der mit bind konfigurierte Listener jedes Clientzertifikat akzeptiert, das von einer der CAs auf Ihrem System generiert wurde, was äußerst unsicher ist.
,...]`**
```haproxy
ca-ignore-err [all|,...]
```
Diese Einstellung ist nur verfügbar, wenn Unterstützung für OpenSSL einkompiliert wurde. Legt eine durch Kommas getrennte Liste von Fehler-IDs fest, die bei der Überprüfung auf Tiefe > 0 ignoriert werden sollen. Es kann sich um eine numerische ID oder um den Konstantennamen (X509_V_ERR) handeln, der in der OpenSSL-Dokumentation verfügbar ist:
Es wird empfohlen, den Konstantennamen zu verwenden, da der numerische Wert in neuen OpenSSL-Versionen geändert werden kann. Wenn auf 'all' gesetzt, werden alle Fehler ignoriert. Der SSL-Handshake wird nicht abgebrochen, wenn ein Fehler ignoriert wird.
`**
```haproxy
ca-sign-file
```
Diese Einstellung ist nur verfügbar, wenn Unterstützung für OpenSSL einkompiliert wurde. Sie legt eine PEM-Datei fest, die sowohl das CA-Zertifikat als auch den CA-Privatschlüssel enthält, der zur Erstellung und Signierung von Serverzertifikaten verwendet wird. Dies ist eine obligatorische Einstellung, wenn die dynamische Generierung von Zertifikaten aktiviert ist. Weitere Details finden Sie unter 'generate-certificates'.
`**
```haproxy
ca-sign-pass
```
Diese Einstellung ist nur verfügbar, wenn Unterstützung für OpenSSL einkompiliert wurde. Sie gibt die Passphrase für den CA-Privatschlüssel an. Diese Einstellung ist optional und wird nur verwendet, wenn die dynamische Generierung von Zertifikaten aktiviert ist. Weitere Details finden Sie unter 'generate-certificates'.
`**
```haproxy
ca-verify-file
```
Diese Einstellung legt eine PEM-Datei fest, aus der CA-Zertifikate geladen werden, die zur Überprüfung des Clientzertifikats verwendet werden. Sie legt CA-Zertifikate fest, die nicht in den in der Server-Hello-Nachricht gesendeten CA-Namen enthalten sein dürfen. Typischerweise muss "ca-file" mit Zwischenzertifikaten und "ca-verify-file" mit Zertifikaten definiert werden, die die Kette abschließen, wie beispielsweise die Root-CA.
`**
```haproxy
cc
```
Diese Einstellung ist nur auf Systemen verfügbar, die TCP_CONGESTION definieren, und wurde unter Linux
und FreeBSD überprüft. Sie übernimmt den Namen eines TCP-Überlastungssteuerungsalgorithmus und richtet
den Listener so ein, dass er diesen Algorithmus für alle von ihm angenommenen Verbindungen verwendet.
Typische Namen sind "reno" und "cubic"; sie hängen vom Betriebssystem ab. Auf manchen Systemen können
besondere Berechtigungen erforderlich sein, um bestimmte Algorithmen zu konfigurieren. Unter Linux
steht die Liste verfügbarer Algorithmen im sysctl "net.ipv4.tcp_available_congestion_control"; die ohne
besondere Rechte zulässigen Algorithmen stehen in "net.ipv4.tcp_allowed_congestion_control". Für
Algorithmen, die zusätzliche Berechtigungen benötigen, kann die Capability "cap_net_admin" erforderlich
sein (siehe "setcap" im global-Abschnitt). Kann ein bestimmter Überlastungssteuerungsalgorithmus nicht
konfiguriert werden, bleibt der Standardalgorithmus unverändert und eine Warnung meldet das Problem.
Siehe auch das server-Schlüsselwort "cc" ([Abschnitt 5.2](/de/docs/haproxy/bind-and-server-options/#section-5-2)).
Beispiel:
```text
frontend public
bind :443 cc bbr # use the BBR algorithm for high bandwidths
```
`**
```haproxy
ciphers
```
Diese Einstellung ist nur verfügbar, wenn Unterstützung für OpenSSL einkompiliert wurde. Sie legt
die Zeichenfolge mit der Liste der Verschlüsselungsalgorithmen ("Cipher-Suite") fest, die beim
SSL/TLS-Handshake bis einschließlich TLSv1.2 ausgehandelt werden. Das Format der Zeichenfolge ist in
"man 1 ciphers" in den OpenSSL-Handbuchseiten definiert. Hintergrundinformationen und Empfehlungen
finden Sie beispielsweise unter () und
(`**
```haproxy
ciphersuites
```
Diese Einstellung ist nur verfügbar, wenn Unterstützung für OpenSSL einkompiliert wurde und
HAProxy mit OpenSSL 1.1.1 oder neuer gebaut wurde. Sie legt die Zeichenfolge mit der Liste der
Verschlüsselungsalgorithmen ("Cipher-Suite") fest, die beim TLSv1.3-Handshake ausgehandelt werden.
Das Format der Zeichenfolge ist im Abschnitt "ciphersuites" von "man 1 ciphers" in den
OpenSSL-Handbuchseiten definiert. Zur Konfiguration der Verschlüsselungsalgorithmen für TLSv1.2
und ältere Versionen siehe das Schlüsselwort "ciphers". Diese Einstellung akzeptiert möglicherweise
TLSv1.2-Cipher-Suites; dieses Verhalten ist jedoch nicht dokumentiert und wird nicht empfohlen,
da es inkonsistent oder fehlerhaft sein könnte. Die standardmäßigen TLSv1.3-Cipher-Suites von OpenSSL sind:
"TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256"
TLSv1.3 unterstützt nur 5 Cipher-Suites:
- 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
Beispiel:
```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
```
`**
```haproxy
client-sigalgs
```
Diese Einstellung ist nur verfügbar, wenn Unterstützung für OpenSSL einkompiliert wurde. Sie legt
die Zeichenfolge mit der Liste der ausgehandelten Signaturalgorithmen für die Clientauthentifizierung
fest. Das Format der Zeichenfolge ist in "man 3 SSL_CTX_set1_client_sigalgs" in den OpenSSL-Handbuchseiten
definiert. Ohne konkreten Anwendungsfall wird von dieser Einstellung abgeraten.
`**
```haproxy
crl-file
```
Diese Einstellung ist nur verfügbar, wenn Unterstützung für OpenSSL einkompiliert wurde. Sie gibt
eine PEM-Datei an, aus der die zur Überprüfung des Clientzertifikats verwendete Zertifikatssperrliste
geladen wird. Für jedes Zertifikat in Ihrer Zertifizierungsstellenkette muss eine Zertifikatssperrliste
bereitgestellt werden.
`**
```haproxy
crt
```
Diese Einstellung ist nur verfügbar, wenn Unterstützung für OpenSSL einkompiliert wurde.
HAProxy verwendet einen Cache: Dateien werden nur einmal in den Zertifikatsspeicher geladen;
jedes weitere Schlüsselwort "crt" verwendet diese zwischengespeicherte Version. Wurde das Zertifikat
in einem "crt-store" deklariert, wird der Zertifikatsspeicher von dort befüllt. Es wird dann nicht
versucht, anhand von Dateierweiterungen zusätzliche Dateien zu laden.
Die Einstellung gibt eine PEM-Datei an, die sowohl die erforderlichen Zertifikate als auch die
zugehörigen privaten Schlüssel enthält. Diese Datei kann durch Zusammenfügen mehrerer PEM-Dateien
erstellt werden (z. B. cat cert.pem key.pem \>
combined.pem). Benötigt Ihre CA ein Zwischenzertifikat, kann dieses ebenfalls an die Datei angehängt
werden. Zwischenzertifikate können auch über die Direktive "issuers-chain-path" gemeinsam in einem
Verzeichnis bereitgestellt werden.
Enthält die Datei keinen privaten Schlüssel, versucht HAProxy, den Schlüssel unter demselben Pfad
mit der angehängten Endung ".key" zu laden.
Unterstützt die verwendete OpenSSL-Version Diffie-Hellman, werden die in dieser Datei enthaltenen
Parameter geladen.
Wird statt einer PEM-Datei ein Verzeichnisname verwendet, werden alle Dateien dieses Verzeichnisses
in alphabetischer Reihenfolge geladen, außer ihre Namen enden auf '.key', '.issuer', '.ocsp' oder
'.sctl' (reservierte Erweiterungen). Dateien, deren Namen mit einem Punkt beginnen, werden ebenfalls
ignoriert. Die Direktive kann mehrfach angegeben werden, um Zertifikate aus mehreren Dateien oder
Verzeichnissen zu laden. Die Zertifikate werden Clients präsentiert, die ein gültiges TLS-Feld
Server Name Indication übermitteln, das zu einem ihrer CN oder alternativen Subjektnamen passt.
Platzhalter werden unterstützt; dabei ersetzt das Platzhalterzeichen '\*' den ersten Bestandteil
des Hostnamens (z. B. passt \*.example.org zu [www.example.org](http://www.example.org), aber nicht
zu [www.sub.example.org](http://www.sub.example.org)). Bei einem leeren Verzeichnis startet HAProxy
nur, wenn das Schlüsselwort "strict-sni" verwendet wird.
Übermittelt der Client keine SNI, unterstützt die SSL-Bibliothek keine TLS-Erweiterungen oder
übermittelt der Client einen SNI-Hostnamen, der zu keinem Zertifikat passt, wird das zuerst geladene
Zertifikat präsentiert. Beim Laden von Zertifikaten aus einem Verzeichnis wird daher dringend
empfohlen, das Standardzertifikat zuerst als Datei zu laden oder sicherzustellen, dass es stets
die erste Datei im Verzeichnis ist. Zur Auswahl mehrerer Standardzertifikate (1 rsa und 1 ecdsa)
gibt es 3 Möglichkeiten:
- Ein Zertifikatsbündel kann als erstes Zertifikat konfiguriert werden (`crt foobar.pem` in der
Konfiguration, wobei die vorhandenen Dateien `foobar.pem.ecdsa` und `foobar.pem.rsa` sind).
- Oder für jedes Zertifikat ein Filter '\*' in einer crt-list-Zeile.
- Das Schlüsselwort 'default-crt' kann verwendet werden.
Dasselbe Zertifikat kann ohne Nebenwirkungen mehrfach geladen werden.
Einige CAs (wie GoDaddy) bieten beim Bezug eines Zertifikats eine Auswahlliste von Servertypen an,
in der HAProxy fehlt. Wählen Sie in diesem Fall unbedingt einen Webserver, für den die CA ein
Zwischenzertifikat voraussetzt (bei GoDaddy liefert die Auswahl Apache Tomcat das richtige Bündel;
viele andere, z. B. NGINX, ergeben dagegen ein falsches Bündel, das bei manchen Clients nicht funktioniert).
HAProxy prüft für jede PEM-Datei, ob eine Datei unter demselben Pfad mit der angehängten Endung
".ocsp" vorhanden ist. Wird eine solche Datei gefunden, wird die Unterstützung für die TLS-Erweiterung
Certificate Status Request (auch als "OCSP stapling" bekannt) automatisch aktiviert. Der Inhalt dieser
Datei ist optional. Ist sie nicht leer, muss sie eine gültige OCSP-Antwort im DER-Format enthalten.
Eine gültige OCSP-Antwort muss folgende Regeln erfüllen: Sie muss den Status good anzeigen, eine
einzelne Antwort für das Zertifikat der PEM-Datei enthalten und zum Zeitpunkt des Hinzufügens gültig
sein. Werden diese Regeln nicht eingehalten, wird die OCSP-Antwort ignoriert und eine Warnung
ausgegeben. Um festzustellen, für welches Zertifikat eine OCSP-Antwort gilt, wird das Zertifikat des
Ausstellers benötigt. Wird dieses in der PEM-Datei nicht gefunden, wird es aus einer Datei mit dem
Pfad der PEM-Datei und der angehängten Endung ".issuer" geladen, sofern diese vorhanden ist.
Andernfalls schlägt der Vorgang mit einem Fehler fehl.
HAProxy prüft für jede PEM-Datei außerdem, ob eine Datei unter demselben Pfad mit der angehängten
Endung ".sctl" vorhanden ist. Wird eine solche Datei gefunden, wird die Unterstützung für die
TLS-Erweiterung Certificate Transparency (RFC6962) aktiviert. Die Datei muss eine gültige Signed
Certificate Timestamp List enthalten, wie im RFC beschrieben. Beim Einlesen wird die grundlegende
Syntax geprüft, jedoch werden keine Signaturen verifiziert.
In manchen Fällen ist es sinnvoll, in den für Clients angebotenen Cipher-Suites mehrere
Schlüsseltypen zu unterstützen, etwa RSA und ECDSA. So können Clients, die EC-Zertifikate
unterstützen, EC-Verschlüsselungsalgorithmen nutzen, während zugleich ältere Clients unterstützt
werden, die nur RSA beherrschen.
Dafür ist OpenSSL 1.1.1 erforderlich. Sie können dieses Verhalten konfigurieren, indem Sie für
jeden Zertifikatstyp einen crt-Eintrag angeben oder ein Zertifikatsbündel konfigurieren, wie es vor
HAProxy 1.8 erforderlich war. Siehe "ssl-load-extra-files".
`**
```haproxy
crt-ignore-err
```
Diese Einstellung ist nur verfügbar, wenn Unterstützung für OpenSSL einkompiliert wurde. Sie legt
eine durch Kommas getrennte Liste von Fehler-IDs fest, die bei der Überprüfung in der Tiefe == 0
ignoriert werden. Dies kann eine numerische ID oder der Konstantenname (X509_V_ERR) aus der
OpenSSL-Dokumentation sein:
Es wird
empfohlen, den Konstantennamen zu verwenden, da sich der numerische Wert in neuen OpenSSL-Versionen
ändern kann. Beim Wert 'all' werden alle Fehler ignoriert. Wird ein Fehler ignoriert, wird der
SSL-Handshake nicht abgebrochen.
`**
```haproxy
crt-list
```
Diese Einstellung ist nur verfügbar, wenn Unterstützung für OpenSSL einkompiliert wurde. Sie gibt
eine Liste von PEM-Dateien mit einer optionalen ssl-Konfiguration und einem SNI-Filter pro Zertifikat
an. Jede Zeile hat das folgende Format:
```text
[\[ ...\]] [[!] ...]
```
Leerzeilen und Zeilen, die mit einem Rautezeichen ('#') beginnen, werden ignoriert.
Die crt-list kann dynamisch über den Statistik-Socket bearbeitet werden. (Siehe "add ssl crt-list",
"del ssl crt-list" und "show ssl crt-list" im Verwaltungshandbuch.)
crt-list sind normalerweise eigene Dateien. Ein über die Direktive "crt" geladenes Verzeichnis
wird intern jedoch ebenfalls als crt-list dargestellt. Die Direktive "ssl-f-use" in einem Frontend
deklariert außerdem eine mit diesem Frontend verknüpfte crt-list.
crtfile:
```text
Dies ist der Dateiname des Zertifikats oder ein Bezeichner, wenn es
an anderer Stelle deklariert wurde (beispielsweise über die CLI oder
mit einem Alias in einem crt-store).
Dieselbe kann in mehreren Zeilen mit unterschiedlichen
Optionen und Filtern verwendet werden.
Zertifikatsbündel (siehe "ssl-load-extra-files") werden in einer
crt-list unterstützt, sofern in nur der Basisname angegeben
wird. HAProxy dupliziert die crt-list-Zeile intern und fügt beim Laden
der Datei eine Algorithmus-Erweiterung (.rsa, .ecdsa, .dsa) hinzu.
```
sslbindconf:
```text
unterstützt die folgenden Schlüsselwörter der bind-Zeile
(siehe Abschnitt 5.1. Bind-Optionen):
- 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
unterstützt außerdem die folgenden Schlüsselwörter von
load in crt-store (siehe Abschnitt 12.7.1. Ladeoptionen):
- crt
- key
- ocsp
- issuer
- sctl
- ocsp-update
Die Parameter der bind-Zeile werden in übernommen. Sind
keine angegeben, werden die Standardoptionen übernommen. Die in
angegebenen Parameter überschreiben diese übernommenen
Einstellungen.
```
snifilter:
```text
Wird der Parameter in einer crt-list-Zeile verwendet, werden
CN und SAN bei der Auswahl des Zertifikats dieser Zeile während des
Handshakes nicht mehr verwendet. Stattdessen wird verwendet.
ist eine durch Leerzeichen getrennte Liste von Einträgen.
Diese Liste kann Domains oder Platzhalter enthalten. Die Platzhalter
entsprechen dem DNS-Platzhalterformat mit einem einzelnen Sternchen
als erstem Zeichen des Eintrags. Eine Domain kann durch einen negativen
Filter von einem Platzhalter ausgeschlossen werden, indem der einzelnen
Domain ein '!' vorangestellt wird. Ein ! vor einem * wird ignoriert.
Negative Filter ohne Platzhalter in derselben Zeile werden ebenfalls
nicht unterstützt. Mit dem besonderen Eintrag '*' werden Standardzertifikate
angegeben, auf die zurückgegriffen wird, wenn keine Domain übereinstimmt.
Die Zertifikate werden Clients präsentiert, die ein gültiges TLS-Feld
Server Name Indication übermitteln, das mit einem der SNI-Filter oder
mit CN und SAN einer übereinstimmt. Der Abgleichalgorithmus
sucht zunächst nach einem positiven Domain-Eintrag in der Liste. Wird
keiner gefunden, sucht er nach einem Platzhalter. Stimmt ein Platzhalter
überein, prüft haproxy auf einen negativen Filter in derselben Zeile und
verwirft die Übereinstimmung gegebenenfalls. Bei mehreren Schlüsselalgorithmen
(RSA,ECDSA,DSA) versucht HAProxy, pro Typ ein passendes Zertifikat zu
finden, und wählt das passende anhand der Unterstützung des Clients aus.
Übermittelt der Client keine SNI oder passt kein Zertifikat, wird auf
eines der Standardzertifikate zurückgegriffen. Mit der Option 'strict-sni'
kann dieser Rückgriff auf ein Standardzertifikat deaktiviert werden.
Sind mehrere Standardzertifikate definiert, kann HAProxy abhängig von
der Unterstützung des Clients das passende ECDSA- oder RSA-Zertifikat wählen.
Das erste in einer bind-Zeile deklarierte Zertifikat wird als
Standardzertifikat verwendet, unabhängig davon, ob es über die Option
crt oder crt-list angegeben wurde.
Es kann auch ein Filter '*' deklariert werden, der dieses Zertifikat
zur Liste der Standardzertifikate hinzufügt. Für eine übersichtlichere
Konfiguration können Standardzertifikate explizit (mit einem Filter '*')
am Listenanfang stehen, sodass davor kein implizites Standardzertifikat
hinzugefügt wird.
Da Zertifikatsbündel in der crt-list für jeden Algorithmus dupliziert
werden, belegt nur ein Algorithmus die erste Zeile der crt-list und
wird als Standard betrachtet. Deklarieren Sie entweder '*' als Filter,
um das gesamte Bündel als Standard festzulegen, oder legen Sie es in
der bind-Zeile fest.
Der Befehl "show ssl sni" am Statistik-Socket kann zur Fehlersuche in
Ihrer Konfiguration verwendet werden. (Siehe "show ssl sni" im
Verwaltungshandbuch.)
```
Beispiel:
```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
```
`**
```haproxy
default-crt
```
Diese Option wirkt wie die Option "crt"; zusätzlich wird dieses Zertifikat jedoch als
Standardzertifikat verwendet. Es können mehrere Standardzertifikate hinzugefügt werden, um sowohl
ein ECDSA- als auch ein RSA-Zertifikat bereitzustellen. Weitere Zertifikate sind kaum sinnvoll.
Diese Option deaktiviert implizite Standardzertifikate nicht. Wird zuerst ein 'crt'-Zertifikat
vor allen 'default-crt'- oder weiteren 'crt'-Angaben deklariert, wird es weiterhin als
Standardzertifikat verwendet.
Ein Standardzertifikat wird verwendet, wenn in der bind-Zeile keine Option "strict-sni" angegeben
ist. Es wird bereitgestellt, wenn der Client die servername-Erweiterung nicht verwendet hat oder
wenn servername zu keinem konfigurierten Zertifikat passt.
Beispiel:
```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
```
Siehe auch das Schlüsselwort "crt".
`**
```haproxy
curves
```
Diese Einstellung ist nur verfügbar, wenn Unterstützung für OpenSSL einkompiliert wurde. Sie legt
die Zeichenfolge mit der Liste elliptischer Kurvenalgorithmen ("Kurvensuite") fest, die beim
SSL/TLS-Handshake mit ECDHE ausgehandelt werden. Die Zeichenfolge ist eine durch Doppelpunkte
getrennte Liste von Kurvennamen, beispielsweise "X25519:P-256" (ohne Anführungszeichen).
Ist "curves" gesetzt, wird der Parameter "ecdhe" ignoriert.
`**
```haproxy
ecdhe
```
Diese Einstellung ist nur verfügbar, wenn Unterstützung für OpenSSL einkompiliert wurde. Sie legt die benannte Kurve (RFC 4492) fest, die zum Generieren von ephemeren ECDH-Schlüsseln verwendet wird. Standardmäßig wird die benannte Kurve prime256v1 verwendet.
[ EXPERIMENTAL ]`**
```haproxy
ech [ EXPERIMENTAL ]
```
Wendet alle ECH-Schlüssel aus `` auf die bind-Zeile an. Die Dateien müssen die Erweiterung .ech haben und das PEM-Dateiformat für ECH verwenden. ( ), und HAProxy muss mit USE_ECH=1 kompiliert sein. Die ECH-API von AWS-LC wird nicht unterstützt.
Beispiel:
```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
```
`**
```haproxy
gid
```
Legt die Gruppe der Unix-Sockets auf die angegebene System-GID fest. Sie kann auch standardmäßig im globalen Abschnitt über die "unix-bind"-Anweisung gesetzt werden. Beachten Sie, dass einige Plattformen dies ignorieren. Diese Einstellung ist äquivalent zur "group"-Einstellung, unterscheidet sich jedoch dadurch, dass die Gruppen-ID anstelle des Namens verwendet wird. Diese Einstellung wird von nicht-Unix-Sockets ignoriert.
`**
```haproxy
group
```
Legt die Gruppe der Unix-Sockets auf die angegebene Systemgruppe fest. Sie kann auch standardmäßig im globalen Abschnitt über die "unix-bind"-Anweisung gesetzt werden. Beachten Sie, dass einige Plattformen dies ignorieren. Diese Einstellung ist äquivalent zur "gid"-Einstellung, unterscheidet sich jedoch dadurch, dass der Gruppenname anstelle der GID verwendet wird. Diese Einstellung wird von nicht-Unix-Sockets ignoriert.
`**
```haproxy
guid-prefix
```
Erzeugt für jeden dieser bind-Zeile zugewiesenen lauschenden Socket global eindeutige IDs, bei denen Groß- und Kleinschreibung unterschieden wird. Das Präfix wird mit dem Index der Listenerposition auf der aktuellen bind-Zeile verbunden, getrennt durch das Zeichen '-'. Weitere Informationen zum Format finden Sie in der Beschreibung des proxy-Schlüsselworts "guid". Siehe auch "shm-stats-file".
`**
```haproxy
id
```
Fixiert die Socket-ID. Standardmäßig werden Socket-IDs automatisch zugewiesen, aber manchmal ist es zweckmäßiger, sie festzulegen, um die Überwachung zu erleichtern. Der Wert muss strikt positiv und innerhalb des Listeners/Frontends eindeutig sein. Diese Option kann nur verwendet werden, wenn nur ein einzelner Socket definiert wird.
`**
```haproxy
idle-ping
```
Kann in folgenden Kontexten verwendet werden: tcp, http, log
Definiert ein Intervall für regelmäßige Erreichbarkeitsprüfungen bei inaktiven Frontend-Verbindungen. Wenn die Gegenstelle vor der nächsten geplanten Prüfung nicht antworten kann, wird die Verbindung geschlossen. Andernfalls wird der Timer für die Client-Zeitüberschreitung neu gestartet und die Verbindung bleibt bestehen. Beachten Sie, dass http-request/http-keep-alive-Timer parallel laufen und nicht durch idle-ping zurückgesetzt werden.
Diese Funktion beruht auf spezifischer Unterstützung durch das zugrundeliegende Protokoll. Derzeit implementiert nur der H2-Multiplexer diese Funktion. idle-ping wird von anderen Protokollen einfach ignoriert.
Diese Option ist besonders nützlich bei der Verwendung von Reverse-HTTP. Die Einstellung auf der bind-Zeile ist nützlich für den Peer, der für die aktive Herstellung von Verbindungen verantwortlich ist und dann eingehenden Datenverkehr über sie empfängt.
`**
```haproxy
interface
```
Beschränkt den Socket auf eine bestimmte Schnittstelle. Wenn angegeben, werden nur Pakete, die von dieser spezifischen Schnittstelle empfangen wurden, vom Socket verarbeitet. Dies wird derzeit nur unter Linux unterstützt. Die Schnittstelle muss eine primäre Systemschnittstelle sein, keine aliasierte Schnittstelle. Es ist auch möglich, mehrere Frontends an dieselbe Adresse zu binden, wenn sie an unterschiedliche Schnittstellen gebunden sind. Beachten Sie, dass die Bindung an eine Netzwerkschnittstelle root-Rechte erfordert. Dieser Parameter ist nur mit TCPv4/TCPv6-Sockets kompatibel. Wenn angegeben, verwendet der Rückverkehr dieselbe Schnittstelle wie der eingehende Verkehr und deren zugehörige Routing-Tabelle, selbst wenn explizite Routen über verschiedene Schnittstellen konfiguriert sind. Dies kann nützlich sein, um asymmetrische Routing-Probleme zu beheben, wenn dieselben Client-IP-Adressen auf Frontends auf unterschiedlichen Schnittstellen zugreifen müssen.
[ EXPERIMENTAL ]`**
```haproxy
ktls [ EXPERIMENTAL ]
```
Aktiviert oder deaktiviert kTLS für diese Sockets. Wenn aktiviert, wird kTLS verwendet, falls der Kernel dies unterstützt und der Verschlüsselungsalgorithmus kompatibel ist. Dies ist nur auf Linux-Kerneln ab 4.17 verfügbar. Bitte beachten Sie, dass einige Netztreiber und/oder TLS-Stacks die Verwendung von kTLS auf TLS v1.2 beschränken können. Siehe auch "force-tlsv12".
`**
```haproxy
label
```
Legt ein optionales Label für diese Sockets fest. Es kann verwendet werden, um Sockets nach Label zu gruppieren, unabhängig davon, wo die bind-Zeilen deklariert wurden.
`**
```haproxy
level
```
Diese Einstellung wird ausschließlich mit Statistik-Sockets verwendet, um die Art der Befehle zu beschränken, die auf dem Socket ausgeführt werden dürfen. Sie wird von anderen Sockets ignoriert. `` kann einer der folgenden Werte sein:
- "user" ist die geringste Berechtigungsstufe; nur nicht sensible Statistiken können gelesen werden, und keine Änderungen sind erlaubt. Dies ist auf Systemen sinnvoll, bei denen der Zugriff auf den Socket nicht einfach eingeschränkt werden kann.
- "operator" ist die Standardstufe und eignet sich für die meisten gängigen Anwendungsfälle. Alle Daten können gelesen werden, und nur nicht sensible Änderungen sind erlaubt (z. B. Zurücksetzen der Max-Zähler).
- "admin" sollte mit Vorsicht verwendet werden, da alles erlaubt ist (z. B. Zurücksetzen aller Zähler).
`**
```haproxy
maxconn
```
Beschränkt die Sockets auf diese Anzahl gleichzeitiger Verbindungen. Zusätzliche Verbindungen verbleiben im Backlog des Systems, bis eine Verbindung freigegeben wird. Wenn nicht angegeben, entspricht der Grenzwert dem Wert von maxconn des Frontends. Beachten Sie, dass bei Portbereichen oder mehreren Adressen der gleiche Wert für jeden Socket angewendet wird. Diese Einstellung ermöglicht unterschiedliche Beschränkungen für kostspielige Sockets, beispielsweise SSL-Einträge, die leicht den gesamten Speicher verbrauchen können.
`**
```haproxy
mode
```
Legt die oktale Berechtigungsstufe für den Unix-Socket fest. Sie kann auch standardmäßig in der globalen Abschnitt mittels der "unix-bind"-Anweisung gesetzt werden. Beachten Sie, dass einige Plattformen diese Einstellung einfach ignorieren. Diese Einstellung wird von nicht-Unix-Sockets ignoriert.
`**
```haproxy
mss
```
Legt den TCP-Maximum-Segment-Size (MSS)-Wert fest, der bei eingehenden Verbindungen angeboten wird. Dies kann verwendet werden, um eine niedrigere MSS für bestimmte Ports zu erzwingen, beispielsweise für Verbindungen, die durch ein VPN laufen. Beachten Sie, dass dies von einer Kernel-Funktion abhängt, die theoretisch unter Linux unterstützt wird, aber in allen Versionen vor 2.6.28 fehlerhaft war. Es kann auf anderen Betriebssystemen funktionieren oder nicht. Es kann auch vorkommen, dass sich der angebotene Wert nicht ändert, sondern nur die tatsächliche Größe ausgehender Segmente. Der üblicherweise angebotene Wert für TCPv4 über Ethernet-Netzwerke beträgt 1460 = 1500(MTU) - 40(IP+TCP). Wenn dieser Wert positiv ist, wird er als angebotene MSS verwendet. Wenn er negativ ist, gibt er an, um wie viel die angebotene MSS der eingehenden Verbindung für ausgehende Segmente reduziert werden soll. Dieser Parameter ist nur mit TCP v4/v6-Sockets kompatibel.
`**
```haproxy
name
```
Legt einen optionalen Namen für diese Sockets fest, der auf der Statistikseite angezeigt wird.
`**
```haproxy
namespace
```
Unter Linux ist es möglich, anzugeben, welchem Netzwerknamensraum ein Socket angehört. Diese Anweisung ermöglicht es, einen Listener explizit an einen anderen Namensraum als den Standardnamensraum zu binden. Weitere Informationen zu Netzwerknamensräumen finden Sie in der Dokumentation Ihres Betriebssystems.
[ EXPERIMENTAL ]`**
```haproxy
nbconn [ EXPERIMENTAL ]
```
Diese Einstellung ist nur für Listener-Instanzen gültig, die Reverse HTTP verwenden. Sie definiert die Anzahl der Verbindungen, die parallel aufgebaut werden. Wenn nicht angegeben, wird ein Standardwert von 1 verwendet.
Reverse HTTP ist derzeit noch in aktiver Entwicklung. Die Konfigurationsmechanismus kann sich zukünftig ändern. Aus diesem Grund ist sie intern als experimentell markiert, was bedeutet, dass "expose-experimental-directives" vor dieser Anweisung auf einer Zeile stehen muss.
`**
```haproxy
nice
```
Legt die 'niceness' der von diesem Socket initiierten Verbindungen fest. Der Wert muss im Bereich -1024..1024 inklusive liegen und hat standardmäßig den Wert null. Positive Werte bedeuten, dass solche Verbindungen anderen gegenüber freundlicher sind und leichter ihren Platz im Scheduler abgeben. Im Gegensatz dazu bedeuten negative Werte, dass Verbindungen eine höhere Priorität als andere haben möchten. Der Unterschied tritt nur unter hoher Last auf, wenn das System nahe an der Sättigung ist. Negative Werte sind für Low-Latency- oder Verwaltungsdienste geeignet, und hohe Werte werden allgemein für CPU-intensive Aufgaben wie SSL-Verarbeitung oder Massentransfers empfohlen, die weniger empfindlich gegenüber Latenz sind. Beispielsweise könnte es sinnvoll sein, einen positiven Wert für einen SMTP-Socket und einen negativen Wert für einen RDP-Socket zu verwenden.
`**
```haproxy
npn
```
Aktiviert die TLS-Erweiterung NPN und bietet die angegebene Protokollliste über NPN als unterstützt
an. Die Protokollliste besteht aus durch Kommas getrennten Protokollnamen, beispielsweise
"http/1.1,http/1.0" (ohne Anführungszeichen). Dafür muss die SSL-Bibliothek mit aktivierter
Unterstützung für TLS-Erweiterungen gebaut worden sein (mit haproxy -vv prüfen). Beachten Sie, dass
die NPN-Erweiterung durch die ALPN-Erweiterung ersetzt wurde (siehe das Schlüsselwort "alpn"), die
allerdings erst ab OpenSSL 1.0.2 verfügbar ist. Wird HTTP/2 mit einer älteren OpenSSL-Version
gewünscht, kann weiterhin NPN verwendet werden, da die meisten Clients es zum Zeitpunkt der
Erstellung dieses Textes noch unterstützen. NPN und ALPN lassen sich auch gemeinsam aktivieren,
was außerhalb von Tests jedoch vermutlich nicht sinnvoll ist.
`**
```haproxy
proto
```
Erzwingt das Multiplexer-Protokoll für eingehende Verbindungen. Es muss mit dem Modus des Frontends
(TCP oder HTTP) kompatibel sein. Außerdem muss es auf der Frontend-Seite verwendbar sein. Die Liste
verfügbarer Protokolle wird von haproxy -vv ausgegeben. Angezeigt werden die Protokolleigenschaften:
der Modus (TCP/HTTP), die Seite (FE/BE), der Name des Multiplexers und seine Flags.
Bei manchen Protokollen kann auf der Serverseite Head-of-Line-Blocking auftreten (flag=HOL_RISK).
Einige Protokolle unterstützen außerdem keine Upgrades (flag=NO_UPG). Auch die HTX-Kompatibilität
wird angegeben (flag=HTX).
Die folgenden Protokolle können als Argument einer "proto"-Direktive in einer bind-Zeile verwendet
werden:
```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
```
Mit dieser Option wird für alle von diesem lauschenden Socket erzeugten Verbindungen die Auswahl
des am besten geeigneten Multiplexer-Protokolls umgangen. Beispielsweise lässt sich http/2 über
unverschlüsseltem TCP erzwingen, indem in der bind-Zeile "proto h2" angegeben wird.
Wenn ALPN oder NPN konfiguriert ist, sollten die angegebenen Protokolle mit dem Multiplexer-Protokoll
kompatibel sein, um Probleme zu vermeiden. Ist beispielsweise "proto h1" gesetzt, sollte ALPN nicht
auf "h2" gesetzt werden.
QMux ist eine Teilmenge von QUIC, die über TCP läuft. Sie entspricht dem folgenden Protokollentwurf:
. In haproxy gilt sie derzeit als
experimentell.
)]`**
```haproxy
quic-cc-algo { cubic | newreno | bbr | nocc }[()]
```
Diese QUIC-spezifische Einstellung wählt den Algorithmus zur Überlastkontrolle für alle
Verbindungsversuche zu den konfigurierten QUIC-Listenern. Die Algorithmen ähneln denen von TCP.
Zusätzlich zum Algorithmus zur Überlastkontrolle ist Pacing aktiviert, um Paketverluste zu verringern
und den Durchsatz zu verbessern. Es kann mit dem globalen Schlüsselwort "tune.quic.fe.tx.pacing"
deaktiviert werden. In den meisten Fällen sollte Pacing aktiviert bleiben, insbesondere bei BBR,
da dessen ordnungsgemäße Funktion davon abhängt. BBR ohne Pacing kann bei Übertragungen zu
Verlangsamungen oder hohen Verlustraten führen.
Standardwert: cubic
Zur weiteren Anpassung kann nach dem Algorithmus eine Liste von Parametern angegeben werden.
Sie muss in Klammern und durch Kommas getrennt geschrieben werden. Jedes Argument ist optional
und kann bei Bedarf leer bleiben. Die Parameter müssen in folgender Reihenfolge stehen:
- maximale Fenstergröße in Bytes. Sie muss größer als 10k und kleiner als 4g sein. Standardmäßig
wird der Wert von "tune.quic.fe.cc.max-win-size" verwendet.
Beispiel:
```shell
# newreno congestion control algorithm
quic-cc-algo newreno
# cubic congestion control algorithm with one megabytes as window
quic-cc-algo cubic(1m)
```
Mit dem besonderen Wert "nocc" kann ein festes Überlastfenster erzwungen werden, das immer auf die
maximale Größe gesetzt ist. Dies ist für die Fehlersuche vorgesehen, um alle Nebeneffekte des
Algorithmus zur Überlastkontrolle auszuschließen. Es darf nicht in der Produktion verwendet werden,
da es schnell zu Netzwerkproblemen wie hohen Verlustraten führen kann.
.
`**
```haproxy
severity-output
```
Diese Einstellung wird nur bei Statistik-Sockets verwendet. Sie legt fest, wie der Schweregrad vor
informativen Rückmeldungen ausgegeben wird. Der Schweregrad einer Meldung kann gemäß Syslog rfc5424
zwischen 0 und 7 liegen. Bei gültigen, erfolgreich ausgeführten Socket-Befehlen zur Datenabfrage
(etwa "show map", "get acl foo" usw.) wird niemals ein Schweregrad vorangestellt. Bei anderen
Sockets wird die Einstellung ignoriert. `` kann einer der folgenden Werte sein:
- "none" (Standard): Rückmeldungen wird kein Schweregrad vorangestellt.
- "number": Der Schweregrad wird als Zahl vorangestellt.
- "string": Der Schweregrad wird als Zeichenfolge gemäß rfc5424 vorangestellt.
| by-thread | by-group }`**
```haproxy
shards { | by-thread | by-group }
```
Im Multithread-Modus erzeugt diese Einstellung auf Betriebssystemen, die mehrere Listener auf
derselben Kombination IP:port unterstützen, automatisch die angegebene Anzahl identischer
Listener für dieselbe Zeile. Jedem wird ein gleich großer Anteil der diesem Listener zugeordneten
Threads zugewiesen. Das kann bei sehr vielen Threads nützlich sein, wenn die Sperren im Kernel
für einen einzigen Socket erheblichen Zusatzaufwand verursachen. Eingehender Datenverkehr wird dann
auf mehrere Sockets verteilt, wodurch die Konkurrenz um gemeinsame Ressourcen abnimmt. Beachten Sie,
dass dies leicht die CPU-Auslastung erhöhen kann, weil mehr Threads jeweils etwas Arbeit leisten.
Ist die Anzahl der Shards größer als die Anzahl verfügbarer Threads, wird sie automatisch auf die
Anzahl der Threads begrenzt (also ein Shard pro Thread). Auch der besondere Wert "by-thread" erzeugt
so viele Shards, wie der "bind"-Zeile Threads zugeordnet sind. Da das System den eingehenden
Datenverkehr gleichmäßig auf diese Shards verteilt, ist es wichtig, dass deren Anzahl ein
ganzzahliger Teiler der Thread-Anzahl ist. Alternativ erzeugt der besondere Wert "by-group" einen Shard pro Thread-Gruppe.
Das kann bei vielen Threads nützlich sein, wenn nicht zu viele Sockets erzeugt werden sollen.
Die Lastverteilung ist dann etwas weniger optimal, aber die Konkurrenz um gemeinsame Ressourcen
(insbesondere im System) ist weiterhin geringer als bei einem einzigen Socket.
Auf Betriebssystemen, die nicht mehrere an dieselbe Adresse gebundene Sockets unterstützen, fallen
"by-thread" und "by-group" automatisch auf einen einzigen Shard zurück. Bei "by-group" geschieht
dies ohne Warnung, da es für eine einzelne Gruppe nichts ändert und die Sockets ohnehin für jede
Gruppe dupliziert werden. Bei "by-thread" wird in diesem Fall jedoch eine Diagnosewarnung
ausgegeben, da die resultierende Anzahl von Listenern nicht der erwarteten Anzahl entspricht.
`**
```haproxy
sigalgs
```
Diese Einstellung ist nur verfügbar, wenn Unterstützung für OpenSSL einkompiliert wurde. Sie legt
die Zeichenfolge mit der Liste der Signaturalgorithmen fest, die beim TLSv1.2- und TLSv1.3-Handshake
ausgehandelt werden. Das Format der Zeichenfolge ist in "man 3 SSL_CTX_set1_sigalgs" in den
OpenSSL-Handbuchseiten beschrieben. Von dieser Einstellung wird abgeraten, sofern keine
Kompatibilität mit einer Middlebox erforderlich ist.
` oder einer niedrigeren Version. Diese Einstellung ohne "ssl-min-ver" zu verwenden, kann
mehrdeutig sein, da sich der Standardwert von ssl-min-ver in zukünftigen HAProxy-Versionen ändern
könnte. Diese Option ist auch in der globalen Anweisung "ssl-default-bind-options" verfügbar.
Siehe auch "ssl-min-ver".
` oder einer höheren Version. Der Standardwert ist "TLSv1.2". Diese Option ist auch in der
globalen Anweisung "ssl-default-bind-options" verfügbar. Siehe auch "ssl-max-ver".
`**
```haproxy
tcp-md5sig
```
Aktiviert die TCP-MD5-Signatur (RFC 2385 Schutz von BGP-Sitzungen mithilfe der TCP-MD5-Signaturoption)
für alle eingehenden Verbindungen, die von diesem lauschenden Socket erzeugt werden. Diese Option
ist nur unter Linux verfügbar. Wenn sie aktiviert ist, wird die Zeichenfolge `` verwendet,
um jedes TCP-Segment mit einem 16-Byte-MD5-Digest zu signieren. Dies schützt die TCP-Verbindung vor
Spoofing. Der wichtigste Anwendungsfall ist der Schutz von BGP gegen das Einschleusen gefälschter
TCP-Segmente in den Verbindungsstrom. Die Option kann aber für alle sehr langlebigen
TCP-Verbindungen nützlich sein.
`**
```haproxy
tcp-ss
```
Setzt die Option TCP Save SYN für alle eingehenden Verbindungen, die von diesem lauschenden Socket
erzeugt werden. Diese Option ist unter Linux seit Version 4.3 verfügbar. Sie weist den Kernel an,
eine Kopie des eingehenden IP-Pakets mit dem TCP-SYN-Flag nach Möglichkeit aufzubewahren, damit es
später mit der Sample-Abruffunktion "fc_saved_syn" untersucht werden kann. Die Option kennt 3 Modi: - 0 Das Speichern von SYN-Paketen ist deaktiviert; dies ist der Standard - 1 Das Speichern von
SYN-Paketen ist aktiviert und umfasst IP- und TCP-Header - 2 Das Speichern von SYN-Paketen ist
aktiviert und umfasst ETH-, IP- und TCP-Header
Dies funktioniert nur bei regulären TCP-Verbindungen und wird bei anderen Protokollen (z. B.
UNIX-Sockets) ignoriert. Siehe auch "fc_saved_syn".
`**
```haproxy
tcp-ut
```
Setzt den TCP User Timeout für alle eingehenden Verbindungen, die von diesem lauschenden Socket
erzeugt werden. Diese Option ist unter Linux seit Version 2.6.37 verfügbar. Damit kann HAProxy eine
Zeitüberschreitung für Sockets konfigurieren, deren Daten innerhalb der angegebenen Zeit keine
Bestätigung erhalten. Dies ist besonders für langlebige Verbindungen mit langen Leerlaufzeiten
nützlich, etwa Remote-Terminals oder Datenbank-Verbindungspools. Dort müssen die
Zeitüberschreitungen für Client und Server hoch bleiben, um lange Leerlaufzeiten zu ermöglichen;
zugleich ist es wichtig, das Verschwinden eines Clients zu erkennen, um alle Ressourcen seiner Verbindung
(und der Serversitzung) freizugeben. Das Argument ist eine Zeitspanne, standardmäßig in Millisekunden.
Dies funktioniert nur bei regulären TCP-Verbindungen und wird bei anderen Protokollen ignoriert.
/][,...]`**
```haproxy
thread [/][,...]
```
Beschränkt die Liste der Threads, auf denen dieser Listener ausgeführt werden darf. Dabei wird
keiner dieser Threads erzwungen; lediglich nicht passende Threads werden ausgeschlossen. Die
Einstellung begrenzt die Threads, die eingehende Verbindungen dieses Listeners verarbeiten dürfen.
Es gibt zwei Nummerierungsschemata. Standardmäßig sind Thread-Nummern innerhalb des Prozesses
absolut und liegen zwischen 1 und dem in global.nbthread angegebenen Wert. Ein Thread kann auch
über seine relative Nummer innerhalb seiner Thread-Gruppe bezeichnet werden. Dazu wird zuerst die
Nummer der Thread-Gruppe angegeben, gefolgt von einem Schrägstrich ('/') und den relativen
Thread-Nummern. In diesem Fall beginnen die Thread-Nummern ebenfalls bei 1 und enden je nach
Plattform bei 32 oder 64. Absolute Thread-Nummern werden automatisch in relative Nummern umgewandelt,
sobald die Thread-Gruppen bekannt sind. Üblicherweise werden absolute Nummern für einfache
Konfigurationen bevorzugt und relative Nummern für komplexe Konfigurationen, bei denen die
CPU-Anordnung für die Leistung entscheidend ist.
Nach der optionalen Thread-Gruppennummer muss die "thread-set"-Angabe folgendes Format verwenden:
```text
"all" | "odd" | "even" | [number][-[number]]
```
Wie die Namen nahelegen, wählt "all" alle Threads der Menge aus (entweder alle Threads der Gruppe,
wenn eine Gruppe angegeben ist, oder alle Threads des Prozesses). "odd" wählt alle ungeradzahligen
Threads aus (jeden zweiten Thread, beginnend bei 1), entweder im Prozess oder in der Gruppe;
"even" wählt alle geradzahligen Threads aus (jeden zweiten Thread, beginnend bei 2). Werden
stattdessen Bereiche von Thread-Nummern verwendet, werden alle Threads von der ersten bis zur
letzten Thread-Nummer des Bereichs ausgewählt. Je nachdem, ob eine Thread-Gruppennummer angegeben
ist, sind die Nummern relativ zur Gruppe oder absolut. Fehlt die erste Thread-Nummer, wird "1"
verwendet, also der erste Thread der Gruppe oder des Prozesses. Fehlt die letzte Thread-Nummer,
wird entweder die letzte Thread-Nummer der Gruppe (32 oder 64) oder die letzte Thread-Nummer des
Prozesses (global.nbthread) verwendet.
Diese Bereiche können, durch Kommas getrennt, mehrfach angegeben werden, um nicht zusammenhängende
Thread-Mengen zu definieren. Eine gegebenenfalls verwendete Gruppe muss für jeden neuen Bereich
erneut angegeben werden. Beachten Sie, dass gruppenrelative und absolute Angaben nicht gemischt
werden dürfen: Die gesamte "bind"-Zeile muss entweder absolute oder relative Notation verwenden,
da nicht gesetzte Werte erst am Ende des Parsens aufgelöst werden.
Dabei ist wichtig, dass jeder durch eine "bind"-Zeile beschriebene Listener mindestens einen Socket
erzeugt, der durch mindestens einen Dateideskriptor repräsentiert wird. Da Dateideskriptoren sich
nicht über mehrere Thread-Gruppen erstrecken können, werden automatisch mehrere Dateideskriptoren
erzeugt, wenn der Thread-Bereich einer "bind"-Zeile mehr als eine Gruppe umfasst. So ist für jede
Gruppe mindestens einer vorhanden. Technisch verweisen sie alle auf denselben Socket im Kernel,
erhalten in haproxy aber jeweils eine eigene Kennung und bei Verwendung von "option socket-stats"
sogar einen eigenen Statistikeintrag.
Der Hauptzweck besteht darin, mehrere bind-Zeilen in einem Listener mit derselben Kombination
IP:port, aber verschiedenen Threads zu verwenden. Das System kann eingehende Verbindungen dann auf
mehrere Warteschlangen verteilen und damit die interne Lastverteilung der Warteschlangen von haproxy
umgehen. Derzeit ist bekannt, dass Linux ab 3.9 dies unterstützt. Siehe auch das oben beschriebene
Schlüsselwort "shards", das die Duplizierung von "bind"-Zeilen und ihre Zuweisung zu mehreren
Thread-Gruppen automatisiert.
Dieses Schlüsselwort ist mit Reverse-HTTP-bind-Zeilen kompatibel. Für einen solchen Listener darf
jedoch keine Thread-Menge angegeben werden, die mehrere Thread-Gruppen umfasst, da "nbconn" sonst
möglicherweise nicht wie vorgesehen funktioniert.
`**
```haproxy
tls-ticket-keys
```
Legt die Datei fest, aus der die TLS-Ticket-Schlüssel geladen werden. Die Schlüssel müssen je nach
Verwendung von aes128 oder aes256 48 oder 80 Bytes lang und base64-codiert sein, mit einer Zeile
pro Schlüssel (z. B. openssl rand
80 \| openssl base64 -A \| xargs echo). Der erste Schlüssel bestimmt die Schlüssellänge der folgenden
Schlüssel; aes128- und aes256-Schlüssel können nicht gemischt werden. Die Anzahl der Schlüssel wird
mit der Build-Option TLS_TICKETS_NO festgelegt (Standard 3), und die Datei muss mindestens so viele
Schlüssel enthalten. Die letzten TLS_TICKETS_NO Schlüssel werden zur Entschlüsselung verwendet,
der vorletzte zur Verschlüsselung. Das ermöglicht einen einfachen Schlüsselwechsel: Ein neuer
Schlüssel wird an die Datei angehängt und der Prozess neu geladen. Die Schlüssel müssen regelmäßig
gewechselt werden (z. B. alle 12h), sonst ist Perfect Forward Secrecy gefährdet. Es empfiehlt sich
auch, die Schlüssel nicht auf dauerhaftem Speicher wie Festplatten abzulegen (Tipp: tmpfs verwenden
und diese Dateien nicht auslagern). Der Hinweis auf die Lebensdauer kann mit tune.ssl.timeout
geändert werden.
`**
```haproxy
uid
```
Setzt den Eigentümer der UNIX-Sockets auf die angegebene System-UID. Der Standardwert kann auch mit
der Anweisung "unix-bind" im globalen Abschnitt gesetzt werden. Beachten Sie, dass manche Plattformen
dies einfach ignorieren. Diese Einstellung entspricht "user", verwendet aber die numerische ID des
Benutzers anstelle seines Namens. Bei anderen als UNIX-Sockets wird sie ignoriert.
`**
```haproxy
user
```
Setzt den Eigentümer der UNIX-Sockets auf den angegebenen Systembenutzer. Der Standardwert kann auch
mit der Anweisung "unix-bind" im globalen Abschnitt gesetzt werden. Beachten Sie, dass manche
Plattformen dies einfach ignorieren. Diese Einstellung entspricht "uid", verwendet aber den
Benutzernamen anstelle seiner uid. Bei anderen als UNIX-Sockets wird sie ignoriert.
[:port] [settings ...]
default-server [settings ...]
```
Beachten Sie, dass alle diese Einstellungen sowohl von "server" als auch von "default-server"
unterstützt werden, außer "id", das nur von "server" unterstützt wird.
Derzeit werden die folgenden Einstellungen unterstützt.
`**
```haproxy
addr
```
Kann in folgenden Kontexten verwendet werden: tcp, http, log
Mit dem Parameter "addr" kann eine andere IP-Adresse zum Senden von Health Checks oder zum
Abfragen des Agent-Checks verwendet werden. Auf manchen Servern kann es sinnvoll sein, einer
bestimmten Komponente eine eigene IP-Adresse zuzuweisen, wenn diese komplexe Tests ausführen kann,
die für Health Checks besser geeignet sind als die Anwendung selbst. Dieser Parameter wird
ignoriert, wenn "check" nicht gesetzt ist. Siehe auch den Parameter "port".
`**
```haproxy
agent-send
```
Kann in folgenden Kontexten verwendet werden: tcp, http, log
Wenn diese Option angegeben ist, sendet HAProxy beim Verbindungsaufbau die angegebene Zeichenfolge
unverändert an den Agent-Server. Sie könnten darin beispielsweise den Backend-Namen codieren,
damit der Agent je nach Backend unterschiedliche Antworten senden kann. Fügen Sie ein '\n'
ein, wenn die Anfrage mit einem Zeilenumbruch enden soll.
`**
```haproxy
agent-inter
```
Kann in folgenden Kontexten verwendet werden: tcp, http, log
Der Parameter "agent-inter" setzt das Intervall zwischen zwei Agent-Checks auf ``
Millisekunden. Ist er nicht angegeben, beträgt das Intervall standardmäßig 2000 ms.
Wie bei allen zeitbasierten Parametern kann explizit eine andere Einheit aus { us, ms, s, m, h, d }
angegeben werden. Der Parameter "agent-inter" dient auch als Zeitüberschreitung für Agent-Checks,
wenn "timeout
check" nicht gesetzt ist. Um "Resonanz"-Effekte bei mehreren Servern auf derselben Hardware zu
verringern, werden die Agent- und Health Checks aller Server mit einem kleinen zeitlichen Versatz
zueinander gestartet. Mit dem globalen Schlüsselwort "spread-checks" kann den Intervallen der
Agent- und Health Checks außerdem eine zufällige Abweichung hinzugefügt werden. Das ist
beispielsweise sinnvoll, wenn viele Backends dieselben Server verwenden.
Siehe auch die Parameter "agent-check" und "agent-port".
`**
```haproxy
agent-addr
```
Kann in folgenden Kontexten verwendet werden: tcp, http, log
Der Parameter "agent-addr" legt die Adresse für den Agent-Check fest.
Sie können den Agent-Check auf ein anderes Ziel auslagern und so Status und Gewichte der in HAProxy
definierten Server zentral verwalten, falls sich die Dienste nicht selbst überwachen und verwalten
können. Es kann sowohl eine IP-Adresse als auch ein Hostname angegeben werden; dieser wird aufgelöst.
`**
```haproxy
agent-port
```
Kann in folgenden Kontexten verwendet werden: tcp, http, log
Der Parameter "agent-port" legt den TCP-Port für Agent-Checks fest.
Siehe auch die Parameter "agent-check" und "agent-inter".
`**
```haproxy
alpn
```
Kann in folgenden Kontexten verwendet werden: tcp, http
Aktiviert die TLS-Erweiterung ALPN und bietet die angegebene Protokollliste über ALPN als unterstützt
an. Die Protokollliste besteht aus durch Kommas getrennten Protokollnamen, beispielsweise
"http/1.1,http/1.0" (ohne Anführungszeichen). Dafür muss die SSL-Bibliothek mit aktivierter
Unterstützung für TLS-Erweiterungen gebaut worden sein (mit haproxy -vv prüfen). Die ALPN-Erweiterung
ersetzt die ursprüngliche NPN-Erweiterung. ALPN ist für Verbindungen zu HTTP/2-Servern erforderlich.
Sie ist auch erforderlich, um HTTP/3 über einen QUIC-Server verwenden zu können; für QUIC-Server
ohne "alpn"-Einstellung ist "h3" der Standardwert. OpenSSL-Versionen vor 1.0.2 unterstützten ALPN
nicht, sondern nur die inzwischen veraltete NPN-Erweiterung. Wenn sowohl HTTP/2 als auch HTTP/1.1
unterstützt werden sollen, können beide Versionen in der gewünschten Präferenzreihenfolge angeboten
werden, wie unten gezeigt:
```text
server 127.0.0.1:443 ssl crt pub.pem alpn h2,http/1.1
```
Siehe auch "ws", um eine alternative ALPN-Angabe für Websocket-Streams zu verwenden.
`**
```haproxy
ca-file
```
Kann in folgenden Kontexten verwendet werden: tcp, http, log, peers, ring
Diese Einstellung ist nur verfügbar, wenn Unterstützung für OpenSSL einkompiliert wurde. Sie gibt
eine PEM-Datei an, aus der CA-Zertifikate zur Überprüfung des Serverzertifikats geladen werden.
Es kann auch ein Verzeichnis mit mehreren CAs geladen werden. In diesem Fall versucht HAProxy,
alle Dateien mit den Endungen ".pem", ".crt", ".cer" und ".crl" aus dem Verzeichnis zu laden.
Dateien, deren Name mit einem Punkt beginnt, werden ignoriert.
Um die vertrauenswürdigen CAs des Systems zu verwenden, kann anstelle der cafile der Parameter
"@system-ca" angegeben werden. Der Pfad dieses Verzeichnisses kann durch Setzen der
Umgebungsvariablen SSL_CERT_DIR überschrieben werden.
`**
```haproxy
cc
```
Kann in folgenden Kontexten verwendet werden: tcp, http, log, peers, ring
Diese Einstellung ist nur auf Systemen verfügbar, die TCP_CONGESTION definieren, und wurde unter
Linux und FreeBSD geprüft. Sie nimmt den Namen eines TCP-Algorithmus zur Überlastkontrolle entgegen
und konfiguriert ausgehende Verbindungen für dessen Verwendung. Typische Namen sind "reno" und
"cubic"; die Auswahl hängt vom Betriebssystem ab. Auf manchen Systemen können für bestimmte
Algorithmen besondere Berechtigungen erforderlich sein. Unter Linux listet die Sysctl-Einstellung
"net.ipv4.tcp_available_congestion_control" die verfügbaren Algorithmen auf und
"net.ipv4.tcp_allowed_congestion_control" die ohne Privilegien zulässigen Algorithmen. Für
Algorithmen mit zusätzlichen Berechtigungsanforderungen kann die Capability "cap_net_admin"
erforderlich sein (siehe "setcap" im globalen Abschnitt). Kann ein bestimmter Algorithmus nicht
konfiguriert werden, bleibt der Standardalgorithmus unverändert. Siehe auch das bind-Schlüsselwort
"cc" ([Abschnitt 5.1](/de/docs/haproxy/bind-and-server-options/#section-5-1)).
`**
```haproxy
check-alpn
```
Kann in folgenden Kontexten verwendet werden: tcp, http
Legt fest, welche Protokolle über ALPN angeboten werden. Die Protokollliste besteht aus durch
Kommas getrennten Protokollnamen, beispielsweise "http/1.1,http/1.0" (ohne Anführungszeichen).
Ist dies nicht gesetzt, wird die ALPN-Einstellung des Servers verwendet.
`**
```haproxy
check-pool-conn-name
```
Kann in folgenden Kontexten verwendet werden: tcp, http
Wenn für Prüfungen Verbindungen wiederverwendet werden, wird ``, sofern gesetzt, als
Verbindungskennung verwendet, um eine passende Verbindung im Pool zu finden. Dies entspricht dem
Server-Schlüsselwort "pool-conn-name". Wird diese Option nicht verwendet, dient auch "check-sni"
als Rückfallwert.
Siehe auch: "check-reuse-pool"
`**
```haproxy
check-proto
```
Kann in folgenden Kontexten verwendet werden: tcp, http
Erzwingt das Multiplexer-Protokoll für die Health-Check-Verbindungen des Servers. Es muss mit dem
Health-Check-Typ (TCP oder HTTP) kompatibel und auf der Backend-Seite verwendbar sein. Die Liste
verfügbarer Protokolle wird von haproxy -vv ausgegeben. Angezeigt werden die Protokolleigenschaften:
der Modus (TCP/HTTP), die Seite (FE/BE), der Name des Multiplexers und seine Flags.
Bei manchen Protokollen kann auf der Serverseite Head-of-Line-Blocking auftreten (flag=HOL_RISK).
Einige Protokolle unterstützen außerdem keine Upgrades (flag=NO_UPG). Auch die HTX-Kompatibilität
wird angegeben (flag=HTX).
Die folgenden Protokolle können als Argument einer "check-proto"-Direktive in einer server-Zeile
verwendet werden:
```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
```
Mit dieser Option wird die Auswahl des am besten geeigneten Multiplexer-Protokolls für
Health-Check-Verbindungen zu diesem Server umgangen. Ist sie nicht definiert, wird das Protokoll
des Servers verwendet, sofern es gesetzt ist.
Wenn ALPN oder NPN konfiguriert ist, sollten die angegebenen Protokolle mit dem Multiplexer-Protokoll
kompatibel sein, um Probleme zu vermeiden. Ist beispielsweise "proto h1" gesetzt, sollte ALPN nicht
auf "h2" gesetzt werden.
Die Konfiguration von QUIC-Prüfungen ist noch nicht vollständig implementiert. Erstens können
QUIC-Prüfungen nur für QUIC-Server durchgeführt werden. Zweitens fällt das Prüfprotokoll auf TCP
zurück, wenn für einen QUIC-Server mindestens ein prüfungsspezifischer Verbindungsparameter
angegeben ist.
`**
```haproxy
check-sni
```
Kann in folgenden Kontexten verwendet werden: tcp, http, log
Mit dieser Option wird die SNI für Health Checks über SSL angegeben. `` kann nur mit einer
Zeichenfolge gesetzt werden. Soll die SNI für weitergeleiteten Datenverkehr gesetzt werden, siehe
"sni".
`**
```haproxy
ciphers
```
Kann in folgenden Kontexten verwendet werden: tcp, http, log, peers, ring
Diese Einstellung ist nur verfügbar, wenn Unterstützung für OpenSSL einkompiliert wurde. Sie legt
die Zeichenfolge mit der Liste der Verschlüsselungsalgorithmen fest, die beim SSL/TLS-Handshake mit
dem Server ausgehandelt werden. Das Format ist in "man 1 ciphers" in den OpenSSL-Handbuchseiten
beschrieben. Hintergrundinformationen und Empfehlungen finden Sie beispielsweise unter
() und
(`**
```haproxy
ciphersuites
```
Kann in folgenden Kontexten verwendet werden: tcp, http, log, peers, ring
Diese Einstellung ist nur verfügbar, wenn Unterstützung für OpenSSL einkompiliert wurde und
HAProxy mit OpenSSL 1.1.1 oder neuer gebaut wurde. Sie legt die Zeichenfolge mit der Liste der
Verschlüsselungsalgorithmen fest, die beim TLS-1.3-Handshake mit dem Server ausgehandelt werden.
Das Format ist in "man
1 ciphers" in den OpenSSL-Handbuchseiten im Abschnitt "ciphersuites" beschrieben. Zur Konfiguration
der Verschlüsselungsalgorithmen für TLSv1.2 und älter siehe das Schlüsselwort "ciphers".
`**
```haproxy
client-sigalgs
```
Kann in folgenden Kontexten verwendet werden: tcp, http, log, peers, ring
Diese Einstellung ist nur verfügbar, wenn Unterstützung für OpenSSL einkompiliert wurde. Sie legt
die Zeichenfolge mit der Liste der auszuhandelnden Signaturalgorithmen für die Client-Authentifizierung
fest. Das Format ist in "man 3 SSL_CTX_set1_client_sigalgs" in den OpenSSL-Handbuchseiten beschrieben.
Von dieser Einstellung wird abgeraten, sofern kein konkreter Anwendungsfall dafür besteht.
`**
```haproxy
cookie
```
Kann in folgenden Kontexten verwendet werden: http
Der Parameter "cookie" setzt den dem Server zugeordneten Cookie-Wert auf ``. Dieser Wert
wird in eingehenden Anfragen geprüft; ausgewählt wird der erste betriebsbereite Server mit demselben
Wert. Im Gegenzug wird dieser Wert im Modus zum Einfügen oder Umschreiben von Cookies dem Cookie
zugewiesen, das an den Client gesendet wird. Mehrere Server können problemlos denselben Cookie-Wert
verwenden; bei normalen und Backup-Servern ist dies sogar recht üblich. Siehe auch das Schlüsselwort
"cookie" im Backend-Abschnitt.
`**
```haproxy
crl-file
```
Kann in folgenden Kontexten verwendet werden: tcp, http, log, peers, ring
Diese Einstellung ist nur verfügbar, wenn Unterstützung für OpenSSL einkompiliert wurde. Sie gibt
eine PEM-Datei an, aus der die Zertifikatssperrliste zur Überprüfung des Serverzertifikats geladen
wird.
`**
```haproxy
crt
```
Kann in folgenden Kontexten verwendet werden: tcp, http, log, peers, ring
Diese Einstellung ist nur verfügbar, wenn Unterstützung für OpenSSL einkompiliert wurde. Sie gibt
eine PEM-Datei an, aus der sowohl ein Zertifikat als auch der zugehörige private Schlüssel geladen
werden. Die Datei kann durch Aneinanderhängen beider PEM-Dateien erzeugt werden. Dieses Zertifikat
wird gesendet, wenn der Server ein Client-Zertifikat anfordert.
Enthält die Datei keinen privaten Schlüssel, versucht HAProxy, den Schlüssel vom selben Pfad mit
der angehängten Endung ".key" zu laden (sofern "ssl-load-extra-files" entsprechend gesetzt ist).
`**
```haproxy
curves
```
Kann in folgenden Kontexten verwendet werden: tcp, http, log, peers, ring
Diese Einstellung ist nur verfügbar, wenn Unterstützung für OpenSSL einkompiliert wurde. Sie legt die Zeichenfolge fest, die die Liste der elliptischen Kurvenalgorithmen ("Kurvensuite") beschreibt, die während des SSL/TLS-Handshakes mit ECDHE vereinbart werden. Das Format der Zeichenfolge ist eine durch Doppelpunkte getrennte Liste von Kurvennamen. Beispiel: "X25519:P-256" (ohne Anführungszeichen)
`**
```haproxy
error-limit
```
Kann in folgenden Kontexten verwendet werden: tcp, http, log
Wenn die Zustandsüberwachung aktiviert ist, legt der "error-limit"-Parameter die Anzahl aufeinanderfolgender Fehler fest, die ein Ereignis auslösen, das durch die "on-error"-Option ausgewählt wurde. Standardmäßig ist dieser Wert auf 10 aufeinanderfolgende Fehler festgelegt.
Siehe auch "check", "error-limit" und "on-error".
`**
```haproxy
fall
```
Kann in folgenden Kontexten verwendet werden: tcp, http, log
Der "fall"-Parameter legt fest, dass ein Server nach `` aufeinanderfolgenden fehlgeschlagenen Health Checks als ausgefallen gilt. Ohne Angabe beträgt dieser Wert standardmäßig 3. Siehe auch die Parameter "check", "inter" und "rise".
`**
```haproxy
guid
```
Kann in folgenden Kontexten verwendet werden: tcp, http, log
Geben Sie eine global eindeutige ID, bei der Groß- und Kleinschreibung unterschieden wird, für diesen Server an. Diese ID muss innerhalb der gesamten haproxy-Konfiguration über alle Objekttypen hinweg eindeutig sein. Weitere Informationen zum Format finden Sie in der Beschreibung des Proxy-Schlüsselworts "guid". Siehe auch "shm-stats-file".
`**
```haproxy
hash-key
```
Kann in folgenden Kontexten verwendet werden: tcp, http, log
Geben Sie an, wie "hash-type consistent"-Knotenschlüssel berechnet werden.
Argumente:
```text
kann einen der folgenden Werte haben:
id Die Knotenschlüssel werden aus dem numerischen Bezeichner
des Servers abgeleitet, der mit "id" festgelegt wird oder
standardmäßig seiner Position in der Serverliste entspricht.
Dies ist die Standardeinstellung. Es werden nur die 20
niedrigsten Bits der ID verwendet (also (id % 1048576)).
Um Überschneidungen zu vermeiden, sollten daher nur Werte
zwischen 1 und diesem Wert verwendet werden.
id32 Die Knotenschlüssel werden aus dem numerischen Bezeichner
des Servers abgeleitet, der mit "id" festgelegt wird oder
standardmäßig seiner Position in der Serverliste entspricht.
Hier werden jedoch alle 32 Bits der ID verwendet, sodass
keine Kollision entsteht. Dieser Wert wird nicht wie "id"
skaliert. Daher empfiehlt es sich, ihn stets entweder mit
einer Hashfunktion (siehe "hash-key") oder mit explizit
zugewiesenen ID-Werten zu verwenden, die gleichmäßig über
den 32-Bit-Raum verteilt sind.
guid Die Knotenschlüssel werden aus der guid des Servers
abgeleitet, sofern vorhanden; andernfalls wird auf "id"
zurückgegriffen. Der Vorteil ist, dass dies überhaupt nicht
von der Reihenfolge abhängt, sondern nur von einem internen,
stabilen Bezeichner, der auf vielen Load-Balancern
repliziert werden kann.
addr Die Knotenschlüssel werden aus der Adresse des Servers
abgeleitet, sofern vorhanden; andernfalls wird auf "id"
zurückgegriffen.
addr-port Die Knotenschlüssel werden aus Adresse und Port des Servers
abgeleitet, sofern vorhanden; andernfalls wird auf "id"
zurückgegriffen.
```
Die Optionen "addr" und "addr-port" können in Szenarien nützlich sein, in denen mehrere HAProxy-Prozesse den Datenverkehr an die gleiche Gruppe von Servern verteilen. Wenn die Serverreihenfolge jedes Prozesses unterschiedlich ist (z. B. weil DNS-Einträge in unterschiedlicher Reihenfolge aufgelöst wurden), ermöglicht dies jedem unabhängigen HAProxy-Prozess, sich auf Routing-Entscheidungen zu einigen. Hinweis: "balance random" verwendet ebenfalls "hash-type consistent", und die Qualität der Verteilung hängt von der Qualität der Schlüssel ab.
`**
```haproxy
healthcheck
```
Kann in folgenden Kontexten verwendet werden: tcp, http
Geben Sie den Health-Check-Abschnitt an, der zum Durchführen des Checks auf dem Server verwendet werden soll.
Argument:
```text
ist der Name des health-check-Abschnitts.
```
Dank dieser Option ist es möglich, eine serverspezifische Health-Check-Konfiguration anstelle der Proxy-Konfiguration zu verwenden. Siehe auch "healthcheck section".
`**
```haproxy
id
```
Kann in folgenden Kontexten verwendet werden: tcp, http, log
Legen Sie eine persistente ID für den Server fest. Diese ID muss eine positive Zahl mit 32 Bit sein und innerhalb des Proxys eindeutig sein. Wenn nicht gesetzt, wird automatisch eine nicht verwendete ID zugewiesen. Der erste zugewiesene Wert ist 1. Diese ID wird derzeit nur in der Statistik zurückgegeben und wird verwendet, um bei konsistenten Hash-Algorithmen LB-Knoten zu platzieren, wenn "hash-key" auf "id" (Standard) gesetzt ist. In diesem Fall werden nur die 20 niedrigsten Bits des Werts verwendet (d. h. (id % 1048576)), sodass es besser ist, Werte im Bereich zwischen 1 und diesem Wert zu verwenden, um Überlappungen zu vermeiden.
`**
```haproxy
idle-ping
```
Kann in folgenden Kontexten verwendet werden: tcp, http, log
Definieren Sie ein Intervall für regelmäßige Erreichbarkeitsprüfungen bei ungenutzten Backend-Verbindungen. Wenn die Gegenstelle vor der nächsten geplanten Prüfung nicht antwortet, wird die Verbindung geschlossen. Dieses Schlüsselwort bezieht sich auf die Backend-Seite, sodass es nützlich ist, um sicherzustellen, dass ungenutzte Verbindungen weiterhin verwendbar sind. Beachten Sie, dass dies das Schließen der Verbindung beim Bereinigen des Pools ungenutzter Verbindungen nicht verhindert.
Diese Funktion basiert auf spezifischer Protokollunterstützung. Derzeit wird sie nur vom H2-Multiplexer unterstützt. Idle-ping wird von anderen Protokollen einfach ignoriert.
Diese Option ist besonders bei Reverse HTTP nützlich. In der server-Zeile hilft sie der
Gegenstelle, die auf eingehende Verbindungen lauscht und diese einem passenden Server zuordnet,
damit sie später zur Weiterleitung von Datenverkehr wiederverwendet werden können.
},[...]*`**
```haproxy
init-addr {last | libc | none | },[...]*
```
Kann in folgenden Kontexten verwendet werden: tcp, http, log
Gibt an, in welcher Reihenfolge die Serveradresse beim Start aufgelöst werden soll, wenn sie einen
FQDN verwendet. Die Methoden der durch Kommas getrennten Liste werden nacheinander zur Auflösung
angewendet. Verwendet wird die erste erfolgreiche Methode. Wird das Listenende ohne erfolgreiche
Methode erreicht, wird ein Fehler ausgelöst. Die Methode "last" verwendet die im Statusdatei
angegebene Adresse (siehe "server-state-file"). "libc" verwendet den internen Resolver der libc
(gethostbyname() oder getaddrinfo(), abhängig von Betriebssystem und Build-Optionen). Die Methode
"none" gibt ausdrücklich an, dass der Server ohne gültige IP-Adresse im Zustand down starten soll.
Dies kann nützlich sein, um DNS-Probleme beim Start zu ignorieren und auf ihre spätere Behebung zu
warten. Schließlich kann auch eine IP-Adresse (IPv4 oder IPv6) angegeben werden. Das kann die
aktuell bekannte Serveradresse sein (z. B. von einem Konfigurationsgenerator eingetragen) oder die
Adresse eines Dummy-Servers, der alte Sitzungen abfängt und ihnen beispielsweise eine verständliche
Fehlermeldung liefert. Beim Lastverteilungsalgorithmus "first" könnte die IP-Adresse auf einen
Dummy-Server verweisen, der bei Bedarf die Erzeugung neuer Instanzen auslöst. Der Standardwert ist
"last,libc": Zunächst wird die frühere Adresse aus dem Statusdatei verwendet, sofern vorhanden,
andernfalls der Resolver der libc. Dies erhält die Kompatibilität mit dem bisherigen Verhalten.
Bei internen Resolvern wird allgemein empfohlen, die libc-basierte Auflösung entweder zu
deaktivieren oder explizit zu machen (Einzelheiten in [Abschnitt 5.3](/de/docs/haproxy/bind-and-server-options/#section-5-3)).
Beispiel 1:
```text
defaults
# never fail on address resolution
default-server init-addr last,libc,none
```
Beispiel 2:
```text
defaults
# disable libc resolution in combination with resolvers
default-server init-addr last,none
```
`**
```haproxy
inter
fastinter
downinter
```
Kann in folgenden Kontexten verwendet werden: tcp, http, log
Der Parameter "inter" setzt das Intervall zwischen zwei aufeinanderfolgenden Health Checks auf
`` Millisekunden. Ist er nicht angegeben, beträgt das Intervall standardmäßig 2000 ms.
Mit "fastinter" und "downinter" können die Prüfintervalle außerdem abhängig vom Serverzustand
optimiert werden:
```text
Serverzustand | Verwendetes Intervall
----------------------------------------+----------------------------------
UP 100% (kein Übergangszustand) | "inter"
----------------------------------------+----------------------------------
UP im Übergang (zu DOWN, "fall"), | "fastinter", falls gesetzt,
DOWN im Übergang (zu UP, "rise"), | andernfalls "inter".
oder noch nicht geprüft. |
----------------------------------------+----------------------------------
DOWN 100% (kein Übergangszustand) | "downinter", falls gesetzt,
| andernfalls "inter".
----------------------------------------+----------------------------------
```
Wie bei allen zeitbasierten Parametern kann explizit eine andere Einheit aus { us, ms, s, m, h, d }
angegeben werden. Der Parameter "inter" dient auch als Zeitüberschreitung für Health Checks an
Server, wenn "timeout check" nicht gesetzt ist. Um "Resonanz"-Effekte bei mehreren Servern auf
derselben Hardware zu verringern, werden die Agent- und Health Checks aller Server mit einem kleinen
zeitlichen Versatz zueinander gestartet. Mit dem globalen Schlüsselwort "spread-checks" kann den
Intervallen der Agent- und Health Checks außerdem eine zufällige Abweichung hinzugefügt werden.
Das ist beispielsweise sinnvoll, wenn viele Backends dieselben Server verwenden. Ist die globale
Einstellung "tune.max-checks-per-thread" auf einen Wert ungleich null gesetzt, begrenzt sie die
Anzahl gleichzeitig ausgeführter Prüfungen pro Thread. Dazu stellt haproxy Prüfungen, die auf einem
Thread mit bereits erreichtem Limit starten sollten, in eine Warteschlange, bis eine andere Prüfung
endet. Dadurch verlängert sich das tatsächliche Prüfintervall. In diesem Fall hat eine Verringerung
von "inter" nur eine sehr begrenzte Wirkung, da sie die Wartezeit in der Warteschlange nicht
verkürzen kann.
[ EXPERIMENTAL ]`**
```haproxy
ktls [ EXPERIMENTAL ]
```
Kann in folgenden Kontexten verwendet werden: tcp, http, log, peers, ring
Aktiviert oder deaktiviert ktls für diese Sockets. Wenn aktiviert, wird kTLS verwendet, sofern der
Kernel dies unterstützt und der Verschlüsselungsalgorithmus kompatibel ist. Dies ist nur unter
Linux ab 4.17 verfügbar. Beachten Sie, dass einige Netzwerktreiber und/oder TLS-Stacks die
Verwendung von kTLS auf TLS v1.2 beschränken können. Siehe auch "force-tlsv12".
`**
```haproxy
log-bufsize
```
Kann in folgenden Kontexten verwendet werden: log
"log-bufsize" legt die Größe des Ringpuffers für den impliziten Ring fest, der dem Log-Server in
einem Log-Backend zugeordnet wird. Ohne Angabe gilt der Standardwert BUFSIZE. Ein größerer Wert
erhöht den Speicherverbrauch, kann bei langsamen Servern aber den Verlust von Protokollmeldungen
verhindern helfen, da mehr ausstehende Meldungen im Puffer Platz finden. Dieses Schlüsselwort darf
nur in Log-Backend-Abschnitten (mit "mode log") verwendet werden.
`**
```haproxy
log-proto
```
Kann in folgenden Kontexten verwendet werden: log, ring
"log-proto" legt das Protokoll zur Weiterleitung von Ereignismeldungen an einen Server fest, der
in einem log- oder ring-Abschnitt konfiguriert ist. Mögliche Werte sind "legacy" und "octet-count";
sie entsprechen "Non-transparent-framing" bzw. "Octet counting" in rfc6587. Der Standardwert ist
"legacy".
`**
```haproxy
maxconn
```
Kann in folgenden Kontexten verwendet werden: tcp, http
Der Parameter "maxconn" gibt die maximale Anzahl gleichzeitiger Verbindungen zu diesem Server an.
Übersteigt die Anzahl gleichzeitig eingehender Verbindungen diesen Wert, werden sie in eine
Warteschlange gestellt, bis ein Platz frei wird. Dieser Parameter ist sehr wichtig, da er empfindliche
Server bei extremer Last vor dem Ausfall bewahren kann. Ist "minconn" angegeben, wird die Grenze
dynamisch. Der Standardwert "0" bedeutet unbegrenzt. Siehe auch "minconn", "maxqueue" und das
Backend-Schlüsselwort "fullconn".
Im HTTP-Modus begrenzt dieser Parameter die Anzahl gleichzeitiger Anfragen statt der Verbindungen.
Mehrere Anfragen können über eine einzige TCP-Verbindung zum Server multiplexiert werden. Bei einem
maxconn-Wert von 50 können beispielsweise zwischen 1 und 50 tatsächliche Serververbindungen
bestehen, aber höchstens 50 gleichzeitige Anfragen.
`**
```haproxy
maxqueue
```
Kann in folgenden Kontexten verwendet werden: tcp, http
Der Parameter "maxqueue" gibt die maximale Anzahl von Verbindungen an, die in der Warteschlange
für diesen Server warten. Ist diese Grenze erreicht, werden weitere Anfragen auf andere Server
umverteilt, anstatt unbegrenzt auf Bedienung zu warten. Das unterbricht die Persistenz, kann
Benutzern aber eine schnelle erneute Anmeldung ermöglichen, wenn der gewünschte Server ausfällt.
Einige Lastverteilungsalgorithmen wie leastconn berücksichtigen dies und nehmen bis zu dieser Grenze
Anfragen in die Serverwarteschlange auf, wenn der Wert explizit auf einen Wert größer als null
gesetzt ist. Gerade bei einstelligen maxconn-Werten lässt sich die Last damit häufig besser glätten.
Der Standardwert "0" bedeutet eine unbegrenzte Warteschlange. Siehe auch die Parameter "maxconn"
und "minconn" sowie "balance leastconn".
`**
```haproxy
max-reuse
```
Kann in folgenden Kontexten verwendet werden: http, ring
Bei Verwendung im http-Kontext:
Das Argument "max-reuse" weist die HTTP-Verbindungsverarbeitung an, eine Serververbindung höchstens
so oft für neue Anfragen wiederzuverwenden. Zulässig sind -1 (der Standardwert), wodurch die Grenze
deaktiviert wird, oder ein positiver Wert. Der Wert null deaktiviert Keep-Alive effektiv. Dies dient
ausschließlich dazu, bestimmte Serverfehler zu umgehen, die mit der Zeit Ressourcenlecks verursachen.
Die unteren Schichten halten sich nicht zwingend an dieses Argument, da technische Einschränkungen
dessen Durchsetzung unmöglich machen können. Zumindest HTTP/2-Verbindungen zu Servern beachten es.
Bei Verwendung im ring-Kontext:
Das Argument "max-reuse" weist die TCP-Verbindungsverarbeitung der Senke an, eine Serververbindung
höchstens so oft zum Senden von Meldungen wiederzuverwenden. Die Verbindung zum Server wird also
zwangsweise abgebaut, sobald mindestens "max-reuse + 1" Meldungen über dieselbe Verbindung
verarbeitet wurden. Anschließend wird sie automatisch neu aufgebaut. Bei vielen Meldungen im
Multithread-Betrieb kann dies helfen, die Last des Rings besser auf mehrere Threads zu verteilen.
Eine Verbindung bleibt nämlich während ihrer gesamten Lebensdauer an denselben CPU-Thread gebunden:
Anders als bei HTTP gibt es keine Syslog-Transaktionen. Daher könnte die Serververbindung unbegrenzt
bestehen bleiben, solange der Server sie nicht schließt und kein Netzwerkfehler auftritt. Durch
gelegentliches Abbauen der Verbindungen erhalten andere Threads die Möglichkeit, ihrerseits einige
Meldungen zu übernehmen. Dies kann auch einen geordneten Wechsel von Log-Servern unterstützen, wenn
zwischen haproxy und den Log-Servern eine zusätzliche Lastverteilungsschicht liegt. Bedenken Sie
jedoch, dass bei jeder Verbindungserneuerung ein ausgehender Port im Zustand TIME_WAIT verbleibt,
der auf modernen Betriebssystemen etwa eine Minute lang nicht wiederverwendet werden kann.
Deshalb muss auf ausreichend hohe Werte geachtet werden, damit die Quellports nicht schnell
erschöpft sind. Als Faustregel gilt: Schließen Sie Verbindungen niemals häufiger als einige Male pro Sekunde
und vorzugsweise deutlich seltener. Zulässig sind -1 (der Standardwert), wodurch
die Grenze deaktiviert wird, oder ein positiver Wert. Anders als im HTTP-Kontext wird "max-reuse"
bei Senkenservern nur nach Möglichkeit eingehalten: Meldungen des Rings werden in Stapeln
verarbeitet, und die Grenze wird zwischen den Stapeln geprüft.
`**
```haproxy
minconn
```
Kann in folgenden Kontexten verwendet werden: tcp, http
Wenn "minconn" gesetzt ist, wird maxconn zu einer dynamischen Grenze, die der Backend-Last folgt.
Der Server akzeptiert immer mindestens `` Verbindungen und nie mehr als ``.
Hat das Backend weniger als `` gleichzeitige Verbindungen, verläuft die Grenze linear zwischen
beiden Werten. So lässt sich die Serverlast bei normaler Auslastung begrenzen und bei hoher
Last stärker erhöhen, ohne den Server bei außergewöhnlich hoher Last zu überlasten. Siehe auch
"maxconn", "maxqueue" und das Backend-Schlüsselwort "fullconn".
`**
```haproxy
namespace
```
Kann in folgenden Kontexten verwendet werden: tcp, http, log, peers, ring
Unter Linux kann festgelegt werden, welchem Netzwerknamensraum ein Socket angehört. Mit dieser
Direktive kann ein Server explizit an einen anderen Namensraum als den Standardnamensraum gebunden
werden. Weitere Informationen zu Netzwerknamensräumen finden Sie in der Dokumentation Ihres
Betriebssystems.
`**
```haproxy
npn
```
Kann in folgenden Kontexten verwendet werden: tcp, http
Dies aktiviert die NPN-TLS-Erweiterung und bietet die angegebene Protokollliste über NPN als unterstützt an. Die Protokollliste besteht aus einer durch Kommas getrennten Liste von Protokollnamen, beispielsweise: "http/1.1,http/1.0" (ohne Anführungszeichen). Dies erfordert, dass die SSL-Bibliothek mit aktivierter Unterstützung für TLS-Erweiterungen gebaut wurde (überprüfen Sie mit haproxy -vv). Beachten Sie, dass die NPN-Erweiterung durch die ALPN-Erweiterung ersetzt wurde (siehe das Schlüsselwort "alpn"), diese ist jedoch erst ab OpenSSL 1.0.2 verfügbar.
`**
```haproxy
observe
```
Kann in folgenden Kontexten verwendet werden: tcp, http
Diese Option aktiviert die Anpassung des Serverzustands basierend auf der Beobachtung der Kommunikation mit dem Server. Standardmäßig ist diese Funktion deaktiviert und deren Aktivierung erfordert zudem die Aktivierung von Health Checks. Es werden zwei Modi unterstützt: "layer4" und "layer7". Im layer4-Modus sind nur erfolgreiche oder fehlgeschlagene TCP-Verbindungen von Bedeutung. Im layer7-Modus, der nur für HTTP-Proxys erlaubt ist, werden Antworten vom Server überprüft, beispielsweise gültige oder ungültige HTTP-Codes, nicht parsbare Header, Zeitüberschreitungen usw. Gültige Statuscodes umfassen 100 bis 499, 501 und 505.
Siehe auch: "check", "on-error" und "error-limit".
`**
```haproxy
on-error
```
Kann in folgenden Kontexten verwendet werden: tcp, http, log
Wählt aus, was geschehen soll, wenn genügend aufeinanderfolgende Fehler erkannt werden. Derzeit sind vier Modi verfügbar:
- fastinter: erzwingt fastinter
- fail-check: simuliert eine fehlgeschlagene Prüfung und erzwingt fastinter (Standard)
- sudden-death: simuliert eine fehlgeschlagene Health-Check-Prüfung unmittelbar vor der Ausfallgrenze;
eine weitere fehlgeschlagene Prüfung markiert den Server als ausgefallen; erzwingt fastinter
- mark-down: markiert den Server sofort als ausgefallen und erzwingt fastinter
Siehe auch: "check", "observe" und "error-limit".
`**
```haproxy
on-marked-down
```
Kann in folgenden Kontexten verwendet werden: tcp, http, log
Ändert, was geschieht, wenn ein Server als ausgefallen markiert wird. Derzeit ist eine Aktion verfügbar:
- shutdown-sessions: Beendet Peer-Streams. Wenn diese Einstellung aktiviert ist, werden alle Verbindungen zum Server sofort beendet, sobald der Server ausfällt. Dies kann verwendet werden, wenn der Health Check komplexere Fälle als ein einfacher Verbindungsstatus erkennt und lange Zeitüberschreitungen dazu führen würden, dass der Dienst zu lange unerreichbar bleibt. Beispielsweise kann ein Health Check erkennen, dass eine Datenbank blockiert ist und dass keine bestehenden Verbindungen mehr wiederverwendet werden können. Verbindungen, die auf diese Weise beendet werden, werden mit einem 'D'-Beendigungscode protokolliert (für "Down").
Aktionen sind standardmäßig deaktiviert.
`**
```haproxy
on-marked-up
```
Kann in folgenden Kontexten verwendet werden: tcp, http, log
Ändert, was geschieht, wenn ein Server als aktiv markiert wird. Derzeit ist eine Aktion verfügbar:
- shutdown-backup-sessions: Beendet Streams auf allen Backup-Servern. Dies erfolgt nur, wenn der Server nicht im Backup-Status ist und nicht deaktiviert ist (er muss ein effektives Gewicht von \> 0 haben). Dies kann gelegentlich verwendet werden, um einen aktiven Server nach der Wiederherstellung dazu zu zwingen, die gesamte Last wieder aufzunehmen, insbesondere bei langen Sitzungen (z. B. LDAP, SQL, ...). Dies kann mehr Probleme verursachen, als es lösen soll (z. B. unvollständige Transaktionen), verwenden Sie diese Funktion daher mit äußerster Vorsicht. Streams, die aufgrund der erneuten Verfügbarkeit eines Servers beendet werden, werden mit einem 'U'-Beendigungscode protokolliert (für "Up").
Aktionen sind standardmäßig deaktiviert.
`**
```haproxy
pool-conn-name
```
Kann in folgenden Kontexten verwendet werden: http
Beim Aufbau einer Backend-Verbindung wird dieser Ausdruck ausgewertet, um den Verbindungsnamen
zu erzeugen. Dieser Name ist eine der Schlüsseleigenschaften der Verbindung im Pool ungenutzter
Serververbindungen. Siehe das Schlüsselwort "http-reuse". Sucht eine Anfrage eine vorhandene
ungenutzte Verbindung, wird der Ausdruck ausgewertet, um eine identische Verbindung zu finden.
Im Kontext, in dem SSL SNI für die Backend-Verbindung verwendet wird, wird der Verbindungsname automatisch auf das Ergebnis des "sni"-Ausdrucks gesetzt. Dies entspricht dem häufigsten Einsatzfall. Für erweiterte Konfigurationen kann "pool-conn-name" verwendet werden, um dies zu überschreiben.
Siehe auch: "http-reuse", "sni"
`**
```haproxy
pool-low-conn
```
Kann in folgenden Kontexten verwendet werden: http
Legt einen unteren Schwellenwert für die Anzahl ungenutzter Verbindungen zu einem Server fest.
Unterhalb dieses Werts versucht ein Thread nicht, eine Verbindung von einem anderen Thread zu
übernehmen. Das kann die CPU-Nutzung bei vielen sehr schnellen Servern verbessern: Alle Threads
behalten jederzeit einige ungenutzte Verbindungen, statt diese bei einem Thread anzusammeln und
anschließend zwischen Threads zu verschieben. Typische Werte in Höhe der doppelten Thread-Anzahl
scheinen bereits bei Antwortzeiten unter einer Millisekunde sehr gute Leistung zu liefern.
Der Standardwert null erlaubt, jede ungenutzte Verbindung jederzeit zu verwenden; dies ist für den
normalen Einsatz empfohlen. Es gilt nur für Verbindungen, die nach denselben Grundsätzen wie bei
"http-reuse" gemeinsam genutzt werden können. Wird die gemeinsame Nutzung von Verbindungen durch
Threads mit "tune.idle-pool.shared" deaktiviert, kann diese Einstellung sehr wichtig sein, um
jedem Thread stets einige Verbindungen zu sichern. Andernfalls sinkt die Wiederverwendungsrate mit
steigender Thread-Anzahl.
`**
```haproxy
pool-max-conn
```
Kann in folgenden Kontexten verwendet werden: http
Legt die maximale Anzahl ungenutzter Verbindungen zu einem Server fest. -1 bedeutet unbegrenzt,
0 bedeutet keine ungenutzten Verbindungen. Der Standardwert ist -1. Sind ungenutzte Verbindungen
aktiviert, werden verwaiste Verbindungen, die keiner Clientsitzung mehr angehören, in einen eigenen
Pool verschoben. So bleiben sie für spätere Clients verwendbar. Dies gilt nur für Verbindungen,
die nach denselben Grundsätzen wie bei "http-reuse" gemeinsam genutzt werden können.
`**
```haproxy
pool-purge-delay
```
Kann in folgenden Kontexten verwendet werden: http
Legt die Verzögerung bis zum Beginn der Bereinigung ungenutzter Verbindungen fest. In jedem
Intervall von `` wird die Hälfte der ungenutzten Verbindungen geschlossen. 0 bedeutet, dass
keine ungenutzten Verbindungen gehalten werden. Der Standardwert ist 5s.
`**
```haproxy
port
```
Kann in folgenden Kontexten verwendet werden: tcp, http, log
Mit dem "port"-Parameter wird es möglich, einen anderen Port für Health Checks oder zur Prüfung des Agent-Checks zu verwenden. Bei einigen Servern kann es sinnvoll sein, einen Port speziell für eine Komponente zu reservieren, die komplexe Tests durchführen kann, die besser für Health Checks geeignet sind als die Anwendung selbst. Häufig wird beispielsweise ein einfaches Skript in inetd ausgeführt. Dieser Parameter wird ignoriert, wenn der "check"-Parameter nicht gesetzt ist. Siehe auch: "addr"-Parameter.
`**
```haproxy
proto
```
Kann in folgenden Kontexten verwendet werden: tcp, http
Erzwingt das Multiplexer-Protokoll für ausgehende Verbindungen zu diesem Server. Es muss mit dem
Modus des Backends (TCP oder HTTP) kompatibel und auf der Backend-Seite verwendbar sein. Die Liste
verfügbarer Protokolle wird von haproxy -vv ausgegeben. Angezeigt werden die Protokolleigenschaften:
der Modus (TCP/HTTP), die Seite (FE/BE), der Name des Multiplexers und seine Flags.
Einige Protokolle sind anfällig für Head-of-Line-Blocking auf der Server-Seite (flag=HOL_RISK). Schließlich unterstützen einige Protokolle keine Upgrades (flag=NO_UPG). Die HTX-Kompatibilität wird ebenfalls angegeben (flag=HTX).
Folgende Protokolle können als Argument für eine "proto"-Anweisung in einer Server-Zeile verwendet werden:
```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
```
Idee hinter dieser Option ist, die Auswahl des besten Multiplexer-Protokolls für alle Verbindungen, die zu diesem Server hergestellt werden, zu umgehen.
Wenn ALPN oder NPN konfiguriert ist, sollten die angegebenen Protokolle mit dem Multiplexer-Protokoll
kompatibel sein, um Probleme zu vermeiden. Ist beispielsweise "proto h1" gesetzt, sollte ALPN nicht
auf "h2" gesetzt werden.
Siehe auch "ws", um für Websocket-Streams ein alternatives Protokoll zu verwenden.
QMux ist eine Teilmenge von QUIC, die über TCP läuft. Sie entspricht dem folgenden Protokollentwurf:
. In haproxy gilt sie derzeit als
experimentell.
)]`**
```haproxy
quic-cc-algo { cubic | newreno | bbr | nocc }[()]
```
Diese QUIC-spezifische Einstellung wählt den Algorithmus zur Überlastkontrolle für alle
Verbindungen zu diesem Server. Die Algorithmen ähneln denen von TCP. Eine vollständige Beschreibung
aller Anpassungsmöglichkeiten finden Sie bei der gleichnamigen bind-Option.
Standardwert: cubic
Siehe auch: "tune.quic.be.tx.pacing" und "tune.quic.be.cc.max-win-size"
`**
```haproxy
redir
```
Kann in folgenden Kontexten verwendet werden: http
Der Parameter "redir" aktiviert die Umleitung für alle an diesen Server gerichteten GET- und
HEAD-Anfragen. HAProxy leitet die Anfrage dann nicht an den Server weiter, sondern sendet eine
Antwort "HTTP 302". Deren "Location"-Header besteht aus diesem Präfix, unmittelbar gefolgt von der
angefragten URI ab dem führenden '/' des Pfadbestandteils. Nach `` sollte deshalb kein
abschließender Schrägstrich stehen. Alle ungültigen Anfragen werden abgewiesen; Anfragen, die weder
GET noch HEAD sind, werden normal vom Server bedient. Da die Antwort vollständig erzeugt wird,
sind darin weder Header-Änderungen noch das Einfügen von Cookies möglich. Cookies in Anfragen
werden jedoch weiterhin ausgewertet. Damit lässt sich diese Lösung auch verwenden, um Benutzer
bei einem lokalen Ausfall an einen entfernten Standort umzuleiten. Der wichtigste Einsatzzweck
besteht darin, die Bandbreite für statische Server zu erhöhen, indem Clients direkt Verbindungen
zu ihnen aufbauen. Hinweis: Verwenden Sie hier niemals ein relatives Ziel, da sonst eine Schleife
zwischen Client und HAProxy entsteht!
Beispiel: server srv1 192.168.1.1:80 redir check
`**
```haproxy
rise
```
Kann in folgenden Kontexten verwendet werden: tcp, http, log
Der Parameter "rise" legt fest, dass ein Server nach `` aufeinanderfolgenden erfolgreichen
Health Checks als betriebsbereit gilt. Ohne Angabe beträgt dieser Wert standardmäßig 2. Siehe auch
die Parameter "check", "inter" und "fall".
resolve-opts ``,` `,... Kann in folgenden Kontexten verwendet werden: tcp, http, log
Durch Kommas getrennte Liste von Optionen für die DNS-Auflösung dieses Servers.
Verfügbare Optionen:
- allow-dup-ip Standardmäßig verhindert HAProxy doppelte IP-Adressen in einem Backend, wenn die
DNS-Auflösung zur Laufzeit aktiv ist. In manchen Fällen ist es jedoch sinnvoll, dass zwei Server
(im selben Backend und über denselben FQDN aufgelöst) dieselbe IP-Adresse haben. Aktivieren Sie
dafür einfach diese Option. Sie ist das Gegenteil von prevent-dup-ip.
- ignore-weight Ignoriert das in einem SRV-Eintrag gesetzte Gewicht. Dies ist nützlich, wenn
Gewichte anders gesteuert werden sollen, beispielsweise über "agent-check" oder die Runtime-API.
- prevent-dup-ip Setzt das Standardverhalten von HAProxy für einen Server durch: Eine IP-Adresse,
die bereits einem Server im selben Backend mit demselben fqdn zugeordnet ist, darf nicht erneut
verwendet werden. Dies ist das Gegenteil von allow-dup-ip.
Beispiel:
```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
```
Wenn allow-dup-ip gesetzt ist:
- Gibt der Nameserver eine einzige IP-Adresse zurück, verwenden beide Server diese Adresse.
- Gibt der Nameserver 2 IP-Adressen zurück, wählt jeder Server eine andere Adresse.
Standardwert: nicht gesetzt
`**
```haproxy
resolve-prefer
```
Kann in folgenden Kontexten verwendet werden: tcp, http, log
Wenn DNS-Auflösung für einen Server aktiviert ist und mehrere IP-Adressen aus verschiedenen
Adressfamilien zurückgegeben werden, bevorzugt HAProxy eine Adresse aus der im Parameter
"resolve-prefer" angegebenen Familie. Siehe auch das globale Schlüsselwort "dns-accept-family", um
ausschließlich eine bestimmte Familie zu erzwingen. Verfügbare Familien: "ipv4" und "ipv6".
Standardwert: ipv6
Beispiel:
```text
server s1 app1.domain.com:80 resolvers mydns resolve-prefer ipv6
```
[,[,