转自（可能有一定的修改）:
http://freeloda.blog.51cto.com/2033581/1294094

目录：

1. balance
2. bind
3. mode
4. hash-type
5. log
6. maxconn
7. default_backend
8. server
9. capture request header
10. capture response header
11. stats enable
12. stats hide-version
13. stats realm
14. stats scope
15. stats auth
16. stats admin
17. option httplog
18. option logasap
19. option forwardfor
20. errorfile
21. errorloc 和 errorloc302
22. errorloc303
23. cookie
24. redirect

1.balance

格式：

balance <algorithm> [ <arguments> ]   
balance url_param <param> [check_post [<max_wait>]]

定义负载均衡算法，可用于“defaults”、“listen”和“backend”。<algorithm>用于在负载均衡场景中挑选一个server，其仅应用于持久信息不可用的条件下或需要将一个连接重新派发至另一个服务器时。支持的算法有：

roundrobin：基于权重进行轮叫，在服务器的处理时间保持均匀分布时，这是最平衡、最公平的算法。此算法是动态的，
这表示其权重可以在运行时进行调整，不过，在设计上，使用这种算法时，支持最多 4095 个后端服务器。

所谓运行时调整（on the fly），比如我们做灰度发布时，让一部分服务器下线，然后修改配置。这里让服务器下线，
是通过 HAProxy 的状态页，将其状态切换为维护状态，就可以让其下线了，然后修改配置即可。然后让其上线。

对于 roundrobin 算法，如果新上线一台服务器，负载不是一下子全部分给新服务器，而是慢慢让其承担负载，这就是所谓
的“慢启动”。

static-rr：基于权重进行轮叫，与roundrobin类似，但是为静态方法，在运行时调整其服务器权重不会生效；不过，
其在支持的后端服务器上没有限制；

对于 static-rr 算法，如果新增一台服务器，不会慢启动，负载会立即让其分担。

leastconn：新的连接请求被派发至具有最少连接数目的后端服务器；在有着较长会话时间的场景中推荐使用此算法，
如 LDAP、SQL 等，其并不太适用于较短会话的应用层协议，如 HTTP；此算法是动态的，可以在运行时调整其权重；

source：将请求的源地址进行 hash 运算，并由后端服务器的权重总数相除后派发至某匹配的服务器；这可以使得同一个
客户端IP的请求始终被派发至某特定的服务器；不过，当服务器权重总数发生变化时，如某服务器宕机或添加了新的服务器，
许多客户端的请求可能会被派发至与此前请求不同的服务器；常用于负载均衡无cookie功能的基于TCP的协议；其默认为静态，
不过也可以使用 hash-type 修改此特性（有一种是动态）；

相当于 lvs 的 sh 算法，也相当于 nginx 的 ip-hash 算法。建议用于 TCP 模式的调度，且不支持使用 cookie 插入
模式时使用。不适用于 HTTP 协议。

uri：对URI的左半部分(“?”标记之前的部分)或整个URI进行hash运算，并与服务器的总权重相除后派发至某匹配
的服务器；这可以使得对同一个URI的请求总是被派发至某特定的服务器，除非服务器的权重总数发生了变化；

此算法常用于代理缓存（后端服务器是 Cache server），可以提高缓存的命中率，或反病毒代理；

需要注意的是，此算法仅应用于HTTP后端服务器场景；其默认为静态算法，不过也可以使用 hash-type 修改此特性
（有一种是动态）；

支持两个参数，len 和 depth，比如 uri len 80 depth 4。不过这个很少用得到。

URL 的语法格式：
    <scheme>://<user>:<password>@<host>:<port>/<paht>;<params>?<query>#<frag>
    
    ;<params>
        - ftp://downloads.magedu.com/pub/gnu;type=d
        - http://www.magedu.com/hammers;sale=false/index.html;graphics=ture
        
        params 通常是用来填写表单的数据
        
    ?<query>
        - 有一些资源，比如数据库服务，可以对其发起询问或查询，以缩小请求的资源类型的范围。
          大致相当于 where 查询子句。

url_param：检索每个 HTTP GET 请求中，URL 的请求参数，通过 URL 的请求参数进行调度。即上面所说的 ;<params> 部分。
Apache 的基本认证中，用户名和密码就是通过 ;<params> 发出去的。

