拾光小站

欢迎来到我的博客！

Sat, 24 Jan 2026 00:00:00 GMT

---你好陌生人，这里是Tyreamon的博客---

---献上一首nbuna的歌给你--- ::music{meting="https://meting.mtcacg.top/api/meting?server=netease&type=song&id=2666842841"}

::v[d/e-m]

你怎么知道我双红的？

::v[d/2-red]

如何联系？

❤️‍🔥致谢板❤️‍🔥

致谢以下博客框架的作者和文章中引用项目的各位前辈，为我的博客搭建提供了极大的帮助。站在巨人肩膀上，借着光能走的更远。

<div class="thanks-wall"> <div class="thanks-card"> <img class="thanks-avatar" src="https://github.com/saicaca.png" /> <div> <b>Fuwari</b><br/> 作者：saicaca<br/> <a href="https://github.com/saicaca/fuwari">GitHub</a><br/> <span class="thanks-tag">主题框架</span> </div> </div>

<div class="thanks-card"> <img class="thanks-avatar" src="https://github.com/afoim.png" /> <div> <b>Fuwari</b><br/> 作者：afoim<br/> <a href="https://github.com/afoim/fuwari">GitHub</a><br/> <span class="thanks-tag">主题框架</span> </div> </div>

<div class="thanks-card"> <img class="thanks-avatar" src="https://github.com/withastro.png" /> <div> <b>Astro</b><br/> 作者：withastro<br/> <a href="https://github.com/withastro/astro">GitHub</a><br/> <span class="thanks-tag">构建框架</span> </div> </div>

<div class="thanks-card"> <img class="thanks-avatar" src="https://github.com/Spr-Aachen.png" /> <div> <b>Tailwind CSS</b><br/> 作者：Spr-Aachen<br/> <a href="https://github.com/Spr-Aachen/Twilight">GitHub</a><br/> <span class="thanks-tag">构建框架</span> </div> </div>

<div class="thanks-card"> <img class="thanks-avatar" src="https://github.com/gmrchk.png" /> <div> <b>Swup</b><br/> 作者：gmrchk<br/> <a href="https://github.com/gmrchk/swup">GitHub</a><br/> <span class="thanks-tag">页面过渡</span> </div> </div>

<div class="thanks-card"> <img class="thanks-avatar" src="https://github.com/giscus.png" /> <div> <b>Giscus</b><br/> 作者：giscus<br/> <a href="https://github.com/giscus/giscus">GitHub</a><br/> <span class="thanks-tag">评论系统</span> </div> </div>

<div class="thanks-card"> <img class="thanks-avatar" src="https://github.com/umami-software.png" /> <div> <b>Umami</b><br/> 作者：umami-software<br/> <a href="https://github.com/umami-software/umami">GitHub</a><br/> <span class="thanks-tag">访问统计</span> </div> </div> </div>

博客简介

由来

其实说来早些时候就有建站这个念头，留意过WordPress、VuePress框架和不少个人博客站。但是都不太合心意，所以一直搁置。真正的契机：是某天刷到让我> 一眼就甚是满意的博客主题—— Fuwari，果然还得是Astro上限还是太高了（个人观点）。于是拉取修改部署，本站就诞生了。（顺带一提本站挂载在CloudFlare上，自带全球CDN,Dos防护直接夯爆啦。只能说cflare善，还是太善了。），还有Yukina & Mizuki以及二者衍生Twilight都非常优秀，所以相当元素本站都有借鉴学习。总之Fuwari都是非常推荐上手试一试。

联系方式

你可以通过以下的方式联系到我。

So Telegram：Join Group [tyr的树洞].

TG二维码 <details> <summary>点击查看</summary>

</details>

点击链接加入群聊【暂无打算】： QQ群

QQ二维码 <details> <summary>点击查看</summary>

![这里什么都没有]

</details>

——ZHIDINGLANWANJIE——

同样的，欢迎你加入

手机连不上 Codex，最后竟然是 v2rayN 的 TUN 网卡坏了

Thu, 04 Jun 2026 18:15:00 GMT

记录时间：2026 年 6 月 4 日
环境：Windows 11、Codex App、v2rayN 7.22.5、Xray

引言

最近 Codex App 支持用手机远程连接电脑。

官方详情：Codex Remote Control

结果就是很经典的场景：电脑上的 Codex 明明在线，账号也登录了，手机却怎么都连不上。你是不是也会先怀疑二维码、账号权限，或者 config.toml 少了什么开关？

我一开始也是这么想的。

最后一路排查下来，真正的问题和 Codex 配置没有太大关系，而是 v2rayN 的 Xray TUN 网卡虽然显示启动，实际上根本没有正常工作。

这篇文章就把完整过程记录下来。遇到同类问题时，你可以按顺序排查，不用像我一样绕一圈。

先说结论

我的问题链路是这样的：

手机无法连接 Codex
→ Codex Remote Control 的 WebSocket 连接超时
→ 普通系统代理没有接住这条直连
→ 需要使用 v2rayN TUN 模式
→ 旧版 Xray 26.3.27 的 TUN 初始化失败
→ xray_tun 只拿到 169.254.x.x 地址
→ 更新 Xray 26.6.1
→ xray_tun 恢复为 172.18.0.1/30
→ Codex 成功连接

所以，如果你只想快速解决，可以直接检查两件事：

Get-NetIPAddress -InterfaceAlias xray_tun -AddressFamily IPv4

<你的 v2rayN 目录>\bin\Xray\xray.exe version

如果 TUN 地址是 169.254.x.x，或者 Xray 版本比较旧，那么问题大概率就在这里。

原理：为什么系统代理还不够

v2rayN 的“系统代理”和“TUN 模式”解决的不是同一类流量。

系统代理只对主动读取 Windows 代理设置的程序有效。TUN 模式则是在网络层接管流量，即使程序自己没有读取代理设置，也可以被送进代理内核。

Codex 的 Remote Control 需要维持一条 WebSocket 连接。浏览器能访问 ChatGPT，只能证明系统代理可用，不能证明这条 WebSocket 一定会经过代理。

所以这类问题的关键，不是“代理软件有没有打开”，而是“Codex 的实际连接路径有没有被接管”。

排查过程

1. 从 config.toml 开始，方向其实错了

网上有一种说法，是在 ~/.codex/config.toml 的 [features] 中加入：

[features]
goals = true
remote_connections = true
remote_control = true

不过我实际修改后发现，每次启动 Codex，remote_control 都会被自动删除。

继续检查才知道，在我当时使用的 Codex CLI 版本中，remote_control 已经被标记为 removed。官方的 Remote Connections 使用流程也没有要求手动添加这个配置。

所以这不是解决方案。

如果你能在 Codex App 中看到手机连接入口，就不要继续和这个配置较劲了。它被删掉并不代表远程连接功能坏了。

2. Codex 已经注册成功，但连接就是超时

接下来我查看了 Codex 日志。

日志中已经存在远程控制注册信息，说明账号、设备注册和远程控制资格都没有问题。真正失败的是远程控制 WebSocket：

wss://chatgpt.com/backend-api/wham/remote/control/server
os error 10060

Windows 的 10060 很直白，就是连接超时。

这时问题已经从“Codex 功能有没有打开”，变成了“这条网络连接到底有没有出去”。

3. 系统代理能用，不代表 Codex 的连接会走代理

我的 v2rayN 系统代理是：

127.0.0.1:10808

通过代理访问 chatgpt.com 没有问题，但直接连接 chatgpt.com:443 会超时。

可以这样测试：

Test-NetConnection chatgpt.com -Port 443

curl.exe --proxy http://127.0.0.1:10808 -I https://chatgpt.com

一个直连超时，一个走代理立即返回，差别就出来了。

从 Codex 当前的开源实现中，可以看到 Remote Control 使用 tokio_tungstenite::connect_async 建立 WebSocket。结合上面的网络测试，我判断普通“系统代理”没有接住这条连接。

那么怎么办？

需要开启 TUN 模式，让没有主动读取代理设置的程序流量也被接管。

4. 开了 TUN，还是不行

我手动打开 v2rayN 的 TUN 模式后，界面看起来没有报错，系统里也出现了 xray_tun 网卡。

不过 Codex 还是连不上。

继续检查网卡地址：

Get-NetIPAddress -InterfaceAlias xray_tun -AddressFamily IPv4

结果是：

169.254.x.x

这个地址很关键。

169.254.0.0/16 是 Windows 在网卡无法获得正常地址时使用的链路本地自动地址。简单来说，xray_tun 虽然创建出来了，但 TUN 初始化失败，没有拿到应该使用的地址，也没有正常生成路由。

所以界面上的“已开启”，并不等于真的能用。

5. v2rayN 是新的，Xray 内核却还是旧的

我的 v2rayN 已经是 7.22.5，但检查实际运行的 Xray 后发现：

<v2rayN 目录>\bin\Xray\xray.exe version

输出还是：

Xray 26.3.27

这就对上了。

v2rayN 7.21.3 的发布说明已经写明，Windows Xray TUN 需要 Xray-core 至少达到 v26.4.17。v2rayN 的 Issue 中也有人遇到了完全相同的现象：TUN 网卡只有 169.254.x.x，更新 Xray 后恢复。

我最后将 Xray 更新到 26.6.1。

注意：26.6.1 在我处理问题时是 pre-release。以后阅读本文时，请优先使用 v2rayN 当前要求的兼容版本，不要永远固定在这个版本。

实操：正式解决

1. 下载新版 Xray

我使用的是：

Xray 26.6.1 发布页

Windows 64 位下载文件：

Xray-windows-64.zip

当时官方提供的 SHA-256 为：

0A1EE8C8A45E11E865C725DB195429C79B52EE960407065089C5BE586F343248

你可以校验一下：

Get-FileHash .\Xray-windows-64.zip -Algorithm SHA256

2. 完全退出 v2rayN

这里不是关闭主窗口，而是在系统托盘中右键 v2rayN，选择“退出”。

如果 xray.exe 仍在运行，文件会被占用，替换不会成功。

3. 替换 xray.exe

压缩包中需要替换的文件是：

xray.exe

通用目标路径：

<你的 v2rayN 目录>\bin\Xray\xray.exe

我的实际路径是：

D:\v2rayN-windows-64-desktop\v2rayN-windows-64\bin\Xray\xray.exe

替换前建议先备份旧文件，确认新版正常后再删除备份。

4. 以管理员身份启动 v2rayN

TUN 模式需要管理员权限。

