Haproxy配置說明

Haproxy介紹

haproxy是一個開源的反向代理或者說是負載均衡服務服務軟件之一，它支持雙機熱備、虛擬主機、基於TCP和http應用代理、具備圖形界面等功能，並且有很好的對服務節點的健康檢查功能，當期代理的後端服務器出現故障時，haproxy會自動的將該服務器摘除，當服務器的故障恢復後haproxy還會自動將該RS服務器加入。

 

Haproxy特別適用於那些訪問量很大，但又須要會話保持或七層應用的業務。Haproxy運行在普通的服務器硬件上，僅僅進行簡單的配置就能夠支持數以萬計的鏈接。而且他的運行模式使得它能夠很簡單安全的整合到各類網站的架構中（能夠代替lvs,nginx等負載均衡設備），同時使得應用服務器不會暴露到網絡上。（NAT模式）

環境說明：

haproxy  ip地址172.16.4.100

web-01   ip地址172.16.4.101

web-02  ip地址172.16.102

使用系統均爲centos6.6 64位

Haproxy安裝

Haproxy在centos6.6系統的安裝光盤中已經自帶直接使用yum安裝便可。

[root@haproxy ~]# yum -y install haproxy

Haproxy的文件

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

啓動腳本：etc/rc.d/init.d/haproxy

主程序：/usr/bin/halog

日誌管理和分析：usr/bin/halog

Ip地址範圍段管理和分析：usr/bin/iprange

配置組成段

 全局配置：

    Global

代理配置：

   Default，frontend，backend，listen

優先級： 

   命令行參數、global、proxies

全局配置

「global」配置中的參數爲進程級別的參數，且一般與其運行的OS相關。

 

 * 進程管理及安全相關的參數

   - chroot <jail dir>：修改haproxy的工做目錄至指定的目錄並在放棄權限以前執行chroot()操做，能夠提高haproxy的安全級別，不過須要注意的是要確保指定的目錄爲空目錄且任何用戶均不能有寫權限；

   - daemon：讓haproxy以守護進程的方式工做於後臺，其等同於「-D」選項的功能，固然，也能夠在命令行中以「-db」選項將其禁用；

   - gid <number>：以指定的GID運行haproxy，建議使用專用於運行haproxy的GID，以避免因權限問題帶來風險；

   - group <group name>：同gid，不過指定的組名；

   - log <address> <facility> [max level [min level]]：定義全局的syslog服務器，最多能夠定義兩個；

   - log-send-hostname [<string>]：在syslog信息的首部添加當前主機名，能夠爲「string」指定的名稱，也能夠缺省使用當前主機名；

   - nbproc <number>：指定啓動的haproxy進程的個數，只能用於守護進程模式的haproxy；默認只啓動一個進程，鑑於調試困難等多方面的緣由，通常只在單進程僅能打開少數文件描述符的場景中才使用多進程模式；

   -pidfile：指定haproxy進程的pid文件。啓動進程的用戶必須有訪問此進程的權限。

   - uid：以指定的UID身份運行haproxy進程；

   - ulimit-n：設定每進程所可以打開的最大文件描述符數目，默認狀況下其會自動進行計算，所以不推薦修改此選項；

   - user：同uid，但使用的是用戶名；

   - node：定義當前節點的名稱，用於HA場景中多haproxy進程共享同一個IP地址時；

   - description：當前實例的描述信息；

 

 * 性能調整相關的參數

   - maxconn <number>：設定每一個haproxy進程所接受的最大併發鏈接數，其等同於命令行選項「-n」；「ulimit -n」自動計算的結果正是參照此參數設定的；

   - maxpipes <number>：haproxy使用pipe完成基於內核的tcp報文重組，此選項則用於設定每進程所容許使用的最大pipe個數；每一個pipe會打開兩個文件描述符，所以，「ulimit -n」自動計算時會根據須要調大此值；默認爲maxconn/4，其一般會顯得過大；

   - noepoll：在Linux系統上禁用epoll機制；

   - nokqueue：在BSD系統上禁用kqueue機制；

   - nopoll：禁用poll機制；

   - nosepoll：在Linux禁用啓發式epoll機制；

   - nosplice：禁止在Linux套接字上使用內核tcp重組，這會致使更多的recv/send系統調用；不過，在Linux 2.6.25-28系列的內核上，tcp重組功能有bug存在；

   - spread-checks <0..50, in percent>：在haproxy後端有着衆多服務器的場景中，在精確的時間間隔後統一對衆服務器進行健康情況檢查可能會帶來意外問題；此選項用於將其檢查的時間間隔長度上增長或減少必定的隨機時長；

   - tune.bufsize <number>：設定buffer的大小，一樣的內存條件下，較小的值可讓haproxy有能力接受更多的併發鏈接，較大的值可讓某些應用程序使用較大的cookie信息；默認爲16384，其能夠在編譯時修改，不過強烈建議使用默認值；

   - tune.chksize <number>：設定檢查緩衝區的大小，單位爲字節；更大的值有助於在較大的頁面中完成基於字符串或模式的文本查找，但也會佔用更多的系統資源；不建議修改；

   - tune.maxaccept <number>：設定haproxy進程內核調度運行時一次性能夠接受的鏈接的個數，較大的值能夠帶來較大的吞吐率，默認在單進程模式下爲100，多進程模式下爲8，設定爲-1能夠禁止此限制；通常不建議修改；

   - tune.maxpollevents  <number>：設定一次系統調用能夠處理的事件最大數，默認值取決於OS；其值小於200時可節約帶寬，但會略微增大網絡延遲，而大於200時會下降延遲，但會稍稍增長網絡帶寬的佔用量；

   - tune.maxrewrite <number>：設定爲首部重寫或追加而預留的緩衝空間，建議使用1024左右的大小；在須要使用更大的空間時，haproxy會自動增長其值；

   - tune.rcvbuf.client <number>：面對客戶端的接收緩衝

   - tune.rcvbuf.server <number>：設定內核套接字中服務端或客戶端接收緩衝的大小，單位爲字節；強烈推薦使用默認值；

   - tune.sndbuf.client：面對客戶端的發送緩衝

   - tune.sndbuf.server：面對服務器端的接收緩衝

 

 * Debug相關的參數

   -debug：調試模式

   -quiet：靜默模式