这种调度方法，常用于后端服务器需要对用户进行认证的场景中。

如果找到了指定的参数且其通过等于号“=”被赋予了一个值，那么此值将被执行 hash 运算并被服务器的总权重相除后派发
至某匹配的服务器；

此算法可以通过追踪请求中的用户标识进而确保同一个用户ID的请求将被送往同一个特定的服务器，除非服务器的总权重发
生了变化；如果某请求中没有出现指定的参数或其没有有效值，则使用轮叫算法对相应请求进行调度；此算法默认为静态的，
不过其也可以使用hash-type修改此特性（有一种是动态）；

hdr(<name>)：对于每个HTTP请求，通过<name>指定的HTTP首部将会被检索；如果相应的首部没有出现或其没有有效值，
则使用轮叫算法对相应请求进行调度；如果后端服务器有很多虚拟主机，就可以基于 Host 首部字段做 hash。

其有一个可选选项“use_domain_only”，可在指定检索类似Host类的首部时仅计算
域名部分(比如通过www.test.com来说，仅计算test字符串的hash值)以降低hash算法的运算量；
比如有几个虚拟主机都在一个真实服务器上，可以使用 use_domain_only 选项：
    www.magedu.com
    web.magedu.com
    wwww.magedu.com 
        
此算法默认为静态的，不过其也可以使用hash-type修改此特性（有一种是动态）；      


rdp-cookie      
rdp-cookie(name)
    用于 Windows 的远程桌面协议，基本很少用到。

如果对 mysql 服务器进行调度，用什么算法？

leastconn

如果对 ssh 服务器进行调度，用什么算法？

leastconn

如果对图片服务器进行调度，使用什么算法？

rr，因为服务器是直接访问文件系统的。

如果对图片服务器之前的缓存服务器进行调度，使用什么算法？

uri

如果对 web 动态程序服务器进行调度，使用什么算法？

一般需要保持会话，可用 source

但其实要保持会话的话，最理想的方法是基于 cookie 进行调度。

2.bind

格式：

bind [<address>]:<port_range> [, ...]   
bind [<address>]:<port_range> [, ...] interface <interface>

此指令仅能用于 frontend 和 listen 区段，用于定义一个或几个监听的套接字。

<address>：可选选项，其可以为主机名、IPv4地址、IPv6地址或*；省略此选项、将其指定为*或0.0.0.0时，
将监听当前系统的所有IPv4地址；

<port_range>：可以是一个特定的TCP端口，也可是一个端口范围(如5005-5010)，代理服务器将通过指定的端口
来接收客户端请求；需要注意的是，每组监听的套接字<address:port>在同一个实例上只能使用一次，而且小于1024
的端口需要有特定权限的用户才能使用，这可能需要通过 uid 参数来定义；

<interface>：指定物理接口的名称，仅能在Linux系统上使用；其不能使用接口别名，而仅能使用物理接口名称，而且
只有管理有权限指定绑定的物理接口；

例如：

    listen http_proxy
        bind :80, :443
        bind 10.0.0.1:10080, 10.0.0.1:10443

3.mode

格式：

mode { tcp|http|health }

设定实例的运行模式或协议。当实现内容交换时，前端和后端必须工作于同一种模式(一般说来都是HTTP模式)，否则将无法启动实例。

tcp：实例运行于纯 TCP 模式，在客户端和服务器端之间将建立一个全双工的连接，且不会对7层报文做任何类型的检查；
此为默认模式，通常用于 SSL、SSH、SMTP 等应用；

http：实例运行于HTTP模式，客户端请求在转发至后端服务器之前将被深度分析，所有不与 RFC 格式兼容的请求都会被拒绝；

health：实例工作于health模式，其对入站请求仅响应“OK”信息并关闭连接，且不会记录任何日志信息；此模式将用于响应
外部组件的健康状态检查请求；目前来讲，此模式已经废弃，因为tcp或http模式中的monitor关键字可完成类似功能；

4. hash-type

格式：

hash-type <method>

定义用于将 hash 码映射至后端服务器的方法；不能用于 frontend 区段；可用方法有 map-based 和 consistent，
在大多数场景下推荐使用默认的 map-based 方法。