如果 v2rayN 标题栏显示“以非管理员身份运行”，即使配置中已经打开 TUN，也可能无法创建正常的网卡和路由。

启动后重新检查：

Get-NetIPAddress -InterfaceAlias xray_tun -AddressFamily IPv4
Get-NetRoute -InterfaceAlias xray_tun -AddressFamily IPv4
Test-NetConnection chatgpt.com -Port 443

修复后，我这里的结果变成了：

xray_tun: 172.18.0.1/30
chatgpt.com:443: 连接成功
出口网卡: xray_tun

随后手机端 Codex 立即显示已连接。

踩坑

remote_control 被删除，不是故障

在我当时的 Codex 版本中，remote_control 已被标记为移除。不要因为它被自动删除，就一直重复修改 config.toml。

先按官方流程确认 Codex App 已更新、账号已登录，并完成多因素认证。

系统代理和 TUN 不是一回事

系统代理只对主动读取代理设置的程序有效。

浏览器能访问 ChatGPT，不代表 Codex Remote Control 的 WebSocket 一定能访问。遇到直连超时，就需要检查 TUN、VPN 或透明代理是否真的接管了流量。

v2rayN 版本不等于 Xray 版本

这是最容易忽略的一点。

v2rayN 是管理界面，Xray 是实际工作的内核。你更新了 v2rayN，不代表 bin\Xray\xray.exe 一定同步更新成功。

排障时不要只看 v2rayN 标题栏，还要执行：

<v2rayN 目录>\bin\Xray\xray.exe version

看到 169.254.x.x 就要警惕

如果 TUN 网卡拿到的是 169.254.x.x，基本可以直接判断它没有正常初始化。

这时继续调路由规则、节点分流或者 Codex 配置，通常都是在错误方向上努力。

最终复盘

这次最绕的地方，是每一层看起来都“差不多正常”：

Codex 有连接入口
手机能扫码
v2rayN 系统代理能访问 ChatGPT
TUN 开关也显示启用
系统里甚至存在 xray_tun 网卡

但真正决定结果的是，那张网卡有没有拿到正常地址，Codex 的 WebSocket 有没有真的从它出去。

所以以后再遇到“某个程序不走代理”的问题，我会先查网络路径，再查应用配置。就这么简单。

参考资料

近期 v2rayN 与 Xray 兼容性问题记录：allowInsecure 与 TUN

Thu, 04 Jun 2026 18:12:00 GMT

记录时间：2026 年 6 月 4 日
后续版本可能已经修复或调整，阅读时请以当前发布说明为准。

起因

最近使用 v2rayN 时，我连续遇到了两类问题。

第一次是 allowInsecure 导致 Core 启动失败，第二次是 Xray TUN 网卡只能取得 169.254.x.x 地址，进而导致 Codex Remote Control 无法连接。

表面上看，这些问题都发生在 v2rayN 中，很容易让人认为是 v2rayN 本身不稳定。

那么，为什么同一个客户端会在短时间内出现两种看似相反的问题？复盘以后可以发现，v2rayN、代理内核和订阅配置实际上是三套独立更新的组件，问题不能简单归因于其中某一个。

v2rayN：负责界面和配置生成
Xray / sing-box：负责真正建立代理连接
订阅配置：负责提供节点和证书参数

只要其中一个没有跟上，最后都可能变成一句很笼统的：

运行 Core 失败，请查看提示信息

问题一：allowInsecure 导致 Core 启动失败

有些旧节点配置中会出现：

{
  "allowInsecure": true
}

它的作用是跳过 TLS 证书验证，虽然可以绕过部分证书问题，但安全风险也很明确。

Xray 在 v26.2.6 中移除了这个配置，并将硬性禁用时间延后到 2026 年 6 月 1 日。时间一到，旧订阅仍然生成 allowInsecure 时，Core 就可能直接启动失败：

The feature "allowInsecure" has been removed

v2rayN 7.22.5 临时恢复了过渡支持，但只持续到 2026 年 8 月 1 日，而且发布说明特别强调需要全新下载并覆盖更新。

因此，这只能作为临时过渡方案。长期仍应由服务商修复证书，或提供正确的证书指纹配置。

问题二：新版 v2rayN，旧版 Xray TUN

另一件事发生在我排查 Codex 手机远程连接时。

我开启了 v2rayN TUN 模式，系统里也出现了 xray_tun 网卡，但它的地址却是：

169.254.x.x

这代表网卡虽然创建了，但没有正常初始化。

检查后发现，我的 v2rayN 已经是 7.22.5，实际运行的 Xray 仍然是：

Xray 26.3.27

而 v2rayN 7.21.3 的发布说明已经注明，Windows Xray TUN 需要 Xray-core 至少为 v26.4.17。

最后我将下面这个文件更新为 Xray 26.6.1：

D:\v2rayN-windows-64-desktop\v2rayN-windows-64\bin\Xray\xray.exe

更新后，TUN 网卡恢复为：

xray_tun: 172.18.0.1/30

Codex 的远程连接也随即成功。

两类问题的共同原因

这两次问题分别来自两个相反方向的兼容性变化：

第一次：Xray 内核太新，旧订阅配置不兼容
第二次：Xray 内核太旧，新版 TUN 配置不兼容

你可能只更新了 v2rayN 界面，没有更新 bin 目录里的内核；也可能更新了内核，却还在使用服务商生成的旧订阅配置。

因此，每个组件单独看都可能没有明显异常，但组合后仍然会出现无法使用的情况。

实操：如何排查

遇到 Core 启动失败或 TUN 异常时，可以先检查以下信息：

<你的 v2rayN 目录>\bin\Xray\xray.exe version

Get-NetIPAddress -InterfaceAlias xray_tun -AddressFamily IPv4

然后再确认：

v2rayN 发布说明是否要求全新下载覆盖更新
订阅是否仍然生成 allowInsecure
TUN 网卡是否出现 169.254.x.x
电脑里是否存在多个 v2rayN 目录，实际运行的并不是刚更新的那个

注意事项

allowInsecure 的临时兼容不是长期方案，Xray 26.6.1 也不是永远的标准答案。后续更新时，还是应该先看 v2rayN 和 Xray 当前的发布说明。

总结

v2rayN 仍然是一个实用的客户端，但近期 Xray 的安全策略和 TUN 功能变化较快，已经不能只根据 v2rayN 界面中的版本号判断整个运行环境是否正常。

排查时，应分别确认以下三项：

v2rayN 版本
Xray 内核版本
订阅配置版本

参考资料

General Compute 免费提供200美元API额度，MiniMax M2.7 速度实测400tokens/s

Sat, 30 May 2026 19:00:00 GMT

`#`一、平台介绍

最近注意到一个 API 平台：General Compute

目前该平台为新注册用户提供 6个月、200美元 的免费 API 调用额度，无需绑定信用卡，注册后即可使用。

`#`二、200 美元额度可用 Token 估算

说明：以下价格按每 1M tokens 计费，实际消耗 = 输入费用 + 输出费用。
这里的估算只用于粗略判断额度能用多久，真实消耗会受上下文长度、回答长度、工具调用、代码读取量等影响。

（1）按单项计算：200 美元全部用于输入或输出

模型	上下文	输入价格 / 1M tokens	输出价格 / 1M tokens	200 美元全用于输入	200 美元全用于输出	1:1 估算总 Token
DeepSeek V3.2	32k	$0.25	$0.38	800M tokens	约 526M tokens	约 635M tokens
DeepSeek V3.1	128k	$0.21	$0.79	约 952M tokens	约 253M tokens	约 400M tokens
MiniMax M2.7	192k	$0.28	$1.20	约 714M tokens	约 166M tokens	约 270M tokens

`#`三、MiniMax M2.7 的推理速度

平台支持多个模型，其中比较值得关注的是 MiniMax M2.7，实测推理速度可以达到约 400 tokens/s。

这个速度在目前的 API 服务中算是相当快的。作为对比，大多数主流模型 API 的输出速度通常在 50-150 tokens/s 左右，M2.7 的吞吐量优势非常明显。

需要说明的是，速度快和模型能力强是两回事。M2.7 在复杂推理、长文理解等方面和 Claude、GPT-4o 这类模型还是有差距的，但在不需要太强推理能力的任务上，这个速度优势就很实用了。

`#`四、适用场景

`200` 美元的额度配合 400 tokens/s 的速度，有几个比较合适的用途：

`（2）批量翻译`

高吞吐速度天然适合翻译任务。无论是文档翻译、字幕翻译还是其他文本处理，M2.7 的响应速度可以大幅缩短批量任务的总耗时。200 美元的额度用于翻译场景，可处理的文本量相当可观。

`（3）作为 OpenClaw 等项目的上游 API 备用`

之前在这篇文章中介绍过 Replit 上的 OpenClaw 项目，这类需要后端 API 转发调用的场景，General Compute 的接口可以作为上游使用。速度快、额度充足、成本为零，适合提前注册储备 API key。

`（4）其他批量处理任务`

批量摘要生成、文本分类、信息提取等任务，对模型推理能力的要求相对较低，但对速度和调用量有较高需求，这类场景下 M2.7 的性价比很高。

`#`五、注意事项

免费额度的有效期为 6个月，过期未使用的额度不会保留
平台支持的模型不止 MiniMax M2.7，具体可用模型列表建议查看官网
免费额度活动的持续时间不确定，有需要的话建议尽早注册

`#`六、小结

General Compute 目前提供的免费额度对于有批量文本处理需求的用户来说是一个不错的选择。MiniMax M2.7 的推理速度在翻译和批量任务场景下表现突出，配合 OpenClaw 等项目使用也很方便。感兴趣的话可以先注册把额度领了，后续根据实际需求再决定怎么用。

如何使用CAPMS完全免费调用GPT、Gemini、Claude模型的API，实现Token自由

Mon, 27 Apr 2026 00:33:32 GMT

::github{repo="router-for-me/CLIProxyAPI"} <details> <summary>点击展开</summary> <p>源站：https://github.com/router-for-me/CLIProxyAPI</p> <p>镜像站：https://gh.kaza.de5.net/router-for-me/CLIProxyAPI</p> </details>

`#` 引言

如何使用CPAMS去中转你的codex、Gpt、Gemini、Claude等代理转成个人api，解放token，实现token自由。

想必大家都听说CAPMS这个项目，这里给到一个capms项目的部署教程。

对了，这里我使用的是本地部署。你也可以使用别的大佬打包好的镜像包去部署。 <p>如：

docker pull routerforme/cliproxyapi:latest
docker pull eceasy/cli-proxy-api:latest