代理

代理相關的配置能夠以下配置段中。

 -defaults <name>

 -frontend <name>

 -backend  <name>

 -listen   <name>

 

 「defaults」段用於爲全部其它配置段提供默認參數，這配置默認配置參數可由下一個「defaults」所從新設定。

 「frontend」段用於定義一系列監聽的套接字，這些套接字可接受客戶端請求並與之創建鏈接。

 「backend」段用於定義一系列「後端」服務器，代理將會將對應客戶端的請求轉發至這些服務器。

 「listen」段經過關聯「前端」和「後端」定義了一個完整的代理，一般只對TCP流量有用。

 

 全部代理的名稱只能使用大寫字母、小寫字母、數字、-(中線)、_(下劃線)、.(點號)和:(冒號)。此外，ACL名稱會區分字母大小寫。

 

配置文件中的關鍵字參考

balance

balance <algorithm> [ <arguments>]

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

 

定義負載均衡算法，可用於「defaults」、「listen」和「backend」。<algorithm>用於在負載均衡場景中挑選一個server，其僅應用於持久信息不可用的條件下或須要將一個鏈接從新派發至另外一個服務器時。支持的算法有：

 

  roundrobin：基於權重進行輪叫，在服務器的處理時間保持均勻分佈時，這是最平衡、最公平的算法。此算法是動態的，這表示其權重能夠在運行時進行調整，不過，在設計上，每一個後端服務器僅能最多接受4128個鏈接；

  static-rr：基於權重進行輪叫，與roundrobin相似，可是爲靜態方法，在運行時調整其服務器權重不會生效；不過，其在後端服務器鏈接數上沒有限制；

  leastconn：新的鏈接請求被派發至具備最少鏈接數目的後端服務器；在有着較長時間會話的場景中推薦使用此算法，如LDAP、SQL等，其並不太適用於較短會話的應用層協議，如HTTP；此算法是動態的，能夠在運行時調整其權重；

  source：將請求的源地址進行hash運算，並由後端服務器的權重總數相除後派發至某匹配的服務器；這可使得同一個客戶端IP的請求始終被派發至某特定的服務器；不過，當服務器權重總數發生變化時，如某服務器宕機或添加了新的服務器，許多客戶端的請求可能會被派發至與此前請求不一樣的服務器；經常使用於負載均衡無cookie功能的基於TCP的協議；其默認爲靜態，不過也可使用hash-type修改此特性；

  uri：對URI的左半部分(「問題」標記以前的部分)或整個URI進行hash運算，並由服務器的總權重相除後派發至某匹配的服務器；這可使得對同一個URI的請求老是被派發至某特定的服務器，除非服務器的權重總數發生了變化；此算法經常使用於代理緩存或反病毒代理以提升緩存的命中率；須要注意的是，此算法僅應用於HTTP後端服務器場景；其默認爲靜態算法，不過也可使用hash-type修改此特性；

  url_param：經過<argument>爲URL指定的參數在每一個HTTP GET請求中將會被檢索；若是找到了指定的參數且其經過等於號「=」被賦予了一個值，那麼此值將被執行hash運算並被服務器的總權重相除後派發至某匹配的服務器；此算法能夠經過追蹤請求中的用戶標識進而確保同一個用戶ID的請求將被送往同一個特定的服務器，除非服務器的總權重發生了變化；若是某請求中沒有出現指定的參數或其沒有有效值，則使用輪叫算法對相應請求進行調度；此算法默認爲靜態的，不過其也可使用hash-type修改此特性；

  hdr(<name>)：對於每一個HTTP請求，經過<name>指定的HTTP首部將會被檢索；若是相應的首部沒有出現或其沒有有效值，則使用輪叫算法對相應請求進行調度；其有一個可選選項「use_domain_only」，可在指定檢索相似Host類的首部時僅計算域名部分(好比經過www.magedu.com來講，僅計算magedu字符串的hash值)以下降hash算法的運算量；此算法默認爲靜態的，不過其也可使用hash-type修改此特性；

  rdp-cookie：表示根據HTTP請求頭來鎖定每一次HTTP請求

  rdp-cookie(name)：表示根據cookie（name）來鎖定哈希每一次TCP請求

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系統上使用；其不能使用接口別名，而僅能使用物理接口名稱，並且只有管理有權限指定綁定的物理接口；

 

