Cygwin 编译 Varnish：Windows 服务器上的开源缓存方案

简介：这是一份让Varnish Cache在Windows/Cygwin环境运行的适配资源，面向需要在非Linux系统部署高性能HTTP缓存服务的开发者与运维人员。Varnish本身常用于加速动态网站、降低后端负载，但原生仅支持Linux；该项目针对其源码中文件路径、网络I/O、线程管理、信号处理等模块做了系统性修补，并提供最小化cygwin.dll与gcc编译器分发版，无需安装全套Cygwin即可使用。压缩包共118个文件、约5.54MB，包含36个头文件与18个静态库以支持二次编译，14个exe程序与13个dll可直接运行和调用，另有VCL配置样例、启动脚本和readme说明文件，目录结构清晰。已有103人下载学习，同类适配资料较为稀少。读者可基于完整源码与配置样例搭建并调试缓存服务，掌握VCL缓存策略、高并发请求处理、热升级等核心机制，适合研究HTTP加速或需要在Windows环境做缓存网关验证的中高级用户。

1. 用 Cygwin 跑 Varnish Cache，绕了一点，却是 Windows 上值得做的开源缓存方案

在 Windows 服务器上做缓存加速，大多数人会直接装一个带原生 Windows 安装包的缓存软件，很少人会想到把 Cygwin 和 Varnish Cache 放在一起。Varnish 是开源的高性能 HTTP 反向代理缓存，设计上走纯 POSIX 路线，官方不提供 Windows 原生二进制；但通过 Cygwin 兼容环境，它能在 Windows 上完整编译运行，并保留 VCL 这个灵活的缓存策略配置语言。

我是在预研项目里碰到这条路的硬约束：缓存层不能额外引入 Linux 机器，只能用现有 Windows。绕了一圈后，Varnish 内存缓存的表现和 VCL 的灵活度，确实比同环境下的磁盘缓存方案更贴近生产需要。代价是依赖编译、路径语义、进程模型都要重新适配；只要你的运维现场以 Windows 为主，又需要开源缓存能力，下面这些步骤和踩坑记录就值得照着试一遍。

2. 为什么 Varnish 必须靠 Cygwin：它在底层坚持了哪些 POSIX 约定

动手编译之前，先把一个关键问题想清楚：Varnish 到底依赖了什么，以至于它对原生 Windows 说“不”。这样在 Cygwin 里撞到怪问题时，才不至于先怀疑是 VCL 写错，再怀疑编译参数，最后才发现是运行环境的问题。

2.1 共享内存模型与线程机制：mmap 和 pthread 是绕不过去的两条命脉

Varnish 和常见磁盘缓存代理最大区分点，是它的主体缓存放在共享内存里。它通过 mmap 把大块内存映射成可管理对象，以 8KB 为单位进行内存分配，再靠工作线程去处理 HTTP 会话。这个模型在 Linux 上很成熟，但 Windows 的内存模型不是这么暴露给应用层的。没有 Cygwin 的 POSIX 适配，开源 Varnish 拿不到它需要的 mmap、shm_open、POSIX 线程语义，连编译这关都过不去。

进一步拆解，Varnish 的缓存结构主体是 stevedore 存储层，最常见的 malloc stevedore 会把整块缓存空间视作一个可随机读写的对象池。对象数据被拆成多个 8KB 的内存片，分配和回收都发生在共享内存里，回源和缓存命中也只操作这段共享内存。varnishd 内部同时存在多类线程：cache-worker 处理 HTTP 业务逻辑，expire 线程负责清理过期对象。线程之间靠内存屏障与互斥锁通信，而这些同步原语在源码层面直接调用 pthread_mutex_lock、pthread_create、sem_wait 这一批 POSIX 接口。

Cygwin 的 pthread 层并不是类似于 1:1 的系统调用透传，它把 Windows 原生线程能力包装成符合 POSIX 语义的接口，并在内部维护自己的队列状态。这个映射层带来最实际的影响是：同样的并发参数在 Linux 上可能毫不费力，在 Cygwin 上线程切换与锁竞争的代价却更高。所以后文第 4 章里的线程池参数，我会刻意留出比 Linux 默认更宽的余量，而不是原样照抄某一篇 Linux 的 Varnish 教程。

2.2 路径语义与文件挂载：/cygdrive 与 /usr 混用是隐患的源头