map-based：hash表是一个包含了所有在线服务器的静态数组。其hash值将会非常平滑，会将权重考虑在列，
但其为静态方法，对在线服务器的权重进行调整将不会生效，这意味着其不支持慢速启动。此外，挑选服务器是
根据其在数组中的位置进行的，因此，当一台服务器宕机或添加了一台新的服务器时，大多数连接将会被重新派
发至一个与此前不同的服务器上，对于缓存服务器的工作场景来说，此方法不甚适用。

consistent：hash表是一个由各服务器填充而成的树状结构；基于hash键在hash树中查找相应的服务器时，
最近的服务器将被选中。此方法是动态的，支持在运行时修改服务器权重，因此兼容慢速启动的特性。添加一个
新的服务器时，仅会对一小部分请求产生影响，因此，尤其适用于后端服务器为cache的场景。不过，此算法不
甚平滑，派发至各服务器的请求未必能达到理想的均衡效果，因此，可能需要不时的调整服务器的权重以获得更
好的均衡性。

推荐对 cache servers 执行负载均衡调度时的配置：

balance uri
hash-type consistent

5.log

格式：

log global   
log <address> <facility> [<level> [<minlevel>]]

为每个实例启用事件和流量日志，因此可用于所有区段。每个实例最多可以指定两个log参数，不过，如果使用了“log global”且"global"段已经定了两个log参数时，多余了 log 参数将被忽略。

global：当前实例的日志系统参数同"global"段中的定义时，将使用此格式；每个实例仅能定义一次“log global”语句，且其没有任何额外参数；

<address>：定义日志发往的位置，其格式之一可以为<IPv4_address:PORT>，其中的port为UDP协议端口，
默认为514；格式之二为Unix套接字文件路径，但需要留心chroot应用及用户的读写权限；

<facility>：可以为syslog系统的标准facility之一；

<level>：定义日志级别，即输出信息过滤器，默认为所有信息；指定级别时，所有等于或高于此级别的日志信息将会被发送；

6.maxconn

格式：

maxconn <conns>

设定一个前端的最大并发连接数，因此，其不能用于backend区段。对于大型站点来说，可以尽可能提高此值以便让haproxy管理连接队列，从而避免无法应答用户请求。当然，此最大值不能超出“global”段中的定义。此外，需要留心的是，haproxy会为每个连接维持两个缓冲，每个缓冲的大小为8KB，再加上其它的数据，每个连接将大约占用17KB的RAM空间。这意味着经过适当优化后，有着1GB的可用RAM空间时将能维护 40000-50000 并发连接。

如果为<conns>指定了一个过大值，极端场景下，其最终占据的空间可能会超出当前主机的可用内存，这可能会带来意想不到的结果；因此，将其设定了一个可接受值方为明智决定。其默认为2000。

7.default_backend

格式：

default_backend <backend>

在没有匹配的"use_backend"规则时，为实例指定使用的默认后端，因此，其不可应用于backend区段。在"frontend"和"backend"之间进行内容交换时，通常使用"use-backend"定义其匹配规则；而没有被规则匹配到的请求将由此参数指定的后端接收。

<backend>：指定使用的后端的名称；
使用案例：

use_backend     dynamic  if  url_dyn
use_backend     static   if  url_css url_img extension_img
default_backend dynamic

8.server

格式：

server <name> <address>[:port] [param*]

为后端声明一个server，因此，不能用于defaults和frontend区段。

<name>：为此服务器指定的内部名称，其将出现在日志及警告信息中；如果设定了"http-send-server-name"，它
还将被添加至发往此后端服务器的请求首部中；

<address>：此服务器的的IPv4地址，也支持使用可解析的主机名，只不过在启动时需要解析主机名至相应的IPv4地址；

[:port]：指定将连接请求所发往的此服务器时的目标端口，其为可选项；未设定时，将使用客户端请求时的同一相端口；
当前端绑定了多个端口时（参考 bind 指令），就不要指定端口了。

[param*]：为此服务器设定的一系参数；其可用的参数非常多，具体请参考官方文档中的说明，下面仅说明几个常用的参数；

服务器或默认服务器参数 [param*]：

backup：设定为备用服务器，仅在负载均衡场景中的其它 server 均不可用于启用此 server；