docker run -d \
  --name cli-proxy-api \
  -p 8317:8317 \
  -p 8085:8085 \
  -p 1455:1455 \
  -p 54545:54545 \
  -p 51121:51121 \
  -p 11451:11451 \
  -v cli-proxy-api-data:/data \
  -e DEPLOY=cloud \
  -e PORT=8317 \
  eceasy/cli-proxy-api:latest

API 地址：http://服务器IP:8317/v1

管理页面：http://服务器IP:8317/management.html

`#` 正式开始

(1)、后端二进制程序下载

首先我们去GitHu下载官方release文件 https://github.com/router-for-me/CLIProxyAPI
选取适合版本的二进制程序包下到本地解压,解压后得到以下文件

(2)、修改配置文件yaml

注意其中的config.example.yaml，这是他的配置文件，建议修改其中的个人密钥。


host: ""
# Server port
port: 8317 #如果你8317端口被占用，可以修改为其他端口
  secret-key: "输入你自己的密钥" #用于capms页面（这个页面得自己导入，后面会提到。）得登录，该密钥后续会被进行加密，也没什么。

做好上述准备，先不急运行exe程序。

(3)、安装前端资源文件

由于此仅仅为CLIProxyAPI 的后端二进制我们要去单独下载他的前端控制台资源：一个html文件。这里我推荐的是router-for-me大佬的前端资源。前端资源：https://github.com/router-for-me/Cli-Proxy-API-Management-Center 下载那个management.html放到解压出来的后端二进制文件目录下。和那个exe同级就行。

`#` 运行程序更改配置

4、运行程序

现在我们可以运行程序了，双击或在终端中运行。

./cli-proxy-api.exe

会跳出终端界面，如下：

无视即可。访问管理页面：http://服务器IP:8317

5、更改配置

现在我们可以去配置面板页去更改配置了。

(1)网络配置

(2)设置自己的apikey

(3)记得保存

后面有需求就继续配置内网穿透ngrok、cloudflare-tunnel等。实现外部访问。不过一般我都在本机进行使用，所以没有这个需求。

接入你的codex、Gemini CLI、Antigravity等的OAuth

Antigravity-model codex-model gemini-cli-model

`#` 注意事项

`1. 注意`

[!WARNING] 注意Gemini CLI及Antigravity记得确认你的project 开启了Gemini for Google Cloud的权限。访问：https://console.cloud.google.com/ 确认你的project 开启了Gemini for Google Cloud的权限。

1. 点击你的My Frist Project > 确认有项目 > 记下project_id：如（gen-lang-client-0412195766）
2. 点击 APIS AND SERVICES
3. 选择库 > 搜索Gemini for Google Cloud
4. 点击ENABLE 到此权限问题解决了。

`2. 注意`

[!WARNING] OAuth接入之后，Gemini CLI、Antigravity要特殊处理一下。因为它没有提供project_id的参数。会导致连接调用失败，尽管你过了认证。找到到这个文件，将project_id添加到文件中。 "C:\Users\Tyr.Eamon\.cli-proxy-api\antigravity-账号.json" 原文件。

{"access_token":"****","disabled":false,"email":"你的账号@gmail.com","expired":"2026-04-27T00:33:32+08:00","expires_in":3599,"refresh_token":"*******","timestamp":1777217***,"type":"antigravity"}

修改后的文件。

{"access_token":"****","disabled":false,"email":"你的账号@gmail.com","expired":"2026-04-27T00:33:32+08:00","expires_in":3599,"project_id":"你的project_id","refresh_token":"*******","timestamp":1777217***,"type":"antigravity"}

`3. 注意`

[!WARNING] 还有就是Antigravity可能要你认证。

{
  "error": {
    "code": 403,
    "message": "Verify your account to continue.",
    "status": "PERMISSION_DENIED",
    "details": [
      {
        "reason": "VALIDATION_REQUIRED",
        "domain": "cloudcode-pa.googleapis.com",
        "metadata": {
          "validation_url": "https://accounts.google.com/signin/continue?[REDACTED]" # 点击这个链接进行认证
        }
      }
    ]
  }
}

`#` 后记

——理论上—— 只要你的号够多，号池够深够硬理论上无限token、解放你的token限制。

后续我们可以用CCSwith去统一入口＋融断及故障转移 等管理。

奇技淫巧LINUX·之·完全免费获取Claude-Opus4模型的API

Fri, 24 Apr 2026 12:00:00 GMT

引言

什么？免费获取 Claude-Opus4 模型的 API？

Cherry Studio导入情况

讨论帖子

今天逛 linux.do，看到一篇讨论 Replit / OpenClaw 的帖子。

`标题看起来是在讲“完全免费获取 Claude-Opus4 模型的 API”，但本质上，它更像是把平台本来就有的一层 AI 能力，重新包装成了一个更像标准 API 的入口。`

该说不说真的逆天，这也行？

版主通过用一段写得非常细的提示词，让 Replit Agent 自己完成构建，按规格一步步搭出了一个给 OpenAI / Anthropic 做协议转换的代理 API。

再往下看，版主调用openclaw去实现一步步拧出来的思路。

本篇不聊具体操作，只简单讲一下它的大概实现逻辑。详情请见Linux.do帖子。

原帖链接: https://linux.do/t/topic/2049325

原理

这件事本质上不是“多了一个官方接口”，而是多了一层代理。

平台原本就有自己的模型接入方式、自己的 Agent 和自己的工作流。帖子里的做法，说白了就是先让 Agent 搭出一个项目壳子，再在中间加一层转换逻辑，最后对外暴露成统一接口。

说实话，能想到这条路，而且还能把它讲明白，我是有点佩服的。

如果缩成一行，大概就是这样:

平台现成能力 -> Agent 生成项目 -> 中间层做协议转换 -> 对外表现成通用 API

Web端有详细的描述，这里就不重复了。

1. 先生成一个能跑的服务

让 Agent 直接把后端、路由、依赖和简单页面先搭出来，省掉手工从零开始的过程。

2. 让中间层负责“翻译”

不同模型接口格式不一样，所以中间层要做几件事:

按模型名决定请求转给谁
把请求格式改成目标模型能接收的样子
把返回结果再转回统一格式
流式输出时重新整理事件流

所以它本质上更像一个协议转换器。

我自己看这类东西的时候，最佩服的其实也是这里。因为最后那个“能用的接口”大家都能看见，但中间这层怎么转、怎么接、怎么统一，才是真正有技术味道的地方。

3. 最后统一对外入口

客户端只看到一个 Base URL、一套鉴权方式和一套熟悉的请求格式。至于后面实际接的是谁、怎么转换，客户端并不关心。

看起来像“免费 API”但有点区别

因为最终效果确实很像。

你看到的是统一地址、统一 Key、统一接口格式，所以用起来会很接近平时理解的 API 服务。

但从实现上看，它更像“平台能力再封装后的代理层”，而不是一个独立存在的官方直连接口。

注意事项:

!!!"注意的是构建有时候会出现流式传输的问题，这需要在中间层做特殊处理。"

原帖里没有提到，好像是因为 Replit 的构建机制导致的。但我个人经验是，流式传输在大多数情况下都是可以正常工作的。只是在某些特殊情况下，比如构建过程中，可能会遇到。你可以关闭流式传输，或者在中间层做一些特殊处理，来解决这个问题。

由于是属于replit漏洞，是不是蜉蝣大家都不知道。

当然额度还是你自己的免费额度，只不过调用的方式变了。一般来说额度用完了就抛，再上新号就是。

总结

所以这件事如果用最简单的话说，就是:
把平台原本已经有的 AI 能力，借助 Agent 生成项目，再包一层协议转换，最后整理成一个通用 API 入口。

‘本章仅供讨论和学习、技术思路和个人观察，涉及的平台能力、接口行为和可用性请以官方规则为准，也请勿将相关思路用于滥用或绕过限制。‘

Emby 是什么？一篇给新手看的入门和种草指南

Sun, 15 Mar 2026 20:00:00 GMT

`#`引言

你是不是经常在群里、论坛里，甚至某些 Telegram 频道里看到别人提到 Emby？

一会儿说“我这个服有 4K”，一会儿又说“这个服直连快”，看起来好像很厉害，但你如果之前没接触过，第一反应多半是：这东西到底是什么？

如果你平时用过 Netflix，或者更熟一点的是 B 站、爱奇艺、腾讯视频这些会员制流媒体平台，那你其实已经理解一半了。

因为 Emby 用起来的感觉，确实跟它们有点像。你一样会看到封面墙、分类、搜索、继续观看、跨设备续播这些东西，所以很多人第一次打开 Emby，都会觉得它有点像“私人版的 Netflix”，或者“自己搭的爱优腾”。

不过这里也有个关键区别。

Netflix、B 站、爱奇艺、腾讯视频这些平台，内容和平台本身通常是一体的，你开会员，本质上是在用它们官方提供的内容服务；而 Emby 更像一个媒体库外壳，或者说一个私人流媒体框架，重点不是“平台自己有什么”，而是“这个服后面挂了什么资源、什么线路、谁在维护”。

而且说白了，很多人真正被 Emby 种草，也不是因为这个概念有多高级，而是它看起来确实很值。

你在 Netflix、B 站、爱奇艺、腾讯视频这些平台上，很多时候得分开买会员、分开看片库；但在一些价格比较低，或者保号条件比较宽松的 Emby 服里，你可能只需要隔段时间看一下，甚至有些公益服一个月看一次、留个观看记录就够了，就能进到一个动不动几千电影、几千剧、十几万到几十万集的媒体库里。

更关键的是，这些库很多还不只是“量大”而已，补新往往也不慢，画质从 1080P、2K 到 4K 的版本也不算少。你这么一想，是不是一下子就能理解，为什么群里总有人聊 Emby 了？

其实没那么复杂。

这篇文章我就不跟你扯太多大而空的概念了，我们就用最短的篇幅，快速把 Emby 这东西讲明白：它是什么、能干什么、为什么有人用，以及你第一次接触它时应该怎么看。

`#`原理

众所周知，电影、电视剧、动漫、音乐这些东西，本质上都只是媒体文件。

而 Emby 干的事情，简单来说，就是把这些原本乱糟糟堆在硬盘里的媒体文件，整理成一个能刮削信息、分类展示、跨设备播放、记录观看进度的媒体库系统。

你可以把它理解成一个更像“私人流媒体站”的东西。

