haproxy配置詳解

1、haproxy簡介

HAProxy是法國開發者威利塔羅(Willy Tarreau) 在2000年使用C語言開發的一個開源軟件

是一款具備高并發(萬級以上)、高性能的TCP和HTTP負載均衡器

支持基于cookie的持久性，自動故障切換，支持正則表達式及web狀態統計

企業版網站：https://www.haproxy.com

社區版網站：http://www.haproxy.org

github：https://github.com/haprox

核心功能：?

負載均衡（Load Balancing）

支持四層（TCP）和七層（HTTP/HTTPS）流量分發。
提供多種調度算法：輪詢（roundrobin）、最少連接（leastconn）、源IP哈希（source）等。

反向代理（Reverse Proxy）

隱藏后端服務器細節，對外提供統一入口。
支持 SSL 終端（SSL Termination），卸載后端服務器加密負擔。

高可用（High Availability）

結合 Keepalived 實現雙機熱備（VRRP 協議）。

流量治理

請求過濾、速率限制、連接控制等。

haproxy特點和優點：

支持原生SSL,同時支持客戶端和服務器的SSL.
支持IPv6和UNIX套字節（sockets）
支持HTTP Keep-Alive
支持HTTP/1.1壓縮，節省寬帶
支持優化健康檢測機制（SSL、scripted TCP、check agent…）
支持7層負載均衡。
可靠性和穩定性非常好。
并發連接 40000-50000個，單位時間處理最大請求 20000個，最大數據處理10Gbps.
支持8種負載均衡算法，同時支持session保持。
支持虛擬主機。
支持連接拒絕、全透明代理。
擁有服務器狀態監控頁面。
支持ACL（access control list）。

多層級負載均衡

層級	協議支持	典型場景
四層（L4）	TCP/UDP	數據庫集群、Redis、SSH 跳板
七層（L7）	HTTP/HTTPS/HTTP2/3	Web 應用、API 網關、微服務路由

二、實驗

1、實驗環境的搭建

準備3臺主機：
主機1
主機名：haproxy
ip：172.25.254.100
主機2
主機名：RS1
ip：172.25.254.10
主機3
主機名：RS2
ip：172.25.254.20

1）軟件包安裝

兩臺RS都安裝nginx：

2）關閉火墻

兩臺RS關閉火墻

3）兩臺RS設置nginx的index.html內容

設置這個是方便后續測試

4）設置開機自啟動（兩個都設置）

5）連通測試

haproxy主機curl一下兩臺RS

關閉火墻

實驗環境搭建完畢\

2、haproxy的安裝和frontend區

1）安裝haproxy

dnf安裝

發現系統自帶，直接裝

2）進入haproxy配置文件?（最基本的負載均衡的調整）

進入編寫

進行tab鍵設置?

?重啟服務

?結果：

將option forwardfor注釋掉

結果

haproxy軟件基本信息

軟件安裝包： haproxy-2.4.22-3.el9_3.x86_64.rpm
啟動文件： /lib/systemd/system/haproxy.service
主配置目錄： /etc/haproxy/
主配置文件： /etc/haproxy/haproxy.cfg
子配置目錄： /etc/haproxy/conf.d

haproxy的基本配置信息

官方文檔：http://cbonte.github.io/haproxy-dconv/

HAProxy 的配置文件haproxy.cfg由兩大部分組成，分別是：

global：全局配置段
進程及安全配置相關的參數
性能調整相關參數
Debug參數

proxies：代理配置段
defaults：為frontend, backend, listen提供默認配置
frontend：前端，相當于nginx中的server {}
backend：后端，相當于nginx中的upstream {}
listen：同時擁有前端和后端配置,配置簡單,生產推薦使用

3、haproxy全局配置參數?（多進程與多線程）

