自托管

之前做过几次公共图床的小活动，都是借用别人的图床。用得多了以后，就一直想做一个真正属于自己的图床。 之前因为发小项目没发到内板，被禁言了三天。也正好趁这几天继续把这个项目完善了一下。 我不是程序员，更多是站在普通用户的角度去打磨这个项目：上传要顺手，外链要好复制，公共上传要能控，相册和图片管理也要够直观。 项目简介 OU-Image Hosting，中文名 欧记图床，是一个面向个人创作者、开发者、小团队和自托管玩家的图床项目。 项目地址：https://github.com/cshaizhihao/ou-image-hosting 它不是网盘，也不是一次性临时上传脚本，而是一个偏长期使用的： 自托管图床 图片库 相册管理面板 公共上传入口 S3 / Cloudflare R2 图片托管工具 一句话概括： 图片放在自己手里，上传、整理、分享都尽量舒服一点。 为什么要做这个项目 很多朋友玩 VPS、独服、小鸡久了以后，都会遇到类似的问题： 截图、教程图、博客图到底放哪里？ 发论坛、写文章、写文档时，图片外链怎么稳定？ 免费图床会不会删图、限流、压缩？ 对象存储很好，但配置起来是不是太麻烦？ 想自己搭一个图床，但不想同时折腾一堆脚本和配置？ 所以有了 OU-Image Hosting / 欧记图床。 它的定位很明确：给 MJJ、博客作者、开发者和小团队用的轻量自托管图床面板。 核心功能 OU-Image Hosting 目前主要支持这些能力： 功能 说明 图片上传 支持拖拽、粘贴、URL 上传和公共上传 外链复制 支持 URL、Markdown、HTML、BBCode 图片管理 支持搜索、筛选、收藏、回收站和批量操作 相册管理 支持创建相册、设置封面、填写描述 权限边界 支持管理员、子管理员、普通用户和访客 存储后端 支持本地存储、Amazon S3、Cloudflare R2、S3-compatible 部署方式 支持 Docker Compose 一键部署 运维能力 支持更新、备份、恢复、回滚、诊断和日志查看 简单说，它就是一个自己可控的图床面板。 新手常见问题 为什么要自建图床？ 主要是为了可控。 ...

博客是最常见的自托管服务之一，但只要放到公网，就不能只考虑“能不能打开”。 下面是一份最小安全清单。 1. 源站只监听本机 如果使用 Cloudflare Tunnel，应用尽量只监听： ```text 127.0.0.1 ``` 不要无意中监听 `0.0.0.0`，否则服务可能绕过 Tunnel 直接暴露在公网。 2. 数据库不要用管理员账号 应用不要长期使用数据库管理员账号。 更好的做法是： 单独创建应用用户； 只授予必要权限； 不把管理员密码写进应用配置。 这样即使应用层出问题，数据库风险也更可控。 3. 后台路径要清楚 前台和后台最好分开规划： ```text / 博客前台 /admin/ 管理后台 ``` 不要让前台代理吞掉后台 API，也不要让后台静态资源被转成 HTML。 4. 定期备份 至少备份两类东西： 数据库； 上传文件。 主题和程序可以重装，文章内容丢了就很麻烦。 5. 保留回滚方案 每次大改之前，先备份配置文件。 自托管系统能长期稳定，不是因为永远不出问题，而是因为出问题后能快速回滚。

很多自托管服务的问题不在“能不能访问”，而在“暴露以后能不能长期维护”。 Cloudflare Tunnel 的好处是：源站不需要开放公网端口。服务器只要能主动连出 Cloudflare，外部访问就可以通过域名进入服务。 为什么适合家庭服务器和小型 VPS 传统发布方式通常需要： 开放 80/443 端口 配置反向代理 申请和续期证书 维护防火墙规则 面对公网扫描和爆破 使用 Tunnel 后，源站服务可以只监听本机： ```text 127.0.0.1:8088 ``` 这样即使服务器公网 IP 被扫到，Web 服务本身也不会直接暴露。 推荐路径规划 如果一个域名下同时跑前台和后台，路径设计要清楚： 路径 用途 `/` 博客前台 `/posts/*` 文章页 `/admin/*` 管理后台 `/auth/`、`/server/`、`/items/*` 后台 API 前台不要贪心接管所有路径，否则后台 SPA 的资源和 API 很容易被吞掉。 常见坑 1. 后台静态资源 MIME 错误 如果 JS 文件请求到了 HTML，浏览器会报类似错误： ```text Expected a JavaScript module script but the server responded with a MIME type of text/html ``` 这通常是路径被错误转发到了前台首页。 ...