Cygwin 有一套自己的路径映射：C 盘根目录默认对应 /cygdrive/c/，D 盘对应 /cygdrive/d/，而 Cygwin 安装目录自身被映射为 /。这意味着同一个 Windows 目录，在 Cygwin 里有两种等价但写法不同的路径表达。编译或运行过程中，只要某个脚本拿到的路径和另一个组件拿到的路径不是同一套写法，就大概率出问题。

举个例子，某次我把 Varnish 的工作目录建在 D 盘，命令里写作 /cygdrive/d/varnish_data，程序运行正常。后来改用 Windows 计划任务启动，工作目录被设置为系统默认目录，varnishd 的相对路径解析落在另一个挂载点上，结果是它找不到 pid 文件，反复启动失败。排查到最后，问题根本不在 Varnish，而是路径语义不统一。

我的习惯是，把所有属于 Varnish 的文件统一放进 /usr/local/varnish 或者 /tmp，避免盘符路径带来的隐含上下文。这也要求目标文件系统必须是 NTFS 而不是 FAT32，因为 Cygwin 的 fchmod、fchown 在 FAT 卷上会退化，可能让 varnishd 在写共享内存描述文件时出现异常行为。产线机器如果是旧式的 FAT 分区，务必先把目录迁移到 NTFS 卷再做编译。

2.3 依赖清单与版本匹配：pcre2、libedit、ncurses 一个都不能漏

编译 Varnish 需要三类依赖：编译器与构建工具链、正则库 pcre2、终端交互库 libedit 与 ncurses。在 Linux 发行版里一条命令能装齐的包，在 Cygwin 软件源里要逐个勾选，而且头文件通常放在 devel 子包里，只装运行库是不够的。

版本上我建议选较新的稳定版本，因为新版本的 autogen 脚本对跨平台的探查更友好，旧版本在 Cygwin 的较新 gcc 下容易报编译错误。正则库优先选 pcre2，Cygwin 源里 pcre 与 pcre2 并存，Varnish 新版默认向 pcre2 靠拢，继续用旧 pcre 反而要多处理正则语法的兼容差异。

依赖装好后，用一条命令验证编译环境是否就绪：

# 验证关键头文件与库是否在位，缺哪个补哪个 ls -l /usr/include/pcre2.h /usr/include/editline/readline.h /usr/include/ncurses.h 2>/dev/null || echo "缺少依赖" gcc --version | head -n 1 make --version | head -n 1 autoconf --version | head -n 1

这里四行命令各自独立：第一行是检查 pcre2 头文件、libedit 头文件和 ncurses 头文件是否存在，任一缺失都会走或逻辑输出“缺少依赖”；后三行则是确认编译器与构建工具可用。看到“缺少依赖”时，回到 Cygwin Setup 里搜索对应包的 devel 版本装上，不要只装主包，否则头文件依旧不会出现。

3. 在 Cygwin 里从源码编译 Varnish：完整步骤与关键参数

把“能跑”变成“能稳定跑”，分水岭就在编译这一步。直接放一个别人编译好的二进制进 Cygwin，往往因为链接的 DLL 集合不一致而失败；自己从源码编译虽然耗时，但依赖关系完全可控，后续排错也清晰得多。

3.1 编译前的环境准备：解压目录、换行符与用户权限

Cygwin 环境里有一个隐蔽的坑：源码 tar 包通常是 LF 换行，但如果你从 Windows 资源管理器里解压到 NTFS 分区，某些编辑器或解压工具可能把文本文件转成 CRLF。configure 脚本对换行符极其敏感，一旦混入 CRLF，会出现“命令未找到”或脚本异常退出的玄学问题。

我习惯把源码解压到 Cygwin 自己的目录体系里，比如 /usr/src，而不是丢在 /cygdrive/d 下，这一步能同时避开换行符和盘符路径两个隐患。准备命令如下：

# 建立干净的编译目录，避免在 Windows 盘符路径下编译 mkdir -p /usr/src/varnish-build cd /usr/src/varnish-build tar xzf /path/to/varnish-src.tar.gz cd varnish-src

命令里的 tar xzf 做了三件事：x 表示解包，z 表示处理 gzip 压缩，f 指定文件。如果下载的是 xz 压缩的后缀 .tar.xz，把 z 换成 J。解压之后先检查一下当前用户是否对 /usr/src 有写权限，权限不足时编译会在某个 make 阶段突然报 permission denied，容易让人误判成代码问题。

3.2 autogen、configure、make：三条命令与每个参数的作用