也就是说，Emby 本身通常不是资源内容本体，它更像是一个负责整理、展示和播放的“大管家”。真正的重点，其实是它后面挂着什么资源、什么线路、什么机器，以及谁在维护。

`#`为什么很多人会用 Emby？

原因其实很简单：体验确实比“文件夹里找视频”优雅太多了。

比如你以前看剧，可能是电脑上一个文件夹，手机上另一个播放器，看到哪一集全靠自己记；而用了 Emby 之后，封面、简介、分集、播放记录、继续观看这些东西，基本都能自动给你整理好。

这是不是一下子就有点像 Netflix 了？对吧。

另外，Emby 的客户端覆盖也挺广，手机、平板、电脑、电视，基本都能找到对应的使用方式。所以你在家里看一半，出门继续看，体验会顺很多。

不过体验还只是第一层。

很多人真正留下来，用得越来越上头，其实还是因为它的性价比确实高。你想想看，如果一个服本身资源就大，新东西补得也不慢，画质还不错，而你付出的成本只是一个相对便宜的价格，或者只是满足一下比较宽松的保号条件，那这个吸引力其实是很强的。

不过也正因为它很像流媒体，所以很多人第一次接触 Emby 时，会误以为它是一个“资源网站”。

并不是。

更准确一点说，Emby 是平台，是壳子，是播放器和媒体库管理系统；至于你能在里面看到什么内容，那取决于具体是谁在搭、怎么搭、资源从哪里来。

`#`正式开始

那么如果你是第一次接触 Emby，最值得先知道的，其实就三件事。

1. 你看到的 Emby，不一定是“官方服务”

这一点非常重要。

很多人口中的“Emby 服”，其实是别人自己搭的私人或半公开服务。也就是说，你用到的往往不是 Emby 官方直接提供的内容平台，而是某个人或者某个小团队搭好的实例。

所以同样叫 Emby，不同服之间的差距可能非常大：资源差很多，速度差很多，稳定性差很多，管理方式也差很多。

2. 好不好用，很多时候看线路和维护

有些 Emby 服看起来资源很多，但你一播放就转圈；有些资源不一定最全，但线路很稳、码率也合适，日常用起来反而更舒服。

所以 Emby 这东西，看的不只是“有没有片”，还得看“能不能顺畅地看”。

接下来如果你以后真要选服，优先看的通常就是这几项：

你所在地区的直连速度怎么样
晚高峰会不会卡
客户端兼容性好不好
管理员会不会维护、会不会清垃圾、会不会修刮削

3. Emby 很适合“看起来舒服”的那批人

如果你只是想临时找个视频点开就走，那 Emby 未必是最直接的方案。

但如果你很在意封面墙、分类、观看记录、跨设备续播、家庭共享这些体验，那么 Emby 往往会让你一用就回不去。

说白了，它卖的不是“能不能播”，而是“播得是不是舒服”。

`#`电报服推荐

那么问题来了。

如果你已经知道 Emby 是什么了，接下来最容易纠结的，往往不是“要不要用”，而是“第一家该先蹲哪个”。

其实这事也不用想得太复杂。你不用把所有 Emby 服都看成同一种东西，有的适合当主力，有的适合当备用，有的胜在线路，有的赢在库量。

下面这几家，是我觉得信息相对明确、而且各自定位也比较典型的几种。

4. 既然都推荐到这里了，那怎么用呢？

其实真上手没那么复杂。

你拿到一个 Emby 服之后，通常只需要准备这几样东西：

服务器地址
用户名
密码

接下来在播放器里添加服务器，连接协议一般选 Emby 或者 其他 Emby，然后把上面这几项填进去就行。

那么播放器该怎么选？

按 2025 年 8 月 11 日这份整理来看，我更建议你优先从下面这些“用的人多、也相对省心”的开始试：

Android：Vidhub、Hills、Yamby、Emby 小秘版、capyplayer
iPhone / iPad：SenPlayer、Vidhub、capyplayer
Apple TV：SenPlayer、Vidhub
Windows：Hills Lite、Yamby、小幻影视
华为鸿蒙：HosPlayer

不过这里有个很重要的小提醒。

Emby 相关客户端和各种改版非常多，不同设备上的兼容性真的不完全一样。所以最稳的做法不是“别人说哪个好我就只装那一个”，而是先从上面这些主流选择里试，再留下你自己设备上最顺手的那个。

另外，苹果系很多人第一反应会去装 Infuse，不过现在不少服已经直接禁掉了，或者禁它的“媒体库模式”。所以你如果是 iPhone、iPad 或 Apple TV 用户，先从 SenPlayer、Vidhub 这类更稳一点的开始，通常更省事。

再补一句，有些服还会限制网页播放、官方客户端，或者某些功能。所以你登录成功之后，还是先看一眼群公告最稳。

`#`常见问题

Q：Emby 和网盘在线看有什么区别？

A：最大的区别在体验。网盘更像“临时打开一个文件”，而 Emby 更像“在一个整理好的媒体库里消费内容”。前者能看，后者更适合长期看。

Q：Emby 和 Plex、Jellyfin 是一类东西吗？

A：对，本质上是同一赛道的媒体库方案。只不过它们各自的生态、客户端体验、授权方式和社区氛围不太一样。

Q：第一次接触 Emby，最容易踩什么坑？

A：最容易踩的坑就是把所有 Emby 服都当成同一个质量水平。其实不是。不同实例之间的差异，可能比你想象中大得多。

`#`总结

所以说，Emby 这东西本身并不神秘。

它本质上就是一个把媒体内容整理得更像现代流媒体的系统，而大家真正讨论得热火朝天的，往往是它背后的资源、线路和维护水平。

如果你只是想先搞明白 Emby 是什么，那么看到这里其实就已经够了。

至此，我们已经把 Emby 这个概念快速捋顺了。就这么简单！

免费白嫖Hi168云平台提供的1TB，S3对象存储。

Thu, 12 Mar 2026 18:20:00 GMT

根据相关文章来说，Hi168 是一个来自上海的云服务商。他提供了一个桌面云应用，有个图形化界面长得跟Window一样。

通过Hi168官方入口注册。

`#`1) 额度情况：基础500G，实名上1T。创建储存桶

Hi168 的储存额度：

注册新用户有 500GB储存。
实名后能到 1TB
提供 S3 兼容对象存储

同时支持很多 S3 的工具去用。对喜欢折腾的人来说，这点比单纯容量大更有意思。

进入Hi168页面打开中的 [1]存储管理，在[2]可以看到你当前的储存空间。 打开对象存储页面后,点击[4]OSS设置，申请新密钥。 再到[3]"＋"号创建存储桶。

`#`2）用Cyberduck等S3工具连接储存空间

这块其实不复杂。因为 Hi168 给的是 S3 兼容存储，所以像 Cyberduck 这种支持 Amazon S3 / 第三方 S3 的客户端，理论上都能直接拿来连。Cyberduck 官方也写了，它支持 Amazon S3 以及很多第三方 S3 兼容服务。

如果是Cyberduck，相关配置如下：

协议：Amazon S3
服务器 / Endpoint：填 Hi168 给你的 S3 endpoint
端口：443
Access Key ID：填你创建的密钥
Secret Access Key：填对应的密钥
连接方式：默认走 HTTPS

如果连不上，还有个小细节要注意。
Cyberduck 官方提到，有些第三方 S3 兼容服务只支持 path-style 请求，这种情况下如果你用普通 S3 配置连不上，可以改用它提供的 “Deprecated path style requests” 配置，或者关闭 virtual host style。

连上之后，一般就能看到你的 bucket，然后直接拖文件上传就行了。很多同类对象存储在 Cyberduck 里的连接方式也差不多：填 endpoint、Access Key、Secret Key，然后进去管理 bucket 和对象。

除了 Cyberduck，也可以用这些：

rclone
S3 Browser
Mountain Duck
其他支持 S3 的文件管理工具等

反正思路都一样：
只要它支持 S3 兼容协议，基本就有机会接 Hi168。

`#`3) Hi168平台的其它服务

Hi168 其实不只是对象存储，同时带有云桌面、镜像、模板、应用部署能力的轻量云平台。注册后平台还会送5算力，后续可以通过充值续算力。

其他详细的使用教程可以参考此篇文章

`#`4) 应用场景

适合的使用场景：

备份文件
轻度挂载 S3 工具
存项目资料或冷数据
自己拿来折腾玩

如果只是想搞一个免费、容量大的 S3 仓库，那它确实挺香。

`#`5) 但也别期待太高，速度情况。

免费的东西，体验一般都会打点折。

按小众软件文中的实测，白天上传大约 2~4MB/s，下载大约 1MB/s，晚高峰可能掉到几百 KB/s。

Hi168的S3速度大概就是“够用，但不惊艳”的水平。
拿来备份、同步、轻度分发还行，但你要把它当高性能图床、正式资源站或者主力对象存储，免费的东西不要求太多。

所以我更愿意把它看成：

一个能白嫖的备用仓库，而不是可以直接全押的主力方案。

`#`6) 篇末

Hi168 这个平台，我的看法很简单：

值得注册试试，也值得拿来薅空间和折腾工具，但更适合当实验仓库、备份仓库，不太像成熟稳定的长期主力存储。

`——自此本章完结——`

日志测试二：日期与评论位验证

Mon, 02 Mar 2026 20:25:00 GMT

这篇用于检查三个点：

列表是否显示发布时间。
详情页是否显示发布时间与更新时间。
页面底部是否正常出现 Giscus 评论区。

如果都正常，就可以按这个模板继续写正式日志。

日志测试一：展览馆日志联通

Mon, 02 Mar 2026 20:10:00 GMT

今天先做联通测试：

在 src/content/posts/ 新建日志 md。
设置 frontmatter 的 category: 日志。
访问 /journal/ 检查是否出现列表项并可点击进入详情。

如果这篇能在日志页显示并能点开，就说明“日志按帖子模型走”已经打通。

用 video-ts 在 Cloudflare Pages / Worker 零成本托管你的视频文件

Fri, 27 Feb 2026 16:30:00 GMT

`项目仓库地址:` ::github{repo="TyrEamon/video-tsp"} <details> <summary>点击展开</summary> <p>源站：https://github.com/TyrEamon/video-ts <p>镜像站：https://gh.kaza.de5.net/TyrEamon/video-tsp</p> </details>

`#`前言

如果你想把视频放进博客，但又不想自建流媒体服务器，那么你可以考虑用强大的FFmpeg工具和video-ts项目。这种“静态分片 + CDN 分发”的方案会非常实用。核心思路是：

