« back to all changes in this revision
Viewing changes to doc/configuration.txt
- browse files at revision 3
- compare with another revision
- download diff
- download tarball
- view history from revision 3
- Committer: Bazaar Package Importer
- Author(s): Arnaud Cornet
- Date: 2008-03-09 21:30:29 UTC
- mfrom: (1.1.1 upstream)
- Revision ID: james.westby@ubuntu.com-20080309213029-8oupnrc607mg5uqw
Tags: 1.3.14.3-1
* New Upstream Version
* Add status argument support to init-script to conform to LSB.
* Cleanup pidfile after stop in init script. Init script return code fixups.
* Add status argument support to init-script to conform to LSB.
* Cleanup pidfile after stop in init script. Init script return code fixups.
- files added:
- SUBVERS
- files removed:
- debian/haproxy.8
- files modified:
- CHANGELOG
added
removed
doc/configuration.txt
1
----------------------
2
HAProxy
3
Configuration Manual
4
----------------------
5
version 1.3.14.2
6
willy tarreau
7
2008/01/17
8
9
10
This document covers the configuration language as implemented in the version
11
specified above. It does not provide any hint, example or advice. For such
12
documentation, please refer to the Reference Manual or the Architecture Manual.
13
14
15
HAProxy's configuration process involves 3 major sources of parameters :
16
17
- the arguments from the command-line, which always take precedence
18
- the "global" section, which sets process-wide parameters
19
- the proxies sections which can take form of "defaults", "listen",
20
"frontend" and "backend".
21
22
The configuration file syntax consists in lines beginning with a keyword
23
referenced in this manual, optionally followed by one or several parameters
24
delimited by spaces. If spaces have to be entered in strings, then they must be
25
preceeded by a backslash ('\') to be escaped. Backslashes also have to be
26
escaped by doubling them.
27
28
Some parameters involve values representating time, such as timeouts. These
29
values are generally expressed in milliseconds (unless explicitly stated
30
otherwise) but may be expressed in any other unit by suffixing the unit to the
31
numeric value. It is important to consider this because it will not be repeated
32
for every keyword. Supported units are :
33
34
- us : microseconds. 1 microsecond = 1/1000000 second
35
- ms : milliseconds. 1 millisecond = 1/1000 second. This is the default.
36
- s : seconds. 1s = 1000ms
37
- m : minutes. 1m = 60s = 60000ms
38
- h : hours. 1h = 60m = 3600s = 3600000ms
39
- d : days. 1d = 24h = 1440m = 86400s = 86400000ms
40
41
42
1. Global parameters
43
--------------------
44
45
Parameters in the "global" section are process-wide and often OS-specific. They
46
are generally set once for all and do not need being changed once correct. Some
47
of them have command-line equivalents.
48
49
The following keywords are supported in the "global" section :
50
51
* Process management and security
52
- chroot
53
- daemon
54
- gid
55
- group
56
- log
57
- nbproc
58
- pidfile
59
- uid
60
- ulimit-n
61
- user
62
- stats
63
64
* Performance tuning
65
- maxconn
66
- noepoll
67
- nokqueue
68
- nopoll
69
- nosepoll
70
- spread-checks
71
- tune.maxaccept
72
- tune.maxpollevents
73
74
* Debugging
75
- debug
76
- quiet
77
78
79
1.1) Process management and security
80
------------------------------------
81
82
chroot <jail dir>
83
Changes current directory to <jail dir> and performs a chroot() there before
84
dropping privileges. This increases the security level in case an unknown
85
vulnerability would be exploited, since it would make it very hard for the
86
attacker to exploit the system. This only works when the process is started
87
with superuser privileges. It is important to ensure that <jail_dir> is both
88
empty and unwritable to anyone.
89
90
daemon
91
Makes the process fork into background. This is the recommended mode of
92
operation. It is equivalent to the command line "-D" argument. It can be
93
disabled by the command line "-db" argument.
94
95
gid <number>
96
Changes the process' group ID to <number>. It is recommended that the group
97
ID is dedicated to HAProxy or to a small set of similar daemons. HAProxy must
98
be started with a user belonging to this group, or with superuser privileges.
99
See also "group" and "uid".
100
101
group <group name>
102
Similar to "gid" but uses the GID of group name <group name> from /etc/group.
103
See also "gid" and "user".
104
105
log <address> <facility> [max level]
106
Adds a global syslog server. Up to two global servers can be defined. They
107
will receive logs for startups and exits, as well as all logs from proxies
108
configured with "log global".
109
110
<address> can be one of:
111
112
- An IPv4 address optionally followed by a colon and a UDP port. If
113
no port is specified, 514 is used by default (the standard syslog
114
port).
115
116
- A filesystem path to a UNIX domain socket, keeping in mind
117
considerations for chroot (be sure the path is accessible inside
118
the chroot) and uid/gid (be sure the path is appropriately
119
writeable).
120
121
<facility> must be one of the 24 standard syslog facilities :
122
123
kern user mail daemon auth syslog lpr news
124
uucp cron auth2 ftp ntp audit alert cron2
125
local0 local1 local2 local3 local4 local5 local6 local7
126
127
An optional level can be specified to filter outgoing messages. By default,
128
all messages are sent. If a level is specified, only messages with a severity
129
at least as important as this level will be sent. 8 levels are known :
130
131
emerg alert crit err warning notice info debug
132
133
nbproc <number>
134
Creates <number> processes when going daemon. This requires the "daemon"
135
mode. By default, only one process is created, which is the recommended mode
136
of operation. For systems limited to small sets of file descriptors per
137
process, it may be needed to fork multiple daemons. USING MULTIPLE PROCESSES
138
IS HARDER TO DEBUG AND IS REALLY DISCOURAGED. See also "daemon".
139
140
pidfile <pidfile>
141
Writes pids of all daemons into file <pidfile>. This option is equivalent to
142
the "-p" command line argument. The file must be accessible to the user
143
starting the process. See also "daemon".
144
145
stats socket <path> [{uid | user} <uid>] [{gid | group} <gid>] [mode <mode>]
146
Creates a UNIX socket in stream mode at location <path>. Any previously
147
existing socket will be backed up then replaced. Connections to this socket
148
will get a CSV-formated output of the process statistics in response to the
149
"show stat" command followed by a line feed, and more general process
150
information in response to the "show info" command followed by a line feed.
151
152
On platforms which support it, it is possible to restrict access to this
153
socket by specifying numerical IDs after "uid" and "gid", or valid user and
154
group names after the "user" and "group" keywords. It is also possible to
155
restrict permissions on the socket by passing an octal value after the "mode"
156
keyword (same syntax as chmod). Depending on the platform, the permissions on
157
the socket will be inherited from the directory which hosts it, or from the
158
user the process is started with.
159
160
stats timeout <timeout, in milliseconds>
161
The default timeout on the stats socket is set to 10 seconds. It is possible
162
to change this value with "stats timeout". The value must be passed in
163
milliseconds, or be suffixed by a time unit among { us, ms, s, m, h, d }.
164
165
stats maxconn <connections>
166
By default, the stats socket is limited to 10 concurrent connections. It is
167
possible to change this value with "stats maxconn".
168
169
uid <number>
170
Changes the process' user ID to <number>. It is recommended that the user ID
171
is dedicated to HAProxy or to a small set of similar daemons. HAProxy must
172
be started with superuser privileges in order to be able to switch to another
173
one. See also "gid" and "user".
174
175
ulimit-n <number>
176
Sets the maximum number of per-process file-descriptors to <number>. By
177
default, it is automatically computed, so it is recommended not to use this
178
option.
179
180
user <user name>
181
Similar to "uid" but uses the UID of user name <user name> from /etc/passwd.
182
See also "uid" and "group".
183
184
185
1.2) Performance tuning
186
-----------------------
187
188
maxconn <number>
189
Sets the maximum per-process number of concurrent connections to <number>. It
190
is equivalent to the command-line argument "-n". Proxies will stop accepting
191
connections when this limit is reached. The "ulimit-n" parameter is
192
automatically adjusted according to this value. See also "ulimit-n".
193
194
noepoll
195
Disables the use of the "epoll" event polling system on Linux. It is
196
equivalent to the command-line argument "-de". The next polling system
197
used will generally be "poll". See also "nosepoll", and "nopoll".
198
199
nokqueue
200
Disables the use of the "kqueue" event polling system on BSD. It is
201
equivalent to the command-line argument "-dk". The next polling system
202
used will generally be "poll". See also "nopoll".
203
204
nopoll
205
Disables the use of the "poll" event polling system. It is equivalent to the
206
command-line argument "-dp". The next polling system used will be "select".
207
It should never be needed to disable "poll" since it's available on all
208
platforms supported by HAProxy. See also "nosepoll", and "nopoll" and
209
"nokqueue".
210
211
nosepoll
212
Disables the use of the "speculative epoll" event polling system on Linux. It
213
is equivalent to the command-line argument "-ds". The next polling system
214
used will generally be "epoll". See also "nosepoll", and "nopoll".
215
216
spread-checks <0..50, in percent>
217
Sometimes it is desirable to avoid sending health checks to servers at exact
218
intervals, for instance when many logical servers are located on the same
219
physical server. With the help of this parameter, it becomes possible to add
220
some randomness in the check interval between 0 and +/- 50%. A value between
221
2 and 5 seems to show good results. The default value remains at 0.
222
223
tune.maxaccept <number>
224
Sets the maximum number of consecutive accepts that a process may perform on
225
a single wake up. High values give higher priority to high connection rates,
226
while lower values give higher priority to already established connections.
227
This value is unlimited by default in single process mode. However, in
228
multi-process mode (nbproc > 1), it defaults to 8 so that when one process
229
wakes up, it does not take all incoming connections for itself and leaves a
230
part of them to other processes. Setting this value to zero or less disables
231
the limitation. It should normally not be needed to tweak this value.
232
233
tune.maxpollevents <number>
234
Sets the maximum amount of events that can be processed at once in a call to
235
the polling system. The default value is adapted to the operating system. It
236
has been noticed that reducing it below 200 tends to slightly decrease
237
latency at the expense of network bandwidth, and increasing it above 200
238
tends to trade latency for slightly increased bandwidth.
239
240
241
1.3) Debugging
242
---------------
243
244
debug
245
Enables debug mode which dumps to stdout all exchanges, and disables forking
246
into background. It is the equivalent of the command-line argument "-d". It
247
should never be used in a production configuration since it may prevent full
248
system startup.
249
250
quiet
251
Do not display any message during startup. It is equivalent to the command-
252
line argument "-q".
253
254
255
2) Proxies
256
----------
257
258
Proxy configuration can be located in a set of sections :
259
- defaults <name>
260
- frontend <name>
261
- backend <name>
262
- listen <name>
263
264
A "defaults" section sets default parameters for all other sections following
265
its declaration. Those default parameters are reset by the next "defaults"
266
section. See below for the list of parameters which can be set in a "defaults"
267
section. The name is optional but its use is encouraged for better readability.
268
269
A "frontend" section describes a set of listening sockets accepting client
270
connections.
271
272
A "backend" section describes a set of servers to which the proxy will connect
273
to forward incoming connections.
274
275
A "listen" section defines a complete proxy with its frontend and backend
276
parts combined in one section. It is generally useful for TCP-only traffic.
277
278
All proxy names must be formed from upper and lower case letters, digits,
279
'-' (dash), '_' (underscore) , '.' (dot) and ':' (colon). ACL names are
280
case-sensitive, which means that "www" and "WWW" are two different proxies.
281
282
Historically, all proxy names could overlap, it just caused troubles in the
283
logs. Since the introduction of content switching, it is mandatory that two
284
proxies with overlapping capabilities (frontend/backend) have different names.
285
However, it is still permitted that a frontend and a backend share the same
286
name, as this configuration seems to be commonly encountered.
287
288
Right now, two major proxy modes are supported : "tcp", also known as layer 4,
289
and "http", also known as layer 7. In layer 4 mode, HAProxy simply forwards
290
bidirectionnal traffic between two sides. In layer 7 mode, HAProxy analyzes the
291
protocol, and can interact with it by allowing, blocking, switching, adding,
292
modifying, or removing arbitrary contents in requests or responses, based on
293
arbitrary criteria.
294
295
296
2.1) Quick reminder about HTTP
297
------------------------------
298
299
When a proxy is running in HTTP mode, both the request and the response are
300
fully analyzed and indexed, thus it becomes possible to build matching criteria
301
on almost anything found in the contents.
302
303
However, it is important to understand how HTTP requests and responses are
304
formed, and how HAProxy decomposes them. It will then become easier to write
305
correct rules and to debug existing configurations.
306
307
308
2.1.1) The HTTP transaction model
309
---------------------------------
310
311
The HTTP protocol is transaction-driven. This means that each request will lead
312
to one and only one response. Traditionnally, a TCP connection is established
313
from the client to the server, a request is sent by the client on the
314
connection, the server responds and the connection is closed. A new request
315
will involve a new connection :
316
317
[CON1] [REQ1] ... [RESP1] [CLO1] [CON2] [REQ2] ... [RESP2] [CLO2] ...
318
319
In this mode, called the "HTTP close" mode, there are as many connection
320
establishments as there are HTTP transactions. Since the connection is closed
321
by the server after the response, the client does not need to know the content
322
length.
323
324
Due to the transactional nature of the protocol, it was possible to improve it
325
to avoid closing a connection between two subsequent transactions. In this mode
326
however, it is mandatory that the server indicates the content length for each
327
response so that the client does not wait indefinitely. For this, a special
328
header is used: "Content-length". This mode is called the "keep-alive" mode :
329
330
[CON] [REQ1] ... [RESP1] [REQ2] ... [RESP2] [CLO] ...
331
332
Its advantages are a reduced latency between transactions, and less processing
333
power required on the server side. It is generally better than the close mode,
334
but not always because the clients often limit their concurrent connections to
335
a smaller value. HAProxy currently does not support the HTTP keep-alive mode,
336
but knows how to transform it to the close mode.
337
338
A last improvement in the communications is the pipelining mode. It still uses
339
keep-alive, but the client does not wait for the first response to send the
340
second request. This is useful for fetching large number of images composing a
341
page :
342
343
[CON] [REQ1] [REQ2] ... [RESP1] [RESP2] [CLO] ...
344
345
This can obviously have a tremendous benefit on performance because the network
346
latency is eliminated between subsequent requests. Many HTTP agents do not
347
correctly support pipelining since there is no way to associate a response with
348
the corresponding request in HTTP. For this reason, it is mandatory for the
349
server to reply in the exact same order as the requests were received.
350
351
Right now, HAProxy only supports the first mode (HTTP close) if it needs to
352
process the request. This means that for each request, there will be one TCP
353
connection. If keep-alive or pipelining are required, HAProxy will still
354
support them, but will only see the first request and the first response of
355
each transaction. While this is generally problematic with regards to logs,
356
content switching or filtering, it most often causes no problem for persistence
357
with cookie insertion.
358
359
360
2.1.2) HTTP request
361
-------------------
362
363
First, let's consider this HTTP request :
364
365
Line Contents
366
number
367
1 GET /serv/login.php?lang=en&profile=2 HTTP/1.1
368
2 Host: www.mydomain.com
369
3 User-agent: my small browser
370
4 Accept: image/jpeg, image/gif
371
5 Accept: image/png
372
373
374
2.1.2.1) The Request line
375
-------------------------
376
377
Line 1 is the "request line". It is always composed of 3 fields :
378
379
- a METHOD : GET
380
- a URI : /serv/login.php?lang=en&profile=2
381
- a version tag : HTTP/1.1
382
383
All of them are delimited by what the standard calls LWS (linear white spaces),
384
which are commonly spaces, but can also be tabs or line feeds/carriage returns
385
followed by spaces/tabs. The method itself cannot contain any colon (':') and
386
is limited to alphabetic letters. All those various combinations make it
387
desirable that HAProxy performs the splitting itself rather than leaving it to
388
the user to write a complex or inaccurate regular expression.
389
390
The URI itself can have several forms :
391
392
- A "relative URI" :
393
394
/serv/login.php?lang=en&profile=2
395
396
It is a complete URL without the host part. This is generally what is
397
received by servers, reverse proxies and transparent proxies.
398
399
- An "absolute URI", also called a "URL" :
400
401
http://192.168.0.12:8080/serv/login.php?lang=en&profile=2
402
403
It is composed of a "scheme" (the protocol name followed by '://'), a host
404
name or address, optionally a colon (':') followed by a port number, then
405
a relative URI beginning at the first slash ('/') after the address part.
406
This is generally what proxies receive, but a server supporting HTTP/1.1
407
must accept this form too.
408
409
- a star ('*') : this form is only accepted in association with the OPTIONS
410
method and is not relayable. It is used to inquiry a next hop's
411
capabilities.
412
413
- an address:port combination : 192.168.0.12:80
414
This is used with the CONNECT method, which is used to establish TCP
415
tunnels through HTTP proxies, generally for HTTPS, but sometimes for
416
other protocols too.
417
418
In a relative URI, two sub-parts are identified. The part before the question
419
mark is called the "path". It is typically the relative path to static objects
420
on the server. The part after the question mark is called the "query string".
421
It is mostly used with GET requests sent to dynamic scripts and is very
422
specific to the language, framework or application in use.
423
424
425
2.1.2.2) The request headers
426
----------------------------
427
428
The headers start at the second line. They are composed of a name at the
429
beginning of the line, immediately followed by a colon (':'). Traditionally,
430
an LWS is added after the colon but that's not required. Then come the values.
431
Multiple identical headers may be folded into one single line, delimiting the
432
values with commas, provided that their order is respected. This is commonly
433
encountered in the "Cookie:" field. A header may span over multiple lines if
434
the subsequent lines begin with an LWS. In the example in 2.1.2, lines 4 and 5
435
define a total of 3 values for the "Accept:" header.
436
437
Contrary to a common mis-conception, header names are not case-sensitive, and
438
their values are not either if they refer to other header names (such as the
439
"Connection:" header).
440
441
The end of the headers is indicated by the first empty line. People often say
442
that it's a double line feed, which is not exact, even if a double line feed
443
is one valid form of empty line.
444
445
Fortunately, HAProxy takes care of all these complex combinations when indexing
446
headers, checking values and counting them, so there is no reason to worry
447
about the way they could be written, but it is important not to accuse an
448
application of being buggy if it does unusual, valid things.
449
450
Important note:
451
As suggested by RFC2616, HAProxy normalizes headers by replacing line breaks
452
in the middle of headers by LWS in order to join multi-line headers. This
453
is necessary for proper analysis and helps less capable HTTP parsers to work
454
correctly and not to be fooled by such complex constructs.
455
456
457
2.1.3) HTTP response
458
--------------------
459
460
An HTTP response looks very much like an HTTP request. Both are called HTTP
461
messages. Let's consider this HTTP response :
462
463
Line Contents
464
number
465
1 HTTP/1.1 200 OK
466
2 Content-length: 350
467
3 Content-Type: text/html
468
469
470
2.1.3.1) The Response line
471
--------------------------
472
473
Line 1 is the "response line". It is always composed of 3 fields :
474
475
- a version tag : HTTP/1.1
476
- a status code : 200
477
- a reason : OK
478
479
The status code is always 3-digit. The first digit indicates a general status :
480
- 2xx = OK, content is following (eg: 200, 206)
481
- 3xx = OK, no content following (eg: 302, 304)
482
- 4xx = error caused by the client (eg: 401, 403, 404)
483
- 5xx = error caused by the server (eg: 500, 502, 503)
484
485
Please refer to RFC2616 for the detailed meaning of all such codes. The
486
"reason" field is just a hint, but is not parsed by clients. Anything can be
487
found there, but it's a common practice to respect the well-established
488
messages. It can be composed of one or multiple words, such as "OK", "Found",
489
or "Authentication Required".
490
491
492
2.1.3.2) The response headers
493
-----------------------------
494
495
Response headers work exactly like request headers, and as such, HAProxy uses
496
the same parsing function for both. Please refer to paragraph 2.1.2.2 for more
497
details.
498
499
500
2.2) Proxy keywords matrix
501
----------------------------
502
503
The following list of keywords is supported. Most of them may only be used in a
504
limited set of section types. Some of them are marked as "deprecated" because
505
they are inherited from an old syntax which may be confusing or functionally
506
limited, and there are new recommended keywords to replace them. Keywords
507
listed with [no] can be optionally inverted using the "no" prefix, ex. "no
508
option contstats". This makes sense when the option has been enabled by default
509
and must be disabled for a specific instance.
510
511
512
keyword defaults frontend listen backend
513
----------------------+----------+----------+---------+---------
514
acl - X X X
515
appsession - - X X
516
backlog X X X -
517
balance X - X X
518
bind - X X -
519
block - X X X
520
capture cookie - X X -
521
capture request header - X X -
522
capture response header - X X -
523
clitimeout X X X - (deprecated)
524
contimeout X - X X (deprecated)
525
cookie X - X X
526
default_backend - X X -
527
disabled X X X X
528
dispatch - - X X
529
enabled X X X X
530
errorfile X X X X
531
errorloc X X X X
532
errorloc302 X X X X
533
errorloc303 X X X X
534
fullconn X - X X
535
grace - X X X
536
http-check disable-on-404 X - X X
537
log X X X X
538
maxconn X X X -
539
mode X X X X
540
monitor fail - X X -
541
monitor-net X X X -
542
monitor-uri X X X -
543
[no] option abortonclose X - X X
544
[no] option allbackups X - X X
545
[no] option checkcache X - X X
546
[no] option clitcpka X X X -
547
[no] option contstats X X X -
548
[no] option dontlognull X X X -
549
[no] option forceclose X - X X
550
option forwardfor X X X X
551
[no] option http_proxy X X X X
552
option httpchk X - X X
553
[no] option httpclose X X X X
554
option httplog X X X X
555
[no] option logasap X X X -
556
[no] option nolinger X X X X
557
[no] option persist X - X X
558
[no] option redispatch X - X X
559
option smtpchk X - X X
560
[no] option srvtcpka X - X X
561
option ssl-hello-chk X - X X
562
option tcpka X X X X
563
option tcplog X X X X
564
[no] option tcpsplice X X X X
565
[no] option transparent X X X -
566
redisp X - X X (deprecated)
567
redispatch X - X X (deprecated)
568
reqadd - X X X
569
reqallow - X X X
570
reqdel - X X X
571
reqdeny - X X X
572
reqiallow - X X X
573
reqidel - X X X
574
reqideny - X X X
575
reqipass - X X X
576
reqirep - X X X
577
reqisetbe - X X X
578
reqitarpit - X X X
579
reqpass - X X X
580
reqrep - X X X
581
reqsetbe - X X X
582
reqtarpit - X X X
583
retries X - X X
584
rspadd - X X X
585
rspdel - X X X
586
rspdeny - X X X
587
rspidel - X X X
588
rspideny - X X X
589
rspirep - X X X
590
rsprep - X X X
591
server - - X X
592
source X - X X
593
srvtimeout X - X X (deprecated)
594
stats auth X - X X
595
stats enable X - X X
596
stats realm X - X X
597
stats refresh X - X X
598
stats scope X - X X
599
stats uri X - X X
600
stats hide-version X - X X
601
timeout client X X X -
602
timeout clitimeout X X X - (deprecated)
603
timeout connect X - X X
604
timeout contimeout X - X X (deprecated)
605
timeout http-request X X X -
606
timeout queue X - X X
607
timeout server X - X X
608
timeout srvtimeout X - X X (deprecated)
609
timeout tarpit X X X X
610
transparent X X X - (deprecated)
611
use_backend - X X -
612
----------------------+----------+----------+---------+---------
613
keyword defaults frontend listen backend
614
615
616
2.2.1) Alphabetically sorted keywords reference
617
-----------------------------------------------
618
619
This section provides a description of each keyword and its usage.
620
621
622
acl <aclname> <criterion> [flags] [operator] <value> ...
623
Declare or complete an access list.
624
May be used in sections : defaults | frontend | listen | backend
625
no | yes | yes | yes
626
Example:
627
acl invalid_src src 0.0.0.0/7 224.0.0.0/3
628
acl invalid_src src_port 0:1023
629
acl local_dst hdr(host) -i localhost
630
631
See section 2.3 about ACL usage.
632
633
634
appsession <cookie> len <length> timeout <holdtime>
635
Define session stickiness on an existing application cookie.
636
May be used in sections : defaults | frontend | listen | backend
637
no | no | yes | yes
638
Arguments :
639
<cookie> this is the name of the cookie used by the application and which
640
HAProxy will have to learn for each new session.
641
642
<length> this is the number of characters that will be memorized and
643
checked in each cookie value.
644
645
<holdtime> this is the time after which the cookie will be removed from
646
memory if unused. If no unit is specified, this time is in
647
milliseconds.
648
649
When an application cookie is defined in a backend, HAProxy will check when
650
the server sets such a cookie, and will store its value in a table, and
651
associate it with the server's identifier. Up to <length> characters from
652
the value will be retained. On each connection, haproxy will look for this
653
cookie both in the "Cookie:" headers, and as a URL parameter in the query
654
string. If a known value is found, the client will be directed to the server
655
associated with this value. Otherwise, the load balancing algorithm is
656
applied. Cookies are automatically removed from memory when they have been
657
unused for a duration longer than <holdtime>.
658
659
The definition of an application cookie is limited to one per backend.
660
661
Example :
662
appsession JSESSIONID len 52 timeout 3h
663
664
See also : "cookie", "capture cookie" and "balance".
665
666
667
backlog <conns>
668
Give hints to the system about the approximate listen backlog desired size
669
May be used in sections : defaults | frontend | listen | backend
670
yes | yes | yes | no
671
Arguments :
672
<conns> is the number of pending connections. Depending on the operating
673
system, it may represent the number of already acknowledged
674
connections, of non-acknowledged ones, or both.
675
676
In order to protect against SYN flood attacks, one solution is to increase
677
the system's SYN backlog size. Depending on the system, sometimes it is just
678
tunable via a system parameter, sometimes it is not adjustable at all, and
679
sometimes the system relies on hints given by the application at the time of
680
the listen() syscall. By default, HAProxy passes the frontend's maxconn value
681
to the listen() syscall. On systems which can make use of this value, it can
682
sometimes be useful to be able to specify a different value, hence this
683
backlog parameter.
684
685
On Linux 2.4, the parameter is ignored by the system. On Linux 2.6, it is
686
used as a hint and the system accepts up to the smallest greater power of
687
two, and never more than some limits (usually 32768).
688
689
See also : "maxconn" and the target operating system's tuning guide.
690
691
692
balance <algorithm> [ <arguments> ]
693
Define the load balancing algorithm to be used in a backend.
694
May be used in sections : defaults | frontend | listen | backend
695
yes | no | yes | yes
696
Arguments :
697
<algorithm> is the algorithm used to select a server when doing load
698
balancing. This only applies when no persistence information
699
is available, or when a connection is redispatched to another
700
server. <algorithm> may be one of the following :
701
702
roundrobin Each server is used in turns, according to their weights.
703
This is the smoothest and fairest algorithm when the server's
704
processing time remains equally distributed. This algorithm
705
is dynamic, which means that server weights may be adjusted
706
on the fly for slow starts for instance.
707
708
source The source IP address is hashed and divided by the total
709
weight of the running servers to designate which server will
710
receive the request. This ensures that the same client IP
711
address will always reach the same server as long as no
712
server goes down or up. If the hash result changes due to the
713
number of running servers changing, many clients will be
714
directed to a different server. This algorithm is generally
715
used in TCP mode where no cookie may be inserted. It may also
716
be used on the Internet to provide a best-effort stickyness
717
to clients which refuse session cookies. This algorithm is
718
static, which means that changing a server's weight on the
719
fly will have no effect.
720
721
uri The left part of the URI (before the question mark) is hashed
722
and divided by the total weight of the running servers. The
723
result designates which server will receive the request. This
724
ensures that a same URI will always be directed to the same
725
server as long as no server goes up or down. This is used
726
with proxy caches and anti-virus proxies in order to maximize
727
the cache hit rate. Note that this algorithm may only be used
728
in an HTTP backend. This algorithm is static, which means
729
that changing a server's weight on the fly will have no
730
effect.
731
732
url_param The URL parameter specified in argument will be looked up in
733
the query string of each HTTP request. If it is found
734
followed by an equal sign ('=') and a value, then the value
735
is hashed and divided by the total weight of the running
736
servers. The result designates which server will receive the
737
request. This is used to track user identifiers in requests
738
and ensure that a same user ID will always be sent to the
739
same server as long as no server goes up or down. If no value
740
is found or if the parameter is not found, then a round robin
741
algorithm is applied. Note that this algorithm may only be
742
used in an HTTP backend. This algorithm is static, which
743
means that changing a server's weight on the fly will have no
744
effect.
745
746
<arguments> is an optional list of arguments which may be needed by some
747
algorithms. Right now, only the "url_param" algorithm supports
748
a mandatory argument.
749
750
The definition of the load balancing algorithm is mandatory for a backend
751
and limited to one per backend.
752
753
Examples :
754
balance roundrobin
755
balance url_param userid
756
757
See also : "dispatch", "cookie", "appsession", "transparent" and "http_proxy".
758
759
760
bind [<address>]:<port> [, ...]
761
Define one or several listening addresses and/or ports in a frontend.
762
May be used in sections : defaults | frontend | listen | backend
763
no | yes | yes | no
764
Arguments :
765
<address> is optional and can be a host name, an IPv4 address, an IPv6
766
address, or '*'. It designates the address the frontend will
767
listen on. If unset, all IPv4 addresses of the system will be
768
listened on. The same will apply for '*' or the system's special
769
address "0.0.0.0".
770
771
<port> is the TCP port number the proxy will listen on. The port is
772
mandatory. Note that in the case of an IPv6 address, the port is
773
always the number after the last colon (':').
774
775
It is possible to specify a list of address:port combinations delimited by
776
commas. The frontend will then listen on all of these addresses. There is no
777
fixed limit to the number of addresses and ports which can be listened on in
778
a frontend, as well as there is no limit to the number of "bind" statements
779
in a frontend.
780
781
Example :
782
listen http_proxy
783
bind :80,:443
784
bind 10.0.0.1:10080,10.0.0.1:10443
785
786
See also : "source".
787
788
789
block { if | unless } <condition>
790
Block a layer 7 request if/unless a condition is matched
791
May be used in sections : defaults | frontend | listen | backend
792
no | yes | yes | yes
793
794
The HTTP request will be blocked very early in the layer 7 processing
795
if/unless <condition> is matched. A 403 error will be returned if the request
796
is blocked. The condition has to reference ACLs (see section 2.3). This is
797
typically used to deny access to certain sensible resources if some
798
conditions are met or not met. There is no fixed limit to the number of
799
"block" statements per instance.
800
801
Example:
802
acl invalid_src src 0.0.0.0/7 224.0.0.0/3
803
acl invalid_src src_port 0:1023
804
acl local_dst hdr(host) -i localhost
805
block if invalid_src || local_dst
806
807
See section 2.3 about ACL usage.
808
809
810
capture cookie <name> len <length>
811
Capture and log a cookie in the request and in the response.
812
May be used in sections : defaults | frontend | listen | backend
813
no | yes | yes | no
814
Arguments :
815
<name> is the beginning of the name of the cookie to capture. In order
816
to match the exact name, simply suffix the name with an equal
817
sign ('='). The full name will appear in the logs, which is
818
useful with application servers which adjust both the cookie name
819
and value (eg: ASPSESSIONXXXXX).
820
821
<length> is the maximum number of characters to report in the logs, which
822
include the cookie name, the equal sign and the value, all in the
823
standard "name=value" form. The string will be truncated on the
824
right if it exceeds <length>.
825
826
Only the first cookie is captured. Both the "cookie" request headers and the
827
"set-cookie" response headers are monitored. This is particularly useful to
828
check for application bugs causing session crossing or stealing between
829
users, because generally the user's cookies can only change on a login page.
830
831
When the cookie was not presented by the client, the associated log column
832
will report "-". When a request does not cause a cookie to be assigned by the
833
server, a "-" is reported in the response column.
834
835
The capture is performed in the frontend only because it is necessary that
836
the log format does not change for a given frontend depending on the
837
backends. This may change in the future. Note that there can be only one
838
"capture cookie" statement in a frontend. The maximum capture length is
839
configured in the souces by default to 64 characters. It is not possible to
840
specify a capture in a "defaults" section.
841
842
Example:
843
capture cookie ASPSESSION len 32
844
845
See also : "capture request header", "capture response header" as well as
846
section 2.6 about logging.
847
848
849
capture request header <name> len <length>
850
Capture and log the first occurrence of the specified request header.
851
May be used in sections : defaults | frontend | listen | backend
852
no | yes | yes | no
853
Arguments :
854
<name> is the name of the header to capture. The header names are not
855
case-sensitive, but it is a common practice to write them as they
856
appear in the requests, with the first letter of each word in
857
upper case. The header name will not appear in the logs, only the
858
value is reported, but the position in the logs is respected.
859
860
<length> is the maximum number of characters to extract from the value and
861
report in the logs. The string will be truncated on the right if
862
it exceeds <length>.
863
864
Only the first value of the first occurrence of the header is captured. The
865
value will be added to the logs between braces ('{}'). If multiple headers
866
are captured, they will be delimited by a vertical bar ('|') and will appear
867
in the same order they were declared in the configuration. Common uses for
868
request header captures include the "Host" field in virtual hosting
869
environments, the "Content-length" when uploads are supported, "User-agent"
870
to quickly differenciate between real users and robots, and "X-Forwarded-For"
871
in proxied environments to find where the request came from.
872
873
There is no limit to the number of captured request headers, but each capture
874
is limited to 64 characters. In order to keep log format consistent for a
875
same frontend, header captures can only be declared in a frontend. It is not
876
possible to specify a capture in a "defaults" section.
877
878
Example:
879
capture request header Host len 15
880
capture request header X-Forwarded-For len 15
881
capture request header Referrer len 15
882
883
See also : "capture cookie", "capture response header" as well as section 2.6
884
about logging.
885
886
887
capture response header <name> len <length>
888
Capture and log the first occurrence of the specified response header.
889
May be used in sections : defaults | frontend | listen | backend
890
no | yes | yes | no
891
Arguments :
892
<name> is the name of the header to capture. The header names are not
893
case-sensitive, but it is a common practice to write them as they
894
appear in the response, with the first letter of each word in
895
upper case. The header name will not appear in the logs, only the
896
value is reported, but the position in the logs is respected.
897
898
<length> is the maximum number of characters to extract from the value and
899
report in the logs. The string will be truncated on the right if
900
it exceeds <length>.
901
902
Only the first value of the first occurrence of the header is captured. The
903
result will be added to the logs between braces ('{}') after the captured
904
request headers. If multiple headers are captured, they will be delimited by
905
a vertical bar ('|') and will appear in the same order they were declared in
906
the configuration. Common uses for response header captures include the
907
"Content-length" header which indicates how many bytes are expected to be
908
returned, the "Location" header to track redirections.
909
910
There is no limit to the number of captured response headers, but each
911
capture is limited to 64 characters. In order to keep log format consistent
912
for a same frontend, header captures can only be declared in a frontend. It
913
is not possible to specify a capture in a "defaults" section.
914
915
Example:
916
capture response header Content-length len 9
917
capture response header Location len 15
918
919
See also : "capture cookie", "capture request header" as well as section 2.6
920
about logging.
921
922
923
clitimeout <timeout>
924
Set the maximum inactivity time on the client side.
925
May be used in sections : defaults | frontend | listen | backend
926
yes | yes | yes | no
927
Arguments :
928
<timeout> is the timeout value is specified in milliseconds by default, but
929
can be in any other unit if the number is suffixed by the unit,
930
as explained at the top of this document.
931
932
The inactivity timeout applies when the client is expected to acknowledge or
933
send data. In HTTP mode, this timeout is particularly important to consider
934
during the first phase, when the client sends the request, and during the
935
response while it is reading data sent by the server. The value is specified
936
in milliseconds by default, but can be in any other unit if the number is
937
suffixed by the unit, as specified at the top of this document. In TCP mode
938
(and to a lesser extent, in HTTP mode), it is highly recommended that the
939
client timeout remains equal to the server timeout in order to avoid complex
940
situations to debug. It is a good practice to cover one or several TCP packet
941
losses by specifying timeouts that are slightly above multiples of 3 seconds
942
(eg: 4 or 5 seconds).
943
944
This parameter is specific to frontends, but can be specified once for all in
945
"defaults" sections. This is in fact one of the easiest solutions not to
946
forget about it. An unspecified timeout results in an infinite timeout, which
947
is not recommended. Such a usage is accepted and works but reports a warning
948
during startup because it may results in accumulation of expired sessions in
949
the system if the system's timeouts are not configured either.
950
951
This parameter is provided for compatibility but is currently deprecated.
952
Please use "timeout client" instead.
953
954
See also : "timeout client", "timeout http-request", "timeout server", and
955
"srvtimeout".
956
957
958
contimeout <timeout>
959
Set the maximum time to wait for a connection attempt to a server to succeed.
960
May be used in sections : defaults | frontend | listen | backend
961
yes | no | yes | yes
962
Arguments :
963
<timeout> is the timeout value is specified in milliseconds by default, but
964
can be in any other unit if the number is suffixed by the unit,
965
as explained at the top of this document.
966
967
If the server is located on the same LAN as haproxy, the connection should be
968
immediate (less than a few milliseconds). Anyway, it is a good practice to
969
cover one or several TCP packet losses by specifying timeouts that are
970
slightly above multiples of 3 seconds (eg: 4 or 5 seconds). By default, the
971
connect timeout also presets the queue timeout to the same value if this one
972
has not been specified. Historically, the contimeout was also used to set the
973
tarpit timeout in a listen section, which is not possible in a pure frontend.
974
975
This parameter is specific to backends, but can be specified once for all in
976
"defaults" sections. This is in fact one of the easiest solutions not to
977
forget about it. An unspecified timeout results in an infinite timeout, which
978
is not recommended. Such a usage is accepted and works but reports a warning
979
during startup because it may results in accumulation of failed sessions in
980
the system if the system's timeouts are not configured either.
981
982
This parameter is provided for backwards compatibility but is currently
983
deprecated. Please use "timeout connect", "timeout queue" or "timeout tarpit"
984
instead.
985
986
See also : "timeout connect", "timeout queue", "timeout tarpit",
987
"timeout server", "contimeout".
988
989
990
cookie <name> [ rewrite|insert|prefix ] [ indirect ] [ nocache ] [ postonly ]
991
Enable cookie-based persistence in a backend.
992
May be used in sections : defaults | frontend | listen | backend
993
yes | no | yes | yes
994
Arguments :
995
<name> is the name of the cookie which will be monitored, modified or
996
inserted in order to bring persistence. This cookie is sent to
997
the client via a "Set-Cookie" header in the response, and is
998
brought back by the client in a "Cookie" header in all requests.
999
Special care should be taken to choose a name which does not
1000
conflict with any likely application cookie. Also, if the same
1001
backends are subject to be used by the same clients (eg:
1002
HTTP/HTTPS), care should be taken to use different cookie names
1003
between all backends if persistence between them is not desired.
1004
1005
rewrite This keyword indicates that the cookie will be provided by the
1006
server and that haproxy will have to modify its value to set the
1007
server's identifier in it. This mode is handy when the management
1008
of complex combinations of "Set-cookie" and "Cache-control"
1009
headers is left to the application. The application can then
1010
decide whether or not it is appropriate to emit a persistence
1011
cookie. Since all responses should be monitored, this mode only
1012
works in HTTP close mode. Unless the application behaviour is
1013
very complex and/or broken, it is advised not to start with this
1014
mode for new deployments. This keyword is incompatible with
1015
"insert" and "prefix".
1016
1017
insert This keyword indicates that the persistence cookie will have to
1018
be inserted by haproxy in the responses. If the server emits a
1019
cookie with the same name, it will be replaced anyway. For this
1020
reason, this mode can be used to upgrade existing configurations
1021
running in the "rewrite" mode. The cookie will only be a session
1022
cookie and will not be stored on the client's disk. Due to
1023
caching effects, it is generally wise to add the "indirect" and
1024
"nocache" or "postonly" keywords (see below). The "insert"
1025
keyword is not compatible with "rewrite" and "prefix".
1026
1027
prefix This keyword indicates that instead of relying on a dedicated
1028
cookie for the persistence, an existing one will be completed.
1029
This may be needed in some specific environments where the client
1030
does not support more than one single cookie and the application
1031
already needs it. In this case, whenever the server sets a cookie
1032
named <name>, it will be prefixed with the server's identifier
1033
and a delimiter. The prefix will be removed from all client
1034
requests so that the server still finds the cookie it emitted.
1035
Since all requests and responses are subject to being modified,
1036
this mode requires the HTTP close mode. The "prefix" keyword is
1037
not compatible with "rewrite" and "insert".
1038
1039
indirect When this option is specified in insert mode, cookies will only
1040
be added when the server was not reached after a direct access,
1041
which means that only when a server is elected after applying a
1042
load-balancing algorithm, or after a redispatch, then the cookie
1043
will be inserted. If the client has all the required information
1044
to connect to the same server next time, no further cookie will
1045
be inserted. In all cases, when the "indirect" option is used in
1046
insert mode, the cookie is always removed from the requests
1047
transmitted to the server. The persistence mechanism then becomes
1048
totally transparent from the application point of view.
1049
1050
nocache This option is recommended in conjunction with the insert mode
1051
when there is a cache between the client and HAProxy, as it
1052
ensures that a cacheable response will be tagged non-cacheable if
1053
a cookie needs to be inserted. This is important because if all
1054
persistence cookies are added on a cacheable home page for
1055
instance, then all customers will then fetch the page from an
1056
outer cache and will all share the same persistence cookie,
1057
leading to one server receiving much more traffic than others.
1058
See also the "insert" and "postonly" options.
1059
1060
postonly This option ensures that cookie insertion will only be performed
1061
on responses to POST requests. It is an alternative to the
1062
"nocache" option, because POST responses are not cacheable, so
1063
this ensures that the persistence cookie will never get cached.
1064
Since most sites do not need any sort of persistence before the
1065
first POST which generally is a login request, this is a very
1066
efficient method to optimize caching without risking to find a
1067
persistence cookie in the cache.
1068
See also the "insert" and "nocache" options.
1069
1070
There can be only one persistence cookie per HTTP backend, and it can be
1071
declared in a defaults section. The value of the cookie will be the value
1072
indicated after the "cookie" keyword in a "server" statement. If no cookie
1073
is declared for a given server, the cookie is not set.
1074
1075
Examples :
1076
cookie JSESSIONID prefix
1077
cookie SRV insert indirect nocache
1078
cookie SRV insert postonly indirect
1079
1080
See also : "appsession", "balance source", "capture cookie", "server".
1081
1082
1083
default_backend <backend>
1084
Specify the backend to use when no "use_backend" rule has been matched.
1085
May be used in sections : defaults | frontend | listen | backend
1086
yes | yes | yes | no
1087
Arguments :
1088
<backend> is the name of the backend to use.
1089
1090
When doing content-switching between frontend and backends using the
1091
"use_backend" keyword, it is often useful to indicate which backend will be
1092
used when no rule has matched. It generally is the dynamic backend which
1093
will catch all undetermined requests.
1094
1095
The "default_backend" keyword is also supported in TCP mode frontends to
1096
facilitate the ordering of configurations in frontends and backends,
1097
eventhough it does not make much more sense in case of TCP due to the fact
1098
that use_backend currently does not work in TCP mode.
1099
1100
Example :
1101
1102
use_backend dynamic if url_dyn
1103
use_backend static if url_css url_img extension_img
1104
default_backend dynamic
1105
1106
See also : "use_backend", "reqsetbe", "reqisetbe"
1107
1108
1109
disabled
1110
Disable a proxy, frontend or backend.
1111
May be used in sections : defaults | frontend | listen | backend
1112
yes | yes | yes | yes
1113
Arguments : none
1114
1115
The "disabled" keyword is used to disable an instance, mainly in order to
1116
liberate a listening port or to temporarily disable a service. The instance
1117
will still be created and its configuration will be checked, but it will be
1118
created in the "stopped" state and will appear as such in the statistics. It
1119
will not receive any traffic nor will it send any health-checks or logs. It
1120
is possible to disable many instances at once by adding the "disabled"
1121
keyword in a "defaults" section.
1122
1123
See also : "enabled"
1124
1125
1126
enabled
1127
Enable a proxy, frontend or backend.
1128
May be used in sections : defaults | frontend | listen | backend
1129
yes | yes | yes | yes
1130
Arguments : none
1131
1132
The "enabled" keyword is used to explicitly enable an instance, when the
1133
defaults has been set to "disabled". This is very rarely used.
1134
1135
See also : "disabled"
1136
1137
1138
errorfile <code> <file>
1139
Return a file contents instead of errors generated by HAProxy
1140
May be used in sections : defaults | frontend | listen | backend
1141
yes | yes | yes | yes
1142
Arguments :
1143
<code> is the HTTP status code. Currently, HAProxy is capable of
1144
generating codes 400, 403, 408, 500, 502, 503, and 504.
1145
1146
<file> designates a file containing the full HTTP response. It is
1147
recommended to follow the common practice of appending ".http" to
1148
the filename so that people do not confuse the response with HTML
1149
error pages.
1150
1151
It is important to understand that this keyword is not meant to rewrite
1152
errors returned by the server, but errors detected and returned by HAProxy.
1153
This is why the list of supported errors is limited to a small set.
1154
1155
The files are returned verbatim on the TCP socket. This allows any trick such
1156
as redirections to another URL or site, as well as tricks to clean cookies,
1157
force enable or disable caching, etc... The package provides default error
1158
files returning the same contents as default errors.
1159
1160
The files are read at the same time as the configuration and kept in memory.
1161
For this reason, the errors continue to be returned even when the process is
1162
chrooted, and no file change is considered while the process is running. A
1163
simple method for developing those files consists in associating them to the
1164
403 status code and interrogating a blocked URL.
1165
1166
See also : "errorloc", "errorloc302", "errorloc303"
1167
1168
1169
errorloc <code> <url>
1170
errorloc302 <code> <url>
1171
Return an HTTP redirection to a URL instead of errors generated by HAProxy
1172
May be used in sections : defaults | frontend | listen | backend
1173
yes | yes | yes | yes
1174
Arguments :
1175
<code> is the HTTP status code. Currently, HAProxy is capable of
1176
generating codes 400, 403, 408, 500, 502, 503, and 504.
1177
1178
<url> it is the exact contents of the "Location" header. It may contain
1179
either a relative URI to an error page hosted on the same site,
1180
or an absolute URI designating an error page on another site.
1181
Special care should be given to relative URIs to avoid redirect
1182
loops if the URI itself may generate the same error (eg: 500).
1183
1184
It is important to understand that this keyword is not meant to rewrite
1185
errors returned by the server, but errors detected and returned by HAProxy.
1186
This is why the list of supported errors is limited to a small set.
1187
1188
Note that both keyword return the HTTP 302 status code, which tells the
1189
client to fetch the designated URL using the same HTTP method. This can be
1190
quite problematic in case of non-GET methods such as POST, because the URL
1191
sent to the client might not be allowed for something other than GET. To
1192
workaround this problem, please use "errorloc303" which send the HTTP 303
1193
status code, indicating to the client that the URL must be fetched with a GET
1194
request.
1195
1196
See also : "errorfile", "errorloc303"
1197
1198
1199
errorloc303 <code> <url>
1200
Return an HTTP redirection to a URL instead of errors generated by HAProxy
1201
May be used in sections : defaults | frontend | listen | backend
1202
yes | yes | yes | yes
1203
Arguments :
1204
<code> is the HTTP status code. Currently, HAProxy is capable of
1205
generating codes 400, 403, 408, 500, 502, 503, and 504.
1206
1207
<url> it is the exact contents of the "Location" header. It may contain
1208
either a relative URI to an error page hosted on the same site,
1209
or an absolute URI designating an error page on another site.
1210
Special care should be given to relative URIs to avoid redirect
1211
loops if the URI itself may generate the same error (eg: 500).
1212
1213
It is important to understand that this keyword is not meant to rewrite
1214
errors returned by the server, but errors detected and returned by HAProxy.
1215
This is why the list of supported errors is limited to a small set.
1216
1217
Note that both keyword return the HTTP 303 status code, which tells the
1218
client to fetch the designated URL using the same HTTP GET method. This
1219
solves the usual problems associated with "errorloc" and the 302 code. It is
1220
possible that some very old browsers designed before HTTP/1.1 do not support
1221
it, but no such problem has been reported till now.
1222
1223
See also : "errorfile", "errorloc", "errorloc302"
1224
1225
1226
fullconn <conns>
1227
Specify at what backend load the servers will reach their maxconn
1228
May be used in sections : defaults | frontend | listen | backend
1229
yes | no | yes | yes
1230
Arguments :
1231
<conns> is the number of connections on the backend which will make the
1232
servers use the maximal number of connections.
1233
1234
When a server has a "maxconn" parameter specified, it means that its number
1235
of concurrent connections will never go higher. Additionally, if it has a
1236
"minconn" parameter, it indicates a dynamic limit following the backend's
1237
load. The server will then always accept at least <minconn> connections,
1238
never more than <maxconn>, and the limit will be on the ramp between both
1239
values when the backend has less than <conns> concurrent connections. This
1240
makes it possible to limit the load on the servers during normal loads, but
1241
push it further for important loads without overloading the servers during
1242
exceptionnal loads.
1243
1244
Example :
1245
# The servers will accept between 100 and 1000 concurrent connections each
1246
# and the maximum of 1000 will be reached when the backend reaches 10000
1247
# connections.
1248
backend dynamic
1249
fullconn 10000
1250
server srv1 dyn1:80 minconn 100 maxconn 1000
1251
server srv2 dyn2:80 minconn 100 maxconn 1000
1252
1253
See also : "maxconn", "server"
1254
1255
1256
grace <time>
1257
Maintain a proxy operational for some time after a soft stop
1258
May be used in sections : defaults | frontend | listen | backend
1259
no | yes | yes | yes
1260
Arguments :
1261
<time> is the time (by default in milliseconds) for which the instance
1262
will remain operational with the frontend sockets still listening
1263
when a soft-stop is received via the SIGUSR1 signal.
1264
1265
This may be used to ensure that the services disappear in a certain order.
1266
This was designed so that frontends which are dedicated to monitoring by an
1267
external equipement fail immediately while other ones remain up for the time
1268
needed by the equipment to detect the failure.
1269
1270
Note that currently, there is very little benefit in using this parameter,
1271
and it may in fact complicate the soft-reconfiguration process more than
1272
simplify it.
1273
1274
1275
http-check disable-on-404
1276
Enable a maintenance mode upon HTTP/404 response to health-checks
1277
May be used in sections : defaults | frontend | listen | backend
1278
yes | no | yes | yes
1279
Arguments : none
1280
1281
When this option is set, a server which returns an HTTP code 404 will be
1282
excluded from further load-balancing, but will still receive persistent
1283
connections. This provides a very convenient method for Web administrators
1284
to perform a graceful shutdown of their servers. It is also important to note
1285
that a server which is detected as failed while it was in this mode will not
1286
generate an alert, just a notice. If the server responds 2xx or 3xx again, it
1287
will immediately be reinserted into the farm. The status on the stats page
1288
reports "NOLB" for a server in this mode. It is important to note that this
1289
option only works in conjunction with the "httpchk" option.
1290
1291
See also : "option httpchk"
1292
1293
1294
log global
1295
log <address> <facility> [<level>]
1296
Enable per-instance logging of events and traffic.
1297
May be used in sections : defaults | frontend | listen | backend
1298
yes | yes | yes | yes
1299
Arguments :
1300
global should be used when the instance's logging parameters are the
1301
same as the global ones. This is the most common usage. "global"
1302
replaces <address>, <facility> and <level> with those of the log
1303
entries found in the "global" section. Only one "log global"
1304
statement may be used per instance, and this form takes no other
1305
parameter.
1306
1307
<address> indicates where to send the logs. It takes the same format as
1308
for the "global" section's logs, and can be one of :
1309
1310
- An IPv4 address optionally followed by a colon (':') and a UDP
1311
port. If no port is specified, 514 is used by default (the
1312
standard syslog port).
1313
1314
- A filesystem path to a UNIX domain socket, keeping in mind
1315
considerations for chroot (be sure the path is accessible
1316
inside the chroot) and uid/gid (be sure the path is
1317
appropriately writeable).
1318
1319
<facility> must be one of the 24 standard syslog facilities :
1320
1321
kern user mail daemon auth syslog lpr news
1322
uucp cron auth2 ftp ntp audit alert cron2
1323
local0 local1 local2 local3 local4 local5 local6 local7
1324
1325
<level> is optional and can be specified to filter outgoing messages. By
1326
default, all messages are sent. If a level is specified, only
1327
messages with a severity at least as important as this level
1328
will be sent. 8 levels are known :
1329
1330
emerg alert crit err warning notice info debug
1331
1332
Note that up to two "log" entries may be specified per instance. However, if
1333
"log global" is used and if the "global" section already contains 2 log
1334
entries, then additional log entries will be ignored.
1335
1336
Also, it is important to keep in mind that it is the frontend which decides
1337
what to log, and that in case of content switching, the log entries from the
1338
backend will be ignored.
1339
1340
Example :
1341
log global
1342
log 127.0.0.1:514 local0 notice
1343
1344
1345
maxconn <conns>
1346
Fix the maximum number of concurrent connections on a frontend
1347
May be used in sections : defaults | frontend | listen | backend
1348
yes | yes | yes | no
1349
Arguments :
1350
<conns> is the maximum number of concurrent connections the frontend will
1351
accept to serve. Excess connections will be queued by the system
1352
in the socket's listen queue and will be served once a connection
1353
closes.
1354
1355
If the system supports it, it can be useful on big sites to raise this limit
1356
very high so that haproxy manages connection queues, instead of leaving the
1357
clients with unanswered connection attempts. This value should not exceed the
1358
global maxconn. Also, keep in mind that a connection contains two buffers
1359
of 8kB each, as well as some other data resulting in about 17 kB of RAM being
1360
consumed per established connection. That means that a medium system equipped
1361
with 1GB of RAM can withstand around 40000-50000 concurrent connections if
1362
properly tuned.
1363
1364
Also, when <conns> is set to large values, it is possible that the servers
1365
are not sized to accept such loads, and for this reason it is generally wise
1366
to assign them some reasonable connection limits.
1367
1368
See also : "server", global section's "maxconn", "fullconn"
1369
1370
1371
mode { tcp|http|health }
1372
Set the running mode or protocol of the instance
1373
May be used in sections : defaults | frontend | listen | backend
1374
yes | yes | yes | yes
1375
Arguments :
1376
tcp The instance will work in pure TCP mode. A full-duplex connection
1377
will be established between clients and servers, and no layer 7
1378
examination will be performed. This is the default mode. It
1379
should be used for SSL, SSH, SMTP, ...
1380
1381
http The instance will work in HTTP mode. The client request will be
1382
analyzed in depth before connecting to any server. Any request
1383
which is not RFC-compliant will be rejected. Layer 7 filtering,
1384
processing and switching will be possible. This is the mode which
1385
brings HAProxy most of its value.
1386
1387
health The instance will work in "health" mode. It will just reply "OK"
1388
to incoming connections and close the connection. Nothing will be
1389
logged. This mode is used to reply to external components health
1390
checks. This mode is deprecated and should not be used anymore as
1391
it is possible to do the same and even better by combining TCP or
1392
HTTP modes with the "monitor" keyword.
1393
1394
When doing content switching, it is mandatory that the frontend and the
1395
backend are in the same mode (generally HTTP), otherwise the configuration
1396
will be refused.
1397
1398
Example :
1399
defaults http_instances
1400
mode http
1401
1402
See also : "monitor", "monitor-net"
1403
1404
1405
monitor fail [if | unless] <condition>
1406
Add a condition to report a failure to a monitor HTTP request.
1407
May be used in sections : defaults | frontend | listen | backend
1408
no | yes | yes | no
1409
Arguments :
1410
if <cond> the monitor request will fail if the condition is satisfied,
1411
and will succeed otherwise. The condition should describe a
1412
combinated test which must induce a failure if all conditions
1413
are met, for instance a low number of servers both in a
1414
backend and its backup.
1415
1416
unless <cond> the monitor request will succeed only if the condition is
1417
satisfied, and will fail otherwise. Such a condition may be
1418
based on a test on the presence of a minimum number of active
1419
servers in a list of backends.
1420
1421
This statement adds a condition which can force the response to a monitor
1422
request to report a failure. By default, when an external component queries
1423
the URI dedicated to monitoring, a 200 response is returned. When one of the
1424
conditions above is met, haproxy will return 503 instead of 200. This is
1425
very useful to report a site failure to an external component which may base
1426
routing advertisements between multiple sites on the availability reported by
1427
haproxy. In this case, one would rely on an ACL involving the "nbsrv"
1428
criterion. Note that "monitor fail" only works in HTTP mode.
1429
1430
Example:
1431
frontend www
1432
mode http
1433
acl site_dead nbsrv(dynamic) lt 2
1434
acl site_dead nbsrv(static) lt 2
1435
monitor-uri /site_alive
1436
monitor fail if site_dead
1437
1438
See also : "monitor-net", "monitor-uri"
1439
1440
1441
monitor-net <source>
1442
Declare a source network which is limited to monitor requests
1443
May be used in sections : defaults | frontend | listen | backend
1444
yes | yes | yes | no
1445
Arguments :
1446
<source> is the source IPv4 address or network which will only be able to
1447
get monitor responses to any request. It can be either an IPv4
1448
address, a host name, or an address followed by a slash ('/')
1449
followed by a mask.
1450
1451
In TCP mode, any connection coming from a source matching <source> will cause
1452
the connection to be immediately closed without any log. This allows another
1453
equipement to probe the port and verify that it is still listening, without
1454
forwarding the connection to a remote server.
1455
1456
In HTTP mode, a connection coming from a source matching <source> will be
1457
accepted, the following response will be sent without waiting for a request,
1458
then the connection will be closed : "HTTP/1.0 200 OK". This is normally
1459
enough for any front-end HTTP probe to detect that the service is UP and
1460
running without forwarding the request to a backend server.
1461
1462
Monitor requests are processed very early. It is not possible to block nor
1463
divert them using ACLs. They cannot be logged either, and it is the intended
1464
purpose. They are only used to report HAProxy's health to an upper component,
1465
nothing more. Right now, it is not possible to set failure conditions on
1466
requests caught by "monitor-net".
1467
1468
Example :
1469
# addresses .252 and .253 are just probing us.
1470
frontend www
1471
monitor-net 192.168.0.252/31
1472
1473
See also : "monitor fail", "monitor-uri"
1474
1475
1476
monitor-uri <uri>
1477
Intercept a URI used by external components' monitor requests
1478
May be used in sections : defaults | frontend | listen | backend
1479
yes | yes | yes | no
1480
Arguments :
1481
<uri> is the exact URI which we want to intercept to return HAProxy's
1482
health status instead of forwarding the request.
1483
1484
When an HTTP request referencing <uri> will be received on a frontend,
1485
HAProxy will not forward it nor log it, but instead will return either
1486
"HTTP/1.0 200 OK" or "HTTP/1.0 503 Service unavailable", depending on failure
1487
conditions defined with "monitor fail". This is normally enough for any
1488
front-end HTTP probe to detect that the service is UP and running without
1489
forwarding the request to a backend server. Note that the HTTP method, the
1490
version and all headers are ignored, but the request must at least be valid
1491
at the HTTP level. This keyword may only be used with an HTTP-mode frontend.
1492
1493
Monitor requests are processed very early. It is not possible to block nor
1494
divert them using ACLs. They cannot be logged either, and it is the intended
1495
purpose. They are only used to report HAProxy's health to an upper component,
1496
nothing more. However, it is possible to add any number of conditions using
1497
"monitor fail" and ACLs so that the result can be adjusted to whatever check
1498
can be imagined (most often the number of available servers in a backend).
1499
1500
Example :
1501
# Use /haproxy_test to report haproxy's status
1502
frontend www
1503
mode http
1504
monitor-uri /haproxy_test
1505
1506
See also : "monitor fail", "monitor-net"
1507
1508
1509
option abortonclose
1510
no option abortonclose
1511
Enable or disable early dropping of aborted requests pending in queues.
1512
May be used in sections : defaults | frontend | listen | backend
1513
yes | no | yes | yes
1514
Arguments : none
1515
1516
In presence of very high loads, the servers will take some time to respond.
1517
The per-instance connection queue will inflate, and the response time will
1518
increase respective to the size of the queue times the average per-session
1519
response time. When clients will wait for more than a few seconds, they will
1520
often hit the "STOP" button on their browser, leaving a useless request in
1521
the queue, and slowing down other users, and the servers as well, because the
1522
request will eventually be served, then aborted at the first error
1523
encountered while delivering the response.
1524
1525
As there is no way to distinguish between a full STOP and a simple output
1526
close on the client side, HTTP agents should be conservative and consider
1527
that the client might only have closed its output channel while waiting for
1528
the response. However, this introduces risks of congestion when lots of users
1529
do the same, and is completely useless nowadays because probably no client at
1530
all will close the session while waiting for the response. Some HTTP agents
1531
support this behaviour (Squid, Apache, HAProxy), and others do not (TUX, most
1532
hardware-based load balancers). So the probability for a closed input channel
1533
to represent a user hitting the "STOP" button is close to 100%, and the risk
1534
of being the single component to break rare but valid traffic is extremely
1535
low, which adds to the temptation to be able to abort a session early while
1536
still not served and not pollute the servers.
1537
1538
In HAProxy, the user can choose the desired behaviour using the option
1539
"abortonclose". By default (without the option) the behaviour is HTTP
1540
compliant and aborted requests will be served. But when the option is
1541
specified, a session with an incoming channel closed will be aborted while
1542
it is still possible, either pending in the queue for a connection slot, or
1543
during the connection establishment if the server has not yet acknowledged
1544
the connection request. This considerably reduces the queue size and the load
1545
on saturated servers when users are tempted to click on STOP, which in turn
1546
reduces the response time for other users.
1547
1548
If this option has been enabled in a "defaults" section, it can be disabled
1549
in a specific instance by prepending the "no" keyword before it.
1550
1551
See also : "timeout queue" and server's "maxconn" and "maxqueue" parameters
1552
1553
1554
option allbackups
1555
no option allbackups
1556
Use either all backup servers at a time or only the first one
1557
May be used in sections : defaults | frontend | listen | backend
1558
yes | no | yes | yes
1559
Arguments : none
1560
1561
By default, the first operational backup server gets all traffic when normal
1562
servers are all down. Sometimes, it may be preferred to use multiple backups
1563
at once, because one will not be enough. When "option allbackups" is enabled,
1564
the load balancing will be performed among all backup servers when all normal
1565
ones are unavailable. The same load balancing algorithm will be used and the
1566
servers' weights will be respected. Thus, there will not be any priority
1567
order between the backup servers anymore.
1568
1569
This option is mostly used with static server farms dedicated to return a
1570
"sorry" page when an application is completely offline.
1571
1572
If this option has been enabled in a "defaults" section, it can be disabled
1573
in a specific instance by prepending the "no" keyword before it.
1574
1575
1576
option checkcache
1577
no option checkcache
1578
Analyze all server responses and block requests with cachable cookies
1579
May be used in sections : defaults | frontend | listen | backend
1580
yes | no | yes | yes
1581
Arguments : none
1582
1583
Some high-level frameworks set application cookies everywhere and do not
1584
always let enough control to the developer to manage how the responses should
1585
be cached. When a session cookie is returned on a cachable object, there is a
1586
high risk of session crossing or stealing between users traversing the same
1587
caches. In some situations, it is better to block the response than to let
1588
some sensible session information go in the wild.
1589
1590
The option "checkcache" enables deep inspection of all server responses for
1591
strict compliance with HTTP specification in terms of cachability. It
1592
carefully checks "Cache-control", "Pragma" and "Set-cookie" headers in server
1593
response to check if there's a risk of caching a cookie on a client-side
1594
proxy. When this option is enabled, the only responses which can be delivered
1595
to the client are :
1596
- all those without "Set-Cookie" header ;
1597
- all those with a return code other than 200, 203, 206, 300, 301, 410,
1598
provided that the server has not set a "Cache-control: public" header ;
1599
- all those that come from a POST request, provided that the server has not
1600
set a 'Cache-Control: public' header ;
1601
- those with a 'Pragma: no-cache' header
1602
- those with a 'Cache-control: private' header
1603
- those with a 'Cache-control: no-store' header
1604
- those with a 'Cache-control: max-age=0' header
1605
- those with a 'Cache-control: s-maxage=0' header
1606
- those with a 'Cache-control: no-cache' header
1607
- those with a 'Cache-control: no-cache="set-cookie"' header
1608
- those with a 'Cache-control: no-cache="set-cookie,' header
1609
(allowing other fields after set-cookie)
1610
1611
If a response doesn't respect these requirements, then it will be blocked
1612
just as if it was from an "rspdeny" filter, with an "HTTP 502 bad gateway".
1613
The session state shows "PH--" meaning that the proxy blocked the response
1614
during headers processing. Additionnaly, an alert will be sent in the logs so
1615
that admins are informed that there's something to be fixed.
1616
1617
Due to the high impact on the application, the application should be tested
1618
in depth with the option enabled before going to production. It is also a
1619
good practice to always activate it during tests, even if it is not used in
1620
production, as it will report potentially dangerous application behaviours.
1621
1622
If this option has been enabled in a "defaults" section, it can be disabled
1623
in a specific instance by prepending the "no" keyword before it.
1624
1625
1626
option clitcpka
1627
no option clitcpka
1628
Enable or disable the sending of TCP keepalive packets on the client side
1629
May be used in sections : defaults | frontend | listen | backend
1630
yes | yes | yes | no
1631
Arguments : none
1632
1633
When there is a firewall or any session-aware component between a client and
1634
a server, and when the protocol involves very long sessions with long idle
1635
periods (eg: remote desktops), there is a risk that one of the intermediate
1636
components decides to expire a session which has remained idle for too long.
1637
1638
Enabling socket-level TCP keep-alives makes the system regularly send packets
1639
to the other end of the connection, leaving it active. The delay between
1640
keep-alive probes is controlled by the system only and depends both on the
1641
operating system and its tuning parameters.
1642
1643
It is important to understand that keep-alive packets are neither emitted nor
1644
received at the application level. It is only the network stacks which sees
1645
them. For this reason, even if one side of the proxy already uses keep-alives
1646
to maintain its connection alive, those keep-alive packets will not be
1647
forwarded to the other side of the proxy.
1648
1649
Please note that this has nothing to do with HTTP keep-alive.
1650
1651
Using option "clitcpka" enables the emission of TCP keep-alive probes on the
1652
client side of a connection, which should help when session expirations are
1653
noticed between HAProxy and a client.
1654
1655
If this option has been enabled in a "defaults" section, it can be disabled
1656
in a specific instance by prepending the "no" keyword before it.
1657
1658
See also : "option srvtcpka", "option tcpka"
1659
1660
1661
option contstats
1662
Enable continuous traffic statistics updates
1663
May be used in sections : defaults | frontend | listen | backend
1664
yes | yes | yes | no
1665
Arguments : none
1666
1667
By default, counters used for statistics calculation are incremented
1668
only when a session finishes. It works quite well when serving small
1669
objects, but with big ones (for example large images or archives) or
1670
with A/V streaming, a graph generated from haproxy counters looks like
1671
a hedgehog. With this option enabled counters get incremented continuously,
1672
during a whole session. Recounting touches a hotpath directly so
1673
it is not enabled by default, as it has small performance impact (~0.5%).
1674
1675
1676
option dontlognull
1677
no option dontlognull
1678
Enable or disable logging of null connections
1679
May be used in sections : defaults | frontend | listen | backend
1680
yes | yes | yes | no
1681
Arguments : none
1682
1683
In certain environments, there are components which will regularly connect to
1684
various systems to ensure that they are still alive. It can be the case from
1685
another load balancer as well as from monitoring systems. By default, even a
1686
simple port probe or scan will produce a log. If those connections pollute
1687
the logs too much, it is possible to enable option "dontlognull" to indicate
1688
that a connection on which no data has been transferred will not be logged,
1689
which typically corresponds to those probes.
1690
1691
It is generally recommended not to use this option in uncontrolled
1692
environments (eg: internet), otherwise scans and other malicious activities
1693
would not be logged.
1694
1695
If this option has been enabled in a "defaults" section, it can be disabled
1696
in a specific instance by prepending the "no" keyword before it.
1697
1698
See also : "log", "monitor-net", "monitor-uri" and section 2.6 about logging.
1699
1700
1701
option forceclose
1702
no option forceclose
1703
Enable or disable active connection closing after response is transferred.
1704
May be used in sections : defaults | frontend | listen | backend
1705
yes | no | yes | yes
1706
Arguments : none
1707
1708
Some HTTP servers do not necessarily close the connections when they receive
1709
the "Connection: close" set by "option httpclose", and if the client does not
1710
close either, then the connection remains open till the timeout expires. This
1711
causes high number of simultaneous connections on the servers and shows high
1712
global session times in the logs.
1713
1714
When this happens, it is possible to use "option forceclose". It will
1715
actively close the outgoing server channel as soon as the server begins to
1716
reply and only if the request buffer is empty. Note that this should NOT be
1717
used if CONNECT requests are expected between the client and the server. This
1718
option implicitly enables the "httpclose" option.
1719
1720
If this option has been enabled in a "defaults" section, it can be disabled
1721
in a specific instance by prepending the "no" keyword before it.
1722
1723
See also : "option httpclose"
1724
1725
1726
option forwardfor [ except <network> ]
1727
Enable insertion of the X-Forwarded-For header to requests sent to servers
1728
May be used in sections : defaults | frontend | listen | backend
1729
yes | yes | yes | yes
1730
Arguments :
1731
<network> is an optional argument used to disable this option for sources
1732
matching <network>
1733
1734
Since HAProxy works in reverse-proxy mode, the servers see its IP address as
1735
their client address. This is sometimes annoying when the client's IP address
1736
is expected in server logs. To solve this problem, the well-known HTTP header
1737
"X-Forwarded-For" may be added by HAProxy to all requests sent to the server.
1738
This header contains a value representing the client's IP address. Since this
1739
header is always appended at the end of the existing header list, the server
1740
must be configured to always use the last occurrence of this header only. See
1741
the server's manual to find how to enable use of this standard header.
1742
1743
Sometimes, a same HAProxy instance may be shared between a direct client
1744
access and a reverse-proxy access (for instance when an SSL reverse-proxy is
1745
used to decrypt HTTPS traffic). It is possible to disable the addition of the
1746
header for a known source address or network by adding the "except" keyword
1747
followed by the network address. In this case, any source IP matching the
1748
network will not cause an addition of this header. Most common uses are with
1749
private networks or 127.0.0.1.
1750
1751
This option may be specified either in the frontend or in the backend. If at
1752
least one of them uses it, the header will be added.
1753
1754
It is important to note that as long as HAProxy does not support keep-alive
1755
connections, only the first request of a connection will receive the header.
1756
For this reason, it is important to ensure that "option httpclose" is set
1757
when using this option.
1758
1759
Example :
1760
# Public HTTP address also used by stunnel on the same machine
1761
frontend www
1762
mode http
1763
option forwardfor except 127.0.0.1 # stunnel already adds the header
1764
1765
See also : "option httpclose"
1766
1767
1768
option http_proxy
1769
no option http_proxy
1770
Enable or disable plain HTTP proxy mode
1771
May be used in sections : defaults | frontend | listen | backend
1772
yes | yes | yes | yes
1773
Arguments : none
1774
1775
It sometimes happens that people need a pure HTTP proxy which understands
1776
basic proxy requests without caching nor any fancy feature. In this case,
1777
it may be worth setting up an HAProxy instance with the "option http_proxy"
1778
set. In this mode, no server is declared, and the connection is forwarded to
1779
the IP address and port found in the URL after the "http://" scheme.
1780
1781
No host address resolution is performed, so this only works when pure IP
1782
addresses are passed. Since this option's usage perimeter is rather limited,
1783
it will probably be used only by experts who know they need exactly it. Last,
1784
if the clients are susceptible of sending keep-alive requests, it will be
1785
needed to add "option http_close" to ensure that all requests will correctly
1786
be analyzed.
1787
1788
If this option has been enabled in a "defaults" section, it can be disabled
1789
in a specific instance by prepending the "no" keyword before it.
1790
1791
Example :
1792
# this backend understands HTTP proxy requests and forwards them directly.
1793
backend direct_forward
1794
option httpclose
1795
option http_proxy
1796
1797
See also : "option httpclose"
1798
1799
1800
option httpchk
1801
option httpchk <uri>
1802
option httpchk <method> <uri>
1803
option httpchk <method> <uri> <version>
1804
Enable HTTP protocol to check on the servers health
1805
May be used in sections : defaults | frontend | listen | backend
1806
yes | no | yes | yes
1807
Arguments :
1808
<method> is the optional HTTP method used with the requests. When not set,
1809
the "OPTIONS" method is used, as it generally requires low server
1810
processing and is easy to filter out from the logs. Any method
1811
may be used, though it is not recommended to invent non-standard
1812
ones.
1813
1814
<uri> is the URI referenced in the HTTP requests. It defaults to " / "
1815
which is accessible by default on almost any server, but may be
1816
changed to any other URI. Query strings are permitted.
1817
1818
<version> is the optional HTTP version string. It defaults to "HTTP/1.0"
1819
but some servers might behave incorrectly in HTTP 1.0, so turning
1820
it to HTTP/1.1 may sometimes help. Note that the Host field is
1821
mandatory in HTTP/1.1, and as a trick, it is possible to pass it
1822
after "\r\n" following the version string.
1823
1824
By default, server health checks only consist in trying to establish a TCP
1825
connection. When "option httpchk" is specified, a complete HTTP request is
1826
sent once the TCP connection is established, and responses 2xx and 3xx are
1827
considered valid, while all other ones indicate a server failure, including
1828
the lack of any response.
1829
1830
The port and interval are specified in the server configuration.
1831
1832
This option does not necessarily require an HTTP backend, it also works with
1833
plain TCP backends. This is particularly useful to check simple scripts bound
1834
to some dedicated ports using the inetd daemon.
1835
1836
Examples :
1837
# Relay HTTPS traffic to Apache instance and check service availability
1838
# using HTTP request "OPTIONS * HTTP/1.1" on port 80.
1839
backend https_relay
1840
mode tcp
1841
option httpchk OPTIONS * HTTP/1.1\r\nHost: www
1842
server apache1 192.168.1.1:443 check port 80
1843
1844
See also : "option ssl-hello-chk", "option smtpchk", "http-check" and the
1845
"check", "port" and "interval" server options.
1846
1847
1848
option httpclose
1849
no option httpclose
1850
Enable or disable passive HTTP connection closing
1851
May be used in sections : defaults | frontend | listen | backend
1852
yes | yes | yes | yes
1853
Arguments : none
1854
1855
As stated in section 2.1, HAProxy does not yes support the HTTP keep-alive
1856
mode. So by default, if a client communicates with a server in this mode, it
1857
will only analyze, log, and process the first request of each connection. To
1858
workaround this limitation, it is possible to specify "option httpclose". It
1859
will check if a "Connection: close" header is already set in each direction,
1860
and will add one if missing. Each end should react to this by actively
1861
closing the TCP connection after each transfer, thus resulting in a switch to
1862
the HTTP close mode. Any "Connection" header different from "close" will also
1863
be removed.
1864
1865
It seldom happens that some servers incorrectly ignore this header and do not
1866
close the connection eventough they reply "Connection: close". For this
1867
reason, they are not compatible with older HTTP 1.0 browsers. If this
1868
happens it is possible to use the "option forceclose" which actively closes
1869
the request connection once the server responds.
1870
1871
This option may be set both in a frontend and in a backend. It is enabled if
1872
at least one of the frontend or backend holding a connection has it enabled.
1873
If "option forceclose" is specified too, it has precedence over "httpclose".
1874
1875
If this option has been enabled in a "defaults" section, it can be disabled
1876
in a specific instance by prepending the "no" keyword before it.
1877
1878
See also : "option forceclose"
1879
1880
1881
option httplog
1882
Enable logging of HTTP request, session state and timers
1883
May be used in sections : defaults | frontend | listen | backend
1884
yes | yes | yes | yes
1885
Arguments : none
1886
1887
By default, the log output format is very poor, as it only contains the
1888
source and destination addresses, and the instance name. By specifying
1889
"option httplog", each log line turns into a much richer format including,
1890
but not limited to, the HTTP request, the connection timers, the session
1891
status, the connections numbers, the captured headers and cookies, the
1892
frontend, backend and server name, and of course the source address and
1893
ports.
1894
1895
This option may be set either in the frontend or the backend.
1896
1897
See also : section 2.6 about logging.
1898
1899
1900
option logasap
1901
no option logasap
1902
Enable or disable early logging of HTTP requests
1903
May be used in sections : defaults | frontend | listen | backend
1904
yes | yes | yes | no
1905
Arguments : none
1906
1907
By default, HTTP requests are logged upon termination so that the total
1908
transfer time and the number of bytes appear in the logs. When large objects
1909
are being transferred, it may take a while before the request appears in the
1910
logs. Using "option logasap", the request gets logged as soon as the server
1911
sends the complete headers. The only missing information in the logs will be
1912
the total number of bytes which will indicate everything except the amount
1913
of data transferred, and the total time which will not take the transfer
1914
time into account. In such a situation, it's a good practice to capture the
1915
"Content-Length" response header so that the logs at least indicate how many
1916
bytes are expected to be transferred.
1917
1918
See also : "option httplog", "capture response header", and section 2.6 about
1919
logging.
1920
1921
1922
option nolinger
1923
no option nolinger
1924
Enable or disable immediate session ressource cleaning after close
1925
May be used in sections: defaults | frontend | listen | backend
1926
yes | yes | yes | yes
1927
Arguments : none
1928
1929
When clients or servers abort connections in a dirty way (eg: they are
1930
physically disconnected), the session timeouts triggers and the session is
1931
closed. But it will remain in FIN_WAIT1 state for some time in the system,
1932
using some resources and possibly limiting the ability to establish newer
1933
connections.
1934
1935
When this happens, it is possible to activate "option nolinger" which forces
1936
the system to immediately remove any socket's pending data on close. Thus,
1937
the session is instantly purged from the system's tables. This usually has
1938
side effects such as increased number of TCP resets due to old retransmits
1939
getting immediately rejected. Some firewalls may sometimes complain about
1940
this too.
1941
1942
For this reason, it is not recommended to use this option when not absolutely
1943
needed. You know that you need it when you have thousands of FIN_WAIT1
1944
sessions on your system (TIME_WAIT ones do not count).
1945
1946
This option may be used both on frontends and backends, depending on the side
1947
where it is required. Use it on the frontend for clients, and on the backend
1948
for servers.
1949
1950
If this option has been enabled in a "defaults" section, it can be disabled
1951
in a specific instance by prepending the "no" keyword before it.
1952
1953
1954
option persist
1955
no option persist
1956
Enable or disable forced persistence on down servers
1957
May be used in sections: defaults | frontend | listen | backend
1958
yes | no | yes | yes
1959
Arguments : none
1960
1961
When an HTTP request reaches a backend with a cookie which references a dead
1962
server, by default it is redispatched to another server. It is possible to
1963
force the request to be sent to the dead server first using "option persist"
1964
if absolutely needed. A common use case is when servers are under extreme
1965
load and spend their time flapping. In this case, the users would still be
1966
directed to the server they opened the session on, in the hope they would be
1967
correctly served. It is recommended to use "option redispatch" in conjunction
1968
with this option so that in the event it would not be possible to connect to
1969
the server at all (server definitely dead), the client would finally be
1970
redirected to another valid server.
1971
1972
If this option has been enabled in a "defaults" section, it can be disabled
1973
in a specific instance by prepending the "no" keyword before it.
1974
1975
See also : "option redispatch", "retries"
1976
1977
1978
option redispatch
1979
no option redispatch
1980
Enable or disable session redistribution in case of connection failure
1981
May be used in sections: defaults | frontend | listen | backend
1982
yes | no | yes | yes
1983
Arguments : none
1984
1985
In HTTP mode, if a server designated by a cookie is down, clients may
1986
definitely stick to it because they cannot flush the cookie, so they will not
1987
be able to access the service anymore.
1988
1989
Specifying "option redispatch" will allow the proxy to break their
1990
persistence and redistribute them to a working server.
1991
1992
It also allows to retry last connection to another server in case of multiple
1993
connection failures. Of course, it requires having "retries" set to a nonzero
1994
value.
1995
1996
This form is the preferred form, which replaces both the "redispatch" and
1997
"redisp" keywords.
1998
1999
If this option has been enabled in a "defaults" section, it can be disabled
2000
in a specific instance by prepending the "no" keyword before it.
2001
2002
See also : "redispatch", "retries"
2003
2004
2005
option smtpchk
2006
option smtpchk <hello> <domain>
2007
Use SMTP health checks for server testing
2008
May be used in sections : defaults | frontend | listen | backend
2009
yes | no | yes | yes
2010
Arguments :
2011
<hello> is an optional argument. It is the "hello" command to use. It can
2012
be either "HELO" (for SMTP) or "EHLO" (for ESTMP). All other
2013
values will be turned into the default command ("HELO").
2014
2015
<domain> is the domain name to present to the server. It may only be
2016
specified (and is mandatory) if the hello command has been
2017
specified. By default, "localhost" is used.
2018
2019
When "option smtpchk" is set, the health checks will consist in TCP
2020
connections followed by an SMTP command. By default, this command is
2021
"HELO localhost". The server's return code is analyzed and only return codes
2022
starting with a "2" will be considered as valid. All other responses,
2023
including a lack of response will constitute an error and will indicate a
2024
dead server.
2025
2026
This test is meant to be used with SMTP servers or relays. Depending on the
2027
request, it is possible that some servers do not log each connection attempt,
2028
so you may want to experiment to improve the behaviour. Using telnet on port
2029
25 is often easier than adjusting the configuration.
2030
2031
Most often, an incoming SMTP server needs to see the client's IP address for
2032
various purposes, including spam filtering, anti-spoofing and logging. When
2033
possible, it is often wise to masquerade the client's IP address when
2034
connecting to the server using the "usesrc" argument of the "source" keyword,
2035
which requires the cttproxy feature to be compiled in.
2036
2037
Example :
2038
option smtpchk HELO mydomain.org
2039
2040
See also : "option httpchk", "source"
2041
2042
2043
option srvtcpka
2044
no option srvtcpka
2045
Enable or disable the sending of TCP keepalive packets on the server side
2046
May be used in sections : defaults | frontend | listen | backend
2047
yes | no | yes | yes
2048
Arguments : none
2049
2050
When there is a firewall or any session-aware component between a client and
2051
a server, and when the protocol involves very long sessions with long idle
2052
periods (eg: remote desktops), there is a risk that one of the intermediate
2053
components decides to expire a session which has remained idle for too long.
2054
2055
Enabling socket-level TCP keep-alives makes the system regularly send packets
2056
to the other end of the connection, leaving it active. The delay between
2057
keep-alive probes is controlled by the system only and depends both on the
2058
operating system and its tuning parameters.
2059
2060
It is important to understand that keep-alive packets are neither emitted nor
2061
received at the application level. It is only the network stacks which sees
2062
them. For this reason, even if one side of the proxy already uses keep-alives
2063
to maintain its connection alive, those keep-alive packets will not be
2064
forwarded to the other side of the proxy.
2065
2066
Please note that this has nothing to do with HTTP keep-alive.
2067
2068
Using option "srvtcpka" enables the emission of TCP keep-alive probes on the
2069
server side of a connection, which should help when session expirations are
2070
noticed between HAProxy and a server.
2071
2072
If this option has been enabled in a "defaults" section, it can be disabled
2073
in a specific instance by prepending the "no" keyword before it.
2074
2075
See also : "option clitcpka", "option tcpka"
2076
2077
2078
option ssl-hello-chk
2079
Use SSLv3 client hello health checks for server testing
2080
May be used in sections : defaults | frontend | listen | backend
2081
yes | no | yes | yes
2082
Arguments : none
2083
2084
When some SSL-based protocols are relayed in TCP mode through HAProxy, it is
2085
possible to test that the server correctly talks SSL instead of just testing
2086
that it accepts the TCP connection. When "option ssl-hello-chk" is set, pure
2087
SSLv3 client hello messages are sent once the connection is established to
2088
the server, and the response is analyzed to find an SSL server hello message.
2089
The server is considered valid only when the response contains this server
2090
hello message.
2091
2092
All servers tested till there correctly reply to SSLv3 client hello messages,
2093
and most servers tested do not even log the requests containing only hello
2094
messages, which is appreciable.
2095
2096
See also: "option httpchk"
2097
2098
2099
option tcpka
2100
Enable or disable the sending of TCP keepalive packets on both sides
2101
May be used in sections : defaults | frontend | listen | backend
2102
yes | yes | yes | yes
2103
Arguments : none
2104
2105
When there is a firewall or any session-aware component between a client and
2106
a server, and when the protocol involves very long sessions with long idle
2107
periods (eg: remote desktops), there is a risk that one of the intermediate
2108
components decides to expire a session which has remained idle for too long.
2109
2110
Enabling socket-level TCP keep-alives makes the system regularly send packets
2111
to the other end of the connection, leaving it active. The delay between
2112
keep-alive probes is controlled by the system only and depends both on the
2113
operating system and its tuning parameters.
2114
2115
It is important to understand that keep-alive packets are neither emitted nor
2116
received at the application level. It is only the network stacks which sees
2117
them. For this reason, even if one side of the proxy already uses keep-alives
2118
to maintain its connection alive, those keep-alive packets will not be
2119
forwarded to the other side of the proxy.
2120
2121
Please note that this has nothing to do with HTTP keep-alive.
2122
2123
Using option "tcpka" enables the emission of TCP keep-alive probes on both
2124
the client and server sides of a connection. Note that this is meaningful
2125
only in "defaults" or "listen" sections. If this option is used in a
2126
frontend, only the client side will get keep-alives, and if this option is
2127
used in a backend, only the server side will get keep-alives. For this
2128
reason, it is strongly recommended to explicitly use "option clitcpka" and
2129
"option srvtcpka" when the configuration is split between frontends and
2130
backends.
2131
2132
See also : "option clitcpka", "option srvtcpka"
2133
2134
2135
option tcplog
2136
Enable advanced logging of TCP connections with session state and timers
2137
May be used in sections : defaults | frontend | listen | backend
2138
yes | yes | yes | yes
2139
Arguments : none
2140
2141
By default, the log output format is very poor, as it only contains the
2142
source and destination addresses, and the instance name. By specifying
2143
"option tcplog", each log line turns into a much richer format including, but
2144
not limited to, the connection timers, the session status, the connections
2145
numbers, the frontend, backend and server name, and of course the source
2146
address and ports. This option is useful for pure TCP proxies in order to
2147
find which of the client or server disconnects or times out. For normal HTTP
2148
proxies, it's better to use "option httplog" which is even more complete.
2149
2150
This option may be set either in the frontend or the backend.
2151
2152
See also : "option httplog", and section 2.6 about logging.
2153
2154
2155
option tcpsplice [ experimental ]
2156
Enable linux kernel-based acceleration of data relaying
2157
May be used in sections : defaults | frontend | listen | backend
2158
yes | yes | yes | yes
2159
Arguments : none
2160
2161
This option is only available when HAProxy has been built for use on Linux
2162
with USE_TCPSPLICE=1. This option requires a kernel patch which is available
2163
on http://www.linux-l7sw.org/.
2164
2165
When "option tcpsplice" is set, as soon as the server's response headers have
2166
been transferred, the session handling is transferred to the kernel which
2167
will forward all subsequent data from the server to the client untill the
2168
session closes. This leads to much faster data transfers between client and
2169
server since the data is not copied twice between kernel and user space, but
2170
there are some limitations such as the lack of information about the number
2171
of bytes transferred and the total transfer time.
2172
2173
This is an experimental feature. It happens to reliably work but issues
2174
caused by corner cases are to be expected.
2175
2176
Note that this option requires that the process permanently runs with
2177
CAP_NETADMIN privileges, which most often translates into running as root.
2178
2179
2180
option transparent
2181
no option transparent
2182
Enable client-side transparent proxying
2183
May be used in sections : defaults | frontend | listen | backend
2184
yes | yes | yes | no
2185
Arguments : none
2186
2187
This option was introduced in order to provide layer 7 persistence to layer 3
2188
load balancers. The idea is to use the OS's ability to redirect an incoming
2189
connection for a remote address to a local process (here HAProxy), and let
2190
this process know what address was initially requested. When this option is
2191
used, sessions without cookies will be forwarded to the original destination
2192
IP address of the incoming request (which should match that of another
2193
equipment), while requests with cookies will still be forwarded to the
2194
appropriate server.
2195
2196
Note that contrary to a common belief, this option does NOT make HAProxy
2197
present the client's IP to the server when establishing the connection.
2198
2199
Use of this option is really discouraged, and since no really valid use of it
2200
has been reported for years, it will probably be removed in future versions.
2201
2202
See also: the "usersrc" argument of the "source" keyword, and the
2203
"transparent" option of the "bind" keyword.
2204
2205
2206
redisp (deprecated)
2207
redispatch (deprecated)
2208
Enable or disable session redistribution in case of connection failure
2209
May be used in sections: defaults | frontend | listen | backend
2210
yes | no | yes | yes
2211
Arguments : none
2212
2213
In HTTP mode, if a server designated by a cookie is down, clients may
2214
definitely stick to it because they cannot flush the cookie, so they will not
2215
be able to access the service anymore.
2216
2217
Specifying "redispatch" will allow the proxy to break their persistence and
2218
redistribute them to a working server.
2219
2220
It also allows to retry last connection to another server in case of multiple
2221
connection failures. Of course, it requires having "retries" set to a nonzero
2222
value.
2223
2224
This form is deprecated, do not use it in any new configuration, use the new
2225
"option redispatch" instead.
2226
2227
See also : "option redispatch"
2228
2229
2230
reqadd <string>
2231
Add a header at the end of the HTTP request
2232
May be used in sections : defaults | frontend | listen | backend
2233
no | yes | yes | yes
2234
Arguments :
2235
<string> is the complete line to be added. Any space or known delimiter
2236
must be escaped using a backslash ('\'). Please refer to section
2237
2.5 about HTTP header manipulation for more information.
2238
2239
A new line consisting in <string> followed by a line feed will be added after
2240
the last header of an HTTP request.
2241
2242
Header transformations only apply to traffic which passes through HAProxy,
2243
and not to traffic generated by HAProxy, such as health-checks or error
2244
responses.
2245
2246
See also: "rspadd" and section 2.5 about HTTP header manipulation
2247
2248
2249
reqallow <search>
2250
reqiallow <search> (ignore case)
2251
Definitely allow an HTTP request if a line matches a regular expression
2252
May be used in sections : defaults | frontend | listen | backend
2253
no | yes | yes | yes
2254
Arguments :
2255
<search> is the regular expression applied to HTTP headers and to the
2256
request line. This is an extended regular expression. Parenthesis
2257
grouping is supported and no preliminary backslash is required.
2258
Any space or known delimiter must be escaped using a backslash
2259
('\'). The pattern applies to a full line at a time. The
2260
"reqallow" keyword strictly matches case while "reqiallow"
2261
ignores case.
2262
2263
A request containing any line which matches extended regular expression
2264
<search> will mark the request as allowed, even if any later test would
2265
result in a deny. The test applies both to the request line and to request
2266
headers. Keep in mind that URLs in request line are case-sensitive while
2267
header names are not.
2268
2269
It is easier, faster and more powerful to use ACLs to write access policies.
2270
Reqdeny, reqallow and reqpass should be avoided in new designs.
2271
2272
Example :
2273
# allow www.* but refuse *.local
2274
reqiallow ^Host:\ www\.
2275
reqideny ^Host:\ .*\.local
2276
2277
See also: "reqdeny", "acl", "block" and section 2.5 about HTTP header
2278
manipulation
2279
2280
2281
reqdel <search>
2282
reqidel <search> (ignore case)
2283
Delete all headers matching a regular expression in an HTTP request
2284
May be used in sections : defaults | frontend | listen | backend
2285
no | yes | yes | yes
2286
Arguments :
2287
<search> is the regular expression applied to HTTP headers and to the
2288
request line. This is an extended regular expression. Parenthesis
2289
grouping is supported and no preliminary backslash is required.
2290
Any space or known delimiter must be escaped using a backslash
2291
('\'). The pattern applies to a full line at a time. The "reqdel"
2292
keyword strictly matches case while "reqidel" ignores case.
2293
2294
Any header line matching extended regular expression <search> in the request
2295
will be completely deleted. Most common use of this is to remove unwanted
2296
and/or dangerous headers or cookies from a request before passing it to the
2297
next servers.
2298
2299
Header transformations only apply to traffic which passes through HAProxy,
2300
and not to traffic generated by HAProxy, such as health-checks or error
2301
responses. Keep in mind that header names are not case-sensitive.
2302
2303
Example :
2304
# remove X-Forwarded-For header and SERVER cookie
2305
reqidel ^X-Forwarded-For:.*
2306
reqidel ^Cookie:.*SERVER=
2307
2308
See also: "reqadd", "reqrep", "rspdel" and section 2.5 about HTTP header
2309
manipulation
2310
2311
2312
reqdeny <search>
2313
reqideny <search> (ignore case)
2314
Deny an HTTP request if a line matches a regular expression
2315
May be used in sections : defaults | frontend | listen | backend
2316
no | yes | yes | yes
2317
Arguments :
2318
<search> is the regular expression applied to HTTP headers and to the
2319
request line. This is an extended regular expression. Parenthesis
2320
grouping is supported and no preliminary backslash is required.
2321
Any space or known delimiter must be escaped using a backslash
2322
('\'). The pattern applies to a full line at a time. The
2323
"reqdeny" keyword strictly matches case while "reqideny" ignores
2324
case.
2325
2326
A request containing any line which matches extended regular expression
2327
<search> will mark the request as denied, even if any later test would
2328
result in an allow. The test applies both to the request line and to request
2329
headers. Keep in mind that URLs in request line are case-sensitive while
2330
header names are not.
2331
2332
A denied request will generate an "HTTP 403 forbidden" response once the
2333
complete request has been parsed. This is consistent with what is practiced
2334
using ACLs.
2335
2336
It is easier, faster and more powerful to use ACLs to write access policies.
2337
Reqdeny, reqallow and reqpass should be avoided in new designs.
2338
2339
Example :
2340
# refuse *.local, then allow www.*
2341
reqideny ^Host:\ .*\.local
2342
reqiallow ^Host:\ www\.
2343
2344
See also: "reqallow", "rspdeny", "acl", "block" and section 2.5 about HTTP
2345
header manipulation
2346
2347
2348
reqpass <search>
2349
reqipass <search> (ignore case)
2350
Ignore any HTTP request line matching a regular expression in next rules
2351
May be used in sections : defaults | frontend | listen | backend
2352
no | yes | yes | yes
2353
Arguments :
2354
<search> is the regular expression applied to HTTP headers and to the
2355
request line. This is an extended regular expression. Parenthesis
2356
grouping is supported and no preliminary backslash is required.
2357
Any space or known delimiter must be escaped using a backslash
2358
('\'). The pattern applies to a full line at a time. The
2359
"reqpass" keyword strictly matches case while "reqipass" ignores
2360
case.
2361
2362
A request containing any line which matches extended regular expression
2363
<search> will skip next rules, without assigning any deny or allow verdict.
2364
The test applies both to the request line and to request headers. Keep in
2365
mind that URLs in request line are case-sensitive while header names are not.
2366
2367
It is easier, faster and more powerful to use ACLs to write access policies.
2368
Reqdeny, reqallow and reqpass should be avoided in new designs.
2369
2370
Example :
2371
# refuse *.local, then allow www.*, but ignore "www.private.local"
2372
reqipass ^Host:\ www.private\.local
2373
reqideny ^Host:\ .*\.local
2374
reqiallow ^Host:\ www\.
2375
2376
See also: "reqallow", "reqdeny", "acl", "block" and section 2.5 about HTTP
2377
header manipulation
2378
2379
2380
reqrep <search> <string>
2381
reqirep <search> <string> (ignore case)
2382
Replace a regular expression with a string in an HTTP request line
2383
May be used in sections : defaults | frontend | listen | backend
2384
no | yes | yes | yes
2385
Arguments :
2386
<search> is the regular expression applied to HTTP headers and to the
2387
request line. This is an extended regular expression. Parenthesis
2388
grouping is supported and no preliminary backslash is required.
2389
Any space or known delimiter must be escaped using a backslash
2390
('\'). The pattern applies to a full line at a time. The "reqrep"
2391
keyword strictly matches case while "reqirep" ignores case.
2392
2393
<string> is the complete line to be added. Any space or known delimiter
2394
must be escaped using a backslash ('\'). References to matched
2395
pattern groups are possible using the common \N form, with N
2396
being a single digit between 0 and 9. Please refer to section
2397
2.5 about HTTP header manipulation for more information.
2398
2399
Any line matching extended regular expression <search> in the request (both
2400
the request line and header lines) will be completely replaced with <string>.
2401
Most common use of this is to rewrite URLs or domain names in "Host" headers.
2402
2403
Header transformations only apply to traffic which passes through HAProxy,
2404
and not to traffic generated by HAProxy, such as health-checks or error
2405
responses. Note that for increased readability, it is suggested to add enough
2406
spaces between the request and the response. Keep in mind that URLs in
2407
request line are case-sensitive while header names are not.
2408
2409
Example :
2410
# replace "/static/" with "/" at the beginning of any request path.
2411
reqrep ^([^\ ]*)\ /static/(.*) \1\ /\2
2412
# replace "www.mydomain.com" with "www" in the host name.
2413
reqirep ^Host:\ www.mydomain.com Host:\ www
2414
2415
See also: "reqadd", "reqdel", "rsprep" and section 2.5 about HTTP header
2416
manipulation
2417
2418
2419
reqtarpit <search>
2420
reqitarpit <search> (ignore case)
2421
Tarpit an HTTP request containing a line matching a regular expression
2422
May be used in sections : defaults | frontend | listen | backend
2423
no | yes | yes | yes
2424
Arguments :
2425
<search> is the regular expression applied to HTTP headers and to the
2426
request line. This is an extended regular expression. Parenthesis
2427
grouping is supported and no preliminary backslash is required.
2428
Any space or known delimiter must be escaped using a backslash
2429
('\'). The pattern applies to a full line at a time. The
2430
"reqtarpit" keyword strictly matches case while "reqitarpit"
2431
ignores case.
2432
2433
A request containing any line which matches extended regular expression
2434
<search> will be tarpitted, which means that it will connect to nowhere, will
2435
be kept open for a pre-defined time, then will return an HTTP error 500 so
2436
that the attacker does not suspect it has been tarpitted. The status 500 will
2437
be reported in the logs, but the completion flags will indicate "PT". The
2438
delay is defined by "timeout tarpit", or "timeout connect" if the former is
2439
not set.
2440
2441
The goal of the tarpit is to slow down robots attacking servers with
2442
identifiable requests. Many robots limit their outgoing number of connections
2443
and stay connected waiting for a reply which can take several minutes to
2444
come. Depending on the environment and attack, it may be particularly
2445
efficient at reducing the load on the network and firewalls.
2446
2447
Example :
2448
# ignore user-agents reporting any flavour of "Mozilla" or "MSIE", but
2449
# block all others.
2450
reqipass ^User-Agent:\.*(Mozilla|MSIE)
2451
reqitarpit ^User-Agent:
2452
2453
See also: "reqallow", "reqdeny", "reqpass", and section 2.5 about HTTP header
2454
manipulation
2455
2456
2457
rspadd <string>
2458
Add a header at the end of the HTTP response
2459
May be used in sections : defaults | frontend | listen | backend
2460
no | yes | yes | yes
2461
Arguments :
2462
<string> is the complete line to be added. Any space or known delimiter
2463
must be escaped using a backslash ('\'). Please refer to section
2464
2.5 about HTTP header manipulation for more information.
2465
2466
A new line consisting in <string> followed by a line feed will be added after
2467
the last header of an HTTP response.
2468
2469
Header transformations only apply to traffic which passes through HAProxy,
2470
and not to traffic generated by HAProxy, such as health-checks or error
2471
responses.
2472
2473
See also: "reqadd" and section 2.5 about HTTP header manipulation
2474
2475
2476
rspdel <search>
2477
rspidel <search> (ignore case)
2478
Delete all headers matching a regular expression in an HTTP response
2479
May be used in sections : defaults | frontend | listen | backend
2480
no | yes | yes | yes
2481
Arguments :
2482
<search> is the regular expression applied to HTTP headers and to the
2483
response line. This is an extended regular expression, so
2484
parenthesis grouping is supported and no preliminary backslash
2485
is required. Any space or known delimiter must be escaped using
2486
a backslash ('\'). The pattern applies to a full line at a time.
2487
The "rspdel" keyword strictly matches case while "rspidel"
2488
ignores case.
2489
2490
Any header line matching extended regular expression <search> in the response
2491
will be completely deleted. Most common use of this is to remove unwanted
2492
and/or sensible headers or cookies from a response before passing it to the
2493
client.
2494
2495
Header transformations only apply to traffic which passes through HAProxy,
2496
and not to traffic generated by HAProxy, such as health-checks or error
2497
responses. Keep in mind that header names are not case-sensitive.
2498
2499
Example :
2500
# remove the Server header from responses
2501
reqidel ^Server:.*
2502
2503
See also: "rspadd", "rsprep", "reqdel" and section 2.5 about HTTP header
2504
manipulation
2505
2506
2507
rspdeny <search>
2508
rspideny <search> (ignore case)
2509
Block an HTTP response if a line matches a regular expression
2510
May be used in sections : defaults | frontend | listen | backend
2511
no | yes | yes | yes
2512
Arguments :
2513
<search> is the regular expression applied to HTTP headers and to the
2514
response line. This is an extended regular expression, so
2515
parenthesis grouping is supported and no preliminary backslash
2516
is required. Any space or known delimiter must be escaped using
2517
a backslash ('\'). The pattern applies to a full line at a time.
2518
The "rspdeny" keyword strictly matches case while "rspideny"
2519
ignores case.
2520
2521
A response containing any line which matches extended regular expression
2522
<search> will mark the request as denied. The test applies both to the
2523
response line and to response headers. Keep in mind that header names are not
2524
case-sensitive.
2525
2526
Main use of this keyword is to prevent sensitive information leak and to
2527
block the response before it reaches the client. If a response is denied, it
2528
will be replaced with an HTTP 502 error so that the client never retrieves
2529
any sensitive data.
2530
2531
It is easier, faster and more powerful to use ACLs to write access policies.
2532
Rspdeny should be avoided in new designs.
2533
2534
Example :
2535
# Ensure that no content type matching ms-word will leak
2536
rspideny ^Content-type:\.*/ms-word
2537
2538
See also: "reqdeny", "acl", "block" and section 2.5 about HTTP header
2539
manipulation
2540
2541
2542
rsprep <search> <string>
2543
rspirep <search> <string> (ignore case)
2544
Replace a regular expression with a string in an HTTP response line
2545
May be used in sections : defaults | frontend | listen | backend
2546
no | yes | yes | yes
2547
Arguments :
2548
<search> is the regular expression applied to HTTP headers and to the
2549
response line. This is an extended regular expression, so
2550
parenthesis grouping is supported and no preliminary backslash
2551
is required. Any space or known delimiter must be escaped using
2552
a backslash ('\'). The pattern applies to a full line at a time.
2553
The "rsprep" keyword strictly matches case while "rspirep"
2554
ignores case.
2555
2556
<string> is the complete line to be added. Any space or known delimiter
2557
must be escaped using a backslash ('\'). References to matched
2558
pattern groups are possible using the common \N form, with N
2559
being a single digit between 0 and 9. Please refer to section
2560
2.5 about HTTP header manipulation for more information.
2561
2562
Any line matching extended regular expression <search> in the response (both
2563
the response line and header lines) will be completely replaced with
2564
<string>. Most common use of this is to rewrite Location headers.
2565
2566
Header transformations only apply to traffic which passes through HAProxy,
2567
and not to traffic generated by HAProxy, such as health-checks or error
2568
responses. Note that for increased readability, it is suggested to add enough
2569
spaces between the request and the response. Keep in mind that header names
2570
are not case-sensitive.
2571
2572
Example :
2573
# replace "Location: 127.0.0.1:8080" with "Location: www.mydomain.com"
2574
rspirep ^Location:\ 127.0.0.1:8080 Location:\ www.mydomain.com
2575
2576
See also: "rspadd", "rspdel", "reqrep" and section 2.5 about HTTP header
2577
manipulation
2578
2579
2580
server <name> <address>[:port] [param*]
2581
Declare a server in a backend
2582
May be used in sections : defaults | frontend | listen | backend
2583
no | no | yes | yes
2584
Arguments :
2585
<name> is the internal name assigned to this server. This name will
2586
appear in logs and alerts.
2587
2588
<address> is the IPv4 address of the server. Alternatively, a resolvable
2589
hostname is supported, but this name will be resolved during
2590
start-up.
2591
2592
<ports> is an optional port specification. If set, all connections will
2593
be sent to this port. If unset, the same port the client
2594
connected to will be used. The port may also be prefixed by a "+"
2595
or a "-". In this case, the server's port will be determined by
2596
adding this value to the client's port.
2597
2598
<param*> is a list of parameters for this server. The "server" keywords
2599
accepts an important number of options and has a complete section
2600
dedicated to it. Please refer to section 2.4 for more details.
2601
2602
Examples :
2603
server first 10.1.1.1:1080 cookie first check inter 1000
2604
server second 10.1.1.2:1080 cookie second check inter 1000
2605
2606
See also : section 2.4 about server options
2607
2608
2609
source <addr>[:<port>] [usesrc { <addr2>[:<port2>] | client | clientip } ]
2610
Set the source address for outgoing connections
2611
May be used in sections : defaults | frontend | listen | backend
2612
yes | no | yes | yes
2613
Arguments :
2614
<addr> is the IPv4 address HAProxy will bind to before connecting to a
2615
server. This address is also used as a source for health checks.
2616
The default value of 0.0.0.0 means that the system will select
2617
the most appropriate address to reach its destination.
2618
2619
<port> is an optional port. It is normally not needed but may be useful
2620
in some very specific contexts. The default value of zero means
2621
the system will select a free port.
2622
2623
<addr2> is the IP address to present to the server when connections are
2624
forwarded in full transparent proxy mode. This is currently only
2625
supported on some patched Linux kernels. When this address is
2626
specified, clients connecting to the server will be presented
2627
with this address, while health checks will still use the address
2628
<addr>.
2629
2630
<port2> is the optional port to present to the server when connections
2631
are forwarded in full transparent proxy mode (see <addr2> above).
2632
The default value of zero means the system will select a free
2633
port.
2634
2635
The "source" keyword is useful in complex environments where a specific
2636
address only is allowed to connect to the servers. It may be needed when a
2637
private address must be used through a public gateway for instance, and it is
2638
known that the system cannot determine the adequate source address by itself.
2639
2640
An extension which is available on certain patched Linux kernels may be used
2641
through the "usesrc" optional keyword. It makes it possible to connect to the
2642
servers with an IP address which does not belong to the system itself. This
2643
is called "full transparent proxy mode". For this to work, the destination
2644
servers have to route their traffic back to this address through the machine
2645
running HAProxy, and IP forwarding must generally be enabled on this machine.
2646
2647
In this "full transparent proxy" mode, it is possible to force a specific IP
2648
address to be presented to the servers. This is not much used in fact. A more
2649
common use is to tell HAProxy to present the client's IP address. For this,
2650
there are two methods :
2651
2652
- present the client's IP and port addresses. This is the most transparent
2653
mode, but it can cause problems when IP connection tracking is enabled on
2654
the machine, because a same connection may be seen twice with different
2655
states. However, this solution presents the huge advantage of not
2656
limiting the system to the 64k outgoing address+port couples, because all
2657
of the client ranges may be used.
2658
2659
- present only the client's IP address and select a spare port. This
2660
solution is still quite elegant but slightly less transparent (downstream
2661
firewalls logs will not match upstream's). It also presents the downside
2662
of limiting the number of concurrent connections to the usual 64k ports.
2663
However, since the upstream and downstream ports are different, local IP
2664
connection tracking on the machine will not be upset by the reuse of the
2665
same session.
2666
2667
Note that depending on the transparent proxy technology used, it may be
2668
required to force the source address. In fact, cttproxy version 2 requires an
2669
IP address in <addr> above, and does not support setting of "0.0.0.0" as the
2670
IP address because it creates NAT entries which much match the exact outgoing
2671
address. Tproxy version 4 and some other kernel patches which work in pure
2672
forwarding mode generally will not have this limitation.
2673
2674
This option sets the default source for all servers in the backend. It may
2675
also be specified in a "defaults" section. Finer source address specification
2676
is possible at the server level using the "source" server option. Refer to
2677
section 2.4 for more information.
2678
2679
Examples :
2680
backend private
2681
# Connect to the servers using our 192.168.1.200 source address
2682
source 192.168.1.200
2683
2684
backend transparent_ssl1
2685
# Connect to the SSL farm from the client's source address
2686
source 192.168.1.200 usesrc clientip
2687
2688
backend transparent_ssl2
2689
# Connect to the SSL farm from the client's source address and port
2690
# not recommended if IP conntrack is present on the local machine.
2691
source 192.168.1.200 usesrc client
2692
2693
backend transparent_ssl3
2694
# Connect to the SSL farm from the client's source address. It
2695
# is more conntrack-friendly.
2696
source 192.168.1.200 usesrc clientip
2697
2698
backend transparent_smtp
2699
# Connect to the SMTP farm from the client's source address/port
2700
# with Tproxy version 4.
2701
source 0.0.0.0 usesrc clientip
2702
2703
See also : the "source" server option in section 2.4, the Tproxy patches for
2704
the Linux kernel on www.balabit.com, the "bind" keyword.
2705
2706
2707
srvtimeout <timeout> (deprecated)
2708
Set the maximum inactivity time on the server side.
2709
May be used in sections : defaults | frontend | listen | backend
2710
yes | no | yes | yes
2711
Arguments :
2712
<timeout> is the timeout value specified in milliseconds by default, but
2713
can be in any other unit if the number is suffixed by the unit,
2714
as explained at the top of this document.
2715
2716
The inactivity timeout applies when the server is expected to acknowledge or
2717
send data. In HTTP mode, this timeout is particularly important to consider
2718
during the first phase of the server's response, when it has to send the
2719
headers, as it directly represents the server's processing time for the
2720
request. To find out what value to put there, it's often good to start with
2721
what would be considered as unacceptable response times, then check the logs
2722
to observe the response time distribution, and adjust the value accordingly.
2723
2724
The value is specified in milliseconds by default, but can be in any other
2725
unit if the number is suffixed by the unit, as specified at the top of this
2726
document. In TCP mode (and to a lesser extent, in HTTP mode), it is highly
2727
recommended that the client timeout remains equal to the server timeout in
2728
order to avoid complex situations to debug. Whatever the expected server
2729
response times, it is a good practice to cover at least one or several TCP
2730
packet losses by specifying timeouts that are slightly above multiples of 3
2731
seconds (eg: 4 or 5 seconds minimum).
2732
2733
This parameter is specific to backends, but can be specified once for all in
2734
"defaults" sections. This is in fact one of the easiest solutions not to
2735
forget about it. An unspecified timeout results in an infinite timeout, which
2736
is not recommended. Such a usage is accepted and works but reports a warning
2737
during startup because it may results in accumulation of expired sessions in
2738
the system if the system's timeouts are not configured either.
2739
2740
This parameter is provided for compatibility but is currently deprecated.
2741
Please use "timeout server" instead.
2742
2743
See also : "timeout server", "timeout client" and "clitimeout".
2744
2745
2746
stats auth <user>:<passwd>
2747
Enable statistics with authentication and grant access to an account
2748
May be used in sections : defaults | frontend | listen | backend
2749
yes | no | yes | yes
2750
Arguments :
2751
<user> is a user name to grant access to
2752
2753
<passwd> is the cleartext password associated to this user
2754
2755
This statement enables statistics with default settings, and restricts access
2756
to declared users only. It may be repeated as many times as necessary to
2757
allow as many users as desired. When a user tries to access the statistics
2758
without a valid account, a "401 Forbidden" response will be returned so that
2759
the browser asks the user to provide a valid user and password. The real
2760
which will be returned to the browser is configurable using "stats realm".
2761
2762
Since the authentication method is HTTP Basic Authentication, the passwords
2763
circulate in cleartext on the network. Thus, it was decided that the
2764
configuration file would also use cleartext passwords to remind the users
2765
that those ones should not be sensible and not shared with any other account.
2766
2767
It is also possible to reduce the scope of the proxies which appear in the
2768
report using "stats scope".
2769
2770
Though this statement alone is enough to enable statistics reporting, it is
2771
recommended to set all other settings in order to avoid relying on default
2772
unobvious parameters.
2773
2774
Example :
2775
# public access (limited to this backend only)
2776
backend public_www
2777
server srv1 192.168.0.1:80
2778
stats enable
2779
stats hide-version
2780
stats scope .
2781
stats uri /admin?stats
2782
stats realm Haproxy\ Statistics
2783
stats auth admin1:AdMiN123
2784
stats auth admin2:AdMiN321
2785
2786
# internal monitoring access (unlimited)
2787
backend private_monitoring
2788
stats enable
2789
stats uri /admin?stats
2790
stats refresh 5s
2791
2792
See also : "stats enable", "stats realm", "stats scope", "stats uri"
2793
2794
2795
stats enable
2796
Enable statistics reporting with default settings
2797
May be used in sections : defaults | frontend | listen | backend
2798
yes | no | yes | yes
2799
Arguments : none
2800
2801
This statement enables statistics reporting with default settings defined
2802
at build time. Unless stated otherwise, these settings are used :
2803
- stats uri : /haproxy?stats
2804
- stats realm : "HAProxy Statistics"
2805
- stats auth : no authentication
2806
- stats scope : no restriction
2807
2808
Though this statement alone is enough to enable statistics reporting, it is
2809
recommended to set all other settings in order to avoid relying on default
2810
unobvious parameters.
2811
2812
Example :
2813
# public access (limited to this backend only)
2814
backend public_www
2815
server srv1 192.168.0.1:80
2816
stats enable
2817
stats hide-version
2818
stats scope .
2819
stats uri /admin?stats
2820
stats realm Haproxy\ Statistics
2821
stats auth admin1:AdMiN123
2822
stats auth admin2:AdMiN321
2823
2824
# internal monitoring access (unlimited)
2825
backend private_monitoring
2826
stats enable
2827
stats uri /admin?stats
2828
stats refresh 5s
2829
2830
See also : "stats auth", "stats realm", "stats uri"
2831
2832
2833
stats realm <realm>
2834
Enable statistics and set authentication realm
2835
May be used in sections : defaults | frontend | listen | backend
2836
yes | no | yes | yes
2837
Arguments :
2838
<realm> is the name of the HTTP Basic Authentication realm reported to
2839
the browser. The browser uses it to display it in the pop-up
2840
inviting the user to enter a valid username and password.
2841
2842
The realm is read as a single word, so any spaces in it should be escaped
2843
using a backslash ('\').
2844
2845
This statement is useful only in conjunction with "stats auth" since it is
2846
only related to authentication.
2847
2848
Though this statement alone is enough to enable statistics reporting, it is
2849
recommended to set all other settings in order to avoid relying on default
2850
unobvious parameters.
2851
2852
Example :
2853
# public access (limited to this backend only)
2854
backend public_www
2855
server srv1 192.168.0.1:80
2856
stats enable
2857
stats hide-version
2858
stats scope .
2859
stats uri /admin?stats
2860
stats realm Haproxy\ Statistics
2861
stats auth admin1:AdMiN123
2862
stats auth admin2:AdMiN321
2863
2864
# internal monitoring access (unlimited)
2865
backend private_monitoring
2866
stats enable
2867
stats uri /admin?stats
2868
stats refresh 5s
2869
2870
See also : "stats auth", "stats enable", "stats uri"
2871
2872
2873
stats refresh <delay>
2874
Enable statistics with automatic refresh
2875
May be used in sections : defaults | frontend | listen | backend
2876
yes | no | yes | yes
2877
Arguments :
2878
<delay> is the suggested refresh delay, specified in seconds, which will
2879
be returned to the browser consulting the report page. While the
2880
browser is free to apply any delay, it will generally respect it
2881
and refresh the page this every seconds. The refresh interval may
2882
be specified in any other non-default time unit, by suffixing the
2883
unit after the value, as explained at the top of this document.
2884
2885
This statement is useful on monitoring displays with a permanent page
2886
reporting the load balancer's activity. When set, the HTML report page will
2887
include a link "refresh"/"stop refresh" so that the user can select whether
2888
he wants automatic refresh of the page or not.
2889
2890
Though this statement alone is enough to enable statistics reporting, it is
2891
recommended to set all other settings in order to avoid relying on default
2892
unobvious parameters.
2893
2894
Example :
2895
# public access (limited to this backend only)
2896
backend public_www
2897
server srv1 192.168.0.1:80
2898
stats enable
2899
stats hide-version
2900
stats scope .
2901
stats uri /admin?stats
2902
stats realm Haproxy\ Statistics
2903
stats auth admin1:AdMiN123
2904
stats auth admin2:AdMiN321
2905
2906
# internal monitoring access (unlimited)
2907
backend private_monitoring
2908
stats enable
2909
stats uri /admin?stats
2910
stats refresh 5s
2911
2912
See also : "stats auth", "stats enable", "stats realm", "stats uri"
2913
2914
2915
stats scope { <name> | "." }
2916
Enable statistics and limit access scope
2917
May be used in sections : defaults | frontend | listen | backend
2918
yes | no | yes | yes
2919
Arguments :
2920
<name> is the name of a listen, frontend or backend section to be
2921
reported. The special name "." (a single dot) designates the
2922
section in which the statement appears.
2923
2924
When this statement is specified, only the sections enumerated with this
2925
statement will appear in the report. All other ones will be hidden. This
2926
statement may appear as many times as needed if multiple sections need to be
2927
reported. Please note that the name checking is performed as simple string
2928
comparisons, and that it is never checked that a give section name really
2929
exists.
2930
2931
Though this statement alone is enough to enable statistics reporting, it is
2932
recommended to set all other settings in order to avoid relying on default
2933
unobvious parameters.
2934
2935
Example :
2936
# public access (limited to this backend only)
2937
backend public_www
2938
server srv1 192.168.0.1:80
2939
stats enable
2940
stats hide-version
2941
stats scope .
2942
stats uri /admin?stats
2943
stats realm Haproxy\ Statistics
2944
stats auth admin1:AdMiN123
2945
stats auth admin2:AdMiN321
2946
2947
# internal monitoring access (unlimited)
2948
backend private_monitoring
2949
stats enable
2950
stats uri /admin?stats
2951
stats refresh 5s
2952
2953
See also : "stats auth", "stats enable", "stats realm", "stats uri"
2954
2955
2956
stats uri <prefix>
2957
Enable statistics and define the URI prefix to access them
2958
May be used in sections : defaults | frontend | listen | backend
2959
yes | no | yes | yes
2960
Arguments :
2961
<prefix> is the prefix of any URI which will be redirected to stats. This
2962
prefix may contain a question mark ('?') to indicate part of a
2963
query string.
2964
2965
The statistics URI is intercepted on the relayed traffic, so it appears as a
2966
page within the normal application. It is strongly advised to ensure that the
2967
selected URI will never appear in the application, otherwise it will never be
2968
possible to reach it in the application.
2969
2970
The default URI compiled in haproxy is "/haproxy?stats", but this may be
2971
changed at build time, so it's better to always explictly specify it here.
2972
It is generally a good idea to include a question mark in the URI so that
2973
intermediate proxies refrain from caching the results. Also, since any string
2974
beginning with the prefix will be accepted as a stats request, the question
2975
mark helps ensuring that no valid URI will begin with the same words.
2976
2977
It is sometimes very convenient to use "/" as the URI prefix, and put that
2978
statement in a "listen" instance of its own. That makes it easy to dedicate
2979
an address or a port to statistics only.
2980
2981
Though this statement alone is enough to enable statistics reporting, it is
2982
recommended to set all other settings in order to avoid relying on default
2983
unobvious parameters.
2984
2985
Example :
2986
# public access (limited to this backend only)
2987
backend public_www
2988
server srv1 192.168.0.1:80
2989
stats enable
2990
stats hide-version
2991
stats scope .
2992
stats uri /admin?stats
2993
stats realm Haproxy\ Statistics
2994
stats auth admin1:AdMiN123
2995
stats auth admin2:AdMiN321
2996
2997
# internal monitoring access (unlimited)
2998
backend private_monitoring
2999
stats enable
3000
stats uri /admin?stats
3001
stats refresh 5s
3002
3003
See also : "stats auth", "stats enable", "stats realm"
3004
3005
3006
stats hide-version
3007
Enable statistics and hide HAProxy version reporting
3008
May be used in sections : defaults | frontend | listen | backend
3009
yes | no | yes | yes
3010
Arguments : none
3011
3012
By default, the stats page reports some useful status information along with
3013
the statistics. Among them is HAProxy's version. However, it is generally
3014
considered dangerous to report precise version to anyone, as it can help them
3015
target known weaknesses with specific attacks. The "stats hide-version"
3016
statement removes the version from the statistics report. This is recommended
3017
for public sites or any site with a weak login/password.
3018
3019
Though this statement alone is enough to enable statistics reporting, it is
3020
recommended to set all other settings in order to avoid relying on default
3021
unobvious parameters.
3022
3023
Example :
3024
# public access (limited to this backend only)
3025
backend public_www
3026
server srv1 192.168.0.1:80
3027
stats enable
3028
stats hide-version
3029
stats scope .
3030
stats uri /admin?stats
3031
stats realm Haproxy\ Statistics
3032
stats auth admin1:AdMiN123
3033
stats auth admin2:AdMiN321
3034
3035
# internal monitoring access (unlimited)
3036
backend private_monitoring
3037
stats enable
3038
stats uri /admin?stats
3039
stats refresh 5s
3040
3041
See also : "stats auth", "stats enable", "stats realm", "stats uri"
3042
3043
3044
timeout client <timeout>
3045
timeout clitimeout <timeout> (deprecated)
3046
Set the maximum inactivity time on the client side.
3047
May be used in sections : defaults | frontend | listen | backend
3048
yes | yes | yes | no
3049
Arguments :
3050
<timeout> is the timeout value specified in milliseconds by default, but
3051
can be in any other unit if the number is suffixed by the unit,
3052
as explained at the top of this document.
3053
3054
The inactivity timeout applies when the client is expected to acknowledge or
3055
send data. In HTTP mode, this timeout is particularly important to consider
3056
during the first phase, when the client sends the request, and during the
3057
response while it is reading data sent by the server. The value is specified
3058
in milliseconds by default, but can be in any other unit if the number is
3059
suffixed by the unit, as specified at the top of this document. In TCP mode
3060
(and to a lesser extent, in HTTP mode), it is highly recommended that the
3061
client timeout remains equal to the server timeout in order to avoid complex
3062
situations to debug. It is a good practice to cover one or several TCP packet
3063
losses by specifying timeouts that are slightly above multiples of 3 seconds
3064
(eg: 4 or 5 seconds).
3065
3066
This parameter is specific to frontends, but can be specified once for all in
3067
"defaults" sections. This is in fact one of the easiest solutions not to
3068
forget about it. An unspecified timeout results in an infinite timeout, which
3069
is not recommended. Such a usage is accepted and works but reports a warning
3070
during startup because it may results in accumulation of expired sessions in
3071
the system if the system's timeouts are not configured either.
3072
3073
This parameter replaces the old, deprecated "clitimeout". It is recommended
3074
to use it to write new configurations. The form "timeout clitimeout" is
3075
provided only by backwards compatibility but its use is strongly discouraged.
3076
3077
See also : "clitimeout", "timeout server".
3078
3079
3080
timeout connect <timeout>
3081
timeout contimeout <timeout> (deprecated)
3082
Set the maximum time to wait for a connection attempt to a server to succeed.
3083
May be used in sections : defaults | frontend | listen | backend
3084
yes | no | yes | yes
3085
Arguments :
3086
<timeout> is the timeout value specified in milliseconds by default, but
3087
can be in any other unit if the number is suffixed by the unit,
3088
as explained at the top of this document.
3089
3090
If the server is located on the same LAN as haproxy, the connection should be
3091
immediate (less than a few milliseconds). Anyway, it is a good practice to
3092
cover one or several TCP packet losses by specifying timeouts that are
3093
slightly above multiples of 3 seconds (eg: 4 or 5 seconds). By default, the
3094
connect timeout also presets the queue timeout to the same value if this one
3095
has not been specified.
3096
3097
This parameter is specific to backends, but can be specified once for all in
3098
"defaults" sections. This is in fact one of the easiest solutions not to
3099
forget about it. An unspecified timeout results in an infinite timeout, which
3100
is not recommended. Such a usage is accepted and works but reports a warning
3101
during startup because it may results in accumulation of failed sessions in
3102
the system if the system's timeouts are not configured either.
3103
3104
This parameter replaces the old, deprecated "contimeout". It is recommended
3105
to use it to write new configurations. The form "timeout contimeout" is
3106
provided only by backwards compatibility but its use is strongly discouraged.
3107
3108
See also : "timeout queue", "timeout server", "contimeout".
3109
3110
3111
timeout http-request <timeout>
3112
Set the maximum allowed time to wait for a complete HTTP request
3113
May be used in sections : defaults | frontend | listen | backend
3114
yes | yes | yes | no
3115
Arguments :
3116
<timeout> is the timeout value specified in milliseconds by default, but
3117
can be in any other unit if the number is suffixed by the unit,
3118
as explained at the top of this document.
3119
3120
In order to offer DoS protection, it may be required to lower the maximum
3121
accepted time to receive a complete HTTP request without affecting the client
3122
timeout. This helps protecting against established connections on which
3123
nothing is sent. The client timeout cannot offer a good protection against
3124
this abuse because it is an inactivity timeout, which means that if the
3125
attacker sends one character every now and then, the timeout will not
3126
trigger. With the HTTP request timeout, no matter what speed the client
3127
types, the request will be aborted if it does not complete in time.
3128
3129
Note that this timeout only applies to the header part of the request, and
3130
not to any data. As soon as the empty line is received, this timeout is not
3131
used anymore.
3132
3133
Generally it is enough to set it to a few seconds, as most clients send the
3134
full request immediately upon connection. Add 3 or more seconds to cover TCP
3135
retransmits but that's all. Setting it to very low values (eg: 50 ms) will
3136
generally work on local networks as long as there are no packet losses. This
3137
will prevent people from sending bare HTTP requests using telnet.
3138
3139
If this parameter is not set, the client timeout still applies between each
3140
chunk of the incoming request.
3141
3142
See also : "timeout client".
3143
3144
3145
timeout queue <timeout>
3146
Set the maximum time to wait in the queue for a connection slot to be free
3147
May be used in sections : defaults | frontend | listen | backend
3148
yes | no | yes | yes
3149
Arguments :
3150
<timeout> is the timeout value specified in milliseconds by default, but
3151
can be in any other unit if the number is suffixed by the unit,
3152
as explained at the top of this document.
3153
3154
When a server's maxconn is reached, connections are left pending in a queue
3155
which may be server-specific or global to the backend. In order not to wait
3156
indefinitely, a timeout is applied to requests pending in the queue. If the
3157
timeout is reached, it is considered that the request will almost never be
3158
served, so it is dropped and a 503 error is returned to the client.
3159
3160
The "timeout queue" statement allows to fix the maximum time for a request to
3161
be left pending in a queue. If unspecified, the same value as the backend's
3162
connection timeout ("timeout connect") is used, for backwards compatibility
3163
with older versions with no "timeout queue" parameter.
3164
3165
See also : "timeout connect", "contimeout".
3166
3167
3168
timeout server <timeout>
3169
timeout srvtimeout <timeout> (deprecated)
3170
Set the maximum inactivity time on the server side.
3171
May be used in sections : defaults | frontend | listen | backend
3172
yes | no | yes | yes
3173
Arguments :
3174
<timeout> is the timeout value specified in milliseconds by default, but
3175
can be in any other unit if the number is suffixed by the unit,
3176
as explained at the top of this document.
3177
3178
The inactivity timeout applies when the server is expected to acknowledge or
3179
send data. In HTTP mode, this timeout is particularly important to consider
3180
during the first phase of the server's response, when it has to send the
3181
headers, as it directly represents the server's processing time for the
3182
request. To find out what value to put there, it's often good to start with
3183
what would be considered as unacceptable response times, then check the logs
3184
to observe the response time distribution, and adjust the value accordingly.
3185
3186
The value is specified in milliseconds by default, but can be in any other
3187
unit if the number is suffixed by the unit, as specified at the top of this
3188
document. In TCP mode (and to a lesser extent, in HTTP mode), it is highly
3189
recommended that the client timeout remains equal to the server timeout in
3190
order to avoid complex situations to debug. Whatever the expected server
3191
response times, it is a good practice to cover at least one or several TCP
3192
packet losses by specifying timeouts that are slightly above multiples of 3
3193
seconds (eg: 4 or 5 seconds minimum).
3194
3195
This parameter is specific to backends, but can be specified once for all in
3196
"defaults" sections. This is in fact one of the easiest solutions not to
3197
forget about it. An unspecified timeout results in an infinite timeout, which
3198
is not recommended. Such a usage is accepted and works but reports a warning
3199
during startup because it may results in accumulation of expired sessions in
3200
the system if the system's timeouts are not configured either.
3201
3202
This parameter replaces the old, deprecated "srvtimeout". It is recommended
3203
to use it to write new configurations. The form "timeout srvtimeout" is
3204
provided only by backwards compatibility but its use is strongly discouraged.
3205
3206
See also : "srvtimeout", "timeout client".
3207
3208
3209
timeout tarpit <timeout>
3210
Set the duration for which tapitted connections will be maintained
3211
May be used in sections : defaults | frontend | listen | backend
3212
yes | yes | yes | yes
3213
Arguments :
3214
<timeout> is the tarpit duration specified in milliseconds by default, but
3215
can be in any other unit if the number is suffixed by the unit,
3216
as explained at the top of this document.
3217
3218
When a connection is tarpitted using "reqtarpit", it is maintained open with
3219
no activity for a certain amount of time, then closed. "timeout tarpit"
3220
defines how long it will be maintained open.
3221
3222
The value is specified in milliseconds by default, but can be in any other
3223
unit if the number is suffixed by the unit, as specified at the top of this
3224
document. If unspecified, the same value as the backend's connection timeout
3225
("timeout connect") is used, for backwards compatibility with older versions
3226
with no "timeout tapit" parameter.
3227
3228
See also : "timeout connect", "contimeout".
3229
3230
3231
transparent (deprecated)
3232
Enable client-side transparent proxying
3233
May be used in sections : defaults | frontend | listen | backend
3234
yes | yes | yes | no
3235
Arguments : none
3236
3237
This keyword was introduced in order to provide layer 7 persistence to layer
3238
3 load balancers. The idea is to use the OS's ability to redirect an incoming
3239
connection for a remote address to a local process (here HAProxy), and let
3240
this process know what address was initially requested. When this option is
3241
used, sessions without cookies will be forwarded to the original destination
3242
IP address of the incoming request (which should match that of another
3243
equipment), while requests with cookies will still be forwarded to the
3244
appropriate server.
3245
3246
The "transparent" keyword is deprecated, use "option transparent" instead.
3247
3248
Note that contrary to a common belief, this option does NOT make HAProxy
3249
present the client's IP to the server when establishing the connection.
3250
3251
Use of this option is really discouraged, and since no really valid use of it
3252
has been reported for years, it will probably be removed in future versions.
3253
3254
See also: "option transparent"
3255
3256
3257
use_backend <backend> if <condition>
3258
use_backend <backend> unless <condition>
3259
Switch to a specific backend if/unless a Layer 7 condition is matched.
3260
May be used in sections : defaults | frontend | listen | backend
3261
no | yes | yes | no
3262
Arguments :
3263
<backend> is the name of a valid backend or "listen" section.
3264
3265
<condition> is a condition composed of ACLs, as described in section 2.3.
3266
3267
When doing content-switching, connections arrive on a frontend and are then
3268
dispatched to various backends depending on a number of conditions. The
3269
relation between the conditions and the backends is described with the
3270
"use_backend" keyword. This is supported only in HTTP mode.
3271
3272
There may be as many "use_backend" rules as desired. All of these rules are
3273
evaluated in their declaration order, and the first one which matches will
3274
assign the backend.
3275
3276
In the first form, the backend will be used if the condition is met. In the
3277
second form, the backend will be used if the condition is not met. If no
3278
condition is valid, the backend defined with "default_backend" will be used.
3279
If no default backend is defined, either the servers in the same section are
3280
used (in case of a "listen" section) or, in case of a frontend, no server is
3281
used and a 503 service unavailable response is returned.
3282
3283
See also: "default_backend" and section 2.3 about ACLs.
3284
3285
3286
2.3) Using ACLs
3287
---------------
3288
3289
The use of Access Control Lists (ACL) provides a flexible solution to perform
3290
content switching and generally to take decisions based on content extracted
3291
from the request, the response or any environmental status. The principle is
3292
simple :
3293
3294
- define test criteria with sets of values
3295
- perform actions only if a set of tests is valid
3296
3297
The actions generally consist in blocking the request, or selecting a backend.
3298
3299
In order to define a test, the "acl" keyword is used. The syntax is :
3300
3301
acl <aclname> <criterion> [flags] [operator] <value> ...
3302
3303
This creates a new ACL <aclname> or completes an existing one with new tests.
3304
Those tests apply to the portion of request/response specified in <criterion>
3305
and may be adjusted with optional flags [flags]. Some criteria also support
3306
an operator which may be specified before the set of values. The values are
3307
of the type supported by the criterion, and are separated by spaces.
3308
3309
ACL names must be formed from upper and lower case letters, digits, '-' (dash),
3310
'_' (underscore) , '.' (dot) and ':' (colon). ACL names are case-sensitive,
3311
which means that "my_acl" and "My_Acl" are two different ACLs.
3312
3313
There is no enforced limit to the number of ACLs. The unused ones do not affect
3314
performance, they just consume a small amount of memory.
3315
3316
The following ACL flags are currently supported :
3317
3318
-i : ignore case during matching.
3319
-- : force end of flags. Useful when a string looks like one of the flags.
3320
3321
Supported types of values are :
3322
3323
- integers or integer ranges
3324
- strings
3325
- regular expressions
3326
- IP addresses and networks
3327
3328
3329
2.3.1) Matching integers
3330
------------------------
3331
3332
Matching integers is special in that ranges and operators are permitted. Note
3333
that integer matching only applies to positive values. A range is a value
3334
expressed with a lower and an upper bound separated with a colon, both of which
3335
may be omitted.
3336
3337
For instance, "1024:65535" is a valid range to represent a range of
3338
unprivileged ports, and "1024:" would also work. "0:1023" is a valid
3339
representation of privileged ports, and ":1023" would also work.
3340
3341
For an easier usage, comparison operators are also supported. Note that using
3342
operators with ranges does not make much sense and is strongly discouraged.
3343
Similarly, it does not make much sense to perform order comparisons with a set
3344
of values.
3345
3346
Available operators for integer matching are :
3347
3348
eq : true if the tested value equals at least one value
3349
ge : true if the tested value is greater than or equal to at least one value
3350
gt : true if the tested value is greater than at least one value
3351
le : true if the tested value is less than or equal to at least one value
3352
lt : true if the tested value is less than at least one value
3353
3354
For instance, the following ACL matches any negative Content-Length header :
3355
3356
acl negative-length hdr_val(content-length) lt 0
3357
3358
3359
2.3.2) Matching strings
3360
-----------------------
3361
3362
String matching applies to verbatim strings as they are passed, with the
3363
exception of the backslash ("\") which makes it possible to escape some
3364
characters such as the space. If the "-i" flag is passed before the first
3365
string, then the matching will be performed ignoring the case. In order
3366
to match the string "-i", either set it second, or pass the "--" flag
3367
before the first string. Same applies of course to match the string "--".
3368
3369
3370
2.3.3) Matching regular expressions (regexes)
3371
---------------------------------------------
3372
3373
Just like with string matching, regex matching applies to verbatim strings as
3374
they are passed, with the exception of the backslash ("\") which makes it
3375
possible to escape some characters such as the space. If the "-i" flag is
3376
passed before the first regex, then the matching will be performed ignoring
3377
the case. In order to match the string "-i", either set it second, or pass
3378
the "--" flag before the first string. Same principle applies of course to
3379
match the string "--".
3380
3381
3382
2.3.4) Matching IPv4 addresses
3383
------------------------------
3384
3385
IPv4 addresses values can be specified either as plain addresses or with a
3386
netmask appended, in which case the IPv4 address matches whenever it is
3387
within the network. Plain addresses may also be replaced with a resolvable
3388
host name, but this practice is generally discouraged as it makes it more
3389
difficult to read and debug configurations. If hostnames are used, you should
3390
at least ensure that they are present in /etc/hosts so that the configuration
3391
does not depend on any random DNS match at the moment the configuration is
3392
parsed.
3393
3394
3395
2.3.5) Available matching criteria
3396
----------------------------------
3397
3398
2.3.5.1) Matching at Layer 4 and below
3399
--------------------------------------
3400
3401
A first set of criteria applies to information which does not require any
3402
analysis of the request or response contents. Those generally include TCP/IP
3403
addresses and ports, as well as internal values independant on the stream.
3404
3405
always_false
3406
This one never matches. All values and flags are ignored. It may be used as
3407
a temporary replacement for another one when adjusting configurations.
3408
3409
always_true
3410
This one always matches. All values and flags are ignored. It may be used as
3411
a temporary replacement for another one when adjusting configurations.
3412
3413
src <ip_address>
3414
Applies to the client's IPv4 address. It is usually used to limit access to
3415
certain resources such as statistics. Note that it is the TCP-level source
3416
address which is used, and not the address of a client behind a proxy.
3417
3418
src_port <integer>
3419
Applies to the client's TCP source port. This has a very limited usage.
3420
3421
dst <ip_address>
3422
Applies to the local IPv4 address the client connected to. It can be used to
3423
switch to a different backend for some alternative addresses.
3424
3425
dst_port <integer>
3426
Applies to the local port the client connected to. It can be used to switch
3427
to a different backend for some alternative ports.
3428
3429
dst_conn <integer>
3430
Applies to the number of currently established connections on the frontend,
3431
including the one being evaluated. It can be used to either return a sorry
3432
page before hard-blocking, or to use a specific backend to drain new requests
3433
when the farm is considered saturated.
3434
3435
nbsrv <integer>
3436
nbsrv(backend) <integer>
3437
Returns true when the number of usable servers of either the current backend
3438
or the named backend matches the values or ranges specified. This is used to
3439
switch to an alternate backend when the number of servers is too low to
3440
to handle some load. It is useful to report a failure when combined with
3441
"monitor fail".
3442
3443
3444
2.3.5.2) Matching at Layer 7
3445
----------------------------
3446
3447
A second set of criteria applies to information which can be found at the
3448
application layer (layer 7). Those require that a full HTTP request has been
3449
read, and are only evaluated then. They may require slightly more CPU resources
3450
than the layer 4 ones, but not much since the request and response are indexed.
3451
3452
method <string>
3453
Applies to the method in the HTTP request, eg: "GET". Some predefined ACL
3454
already check for most common methods.
3455
3456
req_ver <string>
3457
Applies to the version string in the HTTP request, eg: "1.0". Some predefined
3458
ACL already check for versions 1.0 and 1.1.
3459
3460
path <string>
3461
Returns true when the path part of the request, which starts at the first
3462
slash and ends before the question mark, equals one of the strings. It may be
3463
used to match known files, such as /favicon.ico.
3464
3465
path_beg <string>
3466
Returns true when the path begins with one of the strings. This can be used
3467
to send certain directory names to alternative backends.
3468
3469
path_end <string>
3470
Returns true when the path ends with one of the strings. This may be used to
3471
control file name extension.
3472
3473
path_sub <string>
3474
Returns true when the path contains one of the strings. It can be used to
3475
detect particular patterns in paths, such as "../" for example. See also
3476
"path_dir".
3477
3478
path_dir <string>
3479
Returns true when one of the strings is found isolated or delimited with
3480
slashes in the path. This is used to perform filename or directory name
3481
matching without the risk of wrong match due to colliding prefixes. See also
3482
"url_dir" and "path_sub".
3483
3484
path_dom <string>
3485
Returns true when one of the strings is found isolated or delimited with dots
3486
in the path. This may be used to perform domain name matching in proxy
3487
requests. See also "path_sub" and "url_dom".
3488
3489
path_reg <regex>
3490
Returns true when the path matches one of the regular expressions. It can be
3491
used any time, but it is important to remember that regex matching is slower
3492
than other methods. See also "url_reg" and all "path_" criteria.
3493
3494
url <string>
3495
Applies to the whole URL passed in the request. The only real use is to match
3496
"*", for which there already is a predefined ACL.
3497
3498
url_beg <string>
3499
Returns true when the URL begins with one of the strings. This can be used to
3500
check whether a URL begins with a slash or with a protocol scheme.
3501
3502
url_end <string>
3503
Returns true when the URL ends with one of the strings. It has very limited
3504
use. "path_end" should be used instead for filename matching.
3505
3506
url_sub <string>
3507
Returns true when the URL contains one of the strings. It can be used to
3508
detect particular patterns in query strings for example. See also "path_sub".
3509
3510
url_dir <string>
3511
Returns true when one of the strings is found isolated or delimited with
3512
slashes in the URL. This is used to perform filename or directory name
3513
matching without the risk of wrong match due to colliding prefixes. See also
3514
"path_dir" and "url_sub".
3515
3516
url_dom <string>
3517
Returns true when one of the strings is found isolated or delimited with dots
3518
in the URL. This is used to perform domain name matching without the risk of
3519
wrong match due to colliding prefixes. See also "url_sub".
3520
3521
url_reg <regex>
3522
Returns true when the URL matches one of the regular expressions. It can be
3523
used any time, but it is important to remember that regex matching is slower
3524
than other methods. See also "path_reg" and all "url_" criteria.
3525
3526
url_ip <ip_address>
3527
Applies to the IP address specified in the absolute URI in an HTTP request.
3528
It can be used to prevent access to certain resources such as local network.
3529
It is useful with option "http_proxy".
3530
3531
url_port <integer>
3532
Applies to the port specified in the absolute URI in an HTTP request. It can
3533
be used to prevent access to certain resources. It is useful with option
3534
"http_proxy". Note that if the port is not specified in the request, port 80
3535
is assumed.
3536
3537
hdr <string>
3538
hdr(header) <string>
3539
Note: all the "hdr*" matching criteria either apply to all headers, or to a
3540
particular header whose name is passed between parenthesis and without any
3541
space. The header name is not case-sensitive. The header matching complies
3542
with RFC2616, and treats as separate headers all values delimited by commas.
3543
3544
The "hdr" criteria returns true if any of the headers matching the criteria
3545
match any of the strings. This can be used to check exact for values. For
3546
instance, checking that "connection: close" is set :
3547
3548
hdr(Connection) -i close
3549
3550
hdr_beg <string>
3551
hdr_beg(header) <string>
3552
Returns true when one of the headers begins with one of the strings. See
3553
"hdr" for more information on header matching.
3554
3555
hdr_end <string>
3556
hdr_end(header) <string>
3557
Returns true when one of the headers ends with one of the strings. See "hdr"
3558
for more information on header matching.
3559
3560
hdr_sub <string>
3561
hdr_sub(header) <string>
3562
Returns true when one of the headers contains one of the strings. See "hdr"
3563
for more information on header matching.
3564
3565
hdr_dir <string>
3566
hdr_dir(header) <string>
3567
Returns true when one of the headers contains one of the strings either
3568
isolated or delimited by slashes. This is used to perform filename or
3569
directory name matching, and may be used with Referer. See "hdr" for more
3570
information on header matching.
3571
3572
hdr_dom <string>
3573
hdr_dom(header) <string>
3574
Returns true when one of the headers contains one of the strings either
3575
isolated or delimited by dots. This is used to perform domain name matching,
3576
and may be used with the Host header. See "hdr" for more information on
3577
header matching.
3578
3579
hdr_reg <regex>
3580
hdr_reg(header) <regex>
3581
Returns true when one of the headers matches of the regular expressions. It
3582
can be used at any time, but it is important to remember that regex matching
3583
is slower than other methods. See also other "hdr_" criteria, as well as
3584
"hdr" for more information on header matching.
3585
3586
hdr_val <integer>
3587
hdr_val(header) <integer>
3588
Returns true when one of the headers starts with a number which matches the
3589
values or ranges specified. This may be used to limit content-length to
3590
acceptable values for example. See "hdr" for more information on header
3591
matching.
3592
3593
hdr_cnt <integer>
3594
hdr_cnt(header) <integer>
3595
Returns true when the number of occurrence of the specified header matches
3596
the values or ranges specified. It is important to remember that one header
3597
line may count as several headers if it has several values. This is used to
3598
detect presence, absence or abuse of a specific header, as well as to block
3599
request smugling attacks by rejecting requests which contain more than one
3600
of certain headers. See "hdr" for more information on header matching.
3601
3602
3603
2.3.6) Pre-defined ACLs
3604
-----------------------
3605
3606
Some predefined ACLs are hard-coded so that they do not have to be declared in
3607
every frontend which needs them. They all have their names in upper case in
3608
order to avoid confusion. Their equivalence is provided below. Please note that
3609
only the first three ones are not layer 7 based.
3610
3611
ACL name Equivalent to Usage
3612
---------------+-----------------------------+---------------------------------
3613
TRUE always_true 1 always match
3614
FALSE always_false 0 never match
3615
LOCALHOST src 127.0.0.1/8 match connection from local host
3616
HTTP_1.0 req_ver 1.0 match HTTP version 1.0
3617
HTTP_1.1 req_ver 1.1 match HTTP version 1.1
3618
METH_CONNECT method CONNECT match HTTP CONNECT method
3619
METH_GET method GET HEAD match HTTP GET or HEAD method
3620
METH_HEAD method HEAD match HTTP HEAD method
3621
METH_OPTIONS method OPTIONS match HTTP OPTIONS method
3622
METH_POST method POST match HTTP POST method
3623
METH_TRACE method TRACE match HTTP TRACE method
3624
HTTP_URL_ABS url_reg ^[^/:]*:// match absolute URL with scheme
3625
HTTP_URL_SLASH url_beg / match URL begining with "/"
3626
HTTP_URL_STAR url * match URL equal to "*"
3627
HTTP_CONTENT hdr_val(content-length) gt 0 match an existing content-length
3628
---------------+-----------------------------+---------------------------------
3629
3630
3631
2.3.7) Using ACLs to form conditions
3632
------------------------------------
3633
3634
Some actions are only performed upon a valid condition. A condition is a
3635
combination of ACLs with operators. 3 operators are supported :
3636
3637
- AND (implicit)
3638
- OR (explicit with the "or" keyword or the "||" operator)
3639
- Negation with the exclamation mark ("!")
3640
3641
A condition is formed as a disjonctive form :
3642
3643
[!]acl1 [!]acl2 ... [!]acln { or [!]acl1 [!]acl2 ... [!]acln } ...
3644
3645
Such conditions are generally used after an "if" or "unless" statement,
3646
indicating when the condition will trigger the action.
3647
3648
For instance, to block HTTP requests to the "*" URL with methods other than
3649
"OPTIONS", as well as POST requests without content-length, and GET or HEAD
3650
requests with a content-length greater than 0, and finally every request which
3651
is not either GET/HEAD/POST/OPTIONS !
3652
3653
acl missing_cl hdr_cnt(Content-length) eq 0
3654
block if HTTP_URL_STAR !METH_OPTIONS || METH_POST missing_cl
3655
block if METH_GET HTTP_CONTENT
3656
block unless METH_GET or METH_POST or METH_OPTIONS
3657
3658
To select a different backend for requests to static contents on the "www" site
3659
and to every request on the "img", "video", "download" and "ftp" hosts :
3660
3661
acl url_static path_beg /static /images /img /css
3662
acl url_static path_end .gif .png .jpg .css .js
3663
acl host_www hdr_beg(host) -i www
3664
acl host_static hdr_beg(host) -i img. video. download. ftp.
3665
3666
# now use backend "static" for all static-only hosts, and for static urls
3667
# of host "www". Use backend "www" for the rest.
3668
use_backend static if host_static or host_www url_static
3669
use_backend www if host_www
3670
3671
See section 2.2 for detailed help on the "block" and "use_backend" keywords.
3672
3673
3674
2.4) Server options
3675
-------------------
3676
3677
The "server" keyword supports a certain number of settings which are all passed
3678
as arguments on the server line. The order in which those arguments appear does
3679
not count, and they are all optional. Some of those settings are single words
3680
(booleans) while others expect one or several values after them. In this case,
3681
the values must immediately follow the setting name. All those settings must be
3682
specified after the server's address if they are used :
3683
3684
server <name> <address>[:port] [settings ...]
3685
3686
The currently supported settings are the following ones.
3687
3688
addr <ipv4>
3689
Using the "addr" parameter, it becomes possible to use a different IP address
3690
to send health-checks. On some servers, it may be desirable to dedicate an IP
3691
address to specific component able to perform complex tests which are more
3692
suitable to health-checks than the application. This parameter is ignored if
3693
the "check" parameter is not set. See also the "port" parameter.
3694
3695
backup
3696
When "backup" is present on a server line, the server is only used in load
3697
balancing when all other non-backup servers are unavailable. Requests coming
3698
with a persistence cookie referencing the server will always be served
3699
though. By default, only the first operational backup server is used, unless
3700
the "allbackups" option is set in the backend. See also the "allbackups"
3701
option.
3702
3703
check
3704
This option enables health checks on the server. By default, a server is
3705
always considered available. If "check" is set, the server will receive
3706
periodic health checks to ensure that it is really able to serve requests.
3707
The default address and port to send the tests to are those of the server,
3708
and the default source is the same as the one defined in the backend. It is
3709
possible to change the address using the "addr" parameter, the port using the
3710
"port" parameter, the source address using the "source" address, and the
3711
interval and timers using the "inter", "rise" and "fall" parameters. The
3712
request method is define in the backend using the "httpchk", "smtpchk",
3713
and "ssl-hello-chk" options. Please refer to those options and parameters for
3714
more information.
3715
3716
cookie <value>
3717
The "cookie" parameter sets the cookie value assigned to the server to
3718
<value>. This value will be checked in incoming requests, and the first
3719
operational server possessing the same value will be selected. In return, in
3720
cookie insertion or rewrite modes, this value will be assigned to the cookie
3721
sent to the client. There is nothing wrong in having several servers sharing
3722
the same cookie value, and it is in fact somewhat common between normal and
3723
backup servers. See also the "cookie" keyword in backend section.
3724
3725
fall <count>
3726
The "fall" parameter states that a server will be considered as dead after
3727
<count> consecutive unsuccessful health checks. This value defaults to 3 if
3728
unspecified. See also the "check", "inter" and "rise" parameters.
3729
3730
inter <delay>
3731
The "inter" parameter sets the interval between two consecutive health checks
3732
to <delay> milliseconds. If left unspecified, the delay defaults to 2000 ms.
3733
Just as with every other time-based parameter, it can be entered in any other
3734
explicit unit among { us, ms, s, m, h, d }. This parameter also serves as a
3735
timeout for health checks sent to servers. In order to reduce "resonance"
3736
effects when multiple servers are hosted on the same hardware, the
3737
health-checks of all servers are started with a small time offset between
3738
them. It is also possible to add some random noise in the health checks
3739
interval using the global "spread-checks" keyword. This makes sense for
3740
instance when a lot of backends use the same servers.
3741
3742
maxconn <maxconn>
3743
The "maxconn" parameter specifies the maximal number of concurrent
3744
connections that will be sent to this server. If the number of incoming
3745
concurrent requests goes higher than this value, they will be queued, waiting
3746
for a connection to be released. This parameter is very important as it can
3747
save fragile servers from going down under extreme loads. If a "minconn"
3748
parameter is specified, the limit becomes dynamic. The default value is "0"
3749
which means unlimited. See also the "minconn" and "maxqueue" parameters, and
3750
the backend's "fullconn" keyword.
3751
3752
maxqueue <maxqueue>
3753
The "maxqueue" parameter specifies the maximal number of connections which
3754
will wait in the queue for this server. If this limit is reached, next
3755
requests will be redispatched to other servers instead of indefinitely
3756
waiting to be served. This will break persistence but may allow people to
3757
quickly re-log in when the server they try to connect to is dying. The
3758
default value is "0" which means the queue is unlimited. See also the
3759
"maxconn" and "minconn" parameters.
3760
3761
minconn <minconn>
3762
When the "minconn" parameter is set, the maxconn limit becomes a dynamic
3763
limit following the backend's load. The server will always accept at least
3764
<minconn> connections, never more than <maxconn>, and the limit will be on
3765
the ramp between both values when the backend has less than <fullconn>
3766
concurrent connections. This makes it possible to limit the load on the
3767
server during normal loads, but push it further for important loads without
3768
overloading the server during exceptionnal loads. See also the "maxconn"
3769
and "maxqueue" parameters, as well as the "fullconn" backend keyword.
3770
3771
port <port>
3772
Using the "port" parameter, it becomes possible to use a different port to
3773
send health-checks. On some servers, it may be desirable to dedicate a port
3774
to a specific component able to perform complex tests which are more suitable
3775
to health-checks than the application. It is common to run a simple script in
3776
inetd for instance. This parameter is ignored if the "check" parameter is not
3777
set. See also the "addr" parameter.
3778
3779
rise <count>
3780
The "rise" parameter states that a server will be considered as operational
3781
after <count> consecutive successful health checks. This value defaults to 2
3782
if unspecified. See also the "check", "inter" and "fall" parameters.
3783
3784
slowstart <start_time_in_ms>
3785
The "slowstart" parameter for a server accepts a value in milliseconds which
3786
indicates after how long a server which has just come back up will run at
3787
full speed. Just as with every other time-based parameter, it can be entered
3788
in any other explicit unit among { us, ms, s, m, h, d }. The speed grows
3789
linearly from 0 to 100% during this time. The limitation applies to two
3790
parameters :
3791
3792
- maxconn: the number of connections accepted by the server will grow from 1
3793
to 100% of the usual dynamic limit defined by (minconn,maxconn,fullconn).
3794
3795
- weight: when the backend uses a dynamic weighted algorithm, the weight
3796
grows linearly from 1 to 100%. In this case, the weight is updated at every
3797
health-check. For this reason, it is important that the "inter" parameter
3798
is smaller than the "slowstart", in order to maximize the number of steps.
3799
3800
The slowstart never applies when haproxy starts, otherwise it would cause
3801
trouble to running servers. It only applies when a server has been previously
3802
seen as failed.
3803
3804
source <addr>[:<port>] [usesrc { <addr2>[:<port2>] | client | clientip } ]
3805
The "source" parameter sets the source address which will be used when
3806
connecting to the server. It follows the exact same parameters and principle
3807
as the backend "source" keyword, except that it only applies to the server
3808
referencing it. Please consult the "source" keyword for details.
3809
3810
weight <weight>
3811
The "weight" parameter is used to adjust the server's weight relative to
3812
other servers. All servers will receive a load proportional to their weight
3813
relative to the sum of all weights, so the higher the weight, the higher the
3814
load. The default weight is 1, and the maximal value is 255. If this
3815
parameter is used to distribute the load according to server's capacity, it
3816
is recommended to start with values which can both grow and shrink, for
3817
instance between 10 and 100 to leave enough room above and below for later
3818
adjustments.
3819
3820
3821
2.5) HTTP header manipulation
3822
-----------------------------
3823
3824
In HTTP mode, it is possible to rewrite, add or delete some of the request and
3825
response headers based on regular expressions. It is also possible to block a
3826
request or a response if a particular header matches a regular expression,
3827
which is enough to stop most elementary protocol attacks, and to protect
3828
against information leak from the internal network. But there is a limitation
3829
to this : since HAProxy's HTTP engine does not support keep-alive, only headers
3830
passed during the first request of a TCP session will be seen. All subsequent
3831
headers will be considered data only and not analyzed. Furthermore, HAProxy
3832
never touches data contents, it stops analysis at the end of headers.
3833
3834
This section covers common usage of the following keywords, described in detail
3835
in section 2.2.1 :
3836
3837
- reqadd <string>
3838
- reqallow <search>
3839
- reqiallow <search>
3840
- reqdel <search>
3841
- reqidel <search>
3842
- reqdeny <search>
3843
- reqideny <search>
3844
- reqpass <search>
3845
- reqipass <search>
3846
- reqrep <search> <replace>
3847
- reqirep <search> <replace>
3848
- reqtarpit <search>
3849
- reqitarpit <search>
3850
- rspadd <string>
3851
- rspdel <search>
3852
- rspidel <search>
3853
- rspdeny <search>
3854
- rspideny <search>
3855
- rsprep <search> <replace>
3856
- rspirep <search> <replace>
3857
3858
With all these keywords, the same conventions are used. The <search> parameter
3859
is a POSIX extended regular expression (regex) which supports grouping through
3860
parenthesis (without the backslash). Spaces and other delimiters must be
3861
prefixed with a backslash ('\') to avoid confusion with a field delimiter.
3862
Other characters may be prefixed with a backslash to change their meaning :
3863
3864
\t for a tab
3865
\r for a carriage return (CR)
3866
\n for a new line (LF)
3867
\ to mark a space and differentiate it from a delimiter
3868
\# to mark a sharp and differentiate it from a comment
3869
\\ to use a backslash in a regex
3870
\\\\ to use a backslash in the text (*2 for regex, *2 for haproxy)
3871
\xXX to write the ASCII hex code XX as in the C language
3872
3873
The <replace> parameter contains the string to be used to replace the largest
3874
portion of text matching the regex. It can make use of the special characters
3875
above, and can reference a substring which is delimited by parenthesis in the
3876
regex, by writing a backslash ('\') immediately followed by one digit from 0 to
3877
9 indicating the group position (0 designating the entire line). This practice
3878
is very common to users of the "sed" program.
3879
3880
The <string> parameter represents the string which will systematically be added
3881
after the last header line. It can also use special character sequences above.
3882
3883
Notes related to these keywords :
3884
---------------------------------
3885
- these keywords are not always convenient to allow/deny based on header
3886
contents. It is strongly recommended to use ACLs with the "block" keyword
3887
instead, resulting in far more flexible and manageable rules.
3888
3889
- lines are always considered as a whole. It is not possible to reference
3890
a header name only or a value only. This is important because of the way
3891
headers are written (notably the number of spaces after the colon).
3892
3893
- the first line is always considered as a header, which makes it possible to
3894
rewrite or filter HTTP requests URIs or response codes, but in turn makes
3895
it harder to distinguish between headers and request line. The regex prefix
3896
^[^\ \t]*[\ \t] matches any HTTP method followed by a space, and the prefix
3897
^[^ \t:]*: matches any header name followed by a colon.
3898
3899
- for performances reasons, the number of characters added to a request or to
3900
a response is limited at build time to values between 1 and 4 kB. This
3901
should normally be far more than enough for most usages. If it is too short
3902
on occasional usages, it is possible to gain some space by removing some
3903
useless headers before adding new ones.
3904
3905
- keywords beginning with "reqi" and "rspi" are the same as their couterpart
3906
without the 'i' letter except that they ignore case when matching patterns.
3907
3908
- when a request passes through a frontend then a backend, all req* rules
3909
from the frontend will be evaluated, then all req* rules from the backend
3910
will be evaluated. The reverse path is applied to responses.
3911
3912
- req* statements are applied after "block" statements, so that "block" is
3913
always the first one, but before "use_backend" in order to permit rewriting
3914
before switching.
3915
3916
3917
2.6) Logging
3918
------------
3919
3920
[to do]
3921
3922
3923
/*
3924
* Local variables:
3925
* fill-column: 79
3926
* End:
3927
*/
Loggerhead is a web-based interface for Breezy
Version: 2.0.1