轉自（可能有一定的修改）:
http://freeloda.blog.51cto.com/2033581/1294094

目錄：

1. balance
2. bind
3. mode
4. hash-type
5. log
6. maxconn
7. default_backend
8. server
9. capture request header
10. capture response header
11. stats enable
12. stats hide-version
13. stats realm
14. stats scope
15. stats auth
16. stats admin
17. option httplog
18. option logasap
19. option forwardfor
20. errorfile
21. errorloc 和 errorloc302
22. errorloc303
23. cookie
24. redirect

1.balance

格式：

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

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

roundrobin：基于權重進行輪叫，在服務器的處理時間保持均勻分布時，這是最平衡、最公平的算法。此算法是動態的，
這表示其權重可以在運行時進行調整，不過，在設計上，使用這種算法時，支持最多 4095 個后端服務器。

所謂運行時調整（on the fly），比如我們做灰度發布時，讓一部分服務器下線，然后修改配置。這里讓服務器下線，
是通過 HAProxy 的狀態頁，將其狀態切換為維護狀態，就可以讓其下線了，然后修改配置即可。然后讓其上線。

對于 roundrobin 算法，如果新上線一臺服務器，負載不是一下子全部分給新服務器，而是慢慢讓其承擔負載，這就是所謂
的“慢啟動”。

static-rr：基于權重進行輪叫，與roundrobin類似，但是為靜態方法，在運行時調整其服務器權重不會生效；不過，
其在支持的后端服務器上沒有限制；

對于 static-rr 算法，如果新增一臺服務器，不會慢啟動，負載會立即讓其分擔。

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

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

相當于 lvs 的 sh 算法，也相當于 nginx 的 ip-hash 算法。建議用于 TCP 模式的調度，且不支持使用 cookie 插入
模式時使用。不適用于 HTTP 協議。

uri：對URI的左半部分(“?”標記之前的部分)或整個URI進行hash運算，并與服務器的總權重相除后派發至某匹配
的服務器；這可以使得對同一個URI的請求總是被派發至某特定的服務器，除非服務器的權重總數發生了變化；

此算法常用于代理緩存（后端服務器是 Cache server），可以提高緩存的命中率，或反病毒代理；

需要注意的是，此算法僅應用于HTTP后端服務器場景；其默認為靜態算法，不過也可以使用 hash-type 修改此特性
（有一種是動態）；

支持兩個參數，len 和 depth，比如 uri len 80 depth 4。不過這個很少用得到。

URL 的語法格式：
    <scheme>://<user>:<password>@<host>:<port>/<paht>;<params>?<query>#<frag>
    
    ;<params>
        - ftp://downloads.magedu.com/pub/gnu;type=d
        - http://www.magedu.com/hammers;sale=false/index.html;graphics=ture
        
        params 通常是用來填寫表單的數據
        
    ?<query>
        - 有一些資源，比如數據庫服務，可以對其發起詢問或查詢，以縮小請求的資源類型的范圍。
          大致相當于 where 查詢子句。

url_param：檢索每個 HTTP GET 請求中，URL 的請求參數，通過 URL 的請求參數進行調度。即上面所說的 ;<params> 部分。
Apache 的基本認證中，用戶名和密碼就是通過 ;<params> 發出去的。

這種調度方法，常用于后端服務器需要對用戶進行認證的場景中。

如果找到了指定的參數且其通過等于號“=”被賦予了一個值，那么此值將被執行 hash 運算并被服務器的總權重相除后派發
至某匹配的服務器；

此算法可以通過追蹤請求中的用戶標識進而確保同一個用戶ID的請求將被送往同一個特定的服務器，除非服務器的總權重發
生了變化；如果某請求中沒有出現指定的參數或其沒有有效值，則使用輪叫算法對相應請求進行調度；此算法默認為靜態的，
不過其也可以使用hash-type修改此特性（有一種是動態）；

hdr(<name>)：對于每個HTTP請求，通過<name>指定的HTTP首部將會被檢索；如果相應的首部沒有出現或其沒有有效值，
則使用輪叫算法對相應請求進行調度；如果后端服務器有很多虛擬主機，就可以基于 Host 首部字段做 hash。

