Linux：haproxy

一.负载均衡的类型

1.1 四层负载均衡

1.通过ip+port决定负载均衡的去向。

2.对流量请求进行NAT处理，转发至后台服务器。

3.记录tcp、udp流量分别是由哪台服务器处理，后续该请求连接的流量都通过该服务器处理。

4.支持四层的软件

        lvs：重量级四层负载均衡器。

        Nginx：轻量级四层负载均衡器，可缓存。

        Haproxy：模拟四层转发。

 特点：client与server之间有直接通信

1.2 七层负载均衡

1.通过虚拟ur|或主机ip进行流量识别，根据应用层信息进行解析，决定是否需要进行负载均衡。

2.代理后台服务器与客户端建立连接，如nginx可代理前后端，与前端客户端tcp连接，与后端服务器建立tcp连接

3.支持7层代理的软件：

        Nginx:基于http协议(nginx七层是通过proxy_pass)

        Haproxy:七层代理，会话保持、标记、路径转移等。

特点：代理服务器与client，代理服务器与server之间的链接时独立的。

1.3 四层负载均衡与七层负载均衡的区别

四层的负载均衡，就是通过发布三层的IP地址（VIP），然后加四层的端口号，来决定哪些流量需要做负 载均衡，对需要处理的流量进行NAT处理，转发至后台服务器，并记录下这个TCP或者UDP的流量是由哪 台服务器处理的，后续这个连接的所有流量都同样转发到同一台服务器处理。

七层的负载均衡，就是在四层的基础上（没有四层是绝对不可能有七层的），再考虑应用层的特征，比 如同一个Web服务器的负载均衡，除了根据VIP加80端口辨别是否需要处理的流量，还可根据七层的URL、浏览器类别、语言来决定是否要进行负载均衡。

四层负载均衡：架构相对简单，功能相对单一，但性能最优。

七层负载均衡：功能复杂，架构复杂，对硬件要求高，功能性和安全性比四层好。

在企业中，四层负载均衡与七层负载均衡穿插存在。

二.haproxy的安装以及实验环境的设置

2.1 软件安装（下图为已安装过的主机）注：要在haproxy主机中安装。

 2.2 实验环境

haproxy：

关闭火墙并开启haproxy服务

rs服务器：

关闭防火墙，安装和开启nginx服务，编写nginx的默认发布文件（下图以rs1为例，rs1为编程过的主机）

效果：

三.haproxy的负载均衡集群

为了不影响实验结果，将除global和proxies的配置段注释。

自定义一个web集群服务

 效果：

四.haproxy的基本配置信息

HAProxy 的配置文件haproxy.cfg由两大部分组成，分别是：

global：全局配置段

        进程及安全配置相关的参数

        性能调整相关参数

        Debug参数

proxies：代理配置段

        defaults：为frontend, backend, listen提供默认配置

        frontend：前端，相当于nginx中的server {}

        backend：后端，相当于nginx中的upstream {}

        listen：同时拥有前端和后端配置,配置简单,生产推荐使用

4.1 global配置

4.1.1 global 配置参数说明

 log：定义全局的syslog服务器；日志服务器需要开启UDP协 议，最多可以定义两个

chroot：如图为锁定/var/lib/haproxy为运行目录

pidfile：指定/var/run/haproxy.pid为pid文件

maxconn：指定最大连接数

maxconnrate：指定每个客户端每秒建立连接的最大数量

user：指定haproxy的运行用户

group：指定haproxy的运行组

daemon：指定haproxy以守护进程方式运行

nbproc 2：指定haproxy的work进程数量，默认是1个

cpu-map 1 0：指定第一个work绑定第一个cpu核心（核心的数量从0开始）

cpu-map 2 1：指定第二个work绑定第二个cpu核心

nbthread 2：启用多线程

stats socket /var/lib/haproxy/stats：指定haproxy的套接字文件

