* 一）全局配置 * 进程管理及安全相关的参数 1、chroot 《Dir》 修改haproxy的工作目录至指定的目录 2、demon 让haproxy以守护进程的方式工作于后台 3、user 指定运行haproxy的用户 4、group 指定运行haproxy的组 5、log <address> <facility> 定义全局的syslog服务器，最多定义2个 6、nbproc 《number》 指定启动haproxy进程的格式，默认只启动一个进程 7、pidfile： 指定pid文件 8、ulimit -n 设置每进程所能够打开的最大文件描述符数目，默认情况会自动进行计算，因此不建议修改 * 性能调整相关 1、maxconn 《number》设定没哥哥haproxy进程所接受的最大并发连接数 2、spread-check 《0-50，in percent》 在haproxy后端有众多服务器的场景中，在精确的时间间隔后统一对众服务器进行健康检查可能会带来意外问题。此选项用于将其检查的时间间隔长度上增加或减少一定的随机时长 二） 设置代理服务配置 * balance 指明调度算法 1）roundroubin 基于权重进行轮询（支持动态调整）每个后端主机最多支持4128个连接 2）static-rr 静态的轮询（不支持动态调整），每个后端主机支持的数量无上限 3）leastconn 最少连接数 4）source 将请求的源地址进行hash计算，并由后端服务器的权重总数相除后派发至某个服务器，可以实现同一客户端的ip请求，始终定向到某一台服务器上 hash-type： map-based 取模法 consistent 一致性哈希算法 5） uri 对URI的左半部分（问号之前的部分）或整个URI进行计算，并由服务器的总权重相除后派发至某台服务器，这样可以使得同一个uri请求总是被派送至某台服务器上（hash值/总权重） hash-type 6）url_param 根据用户请求中的params中，根据params中的值来进行hash计算，并由服务器的总权重相除后派发至某台服务器 （hash值/总权重） hash-type 7) hdr(name) 根据请求报文中header参数来调度。根据请求报文中所指定的header，如use_agent，cookie，referer，hostname，把指定的header的值做hash计算 hash-type 案例： balance hdr(User-Agent) hash-type consistent * bind 指定绑定ip和端口 bind [<address>]:<port_range> [, ...] [param*] 说明： address：可选选项，可以为主机名，IP地址，省略此选项表示*或0.0.0.0 port_range: 可以是一个特定的tcp端口，也可是一个端口范围（80-85） 案例 listen http_proxy bind :80,:443 bind 10.0.0.1:10080,10.0.0.1:10443 bind /var/run/ssl-frontend.sock user root mode 600 accept-proxy listen http_https_proxy bind :80 bind :443 ssl crt /etc/haproxy/site.pem listen http_https_proxy_explicit bind ipv6@:80 bind ipv4@public_ssl:443 ssl crt /etc/haproxy/site.pem bind unix@ssl-frontend.sock user root mode 600 accept-proxy * mode 功能：设置实例运行的模式或协议。前端和后端必须工作于同一模式（一般都是http模式） mode { tcp|http|health } tcp为默认模式 http：运行于http模式，可将请求在转发至后端服务器之前将被深度分析 health：健康检查（一般不用，因为tcp和http模式中的monitor关键字有类似功能） defaults http_instances mode http * log 功能：定义日志，每个实例最多可以指定2个log，如果使用log global，而global段又定义了2个log，那么在实例中另外配置多余的log参数将被忽略 log global log <address> [len <length>] <facility> [<level> [<minlevel>]] 说明： facility： local0 local1 local2 local3 local4 local5 local6 local7 level： emerg alert crit err warning notice info debug * maxconn <conns> 功能：设置前端的最大的并发连接数，默认为2000  * default_backend 功能：指定默认后端 案例： use_backend dynamic if url_dyn use_backend static if url_css url_img extension_img default_backend dynamic * server server <name> <address>[:[port]] [param*] 说明： name： 为此服务器指定内部名称 address： 后端服务器的地址 port：端口 params： backup 备用服务器，只有当后端服务器都不能用的时候，这个才发挥作用 check：启动对此server执行健康检查 addr ：检测时使用的IP地址； port ：针对此端口进行检测 inter： 设置健康检查的时间间隔，默认为2000毫秒 rise： 从离线到正常，需要成功检查的次数 fall： 从正常到失败，需要检查的次数 cookie： 为指定server设置cookie值，此处指定的值将在请求入栈时被检查（持久连接功能） maxconn: 定义此服务器的最大并发连接数 maxqueue <number> 设置请求队列的最大长度 weight： 权重，默认为1,0表示不参与负载均衡，最大值为256 * HAproxy健康检查的三种方式 option httpchk 语法： option httpchk option httpchk <uri> option httpchk <method> <uri> option httpchk <method> <uri> <version> 1)通过监听端口进行健康检测 。这种检测方式，haproxy只会去检查后端server的端口，并不能保证服务的真正可用 option httpchk server web1 192.168.1.1:80 cookie server01 check server web2 192.168.1.2:80 cookie server02 check 2)通过URI获取进行健康检测 。检测方式，是用过去GET后端server的的web页面 option httpchk GET /index.html 3)通过request获取的头部信息进行匹配进行健康检测 option httpchk HEAD /index.jsp HTTP/1.1\r\nHost:\ www.xxx.com option httpchk HEAD /test3.html HTTP/1.1\r\nHost:\ test.51yuki.cn * haproxy 三种保持客户端Seesion 1)源地址hash（IP地址） haroxy 将用户IP经过hash计算后 ，除以后端服务器总权重数，然后分配给某一台服务器 案例： balance source 2）cookie 识别 haproxy 将WEB服务端返回给客户端的cookie中插入haproxy中特定的字符串(或添加前缀)在后端的服务器COOKIE ID。 cookie语法： cookie <name> [ rewrite | insert | prefix ] [ indirect ] [ nocache ] [ postonly ] [ preserve ] [ httponly ] [ secure ] [ domain <domain> ]* [ maxidle <idle> ] [ maxlife <life> ] [ dynamic ] 说明： [ rewrite | insert | prefix ] /*三者互斥，只能选一*/ （insert最为常用） rewrite //表示cookie由服务器生成并且haproxy会在其值中注入该服务器的标识符;此关键字不能在HTTP隧道模式下工作。 insert //表示如果客户端没有cookie信息且有权限访问服务器时，持久性cookie必须通过haproxy穿插在服务器的响应报文中。当服务器收到相同名称的cookie并且没有“preserve（保存）”选项时，将会移除之前已存的cookie信息。因此，insert可视作"rewrite"的升级版。cookie信息仅仅作为会话cookie且不会存到客户端的磁盘上。默认除非加了“indirect(间接)”选项，否则服务器端会看到客户端端发送的cookie信息。由于缓存的影响，最好加上“nocache”或“postonly”选项。 prefix //表示不依赖专用的cookie做持久性，而是依赖现成的。用在某些特殊的场景，如客户端不支持一个以上的cookie和应用程序需求它。每当服务器建立一个名为<name>的cookie时，它将以服务器的标识符和分隔符为前缀。来自于客户端的请求报文中的前缀将会被删除以便服务器端能识别出它所发出的cookie，由于请求和响应报文都被修改过，所以此模式不能工作在隧道模式中。且不能和“indirect”共用，否则服务器端更新的cookie将不会被发到客户端. [ indirect ] //指定此选项时，将不会向客户端发送服务器已经处理过请求的且可用的cookie信息。如果服务器设置这样一个cookie本身，它将被删除，除非“保存”选项也设置。在“插入”模式下，将从发送给服务器的请求中删除cookie，使持久机制从应用程序的角度完全透明。 [ nocache ] //当客户端和haproxy间存在缓存时，使用此选项和insert搭配最好，以便确保如果一个cookie需要被插入时，可被缓存的响应会被标记成不可缓存。这很重要，举个例子：如果所有的持久cookie被添加到一个可缓存的主页上，之后所有的客户将从外部高速缓存读取页面并将共享相同的持久性cookie，会造成服务器阻塞。 案例： backend websrvs #balance hdr(User-Agent) balance roundrobin #hash-type consistent mode http cookie SRV insert indirect nocache option httpchk HEAD /test3.html HTTP/1.1\r\nHost:\ test.51yuki.cn server node7.51yuki.cn 192.168.20.132:8081 cookie web1 check inter 3000 rise 3 fall 3 weight 1 server node8:51yuki.cn 192.168.20.133:8081 cookie web2 check inter 3000 rise 3 fall 3 weight 2 server proxy01.51yuki.cn 192.168.20.131:8081 backup  3）基于session appsession <cookie> len <length> timeout <holdtime> [request-learn] [prefix] [mode <path-parameters|query-string>] haproxy 将后端服务器产生的session和后端服务器标识存在haproxy中的一张表里。客户端请求时先查询这张表。 * 启用haproxy的状态监控页 1）stats enable 开启统计报告 2）stats uri /haproxy?stats 3) stats hide-version 隐藏版本号 4) stats realm 提示信息 5）stats admin if TRUE（如果登录成功，就启动管理） 案例： listen status bind 10.2.13.220:8888 stats enable stats hide-version #stats scope . stats uri /haproxyadmin?stats stats realm Haproxy\ Statistics stats auth statsadmin:Aa123456 stats admin if TRUE * option参数 1）option httplog 启用记录http请求，回话状态和计时器的功能 2）option except 《NETWORK》 允许在发往服务器的请求首部中插入"X-Forwarded-For"首部 3) option forwardfor 案例： frontend main 10.2.13.220:80 #acl url_static path_beg -i /static /images /javascript /stylesheets #acl url_static path_end -i .jpg .gif .png .css .js #use_backend static if url_static #option forwardfor excepet 127.0.0.1 if-none option forwardfor except 127.0.0.1 default_backend websrvs 案例： backend websrvs #balance hdr(User-Agent) balance roundrobin option forwardfor header X-Client * errorfile errorfile <code> <file> 在用户请求一个不存在的页面，返回一个页面文件给客户端 * 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>] 案例： 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 redirect prefix https://mysite.com if login_page !secure redirect prefix http://mysite.com drop-query if login_page !uid_given redirect location http://mysite.com/ if !login_page secure redirect location / clear-cookie USERID= if logout * reqadd和rspadd reqadd <string> [{if | unless} <cond>] （haproxy发送给后端backend服务器） acl is-ssl dst_port 81 reqadd X-Proto:\ SSL if is-ssl rspadd <string> [{if | unless} <cond>] （haproxy响应给客户端添加） * 连接超时时长： timeout connect： 定义haproxy将客户端请求转发至后端服务器所等待的超时时长 timeout client：客户端非活动状态的超时时长 timeout server：客户端与服务器端建立连接后，等待服务器端的超时时长， timeout http-keep-alive ：定义保持连接的超时时长 * 压缩 compression algo <algorithm> ... compression type <mime type> ... 案例： compression algo gzip compression type text/html text/plain * haproxy实现request请求重定向 http-request redirect 1）位置重定向 http-request redirect location <loc> [code <code>] [<option>] [<condition>] 2）前缀重定向 http-request redirect prefix <pfx> [code <code>] [<option>] [<condition>] 案例： 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 redirect prefix https://mysite.com if login_page !secure redirect prefix http://mysite.com drop-query if login_page !uid_given redirect location http://mysite.com/ if !login_page secure redirect location / clear-cookie USERID= if logout redir重定向的用法:(redir通常配置在haproxy backend部分） 案例： server node1 127.0.0.1:81 check weight 3 redir http://www.bluemobi.cn 注意：path后面不能加/ 网友博客：http://blog.51cto.com/blief/1752669 二）ACL 第一步：定义ACL acl <aclname> <criterion> [flags] [operator] [<value>] ... aclname：ACL名称，区分字符大小写 flags： -i： 不区分模式中的大小写 -f： 从指定文件加载模式 --： 标志位强制结束标记 value： 整数 字符串 IP地址和网络地址 正则表达式 逻辑操作符： and or 非 常用的测试标准： * be_sess_rate 用于测试指定的backend上会话创建的速率是否满足指定的条件。常用于阻止攻击行为 案例： backend dynamic mode http acl being_scanned be_sess_rate gt 100 redirect location /denied.html if being_scanned （重定向） * fe_sess_rate 用于测试指定的frontend上的会话创建速率是否满足是定条件 案例： frontend mail bind :25 mode tcp maxconn 100 acl too_fast fe_sess_rate ge 10 tcp-request inspect-delay 100ms tcp-request content accept if ! too_fast tcp-request content accept if WAIT_END * hdr<header> 用于测试请求报文中所有首部或指定首部是否满足指定条件 hdr([<name>[,<occ>]]) : exact string match hdr_beg([<name>[,<occ>]]) : prefix match hdr_dir([<name>[,<occ>]]) : subdir match hdr_dom([<name>[,<occ>]]) : domain match hdr_end([<name>[,<occ>]]) : suffix match hdr_len([<name>[,<occ>]]) : length match hdr_reg([<name>[,<occ>]]) : regex match hdr_sub([<name>[,<occ>]]) : substring match 案例： acl host_www hdr_beg(host) -i www acl host_static hdr_beg(host) -i img. video. download. ftp. * path_beg 《string》 用于测试请求url是否以string指定的模式开头 * path_end 《string》 用于测试请求url是否以string指定的模式结尾 案例： acl url_static path_beg /static /images /img /css acl url_static path_end .gif .png .jpg .css .js * hdr_beg <string> * hdr_end <string> 案例： acl host_www hdr_beg(host) -i www acl host_static hdr_beg(host) -i img. video. download. ftp. * url_beg * url_end ACL derivatives : url : exact string match url_beg : prefix match url_dir : subdir match url_dom : domain match url_end : suffix match url_len : length match url_reg : regex match url_sub : substring match 第二步：应用ACL，条件满足，执行特定操作 * use_backend * tcp_request * http_request * redirect