mode

mode { tcp|http|health }

 

設定實例的運行模式或協議。當實現內容交換時，前端和後端必須工做於同一種模式(通常說來都是HTTP模式)，不然將沒法啓動實例。

 

tcp：實例運行於純TCP模式，在客戶端和服務器端之間將創建一個全雙工的鏈接，且不會對7層報文作任何類型的檢查；此爲默認模式，一般用於SSL、SSH、SMTP等應用；

http：實例運行於HTTP模式，客戶端請求在轉發至後端服務器以前將被深度分析，全部不與RFC格式兼容的請求都會被拒絕；

health：實例工做於health模式，其對入站請求僅響應「OK」信息並關閉鏈接，且不會記錄任何日誌信息；此模式將用於響應外部組件的健康狀態檢查請求；目前業講，此模式已經廢棄，由於tcp或http模式中的monitor關鍵字可完成相似功能；

 

hash-type

hash-type <method>

 

定義用於將hash碼映射至後端服務器的方法；其不能用於frontend區段；可用方法有map-based和consistent，在大多數場景下推薦使用默認的map-based方法。

 

map-based：hash表是一個包含了全部在線服務器的靜態數組。其hash值將會很是平滑，會將權重考慮在列，但其爲靜態方法，對在線服務器的權重進行調整將不會生效，這意味着其不支持慢速啓動。此外，挑選服務器是根據其在數組中的位置進行的，所以，當一臺服務器宕機或添加了一臺新的服務器時，大多數鏈接將會被從新派發至一個與此前不一樣的服務器上，對於緩存服務器的工做場景來講，此方法不甚適用。