解釋：
nbproc 2 —— 啟用多進程，2個進程
cpu-map 1 0 —— ?進程和cpu核心綁定防止cpu抖動從而減少系統資源消耗，1表示指定第一個work綁定第一個核心，0表示第一個核心，核心從0開始算（類似數組下標）
cpu-map 2 1 —— 指定第二個work綁定第二個cpu核心

global
log             127.0.0.1     local2                 #定義全局的syslog服務器；日志服務器需要開啟UDP協議，最多可以定義兩個 chroot         /var/lib/haproxy                      #鎖定運行目錄 
pidfile        /var/run/haproxy.pid                  #指定pid文件 
maxconn        100000                                #指定最大連接數 
user           haproxy                               #指定haproxy的運行用戶 
group          haproxy                               #指定haproxy的運行組 
daemon                                               #指定haproxy以守護進程方式運行 
# turn on stats unix socket 
stats          socket /var/lib/haproxy/stats         #指定haproxy的套接字文件 
nbproc         2                                     #指定haproxy的work進程數量，默認是1個 
cpu-map        1 0                                   #指定第一個work綁定第一個cpu核心 
cpu-map        2 1                                   #指定第二個work綁定第二個cpu核心 nbthread       2                                     #指定haproxy的線程數量，默認每個進程一個線程，此參數與nbproc互斥 maxsslconn     100000                                #每個haproxy進程ssl最大連接數,用于haproxy配置了證書的場景下 maxconnrate    100                                   #指定每個客戶端每秒建立連接的最大數量

參數	說明
daemon	以守護進程（后臺）模式運行
`user` `group`	指定運行用戶/用戶組（降權運行）
chroot	切換根目錄（增強安全性）
nbproc	工作進程數（CPU 核數綁定）
nbthread	每進程線程數（需啟用線程）
stats socket	管理套接字路徑（動態調整配置）

?重啟服務

查看多進程信息?

多進程與多線程互斥，只能存在一個

解釋：
nbthread —— 啟動多線程，線程數為2??

查看多線程

thread為2

proxies配置：

主要分為下面4個部分

defaults [<name>]? ? ? ? ? ?# 默認配置項，針對以下的frontend、backend和lsiten生效，可以多個name也可以沒有name
frontend <name>? ? ? ? ? ? # 前端servername，類似于Nginx的一個虛擬主機 server和LVS服務集群
backend <name>? ? ? ? ? ?# 后端服務器組，等于nginx的upstream和LVS中的RS服務器
listen <name>? ? ? ? ? ? ? ? # 將frontend和backend合并在一起配置，相對于frontend和backend
配置更簡潔，生產常用
注意：
name字段只能使用大小寫字母，數字，‘-’(dash)，'_‘(underscore)，'.' (dot)和 ':'(colon)，并且嚴格區分大小寫。

1）proxies 配置-defaults

defaults mode    http                   #HAProxy實例使用的連接協議 log    global                  #指定日志地址和記錄日志條目的 
syslog/rsyslog日志設備 #此處的 global表示使用 global配置段中設定的log值。 、option  httplog               #日志記錄選項，httplog表示記錄與 HTTP 會話相關的各種屬性值 #包括 HTTP請求、會話狀態、連接數、源地 址以及連接時間等 option dontlognull            #dontlognull表示不記錄空會話連接日志 option http-server-close      #等待客戶端完整HTTP請求的時間，此處為等 待10s。option forwardfor except 127.0.0.0/8 #透傳客戶端真實IP至后端web服務器 #在apache配置文件中加入:<br>%{X- Forwarded-For}i #后在webserver中看日志即可看到地址透傳 信息 option redispatch             #當server Id對應的服務器掛掉后，強制定 向到其他健康的服務器，重新派發 option http-keep-alive        #開啟與客戶端的會話保持 retries 3                     #連接后端服務器失敗次數timeout http-request 10s      #等待客戶端請求完全被接收和處理的最長時間 timeout queue 1m              #設置刪除連接和客戶端收到503或服務不可用等提示信息前的等待時間 timeout connect 120s          #設置等待服務器連接成功的時間 timeout client 600s           #設置允許客戶端處于非活動狀態，即既不發送數據也不接收數據的時間 timeout server 600s           #設置服務器超時時間，即允許服務器處于既不接收也不發送數據的非活動時間   timeout http-keep-alive 60s   #session 會話保持超時時間，此時間段內會轉發到相同的后端服務器                             timeout check 10s             #指定后端服務器健康檢查的超時時間 maxconn 3000                  #承受最大連接數量default-server inter 1000 weight 3  #對后端服務器的檢測為1000毫秒一次，weight 3 表示權重

