{ "version": "https://jsonfeed.org/version/1", "title": "AcoFork Blog (Beta)", "description": "", "home_page_url": "/", "feed_url": "/feed.json", "user_comment": "", "author": { "name": "AcoFork" }, "items": [ { "id": "/jia-qun-xiang-dao/", "url": "/jia-qun-xiang-dao/", "title": "加群向导", "summary": "官方 Telegram群组…", "content_html": "

官方

\n

Telegram群组

\n

Telegram: Join Group Chat [2x.nz]

QQ群

\n
\n

为什么仅QQ群需要赞助？因为QQ作为国内平台，很容易被内鬼举报致使封群，但相对的，门槛更低，交流更方便。当然，如果您是高级用户，可以加入非QQ群。

\n

请先 赞助 至少 10 CNY 后加群。赞助时建议留备注，加群问题填写你留的备注或者交易订单号\n点击链接加入群聊【2x.nz】： QQ群

\"\"

非官方

\n
\n

粉丝自建

\n

Telegram: View @blog2x

", "image": "/media/posts/1/122782209_p0_master1200.jpg", "author": { "name": "AcoFork" }, "tags": [ ], "date_published": "2077-07-07T07:07:00+08:00", "date_modified": "2077-07-07T07:07:00+08:00" }, { "id": "/umami-cloudqian-yi-dao-ben-di-cai-keng-ji-lu/", "url": "/umami-cloudqian-yi-dao-ben-di-cai-keng-ji-lu/", "title": "Umami Cloud迁移到本地踩坑记录", "summary": "正式开始 首先，我们想要迁移，首先肯定是要拿到原来的Umami…", "content_html": "

正式开始

\n

首先，我们想要迁移，首先肯定是要拿到原来的Umami Cloud存放的数据

在 Umami Cloud Data | Settings 中，我们可以选择，导出数据（Export）\n

\"\"

当数据准备好后（几分钟左右），你的邮箱会收到一封Umami Cloud发来的邮件\n

\"\"

下载下来的文件是一个以UUID命名的ZIP压缩包，将其解压可以得到3个CSV文件\n

\"\"

其中，只有 website_event.csv 有用，其他两个文件仅有表头，无数据

这样，我们就成功拿到了旧Umami数据

接下来，我们需要在本地部署Umami PostgreSQL版本的 最新版 （目前版本为 3.x）（部署教程略）

然后我们还需要安装一个CSV编辑软件： SmoothCSV - The ultimate CSV editor for macOS & Windows

在本地Umami中新建一个网站，Umami会随机为你生成一个UUID

接下来我们需要在你的终端安装一个图形化管理PostgreSQL的软件： pgAdmin - PostgreSQL Tools

然后连上数据库，你将可以看到这些表\n

\"\"

接下来我们查看 website 这张表，将 website_event.csv 打开，查看旧的 website_id 将新的ID改为旧的，这样才能数据匹配\n

\"\"
\n
\"\"

接下来，我们正式开始数据导入，由于导入后的数据有两个 session_id 字段，而在Umami自我管理的过程中这个 session_id 字段是 唯一约束的 ，我们需要先解除这个限制，在正式上线前还要再加回这个限制（后面会说）

让我们删除主键约束和索引

ALTER TABLE session DROP CONSTRAINT session_pkey;\nDROP INDEX session_session_id_key;\n
\n

接下来，我们需要将数据配对，我们先查看 website_event.csv 这张表。这里应该只有表头，没有数据（我有是因为我已经导入完成了，教程是后写的）

注意顺序 如： event_id website_id session_id …

\"\"

编辑CSV文件，你需要将顺序配对，并且删除表中没有的列，如： browser os …\n

\"\"

确保数据库中的表头顺序和CSV文件中的表头顺序一一对应，顺序一致，不多不少后，Ctrl + S 保存 CSV文件，我们开始导入并在选项中勾选 标题

\"\"
\n
\"\"
\n
\"\"
\n导入成功后如图\n
\"\"
\n
\"\"

再编辑 session 这张表，手法同上，导入成功后如图\n

\"\"

接下来打开本地Umami的WebUI，查看数据是否有异常\n

\"\"

确保导入后数据无异常后，我们开始删除另一条 session_id 记录并回锁主键。否则上线后Umami将无法再向表中插入数据

SELECT session_id, COUNT(*) \nFROM public.session\nGROUP BY session_id\nHAVING COUNT(*) > 1;\n\n-- 保留最早的 created_at\nDELETE FROM public.session\nWHERE ctid NOT IN (\n    SELECT MIN(ctid)\n    FROM public.session\n    GROUP BY session_id\n);\n\nALTER TABLE public.session\nADD CONSTRAINT session_id_unique UNIQUE (session_id);\n
\n

至此，迁移工作结束

", "image": "/media/posts/113/umami-migration.BQWzMw30.png", "author": { "name": "AcoFork" }, "tags": [ ], "date_published": "2025-12-29T17:37:54+08:00", "date_modified": "2025-12-29T17:37:54+08:00" }, { "id": "/du-5202nian-liaohuan-you-ren-bu-hui-zi-jian-zi-ji-de-cloudflareedgeonedeng-ge-zhong-cdnde-you-xuan/", "url": "/du-5202nian-liaohuan-you-ren-bu-hui-zi-jian-zi-ji-de-cloudflareedgeonedeng-ge-zhong-cdnde-you-xuan/", "title": "都5202年了，还有人不会自建自己的Cloudflare/EdgeOne等各种CDN的优选？", "summary": "基本思路 想要做一个优选域名，我们首先需要筛选那些质量好的IP…", "content_html": "

基本思路

\n

想要做一个优选域名，我们首先需要筛选那些质量好的IP

筛选到质量好的IP后，通过各大云解析DNS厂商更新指定优选域名的DNS解析

最后，将你的域名投入使用，测试优选后效果

如何筛选到质量好的IP？

\n

假设你要提高国内的访问质量，我们肯定需要国内的机子，如果自家有NAS就再好不过了

如果你想要三网都优选，那么只有你一台机子是不够的，需要同时拥有电信，移动，联通三网的机子去做IP筛选。如果你要做更高级的地域优选，那就…把每个省的三网机子都拿到手？

有了测试机，接下来我们就需要编写测试脚本

首先我们要知道一个CDN厂商的IP段是什么，这里以Cloudflare为例

我们搜索 Cloudflare IP段 即可找到

\"\"

对于其他CDN，他们可能并没有直接在网页上公开IP，你需要自行寻找客服咨询

我们得到IP段后，接下来就是编写实际的测试逻辑

我这边仅推荐通过Curl+Resolve实现强制绑定IP访问业务域名然后看返回的状态码正不正常。

注意，这种方案及其考验您的测试机、路由器、ISP、对端服务器的性能！

但这也是最稳妥的测试方法，主播已经见过了太多TCPing 443通，https访问418或者ping得通，TCPing不通的稀奇古怪CDNIP。请保证您的测试方法筛选到的IP能正常访问到您的访问，避免您的服务宕机

线程不必拉太高，针对于Cloudflare这样有 150w IP的CDN，我们可以仅测试C段，也就是测试完 104.18.91.0 直接测试 104.18.92.0 这样可以节省时间，只需要测5000多个IP

最终，我们得到了一组优选IP

对接华为云云解析DNS

\n

为什么推荐华为云？

无他，因为仅华为云一家支持单解析单次记录值支持50个IP、可以创建多个同名解析以及支持仅缓存DNS解析1s（TTL=1）

受益于华为云的这些功能，我们个人用户也可以做到一个域名下面绑定几万个IP（虽然IP不是越多越好）

推荐使用海外版，不需要实名认证

之后通过API文档自行折腾一下API添加DNS解析即可

后期维护

\n
    \n

  1. 如果你要做三网优选请添加一个默认解析线路，保证您在个别线路宕机时对应线路的用户不会遇到服务宕机

    2. \n

  2. 每个CDN厂商的IP段可能会不定时变更，请勤查多看，及时更换失效IP

    3. \n

  3. 如果遇到服务异常无法得到优选IP，请不要在脚本中编写危险逻辑，如删除所有解析。这会导致大批量服务宕机

    4. \n

  4. 优选并不是主流做法，如果您的站点被攻击，使用自定义CNAME或者IP会导致您的CDN服务商无法为您进行IP调度，高质量IP将被持续攻击，您的CDN服务商可能会采取强制措施如：关停您的业务，封禁您的账号等操作来隔断对方的攻击。当您认为您的站点被攻击时请及时切换到官方为您分配的CNAME或IP

    5. \n
\n", "image": "/media/posts/101/5df07ad0-01cd-4541-9321-b0ded148a90f.C_a60OcQ.webp", "author": { "name": "AcoFork" }, "tags": [ ], "date_published": "2025-12-29T17:30:00+08:00", "date_modified": "2025-12-29T17:30:00+08:00" }, { "id": "/wan-quan-mian-feicong-jia-goukai-fa-dao-bu-shuyi-tiao-long-shi-da-shi-de-jiao-ni-zuo-yi-yansui-ji-tu-deng-sui-ji-urlde-zui-jia-shi-jian/", "url": "/wan-quan-mian-feicong-jia-goukai-fa-dao-bu-shuyi-tiao-long-shi-da-shi-de-jiao-ni-zuo-yi-yansui-ji-tu-deng-sui-ji-urlde-zui-jia-shi-jian/", "title": "完全免费！从架构，开发到部署，一条龙实打实的教你做一言/随机图等随机URL的最佳实践", "summary": "探索架构 我们先不讲一个抽象的概念，我们首先来做一个小项目…", "content_html": "

探索架构

\n

我们先不讲一个抽象的概念，我们首先来做一个小项目

一个随机图API，每次请求都返回不同的图片

你会怎么做？

有非常多的解决方案，就拿最简单的一说，我们可以先搞来一个服务器，然后往里面塞图片，最后写一个脚本创建一个Web服务器，接收客户端请求，每一个请求都从图片库里抽一张图返回

能实现吗？

当然可以！这是你的流程图！\n

\"\"
\n但也会带来一些问题，比如，图片存在本地，给客户端响应图片的时候走的是你机子的流量，那么你就需要一个 高带宽 的服务器，这无疑是一个 高昂 的成本

那可能你会有新的方案： 前后端分离 （逻辑与资产分离），只将返回这个图片的逻辑存放在服务器上，而图片存到其他地方，如对象存储（Cloudflare R2）、IPFS等等\n

\"\"
\n那么问题又来了，假如说你的项目太多人用了，那你的服务器性能可能不够，在后期，你仍然需要一个 高昂 的 维护成本

那么那么那么，现在是 2025 年，传统的架构已经无法满足我们了，我们不妨可以试试 云函数 \n仍然是前后端分离，我们现在将逻辑放到一个函数上面，如Cloudflare Worker、EdgeOne Function、Vercel Function等等\n

\"\"
\n那么现在是不是无敌了？

并非，虽然前端因为使用了 云函数 也就是直接接入了CDN，高并发已经不是问题了，但是由于资产并不直接托管在 云函数 中，云函数 仍然需要创建一个长连接从你的后端，如对象存储获取图片，这样一折腾，你的服务可能并不算快

有人就会说了，那既然现在我都把我服务器丢了，前端在云，后端也在云，为什么不直接让前端的云直接存储后端的资产呢？

当然可以！你已经非常接近最佳实践了！

绝大部分 云函数 都支持动静结合，也就是支持你在他们的云存放一些动态脚本，再顺便 存放静态资产

那么接下来，你就得到了一个完全不需要你买服务器托管，也不需要你担心存储爆仓导致天价账单的随机图…了吗？

\"\"

探索随机图（随机URL）的本质

\n

我们刚刚只是在抽象的说明某种架构 好像 可行，好像 又有什么问题，然后又有一种什么新思路 好像 可以解决这个问题

但我们要走的路才刚刚开始，我们不妨思考一下，随机图，又或者说随机URL这类项目，服务器（如果有）究竟发送了什么给客户端，客户端又对服务器发回的报文执行了什么动作

你肯定知道，如果想要客户端每次请求同一个URL，都返回不同的东西，那肯定是服务器针对每一个请求都返回了不同的响应，它可以是内部的，比如直接在响应体塞图片，又或者也可以是 重定向

直接在响应体塞图片很简单，在客户端是不可见的，当客户端请求API时，服务器直接将选中的图片作为响应体发出，在客户端看来，就好像是请求了一张图片，只不过每次刷新都不一样

而响应 重定向 就更简单了，只需要让服务器发送一个 临时重定向 的状态码，比如 302

有人就会说了，为什么必须要 临时重定向 ？

因为你肯定是想要客户端每次刷新都返回不同的图，一旦你使用了 永久重定向 如 301 ，客户端在收到 301 的那一刻就会在浏览器里写一个记录：下次访问这个URL直接重定向，不再请求服务器 ，这就会导致你的随机图API真的就变成一张图片了

那么，这两种方法哪种更好呢？

各有利弊，一句话说明：直接返回MIME类型是连请求复用，仅需一次请求即可得到图片。而返回302重定向至少需要客户端请求两次

这得看你的实际架构，如果说你是前后端分离，即逻辑和资产不在一个地方，肯定是 302 好，因为如果你直接在响应体塞图片，就相当于你的服务器作为 代理 让客户端访问你的资产，流量全部走你服务器

而如果说你前后端都在一起，正常情况下来说，一次请求复用肯定是比两次连接更快的，不过为了方便管理和统计，我的大部分API仍然使用 302 重定向

::github{repo=”afoim/EdgeOne_Function_PicAPI”}

上线的API： https://eopfapi.acofork.com/pic?img=ua

奇技淫巧1：利用Cloudflare Origin Rules实现无计费的随机URL

\n
\n

Video: https://www.bilibili.com/video/BV19ZBzB8EDQ/\n起因于有一天一位粉丝在我视频下留言\n

\"\"

\n

他提到的仓库为

::github{repo=”Mabbs/cf-hitokoto”}

大致为，Cloudflare在规则提供一个方法，该方法可以在规则层生成一个UUID，而UUID每次都是随机的，我们可以依据此来在规则层做随机URL

理论可行，实践开始

首先，我们要知道UUID是一串带有连字符的随机数，而每一位有16种可能，我们可以仅截取前4位，也就是 16^4 ，共能存储65536张图，每一张图可以分配到一个唯一的UUID，接下来让CF边缘在收到请求的时候，生成UUID，然后直接拼接URL请求静态资产，如 /img/0000.jpg ，再返回给客户端即可

那如果说我图比这多呢？加一位，16^5 = 1048576，够用了吧\n那如果说我图比这少呢？那我们可以让图片填充，说个极端的例子，假如你只有2张图，每张图创建32768个副本即可，依此类推

\"\"

::github{repo=”afoim/cf-rule-random-url”}

上线的API： https://img.072103.xyz/h | https://img.072103.xyz/v

奇技淫巧2：丢掉后端，让前端JS自己拼URL

\n
\n

Video: https://www.bilibili.com/video/BV1tNB4BEEaE/ \nVideo2: https://www.bilibili.com/video/BV1mMBKBREkB/

\n

把思路打开，我们真的需要一个 请求一个端点，返回一个随机内容 的东西吗

如果只是想在我们的网站上用上随机图，那是不是可以让客户端JavaScript代劳呢

大致原理为编写一个客户端JS，生成一个随机数，然后拼接URL得到最终的随机图，然后寻找需要替换为随机图的img容器或者背景图容器，替换其中内容

\"\"

::github{repo=”afoim/Static_RandomPicAPI”}

上线的 API： https://pic.acofork.com

总结

\n

我们共探索了三种流派

\n", "image": "/media/posts/91/random-url-gen.DjmmacBb.png", "author": { "name": "AcoFork" }, "tags": [ ], "date_published": "2025-12-29T10:40:00+08:00", "date_modified": "2025-12-29T17:23:54+08:00" }, { "id": "/wtfzhi-jie-jiang-umamibu-shu-dao-edgeone-pagesreng-diao-vpszhi-jie-pao-zai-yun-han-shu/", "url": "/wtfzhi-jie-jiang-umamibu-shu-dao-edgeone-pagesreng-diao-vpszhi-jie-pao-zai-yun-han-shu/", "title": "WTF？！直接将Umami部署到EdgeOne Pages？扔掉VPS！直接跑在云函数！", "summary": "原理探寻 由于…", "content_html": "

原理探寻

\n

由于 Umami 使用的是 SSR ，我原以为EdgeOne Pages不支持该模式，尝试部署后发现最大的问题在于

Error: SSR functions package size exceeds 128MiB limit (157MiB)\n
\n

也就是说，EdgeOne Page是支持SSR程序的，只是Umami构建后的函数太大了，那么我们的思路就很清晰了，只需要裁切一些代码即可

那么该项目就应运而生了 afoim/umami: Umami is a modern, privacy-focused analytics platform. An open-source alternative to Google Analytics, Mixpanel and Amplitude.

我将Umami v3中的无关紧要的东西，如 像素统计 链接统计 团队 地理位置文件 删去了，最终可以在EO上部署一个残血版的Umami

至于数据库，我用的是 https://supabase.com/ 需要注意，连接方式不能用 Direct Connection\n

\"\"

Demo： Umami

视频： https://www.bilibili.com/video/BV1JiqSBaEY1/

唯一的缺陷，无法获取用户地区（原逻辑有个高达60M的本地Geo文件）\n

\"\"

上手部署

\n
    \n
  1. Fork 该仓库 afoim/umami: Umami is a modern, privacy-focused analytics platform. An open-source alternative to Google Analytics, Mixpanel and Amplitude.
    2. \n
  2. 连接到EdgeOne Pages，但先别点部署
    3. \n
  3. 填写环境变量 DATABASE_URL 从Supbase中拿，类似于 postgresql://postgres.kupggtyqiaepzvjqbboy:[YOUR-PASSWORD]@aws-1-ap-northeast-1.pooler.supabase.com:5432/postgres
    4. \n
  4. 绑定你的域名，访问并登录。用户名： admin | 密码：umami
    5. \n
\n

疑难解答

\n

内部重定向貌似出了问题，如果你想要访问设置更改你的管理员密码请手动前往 /settings/preferences

", "image": "/media/posts/37/eo-umami-1.CDFklV02.png", "author": { "name": "AcoFork" }, "tags": [ ], "date_published": "2025-12-22T16:32:00+08:00", "date_modified": "2025-12-29T16:32:56+08:00" }, { "id": "/ben-zhan-zao-shou-liao-jian-zhan-yi-lai-gui-mo-zui-da-de-yi-ci-ddosgong-jizong-liu-liang-665tbfeng-zhi-shun-fa-195gbs/", "url": "/ben-zhan-zao-shou-liao-jian-zhan-yi-lai-gui-mo-zui-da-de-yi-ci-ddosgong-jizong-liu-liang-665tbfeng-zhi-shun-fa-195gbs/", "title": "本站遭受了建站以来规模最大的一次DDoS攻击，总流量6.65TB，峰值瞬发1.95GB/s", "summary": "引言 本站建站初使用…", "content_html": "

引言

\n

本站建站初使用 静态 架构就是防止别有用心之人进行DDoS

你想啊，一个静态网站，所有攻击流量都是打在 CDN的边缘节点 上，也就是等于攻打 整个CDN厂商

一是很难打死，二是没必要，毕竟静态网站的背后没有源站，也不涉及利益，纯粹是白打

但在昨天，就有位神人试图攻打 EdgeOne/ESA 并且还真给他打死了，待我娓娓道来

如果你就是那位神人，请联系我，我给您颁个奖

初见端倪

\n

于 2025年12月16号 11:13，我在和我的朋友测试项目的时候，有一个知识点他忘记了，我提议他前往我的博客查看，却被告知博客访问报 570 状态码

我立即使用 https://itdog.cn 测试了我的博客网站 https://af-archive-publii.pages.dev 发现大部分节点都为 570 状态码\n

\"\"
\n因为当时我的网站部署在 EdgeOne

随后，我向腾讯客服求证，了解到该状态码是一个 单节点限频访问 的状态码\n

\"\"

我的朋友甚至还在调侃说： 你网站🔥了 \n

\"\"

但是事情貌似还有一些诡异，为什么海外都是 200 OK ？

我开始怀疑被打了\n

\"\"

可能玩静态久了，没有第一时间上到 EdgeOne 查看请求数和流量，想着都是静态，谁没事打呢

然后我就回家，暂时切了一下逻辑

\n

切完后逐步好转，虽然速度有些慢，然后我就睡觉了

茅塞顿开

\n

睡醒后我越想越奇怪，于是就登上了 EdgeOne Pages 控制台，然后一看，我嘞个大雷\n

\"\"
\n
\"\"
\n
\"\"
\n
\"\"

随后我抱着好奇的心态想看看ESA防御咋样，没想到刚切过去阿里云就给我发消息了\n

\"\"

于是…\n

\"\"
\"\"

依旧是熟悉的印度尼西亚\n

\"\"

那没招了，随后我于10分钟内极速 完全切到Cloudflare Pages \n

\"\"

目前来看 Cloudflare Pages 也挺绿的\n

\"\"

最后发了一个被打的B站视频，然后得知

我去！大手子来了！ \n

\"\"

赛后总结

\n
\"\"
\n
\"\"

本站遭受了建站以来规模最大的一次DDoS攻击，总流量6.65TB，峰值瞬发1.95GB/s

目前 acofork.com 域名所有主要业务重定向为 2x.nz ，所有业务采用 Cloudflare CDN

如果各位大牛有防御方案/缓解措施，欢迎留言！

", "image": "/media/posts/29/ddos-6t.Dt5VcSYu.png", "author": { "name": "AcoFork" }, "tags": [ ], "date_published": "2025-12-16T16:07:00+08:00", "date_modified": "2025-12-29T16:07:56+08:00" }, { "id": "/xiang-yao-yi-ge-ni-ming-wen-jian-shang-zai-qiyi-xing-ming-ling-zhuang-hao/", "url": "/xiang-yao-yi-ge-ni-ming-wen-jian-shang-zai-qiyi-xing-ming-ling-zhuang-hao/", "title": "想要一个匿名文件上载器？一行命令装好！", "summary": "安装 确保你安装了…", "content_html": "

安装

\n

确保你安装了 Python

安装 uploadserver

pip install --user uploadserver\n
\n

接下来，创建并进入一个新文件夹，作为 上传目录

mkdir upload\ncd upload\n
\n

运行，并监听 IPv4 的 8000端口

python -m uploadserver 8000\n
\n

又或者，监听 IPv6 的 8000端口 

python -m uploadserver --bind :: 8000\n
\n

接下来，你就可以在内网环境使用这个 文件上载器 了\n

\"\"

再然后，我们就可以将其打到公网了

打到公网

\n

方案一：使用EdgeOne进行IPv6回源

\n

将你的IPv6做 DDNS ，然后使用EdgeOne回源\n

\"\"

方案二：STUN（仅NAT1可用）

\n

当你的家庭网络为 NAT1 ，则可以使用类似这样的软件将你的 内网端口 直接打到 公网端口 （貌似该程序对TCP分片敏感，会导致RST） MikeWang000000/Natter: Expose your TCP/UDP port behind full-cone NAT to the Internet. \n

\"\"

", "image": "/media/posts/88/83e64b93c9f130785f89ccbcd60a7844.Dp66EG2k.png", "author": { "name": "AcoFork" }, "tags": [ ], "date_published": "2025-12-11T17:21:00+08:00", "date_modified": "2025-12-29T17:21:48+08:00" }, { "id": "/shang-shou-mi-ha-you-airan-hou-ba-ta-ni-liao/", "url": "/shang-shou-mi-ha-you-airan-hou-ba-ta-ni-liao/", "title": "上手米哈游AI，然后把它逆了！", "summary": "这是What 这是橘猫，会哈气（见封面…", "content_html": "

这是What

\n

这是橘猫，会哈气（见封面

你可以前往 AnuNeko 逗猫

逆！

\n

okok，注意到登陆后的请求头中有 x-token 字段\n

\"\"

手搓个请求发发，data 携带内容 

curl --location 'https://anuneko.com/api/v1/msg/会话id/stream' \\\n--header 'x-token: 账号Token' \\\n--header 'Content-Type: text/plain' \\\n--header 'Cookie: 自动拿取' \\\n--data '{"contents":["test"]}'\n
\n

通了\n

\"\"

然后还有一种情况，在遇到Pick的时候，我们要发送要选择的回复编号\n

\"\"

发个如图请求帮橘猫选择

curl --location 'https://anuneko.com/api/v1/msg/select-choice' \\\n--header 'x-token: 你的Token' \\\n--header 'Content-Type: text/plain' \\\n--header 'Cookie: 自动拿取' \\\n--data '{"msg_id":"会话id","choice_idx":0或1}'\n
\n

还有还有，这有个橘猫和黑猫，如何切换一个会话的猫？

curl --location 'https://anuneko.com/api/v1/user/select_model' \\\n--header 'x-token: 你的Token' \\\n--header 'Content-Type: text/plain' \\\n--header 'Cookie: 自动拿取' \\\n--data '{"chat_id":"会话id","model":"Exotic Shorthair或Orange Cat"}'\n
\n

随便写了个适用于NoneBot2的插件，玩吧\nAnuNeko_NoneBot2_Plugins/anuneko.py at main · afoim/AnuNeko_NoneBot2_Plugins

", "image": "/media/posts/9/anuneko.sdPL8HoA.png", "author": { "name": "AcoFork" }, "tags": [ ], "date_published": "2025-12-02T15:47:00+08:00", "date_modified": "2025-12-29T15:48:02+08:00" }, { "id": "/pan-dian-na-xie-hao-yong-de-serverlessyun-han-shu/", "url": "/pan-dian-na-xie-hao-yong-de-serverlessyun-han-shu/", "title": "盘点那些好用的Serverless（云函数）！", "summary": "何为Serverless 就像简介所说，传统来说我们搭建Web服务一般会选择买一个VPS，然后在其上安装管理面板，再安装所需软件，如Nginx，AList，最后运行，开放端口，再设置DNS解析，这样，一个网站就成功上线了…", "content_html": "

何为Serverless

\n

就像简介所说，传统来说我们搭建Web服务一般会选择买一个VPS，然后在其上安装管理面板，再安装所需软件，如Nginx，AList，最后运行，开放端口，再设置DNS解析，这样，一个网站就成功上线了

而Serverless就简单多了，毕竟 Server 被 Less 掉了

这又是什么意思呢？在Serverless服务里，你不再需要管理传统的VPS，而是直接将业务代码上传到目标平台，再由平台的CI/CD自动部署你的服务

举个不恰当的例子就比如你正在观看的这个 博客 ，首先我将源码上传到 边缘安全加速平台 EO Pages_腾讯云 ，再经由平台构建出最终的HTML页面，然后再在平台上绑定域名，直接访问就可以了

不难看出，在上一个例子中，我并没有去从零开始搭建这个服务，而是仅做了两件事：1. 源码上传 2. 绑定域名，而其他事情全部交给平台的自动化，这不仅极大减少了运维成本，并且在做版本控制的时候也更加容易

Serverless的利与弊

\n

在Serverless中，你不再需要管理基础设施，只需要确保你的代码能跑，然后直接上传到平台，平台会帮你做好后续工作

并且，这往往是 免费 的，或者说，大部分Serverless平台都有 免费层 。因为在平台看来，你只是租用了你所需要的东西，相比于哪些大客户，你的开销可以说是忽略不计

并且在Serverless中，你永远只是用户，但是如果你买的是VPS，一般来说你是可以完全控制这台VPS的，如设置防火墙，或是重装系统，而这种代价是高昂的，这也是为什么你能看到许许多多免费的Serverless服务，但是几乎看不到免费的VPS提供商

但这也有一些弊端，Serverless往往有严格的用量限制，在传统的VPS中，往往IDC会限制你的 最大带宽、公网IP 和 总流量 ，但是在Serverless中，往往只会限制你的 总流量 ，但可能还会有一些限制，如：CPU最长执行时间 、总请求数 、函数总请求数 、函数最长执行时间 等等等等

因为当你在用Serverless的时候，你的服务直接跑在其平台的CDN上的，你将直接享有所属平台的CDN IP段以及带宽，这也让平台的管理更加方便，不需要大量购入物理机开虚拟机做VPS，只需要做一个小集群并做好用户分配即可

Serverless也比Server更容易做版本控制和Debug，由于Serverless和Git是天生一体的。在用户看来，只需要先将代码托管到Github，再将代码库连接到Serverless平台，此后，你的服务每一次更新就只需要更新源码了，平台会自动帮你构建。当你想要回滚版本的时候，直接将部署回退为之前的提交即可，而Debug无需再连到服务器上做，只需要有一台电脑，将代码拉下来，本地Dev Debug后，再将修复后的代码提交，平台就能自动部署了

好用的Serverless平台

\n

边缘全栈开发平台 - EdgeOne Pages

\n

:::caution\n请不要在其上部署日流量超 10M 的服务，很有可能会被停用账号\n:::

支持原生JS和Node Function，如果你的项目是基于Node打造的，仅需修改一下函数出入口即可无缝迁移。并且目前的 Pages Function 是 不计请求也不计费 的，非常适合部署一些仅自己用的服务

不过其自带的构建服务性能较低，上线速度可能稍慢

示例服务： 自建一个匿名文件上传终结点 - AcoFork Blog

Vercel Functions

\n

支持非常多的语言，如 Node.js、Python、Go、Wasm 等等。构建服务非常强劲！默认分配 4C8G 帮你构建！

用量限制非常宽松，并且可以超过限制的 2倍 以上仍保持正常访问\n

\"\"
\n示例服务： 来！让我们用Vercel来分享你的OneDrive！ - AcoFork Blog

Netlify Functions

\n

支持 JS/TS 和 Go。用量限制更宽松！仅限制每个月100G传输流量，但是一旦超限，即刻宕机

示例服务： https://nf-gh.072103.xyz/afoim

Cloudflare Workers | 利用易于使用的开发工具构建和部署代码 | Cloudflare

\n

支持众多语言，但是对JS/TS的支持最好，特别注意不支持完整的 Node.js 环境。Python目前无法通过pip安装包。优点在于可以和更多Cloudflare产品做协同，如Cloudflare R2 对象存储、Cloudflare KV 键值对存储、Cloudflare D1 SQL数据库

每天限制 10W 请求，但是超了并不会 始终返回 不可用，而是 可能会请求错误

示例服务： 你可曾想过，直接将BitWarden部署到Cloudflare Worker？ - AcoFork Blog

Hugging Face – The AI community building the future.

\n

:::caution\n请不要在其上部署 AList ！秒封！\n:::

严格意义上来说，这是个帮你跑AI大模型服务的平台，但是由于它支持跑 Docker ，可玩性还是很高的

不过访问链接需要你拼一下： https://用户名-Space名.hf.space/

示例服务： 网易云音乐工具箱

ClawCloud Run | Build, Deploy, Manage & Run in Cloud-Native Platform

\n

之前被干爆过，目前亚太爆炸，每个月有 5 美元 余额，直接跑Docker，按你分配的CPU核心数和内存来计费。不过 Hobby 计划还蛮便宜的，常用的话可以买\n

\"\"

Render

\n

\"\"
\n每月免费100G流量，支持非常多的服务，如：静态网站、Web服务（Docker）、定时服务、PostgreSQL数据库、Key Vaule存储

唯一的缺点，性能不高

Zeabur

\n
\"\"
\n每月免费5刀额度 ，免费计划有两个地域可选\n
\"\"

最重磅的在于你可以将自己的VPS托管给Zeabur，它会在你的服务器上安装k3s等服务，之后你就可以直接在Zeabur的仪表盘上进行运维了

最小服务器要求：2GB 内存，1 核 CPU。

\"\"

结语

\n

Serverless不像传统的VPS，你并不完全拥有它，所以有些服务是不能跑的， 特别是在免费层 ，如特别吃IO和网络的 AList ，或是并发请求特别高以及商用服务。如果你用的舒心，请考虑购买各大平台的付费版套餐

", "image": "/media/posts/103/serverless-function.CFyrMOuy.png", "author": { "name": "AcoFork" }, "tags": [ ], "date_published": "2025-11-25T17:30:00+08:00", "date_modified": "2025-12-29T17:31:17+08:00" }, { "id": "/chu-men-zai-wairu-he-you-yagao-xiaoliu-chang-di-yuan-cheng-zi-jia-dian-nao/", "url": "/chu-men-zai-wairu-he-you-yagao-xiaoliu-chang-di-yuan-cheng-zi-jia-dian-nao/", "title": "出门在外，如何优雅、高效、流畅地远程自家电脑？", "summary": "前言 你可能觉得，这人不是XX吗，远控当然下载个类似UU远程、向日葵这种软件不就行了，这还要出一篇文章？…", "content_html": "

前言

\n

你可能觉得，这人不是XX吗，远控当然下载个类似UU远程、向日葵这种软件不就行了，这还要出一篇文章？

那我问你，如果你用的电脑是32位而不是64位，当你用的公司网络NAT类型并不开放又或者没有IPv6？我们要如何优雅、高效、流畅的使用远程呢？

正式开始

\n

我们分两步走，一个是针对于64位的电脑，较简单，而另一个是针对于32位的电脑，稍微复杂

64位

\n

首先，将家里的路由器的 UPnP 功能打开，然后直接下载 网易UU远程官网_真4K、真免费、真好用 ，登录账号直接连接，绝大部分情况都是P2P（点对点连接，即控制和被控端直接连接）

32位

\n

由于UU远程仅支持64位的电脑，我们就要想点花招了

我用的办法比较极客，就是将家里设备的 RDP 端口打到公网上来，也就是利用 STUN ，但是这种方法要求家庭网络的NAT类型为1（Full Cone）

那么首先，我将家中的路由器的 DMZ 主机设置为家里电脑的IP\n

\"\"

DMZ启用后，所有打到路由器上所有端口（除路由器自身占用端口）的流量全部转发给DMZ主机

用人话来说，你访问路由器的3389端口就能直接访问到电脑的3389端口

这样设置之后，你就可以使用 STUN 协议，将路由器的3389端口转发到ISP给你分配的公网上

用人话来说，STUN后，访问你正在用的 公网IP:随机端口 ，就能访问到路由器的3389端口，又因为配置了DMZ，就又能访问到电脑的3389端口

那么如何简单的开一个 STUN隧道 呢？

我这里使用的是 MikeWang000000/Natter: Expose your TCP/UDP port behind full-cone NAT to the Internet. ，它是一个Python编写的程序，确保你的网络为NAT1后，你可以使用一个简单的命令，如： python natter.py -p 3389 来创建STUN隧道\n

\"\"

观察 WAN > 112.32.39.77:55265 [ OPEN ] 证明你已经可以通过该 公网IP:端口 来在世界各地，只要连上了 互联网 ，就能连上家里的电脑

最后，Win+R 调出运行，输入 mstsc 打开远程控制的窗口，开始你的远程之旅吧

\"\"
\"\"
", "image": "/media/posts/94/9207_112_29_106_130_rx7fsq.CvKU81NV.png", "author": { "name": "AcoFork" }, "tags": [ ], "date_published": "2025-11-24T17:25:00+08:00", "date_modified": "2025-12-29T17:25:32+08:00" } ] }