check：启动对此server执行健康状态检查，其可以借助于额外的其它参数完成更精细的设定，如：
    
    inter <delay>：设定健康状态检查的时间间隔，单位为毫秒，默认为2000；也可以使用fastinter和downinter
    来根据服务器端状态优化此时间延迟；      

    rise <count>：设定健康状态检查中，某离线的server从离线状态转换至正常状态需要成功检查的次数；      

    fall <count>：确认server从正常状态转换为不可用状态需要检查的次数；

cookie <value>：为指定server设定cookie值，此处指定的值将在请求入站时被检查，第一次为此值挑选
的server将在后续的请求中被选中，其目的在于实现持久连接的功能；

maxconn <maxconn>：指定此服务器接受的最大并发连接数；如果发往此服务器的连接数目高于此处指定的值，
其将被放置于请求队列，以等待其它连接被释放；

maxqueue <maxqueue>：设定请求队列的最大长度；

observe <mode>：通过观察服务器的通信状况来判定其健康状态，默认为禁用，其支持的类型有“layer4”和“layer7”，
“layer7”仅能用于http代理场景；

redir <prefix>：启用重定向功能，将发往此服务器的GET和HEAD请求均以302状态码响应；需要注意的是，
在prefix后面不能使用/，且不能使用相对地址，以免造成循环；例如：server srv1 172.16.100.6:80 redir 
http://imageserver.test.com check

weight <weight>：权重，默认为1，最大值为256，0表示不参与负载均衡；

执行健康检查的方式，有多种方式，对于 web 服务器，使用 httpchk，对于 mysql 服务器可以使 mysql-check，
还有其他的 check 选项，请参考官方文档。

option httpchk 
    表示基于 HTTP 协议做7层检查。比如请求主页，得到 200 响应码就可以

option httpchk <uri>    
    指定请求的 uri，默认为 /

option httpchk <method> <uri>    
    指定请求的方法，默认方法为 OPTIONS，因为这个方法不需要太多的处理，而且容易从日志中过滤出来。
    指定请求的 uri，默认为 /

option httpchk <method> <uri> <version>：不能用于 frontend 段
    指定请求的方法、uri、版本，例如：

# Relay HTTPS traffic to Apache instance and check service availability
# using HTTP request "OPTIONS * HTTP/1.1" on port 80.
backend https_relay
    mode tcp
    option httpchk OPTIONS * HTTP/1.1\r\nHost:\ www.test.com
    server apache1 192.168.1.1:443 check port 80
    
HAProxy 的工作模式是 tcp 模式。但要使用 http 检查。这里要明确定义使用什么 method 进行检查。
方法为 OPTIONS，uri 为 *，协议为 HTTP/1.1，因为 1.1 协议要求必须携带 Host首部，所以这里也
进行了指定。

使用案例：

server first  172.16.100.7:1080 cookie first  check inter 1000
server second 172.16.100.8:1080 cookie second check inter 1000

9.capture request header

格式：

capture request header <name> len <length>

在日志中添加额外的信息。

捕获并在日志中记录指定的请求首部最近一次出现时的第一个值，仅能用于“frontend”和“listen”区段。

捕获的首部值使用花括号{}括起来后添加进日志中。如果需要捕获多个首部值，它们将以指定的次序出现在日志文件中，并以竖线“|”作为分隔符。

不存在的首部记录为空字符串，最常需要捕获的首部包括在虚拟主机环境中使用的“Host”、上传请求首部中的“Content-length”、快速区别真实用户和网络机器人的“User-agent”，以及代理环境中记录真实请求来源的“X-Forward-For”。

<name>：要捕获的首部的名称，此名称不区分字符大小写，但建议与它们出现在首部中的格式相同，比如大写首字母。
需要注意的是，记录在日志中的是首部对应的值，而非首部名称。

<length>：指定记录首部值时所记录的精确长度，超出的部分将会被忽略。

可以捕获的请求首部的个数没有限制，但每个捕获最多只能记录64个字符。为了保证同一个frontend中日志格式的统一性，首部捕获仅能在frontend中定义。

示例：
capture request header Host len 15
capture request header X-Forwarded-For len 15
capture request header Referer len 15

10.capture response header

格式：

capture response header <name> len <length>

在日志中添加额外的信息。

