Cloudflare

本文介绍了 编者 如何为 Matrix 服务设置外网端口，并讨论了其部署和管理过程中的技术细节与隐私考量。尽管最初尝试直接暴露服务时，Cloudflare 可能会拦截反复递包的设备，导致部分数据包丢失或无法登录，但通过建立连接后，服务能够保持稳定，实现即时消息接收。在域名管理方面，由于使用自有域名，可以创建多个子域名，分别分配给 ntfy 和 Matrix 服务，极大地简化了管理难度。技术上，部署环境有不同，裸机部署可使用 localhost，而容器化部署则需要使用内网 IP 地址。编者选择在家庭服务器（树莓派）上运行 Matrix，并刻意关闭了注册功能，因为 Matrix 的设计本身就是逆管理的，内容加密至本地，难以被外部拦截。为了避免网站被搜索引擎索引，编者采取了开启 Cloudflare 的 robots.txt 机制进行应对。本文强调了这种私密部署模式的优势，即在保证功能可用的同时，最大程度地保护了个人隐私。

本文介绍了 Matrix 这一去中心化聊天网络，旨在挑战那些仅满足于破解本地聊天记录、却不愿构建自身安全堡垒的隐私观。文章描述了如何通过自建“家服务器”来夺回数据主权，实现真正可控的隐私保护。首先，文章阐述了搭建这一系统的基础要求，包括选择硬件，例如 Raspberry Pi 5 或云服务器，并确保操作系统是 Linux 系统，推荐使用 Ubuntu 或 Debian。其次，一个域名至关重要，用于标识服务，推荐使用 NameSilo 等服务商。在部署流程上，作者详细介绍了如何使用 1Panel 这一自动化平台来简化复杂的 Docker 容器管理。核心服务 Synapse 的安装并非简单的一步，需要通过特定的 `docker run` 命令进行关键的初始化，为服务器“打下地基”，确保域名配置正确。为了让服务能够被外部访问，文章强调了 DNS 配置的重要性，强烈推荐使用 Cloudflare 来托管域名，并开启 Proxy 以提供免费的 HTTPS 代理服务，保障安全性。最后，文章阐述了用户创建过程，包括创建具有高权限的管理员账户和日常使用的普通用户账户。本文总结道，自建 Matrix 服务器是一个主动争取个人数据主权的积极过程，它提供了一种合法、可控且高度保护隐私的通信方式，与依赖偷偷摸摸“破解”的虚假隐私理念形成了鲜明对比。这一实践证明，真正的隐私保护，是通过主动构建和维护自己的数字基础设施来实现的。

本文介绍了作者在使用 Cloudflare 解析 DNS 时遇到的登录困境及其解决过程。6 月 14 日晚，作者清理缓存时发现 Cloudflare 登录已退出，且因一周未使用梯子，登录验证反复卡住。作者试图续费梯子，但梯子官网无法访问，转而通过路由分流仍无法购买，原因是微信和支付宝余额仅剩 4 元——此前 30 元充值了 AI 的 API，10 元购买了游戏送给朋友。作为未成年人，作者不愿花父母的钱，也不愿养成伸手要钱的习惯，曾靠经营闲鱼小铺每天赚 100 元，但店铺已注销。在紧张之际，作者回忆起 GitHub 账号绑定过邮箱，且 Cloudflare 也绑定了 GitHub 账号，推测可通过官方授权方式绕过验证。作者冒险尝试点击 GitHub 授权，最终成功登录 Cloudflare 并清除了缓存，解决了问题。全文记录了在资金不足、网络受限的情况下，利用已有账号关联关系实现登录的曲折经历。

本文介绍了作者遭遇邮件轰炸的经历，起初怀疑一位儒雅随和的朋友，但随后发现自己的 QQ 邮箱地址曾公开写在网站的关于页面中，可能被搜索引擎爬虫抓取并汇入垃圾邮件发送者数据库，导致攻击者可能是陌生人。作者于 26 号修改了网站设置，彻底删除 QQ 邮箱显示，替换为专用的域名邮箱，并决定日常不再使用已暴露的 Q 邮。文章提醒独立博客作者检查公开邮箱，建议将邮箱隐藏在卡片或联系表单后，防止爬虫抓取明文地址。作者反思之前关闭了 Cloudflare 的邮箱保护功能，导致防线失守，并警告有一伙人正大规模从搜索引擎结果中扫描公开邮箱发动垃圾轰炸。虽然攻击者仍可能是熟人，但邮箱公开使得线索指向两个方向：社交圈内敌意或无差别自动化攻击。作者最终将问题交给黑名单机制处理，等待真相。

