绑了一个免费的二级域名到cf账号里，现在在worker的配置页能看到domain标签，但是配置了以后访问自定义域名没生效，有没有佬可以截图让我抄一下配置看看我哪弄错了 9 个帖子 - 6 位参与者 阅读完整话题
rt，做成workers了，还没测试工具调用 地址是: https://lumo2api.ooyyh.x10.mx key填任意值 3 个帖子 - 3 位参与者 阅读完整话题
我想用cloudflare workers加速下hf模型的下载,搞了一个转发,请求hf的内容 然后发现响应头中不包括 accept-ranges ,不知道怎么回事,因为直接请求hf的时候响应是带的,转发后就没了. 所以问下大佬们,有没有遇到过这种情况,怎么解决的? 1 个帖子 - 1 位参与者 阅读完整话题
想通过cf workers做个东西把自己的规则集和开源的规则集，以及机场订阅及个人代理都做一个聚合。小火箭好像不支持clash那种yaml格式，就像问问有没有佬买了stash的，借我在ios上下一个。macos端我看好像有人分享了Stash的dmg，也有别的替代，就是ios端没啥替代，好像只能stash 1 个帖子 - 1 位参与者 阅读完整话题
起因： 某些邮箱的 SMTP 发送服务，不会将发送日志记录到到 [已发送] ，需要自己想办法实现发送日志记录。同时调用 SMTP 发送邮件通常需要依赖第三方库，使用起来不是很方便，于是在 AI 的辅助下开发了这个 Zsend 服务。 Zsend 后端可配置多个 STMP 账号，并提供 HTTP API 发送接口，简化了使用方式和没有日志记录的问题。 主要特点 通过 HTTP 接口发送邮件，支持多 SMTP 账号 按请求里的 from 地址精确匹配 SMTP 账号 支持 text 、 html 、 markdown 三种正文类型 SMTP 发送失败时自动重试一次 将邮件发送日志写入 Cloudflare D1 发信接口使用 Bearer Token 鉴权 支持 WebUI 查看发送日志 Github 项目地址中提供了部署方法： https://github.com/helloxz/zsend
起因： 某些邮箱的 SMTP 发送服务，不会将发送日志记录到到 [已发送] ，需要自己想办法实现发送日志记录。同时调用 SMTP 发送邮件通常需要依赖第三方库，使用起来不是很方便，于是在 AI 的辅助下开发了这个 Zsend 服务。 Zsend 后端可配置多个 STMP 账号，并提供 HTTP API 发送接口，简化了使用方式和没有日志记录的问题。 主要特点 通过 HTTP 接口发送邮件，支持多 SMTP 账号 按请求里的 from 地址精确匹配 SMTP 账号 支持 text 、 html 、 markdown 三种正文类型 SMTP 发送失败时自动重试一次 将邮件发送日志写入 Cloudflare D1 发信接口使用 Bearer Token 鉴权 支持 WebUI 查看发送日志 Github 项目地址中提供了部署方法： https://github.com/helloxz/zsend
起因： 某些邮箱的 SMTP 发送服务，不会将发送日志记录到到 [已发送] ，需要自己想办法实现发送日志记录。同时调用 SMTP 发送邮件通常需要依赖第三方库，使用起来不是很方便，于是在 AI 的辅助下开发了这个 Zsend 服务。 Zsend 后端可配置多个 STMP 账号，并提供 HTTP API 发送接口，简化了使用方式和没有日志记录的问题。 主要特点 通过 HTTP 接口发送邮件，支持多 SMTP 账号 按请求里的 from 地址精确匹配 SMTP 账号 支持 text 、 html 、 markdown 三种正文类型 SMTP 发送失败时自动重试一次 将邮件发送日志写入 Cloudflare D1 发信接口使用 Bearer Token 鉴权 支持 WebUI 查看发送日志 Github 项目地址中提供了部署方法： https://github.com/helloxz/zsend
cbsnews.com At least 1 dead, 9 workers missing after chemical tank implosion at... The damaged tank at Nippon Dynawave Packaging Co. held approximately 900,000 gallons of white liquor, a chemical used in paper processing, authorities said. [!quote]+ 当地政府称，华盛顿州南部一家纸浆和造纸厂周二发生化学品罐内爆事故，造成至少一人死亡，九名工人下落不明。 日本 Dynawave 包装公司位于华盛顿州南部与俄勒冈州交界的朗维尤市的工厂发生罐体破裂，造成八名员工和一名消防员受伤。该部门没有说明遇难者是否为工人。 官员们说，已经通知了所有九名下落不明员工的家属。 CNN – 26 May 26 At least 1 dead and 9 missing after a chemical tank rupture at a paper and... At least one person has died, nine people were injured and nine employees remain unaccounted for after a large vat of chemical treatment product, including hazardous materials, ruptured at a paper and packaging facility in Washington state, fire... bbc.com Longview explosion: one killed and others missing after blast at paper mill Nine others were injured and another nine are missing after a tank ruptured at a paper mill in Longview, Washington. 1 个帖子 - 1 位参与者 阅读完整话题
各位 V 友， 翻译 PDF 最痛苦的不是翻译本身，而是“格式崩溃”和“不可干预”。市面上大多数翻译工具都是上传 PDF 直接出一份不可修改的译文，遇到公式、表格错位或者 AI 抽风翻译错词，用户基本无计可施。 为了解决这个问题，我做了一个在线 PDF 翻译工具： onlinepdftranslator.com 🛠️ 技术栈与思路 我没有采用传统的“直出”方案，而是引入了 Markdown 作为中间层： 解析层：利用结构化 Vision-Language 模型将 PDF/图片解析为带格式的 JSON ，自动识别标题、段落、表格。 存储层：所有解析出的图片资源自动落盘到 Cloudflare R2 ，解决百度云域名限制及访问速度问题。 翻译层：接入顶级 LLM （支持普通/专业翻译双模式），对结构化文本进行分段翻译。 编辑层（核心）：前端集成 Milkdown 渲染。我选型 Milkdown 是看中了它的插件化能力和对表格、公式的友好支持。用户可以直接在“所见即所得”的 Markdown 编辑器里进行微调。 渲染层：基于 Cloudflare Browser Rendering API ，通过 headless Chrome 实例将最终的 HTML/CSS 打印成高保真 PDF ，规避了 jsPDF 等前端库处理中文和分页时的各种坑。 ✨ 工具亮点 全栈 Serverless：前后端一体化部署在 Cloudflare Workers 上，响应速度极快。 Markdown 控制权：支持直接导出 MD 文件，或者在编辑器里调整好格式后再导出 PDF/Doc/Excel 。 表格 & 公式友好：针对学术论文和技术文档，支持 LaTeX 实时渲染和复杂的表格编辑插件。 多种导出：除了常规 PDF ，还可以基于原始 JSON 的表格节点，直接生成带样式的 Excel 结构，不丢失单元格属性。 🚀 访问地址 onlinepdftranslator.com 目前项目处于持续迭代中，非常欢迎各位 V 友试用并提出技术建议。
之前看到 Cloudflare 推出的 vinext 能用 vite 来构建 Next.js, 于是上手试了一下顺便整了个订阅到期提醒管理应用. 跑在 Cloudflare worker 上, 零成本. 支持的通知方式: Telegram, webhook, wecombot(企业微信机器人), bark, notifyx, resend, smtp 部署 一键部署 优点是部署简单, 缺点是不方便后续的更新(我自己部署跑了一个多月了, 后续基本不会更新了) GitHub action 部署 fork 仓库后还需要准备: D1 数据库 id,KV Namespace id,Cloudflare Account ID,Cloudflare API Token 具体步骤参照: readme 优点是 sync fork 后自动同步后续的更新, 缺点是部署麻烦要填 action 环境变量 部分页面展示 开源地址 https://github.com/Merack/subflare-vinext
本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容： 我的帖子已经打上 开源推广 标签： 是 我的开源项目完整开源，无未开源部分： 是 我的开源项目已链接认可 LINUX DO 社区： 是 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是 以上选择我承诺是永久有效的，接受社区和佬友监督： 是 以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出 首页UI 顶部的长方形区域 可以根据3篇帖子的头图自动显示为某一篇帖子的大图，嘎嘎好看 示例站点 后台配备了apitotken可以直接调用传文章 图片自动上传到r2 只需要一个域名就能搭建一套完整的博客系统。 开源地址： GitHub - LordVibeCoding/serverless-cloudflare-blog: Serverless news-magazine blog on Cloudflare · Next.js 16 + D1 + R2 + Tiptap · GitHub 6 个帖子 - 6 位参与者 阅读完整话题
- Cloudflare Free Plan 全家桶 Pages：前端部署 Workers：后端接口 R2：文件缓存 KV：数据缓存 - Deno：做中继转发，解决 Workers 30 秒超时限制 - Telegram：当素材服务用，变相实现无限对象存储 - Hugging Face Spaces：运行 FFmpeg，用来处理视频任务 这套方案的优点：不要钱, 并且网站速度还行 佬友们有没有更快、更稳、更优雅，但依然免费的方案？ 1 个帖子 - 1 位参与者 阅读完整话题
临时邮箱最大的用途，是在注册网站、接收验证码或做测试时，避免把自己的常用邮箱暴露出去。很多公共临时邮箱虽然方便，但经常遇到广告多、地址被封、稳定性差、验证码收不到等问题。如果手里有一个自己的域名，就可以把邮件接收能力掌握在自己手里。 这篇文章把整个流程合并成一篇，从免费域名申请、托管到 Cloudflare，再到使用 Cloudflare Workers、D1、KV 和 Email Routing 搭建临时邮箱服务，完整走一遍。 一、准备一个可托管到 Cloudflare 的域名 搭建域名邮箱，首先需要一个域名。域名可以购买，也可以使用支持 Cloudflare 托管的免费二级域名。 常见选择包括： DigitalPlat / FreeDomain：部分后缀支持 Cloudflare，但账号注册可能需要 KYC，部分后缀也可能收费。 DNSHE：注册门槛较低，只需邮箱验证，部分免费二级域名可以直接托管到 Cloudflare。 DNSHE 当前可用的免费根域包括 cc.cd 、 cn.mt 、 ccwc.cc 、 bbroot.com 等。其中部分后缀可以直接注册并接入 Cloudflare，部分可能需要邀请码。 DNSHE 注册域名流程 打开 DNSHE 网站并注册账号。 填写邮箱、密码，完成邮箱验证码验证。 登录后台后，进入左侧的 Free Domains 。 点击 Register a Domain 。 选择一个可用根域，例如 cc.cd 或 ccwc.cc 。 填写想要的二级域名前缀。 点击确认注册。 注册完成后，就得到一个类似 example.cc.cd 这样的免费二级域名。 二、把域名接入 Cloudflare 域名拿到后，需要把它托管到 Cloudflare，这样后续才能使用 Workers、Email Routing 等能力。 操作流程： 登录 Cloudflare。 进入 Domains / 域 页面。 点击添加域名。 输入刚刚注册的域名。 选择 Free 免费计划。 DNS 记录可以先不添加，直接继续。 Cloudflare 会给出两条 nameserver。 回到 DNSHE，把域名的 nameserver 替换成 Cloudflare 提供的两条。 回到 Cloudflare 点击“我已更新名称服务器”。 等待解析生效，通常几分钟到几十分钟不等。 当 Cloudflare 中域名状态显示为 Active / 活动 后，说明域名已经成功托管。 三、选择临时邮箱项目 Cloudflare Workers 生态里有不少临时邮箱项目可以使用，常见选择包括： Cloudflare Temp Mail Freemail Moemail 如果只是想快速搭建一个可用的临时邮箱平台，可以选择 Cloudflare Temp Mail。它通常包含 Worker 后端、D1 数据库表结构、KV 缓存、前端页面等内容。 四、创建 D1 数据库 后端需要存储邮件、地址、用户等数据，因此要先创建 D1 数据库。 步骤如下： 在 Cloudflare 后台打开 存储与数据库 。 进入 D1 SQL 数据库 。 点击创建数据库。 输入数据库名称，例如 mail_d1 。 创建完成后进入该数据库。 创建后数据库是空的，还需要初始化表结构。 初始化表结构 打开 Cloudflare Temp Mail 项目仓库。 找到 db/schema.sql 。 复制 SQL 内容。 回到 Cloudflare D1 数据库页面。 打开 控制台 。 粘贴 SQL 并执行。 执行成功后，刷新概览页，如果能看到多个数据表，说明数据库初始化完成。 五、创建 Workers KV 除了 D1，还需要创建 KV 命名空间，用于缓存或存储部分运行状态。 步骤： 在 Cloudflare 后台进入 Workers KV 。 点击创建实例。 命名为 mail_kv 或其他容易识别的名称。 创建即可，不需要额外配置。 后续绑定时要注意变量名： D1 数据库绑定变量名通常填写 DB KV 绑定变量名通常填写 KV 变量名写错会导致 Worker 运行时报错。 六、部署后端 Worker 后端 Worker 用来接收邮件、处理 API 请求、读写 D1 和 KV。 创建 Worker 打开 Cloudflare 后台。 进入 Workers 和 Pages 。 点击创建应用程序。 选择从 Hello World 开始。 设置 Worker 名称，例如 xapi 。 点击部署。 部署后，会得到一个类似： https://xapi.<account-name>.workers.dev 的后端地址。 绑定 D1 和 KV 进入刚创建的 Worker： 打开设置或绑定选项卡。 添加 D1 数据库绑定。 变量名填写 DB 。 选择前面创建的 D1 数据库。 添加 KV 命名空间绑定。 变量名填写 KV 。 选择前面创建的 KV 实例。 七、配置变量和机密 后端还需要一些环境变量。常见配置如下： DOMAINS = ["example.cc.cd"] DEFAULT_DOMAINS = ["example.cc.cd"] DISABLE_ANONYMOUS_USER_CREATE_EMAIL = false JWT_SECRET = "你的随机密钥" ADMIN_PASSWORDS = ["你的管理员密码"] ENABLE_ADDRESS_PASSWORD = false ENABLE_AUTO_REPLY = false ENABLE_USER_CREATE_EMAIL = true ENABLE_USER_DELETE_EMAIL = true USER_ROLES = [ {"domains": ["example.cc.cd"], "prefix": "", "role": "vip"}, {"domains": ["example.cc.cd"], "prefix": "", "role": "admin"} ] ADMIN_USER_ROLE = "admin" 其中： DOMAINS ：允许使用的域名列表。 DEFAULT_DOMAINS ：未登录用户可使用的默认域名。 JWT_SECRET ：JWT 签名密钥，建议随机生成。 ADMIN_PASSWORDS ：后台管理员密码列表。 ENABLE_USER_CREATE_EMAIL ：是否允许用户创建邮箱。 ENABLE_USER_DELETE_EMAIL ：是否允许用户删除邮箱。 添加变量后，记得重新部署 Worker。 另外，在 Worker 设置中建议开启兼容性标志： nodejs_compat 八、替换 Worker 代码 刚创建的 Worker 默认只是 Hello World，需要替换为临时邮箱项目提供的 Worker 脚本。 操作方式： 打开 Cloudflare Temp Mail 项目发布页或仓库。 下载或复制 worker.js 。 回到 Cloudflare Worker 的代码编辑页面。 删除默认 Hello World 代码。 粘贴或上传新的 worker.js 。 点击部署。 部署完成后，后端就具备了临时邮箱的 API 和邮件处理能力。 九、配置自定义后端域名，可选 如果不想直接使用 workers.dev 域名，可以给后端绑定自定义域名，例如： xapi.example.cc.cd 在 Worker 设置里的 域和路由 中添加自定义域名即可。Cloudflare 会自动为当前域名添加对应路由记录。 这个步骤不是必须的，但如果前端访问后端不稳定，使用自定义域名通常更方便。 十、开启 Cloudflare Email Routing 临时邮箱要能收邮件，必须开启 Cloudflare Email Routing。 步骤： 在 Cloudflare 中打开对应域名。 进入 电子邮件 / Email 。 打开 电子邮件路由 / Email Routing 。 点击添加记录并启用。 Cloudflare 会自动添加 MX、SPF、DKIM 等相关记录。 启用后，还要配置路由规则。 配置 Catch-All 进入 Email Routing 的路由规则页面。 开启 Catch-All。 编辑 Catch-All 操作。 操作选择 发送到 Worker 。 目标选择刚刚部署的后端 Worker，例如 xapi 。 保存。 这样，所有发往 @example.cc.cd 的邮件都会交给 Worker 处理。 十一、部署前端页面 后端完成后，还需要一个前端页面来创建邮箱、查看邮件、登录后台等。 如果使用 Cloudflare Temp Mail 自带前端，可以按以下方式部署： 打开项目文档中的前端生成页面。 输入自己的后端地址。 生成 frontend.zip 。 回到 Cloudflare Workers 和 Pages 。 点击创建应用程序。 选择上传静态文件。 上传 frontend.zip 。 设置项目名称，例如 webui 。 高级设置中，将未找到处理设置为 single-page-application 。 点击部署。 前端部署后，建议绑定自定义域名，例如： mail.example.cc.cd 如果前端需要给国内用户访问，自定义域名通常比默认 workers.dev 更实用。 十二、后台管理和使用方式 打开前端地址后，就可以使用临时邮箱系统。 常见入口方式： 连续点击页面 Logo 多次进入管理入口。 或者访问 /admin 路径。 输入前面设置的 ADMIN_PASSWORDS 后，可以进入后台。 后台通常可以管理： 邮箱地址 用户 邮件 域名配置 统计数据 维护功能 Telegram 机器人或其他高级功能 按照基础配置，这套系统一般可以满足接收验证码、注册测试、临时收信等需求。如果需要发信、自动回复、AI 邮件解析、Telegram 通知等功能，还需要继续配置额外服务。 十三、常见问题 1. 收不到邮件怎么办？ 优先检查： 域名是否已经在 Cloudflare 中显示 Active。 Email Routing 是否已启用。 MX 记录是否存在。 Catch-All 是否已经指向正确的 Worker。 Worker 是否绑定了正确的 D1 和 KV。 变量名是否严格为 DB 和 KV 。 2. Worker 报错怎么办？ 重点检查： nodejs_compat 是否开启。 JWT_SECRET 是否已设置。 DOMAINS 和 DEFAULT_DOMAINS 是否是合法 JSON。 ADMIN_PASSWORDS 是否是数组格式。 D1 数据库是否已经执行过 schema.sql 。 3. 前端无法访问后端怎么办？ 可以尝试： 给后端绑定自定义域名。 检查前端生成时填写的后端 URL 是否正确。 检查浏览器控制台是否有 CORS、网络连接或 API 报错。 总结 整套流程可以概括为： 申请一个可托管到 Cloudflare 的域名。 把域名 nameserver 切到 Cloudflare。 创建 D1 数据库并初始化表结构。 创建 KV 命名空间。 创建后端 Worker，绑定 D1、KV 和环境变量。 替换为临时邮箱项目的 Worker 代码。 启用 Email Routing，并把 Catch-All 指向 Worker。 上传前端静态文件并绑定自定义域名。 打开前端页面开始创建和管理临时邮箱。 完成后，你就拥有了一套基于 Cloudflare 免费资源的自建临时邮箱系统。它不依赖传统服务器，维护成本低，适合个人测试、验证码接收和临时注册场景。 1 个帖子 - 1 位参与者 阅读完整话题
各位佬友有尝试过使用Cloudflare Worker部署Vaultwarden吗？体验怎么样，安全隐患大不大？ 4 个帖子 - 3 位参与者 阅读完整话题
佬们，cf的workers和pages现在为什么看不了,都是空白的，什么原因，还有就是woker的编辑代码功能也没见了 3 个帖子 - 2 位参与者 阅读完整话题
通过Workers 调用和直接API调用是同一个通用额度吗？ 一开始不知道，看了下文档每月存储额度是要乘以维度的。 以1000维度的key能存5000个。 每月30m的调用额度要不要乘以维度？ 我存储1.8万个1000维的数据，算1.82M，统计表里一周600k请求（这个是实际请数还是乘维度的？），估算一月3m的请求，在存储上是不是要收费了？ 1 个帖子 - 1 位参与者 阅读完整话题
最近在 Cloudflare Workers 上接外部 Redis / Valkey ，发现传统 Node 服务那套“建一个 Redis client 然后复用连接”的思路不太行 Worker 会冷启动、冻结、恢复或回收，模块级 client 虽然能复用，但不像常驻进程里的连接池那么可靠。实际遇到的现象是：client 看起来 ready ，但 Redis 命令经常 timeout ，后续还会引发一些连带错误。尤其是从 cloudflare 阿姆斯特丹机房到 digital ocean 班加罗尔机房的连接质量差得离谱，已经超时到无法忍受了 我现在的临时处理是：Serverless 侧不直接维护 Redis TCP 连接，改成通过 HTTP 访问 Redis ，把连接池放到更适合常驻运行的地方。现在从 cloudflare 全球机房，到 racknerd 洛杉矶机房的 redis 代理，到 digital ocean 旧金山机房里的真实 redis 。虽然绕路更多了，但是基本不超时了 Worker -> HTTP -> Redis proxy -> Redis 但自建 Redis proxy 也挺麻烦，平台原生的 redis 资源又很贵 想请教大家：Serverless / Edge Runtime 里访问 Redis 、数据库、MQ 这类需要连接的外部资源，大家一般是直接连、HTTP API / proxy ，还是尽量改用平台原生存储？这种情况下有没有什么最佳实践？
最近在 Cloudflare Workers 上接外部 Redis / Valkey ，发现传统 Node 服务那套“建一个 Redis client 然后复用连接”的思路不太行 Worker 会冷启动、冻结、恢复或回收，模块级 client 虽然能复用，但不像常驻进程里的连接池那么可靠。实际遇到的现象是：client 看起来 ready ，但 Redis 命令经常 timeout ，后续还会引发一些连带错误。尤其是从 cloudflare 阿姆斯特丹机房到 digital ocean 班加罗尔机房的连接质量差得离谱，已经超时到无法忍受了 我现在的临时处理是：Serverless 侧不直接维护 Redis TCP 连接，改成通过 HTTP 访问 Redis ，把连接池放到更适合常驻运行的地方。现在从 cloudflare 全球机房，到 racknerd 洛杉矶机房的 redis 代理，到 digital ocean 旧金山机房里的真实 redis 。虽然绕路更多了，但是基本不超时了 Worker -> HTTP -> Redis proxy -> Redis 但自建 Redis proxy 也挺麻烦，平台原生的 redis 资源又很贵 想请教大家：Serverless / Edge Runtime 里访问 Redis 、数据库、MQ 这类需要连接的外部资源，大家一般是直接连、HTTP API / proxy ，还是尽量改用平台原生存储？这种情况下有没有什么最佳实践？
最近在 Cloudflare Workers 上接外部 Redis / Valkey ，发现传统 Node 服务那套“建一个 Redis client 然后复用连接”的思路不太行 Worker 会冷启动、冻结、恢复或回收，模块级 client 虽然能复用，但不像常驻进程里的连接池那么可靠。实际遇到的现象是：client 看起来 ready ，但 Redis 命令经常 timeout ，后续还会引发一些连带错误。尤其是从 cloudflare 阿姆斯特丹机房到 digital ocean 班加罗尔机房的连接质量差得离谱，已经超时到无法忍受了 我现在的临时处理是：Serverless 侧不直接维护 Redis TCP 连接，改成通过 HTTP 访问 Redis ，把连接池放到更适合常驻运行的地方。现在从 cloudflare 全球机房，到 racknerd 洛杉矶机房的 redis 代理，到 digital ocean 旧金山机房里的真实 redis 。虽然绕路更多了，但是基本不超时了 Worker -> HTTP -> Redis proxy -> Redis 但自建 Redis proxy 也挺麻烦，平台原生的 redis 资源又很贵 想请教大家：Serverless / Edge Runtime 里访问 Redis 、数据库、MQ 这类需要连接的外部资源，大家一般是直接连、HTTP API / proxy ，还是尽量改用平台原生存储？这种情况下有没有什么最佳实践？
最近在 Cloudflare Workers 上接外部 Redis / Valkey ，发现传统 Node 服务那套“建一个 Redis client 然后复用连接”的思路不太行 Worker 会冷启动、冻结、恢复或回收，模块级 client 虽然能复用，但不像常驻进程里的连接池那么可靠。实际遇到的现象是：client 看起来 ready ，但 Redis 命令经常 timeout ，后续还会引发一些连带错误。尤其是从 cloudflare 阿姆斯特丹机房到 digital ocean 班加罗尔机房的连接质量差得离谱，已经超时到无法忍受了 我现在的临时处理是：Serverless 侧不直接维护 Redis TCP 连接，改成通过 HTTP 访问 Redis ，把连接池放到更适合常驻运行的地方。现在从 cloudflare 全球机房，到 racknerd 洛杉矶机房的 redis 代理，到 digital ocean 旧金山机房里的真实 redis 。虽然绕路更多了，但是基本不超时了 Worker -> HTTP -> Redis proxy -> Redis 但自建 Redis proxy 也挺麻烦，平台原生的 redis 资源又很贵 想请教大家：Serverless / Edge Runtime 里访问 Redis 、数据库、MQ 这类需要连接的外部资源，大家一般是直接连、HTTP API / proxy ，还是尽量改用平台原生存储？这种情况下有没有什么最佳实践？