Posts

Caddy 在 10 月 1 日和 10 月 3 日连续发布 v2.11.6 与 v2.11.7，中间只隔了一天多。2.11.6 是一次"安全加固 + 特性"的大补丁，但引入的默认空闲超时直接打断了流式响应，2.11.7 专门来修这些回归。本文记录两版的关键变化、破坏性变更与实测结论。 一、时间线 版本 发布时间（UTC） 性质 v2.11.4 2026-06-03 上一个稳定版 v2.11.6 2026-10-01 15:21 安全加固 + 新特性，引入回归 v2.11.7 2026-10-03 05:58 专修 2.11.6 回归 官方在 2.11.7 的说明里直接写： This patch release fixes regressions from 2.11.6… If you’re on 2.11.6, we recommend upgrading. 也就是说：2.11.6 不值得停留，要么停在 2.11.4，要么直接上 2.11.7。 二、v2.11.6：安全修复是重点 安全修复（11 项） 最需要注意的三条： 修复 说明 forward_auth + reverse_proxy 同路由时，请求可能发到错误的上游连接 GHSA-6365-7ppr-5r92，反代认证场景，最重要 handle_path / uri strip_prefix 现在规范化路径 防止绕过基于路径的鉴权 path_regexp 归一化 Windows 反斜杠 补完 CVE-2026-52844 其余包括：101 Switching Protocols 响应剥离 hop-by-hop 头、Windows 8.3 短名每段路径都拒绝、FastCGI 不再把 Proxy 头当 HTTP_PROXY 传给后端（HTTPoxy）、粘性会话 cookie 哈希改为常量时间比较、Admin API 远程访问路径归一化、超大请求体返回 413、ETag 碰撞修复。 ...

随着移动端 SoC 性能越来越强,现在已经可以直接在 Android 手机上运行 GGUF 格式的大语言模型。本文记录一次实际部署过程:使用 Termux + llama.cpp + Mesa Freedreno/Turnip + Vulkan,让高通 Adreno GPU 参与 LLM 推理。 本文以 Adreno 840 为例,并使用 LFM2.5-2.6B-Q8_0 进行测试。 一、环境 本次测试环境: 项目 配置 系统 Android SoC Qualcomm Snapdragon GPU Adreno 840 推理框架 llama.cpp llama.cpp b10516 GPU Backend Vulkan Mesa 26.0.6 Vulkan 驱动 Freedreno / Turnip 模型 LFM2.5-2.6B-Q8_0 模型大小 约 2.7 GB 手机使用的是统一内存架构,因此 vulkaninfo 显示的 GPU memory 并不是传统 PC 独立显卡意义上的 VRAM。 二、安装 Termux 建议使用官方 Termux 项目提供的版本,不建议使用来源不明的第三方修改版。 ...

一个轻量、原生 Linux、无 GUI 的 Shadowsocks 分流工具的诞生过程。从需求分析到架构选型,从核心实现到踩过的每一个坑。 为什么要做这个 市面上的代理工具很多,但很少有同时满足以下条件的: 纯命令行、无 GUI——跑在服务器/WSL 上,没有桌面环境 全局接管——所有应用流量自动分流,不需要每个程序单独设置代理环境变量 规则分流——国内直连、被墙的走代理,而不是一刀切全代理或全直连 轻量可控——不依赖 Clash/mihomo 那套大而全的框架,只要核心功能 Clash 系太重,simple-tun2socks 没有分流,tun2socks 只做协议转换不做路由决策。于是决定自己造一个。 架构设计 核心思路: TUN 网卡 + 用户态 TCP/IP 栈 + 规则引擎 + Shadowsocks 子进程 Linux / WSL │ 所有应用流量（无需设置任何代理环境变量） ▼ TUN 网卡 (sscli0) │ ▼ sscli 路由引擎（gvisor 用户态 TCP/IP 栈 + 规则匹配） │ ├──── DIRECT ──→ 直接出网（fwmark 防回环） │ └──── PROXY ───→ 本地 SOCKS5 → sslocal → VPS 关键选型 组件 选型 理由 TUN 设备 wireguard/tun (MIT) WireGuard 同款,稳定可靠,MIT 许可 用户态 TCP/IP 栈 gvisor netstack (Apache-2.0) sing-box/mihomo/tun2socks 同款,200 行就能桥接 TUN SOCKS5 客户端 x/net/proxy Go 标准库扩展,支持 UDP ASSOCIATE Shadowsocks 加密 shadowsocks-rust 的 sslocal 不自己实现加密,复用官方预编译二进制,安全可靠 为什么用 gvisor netstack 而不是直接处理 IP 包?因为 gvisor 提供了完整的 TCP/IP 协议栈——你只需要处理"这个连接走代理还是直连",TCP 三次握手、拥塞控制、重传这些脏活累活全由 gvisor 在用户态搞定。 ...