maxsslconn 100000：每个haproxy进程ssl最大连接数,用于haproxy配置了证书的场景下

4.1.2 多进程和线程

4.1.2.1 多进程的设置和查看

多进程的设置：

 多进程的查看（注：再查看之前要重启haproxy服务）：

设置多进程之前：

设置多进程之后：

 4.1.2.2 多线程的设置和查看

多线程的设置（注：不能同时设置多进程和多线程，否则系统会报错）：

 多线程的查看（注：再查看之前要重启haproxy服务）：

先查看haproxy的进程号

设置多线程之前 ：

设置多线程之后：

4.2 proxies配置

4.2.1 proxies参数说明

4.2.1.1 Proxies配置-defaults

        mode                   http：HAProxy实例使用的连接协议

        log                       global：指定日志地址和记录日志条目的syslog/rsyslog日志设备，此处的 global表示使用 global配置段中 设定的log值。

      option                   httplog：日志记录选项，httplog表示记录与HTTP会话相关的各种属性值，包括HTTP请求、会话状态、连接数、源地址以及连接时间等

      option                   dontlognull：dontlognull表示不记录空会话连接日志

      option                   http-server-close：等待客户端完整HTTP请求的时间，此处为等待10s。

      option forwardfor  except 127.0.0.0/8：透传客户端真实IP至后端web服务器，在webserver中看日志即可看到地址透传信息

      option                   redispatch：当server IP对应的服务器挂掉后，强制定向到其他健康的服务器

      option                   http-keep-alive：开启与客户端的会话保持

      retries                   3：连接后端服务器失败次数

      timeout http-request   10s：等待客户端请求完全被接收和处理的最长时间

      timeout queue           1m：设置删除连接和客户端收到503或服务不可用等提示信息前的等待时间

      timeout connect         120s：设置等待服务器连接成功的时间

      timeout client         600s：设置允许客户端处于非活动状态，即既不发送数据也不接收数据的时间

      timeout server         600s：设置服务器超时时间，即允许服务器处于既不接收也不发送数据的非活动时间

      timeout http-keep-alive 60s：session 会话保持超时时间，此时间段内会转发到相同的后端服务器

      timeout check           10s：指定后端服务器健康检查的超时时间

      maxconn                   3000：haproxy所能承受的最大连接数量

      default-server inter 1000：对后端服务器检测的时间间隔为一千毫秒一次

      weight 3 ：权重为3

4.2.1.2 Proxies配置-frontend

frontend 配置示例：

frontend 配置参数： 

bind：指定HAProxy的监听地址，可以是IPV4或IPV6，可以同时监听多个IP或端口，可同时用于listen字段中

格式：

bind [<address>]:<prot_range> [...] [param*] 注意：如果需要绑定在非本机的IP，需要开启内核参数：net.ipv4.ip_nonlocal_bind=1

backlog：针对所有server配置,当前端服务器的连接数达到上限后的后援队列长度，注意：不支持backend

4.2.1.3 Proxies配置-backend

定义一组后端服务器，backend服务器将被frontend进行调用。

注意: backend 的名称必须唯一,并且必须在listen或frontend中事先定义才可以使用,否则服务无法启动

mode http|tcp       ：指定负载协议类型,和对应的frontend必须一致

option                   ：配置选项

server                   ：定义后端real server,必须指定IP和端口

注意：option后面加 httpchk，smtpchk,mysql-check,pgsql-check，ssl-hello-chk方法，可用于实现更多应用层检测功能。

backend配置（server）及示例:

check         #对指定real进行健康状态检查，如果不加此设置，默认不开启检查,只有check后面没 有其它配置也可以启用检查功能

                   #默认对相应的后端服务器IP和端口,利用TCP连接进行周期性健康性检查,注意必须指定 端口才能实现健康性检查

addr            #可指定的健康状态监测IP，可以是专门的数据网段，减少业务网络的流量

