总结版：以 CF Server Monitor 采样间隔 1 秒、上报间隔 60 秒、WSS 上报间隔 1 秒计算，在无前端访问的情况下，WSS 全天开启理论上约支持 69 台服务器；完全关闭 WSS、全部使用 POST 上报时约支持 57 台；如果每天夜间关闭 WSS 6 小时、其余时间使用 WSS，理论上仍约支持 69 台。实际考虑前端访问、Agent 重连及其他额外请求，建议按照约 55～65 台服务器进行规划。夜间关闭 WSS 可以降低 DO Duration 和 DO 计费请求，同时继续保持 POST 上报，不影响基础监控数据采集。
以 采样间隔 1 秒、上报间隔 60 秒、WSS 上报间隔 1 秒 为例，在完全无前端访问且无其他项目占用的情况下，可以估算单台 CF Server Monitor Agent 每天对 Cloudflare 各项资源的消耗。
Cloudflare 免费额度（2026.8.25）
| 资源 | 免费额度 |
|---|---|
| D1 读取行 | 5,000,000 |
| D1 写入行 | 100,000 |
| Workers 请求数 | 100,000 |
| Durable Objects 计费请求数 | 100,000 |
| Durable Objects Duration | 13,000 GB-s |
WSS 时段全部开启
在 WSS 全天开启、没有前端访问的情况下，每台 Agent 每天大约消耗：
| 资源 | 每台 Agent / 天 |
|---|---|
| D1 读取行 | 1,440 |
| D1 写入行 | 1,440 |
| Workers 请求 | ≈ 1,440 |
| DO 计费请求数 | ≈ 124 |
| DO Duration | ≈ 10,800 GB-s |
计算方式：
- 上报次数：86,400 / 60 = 1,440 次/天
- D1 读取：约 1,440 行/天
- D1 写入：约 1,440 行/天
- WSS Inbound WebSocket 消息：约 1,440 条/天
- Inbound WebSocket 按 20:1 折算：1,440 / 20 = 72 个 DO 计费请求
- 另外加上约 25 个 DO HTTP 请求
因此 DO 计费请求基础值约为：25 + 1,440 / 20 ≈ 97
实际运行中还会存在其他少量 DO HTTP 请求，因此可以按照约 124 次/天进行保守估算。
理论支持数量
- D1 写入：100,000 / 1,440 ≈ 69 台
- Workers：100,000 / 1,440 ≈ 69 台
- DO 计费请求：100,000 / 124 ≈ 806 台
- D1 读取：5,000,000 / 1,440 ≈ 3,472 台
因此主要瓶颈是 D1 写入和 Workers 请求，理论上约支持：69 台服务器
实际使用过程中，如果有前端访问，Workers 请求、D1 读取以及 DO Inbound WebSocket 消耗都会增加，因此建议保守按照：62 台以上进行规划。
WSS 时段全部关闭
如果完全关闭 WSS，所有 Agent 都通过 POST 方式上报，同样假设没有前端访问。
| 资源 | 每台 Agent / 天 |
|---|---|
| D1 读取行 | 1,440 |
| D1 写入行 | 1,440 |
| Workers 请求 | ≈ 1,440 |
| DO 计费请求数 | ≈ 1,728 |
| DO Duration | 0 GB-s |
其中：
- Agent 每 60 秒上报一次：86,400 / 60 = 1,440 次
- POST 模式产生约 1,440 次 DO HTTP 请求
- 无前端订阅时，每 5 分钟执行一次 health 检查：86,400 / 300 = 288 次
- DO HTTP 总量约为：1,440 + 288 = 1,728 次/天
由于没有 WSS 长连接，因此 DO Duration 基本为 0。
理论支持数量
主要按照 DO 计费请求计算：
100,000 / 1,728 ≈ 57 台
因此理论上约支持：57 台服务器
考虑前端访问以及其他额外请求，实际建议保守按照：55 台以上进行规划。
夜间关闭 WSS 6 小时
如果希望夜间降低 Cloudflare 资源消耗，可以设置每天 6 小时关闭 WSS，但 Agent 仍然保持 60 秒一次的 POST 上报。
也就是说：
- 白天 18 小时：使用 WSS
- 夜间 6 小时：关闭 WSS，改用 POST
- 采样间隔：1 秒
- 上报间隔：60 秒
- WSS 上报间隔：1 秒
- 完全无前端访问
此时单台 Agent 每天大约消耗：
| 资源 | 每台 Agent / 天 |
|---|---|
| D1 读取行 | ≈ 1,440 |
| D1 写入行 | ≈ 1,440 |
| Workers 请求 | ≈ 360 |
| DO 计费请求数 | ≈ 527 |
| DO Duration | ≈ 8,100 GB-s |
WSS 运行 18 小时
WSS Duration：10,800 × 18 / 24 = 8,100 GB-s
WSS Inbound WebSocket 消息：18 × 60 = 1,080 条/天
按 20:1 折算：1,080 / 20 = 54 个 DO 计费请求
POST 运行 6 小时
POST 上报次数：6 × 60 = 360 次
对应产生约 360 次 Workers 请求和约 432 次 DO HTTP 请求。
综合计算后，DO 计费请求约为：527 次/天
理论支持数量
- D1 写入：100,000 / 1,440 ≈ 69 台
- Workers：100,000 / 360 ≈ 277 台
- DO 计费请求：100,000 / 527 ≈ 189 台
- D1 读取：5,000,000 / 1,440 ≈ 3,472 台
此时主要瓶颈仍然是 D1 写入：理论上约支持 69 台服务器。
考虑前端访问以及其他额外消耗，建议保守按照：60～65 台服务器进行规划。
相比 WSS 全天开启，夜间关闭 6 小时可以明显降低 DO Duration 和 DO 计费请求，同时又不会停止监控数据上报。
三种模式对比
| 模式 | D1 读/天 | D1 写/天 | Workers/天 | DO 计费请求/天 | DO Duration/天 | 理论服务器数 |
|---|---|---|---|---|---|---|
| WSS 全天开启 | ≈1,440 | ≈1,440 | ≈1,440 | ≈124 | ≈10,800 GB-s | ≈69 台 |
| WSS 全天关闭 | ≈1,440 | ≈1,440 | ≈1,440 | ≈1,728 | 0 | ≈57 台 |
| 夜间关闭 WSS 6 小时 | ≈1,440 | ≈1,440 | ≈360 | ≈527 | ≈8,100 GB-s | ≈69 台 |
注意：上表中的“理论服务器数”是按照各项免费额度分别计算后的主要瓶颈估算值，并不是所有资源同时精确达到免费额度时的实际保证值。实际使用时还会受到前端访问、Agent 重连、WebSocket 建立、DO HTTP 请求以及其他业务逻辑影响。
采样间隔、上报间隔、WSS 上报间隔
1. 采样间隔
采样间隔主要影响 Agent 本身的资源消耗。
Agent 会按照采样间隔收集不影响IO的参数：
- CPU
- RAM
- 网络流量
采样频率越高，Agent 执行采集任务的次数越多，因此会增加少量 CPU 和内存开销。
不过对于绝大多数服务器来说，这部分消耗非常低。
实测 128 MB NAT Alpine 服务器，在 1 秒采样间隔下运行也没有明显压力。
因此，如果服务器性能非常差，可以适当调高采样间隔；普通服务器一般可以直接使用 1 秒采样。
采样间隔主要影响 Agent 本身的负载，不直接决定 D1 每天写入多少数据。
2. 上报间隔
上报间隔主要影响 D1 写入量以及数据实时性。
例如：上报间隔 = 60 秒
表示 Agent 每 60 秒向服务端上报一次数据。
一天大约：86,400 / 60 = 1,440 次
如果关闭 WSS，Agent 使用 POST 上报，那么上报间隔越短：
- Workers 请求越多
- D1 写入越多
- DO HTTP 请求越多
- 数据实时性越高
反之，提高上报间隔可以降低 Cloudflare 资源消耗，但前端看到的数据也会有更明显的延迟。
3. WSS 上报间隔
WSS 上报间隔主要影响开启 WSS 后的实时性以及 DO Inbound WebSocket 消息数量。
例如：WSS 上报间隔 = 1 秒
当前端有人访问时，可以按照 1 秒间隔通过 WebSocket 实时推送数据，让监控页面基本做到实时更新。
而当前端无人访问时，Agent 不需要频繁推送实时数据，服务端会让 Agent 自动降低上报频率，回退到60 秒
这样可以实现：有用户访问时追求实时性，无用户访问时降低资源消耗。
因此，对于个人服务器、NAS、软路由以及轻量业务节点等场景，可以使用：
采样间隔：1 秒
上报间隔：60 秒
WSS 上报间隔：1 秒
推荐配置
| 参数 | 推荐值 | 主要影响 |
|---|---|---|
| 采样间隔 | 1 秒 | Agent CPU / 指标采集频率 |
| 上报间隔 | 60 秒 | D1 写入、Workers 请求 |
| WSS 上报间隔 | 1 秒 | 实时性、DO Inbound WS |
如果希望进一步降低夜间 Cloudflare 资源消耗，可以设置：夜间 6 小时关闭 WSS，但继续保持 POST 上报。
这种方式不会停止 Agent 上报，只是夜间不维持 WebSocket 实时连接，可以在实时性、资源消耗和免费额度之间取得比较好的平衡。
总结
- 采样间隔决定“多久采一次数据”。
- 上报间隔决定“多久向服务端上报一次数据”。
- WSS 上报间隔决定“前端有人访问时多久更新一次实时数据”。
- 关闭 WSS不会停止 Agent 上报，只会从 WebSocket 模式切换到 POST 模式。
- 夜间关闭 WSS 6 小时可以降低 DO Duration 和 DO 计费请求消耗，D1 每天仍然约写入 1,440 行/台。
- 在上述配置下，Cloudflare 免费额度理论上可以支持约 57～69 台服务器，具体取决于 WSS 的使用策略和前端访问情况。
- 如果考虑实际使用中的额外消耗，建议按照 55～65 台服务器作为比较保守的规划范围。
对于希望长期运行在 Cloudflare 免费额度内的用户，“白天 WSS、夜间关闭 WSS”是一个比较合适的方案：前端有人使用时提供实时监控，夜间无人访问时减少不必要的 WebSocket 资源消耗。
以上数据为基于当前架构和指定参数的理论估算，实际消耗会受到前端访问、Agent 重连、WebSocket 建立及其他业务请求影响。