捕获并记录响应首部，其格式和要点同请求首部。

示例：
capture response header Content-length len 9
capture response header Location len 15

11.stats enable

格式：

启用基于程序编译时默认设置的统计报告，不能用于“frontend”区段。只要没有另外的其它设定，它们就会使用如下的配置：

stats uri   : /haproxy?stats
stats realm : "HAProxy Statistics"
stats auth  : no authentication
stats scope : no restriction

尽管“stats enable”一条就能够启用统计报告，但还是建议设定其它所有的参数，以免其依赖于默认设定而
带来非预期后果。下面是一个配置案例。

backend public_www
  server websrv1 172.16.100.11:80
  stats enable
  stats hide-version
  stats scope   .
  stats uri     /haproxyadmin?stats
  stats realm   Haproxy\ Statistics
  stats auth    statsadmin:password
  stats auth    statsmaster:password

12.stats hide-version

格式：

stats hide-version

启用统计报告并隐藏 HAProxy 版本报告，不能用于“frontend”区段。默认情况下，统计页面会显示一些有用信息，
包括 HAProxy 的版本号，然而，向所有人公开HAProxy的精确版本号是非常有风险的，因为它能帮助恶意用户快速定
位版本的缺陷和漏洞。

尽管“stats hide-version”一条就能够启用统计报告，但还是建议设定其它所有的参数，以免其依赖于默认设定而
带来非期后果。具体请参照“stats enable”一节的说明。

13.stats realm

格式：

stats realm <realm>

启用统计报告，并且设置认证领域，不能用于“frontend”区段。

haproxy在读取 realm 时会将其视作一个单词，因此，中间的任何空白字符都必须使用反斜线进行转义。
此参数仅在与“stats auth”配合使用时有意义。

<realm>：实现HTTP基本认证时显示在浏览器中的领域名称，用于提示用户输入一个用户名和密码。

尽管“stats realm”一条就能够启用统计报告，但还是建议设定其它所有的参数，以免其依赖于默认设定而带来
非期后果。具体请参照“stats enable”一节的说明。

示例：
# public access (limited to this backend only)
backend public_www
server srv1 192.168.0.1:80
stats enable
stats hide-version
stats scope .
stats uri /admin?stats
stats realm Haproxy\ Statistics
stats auth admin1:AdMiN123
stats auth admin2:AdMiN321

# internal monitoring access (unlimited)
backend private_monitoring
    stats enable
    stats uri     /admin?stats
    stats refresh 5s

14.stats scope

格式：

stats scope { <name> | "." }

启用统计报告并限定报告的区段，不能用于 “frontend” 区段。

当指定此语句时，统计报告将仅显示其列举出区段的报告信息，所有其它区段的信息将被隐藏。如果需要显示多个区段的统计报告，此语句可以定义多次。需要注意的是，区段名称检测仅仅是以字符串比较的方式进行，它不会真检测指定的区段是否真正存在。

<name>：可以是一个“listen”、“frontend”或“backend”区段的名称，而“.”则表示 stats scope
语句所定义的当前区段。

尽管“stats scope”一条就能够启用统计报告，但还是建议设定其它所有的参数，以免其依赖于默认设定而
带来非期后果。下面是一个配置案例。

backend private_monitoring
    stats enable
    stats uri     /haproxyadmin?stats
    stats refresh 10s

15.stats auth

格式：

stats auth <user>:<passwd>

启用带认证的统计报告功能并授权一个用户帐号，其不能用于“frontend”区段。

<user>：授权进行访问的用户名；
<passwd>：此用户的访问密码，明文格式；

此语句将基于默认设定启用统计报告功能，并仅允许其定义的用户访问，其也可以定义多次以授权多个用户帐号。可以结合“stats realm”参数在提示用户认证时给出一个领域说明信息。在使用非法用户访问统计功能时，
其将会响应一个“401 Forbidden”页面。

其认证方式为HTTP Basic认证，密码传输会以明文方式进行，因此，配置文件中也使用明文方式存储以说明其非
保密信息故此不能相同于其它关键性帐号的密码。

尽管“stats auth”一条就能够启用统计报告，但还是建议设定其它所有的参数，以免其依赖于默认设定
而带来非期后果。

16.stats admin

