自托管 on 魔都水滴

买了海外 VPS 又有顶级域名，然后呢？这 12 件事，才是公网 IP 真正的含金量

Sat, 11 Jul 2026 13:30:00 +0800

先说结论

单独一台海外 VPS，只是一间通了电、接了网、却没有门牌号的小房间；单独一个顶级域名，只是一块漂亮招牌。把域名托管到 Cloudflare，再将 DNS 指向 VPS，才等于同时拥有“门牌、导航、店面和公网入口”。

它真正的价值并不是“可以搭一个博客”这么简单，而是让普通人第一次拥有一块全天在线、能被全世界标准互联网访问、能运行自己代码的数字土地：博客、API、Webhook、状态页、密码库、监控、文件入口、自动化任务、远程访问中转，甚至个人 AI 服务的统一入口，都可以从这里长出来。

但公网 IP 也像一扇开在闹市区的门：你刚装好门锁，互联网上的扫描器可能已经来拧过门把手。因此本文既讲“能做什么”，也讲“哪些东西千万别直接暴露”。

受够远程控制被限速？我把 RustDesk 服务端搬回自己家：多合一部署、避坑与安全加固

Fri, 10 Jul 2026 22:00:00 +0800

先说结论

RustDesk 是一款强调开源与自托管的远程桌面工具。客户端之间能直接连接时，画面和键鼠数据优先点对点传输；直连失败时，才由中继服务转发。把服务端部署在自己控制的机器上，最大的价值不是“完全不要服务器”，而是把设备登记、中继路径、密钥、账号和日志重新放回自己的控制范围。

本文使用社区维护的 lejianwen/rustdesk-server-s6 多合一镜像，把 RustDesk OSS 的 hbbs、hbbr 与社区 API、Web 管理功能放进一个容器。它适合家庭、实验室和小团队简化部署，但不是 RustDesk 官方发行的多合一服务端。生产环境仍需自行评估社区镜像、固定版本或镜像摘要、备份数据，并测试升级和回滚。

本文所有域名都使用 example.com，没有展示真实 IP、私有域名、主机名、设备 ID、账号、密钥、Token、Cookie 或镜像仓库地址。公开截图来自项目官方页面或社区仓库公开素材。

我把 Docker 命令行装进了“驾驶舱”：Portainer 2.39.4 从部署到避坑，一篇就够

Fri, 10 Jul 2026 15:30:00 +0800

先说结论

Portainer 不是 Docker 的替代品，它更像 Docker 主机的“驾驶舱”：底层发动机仍然是 Docker Engine，Portainer 只是把容器、镜像、网络、卷和 Compose Stack 整理成网页按钮、表格与状态卡片。

我用 portainer/portainer-ce:2.39.4 做了一次隔离部署，完成初始化、接入本机 Docker、查看仪表盘、筛选容器、创建演示 Stack，并记录了真实截图。部署本身只要一条 docker run，真正需要认真理解的却是三件事：/data 必须持久化、/var/run/docker.sock 权限非常高、生产环境不要把管理页面毫无遮挡地暴露到公网。

本文没有展示完整 IP 地址、真实主机名、内网域名、管理员密码、Token、Cookie、私有镜像地址或生产容器名称。截图里的实验资源使用专门的演示名称，容器地址已遮盖。

我最后留下的自用 Web 剪贴板，居然只有一个文本框

Fri, 10 Jul 2026 15:30:00 +0800

先说结论

我试过不少“跨设备剪贴板”“在线便签”“临时文本同步”工具，最后反而留下了一个看起来最寒酸的东西：minimalist-web-notepad。它打开之后几乎什么都没有，只有一个文本编辑框，只支持纯文本，不支持登录用户、不支持富文本、不支持图片、不支持标签分类，甚至连“保存按钮”都不明显。

但正是这种“功能少到没什么可炫耀”的设计，让它特别适合做自用轻量级 Web 剪贴板：临时从手机传一段命令到电脑、从电脑丢一段说明到平板、给自己留一段短文本、用 curl 在脚本里读写一小段状态。它不像知识库，也不像团队协作文档，更像桌面旁边那张随手撕下来的便签纸。

本文会用 ahfeil/minimalist-web-notepad:latest 镜像演示 Docker Compose 部署；同时给出 Windows 11、Ubuntu 26.04、macOS 26 三套一键脚本，以及人工自动执行和 Agent 自动配置两种方法。全文不展示任何完整内网地址、内网域名、完整计算机名称或真实隐私数据。

别再让 Agent 吞掉你的 Token：我把 Headroom 接到 NewAPI、OpenClaw 和 HermesAgent 的完整实战

Sat, 20 Jun 2026 12:30:00 +0800