本文介绍了作者在处理 Waline 评论系统邮件通知失效问题时，通过排查与配置 DMARC 记录最终解决邮件被拒收或误判为垃圾邮件的过程。作者在周六晚上发现未收到访客留言的邮件提醒，起初怀疑是 Q 邮箱容量超限，但清理收件箱后问题依旧。随后查阅 Resend 后台建议，注意到“未配置 DMARC 策略”是导致邮件被主流服务商拒收的关键原因。通过咨询 DeepSeek 了解到，DMARC 是 1 种用于邮件验证的 TXT 记录子域名，相当于发件方向邮箱服务商提供的官方授权说明，自 2024 年起各大邮件服务商已大幅收紧收信规则。作者在 Cloudflare 上为域名添加了 1 条名为 _dmarc 的 TXT 记录，并填写了包含 v=DMARC1; p=none; 等参数的值，同时将 rua 地址替换为自己的邮箱以接收报告。文章还提醒 DNS 记录修改后需要等待传播生效，且 Resend 会自动重试失败的邮件发送，无需过度焦虑。最终通过此配置解决了邮件提醒问题。

本文介绍了作者在使用 Cloudflare 服务时遭遇的邮箱显示异常问题及其解决过程。凌晨作者发现网站前台邮箱全部变为 [email protected]，经 AI 提示得知这是 Cloudflare 内置的电子邮箱地址混淆功能，旨在防止爬虫抓取真实邮箱减少垃圾邮件。文章随后阐述了 Cloudflare 作为域名托管与 CDN 加速服务商的背景，以及该功能的底层实现原理：在数据传输层修改 HTML 源码将邮箱替换为占位符，并注入加密 JavaScript 脚本，在安全环境下动态还原。然而作者的网站采用了 PJAX 技术实现局部刷新，导致该脚本在页面切换时不会执行，邮箱始终显示占位符，国内访客无法看到有效联系方式，造成沟通障碍。作者最终通过 Cloudflare 仪表盘关闭该功能，但凌晨操作时遭遇 API 返回 504 错误，疑似后台维护，直到星期六早上才成功关闭，网站联系方式恢复正常。

本文介绍了 Cloudflare AI 防护功能对网站搜索引擎排名的影响及其解决方案。当用户开启 Cloudflare 的 AI 防护后，系统会自动生成一份 robots.txt 文件，即使网站原本没有该文件，也会禁止绝大部分 AI 和爬虫访问，导致网站在搜索引擎中掉排名甚至无法被搜到。作者通过必应警告发现了这一隐藏问题，并指出除非用户完全不关心网站排名且只希望朋友访问，否则应当关闭该自动功能，自行编写合适的 robots.txt。文章反思了个人网站运维中容易被忽视的细节，强调即便掌握 Linux 等运维技能，仍可能因这类小配置影响网站可见性。

本文介绍了 Cloudflare Workers 与 Pages 两种原生部署模式的区别。文章从域名入手，指出 Workers 使用 workers.dev 而 Pages 使用 pages.dev。接着深入分析 Workers 的两种形态：Serverless 和静态 Workers。Serverless 以函数形式处理请求，存在冷启动问题，仅有算力无存储，需搭配云数据库如 Neon、MongoDB 使用；静态 Workers 则能连接 GitHub 仓库自动构建静态站点，但每次需回源计算，无法充分利用 Cache Rules。文章还对比了 Workers 与 Pages 在部署流程上的差异，并提供了使用 Wrangler 命令行工具推送代码到 Pages 或 Workers 的实战示例，帮助读者根据项目类型选择合适方案。

本文介绍了作者因 GitHub 被封导致 Vercel 无法使用，不得不将博客评论区迁移到自家树莓派的过程。文章详细描述了使用 Waline 导出评论后，在迁移至 Cloudflare Pages 时发现评论大量丢失的乌龙事件。经过与 DeepSeek 彻夜排查，最终发现罪魁祸首是 Vercel 的路径问题：Vercel 将文章时间错误改为 10 号，导致路径为 2026/04/10，而本地正确路径为 2026/04/11，因此本地浏览时评论显示异常。此外，友链页面也因 Vercel 与 Cloudflare Pages 路径规范差异（是否带尾部斜杠）而无法显示评论。最终作者通过修改 Waline 源文件中的路径重新导入，成功恢复评论。文章强调 Waline 数据自主可控的优势，提醒开发者注意平台路径差异带来的兼容性问题。

本文介绍了作者因 GitHub 账号被封而被迫迁移网站的经历。作者在凌晨美化网站并推送更新时发现账号被 Masked，怀疑与使用域名邮箱有关。认为 GitHub 虽重要但访问不便，且存在被封风险，因此决定将网站迁移至 Cloudflare Pages。通过本地编译后拖拽部署，发现 Cloudflare Pages 速度极快，优于 Vercel。作者最终建议开发者备份代码至 Codeberg 或 Gitee 等平台，避免依赖单一服务商。全文体现了对开源平台风险的警觉与主动备份的重要性。