stats admin { if | unless } <cond>

开启管理功能。

在指定的条件满足时启用统计报告页面的管理级别功能，它允许通过web接口启用或禁用服务器，
不过，基于安全的角度考虑，统计报告页面应该尽可能为只读的。

此外，如果启用了HAProxy的多进程模式，启用此管理级别将有可能导致异常行为。

目前来说，POST 请求方法被限制于仅能使用缓冲区减去保留部分之外的空间，因此，服务器列表不能过长，否则，
此请求将无法正常工作。因此，建议一次仅调整少数几个服务器。下面是两个案例，第一个限制了仅能在本机打开报告页面时启用管理级别功能，第二个定义了仅允许通过认证的用户使用管理级别功能。

backend stats_localhost
    stats enable
    stats admin if LOCALHOST
backend stats_auth
    stats enable
    stats auth  haproxyadmin:password
    stats admin if TRUE

17.option httplog

格式：

option httplog [ clf ]

启用记录 HTTP 请求、会话状态和计时器的功能。

clf：使用CLF格式来代替HAProxy默认的HTTP格式，通常在使用仅支持CLF格式的特定日志分析器时才需要使用此格式。

默认情况下，日志输入格式非常简陋，因为其仅包括源地址、目标地址和实例名称，而“option httplog”参数将会使得日志格式变得丰富许多，其通常包括但不限于HTTP请求、连接计时器、会话状态、连接数、捕获的首部及cookie、“frontend”、“backend”及服务器名称，当然也包括源地址和端口号等。

18.option logasap

格式：

option logasap   
no option logasap

启用或禁用提前将HTTP请求记入日志，不能用于“backend”区段。

默认情况下，HTTP请求是在请求结束时进行记录，以便能将其整体传输时长和字节数记入日志，由此，传较大的对象时，其记入日志的时长可能会略有延迟。
“option logasap” 参数能够在服务器发送 complete 首部时即时记录日志，只不过，此时将不记录整体传输时长和字节数。此情形下，
捕获“Content-Length”响应首部来记录传输的字节数是一个较好选择。下面是一个例子。

listen http_proxy 0.0.0.0:80
    mode http
    option httplog
    option logasap
    log 172.16.100.9 local2

19.option forwardfor

格式：

option forwardfor [ except <network> ] [ header <name> ] [ if-none ]

允许在发往后端服务器的请求首部中插入“X-Forwarded-For”首部。

<network>：可选参数，当指定时，源地址为匹配至此网络中的请求都禁用此功能。

<name>：可选参数，可使用一个自定义的首部，如“X-Client”来替代“X-Forwarded-For”。
有些独特的web服务器的确需要用于一个独特的首部。

if-none：仅在此首部不存在时才将其添加至请求报文中。

HAProxy工作于反向代理模式，其发往服务器的请求中的客户端IP均为HAProxy主机的地址而非真正客户端的地址，这会使得服务器端的日志信息记录不了真正的请求来源。

“X-Forwarded-For”首部则可用于解决此问题。HAProxy可以向每个发往服务器的请求上添加此首部，并以客户端IP为其value。

需要注意的是，HAProxy工作于隧道模式，其仅检查每一个连接的第一个请求，因此，仅第一个请求报文被附加此首部。如果想为每一个请求都附加此首部，请确保同时使用了这几个option：

option httpclose
option forceclose
option http-server-close

下面是一个例子。

frontend www
    mode http
    option forwardfor except 127.0.0.1

20.errorfile

格式：

errorfile <code> <file>

在用户请求不存在的页面时，返回一个页面文件给客户端而非由haproxy生成的错误代码；可用于所有段中。

<code>：指定对HTTP的哪些状态码返回指定的页面；这里可用的状态码有200、400、403、408、500、502、503和504；
<file>：指定用于响应的页面文件；

例如：

errorfile 400 /etc/haproxy/errorpages/400badreq.http
errorfile 403 /etc/haproxy/errorpages/403forbid.http
errorfile 503 /etc/haproxy/errorpages/503sorry.http

21.errorloc 和 errorloc302

格式：

errorloc <code> <url>   
errorloc302 <code> <url>    

请求错误时，返回一个HTTP重定向至某URL的信息；可用于所有配置段中。