2）proxies 配置-frontend和backend

    bind     *:80              # 監聽端口，即 haproxy 提供web服務的端口，和 lvs 的vip端口類似 mode     http              # http的7層模式use_backend webserver      # 調用的后端為webserverbalance  roundrobin        # 輪詢調用

?server 配置

#針對一個server配置
check ????????????????????????#對指定real進行健康狀態檢查，如果不加此設置，默認不開啟檢查,只有check后面沒有其它配置也可以啟用檢查功能
???????????????????????????????????#默認對相應的后端服務器IP和端口,利用TCP連接進行周期性健康性檢查,注意必須指定端口才能實現健康性檢查
addr <IP>? ? ? ? ? ? ? ? ? ??#可指定的健康狀態監測IP，可以是專門的數據網段，減少業務網絡的流量
port <num>? ? ? ? ? ? ? ? ??#指定的健康狀態監測端口
inter <num>? ? ? ? ? ? ? ? ?#健康狀態檢查間隔時間，默認2000 ms
fall <num> ??????????????????#后端服務器從線上轉為線下的檢查的連續失效次數，默認為3
rise <num>??????????????????#后端服務器從下線恢復上線的檢查的連續有效次數，默認為2
weight <weight> ?????????#默認為1，最大值為256，0(狀態為藍色)表示不參與負載均衡，但仍接受持久連接
backup ????????????????????????#將后端服務器標記為備份狀態,只在所有非備份主機down機時提供服務，類似SorryServer
disabled? ? ? ? ? ? ? ? ? ? ? #將后端服務器標記為不可用狀態，即維護狀態，除了持久模式
???????????????????????????????????#將不再接受連接,狀態為深黃色,優雅下線,不再接受新用戶的請求
redirect prefix http://www.baidu.com/ #將請求臨時(302)重定向至其它URL，只適用于http模式
maxconn <maxconn> #當前后端server的最大并發連接數

3）proxies 配置-listen

使用listen替換 frontend和backend的配置方式，可以簡化設置，通常只用于TCP協議的應用

socat 工具

對服務器動態權重和其它狀態可以利用 socat工具進行調整，Socat 是 Linux 下的一個多功能的網絡工具，名字來由是Socket CAT，相當于netCAT的增強版.Socat 的主要特點就是在兩個數據流之間建立雙向通道，且支持眾多協議和鏈接方式。如 IP、TCP、 UDP、IPv6、Socket文件等

4、HAProxy算法

所有算法在主配置文件配置/etc/haproxy/haproxy.cfg
vim /etc/haproxy/haproxy.cfg ---編輯配置文件
HAProxy通過固定參數 balance 指明對后端服務器的調度算法
balance參數可以配置在listen或backend選項中。
HAProxy的調度算法分為靜態和動態調度算法
有些算法可以根據參數在靜態和動態算法中相互轉換。

靜態算法

靜態算法：按照事先定義好的規則輪詢公平調度，不關心后端服務器的當前負載、連接數和響應速度等，且無法實時修改權重(只能為0和1,不支持其它值)，只能靠重啟HAProxy生效。

static-rr