本地用 FFmpeg 处理视频，转码和生成 HLS/DASH 分片文件。

video-ts 负责整理路由和播放页。

白嫖Cloudflare服务，让大善人负责全球分发和缓存。

后续可以嵌入 、读取到博客中，直接播放比如：

::video-ts{url="https://你的域名/_v/001/index.m3u8"}

`#`1、为什么用 Cloudflare Pages 或 Worker 托管视频

用cloudflare托管我们可以享受它的服务：我们不用自己搭流媒体服务器、自带有 CDN，跨地区访问更稳。自带 HTTPS 和自定义域名，不用自己配置。可用缓存规则把热分片打到边缘缓存（HIT）

同时每次提交新文件到 GitHub，Pages 会自动部署新的视频文件。

Pages 和 Worker 的选择：

想省事：先用 Pages（静态托管很直接）
如果你后面想做更复杂逻辑（鉴权、签名、反代）：再加 Worker

`#`2、想托管到cf，首先得进行HLS 和 DASH 分片

Cloudflare Pages 托管静态文件的约束：

单个静态文件最大 25 MiB

Free 计划每个站点最多 20,000 个文件

HLS 和 DASH本质就是“把一个大视频切成很多小段 + 一份清单文件”。

HLS文件：入口文件 .m3u8＋多个 .ts 或 .m4s 分片文件
DASH文件：入口文件 .mpd＋多个 .m4s 或 .webm 分片文件

进行播放时，播放器会先读清单，再按顺序拉分片。

`#`3、分片前要先考虑视频的编码格式。选H.264(AVC) 还是 AV1？兼容性和压缩率怎么选?

目前主流上最稳定的视频编码格式是 H.264（AVC）。它是最老的视频编码格式，兼容性最强。
AV1：同画质通常更省码率兼并高压缩率、文件更小更省流量，但前提是得设备支持 AV1 解码。

我的建议：

博客主力先上 H.264（稳）
你有精力再补 AV1 版本（省流量）

`#`4、工具推荐 FFmpeg（含命令 + 关键参数）

FFmpeg处理视频、音频界的瑞士军刀，功能强大，支持几乎所有视频格式。我们的转码和分片都在FFmpeg里进行。

4.1 转 AV1（示例）

ffmpeg -i "input.mp4" -c:v libsvtav1 -crf 30 -preset 6 -pix_fmt yuv420p -c:a libopus -b:a 160k "output-av1.mkv"

参数调整：

-c:v libsvtav1：视频编码器用 AV1
-crf 30：质量与体积平衡（越小越清晰，也更大）
-preset 6：编码速度档位（越慢通常压得更好）
-pix_fmt yuv420p：兼容性更稳
-c:a libopus -b:a 160k：音频 Opus 160k

4.2 切 HLS（`.m3u8 + .ts`）

ffmpeg -i "input.mp4" -c:v libx264 -preset medium -crf 23 -c:a aac -b:a 128k -f hls -hls_time 6 -hls_playlist_type vod -hls_flags independent_segments -hls_segment_filename "public/_v/001/seg_%05d.ts" "public/_v/001/index.m3u8"

关键调整：

-f hls：输出 HLS
-hls_time 6：每段大约 6 秒
-hls_playlist_type vod：点播场景
-hls_segment_filename：分片命名模板

4.3 切 DASH（`.mpd + 分片`）

ffmpeg -i "input.mp4" -map 0:v:0 -map 0:a:0 -c:v libx264 -preset medium -crf 23 -c:a aac -b:a 128k -f dash -seg_duration 4 -use_template 1 -use_timeline 1 "public/_v/001/manifest.mpd"

关键调整：

-f dash：输出 DASH
-seg_duration 4：每段约 4 秒
-use_template 1 -use_timeline 1：模板 + 时间线

`#`5、分片后的`.m3u8`和`.ts`、`.mpd`和`.m4s/webm`文件放,统一放在 `_v` 下

在 video-ts 里统一放：

public/_v/<slug>/

比如：

public/_v/001/index.m3u8
public/_v/001/seg_00000.ts
public/_v/001/manifest.mpd
public/_v/001/chunk-stream0-00001.m4s

`#`6、video-ts的首次部署&日常使用流程（最实用）

（1）首次部署：
1. worker 端：
  - 到 cf 控制台，创建一个新的 Worker。
  - 把 worker.js 内容复制到 Worker 编辑器。
  - 绑定自定义域名到 Worker。
2. pages 端：
  - 到 cf 控制台，创建一个新的 Pages 项目。
  - 链接到你的 GitHub 仓库项目
  - 构建命令：npm run build
  - 构建输出：public
  - 绑定自定义域名到 Pages。
（2）日常使用（每次加新视频我就是这四步）：
1. 把分片放进 public/_v/<slug>/
2. 跑：

npm run build

提交并 push
push到远端github仓库，cf pages等会自动部署

`#`后记

_headers 和 player.html 是干嘛的

`_headers`： Cloudflare 静态响应头配置。

CORS（跨域播放）
缓存策略（清单短缓存、分片长缓存）：m3u8/mpd：短缓存、ts/m4s/webm/mp4：长缓存 + immutable

`player.html`：通用播放器页面，能直接打开 URL 播放。

引用的js库：

video-dev/hls.js（HLS）
Dash-Industry-Forum/dash.js（DASH）然后博客端直接用：

<details> <summary>点我展开</summary> <p>/d、/h 指定解码方式

HLS解码：https://你的域名/h/<slug>
DASH解码：https://你的域名/d/<slug>
默认入口：https://你的域名/<slug>（优先 HLS）</p> </details>

如果你博客自己已经内置播放器，也可以不走 player.html，直接用路由：

HLS：/h/<slug>
DASH：/d/<slug>

Cloudflare 缓存规则建议(看情况加)

如果浏览器缓存命中了，但 CF-Cache-Status 还是 DYNAMIC。可以到cf的缓存规则里加 Cache Rules。

分片规则（长缓存）

匹配：/_v/* 下的 m4s/ts/webm/mp4
动作：Eligible for cache
Edge TTL：1 个月或 1 年

清单规则（短缓存）

匹配：/_v/* 下的 m3u8/mpd
动作：Eligible for cache
Edge TTL：5 分钟

这样基本就能从 DYNAMIC 变成 MISS/HIT 了。

video-ts 这套就是“轻后端视频托管”：
FFmpeg 负责处理，Cloudflare 负责分发，博客负责展示

`--到此本文结束--`

Alist/OpenList 美化教程：自定义头部快速上手（背景/毛玻璃/切换按钮）

Mon, 23 Feb 2026 00:00:00 GMT

Alist/OpenList 美化教程：自定义头部快速上手（背景/毛玻璃/切换按钮）

这篇就写一个简单实用版：用 Alist/OpenList 后台的 “自定义头部（Customize head）”，做背景图、毛玻璃和切换按钮。

重点放在怎么使用，优化过程只简单带过。

最终效果（这篇能做什么）

白天/夜间模式不同背景图
列表/卡片毛玻璃效果
左下角手动切换按钮
一些细节样式（导航、代码块、底部渐变）

使用前准备

你需要准备：

一份主题片段文件（openlist-Theme.html）
背景图链接（推荐 4 张）

推荐准备 4 张图，分别对应：

白天横屏
白天竖屏
夜间横屏
夜间竖屏

没有 4 张也没关系，先用 2 张（白天/夜间各一张）也能用。

使用方法（重点）

打开 OpenList 后台
进入 设置 -> 全局 -> 自定义头部（Customize head）
打开 openlist-Theme.html
把里面的背景图 url("...") 换成你自己的图片直链
将整份内容复制到 自定义头部
保存并刷新页面

需要替换的地方（背景图）

在 <style> 里主要改这 4 处：

.hope-ui-light 的横屏背景
.hope-ui-light 里的竖屏背景（@media (max-aspect-ratio:1)）
.hope-ui-dark 的横屏背景
.hope-ui-dark 里的竖屏背景（@media (max-aspect-ratio:1)）

简单说就是把原来的：

background-image: url("你的图片链接");

替换成自己的图床/网盘直链。

只想换背景，不想要按钮？

可以。

你只保留 <style>...</style> 部分，把按钮相关的 <script>...</script> 去掉就行。这样更稳，也更适合只做静态美化。

完整代码（可直接复制）

下面这份就是可以直接粘贴到自定义头部的版本（记得先把 4 个背景图链接替换成你自己的）。

GitHub 仓库（可直接取最新版本）：

https://github.com/TyrEamon/openlist-Theme

背景url修改示例（确认格式没问题）：

<script src="https://polyfill.alicdn.com/v3/polyfill.min.js?features=String.prototype.replaceAll"></script>
<style>
.hope-ui-light { /* 白天背景(电脑端&手机端) */ }     /* 日：url.1=横屏 url.2=竖屏 */
.hope-ui-dark  { /* 夜间背景(电脑端&手机端) */ }     /* 夜：url.1=横屏 url.2=竖屏 */
</style>
<script>
// 日夜切换按钮逻辑（已做移动端误触修复）
</script>

<details> <summary>点击展开完整代码（可直接复制）</summary>