<code>：指定对HTTP的哪些状态码返回指定的页面；这里可用的状态码有200、400、403、408、500、502、503和504；

<url>：Location首部中指定的页面位置的具体路径，可以是在当前服务器上的页面的相对路径，也可以使用绝对路径；
需要注意的是，如果URI自身错误时产生某特定状态码信息的话，有可能会导致循环定向；

需要留意的是，这两个关键字都会返回302状态吗，这将使得客户端使用同样的HTTP方法获取指定的URL，对于非GET方法的场景(如POST)来说会产生问题，因为返回客户的URL是不允许使用GET以外的其它方法的。如果的确有这种问题，可以使用errorloc303来返回303状态码给客户端。

22.errorloc303

errorloc303 <code> <url>

请求错误时，返回一个HTTP重定向至某URL的信息给客户端；可用于所有配置段中。

<code>：指定对HTTP的哪些状态码返回指定的页面；这里可用的状态码有400、403、408、500、502、503和504；

<url>：Location首部中指定的页面位置的具体路径，可以是在当前服务器上的页面的相对路径，也可以使用绝对路径；
需要注意的是，如果URI自身错误时产生某特定状态码信息的话，有可能会导致循环定向；

例如：

backend webserver
  server 172.16.100.6 172.16.100.6:80 check maxconn 3000 cookie srv01
  server 172.16.100.7 172.16.100.7:80 check maxconn 3000 cookie srv02
  errorloc 403 /etc/haproxy/errorpages/sorry.htm
  errorloc 503 /etc/haproxy/errorpages/sorry.htm

23. cookie

cookie <name> [ rewrite | insert | prefix ] [ indirect ] [ nocache ]
[ postonly ] [ preserve ] [ httponly ] [ secure ]
[ domain <domain> ]* [ maxidle <idle> ] [ maxlife <life> ]

在 backend 中激活基于 cookie 的持久连接。

适用于：default, listen, backend

参数说明：

<name>:
指定 cookie 的名字。该 cookie 可能被监测、修改、插入信息。这个 cookie 由响应报文的 Set-Cookie header 发送给客户端（只发送一次）。客户端收到该 cookie 后，在其请求报文的 Cookie header 中携带该 cookie。

应特别注意，不要使该 cookie 的名字与其他 cookie 冲突。
不同的 backends 应使用不同的 cookie name

在一个 HTTP backend 中之只能定义一个 persistent cookie。

例如我们在一个 backend 中定义：
    cookie SRV insert indirect nocache

在该 backend 中，cookie 的值在 server 语句中定义：
    server first  10.1.1.1:1080 cookie first  check inter 1000
    server second 10.1.1.2:1080 cookie second check inter 1000

如果第一次请求调度至第一个服务器，cookie 的值为 first；如果调度至第二个服务器，cookie 的值为 second；

Set-Cookie 首部的内容包含：SRV=first/second，客户端收到之后，以后向该域名路径发送的请求，都会携带有包含 
SRV=first/second 的 cookie。根据 cookie 的值为 first or second，请求被调度至第一个或者
第二个服务器。这就是基于 cookie 的连接保持。这时是根据 cookie 的值来调度的，不是基于算法，即使
backend 的算法是 roundrobin 算法，也不会进行轮询调度。

24. redirect

语法：

redirect location <loc> [code <code>] <option> [{if | unless} <condition>]
redirect prefix   <pfx> [code <code>] <option> [{if | unless} <condition>]
redirect scheme   <sch> [code <code>] <option> [{if | unless} <condition>]

使用范围： frontend, backend, listen

If/unless the condition is matched, the HTTP request will lead to a redirect
response. If no condition is specified, the redirect applies unconditionally.

如果/除非 条件满足，返回重定向给客户端；如果未指定条件，表示直接返回重定向。

参数说明：

<loc>

redirect location <loc>；

使 Location 首部的值等于 loc;

<pfx>

redirect prefix <pfx>；

构建 Location 首部为：<pfx> + 完整的 URI path + query string；

• 如果使用了 "drop-query" 选项，表示不添加 query string；

• 如果 <pfx> = /，那么不需要重新构建 URI；适用的场景：重定向至同一个 URL，但是插入一个 cookie；

<sch>

redirect scheme <sch>；