consistent：hash表是一個由各服務器填充而成的樹狀結構；基於hash鍵在hash樹中查找相應的服務器時，最近的服務器將被選中。此方法是動態的，支持在運行時修改服務器權重，所以兼容慢速啓動的特性。添加一個新的服務器時，僅會對一小部分請求產生影響，所以，尤爲適用於後端服務器爲cache的場景。不過，此算法不甚平滑，派發至各服務器的請求未必能達到理想的均衡效果，所以，可能須要不時的調整服務器的權重以得到更好的均衡性。

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>：定義日誌級別，即輸出信息過濾器，默認爲全部信息；指定級別時，全部等於或高於此級別的日誌信息將會被髮送；

 

maxconn

maxconn <conns>

 

設定一個前端的最大併發鏈接數，所以，其不能用於backend區段。對於大型站點來講，能夠儘量提升此值以便讓haproxy管理鏈接隊列，從而避免沒法應答用戶請求。固然，此最大值不能超出「global」段中的定義。此外，須要留心的是，haproxy會爲每一個鏈接維持兩個緩衝，每一個緩衝的大小爲8KB，再加上其它的數據，每一個鏈接將大約佔用17KB的RAM空間。這意味着通過適當優化後，有着1GB的可用RAM空間時將能維護40000-50000併發鏈接。

 

若是爲<conns>指定了一個過大值，極端場景下，其最終佔據的空間可能會超出當前主機的可用內存，這可能會帶來意想不到的結果；所以，將其設定了一個可接受值方爲明智決定。其默認爲2000。

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

 

server

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

 

爲後端聲明一個server，所以，不能用於defaults和frontend區段。

 

<name>：爲此服務器指定的內部名稱，其將出如今日誌及警告信息中；若是設定了"http-send-server-name"，它還將被添加至發往此服務器的請求首部中；

<address>：此服務器的的IPv4地址，也支持使用可解析的主機名，只不過在啓動時須要解析主機名至相應的IPv4地址；

[:port]：指定將鏈接請求所發往的此服務器時的目標端口，其爲可選項；未設定時，將使用客戶端請求時的同一相端口；