port             #指定的健康状态监测端口

inter            #健康状态检查间隔时间，默认2000 ms

fall              #后端服务器从线上转为线下的检查的连续失效次数，默认为3

rise             #后端服务器从下线恢复上线的检查的连续有效次数，默认为2

weight        #默认为1，最大值为256，0(状态为蓝色)表示不参与负载均衡，但仍接受持久连接

backup       #将后端服务器标记为备份状态,只在所有非备份主机down机时提供服务，类似Sorry Server

disabled     #将后端服务器标记为不可用状态，即维护状态，除了持久模式#将不再接受连接,状态为深黄色,优雅下线,不再接受新用户的请求

redirect prefix http://www.baidu.com/   #将请求临时(302)重定向至其它URL，只适用于http模 式

maxconn                       #当前后端server的最大并发连接数

4.2.1.4 Proxies配置-listen 简化配置

使用listen替换 frontend和backend的配置方式，可以简化设置，通常只用于TCP协议的应用

listen配置示例：

五.haproxy的算法

5.1 静态算法

静态算法：按照事先定义好的规则轮询公平调度，不关心后端服务器的当前负载、连接数和响应速度 等，且无法实时修改权重(只能为0和1,不支持其它值)，只能靠重启HAProxy生效。

5.1.1 static-rr 

（1）不支持运行时利用socat进行权重的动态调整(只支持0和1,不支持其它值)

（2）不支持端服务器慢启动

支持运行时利用socat进行权重调整

5.1.2 first

根据服务器在列表中的位置，自上而下进行调度

其只会当第一台服务器的连接数达到上限，新请求才会分配给下一台服务

其会忽略服务器的权重设置

不支持用socat进行动态修改权重,可以设置0和1,可以设置其它值但无效

5.2 动态算法

动态算法：

基于后端服务器状态进行调度适当调整

新请求将优先调度至当前负载较低的服务器

权重可以在haproxy运行时动态调整无需重启

5.2.1 roundrobin

1. 基于权重的轮询动态调度算法，

2. 支持权重的运行时调整，不同于lvs中的rr轮训模式，

3. HAProxy中的roundrobin支持慢启动(新加的服务器会逐渐增加转发数)，

4. 其每个后端backend中最多支持4095个real server，

5. 支持对real server权重动态调整，

6. roundrobin为默认调度算法,此算法使用广泛

支持用socat动态调整权重

5.2.2 leastconn

leastconn加权的最少连接的动态

支持权重的运行时调整和慢启动，即:根据当前连接最少的后端服务器而非权重进行优先调度(新客户 端连接)

比较适合长连接的场景使用

 支持用socat动态调整权重

5.3 其他算法

其他算法即可作为静态算法又可通过选项成为动态算法

5.3.1 source

源地址hash，基于用户源地址hash并将请求转发到后端服务器，后续同一个源地址请求将被转发至同一 个后端web服务器。此方式当后端服务器数据量发生变化时，会导致很多用户的请求转发至新的后端服 务器，默认为静态方式，但是可以通过hash-type支持的选项更改这个算法一般是在不插入Cookie的TCP模式下使用，也可给拒绝会话cookie的客户提供最好的会话粘性，适用session会话保持但不支持cookie和缓存的场景源地址有两种转发客户端请求到后端服务器的服务器选取计算方式，分别是取模法和一致性hash

 效果：

5.3.1.1  map-base 取模法

map-based：取模法，对source地址进行hash计算，再基于服务器总权重的取模，最终结果决定将此请 求转发至对应的后端服务器。 此方法是静态的，即不支持在线调整权重，不支持慢启动，可实现对后端服务器均衡调度

缺点是当服务器的总权重发生变化时，即有服务器上线或下线，都会因总权重发生变化而导致调度结果 整体改变

