* 一）全局配置 * 進程管理及安全相關的參數 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