构建 Location 首部为：<sch> + "://" + 第一个 Host 首部字段的值 + URI path + query sting

• 如果使用了 "drop-query" 选项，表示不添加 query string；

• 如果没有给出 URI path，或者 path = *，则使用 "/" 替代 URI path；

• 如果找不到 Host 首部字段，则返回空的 Host 首部，大部分浏览器将其解释为：重定向到同一个 host；

常用于将 HTTP 重定向至 HTTPS

<code>

<code> 是可选的；用于指定重定向的状态码，不同的重定向码表示不同的重定向类型，支持使用 301, 302, 303, 307 and 308；

302 是默认状态码；

301 表示："Moved permanently" 永久重定向；浏览器可以将这个 Location 进行缓存

302 表示："Moved temporarily" 临时重定向；浏览器不应该缓存这个 Location

303 表示：与 302 相同，但浏览器会使用 GET 方法获取 location

307 表示：与 302 相同，但会明确让浏览器使用同一个 method

308 表示：与 301 相同，但会明确让浏览器使用同一个 method

<option>

选项是用于调整重定向的行为的：

"drop-query"

用于 prefix-based redirection 和 sch-based redirection，表示设置 Location 字段时，不添加 query string；

使用场景举例：将用户导向一个非安全的页面；

"append-slash"

这个选项和 drop-query 合用时，可将不是以 '/' 重定向至同一个 Location ，但在尾部添加上 '/'；

这个修改可确保搜索引擎只看到一个 URL；

这时最好使用 301 作为状态码；

"set-cookie NAME[=value]"

在重定向响应中添加一个 "Set-Cookie" 首部字段；

这使得用户的下一次访问会携带 cookie，利用这一点可以防御某些类型的 DoS 攻击；

因为没有添加其他的 cookie 选项，所以这里设置的 cookie 是唯一的 cookie，这是其成为一个 session cookie；

注意，对于浏览器而言，一个不带 = 符号的 cookie name，和带了 = 符号的 cookie name 是不同的；

"clear-cookie NAME[=]"

在重定向响应中添加一个 "Set-Cookie" 首部字段，但 "Max-Age" 属性被设置为 0，浏览器会删除这个 cookie；

使用场景举例：访问了一个登出页面 logout page，表示要退出访问，这时为安全考虑最好删除 cookie，以免被人盗取，这对于提高安全性是有好处的；

特别要注意，"clear-cookie NAME" 和 "clear-cookie NAME=" 是不同的；前者不会删除这样的 cookie: "NAME=value"，必须使用 "clear-cookie NAME=" 删除这样的 cookie，这一点不同是因为浏览器而产生的，因为浏览器对其进行不同的处理。

示例1：Move the login URL only to HTTPS. 强制用户使用 HTTPS 协议访问登陆页面

acl clear      dst_port  80
acl secure     dst_port  8080
acl login_page url_beg   /login
acl logout     url_beg   /logout
acl uid_given  url_reg   /login?userid=[^&]+
acl cookie_set hdr_sub(cookie) SEEN=1

redirect prefix   https://mysite.com set-cookie SEEN=1 if !cookie_set # 如果用户访问时不携带 cookie，让其重定向使用 HTTPS 访问，并且为其设置 cookie
redirect prefix   https://mysite.com           if login_page !secure # 访问登陆页面，但不是访问的安全端口，重定向使用 HTTPS 协议
redirect prefix   http://mysite.com drop-query if login_page !uid_given # 访问登陆页面，但没有给出 userid 信息，让用户重新填写登陆信息
redirect location http://mysite.com/           if !login_page secure # 访问非登陆页面，但却要求使用安全端口，这没必要，让用户重定向到普通页面
redirect location / clear-cookie USERID=       if logout # 登出之后，让浏览器删除 cookie USERID=value，且重定向到首页

示例2：Send redirects for request for articles without a '/'.

acl missing_slash path_reg ^/article/[^/]*$
redirect code 301 prefix / drop-query append-slash if missing_slash # 不改变 URI，改变默认状态码为 301，删除 query string，并在 URI 尾部添加 "/"

示例3：Redirect all HTTP traffic to HTTPS when SSL is handled by haproxy.
acl is_ssl dst_port 8080
redirect scheme https if !is_ssl