例：

        所谓取模运算，就是计算两个数相除之后的余数，10%7=3, 7%4=3

        map-based算法：基于权重取模，hash(source_ip)%所有后端服务器相加的总权重

 5.3.1.2 一致性hash

一致性哈希，当服务器的总权重发生变化时，对调度结果影响是局部的，不会引起大的变动hash

该hash算法是动态的，支持使用 socat等工具进行在线权重调整，支持慢启动

算法：

1、后端服务器哈希环点keyA=hash(后端服务器虚拟ip)%(2^32)

2、客户机哈希环点key1=hash(client_ip)%(2^32) 得到的值在[0---4294967295]之间，

3、将keyA和key1都放在hash环上，将用户请求调度到离key1最近的keyA对应的后端服务器

hash环偏斜问题

增加虚拟服务器IP数量，比如：一个后端服务器根据权重为1生成1000个虚拟IP，再hash。而后端服务器权重为2则生成2000的虚拟IP，再bash,最终在hash环上生成3000个节点，从而解决hash环偏斜问题

一致性hash示意图

后端服务器在线与离线的调度方式

 sorce一致性哈希配置示例

 若需将source设置成动态算法需在配置文件中添加一致性哈希并重启haproxy服务

5.3.2 uri

基于对用户请求的URI的左半部分或整个uri做hash，再将hash结果对总权重进行取模后 根据最终结果将请求转发到后端指定服务器 适用于后端是缓存服务器场景 默认是静态算法，也可以通过hash-type指定map-based和consistent，来定义使用取模法还是一致性hash

注：

        此算法基于应用层，所以只支持 mode http ，不支持 mode tcp

uri取模法配置示例

 uri一致性哈希配置示例

5.3.3 url_param

url_param对用户请求的url中的 params 部分中的一个参数key对应的value值作hash计算，并由服务器 总权重相除以后派发至某挑出的服务器,后端搜索同一个数据会被调度到同一个服务器，多用与电商 通常用于追踪用户，以确保来自同一个用户的请求始终发往同一个real server

如果无没key，将按roundrobin算法

url_param取模法配置示例

 url_param一致性哈希配置示例

效果：

5.3.4 hdr

针对用户每个http头部(header)请求中的指定信息做hash， 此处由 name 指定的http首部将会被取出并做hash计算， 然后由服务器总权重取模以后派发至某挑出的服务器，如果无有效值，则会使用默认的轮询调度。

hdr取模法配置示例

 hdr一致性哈希配置示例

效果：

六.haproxy的高级功能及配置

6.1 基于cookie的会话保持

cookie value：为当前server指定cookie值，实现基于cookie的会话黏性，相对于基于 source 地址hash调度算法对客户端的粒度更精准，但同时也加大了haproxy负载，目前此模式使用较少， 已经被session共享服务器代替

注：仅支持http mode，不支持tcp mode。

6.1.1 配置选项

name： cookie 的 key名称，用于实现持久连接（上图name为WEBCOOKIE)

insert： 插入新的cookie,默认不插入cookie indirect： #如果客户端已经有cookie,则不会再发送cookie信息

nocache： 当client和hapoxy之间有缓存服务器（如：CDN）时，不允许中间缓存器缓存cookie，因为这会导致很多经过同一个CDN的请求都发送到同一台后端服务器

 6.1.2 配置示例

6.1.3 验证cookie信息

6.2 haproxy状态页

6.2.1 状态页配置项

stats enable：基于默认的参数启用stats page stats hide-version   #将状态页中haproxy版本隐藏

stats refresh：设定自动刷新时间间隔，默认不自动刷新

stats uri：自定义stats page uri，默认值：/haproxy?stats

stats auth<user>:<passwd>：认证时的账号和密码，可定义多个用户,每行指定一个用户

                                                #默认：no authentication

stats admin { if | unless }<cond>：启用stats page中的管理功能

6.2.2 启动状态页

配置文件：/etc/haproxy/haproxy.cfg

 浏览器访问：

                     http:172.25.254.100:3456/status