转载自数码之家 @badcrazy，2025-02-20。原文配图为论坛附件，此处用自制 CPU 对比图替代。 背景 因为运营商封堵，去年开始网心云就矿难了。但 OEC 的 CPU 加密，之前需要拆换 CPU 刷机（据说换 U + 刷机 30 元），成本上去了，玩的人少。去年底直刷固件出现，OEC 的性价比就真香了。 性价比 RK3566，千兆网卡，内置 SATA，USB 3.0，散热片巨大 2+8 卖 70 上下，4+8 卖 90 上下，目前价格小涨 对比：老掉牙的玩客云还要 30 多；N1 稳在 70、80（没想到 FX 暴雷了，N1 倒像理财产品，保值到莫名其妙）；RK3568 4+32、只有 USB 2.0 也没 SATA 的黑豹 X2 还要 100+（这波 OEC 出来后面应该会降，不打算接硬盘、U 盘，就想用内置跑跑服务的后续也可以观望一下） 这么一对比，是不是价格真香？ CPU 性能对比（PassMark） OEC 的 RK3566 比 N1 的 S905D 多核强约 42%（1160 vs 815），单核也有 10% 优势（546 vs 493）。考虑到价格相近（OEC 2+8 约 70 元），性价比优势明显。 ...

一、为什么要单独做一台冷备机 对于一些重要数据,单纯依赖主服务器上的 RAID、快照或者定期备份并不够。 我准备搭建一台专门用于冷备的机器: 4 块 4TB 硬盘 实际冷备数据量不会超过 8TB 一个月甚至更久才开机一次 完成备份、检查后直接关机 平时整机断电 主要目标是防止硬盘故障,同时保证数据长期完整性 这台机器并不是传统意义上的 NAS。 它大部分时间都是: 关机 ↓ 开机 ↓ 备份 ↓ 检查 ↓ 关机 ↓ 断电 因此设计目标不是高性能,也不是提供 7×24 小时文件共享,而是尽可能简单、可靠。 二、为什么选择 RAIDZ2 4 块 4TB 硬盘一共有约 16TB 原始容量。 由于实际需要的冷备容量不到 8TB,因此没有必要为了容量去选择 RAID5。 最终选择: 4 × 4TB → ZFS RAIDZ2 RAIDZ2 相当于双校验,可以容忍同时损坏两块硬盘。 大致结构: 4 × 4TB HDD │ ▼ RAIDZ2 │ ▼ ≈ 8TB 可用容量 对于冷备场景来说,容量利用率并不是第一目标。 相比 RAID5,RAIDZ2 可以在一块硬盘已经损坏、正在更换和恢复的情况下,再承受一块硬盘故障,因此更适合这种低频使用、长期存放数据的场景。 三、为什么选择 ZFS,而不是 mdadm RAID6 RAIDZ2 和传统 RAID6 在容错能力和可用容量上非常接近。 ...

最近折腾了一段时间 Hermes Agent。 最开始我的想法非常简单: «Hermes 不就是一个 AI Agent 吗?Docker 隔离一下环境,岂不是既干净又方便升级?» 于是我选择了 Docker 部署。 结果一路从"这东西跑起来真简单",折腾到了"我已经把 Docker 部署所有坑都踩完了"。 最后得出的结论反而是: Hermes 可以很好地运行在 Docker 里,但如果你的目标是让它长期作为一台机器上的自动化 Agent 使用,原生部署反而更加合理。 这篇文章记录一下整个过程。 一、为什么一开始选择 Docker 我平时本身就大量使用 Docker。 数据库、Home Assistant、各种 Web 服务基本都是容器化部署,因此看到 Hermes 官方提供 Docker 镜像之后,第一反应就是: services: hermes: image: nousresearch/hermes-agent:latest container_name: hermes restart: unless-stopped command: gateway run ports: - "9119:9119" # Dashboard(默认 127.0.0.1,按需暴露) volumes: - ./data:/opt/data environment: HERMES_DASHBOARD: "1" 然后: ...

