1、關鍵詞balance
balance用於定義負載均衡的演算法，可用於defaults、listen和backend中。
balance使用方法如下：
balance <algorithm> [ <arguments> ]
balance url_param <param> [check_post [<max_wait>]]
<algorithm>用於在負載均衡場景中挑選一個server，其僅應用於持久資訊不可用的條件下或需要將一個連線重新派發至另一個伺服器時。
balance支援的演算法有：
roundrobin：基於權重進行輪詢，在伺服器的處理時間保持均勻分佈時，這是最平衡、最公平的演算法。此演算法是動態的，這表示其權重可以在執行時進行調整。不過在設計上，每個後端伺服器僅能最多接受4128個連線。
source：將請求的源地址進行hash運算，並由後端伺服器的權重總數相除後派發至某匹配的伺服器。這可以使得同一個客戶端IP的請求始終被派發至某特定的伺服器；不過，當伺服器權重總數發生變化時，如某伺服器當機或新增了新的伺服器，許多客戶端的請求可能會被派發至與此前請求不同的伺服器；常用於負載均衡無cookie功能的基於TCP的協議；其預設為靜態，不過也可以使用hash-type修改此特性。
static-rr：基於權重進行輪詢，與roundrobin類似，但是為靜態方法，在執行時調整其伺服器權重不會生效；不過，其在後端伺服器連線數上沒有限制。
leastconn：新的連線請求被派發至具有最少連線數目的後端伺服器；在有著較長時間會話的場景中推薦使用此演算法，如LDAP、SQL等，其並不太適用於較短會話的應用層協議，如HTTP；此演算法是動態的，可以在執行時調整其權重。
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.ilanni.com來說，僅計算ilanni詞符串的hash值)以降低hash演算法的運算量；此演算法預設為靜態的，不過其也可以使用hash-type修改此特性；
2、關鍵詞bind
bind僅能用於frontend和listen區段，用於定義一個或幾個監聽的套接詞。
bind使用方法如下：
bind [<address>]:<port_range> [, ...]
bind [<address>]:<port_range> [, ...] interface <interface>
<address>：可選選項，其可以為主機名、IPv4地址、IPv6地址或*。省略此選項、將其指定為*或0.0.0.0時，將監聽當前系統的所有IPv4地址。
<port_range>：可以是一個特定的TCP埠，也可是一個埠範圍(如5005-5010)，代理伺服器將通過指定的埠來接收客戶端請求。
需要注意的是，每組監聽的套接詞<address:port>在同一個例項上只能使用一次，而且小於1024的埠需要有特定許可權的使用者才能使用，這可能需要通過uid引數來定義。
<interface>：指定物理介面的名稱，僅能在Linux系統上使用。其不能使用介面別名，而僅能使用物理介面名稱，而且只有管理有許可權指定繫結的物理介面。
3、關鍵詞mode
mode用於設定例項的執行模式或協議。當實現內容交換時，前端和後端必須工作於同一種模式(一般說來都是HTTP模式)，否則將無法啟動例項。
mode可被用與listen、defaults、frontend、backend區段。
mode使用方法如下：
mode { tcp|http|health }
tcp：例項執行於純TCP模式（即4層），在客戶端和伺服器端之間將建立一個全雙工的連線，且不會對7層報文做任何型別的檢查；此為預設模式，通常用於SSL、SSH、SMTP等應用。
http：例項執行於HTTP模式（即7層），客戶端請求在轉發至後端伺服器之前將被深度分析，所有不與RFC格式相容的請求都會被拒絕。
health：例項工作於health模式，其對入站請求僅響應“OK”資訊並關閉連線，且不會記錄任何日誌資訊；此模式將用於響應外部元件的健康狀態檢查請求；目前此模式已經廢棄，因為tcp或http模式中的monitor關鍵詞可完成類似功能；
4、關鍵詞hash-type
hash-type定義用於將hash碼對映至後端伺服器的方法；其不能用於frontend區段；可用方法有map-based和consistent，在大多數場景下推薦使用預設的map-based方法。
hash-type使用方法如下：
hash-type <method>
map-based：hash表是一個包含了所有線上伺服器的靜態陣列。其hash值將會非常平滑，會將權重考慮在列，但其為靜態方法，對線上伺服器的權重進行調整將不會生效，這意味著其不支援慢速啟動。此外，挑選伺服器是根據其在陣列中的位置進行的，因此，當一臺伺服器當機或新增了一臺新的伺服器時，大多數連線將會被重新派發至一個與此前不同的伺服器上，對於快取伺服器的工作場景來說，此方法不甚適用。
consistent：hash表是一個由各伺服器填充而成的樹狀結構；基於hash鍵在hash樹中查詢相應的伺服器時，最近的伺服器將被選中。此方法是動態的，支援在執行時修改伺服器權重，因此相容慢速啟動的特性。新增一個新的伺服器時，僅會對一小部分請求產生影響，因此，尤其適用於後端伺服器為cache的場景。不過，此演算法不甚平滑，派發至各伺服器的請求未必能達到理想的均衡效果，因此，可能需要不時的調整伺服器的權重以獲得更好的均衡性。
5、關鍵詞log
log為每個例項啟用事件和流量日誌，因此可用於所有區段。每個例項最多可以指定兩個log引數，不過，如果使用了“log global”且"global"段已經定了兩個log引數時，多餘了log引數將被忽略。
log global
log <address> <facility> [<level> [<minlevel>]]
global：當前例項的日誌系統引數同"global"段中的定義時，將使用此格式；每個例項僅能定義一次“log global”語句，且其沒有任何額外引數。
<address>：定義日誌發往的位置，其格式之一可以為<IPv4_address:PORT>，其中的port為UDP協議埠，預設為514；格式之二為Unix套接詞檔案路徑，但需要留心chroot應用及使用者的讀寫許可權。
<facility>：可以為syslog系統的標準facility之一。
<level>：定義日誌級別，即輸出資訊過濾器，預設為所有資訊；指定級別時，所有等於或高於此級別的日誌資訊將會被髮送。
6、關鍵詞maxconn
maxconn設定一個前端的最大併發連線數，因此，其不能用於backend區段。
maxconn使用方法如下：
maxconn <conns>
對於大型站點來說，可以儘可能提高此值以便讓haproxy管理連線佇列，從而避免無法應答使用者請求。當然，此最大值不能超出“global”段中的定義。此外，需要留心的是，haproxy會為每個連線維持兩個緩衝，每個緩衝的大小為8KB，再加上其它的資料，每個連線將大約佔用17KB的RAM空間。這意味著經過適當優化後，有著1GB的可用RAM空間時將能維護40000-50000併發連線。
如果為<conns>指定了一個過大值，極端場景下，其最終佔據的空間可能會超出當前主機的可用記憶體，這可能會帶來意想不到的結果；因此，將其設定了一個可接受值方為明智決定。其預設為2000。
7、關鍵詞default_backend
default_backend定義在沒有匹配的use_backend規則時為例項指定使用的預設後端伺服器，因此，其不可應用於backend區段。在frontend和backend之間進行內容交換時，通常使用use-backend定義其匹配規則；而沒有被規則匹配到的請求將由此引數指定的後端伺服器接收。
default_backend使用方法如下：
default_backend <backend>
<backend>：指定使用的後端的名稱。
使用案例：
use_backend dynamic if url_dyn
use_backend static if url_css url_img
default_backend dynamic
8、關鍵詞server
server為後端宣告一個server，因此，不能用於defaults和frontend區段。
server使用方法如下：
server <name> <address>[:port] [param*]
<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代理場景；
一個標準的使用案例，如下：
server web1 192.168.5.171:8080 maxconn 1024 weight 3 check inter 2000 rise 2 fall 3
以上就是[param*]中比較經常使用的引數。
redir <prefix>：啟用重定向功能，將發往此伺服器的GET和HEAD請求均以302狀態碼響應；需要注意的是，在prefix後面不能使用/，且不能使用相對地址，以免造成迴圈；例如：
server srv1 192.168.5.174:80 redir http://imags.ilanni.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.1\r\nHost:\ www.ilanni.com
server apache1 192.168.1.1:443 check port 80
9、關鍵詞stats enable
stats enable啟用基於程式編譯時預設設定的統計報告，stats enable不能用於frontend區段。只要沒有另外的其它設定，它們就會使用如下的配置：
stats uri : /stats
stats realm : "HAProxy Statistics"
stats auth : no authentication
stats scope : no restriction
儘管stats enable一條就能夠啟用統計報告，但還是建議設定其它所有的引數，以免其依賴於預設設定而帶來非期望的後果。下面是一個配置案例。
backend public_www
server websrv1 192.168.5.171:80
stats enable
stats hide-version
stats scope
stats uri /stats
stats realm Haproxy\ Statistics
stats auth admin:password
stats auth admin:password
10、關鍵詞stats hide-version
stats hide-version隱藏統計報告中haproxy版本號，不能用於frontend區段。預設情況下，統計頁面會顯示一些有用資訊，包括haproxy的版本號。
然而，向所有人公開haproxy的精確版本號是非常有風險的，因為它能幫助惡意使用者快速定位版本的缺陷和漏洞。
11、關鍵詞stats realm
stats realm啟用統計報告並高精認證領域，不能用於“frontend”區段。
stats realm <realm>
haproxy在讀取realm時會將其視作一個單詞，因此，中間的任何空白詞符都必須使用反斜線進行轉義。此引數僅在與“stats auth”配置使用時有意義。
<realm>：實現HTTP基本認證時顯示在瀏覽器中的領域名稱，用於提示使用者輸入一個使用者名稱和密碼。
12、關鍵詞stats scope
stats scope啟用統計報告並限定報告的區段，不能用於frontend區段。
當指定此語句時，統計報告將僅顯示其列舉出區段的報告資訊，所有其它區段的資訊將被隱藏。如果需要顯示多個區段的統計報告，此語句可以定義多次。需要注意的是，區段名稱檢測僅僅是以詞符串比較的方式進行，它不會真檢測指定的區段是否真正存在。
stats scope { <name> | "." }
<name>：可以是一個listen、frontend或backend區段的名稱，而“.”則表示stats scope語句所定義的當前區段。
13、關鍵詞stats auth
stats auth啟用帶認證的統計報告功能並授權一個使用者帳號，其不能用於frontend區段。
stats auth <user>:<passwd>
<user>：授權進行訪問的使用者名稱；
<passwd>：此使用者的訪問密碼，明文格式；
此語句將基於預設設定啟用統計報告功能，並僅允許其定義的使用者訪問，其也可以定義多次以授權多個使用者帳號。可以結合“stats realm”引數在提示使用者認證時給出一個領域說明資訊。在使用非法使用者訪問統計功能時，其將會響應一個“401 Forbidden”頁面。其認證方式為HTTP Basic認證，密碼傳輸會以明文方式進行，因此，配置檔案中也使用明文方式儲存以說明其非保密資訊故此不能相同於其它關鍵性帳號的密碼。
14、關鍵詞stats admin
stats admin在指定的條件滿足時啟用統計報告頁面的管理級別功能，它允許通過web介面啟用或禁用伺服器，不過，基於安全的角度考慮，統計報告頁面應該儘可能為只讀的。此外，如果啟用了HAProxy的多程式模式，啟用此管理級別將有可能導致異常行為。
stats admin { if | unless } <cond>
目前來說，POST請求方法被限制於僅能使用緩衝區減去保留部分之外的空間，因此，伺服器列表不能過長，否則，此請求將無法正常工作。因此，建議一次僅調整少數幾個伺服器。下面是兩個案例，第一個限制了僅能在本機開啟報告頁面時啟用管理級別功能，第二個定義了僅允許通過認證的使用者使用管理級別功能。
backend stats_localhost
stats enable
stats admin if LOCALHOST
backend stats_auth
stats enable
stats auth admin:password
stats admin if TRUE
15、關鍵詞option httplog
option httplog啟用記錄HTTP請求、會話狀態和計時器的功能。
option httplog [ clf ]
clf：使用CLF格式來代替HAProxy預設的HTTP格式，通常在使用僅支援CLF格式的特定日誌分析器時才需要使用此格式。
預設情況下，日誌輸入格式非常簡陋，因為其僅包括源地址、目標地址和例項名稱，而“option httplog”引數將會使得日誌格式變得豐富許多，其通常包括但不限於HTTP請求、連線計時器、會話狀態、連線數、捕獲的首部及cookie、“frontend”、“backend”及伺服器名稱，當然也包括源地址和埠號等。
16、關鍵詞option logasap
option logasap
啟用提前將HTTP請求記入日誌，不能用於backend區段。
預設情況下，HTTP請求是在請求結束時進行記錄以便能將其整體傳輸時長和詞節數記入日誌，由此，傳較大的物件時，其記入日誌的時長可能會略有延遲。option logasap引數能夠在伺服器傳送complete首部時即時記錄日誌，只不過，此時將不記錄整體傳輸時長和詞節數。此情形下，捕獲Content-Length響應首部來記錄傳輸的詞節數是一個較好選擇。下面是一個例子。
listen http_proxy 0.0.0.0:80
mode http
option httplog
option logasap
log 172.16.100.9 local2
17、關鍵詞option forwardfor
option forwardfor允許在發往伺服器的請求首部中插入“X-Forwarded-For”首部。即啟用獲取客戶端真實IP功能。
option forwardfor [ except <network> ] [ header <name> ] [ if-none ]
<network>：可選引數，當指定時，源地址為匹配至此網路中的請求都禁用此功能。
<name>：可選引數，可使用一個自定義的首部，如“X-Client”來替代“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。
下面是一個例子。
frontend www
mode http
option forwardfor except 127.0.0.1
18、關鍵詞errorfile
errorfile在使用者請求不存在的頁面時，返回一個頁面檔案給客戶端而非由haproxy生成的錯誤程式碼；可用於所有段中。
errorfile <code> <file>
<code>：指定對HTTP的哪些狀態碼返回指定的頁面；這裡可用的狀態碼有200、400、403、408、500、502、503和504。
<file>：指定用於響應的頁面檔案。
例如：
errorfile 400 /etc/haproxy/errorpages/400badreq.http
errorfile 403 /etc/haproxy/errorpages/403forbid.http
errorfile 503 /etc/haproxy/errorpages/503sorry.http
19、關鍵詞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法的場景(如POST)來說會產生問題，因為返回客戶的URL是不允許使用GET以外的其它方法的。如果的確有這種問題，可以使用errorloc303來返回303狀態碼給客戶端。
20、關鍵詞errorloc303
errorloc303 <code> <url>
請求錯誤時，返回一個HTTP重定向至某URL的資訊給客戶端，可用於所有配置段中。
<code>：指定對HTTP的哪些狀態碼返回指定的頁面；這裡可用的狀態碼有400、403、408、500、502、503和504；
<url>：Location首部中指定的頁面位置的具體路徑，可以是在當前伺服器上的頁面的相對路徑，也可以使用絕對路徑；需要注意的是，如果URI自身錯誤時產生某特定狀態碼資訊的話，有可能會導致迴圈定向；
例如：
backend webserver
server 172.16.100.6 172.16.100.6:80 check maxconn 3000 cookie srv01
server 172.16.100.7 172.16.100.7:80 check maxconn 3000 cookie srv02
errorloc 403 /etc/haproxy/errorpages/sorry.htm
errorloc 503 /etc/haproxy/errorpages/sorry.htm
轉載自：http://www.cnblogs.com/ilanni/p/4750729.html