Caddy encode gzip 没有压缩小响应：minimum_length 设为 0 会采用默认值

Caddy 已启用 gzip，较大的页面带有 Content-Encoding: gzip，一个很短的响应却没有这个头。即使把 minimum_length 写成 0，结果也可能不变：在 Caddy 2 的 encode 配置中，0 会采用默认长度阈值 512 字节，并不表示“所有响应都压缩”。

这篇针对普通非流式 HTTP 响应。先确认客户端接受 gzip、响应符合压缩条件，再检查长度阈值。服务端没有压缩，与客户端收到压缩内容却没有解码，是两种不同问题。

用 GET 查看协商和响应头

下面是检查示例，地址替换为受控站点中待检查的资源：

curl -sS -D - -o /dev/null \
  -H 'Accept-Encoding: gzip' 'https://example.com/small.txt'

它读取响应头，并把正文丢弃，不把压缩字节直接打印到终端。核对状态、Content-Type、Content-Encoding 和实际响应内容对应的资源；若得到重定向或登录页，先确认最终业务路径，不能把别的响应大小作为判断依据。

用 GET 可以检查真实正文的处理。只发送 HEAD 或只看浏览器解码后的内容，不能完整证明普通 GET 是否经过压缩。--compressed 则会让 curl 请求受支持的编码并解码正文；看见可读文本不代表服务端没压缩，仍需查看响应头。

若大、小两个同类资源只有大响应压缩，长度阈值是一个合理方向。若所有响应都没有编码头，先查请求的 Accept-Encoding、实际加载配置及响应匹配规则，不要直接把阈值降到最小。

0 采用默认值，想降低阈值应给正数

以下是局部配置示例：

encode gzip {
    minimum_length 1
}

它用于说明正数阈值，应放进需要压缩的站点块并与原配置合并。对满足其他条件、超过该阈值的普通响应，Caddy 才会进入相应编码流程。不要把已有站点的完整配置替换成这一段。

使用 JSON 配置时，对应字段是 minimum_length。0 仍会触发默认值；不要改为 -1 试图表达“没有下限”。负值不是这里提供的关闭阈值约定，普通正文的编码判断并不按你期望的方式处理它。

很短的文本并不一定因 gzip 得到更小的传输体积，压缩还有编码开销。先判断业务是否需要强制压缩这些小响应，通常保留默认阈值也可以是正确行为。不能把没有 gzip 头本身当作性能故障。

长度满足时，仍有其他条件

encode 要与客户端协商已有编码器。客户端没有接受 gzip，或者禁止相应编码时，不能要求 Caddy 无条件发 gzip。默认响应匹配器主要覆盖可压缩的内容类型，图片或其他未匹配类型要按实际用途核对。

上游已经给出 Content-Encoding 时，Caddy 不应再重复压缩；响应带有 Cache-Control: no-transform 也会影响编码。此时降低 minimum_length 不会解决问题。应查清哪一层负责压缩，避免让应用和多个代理同时处理。

范围响应、没有正文的响应和流式数据有额外处理条件。这条普通小正文路径不能直接外推到 SSE 或其他持续推送场景，也不要为它们统一修改缓冲或压缩设置。

确认生效，并保留恢复入口

修改前保存原站点配置，使用当前实例的正常校验和加载方式。重新请求同一资源，确认预期状态及内容不变、接受 gzip 的普通响应按设定出现正确编码，并核对缓存变体和其他资源没有异常。

还应检查不接受 gzip 的客户端能取得正常响应。若前面有 CDN，区分 CDN 返回结果与 Caddy 直接处理结果，不能把某一层的编码头当作另一层已加载配置的证据。

调整没有带来所需行为或影响业务时，恢复原阈值和匹配规则并重新加载。保留检查的响应头，继续按协商、长度、内容类型和已有编码定位，不需要删掉整份 encode 配置反复重建。