编译vcl文件中状态引擎的顺序我们按照默认配置文件的顺序来，此顺序也符合请求处理的基本顺序，当然，为了配合实验也会有些改动。我们来看一张图，可以明确的明白请求的过程：
1，首先我们来编写vcl_recv段，
vcl_recv作为进入varnish对请求报文解码后第一个子例程，可以在此处做访问控制，是否查询缓存，以及无法识别的数据的判定。
首先对default.vcl文件复制一份重新改名为test1.vcl
acl purgers { #定义一个acl
"127.0.0.1";
"172.16.0.0"/16;
}
sub vcl_recv {
if (req.url ~ "^/test.html$") { #请求首部的url匹配到test.html，
return(pass); #跳过缓存
}
if
if (req.request != "GET" && #请求方法不是已知的这7中则发到pipe上去
req.request != "HEAD" &&
req.request != "PUT" &&
req.request != "POST" &&
req.request != "TRACE" &&
req.request != "OPTIONS" &&
req.request != "DELETE") {
return (pipe);
}
if (req.request != "GET" && req.request != "HEAD") { #不是获取资源的全部跳过缓存，减少无用缓存查询
return (pass);
}
if (req.request == "PURGE") {
if (!client.ip ~ purgers) { #请求IP不在ACL中定义，则发挥405错误页。
error 405 "Method not allowed";
}
return (lookup);
}
return (lookup);
}
那么此时如何加载这个test1让他生效呢？
第一修改配置文件。
第二，利用varnishadm客户端工具。
varnishadm
[root@node1 ~]# varnishadm -S /etc/varnish/secret -T 127.0.0.1:6082 #进入到管理工具
200
-----------------------------
Varnish Cache CLI 1.0
-----------------------------
Linux,2.6.32-431.el6.x86_64,x86_64,-sfile,-smalloc,-hcritbit
varnish-3.0.5 revision 1a89b1f
Type 'help' for command list.
Type 'quit' to close CLI session.
varnish> vcl.load test1 test1.vcl #加载vcl文件
200
VCL compiled.
varnish> vcl.list
200
active 2 boot
available 0 test1
varnish> vcl.use test1
200
varnish> vcl.list
200
available 2 boot
active 0 test1
这样就设定成功了。
为了显示效果我们来配置一下deliver段，给客户端返回时候匹配到缓存信息，以便我我们来查看实验结果。
sub vcl_deliver {
if (obj.hits > 0) { #判断条件缓存匹配次数���于0
set resp.http.X-Cache = "HIT via" + " " + server.hostname; #添加HIT via
} else {
set resp.http.X-Cache = "MISS via" + " " + server.hostname; #没有匹配到则添加MISS via
}
}
访问缓存172.16.18.1.第一次是miss via 之后的访问在缓存有效期内都是HIT via
当访问test.html是会被vcl_recv定义的pass匹配到，直接跳过缓存，所以X-cache状态一直是MISS via
2，编辑vcl_hash，自定义hash生成时的数据来源。
sub vcl_hash {
hash_data(req.url); #依据req.url来匹配
if (req.http.host) {
hash_data(req.http.host); #请求首部的host来缓存
} else {
hash_data(server.ip);