其有一個可選選項“use_domain_only”，可在指定檢索類似Host類的首部時僅計算
域名部分(比如通過www.test.com來說，僅計算test字符串的hash值)以降低hash算法的運算量；
比如有幾個虛擬主機都在一個真實服務器上，可以使用 use_domain_only 選項：
    www.magedu.com
    web.magedu.com
    wwww.magedu.com 
        
此算法默認為靜態的，不過其也可以使用hash-type修改此特性（有一種是動態）；      


rdp-cookie      
rdp-cookie(name)
    用于 Windows 的遠程桌面協議，基本很少用到。

如果對 mysql 服務器進行調度，用什么算法？

leastconn

如果對 ssh 服務器進行調度，用什么算法？

leastconn

如果對圖片服務器進行調度，使用什么算法？

rr，因為服務器是直接訪問文件系統的。

如果對圖片服務器之前的緩存服務器進行調度，使用什么算法？

uri

如果對 web 動態程序服務器進行調度，使用什么算法？

一般需要保持會話，可用 source

但其實要保持會話的話，最理想的方法是基于 cookie 進行調度。

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

例如：

    listen http_proxy
        bind :80, :443
        bind 10.0.0.1:10080, 10.0.0.1:10443

3.mode

格式：

mode { tcp|http|health }

設定實例的運行模式或協議。當實現內容交換時，前端和后端必須工作于同一種模式(一般說來都是HTTP模式)，否則將無法啟動實例。

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

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

health：實例工作于health模式，其對入站請求僅響應“OK”信息并關閉連接，且不會記錄任何日志信息；此模式將用于響應
外部組件的健康狀態檢查請求；目前來講，此模式已經廢棄，因為tcp或http模式中的monitor關鍵字可完成類似功能；

4. hash-type

格式：

hash-type <method>

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

map-based：hash表是一個包含了所有在線服務器的靜態數組。其hash值將會非常平滑，會將權重考慮在列，
但其為靜態方法，對在線服務器的權重進行調整將不會生效，這意味著其不支持慢速啟動。此外，挑選服務器是
根據其在數組中的位置進行的，因此，當一臺服務器宕機或添加了一臺新的服務器時，大多數連接將會被重新派
發至一個與此前不同的服務器上，對于緩存服務器的工作場景來說，此方法不甚適用。

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

推薦對 cache servers 執行負載均衡調度時的配置：

balance uri
hash-type consistent

5.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>：定義日志級別，即輸出信息過濾器，默認為所有信息；指定級別時，所有等于或高于此級別的日志信息將會被發送；

6.maxconn

格式：

maxconn <conns>

設定一個前端的最大并發連接數，因此，其不能用于backend區段。對于大型站點來說，可以盡可能提高此值以便讓haproxy管理連接隊列，從而避免無法應答用戶請求。當然，此最大值不能超出“global”段中的定義。此外，需要留心的是，haproxy會為每個連接維持兩個緩沖，每個緩沖的大小為8KB，再加上其它的數據，每個連接將大約占用17KB的RAM空間。這意味著經過適當優化后，有著1GB的可用RAM空間時將能維護 40000-50000 并發連接。

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

7.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

8.server

格式：

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

為后端聲明一個server，因此，不能用于defaults和frontend區段。

<name>：為此服務器指定的內部名稱，其將出現在日志及警告信息中；如果設定了"http-send-server-name"，它
還將被添加至發往此后端服務器的請求首部中；

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

[:port]：指定將連接請求所發往的此服務器時的目標端口，其為可選項；未設定時，將使用客戶端請求時的同一相端口；
當前端綁定了多個端口時（參考 bind 指令），就不要指定端口了。

[param*]：為此服務器設定的一系參數；其可用的參數非常多，具體請參考官方文檔中的說明，下面僅說明幾個常用的參數；