static-rr---基于權重的輪詢調度
不支持運行時利用socat進行權重的動態調整(只支持0和1,不支持其它值)
不支持端服務器慢啟動
其后端主機數量沒有限制，相當于LVS中的 wrr
statick-rr 按照預先配置的順序和權重，將客戶端請求依次分配給后端服務器。當所有服務器都被分配一次后，算法會從頭開始循環

配置文件

運行

first

根據服務器在列表中的位置，自上而下進行調度
其只會當第一臺服務器的連接數達到上限，新請求才會分配給下一臺服務
其會忽略服務器的權重設置
不支持用socat進行動態修改權重,可以設置0和1,可以設置其它值但無效

配置文件?

運行

重新配置

運行

動態算法

動態算法

基于后端服務器狀態進行調度適當調整，
新請求將優先調度至當前負載較低的服務器
權重可以在haproxy運行時動態調整無需重啟

roundrobin

基于權重的輪詢動態調度算法，
支持權重的運行時調整，不同于lvs中的rr輪訓模式，
HAProxy中的roundrobin支持慢啟動(新加的服務器會逐漸增加轉發數)，
其每個后端backend中最多支持4095個real server，
支持對real server權重動態調整，
roundrobin為默認調度算法,此算法使用廣泛

配置文件?運行

leastconn

leastconn加權的最少連接的動態
支持權重的運行時調整和慢啟動，即:根據當前連接最少的后端服務器而非權重進行優先調度(新客戶端連接)
比較適合長連接的場景使用，比如：MySQL等場景。

配置文件?

運行

其他算法

其它算法即可作為靜態算法，又可以通過選項成為動態算法

source

源地址hash，基于用戶源地址hash并將請求轉發到后端服務器，后續同一個源地址請求將被轉發至同一個后端web服務器。此方式當后端服務器數據量發生變化時，會導致很多用戶的請求轉發至新的后端服務器，默認為靜態方式，但是可以通過hash-type支持的選項更改這個算法一般是在不插入Cookie的TCP模式下使用，也可給拒絕會話cookie的客戶提供最好的會話粘性，適用于session會話保持但不支持cookie和緩存的場景源地址有兩種轉發客戶端請求到后端服務器的服務器選取計算方式，分別是取模法和一致性hash

這個算法用到的是?map-base 取模法

map-base 取模法
map-based：取模法，對source地址進行hash計算，再基于服務器總權重的取模，最終結果決定將此請求轉發至對應的后端服務器。
此方法是靜態的，即不支持在線調整權重，不支持慢啟動，可實現對后端服務器均衡調度
缺點是當服務器的總權重發生變化時，即有服務器上線或下線，都會因總權重發生變化而導致調度結果整體改變

配置文件?

運行

變為動態的配置文件

變為動態的算法

一致性hash
一致性哈希，當服務器的總權重發生變化時，對調度結果影響是局部的，不會引起大的變動hash（o）mod n
該hash算法是動態的，支持使用 socat等工具進行在線權重調整，支持慢啟動

算法

1、后端服務器哈希環點keyA=hash(后端服務器虛擬ip)%(2^32)
2、客戶機哈希環點key1=hash(client_ip)%(2^32) 得到的值在[0---4294967295]之間，
3、將keyA和key1都放在hash環上，將用戶請求調度到離key1最近的keyA對應的后端服務器

hash環偏斜問題?

增加虛擬服務器IP數量，比如：一個后端服務器根據權重為1生成1000個虛擬IP，再hash。而后端服務器權重為2則生成2000的虛擬IP，再bash,最終在hash環上生成3000個節點，從而解決hash環偏斜問題

hash對象

Hash對象到后端服務器的映射關系：

uri

基于對用戶請求的URI的左半部分或整個uri做hash，再將hash結果對總權重進行取模后
根據最終結果將請求轉發到后端指定服務器
適用于后端是緩存服務器場景
默認是靜態算法，也可以通過hash-type指定map-based和consistent，來定義使用取模法還是一致性hash
注意：此算法基于應用層，所以只支持 mode http ，不支持 mode tcp