<script src="https://polyfill.alicdn.com/v3/polyfill.min.js?features=String.prototype.replaceAll"></script>
<style> .notify-render .hope-close-button {
    display:none
}
.hope-ui-light {
    background-image:url("https://pan.0106010.xyz/file/openlist-Theme/1771838991109_130584045_p0.webp") !important;
    @media (max-aspect-ratio:1) {
        background-image:url("https://pan.0106010.xyz/file/openlist-Theme/1771838999793_file_6179.webp") !important;
    }
    background-repeat:no-repeat;
    background-size:cover;
    background-attachment:fixed;
    background-position-x:center
}
.hope-ui-dark {
     background-image:url("https://pan.0106010.xyz/file/openlist-Theme/1771839006594_openlist1.webp") !important;
    @media (max-aspect-ratio:1) {
        background-image:url("https://pan.0106010.xyz/file/openlist-Theme/1771838992434_1673371139204.webp") !important;
    }
    background-repeat:no-repeat;
    background-size:cover;
    background-attachment:fixed;
    background-position-x:center
}
.hope-ui-light .obj-box.hope-stack.hope-c-dhzjXW.hope-c-PJLV.hope-c-PJLV-igScBhH-css {
    backdrop-filter: blur(1px);
    background-color:rgba(255,255,255,0.7) !important
}
.hope-ui-dark .obj-box.hope-stack.hope-c-dhzjXW.hope-c-PJLV.hope-c-PJLV-iigjoxS-css {
    backdrop-filter: blur(1px);
    background-color:rgb(0 0 0 / 50%) !important
}
.hope-ui-light .hope-c-PJLV.hope-c-PJLV-ikSuVsl-css {
    backdrop-filter: blur(1px);
    background-color:rgba(255,255,255,0.5) !important
}
.hope-ui-dark .hope-c-PJLV.hope-c-PJLV-iiuDLME-css {
    backdrop-filter: blur(1px);
    background-color:rgb(0 0 0 / 50%) !important
}
.hope-ui-light .hope-c-ivMHWx-hZistB-cv.hope-icon-button {
    backdrop-filter: blur(1px);
    background-color:rgba(255,255,255,0.5) !important
}
.hope-ui-dark .hope-c-ivMHWx-hZistB-cv.hope-icon-button {
    backdrop-filter: blur(1px);
    background-color:rgb(0 0 0 / 50%) !important
}
.hope-ui-light .hope-c-PJLV-ijgzmFG-css {
    backdrop-filter: blur(1px);
    background-color:rgba(255,255,255,0.5) !important
}
.hope-ui-dark .hope-c-PJLV-ijgzmFG-css {
    backdrop-filter: blur(1px);
    background-color:rgb(0 0 0 / 50%) !important
}
.hope-ui-light pre {
    background-color:rgba(255,255,255,0.1) !important
}
.hope-ui-dark pre {
    background-color:rgba(255,255,255,0) !important
}
.hope-ui-light .hope-c-PJLV-ieGWMbI-css {
    backdrop-filter: blur(1px);
    background:rgba(255,255,255,0.5) !important
}
.hope-ui-dark .hope-c-PJLV-ieGWMbI-css {
    backdrop-filter: blur(1px);
    background-color:rgb(0 0 0 / 50%) !important
}
.hope-ui-light .hope-c-PJLV-ihVEsOa-css {
    backdrop-filter: blur(1px);
    background:rgba(255,255,255,0.5) !important
}
.hope-ui-dark .hope-c-PJLV-ihVEsOa-css {
    backdrop-filter: blur(1px);
    background-color:rgb(0 0 0 / 50%) !important
}
#root > .header {
    background:linear-gradient(180deg,rgba(255,255,255,0.3),rgba(255,255,255,0))
}
.footerd {
    width: 100vw;
    height: 5vh;
    position: fixed;
    bottom: 0;
    left: 0;
    background:linear-gradient(0deg,rgba(255,255,255,0.3),rgba(255,255,255,0))
}
.hope-ui-light .body > .nav {
    background-color:rgba(255,255,255,0.7);
    border-radius:var(--hope-radii-xl)
}
.hope-ui-dark .body > .nav {
    background-color:rgb(0 0 0 / 50%);
    border-radius:var(--hope-radii-xl)
}
.body > .nav::after {
    display:none
}
dibu {
    border-top:0px;
    position:absolute;
    bottom:0;
    width:100%;
    margin:0px;
    padding:0px
}
.App {
    min-height:85vh
}
.table {
    margin:auto
}
#canvas-basic {
    position:fixed;
    display:block;
    width:100%;
    height:100%;
    top:0;
    right:0;
    bottom:0;
    left:0;
    z-index:-999
}
.hope-image {
    filter:drop-shadow(2px 4px 8px rgb(255,255,255))
}
button#hope-menu-daynight-switch-trigger {
    position: fixed;
    bottom: 7.5vh;
    left: 2.5vw;
    z-index: 114;
    size: var(--hope-sizes-8);
}

/* fallback panel colors when OpenList hash classes change */
.hope-ui-light .obj-box {
    background-color: rgba(255,255,255,0.65) !important;
}
.hope-ui-dark .obj-box {
    background-color: rgb(0 0 0 / 50%) !important;
}
</style>
<script>
    document.write(`<div class="footerd"></div>`);
</script>
<!-- 日夜主题切换按钮 | Day/Night Switch Button -->
<script>
    function unlockScroll() {
        var docEl = document.documentElement;
        var body = document.body;
        if (docEl) {
            docEl.style.overflow = "";
            docEl.style.overflowY = "";
            docEl.style.position = "";
            docEl.style.width = "";
        }
        if (body) {
            body.style.overflow = "";
            body.style.overflowY = "";
            body.style.position = "";
            body.style.width = "";
            body.style.paddingRight = "";
            body.style.touchAction = "";
        }
    }

    function cleanupThemeSwitchUi() {
        if (document.querySelectorAll) {
            var leftovers = document.querySelectorAll(".hope-drawer__overlay, .hope-drawer__content-container, .hope-modal__overlay");
            for (var i = 0; i < leftovers.length; i++) {
                leftovers[i].style.display = "none";
                leftovers[i].style.pointerEvents = "none";
            }
        }

        unlockScroll();
        setTimeout(unlockScroll, 120);
        setTimeout(unlockScroll, 320);
    }

    function getThemeTargets() {
        if (!document.querySelectorAll) return [];
        return document.querySelectorAll(".hope-ui-light, .hope-ui-dark");
    }

    function daynightswitch(e) {
        if (e) {
            if (e.preventDefault) e.preventDefault();
            if (e.stopPropagation) e.stopPropagation();
            if (e.stopImmediatePropagation) e.stopImmediatePropagation();
        }

        var targets = getThemeTargets();
        if (!targets.length) return;

        var toDark = false;
        for (var i = 0; i < targets.length; i++) {
            if (targets[i].classList.contains("hope-ui-light")) {
                toDark = true;
                break;
            }
        }

        for (var j = 0; j < targets.length; j++) {
            targets[j].classList.remove("hope-ui-light", "hope-ui-dark");
            targets[j].classList.add(toDark ? "hope-ui-dark" : "hope-ui-light");
        }

        cleanupThemeSwitchUi();
    }

    if (!document.getElementById("hope-menu-daynight-switch-trigger")) {
        document.write(`<button
    class="hope-c-bvjbhC hope-c-PJLV hope-c-PJLV-ieTGfmR-css hope-icon-button hope-button hope-c-ivMHWx hope-c-ivMHWx-kcPQpq-variant-subtle hope-c-ivMHWx-cEknLI-size-lg hope-c-ivMHWx-dvmlqS-cv hope-c-ivMHWx-hZistB-cv hope-c-PJLV hope-c-PJLV-iikaotv-css"
    type="button" role="button" id="hope-menu-daynight-switch-trigger" aria-label="switch layout"><svg t="1733225100292"
        class="icon" viewBox="0 0 1024 1024" version="1.1" xmlns="http://www.w3.org/2000/svg" p-id="4397"
        xmlns:xlink="http://www.w3.org/1999/xlink" width="1em" height="1em">
        <path
            d="M512 0c282.7776 0 512 229.2224 512 512s-229.2224 512-512 512S0 794.7776 0 512 229.2224 0 512 0z m0 51.2a460.8 460.8 0 0 0-13.568 921.3952L512 972.8v-256a204.8 204.8 0 1 0 0-409.6V51.2z m0 256v409.6a204.8 204.8 0 1 1 0-409.6z"
            fill="currentColor" p-id="4398"></path>
    </svg></button>`);
    }

    var dayNightBtn = document.getElementById("hope-menu-daynight-switch-trigger");
    if (dayNightBtn && !dayNightBtn.dataset.bound) {
        dayNightBtn.dataset.bound = "1";
        dayNightBtn.addEventListener("click", daynightswitch, true);
    }

</script>

</details>

我这次做的优化（简单带过）

我这边在原主题基础上做了几个小优化，主要是为了更好用：

修复切换过程中会给页面加滚动锁导致“不刷新切换后页面不能滚动”
修复daynightswitch() 在手机端会按索引错误触发“新建文件夹/上传” 按钮
修复白天模式下面板发黑（补 light/dark 前缀和兜底样式）

问题示意图

修复后示意图

如果你只是拿来用，不需要关心太多实现细节，直接用调好的版本即可。

使用建议（推荐）

背景图尽量用 webp，加载更快
图片链接尽量走 CDN/图床，避免加载慢
先能用，再慢慢调透明度和模糊值
手机端一定要测按钮点击和滚动
OpenList 更新后若样式异常，优先检查 hope-xxx 类名是否变化

总结

这套 OpenList 美化的使用流程其实很简单：

准备主题片段
替换背景图链接
粘贴到 自定义头部
保存刷新

先用起来，再慢慢优化细节就行。

xin 项目一个“自用”的图片采集/发布/展示系统，从 0 到部署

Sat, 21 Feb 2026 23:30:00 GMT

该项目是为了更好的收集和展示个人收藏的图片而设计的，自用。本项目可以部署在本地或云端，推荐在云端部署。

0. 先说结论：xin 到底在干嘛

xin 本质是一个 Go 后端 + 静态前端 的图站方案：

图来源：轮询爬取pixiv及twitter的收藏、TG 上传、TG 链接监听（Pixiv / Yande / FANBOX / Twitter / 或其他图站[得自己加逻辑]）
图存储：
- 发布频道 A：放预览图（给前台看）
- 存储频道 B：放原图（留档 + 按钮获取）
建议给 A 频道绑定讨论组，用于评论区挂原图/详情按钮
元数据：Cloudflare D1
可选备份：WebDAV / OpenList

关键设计：前台只吃预览图，原图走 B 频道，前端更稳，带宽压力也更小。

系统架构一览：Pixiv/TG -> Go 后端 -> A/B 频道 + D1 + WebDAV

1. 前置条件（不满足就别往下）

先确认你有这些东西：

一个 Telegram Bot（拿到 BOT_TOKEN）
两个 Telegram 频道：A（发布）+ B（存储）
（可选）A 绑定的讨论组（用于评论区挂原图/详情按钮）
Cloudflare D1（已有数据库 ID）
我这里使用的是Zeabur（部署后端容器），建议使用线路好的个人主机或者容器
Cloudflare Pages / EdgeOne（部署静态前端）

1.1 TG 权限

机器人必须是 A、B 两个频道管理员；要用讨论区就让机器人在讨论组也能发消息。

2. 建立D1数据库表

你有两种方式：

你可以直接跑项目里的 schema.sql（推荐）
让后端首次启动自动补齐（更省事，但建议后面手动核对）

如果你是旧库升级，至少确认这些表存在：

images
favorites
ingest_blocklist
crawler_state
（开备份）image_backups

快速检查表：

SELECT name FROM sqlite_master WHERE type='table' ORDER BY name;