Varnish 的源码包解开后，目录里没有现成的 configure 脚本，而是有 autogen.sh 和 configure.ac 这类声明文件。需要先跑 autogen.sh 让它调用 autoconf 与 automake 把 configure 生成出来，这一步在针对特定平台做适配时尤其重要，因为 configure.ac 里包含了对 pthread、共享内存、信号量等能力的探测逻辑。

# 重新生成 configure 脚本 ./autogen.sh # 配置编译选项：prefix 决定安装位置 ./configure --prefix=/usr/local/varnish --with-pcre2 CFLAGS="-O2 -g" # 编译并安装 make -j4 make install

三个关键参数逐一说明。--prefix=/usr/local/varnish 指定安装根目录，后续 varnishd、varnishstat、VCL 示例文件都会落在这个前缀下，卸载时直接删目录即可，不会污染 Cygwin 自身的 /usr。--with-pcre2 强制使用 PCRE2 正则库，避免 configure 探测到旧 pcre 后做出错误选择。CFLAGS 里的 -O2 是优化级别，-g 保留调试符号，想让 varnishd 跑得更快可以把 -g 去掉，但遇到段错误要分析时又得重新编译，我一般留着。

configure 结束后终端会打印一份汇总表，仔细看 pcre2 和 pthread 两行是否为 yes。如果 configure 提示找不到某个库，优先检查 pkg-config 和 PKG_CONFIG_PATH 是否正确，Cygwin 下这类探测失败多数是环境变量没指向 .pc 文件所在目录。

3.3 安装后的自检：PATH 写入与依赖完整性验证

make install 只是把文件复制到位，varnishd 能不能真正运行还要看运行库是否齐全。为了让后续命令方便调用，先把安装目录加入 PATH：

# 写入 shell 配置，避免每次开终端都重复设置 echo 'export PATH=/usr/local/varnish/bin:/usr/local/varnish/sbin:$PATH' >> ~/.bashrc export PATH=/usr/local/varnish/bin:/usr/local/varnish/sbin:$PATH # 用 -V 检查版本与编译选项 varnishd -V

varnishd -V 会输出版本号和编译期参数，如果提示找不到某个 Cygwin 动态库，说明运行库缺件，用 cygcheck 递归查看它的依赖集：

# 递归检查 varnishd 依赖的所有 Cygwin 动态库 cygcheck ./sbin/varnishd

正常输出会列出一长串 dll 路径；如果某一行提示文件不存在，就把它对应的 Cygwin 包装上。这一步常见的翻车点是只装了主包没装 devel 包，运行库在但头文件缺失，或者反过来，configure 过了但运行时 DLL 找不全。

4. 把缓存策略用 VCL 立起来：最小配置与关键参数说明

编译只是起了个头，Varnish 真正发挥价值靠的是 VCL。VCL 是 Varnish 的配置即编程语言，请求处理、缓存命中、访问控制在代码里定义。很多初学者会把 VCL 想得过于复杂，其实先从最小配置入手，把链路跑通，再逐步加规则，反而更容易定位是哪一层出了问题。

4.1 最小 VCL 与三个后端状态变量：从回源到缓存命中的链路

第一个配置只需要做两件事：定义一个后端、设置缓存时间。后端是 varnishd 回源的对象，下面以本机 8080 端口的一个测试服务为例。VCL 文件内容如下：

vcl 4.1; backend default { .host = "127.0.0.1"; .port = "8080"; } sub vcl_recv { return (hash); } sub vcl_backend_response { set beresp.ttl = 120s; set beresp.grace = 30s; }

vcl_recv 里 return (hash) 让所有请求进入缓存查找流程，这是最简链路的关键。vcl_backend_response 里，beresp.ttl 决定资源被缓存多久，beresp.grace 决定后端故障时能继续用过期内容服务多久。crash 点在这里最容易搞混：ttl 管常规缓存时长，grace 管兜底期限。Varnish 的处理顺序是先查 ttl 是否有效，无效再看 grace 窗口，两者都不满足才回源。

用 varnishlog 可以确认单个请求是否真的命中了缓存：

# 观察根路径请求的处理状态 /usr/local/varnish/bin/varnishlog -g request -q "ReqURL == '/'"

输出里会看到 hit 或 miss 的明确标记，同时能看到缓存键由哪些字段组成。这一步比单纯看命中率统计更直接，能帮你定位“到底哪一条请求路径出了问题”。

4.2 启动命令里三个必调参数：缓存大小、线程池、超时窗口

VCL 之外，varnishd 启动参数里三个值是我在 Windows 环境落地前都会调一遍的基准参数。典型启动命令如下：

