TTL（Time To Live）是一份缓存在边缘节点上的存活时间。TTL 越长，命中率越高、回源越少；但内容更新后，旧缓存也会停留更久。给不同内容设合适的 TTL，是平衡「快」与「新」的关键。
TTL 是什么
当边缘节点缓存一份内容时，会同时记下它的过期时刻。在 TTL 内的请求直接由边缘返回；超过 TTL 后，节点会回源校验或重新拉取。TTL 到期不等于内容一定变了，只是触发一次「该不该更新」的检查。
取值范围
缓存时间至少为 1 秒，不能填 0。如果你想让某类内容完全不走缓存，请使用「不缓存」策略，而不是把 TTL 设为 0——后者不是表达「不缓存」的正确方式，系统也不接受 0 值。
- 静态资源（图片、字体等）可设较长 TTL，如一天甚至更久。
- 偶尔更新的页面可设几分钟到几十分钟，兼顾命中率与新鲜度。
- 需要实时的内容不要靠极短 TTL，直接用不缓存策略更稳妥。
为不同内容设不同 TTL
在缓存规则里，每条规则都可单独指定 TTL。建议按内容变动频率分层：几乎不变的长 TTL，偶尔变的中等 TTL，频繁变的短 TTL 或不缓存。这样既最大化命中，又把过期内容的窗口控制在可接受范围内。
与源站 Cache-Control 的关系
若源站响应里带了 Cache-Control 等缓存头，可以选择让边缘遵循源站，或由 veilx 规则统一覆盖。源站头便于集中管理、随内容下发；平台规则便于在控制台快速调整。两者择一为主，避免来回打架。