服務器或默認服務器參數 [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://imageserver.test.com check

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

執行健康檢查的方式，有多種方式，對于 web 服務器，使用 httpchk，對于 mysql 服務器可以使 mysql-check，
還有其他的 check 選項，請參考官方文檔。

option httpchk 
    表示基于 HTTP 協議做7層檢查。比如請求主頁，得到 200 響應碼就可以

option httpchk <uri>    
    指定請求的 uri，默認為 /

option httpchk <method> <uri>    
    指定請求的方法，默認方法為 OPTIONS，因為這個方法不需要太多的處理，而且容易從日志中過濾出來。
    指定請求的 uri，默認為 /

option httpchk <method> <uri> <version>：不能用于 frontend 段
    指定請求的方法、uri、版本，例如：

# Relay HTTPS traffic to Apache instance and check service availability
# using HTTP request "OPTIONS * HTTP/1.1" on port 80.
backend https_relay
    mode tcp
    option httpchk OPTIONS * HTTP/1.1\r\nHost:\ www.test.com
    server apache1 192.168.1.1:443 check port 80
    
HAProxy 的工作模式是 tcp 模式。但要使用 http 檢查。這里要明確定義使用什么 method 進行檢查。
方法為 OPTIONS，uri 為 *，協議為 HTTP/1.1，因為 1.1 協議要求必須攜帶 Host首部，所以這里也
進行了指定。

使用案例：

server first  172.16.100.7:1080 cookie first  check inter 1000
server second 172.16.100.8:1080 cookie second check inter 1000

9.capture request header

格式：

capture request header <name> len <length>

在日志中添加額外的信息。

捕獲并在日志中記錄指定的請求首部最近一次出現時的第一個值，僅能用于“frontend”和“listen”區段。

捕獲的首部值使用花括號{}括起來后添加進日志中。如果需要捕獲多個首部值，它們將以指定的次序出現在日志文件中，并以豎線“|”作為分隔符。

不存在的首部記錄為空字符串，最常需要捕獲的首部包括在虛擬主機環境中使用的“Host”、上傳請求首部中的“Content-length”、快速區別真實用戶和網絡機器人的“User-agent”，以及代理環境中記錄真實請求來源的“X-Forward-For”。

<name>：要捕獲的首部的名稱，此名稱不區分字符大小寫，但建議與它們出現在首部中的格式相同，比如大寫首字母。
需要注意的是，記錄在日志中的是首部對應的值，而非首部名稱。

<length>：指定記錄首部值時所記錄的精確長度，超出的部分將會被忽略。

可以捕獲的請求首部的個數沒有限制，但每個捕獲最多只能記錄64個字符。為了保證同一個frontend中日志格式的統一性，首部捕獲僅能在frontend中定義。

示例：
capture request header Host len 15
capture request header X-Forwarded-For len 15
capture request header Referer len 15

10.capture response header

格式：

capture response header <name> len <length>

在日志中添加額外的信息。

捕獲并記錄響應首部，其格式和要點同請求首部。

示例：
capture response header Content-length len 9
capture response header Location len 15

11.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 websrv1 172.16.100.11:80
  stats enable
  stats hide-version
  stats scope   .
  stats uri     /haproxyadmin?stats
  stats realm   Haproxy\ Statistics
  stats auth    statsadmin:password
  stats auth    statsmaster:password

12.stats hide-version

格式：

stats hide-version

啟用統計報告并隱藏 HAProxy 版本報告，不能用于“frontend”區段。默認情況下，統計頁面會顯示一些有用信息，
包括 HAProxy 的版本號，然而，向所有人公開HAProxy的精確版本號是非常有風險的，因為它能幫助惡意用戶快速定
位版本的缺陷和漏洞。

盡管“stats hide-version”一條就能夠啟用統計報告，但還是建議設定其它所有的參數，以免其依賴于默認設定而
帶來非期后果。具體請參照“stats enable”一節的說明。

13.stats realm

格式：

stats realm <realm>

啟用統計報告，并且設置認證領域，不能用于“frontend”區段。

haproxy在讀取 realm 時會將其視作一個單詞，因此，中間的任何空白字符都必須使用反斜線進行轉義。
此參數僅在與“stats auth”配合使用時有意義。

<realm>：實現HTTP基本認證時顯示在瀏覽器中的領域名稱，用于提示用戶輸入一個用戶名和密碼。

盡管“stats realm”一條就能夠啟用統計報告，但還是建議設定其它所有的參數，以免其依賴于默認設定而帶來
非期后果。具體請參照“stats enable”一節的說明。

示例：
# public access (limited to this backend only)
backend public_www
server srv1 192.168.0.1:80
stats enable
stats hide-version
stats scope .
stats uri /admin?stats
stats realm Haproxy\ Statistics
stats auth admin1:AdMiN123
stats auth admin2:AdMiN321

# internal monitoring access (unlimited)
backend private_monitoring
    stats enable
    stats uri     /admin?stats
    stats refresh 5s

14.stats scope

格式：

stats scope { <name> | "." }

啟用統計報告并限定報告的區段，不能用于 “frontend” 區段。

當指定此語句時，統計報告將僅顯示其列舉出區段的報告信息，所有其它區段的信息將被隱藏。如果需要顯示多個區段的統計報告，此語句可以定義多次。需要注意的是，區段名稱檢測僅僅是以字符串比較的方式進行，它不會真檢測指定的區段是否真正存在。

<name>：可以是一個“listen”、“frontend”或“backend”區段的名稱，而“.”則表示 stats scope
語句所定義的當前區段。

盡管“stats scope”一條就能夠啟用統計報告，但還是建議設定其它所有的參數，以免其依賴于默認設定而
帶來非期后果。下面是一個配置案例。

backend private_monitoring
    stats enable
    stats uri     /haproxyadmin?stats
    stats refresh 10s

15.stats auth

格式：

stats auth <user>:<passwd>

啟用帶認證的統計報告功能并授權一個用戶帳號，其不能用于“frontend”區段。

<user>：授權進行訪問的用戶名；
<passwd>：此用戶的訪問密碼，明文格式；

此語句將基于默認設定啟用統計報告功能，并僅允許其定義的用戶訪問，其也可以定義多次以授權多個用戶帳號?？梢越Y合“stats realm”參數在提示用戶認證時給出一個領域說明信息。在使用非法用戶訪問統計功能時，
其將會響應一個“401 Forbidden”頁面。

其認證方式為HTTP Basic認證，密碼傳輸會以明文方式進行，因此，配置文件中也使用明文方式存儲以說明其非
保密信息故此不能相同于其它關鍵性帳號的密碼。

盡管“stats auth”一條就能夠啟用統計報告，但還是建議設定其它所有的參數，以免其依賴于默認設定
而帶來非期后果。

16.stats admin

stats admin { if | unless } <cond>

開啟管理功能。

在指定的條件滿足時啟用統計報告頁面的管理級別功能，它允許通過web接口啟用或禁用服務器，
不過，基于安全的角度考慮，統計報告頁面應該盡可能為只讀的。

此外，如果啟用了HAProxy的多進程模式，啟用此管理級別將有可能導致異常行為。

目前來說，POST 請求方法被限制于僅能使用緩沖區減去保留部分之外的空間，因此，服務器列表不能過長，否則，
此請求將無法正常工作。因此，建議一次僅調整少數幾個服務器。下面是兩個案例，第一個限制了僅能在本機打開報告頁面時啟用管理級別功能，第二個定義了僅允許通過認證的用戶使用管理級別功能。

backend stats_localhost
    stats enable
    stats admin if LOCALHOST
backend stats_auth
    stats enable
    stats auth  haproxyadmin:password
    stats admin if TRUE

17.option httplog

格式：

option httplog [ clf ]

啟用記錄 HTTP 請求、會話狀態和計時器的功能。

clf：使用CLF格式來代替HAProxy默認的HTTP格式，通常在使用僅支持CLF格式的特定日志分析器時才需要使用此格式。

默認情況下，日志輸入格式非常簡陋，因為其僅包括源地址、目標地址和實例名稱，而“option httplog”參數將會使得日志格式變得豐富許多，其通常包括但不限于HTTP請求、連接計時器、會話狀態、連接數、捕獲的首部及cookie、“frontend”、“backend”及服務器名稱，當然也包括源地址和端口號等。

18.option logasap

格式：

option logasap   
no 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

19.option forwardfor

格式：

option forwardfor [ except <network> ] [ header <name> ] [ if-none ]

允許在發往后端服務器的請求首部中插入“X-Forwarded-For”首部。

<network>：可選參數，當指定時，源地址為匹配至此網絡中的請求都禁用此功能。

<name>：可選參數，可使用一個自定義的首部，如“X-Client”來替代“X-Forwarded-For”。
有些獨特的web服務器的確需要用于一個獨特的首部。

if-none：僅在此首部不存在時才將其添加至請求報文中。

HAProxy工作于反向代理模式，其發往服務器的請求中的客戶端IP均為HAProxy主機的地址而非真正客戶端的地址，這會使得服務器端的日志信息記錄不了真正的請求來源。

“X-Forwarded-For”首部則可用于解決此問題。HAProxy可以向每個發往服務器的請求上添加此首部，并以客戶端IP為其value。

需要注意的是，HAProxy工作于隧道模式，其僅檢查每一個連接的第一個請求，因此，僅第一個請求報文被附加此首部。如果想為每一個請求都附加此首部，請確保同時使用了這幾個option：

option httpclose
option forceclose
option http-server-close

下面是一個例子。

frontend www
    mode http
    option forwardfor except 127.0.0.1

20.errorfile

格式：

errorfile <code> <file>

在用戶請求不存在的頁面時，返回一個頁面文件給客戶端而非由haproxy生成的錯誤代碼；可用于所有段中。

<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

21.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狀態碼給客戶端。

22.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

23. cookie

cookie <name> [ rewrite | insert | prefix ] [ indirect ] [ nocache ]
[ postonly ] [ preserve ] [ httponly ] [ secure ]
[ domain <domain> ]* [ maxidle <idle> ] [ maxlife <life> ]

在 backend 中激活基于 cookie 的持久連接。

適用于：default, listen, backend

參數說明：

<name>:
指定 cookie 的名字。該 cookie 可能被監測、修改、插入信息。這個 cookie 由響應報文的 Set-Cookie header 發送給客戶端（只發送一次）。客戶端收到該 cookie 后，在其請求報文的 Cookie header 中攜帶該 cookie。

應特別注意，不要使該 cookie 的名字與其他 cookie 沖突。
不同的 backends 應使用不同的 cookie name

在一個 HTTP backend 中之只能定義一個 persistent cookie。

例如我們在一個 backend 中定義：
    cookie SRV insert indirect nocache

在該 backend 中，cookie 的值在 server 語句中定義：
    server first  10.1.1.1:1080 cookie first  check inter 1000
    server second 10.1.1.2:1080 cookie second check inter 1000

如果第一次請求調度至第一個服務器，cookie 的值為 first；如果調度至第二個服務器，cookie 的值為 second；

Set-Cookie 首部的內容包含：SRV=first/second，客戶端收到之后，以后向該域名路徑發送的請求，都會攜帶有包含 
SRV=first/second 的 cookie。根據 cookie 的值為 first or second，請求被調度至第一個或者
第二個服務器。這就是基于 cookie 的連接保持。這時是根據 cookie 的值來調度的，不是基于算法，即使
backend 的算法是 roundrobin 算法，也不會進行輪詢調度。

24. 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>]