修改 Hermes Dashboard 的登录密码,不需要重启整个容器——改配置 + kill 进程即可,QQ 会话不断线。 背景 Hermes Agent 的 Dashboard(Web 管理界面)默认带 basic auth 登录。Dashboard 页面本身没有"改密码"功能,需要改配置文件。但很多人以为要重启容器才能生效——其实有更轻的方式。 方法 1. 改配置文件 编辑 Hermes 配置(config.yaml),找到 dashboard 的 basic_auth 配置: dashboard: basic_auth: username: admin password_hash: "<scrypt 哈希>" # 或明文 password: "xxx" 两种密码写法: password_hash:scrypt 哈希(推荐,不存明文) password:明文密码(简单但安全性低) 生成 password_hash(交互式输入,避免密码出现在命令行历史里): # 容器部署的,先进入容器内再执行: docker exec -it <容器名> bash # 然后在容器内: python3 -c " from plugins.dashboard_auth.basic import hash_password import getpass pw = getpass.getpass('输入新密码: ') print(hash_password(pw)) " 用 getpass 交互输入——密码不会显示在终端、不会进 shell history。 (如果容器里找不到 plugins 模块,说明需要在 Hermes 的虚拟环境里执行:/opt/hermes/.venv/bin/python3) ...

本博客即本文的产物。记录完整搭建过程和踩过的坑,供以后重建参考。 技术选型 Hugo v0.164.0(extended)— Go 单二进制,极快 PaperMod 主题 — 极简技术风,内置搜索/归档/标签 目标:按日期更新的技术日志流 搭建步骤 1. 安装 Hugo(容器内,免 root) # 下载官方 release 的 tar.gz 到用户目录(路径按实际环境替换) curl -L "https://github.com/gohugoio/hugo/releases/download/v0.164.0/hugo_extended_0.164.0_linux-amd64.tar.gz" -o /tmp/hugo.tar.gz mkdir -p ~/bin && tar -xzf /tmp/hugo.tar.gz -C ~/bin hugo # 验证 ~/bin/hugo version 2. 建站点 + 装主题 cd ~ && ~/bin/hugo new site techlog git clone --depth 1 https://github.com/adityatelange/hugo-PaperMod ~/techlog/themes/PaperMod 3. 配置 config.toml(中文) 关键配置点: theme = "PaperMod" 菜单:归档 / 搜索 / 标签 输出:HTML + RSS + JSON(搜索需要) 4. 创建归档/搜索页面 <!-- content/archives.md --> --- title: "归档" layout: "archives" url: "/archives/" --- <!-- content/search.md --> --- title: "搜索" layout: "search" url: "/search/" --- 5. 构建 hugo --minify # 输出到 public/ 踩坑记录 坑 1:hugo.toml vs config.toml 并存 Hugo 0.164 的 hugo new site 默认生成 hugo.toml,如果又写了 config.toml,两个文件并存时 hugo 优先读 hugo.toml(还是默认内容),你的配置全部不生效。 ...

仪表盘显示 7 天消耗 4 亿 token,看似吓人——但拆开看,真实成本一个月才几十块。 现象 hermes insights 显示: 输入 477 万 + 输出 92 万 Total 4 亿(对不上?) 真相:Total = 输入 + 输出 + 缓存读 + 缓存写 + 推理 4 亿的真实构成: 项目 数量 占比 缓存读取(cache read) 3.99 亿 98.6% 输入 447 万 1.1% 输出 76 万 0.2% 推理 33 万 0.08% “4 亿"几乎全是缓存读取——不是真的消耗了 4 亿新 token。 为什么有这么多缓存读 长会话场景(如 QQ 单窗口聊天):每轮对话都要把整个会话历史重新发给模型。但历史大部分没变,被**上下文缓存(cache)**命中——服务端只收极低的缓存价,不重新计费。 单轮实测:发一条消息,输入 2,421 token,但缓存读 23 万(整个历史)。 成本换算 按 DeepSeek V4-Flash 价格(涨价前): ...

一次 82 页 PDF 提取烧掉 84 credits(月度免费额度的 8.4%),血的教训。 计费规则(官方确认) 操作 消耗 搜索 2 credits / 10 条结果(向上取整) HTML 提取 1 credit / 页 PDF 提取 按页计费(82 页 ≈ 84 credits) 搜索+自动抓正文 搜索 2 + 每结果 1 credit 免费额度:1000 credits/月。 教训 PDF 绝对不要直接扔给 Firecrawl 提取——按页计费,一个几十页的 PDF 就能烧掉月度额度的百分之几到十几。 正确做法 PDF → curl 下载到本地 → 本地解析(pymupdf/read_file) → 免费 HTML → Firecrawl(1 credit/页) 或 curl 搜索 → DeepSeek 服务端(不耗 Firecrawl 额度) 实测对比: 82 页 PDF 扔 Firecrawl:84 credits 同 PDF curl + 本地解析:0 credits 为什么 Firecrawl 搜索也烧额度 Firecrawl 的搜索默认会抓每个结果的正文(“search + extraction in one call”)——一次搜索 10 条结果 = 2(搜索)+ 10(抓取)= 12 credits。所以搜索密集场景要小心,最好用纯搜索服务(如 DeepSeek web_search)。 ...