• 作者: 作者
  • 时间:
  • 分类: 文章

最近看到有朋友在抱怨，说自己搭建的CPA（Cloudflare Proxy Anything）服务，缓存效果实在太差了。

CPA监控面板截图

CPA 监控面板显示写缓存数据为0，命中率极低的情况

用的还是免费账号，缓存命中率大多数时候只有可怜的10%多一点，偶尔运气好能冲到80%-90%，但极其不稳定。更让人摸不着头脑的是，监控面板上的“写缓存”数据一直是0。明明已经按照网上的教程，把“会话粘性路由”和TTL都配置好了，为什么还是没有效果？

今天我们就来扒一扒这背后的技术逻辑，顺便聊聊Free账号的天花板在哪里。

CPA后台配置截图

CPA 后台路由策略配置，展示了会话粘性和轮询设置

一、 缓存命中率的真相：别被“Free”骗了

首先，大家要搞清楚CPA这类服务的缓存机制。缓存生效的一个大前提是：你的源站必须明确告诉CDN“这个内容可以缓存”。

如果源站返回的 Header 里是 Cache-Control: no-store、private 或者 max-age=0，那不管你怎么折腾CPA的配置，边缘节点都不会存这份数据。

Free账号的玄机： 很多CPA工具的免费版本为了节省资源，默认采用了比较“保守”的缓存策略。这意味着，即便你的请求通过了代理，CPA可能并没有针对所有类型的响应都启用边缘缓存。特别是在处理动态API请求或者需要鉴权的内容时，Free策略倾向于绕过缓存。

为什么偶尔会有80%-90%的命中？ 那通常是因为在那段时间内，你访问的资源碰巧是静态资源（比如图片、JS/CSS文件），或者这些资源的缓存头设置得非常激进。大多数时候只有10%，说明你主要访问的内容可能带有动态特征（Cookie、Query String等），导致无法被标准缓存。

二、 为什么“写缓存”一直是0？

“写缓存”为0其实是个好消息，说明系统运行逻辑是正常的。

写缓存的触发条件极其苛刻：只有在边缘节点确定该资源需要被缓存，且此时边缘节点上没有该资源的缓存副本时，系统才会进行“回源并写入缓存”的操作，即 Write Cache。

如果你的“写缓存”一直是0，通常有两种可能：

  1. 热门资源已被缓存：你的请求大部分时候都能直接命中现有的缓存，不需要回源写缓存。
  2. 完全不可缓存：你的请求类型决定了它根本不可能进入CPA的缓存存储区，自然也就没有“写”的动作。

结合你说命中率极低，第二种可能性更大。也就是说，你的流量一直在“回源”，但回源拿回来的数据又因为某些规则不会被存下来。

三、 路由策略的坑：Round-Robin vs 会话粘性

来看看你提供的配置：

routing:
  strategy: round-robin
  session-affinity: true
  session-affinity-ttl: "1h"
  cache-user-id: true
``

这里有个很经典的“想当然”误区。

`round-robin`（轮询）的意思是：如果有多个上游节点，请求会轮流分发给 Node A, Node B, Node C...

即便你开启了 `session-affinity`（会话粘性），这只保证了**同一个用户**的请求会尽量打到同一个上游节点。但是，对于**缓存系统**来说，Free账号的CPA实例通常是在多台边缘服务器上负载均衡的。

**问题的关键在于**：
CPA作为反向代理，它的 Cache 层通常是在“边缘”和“上游”之间。如果你使用的是Free账号，很多服务并没有提供全局的共享缓存层。当请求轮流或者随机落在不同的CPA Worker/Pod上时，如果这些实例之间没有共享内存或Redis，那么：

实例A缓存了内容 -> 隔一段时间，请求被路由到了实例B -> 实例B没有缓存 -> 只能回源。

Free层的 `session-affinity` 更多是为了保持WebSocket不断连或者维持Session状态，对于提升静态资源的缓存命中率帮助有限，除非你的并发量极小且路由极其稳定。

### 四、 怎么解决？（实操建议）

如果你不想充值升级，想尽量榨干Free账号的性能，可以尝试以下排查方向：

1.  **检查源站 Header**：使用 `curl -I` 访问你的源站，确保返回了 `Cache-Control: public, max-age=3600` 之类允许缓存的头。如果是动态网页，尝试忽略 Query String 参数。

2.  **调整缓存策略（如果工具支持）**：部分CPA工具允许自定义 Cache Key。尝试忽略 Cookie，或者将 `cache-user-id` 设为 `false` 试试看（`cache-user-id` 会导致每个用户都有一份独立缓存，这在共享服务中会极大地稀释命中率）。

3.  **理解写缓存为0**：只要访问正常，先别纠结写缓存为0。先把命中率拉上去才是正经事。一旦命中率上来，你会发现写缓存偶尔会有数值，那代表有新内容更新了。

4.  **路由策略**：如果只有1个上游节点，把 `strategy` 改为固定的或者轮询其实没区别。如果你是多节点源站，且依赖 Session，保持现状即可；如果只是想加速静态内容，Session 粘性反而可能妨碍负载均衡的效果。

### 总结

CPA Free账号缓存低，大概率不是配置写错了，而是免费版资源隔离机制和动态内容特性共同作用的结果。`cache-user-id: true` 这个配置在多人共享的场景下是命中率杀手，建议根据业务实际情况关闭它，优先追求公共资源的缓存复用。

标签: none

评论已关闭