先说结论

这次我没有替换原来的 NewAPI，也没有让 OpenClaw / HermesAgent 直接改用一个不确定的新网关。真正做法是：在 NewAPI 前面加一层 Headroom 代理，把所有已经使用 OpenAI-compatible 协议的调用改到 http://<headroom-host>:8787/v1，而原来的 NewAPI 入口继续保留。这样 Agent 发来的长上下文先经过 Headroom 压缩，再转发给 NewAPI，最后仍由 NewAPI 统一路由到后端模型。

最关键的原则只有一句：先测试，后修改；只迁移测试通过的 OpenAI-compatible 项；非 OpenAI 协议的 fallback 不碰。 这篇文章既是复盘，也是一份可以直接交给 Agent 或人工照着执行的操作指南。

一句话让 Claude 把 Ubuntu 22.04 升级到 24.04:一次几乎不用盯屏幕的跨 LTS 实战

Fri, 19 Jun 2026 10:58:00 +0800

先说结论

这台远端机器是家里那台 24 小时开机的代理机,系统一直停在 Ubuntu 22.04.4 LTS(jammy),内核 5.15。一句"帮我把 192.168.103.182 升级到 ubuntu24.04",Claude 就替我拆开了旧柜子,在另一个房间装上了新柜子,过程中它自己开了 tmux 守夜、自己起了 fallback sshd 备胎、自己用 do-release-upgrade -f DistUpgradeViewNonInteractive 跑完了整段流水线。25 分钟后主机回来,内核已经是 6.8.0-124,所有服务依旧在听。

本文不是讲 do-release-upgrade 怎么用,那是 Ubuntu 官方文档的事;本文是讲"当 Agent 拿到 SSH 之后,它在做什么、为什么这么做、以及哪些坑你必须提前排"。

我把 AnythingLLM 装进 Docker 之后，容器像一只上紧发条的小松鼠——反复重启直到我把那个 1000:1000 给它

Wed, 17 Jun 2026 20:30:00 +0800

TL;DR（先说结论）

AnythingLLM 这只"啥都能塞进去的 LLM 口袋书"官方就有 Docker 镜像，正常情况下 docker run 一行就能起；但它里面那位 anythingllm 用户很挑剔——挂给它的宿主机目录必须属于 1000:1000，否则它写不动自己的 SQLite 数据库，Prisma 启动迁移会直接挂掉，容器就会进入"重启—挂掉—再重启"的死循环。修起来不到一分钟：chown -R 1000:1000 /你的数据目录，再 docker compose up -d 一次，它就乖乖听 3001 了。

本文顺道把"Prisma 那个 file:../storage/anythingllm.db 相对路径为什么能坑死人"讲清楚，最后附上 Portainer stack 写法、几条常见坑、以及中英两个 demo 地址。

新电脑 Bitwarden 登不上，旧电脑却正常：一次 Vaultwarden 版本兼容坑的完整复盘

Mon, 18 May 2026 10:05:00 +0800

先说结论

这次问题表面上看是“新安装的 Chrome + Bitwarden 扩展登录失败”，但根因并不在 Chrome，也不是账号密码输错，而是 Bitwarden 2026.4.1 客户端登录流程调用了新的 prelogin 接口，而自建 Vaultwarden 服务端还停留在 1.35.4-alpine，缺少 /identity/accounts/prelogin/password 接口。

旧电脑之所以还能用，是因为它大概率已有登录态和本地缓存，并没有重新触发完整的首次登录流程。真正的修复不是反复重装浏览器，而是先备份，再把 Vaultwarden 升级到 1.36.0 或更新版本，然后用日志确认新接口不再 404。

本文所有域名、路径、账号、部署目录均已脱敏，示例中统一使用 vault.example.com、/opt/vaultwarden 等占位值，不包含任何内网地址或私人信息。

OpenClaw / HermesAgent 的最佳归宿：Proxmox VE

Wed, 29 Apr 2026 10:00:00 +0800

OpenClaw / HermesAgent 的最佳归宿：Proxmox VE

如果只把 OpenClaw 或 HermesAgent 看成一个“能聊天的机器人”，那它装在哪里似乎都无所谓：实体机可以，VPS 可以，Docker 也可以，甚至日常用的笔记本也能跑起来。

但只要它开始接入消息渠道、执行命令、读写文件、调用浏览器、保存长期记忆、定时跑任务，这个问题就不再是“能不能安装”，而是“它应该被放进什么样的运行边界里”。

我的结论很明确：OpenClaw / HermesAgent 这类长期运行的个人智能体，最稳妥的归宿不是直接装在实体机上，而是安装在 Proxmox VE 里的专用虚拟机中。