<scheme>://<user>:<password>@<host>:<port>/<path>;<params>?<query>#<frag>
左半部分：/<path>;<params>
整個uri：/<path>;<params>?<query>#<frag>

配置文件?

運行

url_param

url_param對用戶請求的url中的 params 部分中的一個參數key對應的value值作hash計算，并由服務器總權重相除以后派發至某挑出的服務器,后端搜索同一個數據會被調度到同一個服務器，多用于電商
通常用于追蹤用戶，以確保來自同一個用戶的請求始終發往同一個real server
如果無沒key，將按roundrobin算法

配置文件

運行

hdr

針對用戶每個http頭部(header)請求中的指定信息做hash，
此處由 name 指定的http首部將會被取出并做hash計算，
然后由服務器總權重取模以后派發至某挑出的服務器，如果無有效值，則會使用默認的輪詢調度。

配置文件?

運行

算法總結

#靜態
static-rr--------->tcp/http
first------------->tcp/http
#動態
roundrobin-------->tcp/http
leastconn--------->tcp/http
random------------>tcp/http
#以下靜態和動態取決于hash_type是否consistent
source------------>tcp/http
Uri--------------->http
url_param--------->http
hdr--------------->http

各算法使用場景?

first #使用較少
static-rr #做了session共享的web集群
roundrobin
random
leastconn #數據庫
source
#基于客戶端公網IP的會話保持
Uri--------------->http #緩存服務器，CDN服務商，藍汛、百度、阿里云、騰訊
url_param--------->http #可以實現session保持
hdr #基于客戶端請求報文頭部做下一步處理

5、基于cookie值的會話保持

基于 Cookie 值的會話保持（也稱為 "粘性會話"）是一種常用的負載均衡策略，確保來自同一客戶端的請求始終被路由到同一后端服務器，從而維護會話狀態的一致性。這種機制特別適用于不支持分布式會話的應用程序
cookie value：為當前server指定cookie值，實現基于cookie的會話黏性，相對于基于 source 地址hash調度算法對客戶端的粒度更精準，但同時也加大了haproxy負載，目前此模式使用較少，已經被session共享服務器代替
注意：不支持 tcp mode，使用 http mode?

目的：?解決有狀態應用（Stateful Application）的問題。例如，用戶的購物車數據、登錄會話信息等通常存儲在特定后端服務器的內存或本地緩存中。如果用戶的后續請求被負載均衡到不同的服務器，這些狀態信息將丟失，導致應用出錯。

?配置

測試

-b 指定cookie值

可以看到訪問cookie值為servera時，被調度到RS1處理；?cookie值為serverb時，被調度到RS2處理，與我們在haproxy配置文件里配置的一致。

6、HAProxy狀態頁

HAProxy 的狀態頁（Stats Page）?是實時監控負載均衡集群的核心工具，通過 Web 頁面展示關鍵性能指標和后端節點狀態。

狀態頁配置項

stats enable???????????????????????? #基于默認的參數啟用stats page
stats hide-version???????????????? #將狀態頁中haproxy版本隱藏
stats refresh <delay> ???????????#設定自動刷新時間間隔，默認不自動刷新
stats uri <prefix> ????????????????#自定義stats page uri，默認值：/haproxy?stats
stats auth <user>:<passwd> #認證時的賬號和密碼，可定義多個用戶,每行指定一個用戶
???????????????????????????????????????????????#默認：no authentication
stats admin { if | unless } <cond> #啟用stats page中的管理功能

實驗配置?

測試

加上stats refresh后面加上數字表示自動刷新的間隔

