选择 CacheFly 进行测试，并不是因为它“有多火”，恰恰相反，是因为它在国内技术社区的存在感非常低，但却长期出现在一些流媒体、游戏下载、企业分发场景中。
本次测试的初衷很简单：当主流 CDN（Cloudflare / CloudFront）在某些地区表现不稳定时，CacheFly 是否还能作为一个“工程兜底选项”？
一、实际接入背景与测试环境
CacheFly 的接入流程并不复杂，但明显是偏工程师思维，控制台设计较为传统，没有明显的产品化引导。
| 项目 | 说明 |
|---|---|
| CDN 服务商 | CacheFly |
| 测试方 | 本站网络安全测试团队 |
| 接入方式 | DNS CNAME 指向 CacheFly 提供的加速域名 |
| 源站 | 独立 VPS（Nginx，洛杉矶） |
| 测试内容 | 静态资源分发 + DDoS 压力测试 |
| 测试周期 | 约 3 周 |
二、CacheFly 的计费方式（非常重要）
CacheFly 与 AWS / Azure 最大的不同在于：它是“套餐 + 协商制”的 CDN，而不是完全开放的按量账单模式。
实际接入过程中，需要与官方销售确认流量级别，再分配对应的月度套餐。
| 项目 | 说明 |
|---|---|
| 计费模式 | 月度流量套餐（TB 级起） |
| 超额流量 | 需单独协商或按约定单价计费 |
| DDoS 防护 | 包含在服务内，无单独开关 |
| 测试套餐 | 官方测试级别流量方案 |
这种模式的优点是：成本可预期；缺点也很明显：灵活性不如云厂商。
三、CDN 加速测试（真实访问数据）
curl -o /dev/null -s -w \
"TTFB: %{time_starttransfer}s\nTotal: %{time_total}s\nHTTP: %{http_code}\n" \
https://cdn-test.example.com/static/large-file.bin
| 区域 | TTFB(s) | 总耗时(s) | 状态码 |
|---|---|---|---|
| 美国西部 | 0.09 | 0.41 | 200 |
| 欧洲 | 0.14 | 0.58 | 200 |
| 亚洲（SG） | 0.21 | 0.76 | 200 |
CacheFly 的特点很明显：首包不惊艳，但传输过程非常稳定，大文件下载时抖动明显小于部分主流 CDN。
四、DDoS 压力测试（工程视角）
本次测试更关注一个现实问题：攻击发生时，它会不会把流量打回源站？
| 阶段 | HTTP 200 | 异常返回 | 源站 CPU |
|---|---|---|---|
| 正常 | 99.9% | 0% | 12% |
| 攻击中 | 91.2% | 403 / 429 | 18% |
| 攻击后 | 99.8% | 少量 | 13% |
在中等规模 HTTP Flood 下，CacheFly 的行为偏向直接在边缘限速，回源流量控制得比较克制。
五、真实使用中遇到的问题
- 控制台功能偏老，学习成本不低
- 缓存规则需要工程背景，不适合新手
- 日志与分析能力不如云厂商完善
- 但技术支持响应质量明显高于平均水平
六、常见问题（FAQ）
CacheFly 适合小站或个人项目吗？
不太适合，它更偏向企业或稳定流量场景。
CacheFly 的 DDoS 防护能单独配置吗？
不能，防护策略更多是内置和自动化处理。
CacheFly 和 Cloudflare 的核心差异是什么？
CacheFly 更偏“内容分发工程”，Cloudflare 更偏“平台型安全产品”。
七、结论
如果你期待的是一个“点几下就能用、界面漂亮”的 CDN，那CacheFly可能会让你失望。
但如果你的业务对稳定性、大文件分发、成本可预期性更敏感，CacheFly 反而是一个被低估的工程型 CDN。
它不像是在“卖产品”，更像是在“帮你把内容稳稳地送出去”。