[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://p_w_picpathserver.magedu.com check

weight<weight>：權重，默認爲1，最大值爲256，0表示不參與負載均衡；

解決haproxy日誌記錄問題：

Haproxy的日誌默認是記錄到日誌服務器的local2設備中，這個時候本機就須要開啓一個端口和設置local2設備的日誌記錄位置，haproxy才能夠記錄日誌。

    log         127.0.0.1 local2

若是想向haproxy記錄日誌，就須要修改rsyslog記錄日誌到指定位置和監聽指定端口才能夠成功記錄日誌。

[root@haproxy ~]# vim /etc/rsyslog.conf
$ModLoad imudp
$UDPServerRun 514
local2.*                                               /var/log/haproxy.log

設置完成重啓日誌服務

[root@haproxy ~]# service rsyslog restart
[root@haproxy ~]# ss -unl | grep 514
UNCONN    0      0                         *:514                      *:*

設置haproxy四層負載均衡集羣

後端web服務器設置不一樣頁面，一遍驗證負載均衡的效果

[root@web-01 ~]# echo "web-01" >>/var/www/html/index.html
[root@web-02 ~]# echo "web-02" >>/var/www/html/index.html

訪問驗證

[root@haproxy ~]# curl 172.16.4.101
web-01
[root@haproxy ~]# curl 172.16.4.102
web-02

haproxy配置以下

frontend main *:80                      
    default_backend                      
backend appsrvs                
   balance     roundrobin               
   server  web1 172.16.4.101:80 check  
   server  web2 172.16.4.102:80 check

設置完成啓動服務就實現了haproxy的四層負載均衡配置

[root@haproxy ~]# service haproxy start
[root@haproxy ~]# netstat -lntp | grep 80
tcp       0      0 0.0.0.0:80                  0.0.0.0:*                   LISTEN      36653/haproxy

驗證負載均衡

[root@haproxy ~]# curl 172.16.4.100
web-01
[root@haproxy ~]# curl 172.16.4.100
web-02
[root@haproxy ~]# curl 172.16.4.100
web-01
[root@haproxy ~]# curl 172.16.4.100
web-02
[root@haproxy ~]# curl 172.16.4.100
web-01
[root@haproxy ~]# curl 172.16.4.100
web-02

status狀態頁配置

啓用基於程序編譯時默認設置的統計報告，不能用於「frontend」區段。只要沒有另外的其它設定，它們就會使用以下的配置：

  -stats uri   : /haproxy?stats

  -stats realm : "HAProxy Statistics"

  -stats auth  : no authentication

  -stats scope : no restriction

儘管「stats enable」一條就可以啓用統計報告，但仍是建議設定其它全部的參數，以避免其依賴於默認設定而帶來非期後果。下面是一個配置案例。  

backend appsrvs
   balance     roundrobin
   server  web1 172.16.4.101:80 check
   server  web2 172.16.4.102:80 check
      stats enable       #啓用狀態頁面功能
      stats realm"My\ haproxy\ stats"  #認證提示，這個的空格須要使用\轉義
   stats uri/admin?stats  #訪問狀態頁面的路徑
   statsauth proxy:proxy  #登陸的用戶名和密碼

訪問狀態頁，輸入正確的用戶名和密碼便可訪問

若是想隱藏狀態頁面的版本信息，須要使用stats hide-version選項。

啓動狀態頁面管理功能：
backend appsrvs
   balance     roundrobin
   server  web1 172.16.4.101:80 check
   server  web2 172.16.4.102:80 check
    statsenable
    statsrealm "My\ haproxy\ stats"
    statshide-version     #隱藏haproxy版本信息
    statsadmin if TRUE    #表示認證成功，可使用web管理haproxy
    stats uri/admin?stats
    statsauth proxy:proxy

健康檢查

基於端口的建康檢查

只要後端服務器的80端口能夠正常訪問，那麼就認爲服務是正常的

只要在定義的server後面添加check就能夠實現健康檢查的功能

   server  web1 172.16.4.101:80 check
   server  web2 172.16.4.102:80 check

基於URL的健康檢查

只要後端服務器的指定頁面文件能夠正常訪問那麼就認爲服務是正常的，不然就算服務能夠正常訪問也認爲服務不可用

檢測後端服務器的index.html文件是否存在，若是不存在就中止向後端服務器轉發

    optionhttpchk HEAD /index.html HTTP/1.0
   server  web1 172.16.4.101:80 check
   server  web2 172.16.4.102:80 check

backup設置

在配置文件中定義server的時候若是在結尾添加backup字段，那麼這臺服務器就會成爲備份服務器不在提供服務，只有當提供服務的服務器所有都掛了，他才提供服務。

    server  web1 172.16.4.101:80 check
    server  web2 172.16.4.102:80 check backup   #表示這臺服務器是備份服務器

查看web頁面服務器的狀態，設置backup參數的服務器成爲了藍色

驗證：

訪問負載均衡集羣，備份服務器沒有提供服務

[root@haproxy ~]# curl 172.16.4.100
web-01
[root@haproxy ~]# curl 172.16.4.100
web-01
[root@haproxy ~]# curl 172.16.4.100
web-01
[root@haproxy ~]# curl 172.16.4.100
web-01

關閉web-01服務器，備份服務器就開始提供服務了

驗證：訪問集羣已是備份服務器在提供服務了

[root@haproxy ~]# curl 172.16.4.100
web-02
[root@haproxy ~]# curl 172.16.4.100
web-02
[root@haproxy ~]# curl 172.16.4.100
web-02
[root@haproxy ~]# curl 172.16.4.100
web-02

haproxy cookie sticky

啓用基於cookie的持久鏈接

backend appsrvs
    balance   roundrobin
    optionforwardfor
    cookieSERVERID insert indirect nocache    #定義首部插入cookie
    server  web1 172.16.4.101:80 checkcookie web1   #指定cookie附加的值爲web1
    server  web2 172.16.4.102:80 checkcookie web2   #指定cookie附加的值爲web2

訪問集羣，查看請求首部已經有了請求的cookie信息，並且不管如何刷新都是定位到這臺服務器響應。

ACL規則說明

haproxy的ACL用於實現基於請求報文的首部、響應報文的內容或其它的環境狀態信息來作出轉發決策，這大大加強了其配置彈性。其配置法則一般分爲兩步，首先去定義ACL，即定義一個測試條件，然後在條件獲得知足時執行某特定的動做，如阻止請求或轉發至某特定的後端。定義ACL的語法格式以下。

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

<aclname>：ACL名稱，區分字符大小寫，且其只能包含大小寫字母、數字、-(鏈接線)、_(下劃線)、.(點號)和:(冒號)；haproxy中，acl能夠重名，這能夠把多個測試條件定義爲一個共同的acl；

 <criterion>：測試標準，即對什麼信息發起測試；測試方式能夠由[flags]指定的標誌進行調整；而有些測試標準也能夠須要爲其在<value>以前指定一個操做符[operator]；

 [flags]：目前haproxy的acl支持的標誌位有3個：

   -i：不區分<value>中模式字符的大小寫；

   -f：從指定的文件中加載模式；

   --：標誌符的強制結束標記，在模式中的字符串像標記符時使用；

 <value>：acl測試條件支持的值有如下四類：

    整數或整數範圍：如1024:65535表示從1024至65535；僅支持使用正整數(若是出現相似小數的標識，其爲一般爲版本測試)，且支持使用的操做符有5個，分別爲eq、ge、gt、le和lt；

    字符串：支持使用「-i」以忽略字符大小寫，支持使用「\」進行轉義；若是在模式首部出現了-i，能夠在其以前使用「--」標誌位；

    正則表達式：其機制類同字符串匹配；

   IP地址及網絡地址

 

同一個acl中能夠指定多個測試條件，這些測試條件須要由邏輯操做符指定其關係。條件間的組合測試關係有三種：「與」(默認即爲與操做)、「或」(使用「||」操做符)以及「非」(使用「!」操做符)。

經常使用的測試標準(criteria)

be_sess_rate <integer>

be_sess_rate(backend)<integer>

 

用於測試指定的backend上會話建立的速率(即每秒建立的會話數)是否知足指定的條件；經常使用於在指定backend上的會話速率太高時將用戶請求轉發至另外的backend，或用於阻止***行爲。例如：

    backenddynamic
        modehttp 
        aclbeing_scanned be_sess_rate gt 50   #判斷每秒會話速率大於50個
       redirect location /error_pages/denied.html if being_scanned   #將用戶請求轉發到錯誤頁面

fe_sess_rate <integer>

fe_sess_rate(frontend)<integer>

 

用於測試指定的frontend(或當前frontend)上的會話建立速率是否知足指定的條件；經常使用於爲frontend指定一個合理的會話建立速率的上限以防止服務被濫用。例以下面的例子限定入站郵件速率不能大於50封/秒，全部在此指定範圍以外的請求都將被延時50毫秒。

    frontendmail
        bind:25
        modetcp
       maxconn 500
        acltoo_fast fe_sess_rate ge 50   #判斷建立的會話速率大於等於50個
       tcp-request inspect-delay 50ms   #每50毫秒作一個探測
       tcp-request content accept if ! too_fast #若是沒有達到會話建立速率大於50個，那麼就接受請求
       tcp-request content accept if WAIT_END

hdr <string>

hdr(header)<string>

 

用於測試請求報文中的全部首部或指定首部是否知足指定的條件；指定首部時，其名稱不區分大小寫，且在括號「()」中不能有任何多餘的空白字符。測試服務器端的響應報文時可使用shdr()。例以下面的例子用於測試首部Connection的值是否爲close。

   hdr(Connection) -i close

method <string>

method<string>

測試HTTP請求報文中使用的方法。

path_beg <string>

用於測試請求的URL是否以<string>指定的模式開頭。下面的例子用於測試URL是否以/static、/p_w_picpaths、/javascript或/stylesheets頭。

    aclurl_static       path_beg       -i/static /p_w_picpaths /javascript /stylesheets

path_end <string>

用於測試請求的URL是否以<string>指定的模式結尾。例如，下面的例子用戶測試URL是否以jpg、gif、png、css或js結尾。

    aclurl_static       path_end       -i .jpg .gif .png .css .js

hdr_beg <string>

用於測試請求報文的指定首部的開頭部分是否符合<string>指定的模式。例如，下面的例子用記測試請求是否爲提供靜態內容的主機img、video、download或ftp。

    acl host_static hdr_beg(host) -i img.video. download. ftp.

hdr_end <string>

用於測試請求報文的指定首部的結尾部分是否符合<string>指定的模式。例如，下面的例子用記測試請求是否爲   

其它的creterion：

  dst_port,src_port, src, dst, url_beg, url_end

動靜分離的示例：

frontend main
    bind *:80
    aclurl_static       path_beg       -i /static /p_w_picpaths /javascript/stylesheets    #判斷請求報文開頭部分是否爲指定內容，並定義到url_static中
    aclurl_static       path_end       -i .jpg .gif .png .css .js                       #判斷結尾內容是否爲指定內容，並定義到url_static中
 
   use_backend static          ifurl_static
   default_backend            appsrvs
 
backend static      #將靜態內容轉發到這裏
    balanceroundrobin
    serverstatic1 172.16.100.11 check  
    serverstatic2 172.16.100.12 check
 
backend appsrvs    #將動態內容轉發到這裏
   balance     roundrobin
    optionforwardfor except 127.0.0.1 header X-Client
    optionhttpchk
    cookieSERVERID insert indirect nocache
   server  web1 172.16.100.7:80 checkcookie web1
   server  web2 172.16.100.8:80 checkcookie web2

                     

Haproxy配置文件示例：

global
    log         127.0.0.1 local2
 
   chroot      /var/lib/haproxy
   pidfile     /var/run/haproxy.pid
   maxconn     4000
    user        haproxy
   group       haproxy
    daemon
 
    # turn onstats unix socket
    statssocket /var/lib/haproxy/stats
 
defaults
    mode                    http
    log                     global
   option                  httplog
   option                 dontlognull
    optionhttp-server-close
    optionforwardfor       except 127.0.0.0/8
   option                  redispatch
   retries                 3
    timeouthttp-request    10s
    timeoutqueue           1m
    timeoutconnect         10s
    timeoutclient          1m
    timeoutserver          1m
    timeouthttp-keep-alive 10s
    timeoutcheck           10s
   maxconn                 30000
 
listen stats    #狀態頁面設置
    mode http
    bind0.0.0.0:1080
    statsenable
    statshide-version
    statsuri     /haproxyadmin?stats
    statsrealm   Haproxy\ Statistics
    statsauth    admin:admin
    statsadmin if TRUE
 
 
frontend http-in      #http請求的響應
    bind *:80
    mode http
    logglobal
    optionhttpclose  
    optionlogasap
    optiondontlognull   #不記錄空信息
    capturerequest  header Host len 20     #捕獲請求報文首部host的值的前20個字節記錄到日誌中
    capturerequest  header Referer len 60  #捕獲請求報文首部Referer的前20個本身記錄到日誌中
    aclurl_static       path_beg       -i /static /p_w_picpaths /javascript/stylesheets
    aclurl_static       path_end       -i .jpg .jpeg .gif .png .css .js
 
   use_backend static_servers         if url_static
   default_backend dynamic_servers
 
backend static_servers
    balanceroundrobin
    serverimgsrv1 172.16.200.7:80 check maxconn 6000
    serverimgsrv2 172.16.200.8:80 check maxconn 6000
 
backend dynamic_servers
    cookie srvinsert nocache
    balanceroundrobin
    serverwebsrv1 172.16.200.7:80 check maxconn 1000 cookie websrv1
    serverwebsrv2 172.16.200.8:80 check maxconn 1000 cookie websrv2
    serverwebsrv3 172.16.200.9:80 check maxconn 1000 cookie websrv3