#pid為當前pid號，process為當前進程號，nbproc和nbthread為一共多少進程和每個進程多少個線程 
pid = 27134 (process #1, nbproc = 1, nbthread = 1) #啟動了多長時間 
uptime = 0d 0h00m04s #系統資源限制：內存/最大打開文件數/ 
system limits: memmax = unlimited; ulimit-n = 200029 #最大socket連接數/單進程最大連接數/最大管道數maxpipes 
maxsock = 200029; maxconn = 100000; maxpipes = 0 #當前連接數/當前管道數/當前連接速率 
current conns = 2; current pipes = 0/0; conn rate = 2/sec; bit rate = 0.000 kbps#運行的任務/當前空閑率 
Running tasks: 1/14; idle = 100 % active UP：                 #在線服務器 
backup UP：                 #標記為backup的服務器 
active UP, going down：     #監測未通過正在進入down過程 
backup UP, going down：     #備份服務器正在進入down過程 
active DOWN, going up：     #down的服務器正在進入up過程 
backup DOWN, going up：     #備份服務器正在進入up過程 
active or backup DOWN：     #在線的服務器或者是backup的服務器已經轉換成了down狀態 
not checked：               #標記為不監測的服務器 #active或者backup服務器人為下線的 
active or backup DOWN for maintenance (MAINT) #active或者backup被人為軟下線(人為將weight改成0) 
active or backup SOFT STOPPED for maintenance

?backend server信息

session rate(每秒的連接會話信息):
Errors(錯誤統計信息)：
cur:每秒的當前會話數量 :
Req:錯誤請求量
max:每秒新的最大會話數量
conn:錯誤鏈接量
limit:每秒新的會話限制量
Resp:錯誤響應量
sessions(會話信息):
Warnings(警告統計信息)：
cur:當前會話量
Retr:重新嘗試次數
max:最大會話量
Redis:再次發送次數
limit: 限制會話量
Total:總共會話量
Server(real server信息)：
LBTot:選中一臺服務器所用的總時間
Status:后端機的狀態，包括UP和DOWN
Last：和服務器的持續連接時間
LastChk:持續檢查后端服務器的時間
Wght:權重
Bytes(流量統計)：
Act:活動鏈接數量
In:網絡的字節輸入總量
Bck:備份的服務器數量
Out:網絡的字節輸出總量
Chk:心跳檢測時間
Dwn:后端服務器連接后都是DOWN的數量
Denied(拒絕統計信息)：
Dwntme:總的downtime時間
Req:拒絕請求量
Thrtle:server 狀態
Resp:拒絕回復量

?7、IP透傳

HAProxy 的 IP 透傳是指將原始客戶端的真實 IP 地址傳遞給后端服務器，而不是讓后端服務器只看到 HAProxy 自身的 IP 地址。這對于后端應用至關重要，因為它需要知道真實的客戶端信息來進行日志記錄、訪問控制、地理定位、速率限制、安全審計等操作。?

HAProxy 本身作為反向代理或負載均衡器，是客戶端與后端服務器之間的中間節點。默認情況下，后端服務器看到的 TCP 連接源 IP 地址就是 HAProxy 的 IP 地址。

7層ip透傳

當haproxy工作在七層的時候，也可以透傳客戶端真實IP至后端服務器

進入haproxy配置文件

開啟Listen就把frontend和backend關了

4層ip透傳

1）未開啟時

未開啟4層ip透傳時的各種配置：

haproxy.cfg

兩臺RS都要配置

未開啟4層ip透傳時的訪問測試極其日志：

訪問測試

日志查看

在一臺RS上查看nginx日志會發現，其真實訪問源地址是看不到的（紅框為-）

開啟時

開啟4層ip透傳時的各種配置：

nginx.conf（兩臺RS都要配置）

開啟4層ip透傳時的訪問測試極其日志：

訪問測試

?查看日志nginx

?這樣就能看到源ip地址

8、ACL

訪問控制列表ACL，Access Control Lists）

是一種基于包過濾的訪問控制技術

HAProxy 的 ACL 是其核心功能之一，用于定義復雜的流量匹配規則，實現基于請求內容（如 URL、Header、IP、路徑等）的智能路由、過濾或決策。

前置要求

將proxy_protocol去掉

Client里做解析

先在Client里做域名解析，不然后續測試訪問不了

解析在/etc/hosts做

這樣就有解析了

基本配置

開啟frontend、backend

其余的listen注釋掉

ACL配置選項

基本語法

用acl來定義或聲明一個acl
acl ????????<aclname>???????? <criterion>????????[flags] ????????[operator] ????????[<value>]
acl ????????名稱 ????????????????????匹配規范 ????????匹配模式 ???具體操作符? ? ?操作對象類型

ACL-Name 名稱

#ACL名稱，可以使用大字母A-Z、小寫字母a-z、數字0-9、冒號：、點.、中橫線和下劃線，并且嚴格區分大小寫，比如:my_acl和My_Acl就是兩個完全不同的acl5.8.1.2 ACL-criterion。

ACL-criterion 匹配規則

路徑匹配（(URL Path）

條件類型	說明
path	精確匹配路徑
path_beg	路徑開頭匹配
path_end	路徑結尾匹配
path_sub	路徑包含子串
path_dir	包含目錄匹配
path_reg	正則表達式匹配
path_len	路徑長度比較

域名/主機頭匹配 (Host)

條件類型	說明
hdr(host)	精確匹配 Host 頭
hdr_reg(host)	正則匹配 Host
hdr_dom	同 hdr(host) (舊式寫法)

HTTP頭部匹配

語法	說明
hdr(<name>)	檢查頭部存在/值
hdr_sub(<name>)	頭部包含子串
hdr_reg(<name>)	正則匹配頭部值
hdr_cnt(<name>)	頭部數量檢查
hdr_beg(<name>)	頭部開頭匹配

HTTP方法/版本

條件類型	說明
method	HTTP方法匹配
method_len	方法長度比較
ver	HTTP版本

標志項詳解

標志	說明	示例
-i	忽略大小寫	hdr(host) -i EXAMPLE.COM
-m	匹配模式	`-m str`：字符串匹配 `-m beg`：開頭匹配 `-m end`：結尾匹配 `-m sub`：子串匹配 `-m reg`：正則匹配 `-m found`：存在即匹配
-f	從文件加載	src -f /path/to/ip.list
-n	數值比較	path_len -n gt 100

ACL-operator 具體操作符

ACL 操作符

整數比較：eq、ge、gt、le、lt
字符比較：
exact match (-m str) :字符串必須完全匹配模式
substring match (-m sub) :在提取的字符串中查找模式，如果其中任何一個被發現，ACL將匹配
prefix match (-m beg) :在提取的字符串首部中查找模式，如果其中任何一個被發現，ACL將匹配
suffix match (-m end) :將模式與提取字符串的尾部進行比較，如果其中任何一個匹配，則ACL進行匹配
subdir match (-m dir) :查看提取出來的用斜線分隔（“/"）的字符串，如其中任一個匹配，則ACL進行匹配
domain match (-m dom) :查找提取的用點（“."）分隔字符串，如果其中任何一個匹配，則ACL進行匹配

ACL-value 操作對象

value的類型

The ACL engine can match these types against patterns of the following types :
Boolean #布爾值
integer or integer range #整數或整數范圍，比如用于匹配端口范圍
IP address / network #IP地址或IP范圍, 192.168.0.1 ,192.168.0.1/24
string--> www.timinglee.org
????????????????????????exact???????????????????????? #精確比較
????????????????????????substring ???????????????????#子串
????????????????????????suffix???????????????????????? #后綴比較
????????????????????????prefix ????????????????????????#前綴比較
????????????????????????subdir ????????????????????????#路徑， /wp-includes/js/jquery/jquery.js
????????????????????????domain? ? ? ? ? ? ? ? ? ? ?? #域名，www.timinglee.org
regular expression #正則表達式
hex block #16進制