使用范圍： frontend, backend, listen

If/unless the condition is matched, the HTTP request will lead to a redirect
response. If no condition is specified, the redirect applies unconditionally.

如果/除非 條件滿足，返回重定向給客戶端；如果未指定條件，表示直接返回重定向。

參數說明：

<loc>

redirect location <loc>；

使 Location 首部的值等于 loc;

<pfx>

redirect prefix <pfx>；

構建 Location 首部為：<pfx> + 完整的 URI path + query string；

• 如果使用了 "drop-query" 選項，表示不添加 query string；

• 如果 <pfx> = /，那么不需要重新構建 URI；適用的場景：重定向至同一個 URL，但是插入一個 cookie；

<sch>

redirect scheme <sch>；

構建 Location 首部為：<sch> + "://" + 第一個 Host 首部字段的值 + URI path + query sting

• 如果使用了 "drop-query" 選項，表示不添加 query string；

• 如果沒有給出 URI path，或者 path = *，則使用 "/" 替代 URI path；

• 如果找不到 Host 首部字段，則返回空的 Host 首部，大部分瀏覽器將其解釋為：重定向到同一個 host；

常用于將 HTTP 重定向至 HTTPS

<code>

<code> 是可選的；用于指定重定向的狀態碼，不同的重定向碼表示不同的重定向類型，支持使用 301, 302, 303, 307 and 308；