# 前台运行，便于观察日志与报错 /usr/local/varnish/sbin/varnishd -F \ -n /tmp/varnish \ -a :8088 \ -f /usr/local/varnish/etc/varnish/default.vcl \ -s malloc,256m \ -w 16,64,120 \ -p thread_pool_add_delay=2 \ -p listen_depth=128

-s malloc,256m 表示分配 256MB 内存作为缓存空间。机器内存小于 8GB 时不要跟风给到 1GB，Cygwin 进程在 Windows 的地址空间里受原生限制，缓存给大了反而频繁触发换页，命中率上去了但整体响应变慢。-w 16,64,120 表示线程池从 16 起步、上限 64、120 秒无任务则收缩，这是为 Cygwin 的线程映射层留的余量。线程创建开销在 Cygwin 下远高于 Linux，线程池太小会导致突发流量把 CPU 烧在创建线程上，线程池太大又增加锁竞争。

-n /tmp/varnish 指定 varnishd 的工作目录，pid 文件和共享内存描述都放这里。建议用路径语义最稳定的纯 Cygwin 目录，避免第 2 章说的盘符路径坑。重载 VCL 时不重启进程，用的是 varnishadm：

# 重载 VCL 并切换新配置，不中断当前服务 /usr/local/varnish/bin/varnishadm -n /tmp/varnish vcl.load reload_1 /usr/local/varnish/etc/varnish/default.vcl /usr/local/varnish/bin/varnishadm -n /tmp/varnish vcl.use reload_1

vcl.load 先把新配置编译并载入，vcl.use 再切到新版本。如果 vcl.load 阶段就报错，旧配置还在继续服务，这一点在生产环境里很实用。

4.3 回源与访问控制：在 Windows 混布网络里设置后端与 ACL

作为反向代理时，Varnish 的后端可以是本机服务，也可以是内网其他机器。Cygwin 环境下回源路径要经过 Windows 网络栈，本机回源建议用 127.0.0.1 而不是主机名，Windows 的主机名解析在某些网络配置下会多出一次 DNS 查询，把回源延迟拉高。

访问控制方面，可以在 VCL 里限制允许进入缓存的来源网段。下面这个例子结合了 ACL 与静态资源 Cookie 清理：

acl internal { "10.0.0.0"/8; "192.168.0.0"/16; } sub vcl_recv { if (!client.ip ~ internal) { return (synth(403, "Forbidden")); } if (req.url ~ "^/static/") { unset req.http.Cookie; } return (hash); } sub vcl_backend_response { if (beresp.status == 200 && req.url ~ "\.(css|js|png|jpg)$") { set beresp.ttl = 600s; } else { set beresp.ttl = 60s; } set beresp.grace = 30s; }

这段逻辑并不复杂：先在 vcl_recv 入口做来源筛选，不在 internal 网段的请求直接返回 403 合成响应；然后对 /static/ 路径抹掉 Cookie，避免同一 URL 因为 Cookie 不同而拆成多个缓存副本；最后在 vcl_backend_response 里按资源类型区分缓存时长。静态资源缓存 600 秒，普通响应 60 秒，两者都留了 30 秒 grace 窗口。Windows 与虚拟机混布、多条内网网段共存的环境里，这类 ACL 能挡住相当一部分误请求。

5. Cygwin 下跑 Varnish 的踩坑记录：五个高频翻车现场

换到 Cygwin 后，很多在 Linux 上不会出现的问题会反复出现，而且日志往往不具备直接指导意义。下面五条按“现象、原因、解决”的顺序记录，是我在这个方向上排查损耗最集中的五个环节。

5.1 现象：启动成功、端口正常，但所有请求都是 miss

varnishstat 里 miss 持续增长，hit 恒为零，日志里没有报错。这种局面多数不是 VCL 语法的问题，而是请求带着 Cookie 进入 hash，同一 URL 因 Cookie 不同被拆出多个缓存键。尤其是后台回源应用默认给所有响应种 Cookie 的场景，缓存几乎等于失效。

解决分两步。第一步在 vcl_recv 里针对静态路径 unset Cookie，这一步见 4.3 节代码。第二步用 varnishlog 观察单个请求的缓存键组成，确认还有没有 User-Agent、Accept-Encoding 之类的头参与哈希。缓存键过于碎片化时，可以考虑统一去掉干扰头，而不是继续堆缓存空间。

5.2 现象：varnishd 随机闪退，日志里找不到 ERROR