3. Zeabur 部署后端（最小可用）

3.1 必填环境变量

最小集合（先跑起来）：

BOT_TOKEN=
PUBLISH_CHANNEL_ID=
STORAGE_CHANNEL_ID=
# 可选：DISCUSSION_GROUP_ID=

CLOUDFLARE_ACCOUNT_ID=
CLOUDFLARE_API_TOKEN=
D1_DATABASE_ID=

ADMIN_PASSWORD=

3.2 Pixiv 相关配置（看个人需求，要自动爬就配）

PIXIV_PHPSESSID=
PIXIV_USER_ID=
PIXIV_TAG=
PIXIV_REST=show
PIXIV_CRAWL_ORDER=desc
PIXIV_LIMIT=40
PIXIV_MAX_PAGES=0
PIXIV_BOOTSTRAP_MAX_PAGES=-1
PIXIV_INCREMENTAL_MAX_PAGES=2
PIXIV_INTERVAL_MINUTES=120

经验值：全量完成后，把状态切到增量，不然每轮从头扫会很慢。

3.3 一眼看启动是否正常

看日志是否有：

HTTP server listening on :8080
Pixiv crawl started ...（你配了 Pixiv 时）

4. 前端部署（Pages/EdgeOne）

前端是静态页，和后端分开部署。也可以不去部署web，因为后端部署上去就包括前端。访问后端域名，通常都能重定向到/gallery.html。

后端域名示例：https://a.example.com
前端域名示例：https://b.example.com/gallery.html

前端请求后端 API，只要 API 域名填对即可。

5. 先做 5 分钟验收（别一上来就全链路压测）

按顺序测：

给 Bot 发一张图
- A 有预览
- B 有原图
- D1 有新记录
给 Bot 发一条 Pixiv 链接
- 正常入库 + 前台可见
打开后台上传页上传一张图
- 成功后前台能看到
（开了备份）看备份健康状态

备份检查（可选，你可以在管理面板查看备份情况）：

$base = "https://你的后端域名"
$auth = "x:你的ADMIN_PASSWORD"
curl.exe -sS -u $auth "$base/admin/api/backup/health?probe=1"

6. 常见坑（按报错关键字定位）

6.1 `getUpdates ... 409 Conflict`

含义：同一个 Bot 有多个实例在轮询。
处理：保证只有一个服务在跑（关掉旧实例、重复服务）。

6.2 `ghcr.io ... 401 Unauthorized`

含义：拉镜像没权限。
处理：检查包是否 public，或给 Zeabur 配 GHCR 拉取凭证。

6.3 `chat not found`

含义：机器人不在目标频道，或频道 ID 配错。
处理：确认 Bot 在 A/B 频道里、ID 前缀 -100 没写错。

6.4 `context deadline exceeded`

含义：网络链路超时（TG / 目标站 / 容器出口波动）。
处理顺序：

容器里 wget 测目标 URL 连通性
降低并发/缩小单次抓取量
把 TG 直传改成 file_id 直发

6.5 `pixiv bookmarks error: cannot unmarshal ... id`

含义：上游返回结构变了。
处理：更新解析逻辑，别硬写死字段类型。

7. 我建议的“稳定参数”起步值

用的是go语言轻量、高并发，对配置要求不高。反倒看重线路的质量。：

Pixiv：PIXIV_INTERVAL_MINUTES=120
Pixiv 增量：PIXIV_INCREMENTAL_MAX_PAGES=2
Twitter 作者轮询：TWITTER_AUTHOR_INTERVAL_MINUTES=120
作者抓取数：TWITTER_AUTHOR_FETCH_LIMIT=3~5
备份：BACKUP_WORKERS=1

先稳住，再提速。

8. 你要能复述的原理（核心三句话）

前台看的是预览图，不是原图，原图放 B 频道。
D1 只管索引和状态，图文件本体不进 D1。
超时大头通常在“下载再上传”，file_id 直发能明显减压。

日志对照图

如果你照着做卡住了，优先把这 3 个信息贴出来再排：

报错原文（完整一段）
相关环境变量名（值可打码）
你当前访问链路（前端域名、后端域名、有没有 Worker/CDN）

这样定位会很快，不用盲猜。

Pixiv 收藏本地下载器（Python）随手记

Tue, 27 Jan 2026 21:10:00 GMT

说明：本文仅供个人学习 + 进行本地备份记录，还请遵守 Pixiv 的相关使用条款，不要二次分发。

Github项目地址: <details> <summary>点击展开</summary>

https://github.com/TyrEamon/Pixiv-mylove

</details>

至于这个该工具能做什么？

这是一个 Pixiv 个人收藏本地下载器（用的Python语言，单线程就不上go了），我拿来做本地备份。功能单一，但也挺实用：

它能自动下载你的pixiv收藏插画（支持标签筛选）。
自动分页抓取page1、page2。
3次的失败重试 + 页间间隔10s，图间1.5s外加随机间隔（避免过快，触发pixiv的风控。至于有没有，我觉得应该是有的）。
流程自生成history_* .json历史文件，下载中同步写入记录进行去重，避免重复爬取。
history_* .json是按标签生成独立历史文件，个人收藏根目录下用的是全局去重，它会合并所有的history_* .json子历史文件构建全局去重池，所以你"tag": "留空时"爬到的插画不会和子标签里的图片重复。
命名格式统一：pixiv_{id}_p{n}.ext，p0、p1....对应的就是父子图。
爬过的图，再次获取将直接跳过，当连续跳过 200 张就停止。(你也可以关闭该设置，或增加阈值)

项目结构一览：

pixiv_mylove/ 里主要是这几样：

pixiv_mylove/
├── main.py                 # 主程序
├── config.json             # 配置文件
├── history_*.json          # 历史记录（去重）
└── run.bat                 # 一键运行脚本（这个我不想调终端，就整了懒人bat）

`前置准备：`

注意需要自己配置好网络环境，确保与Pixiv的连通性！！！

我个人用的是V2ranyN，直接开启Tun模式。 你也可以自己手动进行相应的配置

获取你自己的Pixiv Cookie/PHPSESSID、个人uid
登录你的Pixiv账号，F12 开发者面板
找到PHPSESSID，里面的值就是我们要的Cookie了

接下来进入实操

使用步骤

① Clone仓库文件到本地

git clone https://github.com/TyrEamon/Pixiv-mylove.git

② 根据你自己的信息修改配置文件 `config.json`

{
  "php_sessid": "你的PHPSESSID",
  "user_id": "你的Pixiv用户ID",
  "tag": "H",
  "limit": 40,
  "max_pages": 0,
  "download_dir": "E:/pixiv图片/h"
}

③ 直接运行

python main.py

或者直接双击 run.bat。

-正常运行-

拿到图片文件，你可以存在本地或上传到图床。

说到上传你可以原图直传，但你下次获取的时候也是原图，图片体量会非常大（十到几十M）。这里我会用到Xnconvert，它能批量在保证图片质量下给你转成webp。更多详见文章

配置项说明

php_sessid：Pixiv 登录后 cookie 里的 PHPSESSID
user_id：你的 Pixiv 用户 ID
tag：收藏标签，留空=全部收藏
limit：每页抓取数量（默认 40）
max_pages：你要抓取页数（值=0将爬完延续下页轮询爬取）
download_dir：你要保存到本地的目录位置

爬图频率与稳定性相关（有需要就自己设置，没有直接默认就行）

sleep_between_images_sec：每张图间隔
sleep_between_pages_sec：每页间隔
retry_times：失败重试次数
retry_delay_sec：重试等待
max_consecutive_skips：连续跳过多少张后自动停止

如果你也只是想把收藏图放到本地，这套目前已经够用了。

—— 记录完毕 ——

踩着前人的脚印，RuneByte Blog 终于建站成功了

Tue, 27 Jan 2026 20:30:00 GMT

说明：本博客基于开源项目进行二次改造与使用，感谢原作者和相关项目的贡献。本文是我的建站记录与成果分享。

1) 终于有自己的博客了

踩着前人的脚印折腾了一阵子，RuneByte Blog 总算上线了。
站点入口在这里：
👉 https://i.kyr.us.ci

作为编程小白，这次建站从“能跑起来”到“像自己的网站”，看到它跑起来挺有成就感。

我就微微带过一下我的搭建过程（博客主框架Fuwari）

也没什么特别值得详谈的东西。

首先

fork 原作者项目

这里原作者[saicaca]的Fuwari、作者二叉树树[afoim]二改过Fuwari

我本人用的是以fuwari为底的新一代博客

先在自己本地跑起来，方便调试改动。

pnpm install #如果没有项目依赖包的话
pnpm dev

开放4321端口，本地预览 http://localhost:4321

修改配置（把个人信息换过来）>删除旧文章>去广告把分类页标签加回来>改脚注>加功能，花了一点时间。

然后正常流程：部署上线给它扔到edgeone上 + 绑定自定义域名。
浏览器访问，成功返回博客页面ok了，博客到这里旧通了。

EdgeOne的线路说是国内挺快的(但是要得是备案域名，可惜我的域名还没备案)，看看后面吧！要不要给它整一个备案。目前就这样吧，先建着站玩玩先。

还过得去，后面再研究研究优化一下。

—— 这是我的第一篇，继续更新中 ——

Static.Random.PicAPI的随机图 Gallery的样式性能优化

Tue, 27 Jan 2026 14:43:00 GMT

说明：本文基于原作者项目进行二次优化与记录，感谢原作者的思路与代码。本文仅用于学习与个人使用，转载请注明来源。

Github项目地址: <details> <summary>点击展开</summary>

https://github.com/TyrEamon/Static_RandomPicAPI

</details>

1) 背景：SRPAPI这个项目原本能做什么？？

这是一个「静态随机图库」项目，构建后输出 dist/,静态托管即可：

首页展示随机图片
gallery.html 展示图库
横图/竖图分类（H/V）

但原版的 gallery.html 有两个明显问题：

一次性加载太多图片，浏览器会卡
页面样式不够顺眼（布局、交互、日夜模式等）

2) 其实作者的api是完善过了，但仓库项目似乎还没有更新。

原作者的API: https://pic1.acofork.com

干脆直接自己找ai搓来玩，因此把给它“Transform”了吧，其实也是造葫芦画瓢，也没啥说法就是了。

至于画瓢画了哪些东西呢？如下：

1. Gallery 样式升级

顶栏改为 sticky + 玻璃拟态
横/竖切换更明显
标题更大、更醒目
Hover 放大动效

2. 性能优化

