官网 esim.lilt.pw esim.gg 公开号码库 · FreeSIM Watch esim.gg 多后端节点公开号码目录与支付链接网关 前言 之前我用了7个cloudfare的后端都无法稳定供应一天的访问量。于是，我就想着该怎么缓解或者解决这个问题，于是在我冥思苦想了一天的情况下，我终于想到了一个好的方法。 更新思路 首先，我想到的思路是，既然访问量比较大，d1是通过读取行数来判断的。并且官网的电话号码又是长时间不需要实时更新的数据，我不更新最近的1分钟的也不会影响你选号（哈哈哈哈哈）。 那我不需要实时更新记录，我可以借助缓存啊，看看能不能使用cloudfare的缓存机制。于是我在ai探索了后，我发现，可以使用缓存，但是呢，基本只能缓存已经有人访问过的，不能缓存没访问的，比如全网用户查询了前100页，但是未保存后面399页，那就无法访问到后399页的缓存数据，并且，缓存时间也是个问题，基本就是5-10分钟，那这就不好了呀，那我一晚上到第二天8点的时间怎么办？ 于是我又问了ai，那我想在d1数据库失效后，能够保持访问到第二天的更新时间，你有什么方法吗？AI就给我推荐并引入了cloudfare的R2。我一看，这还得了，别给我银行卡干爆了，付不起账单。 我再三思索，有了，我可以创建一个github仓库，私有，然后再一段时间内同步，再同步后，如果d1全部失效，我就直接去读取github仓库的json文件，这样就可以加载出来内容了。但是呢，这个github是有api的访问频率限制的，这下坏了，还有什么可以不限制访问频率呢？ 突然我想到了之前下载插件送积分里面有个存储网站，我就问了一下，还真可以，于是就有了当前的这个版本，这个版本，在默认时会使用d1，可以同步最新的数据，在d1消耗完后，就会转移到数据网站，然后就不会抛出d1错误了，就可以继续做了。 最后 感谢各位佬的使用，佬们也好几次反馈了这个问题，今天终于是简单的解决了一下，后续看看这个问题还会不会存在，感谢佬们的反馈和使用！ 1 个帖子 - 1 位参与者 阅读完整话题

  • 情报分类：硬件与数码
  • 分类依据：内容涉及硬件、数码产品或通信卡
  • 信息来源：服务器 / LINUX DO - 最新话题
  • 发布时间：2026/9/19 19:12:30