闪退最棘手的地方在于表面没有报错轨迹。从两个方向排查：第一，工作目录 -n 是否被删除或权限不足，比如目录建在 /cygdrive 下某个读写受限位置，varnishd 在后台线程写文件时崩溃；第二，Windows 的安全软件把 varnishd 的临时文件当作可疑目标强制终止进程。解决方案是把工作目录迁到 /tmp 这类纯净路径，并把相关目录加入安全软件信任区。这个问题本质跟 Varnish 无关，但在 Cygwin 组合下出现概率远高于 Linux。

5.3 现象：VCL 加载失败，提示第 N 行解析错误

最常见原因是编辑器把 VCL 存成了 CRLF 换行，Varnish 解析器把行尾的回车符当作语法内容，报错行号往往指向行尾。解决方法是显式转换换行符：

# 把 CRLF 转换为 LF，避免 VCL 解析器报行尾错误 sed -i 's/\r$//' /usr/local/varnish/etc/varnish/default.vcl

另一个隐蔽点在于 include 语句里出现反斜杠路径。VCL 必须使用 Cygwin 正斜杠路径，不能沿用 Windows 路径写法，把这句记到检查清单里，能省掉很多无谓的编译重试。

5.4 现象：外部机器访问 8088 端口不通，本机 curl 正常

本机访问正常说明 varnishd 本身没问题，问题在 Windows 防火墙的入站规则。Cygwin 程序不会以系统服务的方式自动注册防火墙放行规则，首次监听端口时，Windows 安全中心通常把它当成未知程序拦截。解决方法是手动添加入站规则，放行对象指向 varnishd 可执行文件，而不是只开端口。只开端口的隐患是 varnishd 重启后可执行文件路径变化，规则失效。

5.5 现象：Windows 或 Cygwin 重启后，缓存命中率彻底归零

这不是故障，但容易被误判。Varnish 的 -s malloc 缓存是纯内存态，进程退出即清空。重启后命中率需要一个预热爬坡过程。我用一个简单脚本做主动预热，把热点 URL 清单依次请求一遍，触发回源并建立缓存：

# 简单预热：把热点 URL 逐个请求一遍，加速缓存回填 while read url; do curl -s -o /dev/null "http://127.0.0.1:8088$url" done < /usr/local/varnish/etc/varnish/warmup.txt

预热脚本对个别 URL 返回 404 不敏感，循环会继续执行。热点资源集中时，这段脚本能让命中率在几分钟内恢复到重启前的水平，避免业务方一开机就看到缓存命中率暴跌而误判成系统故障。

6. 值得下功夫的两个验证动作：命中率监控与压力回退

如果打算把 Varnish 当长期依赖的缓存层，两个验证动作决定你是否敢让它承接真实流量，也决定你后续调参时有没有依据。

6.1 用 varnishstat 判断缓存真的在起作用

只盯 hit 和 miss 会漏掉关键信息。字节命中率是衡量缓存价值的核心指标，它反映从缓存直接返回的流量占比。命令如下：

# 抓取四类关键计数，命中数、未命中数、响应字节、命中字节 /usr/local/varnish/bin/varnishstat -1 | grep -E "MAIN.cache_hit|MAIN.cache_miss|MAIN.s_bodybytes|MAIN.s_hitbytes"

四个字段配合使用，判断逻辑可以列表化：

命中率走高而字节命中率偏低时，说明缓存有效覆盖的是小对象，大流量对象反而没有缓存命中，需要回头检查 VCL 里对大文件路径的处理规则。

6.2 压测与参数回退：一次只动一个变量

压测时用 ab 或同类工具对 Varnish 端口做并发请求，重点观察 failed requests 与连接重置数量：

# 用 100 并发发起 10 万次请求，观察失败率 ab -n 100000 -c 100 http://127.0.0.1:8088/static/app.css

如果连接重置明显，优先确认 listen_depth 和线程池是否过小；如果内存换页升高，则把 -s 的内存值回退。我在一次压测里把 256m 改成 512m，性能不升反降，原因就是换页抢占了 CPU 时间。这让我养成一个习惯：每改一个参数只动一个变量，压测前后各存一份 varnishstat 输出做对比，而不是凭感觉调。这套方案的价值在于它完全由开源组件构成，在 Windows 环境里能获得接近正统 Varnish 的缓存行为。按前面几章跑通最小链路，再针对性调参，你会明显感受到它和普通磁盘缓存的差异。希望这些经验能帮到你。

本文还有配套的精品资源，点击获取