302 是默認狀態碼；

301 表示："Moved permanently" 永久重定向；瀏覽器可以將這個 Location 進行緩存

302 表示："Moved temporarily" 臨時重定向；瀏覽器不應該緩存這個 Location

303 表示：與 302 相同，但瀏覽器會使用 GET 方法獲取 location

307 表示：與 302 相同，但會明確讓瀏覽器使用同一個 method

308 表示：與 301 相同，但會明確讓瀏覽器使用同一個 method

<option>

選項是用于調整重定向的行為的：

"drop-query"

用于 prefix-based redirection 和 sch-based redirection，表示設置 Location 字段時，不添加 query string；

使用場景舉例：將用戶導向一個非安全的頁面；

"append-slash"

這個選項和 drop-query 合用時，可將不是以 '/' 重定向至同一個 Location ，但在尾部添加上 '/'；

這個修改可確保搜索引擎只看到一個 URL；

這時最好使用 301 作為狀態碼；

"set-cookie NAME[=value]"

在重定向響應中添加一個 "Set-Cookie" 首部字段；

這使得用戶的下一次訪問會攜帶 cookie，利用這一點可以防御某些類型的 DoS 攻擊；

因為沒有添加其他的 cookie 選項，所以這里設置的 cookie 是唯一的 cookie，這是其成為一個 session cookie；

