使用 Nginx 搭建个人图床,让链接永远有效!
这周发生了很多有意思的事情。
Clawdbot 改名成 Moltbot,然后某个 B站 UP 发了条动态:
做个 Opencode Desktop 的视频,第二天 Clawdbot 就爆火,Clawdbot 视频要发了,Clawdbot 又把名字改成了 Moltbot。这个时代不要为难老人家好不好~
前天一看 Moltbot 又把名字改成了 OpenClaw,想蹭个热点真不容易啊 2333。
CloudCone 机房罕见的出故障了,因为虚拟机 WEB 控制面板 Virtualizor 上存在一个严重漏洞,本来还准备在周末在 CC 服务器上整个 mjl-/mox,结果什么也干不了。
周末要结束了还没修复:
于是在用 Memos 记录这些事情的时候,发现 Memos 不能直接在 post 里上传图片,只能用图床。
既然现在没法部署 mjl-/mox,那就整(shui)个(pian)图(bo)床(ke)好了。
这次主要用的是 Claude + GLM-4.7,体验下 Claude 和 OpenCode 的区别。
为什么要自建
没怎么用图床,相关的工具倒是收藏了不少。
其中杀手级的 App 当属 Molunerfinn/PicGo,功能非常全面,支持各种存储服务,还能和常见的文本编辑器交互:
虽然有很多免费的存储服务可以用,但这些都逃不开一个最大的问题:很难保证链接长期有效。
比如把文件上传到 OneDrive,得到一个链接,但如果哪天想要把图床迁移到另一个服务,那就不得不修改原来使用的链接,而用到这个链接的地方可能很多,emmm…
更不用说有些免费图床用着用着就跑路的。
而如果是用自己的域名访问的话,就能解决这个痛点。只在域名还在,做好备份恢复,就完全可以保证链接一直有效。
搭建思路
图床这种算是静态网站服务,有很多平台可以提供免费部署,比如 Vercel,Github 等,也能自定义域名。但这里用的是服务器 + Nginx,毕竟现在的服务器很便宜了,这样也更方便备份迁移。
如果追求极致精简,直接把图片放在 Nginx 的静态文件目录就好。但这样服务器端是简单,客户端操作就有点复杂了,得用 rsync, scp 之类的工具把文件传上去,不方便也不安全。
所以设计原则是:客户端操作尽可能简单,无论在哪都能轻松上传图片。
于是我选择使用 curl,通过http请求的方式上传图片,这命令是个电脑都应该会有吧,而且命令也不会很长,很容易就能记住。
开始干活
当然不是我干活,而是指挥 AI 干活。
要实现的功能也不多,需求一描述,用 Claude 和 GLM-4.7 生成的代码直接就能跑起来。
然后不出意外的出意外了,在首次生成的代码上继续改进时,上传图片的权限突然从一开始的 600 变成了 666:
这可不是什么好事。
让 Claude 定位原因把图片权限改回去,但 Claude 并不知道是什么导致的权限改变,虽然加上了改变文件权限的代码,但最后图片权限依旧是 666。
眼看 Claude 解决不了,只好亲自出手了。
扫了一眼本就不多的 lua 脚本,唯一对图片有修改是调用 ImagicMagick 压缩图片这段
1 | -- Optimize images (requires ImageMagick) |
于是把这段 lua 注掉一试,果然,就是用 /usr/bin/mogrify 压缩图片后图片文件的权限从 600 变成了 666 。
而虽然 Claude 加上了改变文件权限的代码
1 | os.execute("/bin/chmod 600 " .. target .. " 2>/dev/null") |
但因这段代码放在 ImagicMagick 压缩图片之前,所以没能发挥任何效果。
收尾
最后照例生成了 Git 项目,把代码传到了 Github 上:qspidy/imgng。
不得不夸一下 OpenCode 生成的 README 了。相比 Claude,OpenCode 生成的又有图标又有 Badge,看起来很现代。
最后让 Claude 参考之前的项目才生成的现在这么现代的 README:
结语
不得不感慨 AI 写代码之神速啊,虽然就目前看来还有一定的局限,有些问题还是得有人的配合才能解决。
但是,如果这次 AI 可以在本地调试,它应该能很快定位问题吧。
如果调试也被 AI 完全掌握,那或许真的就是程序员的末日了。
感觉也快了啊。