6.2.3 登陆状态页

账号/密码： 配置文件的stats auth 的lee：lee

pid为当前pid号，process为当前进程号，nbproc和nbthread为一共多少进程和每个进程多少个线程pid = 27134 (process #1, nbproc = 1, nbthread = 1)

(1)启动了多长时间

uptime = 0d 0h00m04s

(2)系统资源限制：内存/最大打开文件数/

system limits: memmax = unlimited; ulimit-n = 200029

(3)最大socket连接数/单进程最大连接数/最大管道数

maxpipes maxsock = 200029; maxconn = 100000; maxpipes = 0

(4)当前连接数/当前管道数/当前连接速率

current conns = 2; current pipes = 0/0; conn rate = 2/sec; bit rate = 0.000 kbps

(5)运行的任务/当前空闲率

Running tasks: 1/14; idle = 100 % active UP： 在线服务器

backup UP： 标记为backup的服务器

active UP, going down： 监测未通过正在进入down过程

backup UP, going down： 备份服务器正在进入down过程

active DOWN, going up： down的服务器正在进入up过程

backup DOWN, going up： 备份服务器正在进入up过程

active or backup DOWN： 在线的服务器或者是backup的服务器已经转换成了down状态

not checked： 标记为不监测的服务器

(6)active或者backup服务器人为下线的

active or backup DOWN for maintenance (MAINT)

(7)active或者backup被人为软下线(人为将weight改成0)

active or backup SOFT STOPPED for maintenance

6.2.4 backend server 信息

session rate(每秒的连接会话信息): Errors(错误统计信息)：

cur:每秒的当前会话数量 : Req:错误请求量

max:每秒新的最大会话数量 conn:错误链接量

limit:每秒新的会话限制量 Resp:错误响应量

sessions(会话信息): Warnings(警告统计信息)：

cur:当前会话量 Retr:重新尝试次数

max:最大会话量 Redis:再次发送次数

limit: 限制会话量

Total:总共会话量 Server(real server信息)：

LBTot:选中一台服务器所用的总时间 Status:后端机的状态，包括UP和DOWN Last：和服务器的持续连接时间 LastChk:持续检查后端服务器的时间

Wght:权重

Bytes(流量统计)： Act:活动链接数量

In:网络的字节输入总量 Bck:备份的服务器数量

Out:网络的字节输出总量 Chk:心跳检测时间

Dwn:后端服务器连接后都是DOWN的数量

Denied(拒绝统计信息)： Dwntme:总的downtime时间

Req:拒绝请求量 Thrtle:server 状态

Resp:拒绝回复量

6.3 IP透传

web服务器中需要记录客户端的真实IP地址，用于做访问统计、安全防护、行为分析、区域排行等场景。

6.3.1 四层IP透传

开启四层IP透传

配置文件：/etc/nginx/nginx.conf（注：配置后需重启nginx服务）

四层IP透传若想透传客户端IP需打开在配置文件中设置' "$proxy_protocol_addr" '

配置文件：/etc/haproxy/haproxy.cfg （注：配置后需重启haproxy服务）

 效果：

6.3.2 七层IP透传

当haproxy工作在七层的时候，也可以透传客户端真实IP至后端服务器

haproxy配置

在由haproxy发往后端主机的请求报文中添加“X-Forwarded-For"首部，其值为前端客户端的地址；用于 向后端主发送真实的客户端IP（注：配置完后需重启haproxy服务）

 nginx服务器设置（注：配置后需要重启服务）

效果：

6.4 ACL

访问控制列表ACL，Access Control Lists）

是一种基于包过滤的访问控制技术

它可以根据设定的条件对经过服务器传输的数据包进行过滤(条件匹配)即对接收到的报文进行匹配和过 滤，基于请求报文头部中的源地址、源端口、目标地址、目标端口、请求方法、URL、文件后缀等信息内 容进行匹配并执行进一步操作，比如允许其通过或丢弃。

 效果：

 6.4.1 ACL配置选项

用acl来定义或声明一个acl

acl     <aclname>      <criterion>    [flags]          [operator]     [<value>]

acl     名称                匹配规范       匹配模式     具体操作符   操作对象类型

6.4.2 ACL-Name名称

acl        test        path_end        -m        sub /a

ACL名称，可以使用大字母A-Z、小写字母a-z、数字0-9、冒号：、点.、中横线和下划线，并且严格区分大 小写，比如:my_acl和My_Acl就是两个完全不同的acl

6.4.3 ACL-criterion匹配规则

定义ACL匹配规范，即：判断条件

hdr string，提取在一个HTTP请求报文的首部

hdr（[ [，]]）：完全匹配字符串,header的指定信息， 表示在多值中使用的值的出 现次数

hdr_beg（[ [，]]）：前缀匹配，header中指定匹配内容的begin hdr_end（[ [，]]）：后缀匹配，header中指定匹配内容end hdr_dom（[ [，]]）：域匹配，header中的dom（host）

hdr_dir（[ [，]]）：路径匹配，header的uri路径

hdr_len（[ [，]]）：长度匹配，header的长度匹配

hdr_reg（[ [，]]）：正则表达式匹配，自定义表达式(regex)模糊匹配

hdr_sub（[ [，]]）：子串匹配，header中的uri模糊匹配 模糊匹配c 报文中a/b/c也会匹配

#示例：

hdr() 用于测试请求头部首部指定内容

hdr_dom(host) 请求的host名称，如 www.timinglee.org hdr_beg(host) 请求的host开头，如 www.   img.   video.   download.   ftp. hdr_end(host) 请求的host结尾，如 .com   .net   .cn

#示例：

acl bad_agent hdr_sub(User-Agent) -i curl wget

http-request deny  if bad_agent

#有些功能是类似的，比如以下几个都是匹配用户请求报文中host的开头是不是www

acl short_form hdr_beg(host)                      www.

acl alternate1 hdr_beg(host)           -m beg www.

acl alternate2 hdr_dom(host)          -m beg www.

acl alternate3 hdr(host)                   -m beg www.

base : string

#返回第一个主机头和请求的路径部分的连接，该请求从主机名开始，并在问号之前结束,对虚拟主机有用

<scheme>://<user>:<password>@#<host>:<ports>/<path>;<params>#?<query>#<frag>

base     : exact string match

base_beg : prefix match

base_dir : subdir match

base_dom : domain match

base_end : suffix match

base_len : length match

base_reg : regex match

base_sub : substring match

path : string

#提取请求的URL路径，该路径从第一个斜杠开始，并在问号之前结束（无主机部分）

<scheme>://<user>:<password>@<host>:<ports>#/<path>;<params>#?<query>#<frag>

path          : exact string match

path_beg  : prefix match  #请求的URL开头，如/static、/images、/img、/css

path_end  : suffix match  #请求的URL中资源的结尾，如 .gif .png .css .js .jpg .jpeg

path_dom : domain match

path_dir : subdir match

path_len : length match

path_reg : regex match

path_sub : substring match

#示例：

path_beg -i /haproxy-status/

path_end .jpg .jpeg .png .gif

path_reg ^/images.*\.jpeg$

path_sub image  

path_dir jpegs

path_dom timinglee

url : string

#提取请求中的整个URL。

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

dst                 :目标IP

dst_port         :目标PORT

src                  :源IP

src_port          :源PORT

#示例：

acl invalid_src src 10.0.0.7 192.168.1.0/24

acl invalid_src src 172.16.0.0/24

acl invalid_port src_port 0:1023

status : integer  #返回在响应报文中的状态码

#七层协议

acl valid_method method GET HEAD

http-request deny if ! valid_method

6.4.4 ACL-flags 匹配模式

ACL匹配模式

-i 不区分大小写

-m 使用指定的正则表达式匹配方法

-n 不做DNS解析

-u 禁止acl重名，否则多个同名ACL匹配或关系

6.4.5 ACL-operator 具体操作符

ACL 操作符

整数比较：eq、ge、gt、le、lt

字符比较：

exact match     (-m str) :字符串必须完全匹配模式

substring match (-m sub) :在提取的字符串中查找模式，如果其中任何一个被发现，ACL将匹配

prefix match   (-m beg) :在提取的字符串首部中查找模式，如果其中任何一个被发现，ACL将匹配

suffix match   (-m end) :将模式与提取字符串的尾部进行比较，如果其中任何一个匹配，则ACL进行匹配

subdir match   (-m dir) :查看提取出来的用斜线分隔（“/"）的字符串，如其中任一个匹配，则ACL

进行匹配

domain match   (-m dom) :查找提取的用点（“."）分隔字符串，如果其中任何一个匹配，则ACL进行匹配

6.4.6 ACL-value 操作对象

value的类型

The ACL engine can match these types against patterns of the following types :

- Boolean                         #布尔值

- integer or integer range #整数或整数范围，比如用于匹配端口范围

- IP address / network      #IP地址或IP范围, 192.168.0.1 ,192.168.0.1/24

- string--> www.timinglee.org exact          #精确比较

substring                          #子串

suffix                                #后缀比较

prefix                                #前缀比较

subdir                               #路径， /wp-includes/js/jquery/jquery.js

domain                             #域名，www.timinglee.org

- regular expression         #正则表达式

- hex block                       #16进制

6.4.7 多个ACL的组合调用方式

多个ACL的逻辑处理

与：隐式（默认）使用

或：使用“or" 或 “||"表示

否定：使用 "!" 表示

多个ACL调用方式

#示例：

if valid_src valid_port #与关系，ACL中A和B都要满足为true，默认为与

if invalid_src || invalid_port  #或，ACL中A或者B满足一个为true

if ! invalid_src #非，取反，不满足ACL才为true

6.5 自定义HAProxy 错误界面

对指定的报错进行重定向，进行优雅的显示错误页面 使用errorfile和errorloc指令的两种方法，可以实现自定义各种错误页面

 6.5.1 基于自定义的错误页面文件

自定义错误页（注：需要先将服务器的nginx服务关闭）

errorfile <code> <file>

<code>#HTTP status code.支持200, 400, 403, 405, 408, 425, 429, 500, 502，503,504

<file>#包含完整HTTP响应头的错误页文件的绝对路径。 建议后缀".http"，以和一般的html文件相区分

示例：

配置文件：/etc/haproxy/haproxy.cfg

 新建目录：/etc/haproxy/errorpath/

配置文件：/etc/haproxy/errorpath/503.http

 效果：

 6.5.2 基于http重定向错误页面

 配置文件：/etc/haproxy/haproxy.cfg

 效果（浏览器中访问172.25.254.100）：

6.6  HAProxy 四层负载

针对除HTTP以外的TCP协议应用服务访问的应用场景

如：

        MySQL

        Redis

        Memcache

        RabbitMQ

四层负载示例

注意：如果使用frontend和backend，一定在 frontend 和 backend 段中都指定mode tcp

 示例：对MySQL服务进行四层负载均衡

rs（如图以rs1为例）：

 开启mariadb服务

 配置文件：/etc/my.cnf.d/mariadb-server.cnf

效果：

 注：client客户端需安装mariadb服务--dnf install mariadb -y

6.7 HAProxy https 实现

haproxy可以实现https的证书安全,从用户到haproxy为https,从haproxy到后端服务器用http通信 但基于性能考虑,生产中证书都是在后端服务器比如nginx上实现

6.7.1 证书制作

 6.7.2 http配置示例

效果：