說明：
1.haproxy的配置段有"global"，"defaults","listen","frontend"和"backend"等
“global”配置中的參數爲進程級別的參數，且通常與其運行的操作系統有關
defaults：用於爲所有其他配置段提供默認參數，這配置默認配置參數可由下一個"defaults"所重新設定
forntend：用於定義一系列監聽的套接字，這些套接字可以接受客戶端請求並與子建立連接
backend: 用於定義一系列“後端”服務器，代理將會將對應客戶端的請求轉發至這些服務器
listen: 用於定義通過關聯“前段”和“後端”一個完整的代理，通常只對TCP流量有用
所有代理的名稱只能使用大寫字母、小寫字母、數字、-（中線）、_（下劃線）、.(點號)和：（冒號）。此外，ACL名稱會區分大小寫
2.時間格式一些包含了值得參數表示時間，如超時時長。這些值一般都以毫秒爲單位，但也可以使用其他的時間單位做後綴，如us（微妙，1/10000000秒），ms（毫秒，1/1000秒），s（秒），m（分鐘），h（小時），d（天）
3.配置參數詳細說明請參考http://cbonte.github.io/haproxy-dconv/configuration-1.4.html
一：global 全局配置
“global”配置中的參數爲進程級別的參數，且通常與其運行的操作系統有關
chroot: 修改haproxy的工作目錄至指定的目錄，並在放棄權限之前執行chroot()操作，可以提升haproxy的安全級別，不過需要注意的是確保指定的目錄爲空目錄且任何用戶均不能有寫權限
daemon：讓haproxy以守護進程的方式工作於後臺，其等同於“-D”選項的功能，當然，也可以在命令行中以“-db”選項將其禁用
gid：以指定的GID運行haproxy，建議使用專用於運行haproxy的GID，以避免因權限帶來的風險
group：同gid，不過這裏爲指定的組名
uid: 已指定的UID身份運行haproxy進程
user：同uid，但這裏使用的爲用戶名
log：定義全局的syslog服務器，最多可以定義兩個
nbproc: 指定啓動的haproxy進程個數，只能用於守護進程模式的haproxy；默認只啓動一個進程
pidfile: pid文件的存放位置
ulimit-n:設定每個進程所能夠打開的最大文件描述符，默認情況下其會自動進行計算，因此不建議修改此選項
node：定義當前節點的名稱，用於HA場景中多haproxy進程共享同一個IP地址時
description: 當前實例的描述信息
maxconn：設定每個haproxy進程所接受的最大併發連接數，"ulimit-n"自動計算的結果正式參照此參數設定的
maxpipes: haproxy使用pipe完成基於內核的tcp報文重組，此選項用於設定每進程所允許使用的最大pipe個數，每個pipe會打開兩個文件描述符，因此，"ulimit -n"自動計算的結果會根據需要調大此值，默認爲maxcoon/4
noepoll: 在linux系統上禁用epoll機制
nokqueue：在BSE系統上禁用kqueue機制
nopoll：禁用poll機制
nosepoll: 在linux系統上禁用啓發式epoll機制
nosplice：禁止在linux套接字上使用tcp重組，這會導致更多的recv/send調用，不過，在linux2.6.25-28系列的內核上，tcp重組功能有bug存在
spread-checks<0..50,in percent>: 在haprorxy後端有着衆多服務器的場景中，在緊缺是時間間隔後統一對中服務器進行健康狀況檢查可能會帶來意外問題，此選項用於將檢查的時間間隔長度上增加或減少一定的隨機時長，爲當前檢查檢測時間的%
tune.bufsize: 設定buffer的大小，同樣的內存條件下，較小的值可以讓haproxy有能力接受更多的併發連接，較大的值了可以讓某些應用程序使用較大的cookie信息，默認爲16384，其可以在編譯時修改，不過強烈建議使用默認值
tune.chksize: 設定檢查緩衝區的大小，單位爲字節，更大的值有助於在較大的頁面中完成基於字符串或模式的文本查找，但也會佔用更多的系統資源，不建議修改
tune.maxaccept：設定haproxy進程內核調度運行時一次性可以接受的連接的個數，較大的值可以帶來較大的吞吐量，默認爲單進程模式下爲100，多進程模式下爲8，設定爲-1可以禁止此限制，一般不建議修改
tune.maxpollevents：設定一次系統調用可以處理的事件最大數，默認值取決於OS,其至小於200時可介於帶寬，但會略微增大網絡延遲，但大於200時會降低延遲，但會稍稍增加網絡帶寬的佔用
tune.maxrewrite：設定在首部重寫或追加而預留的緩存空間，建議使用1024左右的大小，在需要更大的空間時，haproxy會自動增加其值
tune.rcvbuf.client：設定內核套接字中客戶端接收緩存區的大小，單位爲字節，強烈推薦使用默認值
tune.rcvbuf.server：設定內核套接字中服務器接收緩存區的大小，單位爲字節，強烈推薦使用默認值
tune.sndbuf.client：設定內核套接字中客戶端發送緩存區的大小，單位爲字節，強烈推薦使用默認值
tune.sndbuf.server：設定內核套接字中服務器端發送緩存區的大小，單位爲字節，強烈推薦使用默認值
debug 調試模式，輸出啓動信息到標準輸出
quiet 安裝模式，啓動時無輸出
二：defaults 默認配置
defaults：用於爲所有其他配置段提供默認參數，這配置默認配置參數可由下一個"defaults"所重新設定
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的請求始終被派發至某特定的服務器，不過，當服務器權重總數發生變化時，如某服務器宕機或者添加新服務器，許多的請求可能會被派發至與此前請求不同的服務器，常用於負載均衡無cooki功能的基於TCP的協議，默認爲動態，不過可以使用hash-type修改此特性
uri：對URI的左半部分（“問號”標記之前的部分）或整個URI進行hash運算，並由服務器的總權重相除後派發至某匹配的服務器；這可以使得對同一個URI的請求總是派發至某匹配的服務器，除法服務器的權重總數發生了變化，此算法常用於代理緩存或反病毒代理以提高緩存的命中率，需要注意的是，此算法僅應用於HTTP後端服務器場景，其默認爲靜態算法，不過可以使用hash-type修改此特性
url_param：通過<argument>爲URL指定的參數在每個HTTP GET請求中將會被索引，日過找到了指定的參數且其通過等於號“=”被賦予了一個值，那麼此值將被執行hash運算並被服務器的總權重相處後派發至某匹配的服務器，此算法可以通過追蹤請求中的用戶標識進而確保同一個用戶的ID請求被髮送同一個特定的服務器，除非服務器的總權重發生了變化；如果某請求中沒有出現指定的參數或其沒有有效值，則使用輪詢算法對其想用請求進行調度，此算法默認爲靜態，不過可以使用hash-type修改此特性
har（<name>）:對於每個HTTP請求，通過<name>指定的HTTP首部將會被檢索，如果對於那個的首部沒有出現或其沒有有效值，則使用輪詢算法對響應請求進行調度，其有一個可選項“use_domain_only”可以指定檢索類似host類的首部時僅計算域名部分以降低hash算法的運算量，此算法默認爲靜態，不過可以使用hash-type修改此特性
bind
bind [<address>]:<port_range>[,.....]
bind [<address>]:<port_range>[,.....] interface <interface>
該指令僅能用於frontend和listen區段，用於定義一個或多個監聽的套接字
<address>:可選項，其可以爲主機名、IPV4地址、IPV6地址或*：省略此選項、將其指定爲*或0.0.0.0時，將監聽當前系統的所有IPv4地址
<port_range>:可以是一個特定的TCP端口，也可是一個端口範圍（如6604-6610），代理服務器將通過制定的端口來接受客戶端請求，需要注意的是，每組監聽的套接字<address:prot>在同一個實例上只能使用一次，而且小於1024的端口需要有特定的權限的用戶才能使用，這可能需要通過uid參數來定義
<interface>：指定物理接口的名稱，僅能在linux系統上使用，其不能使用接口別名，二進程使用物理端口名稱，而且只有管理有權限指定綁定的物理端口
mode
mode{ tcp|http|health }
設定實例的運行模式或協議，當實現內容交換時，前段和後端必須工作與統一中模式（一般說來時tcp模式），否則將無法啓動實例
tcp: 實例運行於純tcp模式，在客戶端和服務器端之間將建立一個全雙工的連接，且不會對7層報文做任何類型的檢查，此爲默認模式，通常用於SSL、SSH、SMTP等應用
http：實例運行於http模式，客戶端請求在轉發至後端服務器之前將被深度分析，所有不與RFC模式兼容的請求都會被拒絕
health：實例運行於health模式，其對入站請求僅響應“OK”信息並關閉連接，且不會記錄任何日誌信息 ，此模式將用於相應外部組件的監控狀態檢測請求；目前來講，此模式已經廢棄，因爲tcp或http模式中的monitor關鍵字可完成此類功能
log
log global
log<address><facility>[<level>[<minlevel>]]
爲每個實例啓用事件和流量日誌，因此可用於所有區段。每個實例最多可硬定義兩個log參數，不過，如果使用了“log global”且“global”端定義了兩個log參數時，多餘的log參數將會倍忽略
global：當前實例的日誌系統參數同“global”段中的定義時，將使用此格式，每個實例僅能定義一個“log global”語句，且其沒有額外的參數
<address>：定義日誌發往的位置，其格式之一可以爲<ipv4_address:port>，其中prot爲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>:指定使用的後端名稱
server
server<name><address>[:port][param*]
在後端聲明一個server，因此，不能用於defaults和frontend區段。
<name>: 爲此服務器指定的內部名稱，其將會出現在日誌及警告信息中；如果設定了“http-send-server-name”,他還將會被添加至發往此服務器的請求首部中
<adderss>：此服務器的IPv4地址，也支持使用可解析的主機名，只不過在啓動時需要解析主機名至響應的IPV4地址
<:port>：指定將連接請求所發往此服務器時的目標端口，其爲可選項，爲設定是，將使用客戶端請求時的同一相同端口
[param*]：爲此服務器設定的一系列參數：其可以得參數非常多，具體請參考官方文檔（http://cbonte.github.io/haproxy-dconv/configuration-1.4.html#5）中的說明，下面僅說明幾個常用的參數
服務器或默認服務器參數:
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>：通過觀察服務器的通信狀況來判斷其健康狀態，默認爲禁用，其支持的類型有“layer 4”和“layer 7”，“layer 7”僅能用於http代理場景
redir<prefix>：啓用重定向功能，將發往此服務的GET和HEAD請求均以302狀態碼響應，需要注意的是，在prefix後面不能使用/，且不能使用相對地址，以避免造成循環，例如
server srv1 192..168.1.202:80 redir http://imageserver.wangfeng7399.com check
weight<weight>: 權重，默認爲1，最大值爲256，0表示不參與負載均衡
檢查方法：
option httpchk
option httpchk<uri>
option httpchk<method><uri>
option httpchk<method><uri><version>：不能用於frontend端，例如：
backend https_relay
mode tcp
option httpchk OPTIONS * HTTP/1.1rnHost: www
server apache1 192.168.1.1:443 check port 80
capture request header
capture request header <name> len <length>
捕獲並記錄指定的請求首部最近一次出現時的第一個值，僅能用於“frontend”和“listen”區段，捕獲的首部值使用花括號{}括起來後添加進日誌中，如果需要捕獲多個首部值，他們將以指定的次序出現在日誌文件中，並以豎線“|”作爲分隔符，不存在的首部記錄爲空字符串，最長需要捕獲的首部包括在虛擬主機環境中使用的“host”、上傳請求首部中的“Content-length”、快速區別現實用戶和網絡機器人“User-agent”，已經代理環境中距離請求來源的“X-Forword-For”
<name>: 要捕獲的首部的名稱，此名稱不區分大小寫，但建議與他們出現在首部中的格式相同，比如大寫首字母，需要注意的是，記錄在日誌的是首部的值，而非首部名稱
<length>: 指定距離首部值時所記錄的精確長度，超出的部分將會倍忽略
可以捕獲的請求首部的個數沒有限制，但每個捕獲最多能記錄64個字符，爲了保證同一個frontend中日誌格式的統一性，首部捕獲僅能在frontend中定義
capture response header
capture response header <name> len <length>
捕獲並記錄響應首部。其格式和要點同捕獲的請求首部響應
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 srv1 192.168.1.201:80
stats enable
stats hide-version
stats scope .
stats uri /admin?stats
stats realm Haproxy Statistics
stats auth admin1:AdMiN123
stats auth admin2:AdMiN321
stats hide-version
啓用統計報告並隱藏HAProxy版本報告，不能用於“frontend”區域，默認情況下，統計頁面會顯示一些有用信息，包括HAProxy的版本號，然後，向所有人公開HAproxy的準確版本號是非常有危險的，因爲他能夠版主惡意用戶快速定位版本的缺陷和漏洞，儘管“stats hide-version”一條就能夠啓用統計報告，但還是建議設定其他所有的參數，以避免其依賴默認設定而帶來非預期後果請參照“stats enable”一節的說明
stats realm
stats realm <realm>
啓用統計報告並高精認證領域，不能用於“frontend”區域，haproxy在讀取realm是會講是做一個單詞，因此，中間的空白字符都必須使用反斜線進行轉移。此參數僅在與“stats auth”配置使用時有意義
<realm>：實現HTTP基本認證時顯示在瀏覽器中的領域名稱，用於提示用戶輸入一個用戶名和密碼
儘管“stats realm”一條就能夠啓用統計報告，但還是建議設定其他所有的參數，以避免其依賴默認設定而帶來非預期，後果請參照“stats enable”一節的說明
stats scope
stats scope {<name>|"."}
啓用統計報告並限定報告的區段，不能用於“frontend”區域，當指定此語句時，統計報告將僅顯示其列舉出區段的報告信息，所有其他區段的信息將被隱藏，如果需要顯示多個區段的統計報告，此語句可以定義多次，需要注意的是，區段名稱進程僅僅是以字符串比較的方式進行，他不會真檢查指定的區段是否真正存在
<name>：可以是一個“listen”、“frontend”或“backend”區段的名稱，而“.”則表示stats scope語句所定義的當前區段
儘管“stats scope”一條就能夠啓用統計報告，但還是建議設定其他所有的參數，以避免其依賴默認設定而帶來非預期後果，請參照“stats enable”一節的說明
stats auth
stats auth <user>:<password>
啓用帶認證的統計報告功能並授權一個用戶賬號，不能用於“frontend”區域
<user>：授權進行訪問的用戶名
<password>：此用戶的訪問密碼，明文格式
此語句將給予默認設定啓用統計功能報告，並僅允許其定義的用戶訪問，其也可以定義多次以手段多個用戶賬號，可以結合“stats realm”參數在提示用戶認證是給出一個領域說明信息，在使用非法用戶訪問統計功能時，其將會響應一個“401 Forbidden”頁面，其認證方式爲HTTP Basic認證，密碼傳輸會以明文方式進行，因此，配置文件中也使用存儲明文方式存儲以說明其非保密信息故此不能想用與其他關鍵性賬號的密碼。
儘管“stats auth”一條就能夠啓用統計報告，但還是建議設定其他所有的參數，以避免其依賴默認設定而帶來非預期後果，請參照“stats enable”一節的說明
stats admin
atsts admin {if|unless}<cond>
在指定的條件滿足時啓用統計報告頁面的管理級別功能，他允許通過web接口啓用或禁用服務器，不過，基於安全的角度考慮，統計報告頁面應該儘可能爲只讀的，此外，如果啓用了HAproxy的多進程模式，啓用此管理級別將會可能導致異常行爲
目前來說，POST請求方法被限制於僅能使用緩衝區減去保留之外的空間，因此，服務器列表不能過長，否則，此請求將無法正常工作，因此，建議一次僅調整少數幾個服務器，
option httplog
option httplog [clf]
啓用記錄HTTP請求、會話狀態和計時器的功能
clf：使用CLF格式來代替HAproxy默認的HTTP格式，通常在使用僅支持CLF格式的特定日誌分析器時才需要使用此格式
默認情況下，日誌輸入格式非常簡陋。因爲其僅包括源地址、目標地址和實例名稱、而“option httplog”參數將會使得日誌變得豐富許多，其通常包括但不侷限於HTTP請求、連接計時器、會話狀態、連接數、捕獲的首部及cookie、“frontend”、“backend”及服務器名稱。當然也包括源地址和端口號等。
option logasap
no option logasap
啓用或禁用提前將HTTP請求記入日誌，不能用於“frontend”區段。
默認情況下，HTTP請求是在請求結束時進行記錄以便能夠將其整體輸入時長和字節數記入日誌，由此，傳較大的對象時，其記入日誌的市場可能會略有延遲，“option logasap”參數能夠在服務器發送complete首部時及時記錄日誌，只不過，此時將不記錄整體傳輸時長和字節數。此情形下，捕獲“Content-Length”響應報文來記錄的字節數是以一個較好的選擇
option forwardfor
option forwardfor[ except <network> ][ header <name> ][ if-none ]
允許在發往服務器的請求首部中插入“X-Forwarded-For”首部
<network>：可選參數，當指定時，源地址爲皮至此網絡中的請求都禁用此功能
<name>：可選參數，可使用一個自定義的首部，如“X-Cluster-Client-IP”來代替“X-Forwarded-For”，有些獨特的web服務器的確需要用一個獨特的首部
if-none: 僅在此首部不存在時纔會將其添加至請求報文中
HAproxy工作與反向代理模式，其發往服務器的請求中的客戶端IP均爲HAproxy主機的地址而非真正的客戶端地址，這會使得服務器的日誌記錄不了真正的請求來源，“X-Forwarded-For”首部則可用於解決此問題，HAproxy可以向每個房網服務器的請求上添加此首部，並以客戶端IP爲其value
需要注意的是，HAproxy工作與隧道模式，其僅檢查每一個連接的第一個請求，一次，僅第一個請求報文中被附加此首部，請確保同時使用“option httpclose”、“option forceclose”和“option http-server-close”幾個option，例如
errorfile
errorfile <code> <file>
在用戶請求不存在的頁面時，返回一個頁面給客戶端而非有haproxy生成的錯誤代碼，可用於所有段中
<code>: 指定對HTTP的那些狀態碼發回指定的頁面，這裏可用的狀態碼有200、400、403、408、500、502、503和504
<file>：指定用於響應的頁面文件
例如：
errorfile 400 /etc/haproxy/errorfiles/400badreq.http
errorfile 403 /etc/haproxy/errorfiles/403forbid.http
errorfile 503 /etc/haproxy/errorfiles/503sorry.http
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方法獲取指定的URL，對於非GET方法的場景（如POST）來說會產生問題，因爲返回客戶端的URL是不允許使用GET意外的其他方法的，如果的確有這種問題，可以使用errorloc303來返回303狀態碼給客戶端
errorloc303
errorloc303 <code> <url>
<code>: 指定對HTTP的那些狀態碼發回指定的頁面，這裏可用的狀態碼有400、403、408、500、502、503和504
<url>：Location首部中指定的頁面位置的具體路徑，可以是在當前服務器上的頁面的相對路徑，也可以使用絕對路徑，需要注意的是，如果URI之神錯誤時禪師某特定狀態碼信息的話，有可能會導致循環定向
五、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中可以指定多個測試條件，這些測試條件需要由邏輯操作符指定其關係，條件間的組合測試關係有三種：“與”（默認即爲與操作）、“或”（使用“||”操作符和“or”）和“非”（使用“！”操作符）
常用的測試標準
5.1 be_sess_rate (integer)
be_sess_rate(backend) (integer)
用於測試指定的backend上會話創建的速率（即每秒創建的會話數）是否滿足指定的條件，常用於在指定的backend上的會話速率過高時將用戶請求轉發至另外的backend，或用於阻止攻擊行爲。例如：
backend dynamic
mode http
acl being_scanned be_sess_rate gt 100
redirect location /denied.html if being_scanned
5.2 fe_sess_rate <integer>
fe_sess_rate(backend) (integer)
用於測試指定的frontend（或當前fortend）上的創建速率是否滿足指定的條件，常用於爲frontend指定一個合理的會話創建速率的上限以防止服務器被濫用，例如
frontend mail
bind :25
mode tcp
maxconn 500
acl too_fast fe_sess_rate ge 50
tcp-request inspect-delay 50ms
tcp-request content accept if ! too_fast
tcp-request content accept if WAIT_END
定律限定入站郵件速率不能大於50封/秒，所有在指定範圍之外的請求都被延時50毫秒
5.3 hdr <string>
hdr(header) <string>
用於測定請求報文中的所有首部或指定首部是否滿足指定的條件，指定首部時，其名稱不區分大小寫，且在括號“（）”中不能有任何多餘的空白字符，測試服務器端的響應報文時可以使用shdr（）。例如。下面的例子用於測試首部Connection的值是否爲close
hdr(Connection) -i close
5.4 method <string>
測試HTTP請求報文中使用的方法
5.5 path_beg <string>
用於測試請求的URI是否以<string>指定的模式開頭。
1
acl url_static path_beg -i /static /images /javascript /stylesheets
測試URL是個以/static /images /javascript /stylesheets開頭
5.6 path_end <string>
用於測試請求的URL是否以<string>指定的模式結尾
1
acl url_static path_end -i .jpg .gif .png .css .js
測試URI是否以.jpg .gif .png .css .js結尾
5.7 hdr_beg <string>
用於測試請求報文的指定首部的開頭部分是否符合<string>指定的模式
1
acl host_static hdr_beg(host) -i img. video. download. ftp.
用於測試請求報文首部中的主機是否已img. video. download. ftp.開頭
5.8 hdr_beg <string>
用於測試請求報文的指定首部結尾是否符合<string>指定的模式