触底自动加载，每批 20 张
图片加载时使用 占位容器，防止跳动

3. 体验细节

日/夜模式切换
点击图片可进入预览（lightbox）。直接套用Fancybox组件了，简单直接又省心。

操作过程

1.好了也是问ai将项目搓好了，虽然没做什么但是辛苦我了...玩个梗哈哈。弄好之后我们，得到了这一坨文件。

拿到文件，我们先把config.json里的域名，给他改改。改成你R2的存储公共开放域名。图1

因为我弄了反代用pic和gallery去隐藏了/index.html和/gallery.html的后缀，所以我要多填两个域名,详见博客文章Link。如果你们无所谓那就无所谓吧!你直接填 你的公共域/index(gallery).html就行了。

{
    "domain": "https://rapi.0w0.us.ci",
    "galleryDomain": "https://gallery.0w0.us.ci",  //不用反代就 公共域+/index.html
    "indexDomain": "https://pic.0w0.us.ci"         //不用反代就 公共域+/gallery.html
}

注意啊，如果你按教程来，那么那个图库基本上是fork仓库原作者的图（应该有4000多张），我自己是在本地新建的ri文件存的是自己的图。是否要换用自己的图库，看你·_·自己。

我自己就差不多700来张图，自己存的和一些从pixiv上爬我自己的个人收藏图。你问，这个脚本有吗？有的！兄弟有的 。你可以自己github搜索、搓一个或者我在用的这个Pixiv-Tool

填完，接下来我们就能本地 build 构建 dist 瞧瞧。

直接命令行 `node build.js` 得到构建产物/dist。（如果你没有装过依赖，你要执行一次 `npm install`）

npm install
node build.js

耐心等待如图，拿到产物。我们lib就是gallery页面相关逻辑js了，图片就存在ri里。 给他本地预览一下继续命令行

npx serve dist

你会在终端得到 http://localhost:3000 本地预览地址,进行网页访问。得到如下接下来，就是把它丢到R2上去部署。

上传部署（以 Cloudflare R2 为例）

个人用的是rclone，不过推荐用Cyberduck，有GUI界面更直观友好。

首先登录cloudflare获取你的：

R2 的 Access Key ID
R2 的 Secret Access Key
R2 的 Endpoint（S3 兼容地址）
rclone 同步到 R2：

rclone sync "C:\Users\Tyr.Eamon\Desktop\博客背景文件\随机图\dist" r2:YOUR_BUCKET --checksum --transfers 16 --checkers 16 --progress

Cyberduck 同步R2：打开 Cyberduck
- 选择Amazon S3协议。
- Server（服务器）：填你的 R2 endpoint 的主机名。形如：<accountid>.r2.cloudflarestorage.com（不要带 https://，不要带路径）
- Port：443
- Access Key ID：填你的 R2 Access Key ID
- Secret Access Key：填你的 R2 Secret Access Key

上传文件完全后，直接访问你的R2公开域就能看到SPA的界面了。

R2公共域 <details> <summary>点击展开</summary>

这里默认你部署前绑好了。

</details>

OK啊，到这里算部署出成功了，接下来就是愉快的玩耍了

最后的最后：尊重原创

这是 fork 项目的优化记录，不是从零开发。感谢原作者AcoFork提供的基础结构。

——自此本章完结——

后记！！

Thu, 21 Jul 1949 18:20:00 GMT

Github 反代

1、~~https://k.bba.cc.cd~~ 2、https://gh.kaza.de5.net 3、https://gh.2x.nz 他人维护

屏蔽海外请求。你都海外了还上不了github不是吧。该类下载域没有写进白名单，所以下载文件时会走原链。

codeload.github.com
objects.githubusercontent.com
github-releases.githubusercontent.com

Meting-music音乐api接口（个人维护）

支持的平台

平台代码搜索歌曲专辑歌手歌单链接歌词图片

网易云音乐 netease ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅

腾讯音乐 tencent ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅

酷狗音乐 kugou ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅

百度音乐 baidu ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅

酷我音乐 kuwo ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅

平台	代码	搜索	歌曲	专辑	歌手	歌单	链接	歌词	图片
网易云音乐	`netease`	✅	✅	✅	✅	✅	✅	✅	✅
腾讯音乐	`tencent`	✅	✅	✅	✅	✅	✅	✅	✅
酷狗音乐	`kugou`	✅	✅	✅	✅	✅	✅	✅	✅
百度音乐	`baidu`	✅	✅	✅	✅	✅	✅	✅	✅
酷我音乐	`kuwo`	✅	✅	✅	✅	✅	✅	✅	✅

`#`EMBY反代合集（他人维护）

使用方法：反代头/emby域名+通常端口为443

- https://ada.6yhy.top/
- https://fd.dirige.de5.net/
- https://auto.embys.dpdns.org/
- https://auto.liuer.indevs.in/
- https://auto.dolby.dpdns.org/
- https://assrt.net/

`#`优选域名

CM大佬维护：

https://cf.090227.xyz/

秋名山大佬维护：

https://cf.877774.xyz/

自用hw云单ipvv4优选（ipv6屏蔽不通）

https://cf.hw.0721521.xyz

MIYU维护:

https://saas.sin.fan

拾光小站

欢迎来到我的博客！

你怎么知道我双红的？

如何联系？

❤️‍🔥致谢板❤️‍🔥

博客简介

由来

联系方式

</details>

手机连不上 Codex，最后竟然是 v2rayN 的 TUN 网卡坏了

引言

先说结论

原理：为什么系统代理还不够

排查过程

1. 从 config.toml 开始，方向其实错了

2. Codex 已经注册成功，但连接就是超时

3. 系统代理能用，不代表 Codex 的连接会走代理

4. 开了 TUN，还是不行

5. v2rayN 是新的，Xray 内核却还是旧的

实操：正式解决

1. 下载新版 Xray

2. 完全退出 v2rayN

3. 替换 xray.exe

4. 以管理员身份启动 v2rayN

踩坑

remote_control 被删除，不是故障

系统代理和 TUN 不是一回事

v2rayN 版本不等于 Xray 版本

看到 169.254.x.x 就要警惕

最终复盘

参考资料

近期 v2rayN 与 Xray 兼容性问题记录：allowInsecure 与 TUN

起因

问题一：allowInsecure 导致 Core 启动失败

问题二：新版 v2rayN，旧版 Xray TUN

两类问题的共同原因

实操：如何排查

注意事项

总结

参考资料

General Compute 免费提供200美元API额度，MiniMax M2.7 速度实测400tokens/s

#一、平台介绍

#二、200 美元额度可用 Token 估算

（1）按单项计算：200 美元全部用于输入或输出

#三、MiniMax M2.7 的推理速度

#四、适用场景

200 美元的额度配合 400 tokens/s 的速度，有几个比较合适的用途：

（2）批量翻译

（3）作为 OpenClaw 等项目的上游 API 备用

（4）其他批量处理任务

#五、注意事项

#六、小结

如何使用CAPMS完全免费调用GPT、Gemini、Claude模型的API，实现Token自由

# 引言

# 正式开始

(1)、后端二进制程序下载

(2)、修改配置文件yaml

(3)、安装前端资源文件

# 运行程序更改配置

4、运行程序

5、更改配置

接入你的codex、Gemini CLI、Antigravity等的OAuth

# 注意事项

**1. 注意**

**2. 注意**

**3. 注意**

# 后记

奇技淫巧LINUX·之·完全免费获取Claude-Opus4模型的API

引言

什么？免费获取 Claude-Opus4 模型的 API？

Cherry Studio导入情况

讨论帖子

标题看起来是在讲“完全免费获取 Claude-Opus4 模型的 API”，但本质上，它更像是把平台本来就有的一层 AI 能力，重新包装成了一个更像标准 API 的入口。

本篇不聊具体操作，只简单讲一下它的大概实现逻辑。详情请见Linux.do帖子。

原帖链接: https://linux.do/t/topic/2049325

原理

1. 先生成一个能跑的服务

2. 让中间层负责“翻译”

3. 最后统一对外入口

看起来像“免费 API”但有点区别

`#`一、平台介绍

`#`二、200 美元额度可用 Token 估算

`#`三、MiniMax M2.7 的推理速度

`#`四、适用场景

`200` 美元的额度配合 400 tokens/s 的速度，有几个比较合适的用途：

`（2）批量翻译`

`（3）作为 OpenClaw 等项目的上游 API 备用`

`（4）其他批量处理任务`

`#`五、注意事项

`#`六、小结

`#` 引言

`#` 正式开始

`#` 运行程序更改配置

`#` 注意事项

`1. 注意`

`2. 注意`

`3. 注意`

`#` 后记

`标题看起来是在讲“完全免费获取 Claude-Opus4 模型的 API”，但本质上，它更像是把平台本来就有的一层 AI 能力，重新包装成了一个更像标准 API 的入口。`

本篇不聊具体操作，只简单讲一下它的大概实现逻辑。`详情请见Linux.do帖子。`

`#`引言

`#`原理

`#`为什么很多人会用 Emby？

`#`正式开始

`#`电报服推荐

`#`常见问题

`#`总结

`#`1) 额度情况：基础500G，实名上1T。创建储存桶

`#`2）用Cyberduck等S3工具连接储存空间

`#`3) Hi168平台的其它服务

`#`4) 应用场景

`#`5) 但也别期待太高，速度情况。

`#`6) 篇末

`——自此本章完结——`

`项目仓库地址:` ::github{repo="TyrEamon/video-tsp"} <details> <summary>点击展开</summary> <p>源站：https://github.com/TyrEamon/video-ts <p>镜像站：https://gh.kaza.de5.net/TyrEamon/video-tsp</p> </details>

`#`前言

`#`1、为什么用 Cloudflare Pages 或 Worker 托管视频

`#`2、想托管到cf，首先得进行HLS 和 DASH 分片

`#`3、分片前要先考虑视频的编码格式。选H.264(AVC) 还是 AV1？兼容性和压缩率怎么选?

`#`4、工具推荐 FFmpeg（含命令 + 关键参数）

4.2 切 HLS（`.m3u8 + .ts`）

4.3 切 DASH（`.mpd + 分片`）

`#`5、分片后的`.m3u8`和`.ts`、`.mpd`和`.m4s/webm`文件放,统一放在 `_v` 下

`#`6、video-ts的首次部署&日常使用流程（最实用）

`#`后记

`_headers`： Cloudflare 静态响应头配置。

`player.html`：通用播放器页面，能直接打开 URL 播放。

`--到此本文结束--`