注意，對于瀏覽器而言，一個不帶 = 符號的 cookie name，和帶了 = 符號的 cookie name 是不同的；

"clear-cookie NAME[=]"

在重定向響應中添加一個 "Set-Cookie" 首部字段，但 "Max-Age" 屬性被設置為 0，瀏覽器會刪除這個 cookie；

使用場景舉例：訪問了一個登出頁面 logout page，表示要退出訪問，這時為安全考慮最好刪除 cookie，以免被人盜取，這對于提高安全性是有好處的；

特別要注意，"clear-cookie NAME" 和 "clear-cookie NAME=" 是不同的；前者不會刪除這樣的 cookie: "NAME=value"，必須使用 "clear-cookie NAME=" 刪除這樣的 cookie，這一點不同是因為瀏覽器而產生的，因為瀏覽器對其進行不同的處理。

示例1：Move the login URL only to HTTPS. 強制用戶使用 HTTPS 協議訪問登陸頁面

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 # 如果用戶訪問時不攜帶 cookie，讓其重定向使用 HTTPS 訪問，并且為其設置 cookie
redirect prefix   https://mysite.com           if login_page !secure # 訪問登陸頁面，但不是訪問的安全端口，重定向使用 HTTPS 協議
redirect prefix   http://mysite.com drop-query if login_page !uid_given # 訪問登陸頁面，但沒有給出 userid 信息，讓用戶重新填寫登陸信息
redirect location http://mysite.com/           if !login_page secure # 訪問非登陸頁面，但卻要求使用安全端口，這沒必要，讓用戶重定向到普通頁面
redirect location / clear-cookie USERID=       if logout # 登出之后，讓瀏覽器刪除 cookie USERID=value，且重定向到首頁

示例2：Send redirects for request for articles without a '/'.

acl missing_slash path_reg ^/article/[^/]*$
redirect code 301 prefix / drop-query append-slash if missing_slash # 不改變 URI，改變默認狀態碼為 301，刪除 query string，并在 URI 尾部添加 "/"

示例3：Redirect all HTTP traffic to HTTPS when SSL is handled by haproxy.
acl is_ssl dst_port 8080
redirect scheme https if !is_ssl