技术 on Colinx Blog

OpenClaw 虽好，搭配沙箱才安心 - 使用 Lume 构建 mac 虚拟环境

Wed, 04 Feb 2026 00:00:00 +0000

近日 OpenClaw(原 Clawdbot, 曾用名 Moltbot) 爆火，独立自主操控电脑完成各种任务，一个挺 fancy 的 agent 应用。结合 moltbook 网站的新闻，在各种媒体的鼓吹下故事画风变得愈发科幻，巴不得明天就统治全人类。

爆火没两天，就爆出不少安全新闻，要么是 agent 自作主张直接电脑删空，要么是大量小白用户把实例暴露在公网，别有用心的人可以直接通过 openclaw 的黑洞控制整个电脑。OpenClaw 这种应用最吸引人、最方便的地方在于 ta 可以成为「代理」, 去执行任何「你可以做」的事。你能做，ta 就能做。不过前提便是宽松的权限管理，超级多的权限。

下面介绍一个基于 lume 的 Mac OS 虚拟机方案，将其作为沙箱环境节点供 openclaw 调用。

OpenClaw Gateway 安装

由于 gateway 节点负责与各个 channel 即 bot 通信，最好有公网 ip, 这里我在 linux 云服务器上进行部署。

官方默认给的安装命令很简单，npm install -g openclaw 就可以了。但是为了安全起见我还是偏好使用 docker 容器。官方对 docker 容器的支持并不是很好，文档也有点混乱，实际测下来从代码库自行构建镜像比较好

首先是克隆仓库。注意默认的 main 分支可能不是很稳定，最好切换到某个 tag 或者 github actions 全部通过的 commit 再构建。

# 示例: 切换到指定tag
git pull --rebase
git fetch --tags
git checkout v2026.1.29

之后准备构建。很多教程包括官方文档是让用户直接在克隆后的 git 仓库里，修改 compose 和 env 文件。但是这样的话后续不方便更新，因为工作区有修改，每次都要 stash 再 pull 还要解决冲突的问题，太麻烦了。建议的方式是在代码库上级目录创建 compose 和 env, 这样下次要更新的话，直接到 repo 里面 git pull 再重新构建镜像就可以了。

目录结构如下：

.
├── .env
├── docker-compose.yml
└── **openclaw-repo**

compose 文件设置好构建的目录即可。示例如下

services:
  openclaw-gateway:
    image: ${OPENCLAW_IMAGE:-openclaw:local}
    container_name: openclaw-gateway
    build: ./openclaw-repo
    environment:
      xxx:xxx

准备好目录和 docker compose 之后，即可开始构建

完整 docker compose

services:
  openclaw-gateway:
    image: ${OPENCLAW_IMAGE:-openclaw:local}
    container_name: openclaw-gateway
    build: ./openclaw-repo
    environment:
      HOME: /home/node
      TERM: xterm-256color
      OPENCLAW_GATEWAY_BIND: ${OPENCLAW_GATEWAY_BIND}
      OPENCLAW_GATEWAY_PORT: ${OPENCLAW_GATEWAY_PORT}
      XDG_CONFIG_HOME: ${XDG_CONFIG_HOME}
      PATH: /home/linuxbrew/.linuxbrew/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
    volumes:
      - ${OPENCLAW_CONFIG_DIR}:/home/node/.openclaw
      - ${OPENCLAW_WORKSPACE_DIR}:/home/node/.openclaw/workspace
    ports:
      - "${OPENCLAW_GATEWAY_PORT}:${OPENCLAW_GATEWAY_PORT}"
      # - "${OPENCLAW_BRIDGE_PORT:-18790}:18790"
    init: true
    restart: unless-stopped
    command:
      [
        "node",
        "dist/index.mjs",
        "gateway",
        "--bind",
        "${OPENCLAW_GATEWAY_BIND:-lan}",
        "--port",
        "${OPENCLAW_GATEWAY_PORT}",
      ]
     
  openclaw-cli:
    image: ${OPENCLAW_IMAGE:-openclaw:local}
    environment:
      HOME: /home/node
      TERM: xterm-256color
      BROWSER: echo
      OPENCLAW_GATEWAY_BIND: ${OPENCLAW_GATEWAY_BIND}
      OPENCLAW_GATEWAY_PORT: ${OPENCLAW_GATEWAY_PORT}
      XDG_CONFIG_HOME: ${XDG_CONFIG_HOME}
      PATH: /home/linuxbrew/.linuxbrew/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
    volumes:
      - ${OPENCLAW_CONFIG_DIR}:/home/node/.openclaw
      - ${OPENCLAW_WORKSPACE_DIR}:/home/node/.openclaw/workspace
    stdin_open: true
    tty: true
    init: true
    entrypoint: ["node", "dist/index.mjs"]
    restart: none

env 示例

OPENCLAW_IMAGE=openclaw:latest
OPENCLAW_GATEWAY_TOKEN=change-me
OPENCLAW_GATEWAY_BIND=lan
OPENCLAW_GATEWAY_PORT=8089
OPENCLAW_CONFIG_DIR=/data/openclaw
OPENCLAW_WORKSPACE_DIR=/data/openclaw/workspace
XDG_CONFIG_HOME=/home/node/.openclaw


# 镜像中的应用默认以uid 1000账户运行, 手动设置data数据目录的权限避免出现预期外的问题
sudo chown -R 1000:1000 /data/openclaw
# 构建镜像
sudo docker compose build
# 第一次使用, 初始化相关配置
docker compose run --rm openclaw-cli onboard
# 之后启动gateway
docker compose up -d openclaw-gateway

如果使用 tg channel ,创建完 bot 后需要配对才可以使用。

docker compose run --rm openclaw-cli pairing approve telegram <code>

日常配置可以直接使用这个 cli 镜像后面加上需要的参数。或者直接到 Gateway 镜像中执行 node dist/index.mjs xxx 代替官方文档里 openclaw xxx . (官方 Dockerfile 里面对 cli 工具名字的处理有问题，先曲线救国)

docker compose run --rm openclaw-cli xxx

MacOS VM via Lume

接下来配置 mac os 的虚拟机。使用 lume 工具

brew install lume
brew services start lume

之后可以快捷安装 macos vm. 一般情况下，默认安装当前系统大版本下最新的小版本。你可以通过以下方式查询

# 查询`latest`参数对应默认的系统镜像和版本, 可以看到显示的url指向的系统版本为15.6.1
~ » lume ipsw                                                                         
[2026-01-31T12:23:12Z] INFO: Fetching latest supported IPSW URL
[2026-01-31T12:23:13Z] INFO: Found latest IPSW URL url=https://updates.cdn-apple.com/2025SummerFCS/fullrestores/093-10809/CFD6DD38-DAF0-40DA-854F-31AAD1294C6F/UniversalMac_15.6.1_24G90_Restore.ipsw
https://updates.cdn-apple.com/2025SummerFCS/fullrestores/093-10809/CFD6DD38-DAF0-40DA-854F-31AAD1294C6F/UniversalMac_15.6.1_24G90_Restore.ipsw
# 查询当前系统版本为15.2
~ » sw_vers                                                                           
ProductName: macOS
ProductVersion: 15.2
BuildVersion: 24C101

也可以从这里获取指定版本的系统镜像下载地址，手动下载。https://ipsw.me/. 一般 mac os 的镜像大小在 15-20GB

创建 vm

# 默认安装最新的版本
lume create openclaw --os macos --ipsw latest
# 如果失败报错"Installation requires a software update." 可以下载不高于当前系统运行的版本手动创建
lume create openclaw --os macos --cpu 2 --memory 8GB --disk-size 100GB --ipsw ./<YOUR-DOWNLOAD-IPSW-FILE>
# 启动vm
lume run openclaw

之后会输出一个 vnc 地址，可以用 mac 自带的「屏幕共享」app 进行查看。菜单「连接」- 「新建」

完成系统安装的几个必要步骤，然后到设置里把远程控制打开，后面 SSH 要用到。系统更新建议关掉。

![[image-23.png]]

![[image-24.png]]

在 mac vm 上安装 openclaw

# 基础环境配置
## brew 安装 (加速版本, 使用中科大镜像源)
export HOMEBREW_BREW_GIT_REMOTE="https://mirrors.ustc.edu.cn/brew.git"
export HOMEBREW_CORE_GIT_REMOTE="https://mirrors.ustc.edu.cn/homebrew-core.git"
export HOMEBREW_BOTTLE_DOMAIN="https://mirrors.ustc.edu.cn/homebrew-bottles"
export HOMEBREW_API_DOMAIN="https://mirrors.ustc.edu.cn/homebrew-bottles/api"
/bin/bash -c "$(curl -fsSL https://mirrors.ustc.edu.cn/misc/brew-install.sh)"
## brew 镜像配置
echo 'export HOMEBREW_BOTTLE_DOMAIN="https://mirrors.ustc.edu.cn/homebrew-bottles"' >> ~/.zshrc
echo 'export HOMEBREW_API_DOMAIN="https://mirrors.ustc.edu.cn/homebrew-bottles/api"' >> ~/.zshrc
echo 'export HOMEBREW_CORE_GIT_REMOTE="https://mirrors.ustc.edu.cn/homebrew-core.git"' >> ~/.zshrc
echo 'export HOMEBREW_BREW_GIT_REMOTE="https://mirrors.ustc.edu.cn/brew.git"' >> ~/.zshrc
source ~/.zshrc
## 安装基础环境
brew install node
brew install pnpm
pnpm setup
source ~/.zshrc
echo "registry=https://npmreg.proxy.ustclug.org/" >> ~/.npmrc
pnpm install -g openclaw@latest
openclaw onboard --install-daemon

client 端配置好 gateway 地址和 token .第一次连接显示需要配对。在服务端执行


openclaw devices list
openclaw devices apprve <复制的request id>

# 作为node注册
openclaw node install --host <gateway-host> --port 18789 --display-name "Mac mini"
# 然后在服务端approve
# 查看状态
openclaw node status
# 启动节点
openclaw node start

之后就可以让 openclaw 调用这个节点啦

THE END

Search-as-a-RSS! 把任何搜索查询转换为 RSS! FeedCraft 新功能速递

Mon, 22 Dec 2025 00:00:00 +0000

前言

作为 RSS 5 年忠实用户，我非常享受 RSS 主动管理信息源给我带来的掌控感。但是传统 RSS 订阅方式只能基于站点或者频道，更多时候我其实是想关注某一个特定领域信息，比如 AI 领域世界模型有什么新的新闻，或者是想订阅一个特定的信息，比如我关注的 xxx 歌手有没有新的巡演规划。

这些需求通过传统 RSS 方式难以实现，你只能定向的订阅某个新闻站点，然后过滤一下关键词。使用方式局限性很大。其实最理想的方式是直接把搜索引擎的结果拿来作为信息源。问题主要是噪声太多：

搜索查询一般是按照关键词来的，不够灵活
垃圾内容农场泛滥
高质量的信息很多时候是多种语言的网页，直接阅读会很困难

好在我们有了 AI, 很多问题有了新的解决方法。在 FeedCraft 新版本中，我新增了一个 Search-as-a-RSS 的功能，用户只需要使用自然语言指定好要搜索什么，接下来就可以自动根据搜索结果生成一个 RSS 了。

接下来简要介绍一下流程：

FeedCraft 如何通过搜索结果创建 RSS

FeedCraft 本身是一个一站式处理 RSS 的工具，这里的搜索需要依赖第三方服务。首发支持的搜索服务是 LiteLLM Proxy(一个 AI 服务的代理转发平台，开源可自部署，可以方便对接各种第三方搜索服务比如 Exa, Tavily, Plexirity, Perplexity, Brave 等等)

以 Tavily 为例，这个平台提供了每月 1000credits 的额度，可以执行上百次搜索，轻度使用绰绰有余了。前往官网注册个账号，生成一个 api key 即可。

Tavily 是一个专为人工智能代理（AI Agents）设计的搜索引擎，旨在优化 AI 在执行任务时的信息检索过程。它不同于传统的面向人类用户的搜索引擎（如 Google 或 Bing），而是专门为 AI 系统“理解”和“查找”所需信息而构建，强调高效、准确和上下文相关的搜索结果。

接下来到 LiteLLM 的后台，Tool - Search Tool 里面增加一个 search tool. 这里 search tool name 可以自定义，先记下来待会在 feed craft 的设置页面需要填入。

在 LiteLLM 后台生成一个 API KEY, Key Name 可以随便写主要是备注。这个生成的 api key 可以用于请求 LLM, 也可以调用刚才配置的搜索工具。确认生成后，复制 api key.

在 FeedCraft 后台，设置里面配置搜索服务，这里 API URL 是你的 LiteLLM 服务加上/search 后缀。例如你的 LiteLLM 服务部署在 https://my-litellm.example.com, 那么这里就填写 https://my-litellm.example.com/search . 工具填写刚才在 LiteLLM 后台接入 Tavily 的时候填写的 search tool name

之后在「搜索转 RSS」页面，输入你想查询的东西即可。你可以直接用自然语言描述，比如「SpaceX 的最新新闻」. 之后点击下一步即可预览搜索结果。

你可以按需调整搜索语句。确认没问题一直下一步，可以保存为自定义的配方 (Custom Recipe) , 就可以生成一个唯一的 RSS 链接，在你喜欢的任意 RSS 阅读器里面查看啦

更进一步，你可以使用 FeedCraft 的各种 Craft 来做进一步的处理。比如获取全文，添加总结、翻译文章、以及调用 AI 使用自然语言对文章进行筛选等等

总体功能就是这样啦，欢迎试用 FeedCraft 和 Star 🌟! Have fun!

https://github.com/Colin-XKL/FeedCraft

LLM Agent is All You Need - 让 AI 指导我完成 MVP 产品 - 「Colin's Weekend Project」

Sun, 14 Sep 2025 00:00:00 +0000

「Colin’s Weekend Project」 我个人喜欢挑一个周末在一个很短很专注的时间内，捣鼓点小玩意。这个栏目用来记录我的这些 idea、作品、创作过程以及吐槽

今天来挑战一下，在大模型的指导下，完成一个最小可行产品 (MVP)

idea

如果单纯是开发一个完整的 web 程序 or 移动端程序，其实没啥意思。我之前已经搞过很多，更别提日常在公司里面就是在开发各种功能。今天我打算以一个非专业人士的视角，探究一下：

当下各种 AI 助手已经百花齐放，飞入寻常百姓家。但是当下的 AI 在真实世界的任务中，究竟能做到什么地步
如果作为一名非专业人士，究竟能不能借助这些 AI 工具做出一个可用的产品
如果真正要做一个面向 C 端的产品，把流程 Run 起来持续下去，需要考虑哪些因素

如果一切都从 LLM 开始…

我需要代入一个非专业开发人员的视角，来进行这次的项目。首先项目启动的第一个问题：在没有任何产品经理的知识，不懂得产品开发流程的小白的情况下，我需要如何开始？

在没有 LLM 以前，或许我需要先各种查阅资料学习，或者各种摇人让懂行的朋友进行指导。但是现在，一切都不一样了：随便一个 LLM 都可以帮我快速入门

一开始，我是打算接住 LLM 让我快速了解产品相关的知识。但是突然觉得，既然都用 AI 了，为什么还在遵循原有的路径，一步步自己学习、理解然后教 AI 做事呢？换个思路，我只要提供需求，AI 来拆解任务。

于是

利用 AI 生成一套提示词，来指导我如果分析我的需求、拆解任务

不得不说，对于这些跨领域的知识，能有一个不厌其烦的 AI 助手来循序渐进地跟你交流、帮你分析，效果非常好。人类可能还真不好干这个活。

「AI 教我做产品」

经过跟这个「MVP 导师」的 LLM Agent 反复沟通，确定了产品的主要构想和核心事项。以下是摘录的一部分

#### MVP 概要（3 句话）

- **为谁**：20‑30 岁、周末感到无聊且有意愿尝试新事物的年轻人。
- **解决什么痛点**：不清楚该尝试哪些活动、如何快速入门、活动是否适合自己、以及能获得什么收益。
- **提供的核心功能**：活动列表页面 → 点击感兴趣的活动 → 展示入门门槛与材料推荐（入门材料按钮）并埋点上报。

## MVP 核心功能：
 1. **活动列表**：集中展示多种可入门活动（绘画、球类、手工等）。
2. **入门详情**：点击任意活动 → 展示入门门槛、必备材料、推荐教程链接。
3. **埋点追踪**：记录“点击 → ≥1 min 外部阅读 → 回站”行为，用于验证假设。

这里印象深刻的是，MVP 导师让我先确保用户痛点一定要是真实的，在初期没有论证的情况下，MVP 的意义就在于基于一个假设 (假设用户的痛点是 xxx), 我们要围绕这个痛点先开发出 1-2 个核心功能，然后通过用户数据分析，来验证我们关于用户痛点的假设是否成立。如果不成立说明是伪需求，也就没有继续投入的必要了。

这一点还是让我挺惊喜的，因为大部分人有个 idea 想做 xx 产品，大部分都是脑门一热，想要有 xxx 功能但是其实根本的需求并不是这个。花了很多精力搞出来的功能其实是伪需求。而 AI 导师专业水准还是挺在线的，能够在一开始就识别这个风险

Vibe Coding

接下来就是要进入开发的部分了。我选择的 AI 代码工具是字节的 Trae 海外版，不用验证手机号而且可以使用 Google Gemini、OpenAI GPT-4o、Anthropic Claude 4 等高级模型。

首先让 AI 根据产品需求文档、拆解任务文档，确定了技术方案。不过这里我为了效率简化了下&注入了一些自己的私房调料，最终使用的方案为：

astro + vue3 + tailwind css 来构建 web 站点
directus cms 作为后端，省去编写后端和对接数据库的麻烦
vercel 快速部署

这部分没啥好说的，简单列几个吐槽的点吧：

astro 配置 tailwindcss, 换了一圈大模型没一个正确的。应该是跟近期大版本更新有关系。最后还是我手动跟着 astro 官方的文档搞定的
trae 高级模型试用额度很低，没写几个功能就超限了开始排队，动不动前面几百号人基本没法用
现阶段 AI IDE 基本都是基于 vs code 改的。所以 vscode 的缺点也都一并继承了过来，很多语言的插件需要额外手动安装、各种变量跳转用不了、各种奇怪的波浪线报错又没法快速修正

最后简要看下最终的成果吧

后台数据：

埋点上报与用户行为分析

之前做的都是玩具项目和公司内部平台，没怎么接触过 C 端用户行为分析。这块确实还是个挺陌生的领域。不过好在我们有万能的 AI. 在经过埋点需求分析、技术方案对比、任务拆解之后，最后采用了 Umami 平台来进行上报，并简单配置了下指标用于计算用户停留，辅助验证我们关于用户痛点的假设

跟 MVP 导师沟通的时候，确定了验证假设的方式为：衡量用户是否点击「查看详情」按钮

用户点击并在外部阅读 ≥ 1  分钟后回站
成功阈值：≥ 25 % 的访问者完成“点击 → ≥ 1 min 回站

为了方便统计，借助 umaimi 的统计功能快速实现，我只需要统计有多少比例的用户至少点击了一次「了解详情」. 具体到代码实现上，就是在「点击详情」按钮添加一个上报，上报内容包括用户的 session id, 后面在 umaimi 统计一段时间内，按钮点击事件里面，有多少独立的 session id 处以总的 uv 就可以。

投放

众所周知，天朝桌面端 web 用户已经约等于 0 了，技术博客都很少人看，更别提这种泛娱乐向的内容。MVP 导师提供的方案，也是路线正确，但是 web 端用户数据反馈验证的路子基本没用。不过这个 web 页面我也不指望能成为流量主力，最多算个 wiki.

要想真的有人看，收获真实用户反馈，还是需要到各种新媒体平台去投放的。然后再收集数据进行分析，不过这个工作量就是另外一回事了。运营起来还是需要挺多时间精力的。

尝试做了几个图投放到小红书，放几个示例图

用的搞定设计的模版调整了下，插图是用 Gemini, 效果还可以，能很好地遵循用户指令，不过美学方面跟 MidJourney 那些还是差了一截，毕竟人家专攻的方向。提示词里面限制好风格的话出图效果还是可以的，这里后续如果有必要的话，其实也可以 AI 批量生产插图。

不过小红书账号冷启动，反响平平。这里后续有时间再研究吧

The End

安全不是特权 - 雷池 WAF 使用体验及部署安装教程

Mon, 18 Dec 2023 00:00:00 +0000

自从开始倒腾服务器，部署各种各样服务以来，网站安全一直是那个令我焦虑的一个话题。暴露了那么多服务在公网，总免不了有无聊的人或者别有用心的人在搞事。(当然也有可能不是人类 hhh) 之前也有几次被攻击的历史，比如阿里云控制台一堆 SSH 爆破攻击记录，还有 Wordpress 被攻陷，出现一堆奇怪的文章和评论。虽然损失不是很大，但是处理起来还是有点麻烦的。(被攻击之后学乖了，老老实实定期备份) 况且我在明敌在暗，我们总是处于被动的那个，时间一长，网站的风险和潜在的损失还是不小的，最好是可以有一些防火墙和策略能够拦截点大部分不友好的请求。

很早以前就有调研过世面上的网站防火墙类产品，主要就几种类型：

各大云厂商配套的 WAF, 不过收费都很贵
Cloudflare 等 CDN 服务商提供的服务，不过必须要接入其 CDN 反代才能用。而且大陆地区联通性并不好
ModSecurity 等开源方案，开源免费可自托管，不过配置比较麻烦，而且没有好用的 web 页面

近期刚好关注到雷池 WAF 这个项目比较火，看了下是国内一个安全公司搞得，看 Github Repo 和官方文档像模像样的，虽然文档跟大多数中文项目一样，很多地方写的不够清晰，一些小细节没有跟最新的版本同步，但是总体而言，可用，不难用。值得一试

使用体验

谈一谈我为什么选择使用雷池 WAF:

免费，开源 (这点存疑，没有详细审计过所有 submoudule, 目前看起来只有部分开源，仓库里大部分都是文档啥的。不过有有安全厂商实名，应该不会做出来一些自毁招牌的操作)
支持通过 docker compose 自部署
功能够用。基本反代站点配置，SSL, 多种规则的黑白名单，频率限制，人机验证，攻击历史看板

目前已经使用了有几个月了，来谈一谈一些个人感受

优点：

又要免费，又要能自部署，又要有方便使用的 web 页面，目前这个好像是唯一能选的…
支持 docker compose 自部署，可以自行编排和自定义很多配置
TOTP 认证，加分
UI 简约清晰，加分

缺点：

有一些小 bug, 挺影响使用体验的，比如我最开始用的那个版本，那时候还不知道这个只能 TOTP 验证，又找不到地方和文档设置初始账号密码，但是进首页直接跳到了仪表盘，又一直刷报错。这种情况没登录就不应该显示仪表盘界面的，非常误导人，我还以为是强制开了 HTTPS 但是我没有上传 SSL 证书导致的后端请求一直报错。
开源了但是又没有完全开。人家企业做这个的本意是推销自家的收费套餐，这个没毛病。但是请不要挂羊头卖狗肉，影响不好。GitHub Repo 都是些文档内容，有个所谓的语义检测引擎倒是放了一点代码，但是这个代码量级太少了，像个玩具项目，不像是正儿八经投入使用的引擎的源码。看了下这个社区版本的文档之类的，从头到尾就没有提过怎么参与项目贡献代码，挂了个 GitHub 链接似乎只是诱导大家去 star, 这样好做宣传。合着这个所谓的社区版就只是部署了之后有个按钮，可以共享攻击记录的 ip?
docker compose 写的方式令人费解。竟然需要在.env 文件中自定义一个内网网段，然后用 docker compose 的时候自动创建一个子网，每个容器根据子网的前缀指定了一个 ip, 然后其他容器连接都是在环境变量里写死….明明可以用 compose 文件里定义的 service name 或者 container name 作为 alias 使用内置的 dns 轻松实现的服务发现，为什么搞得如此麻烦？而且有没有考虑过，如果要更新，再执行 compose up 的时候，先前的子网 ip 是被占用的，每次还得先看一下当前用了哪些子网，然后找个没用的，这操作也是没谁了… 你说人家懂吧，他还通过 env 文件自定义 compose 创建的子网前缀，说人家不懂吧，用 container name 做 alias 自动实现服务发现这么简单的方式竟然不用。可能有安全或者性能方面的考量？不过我个人使用还是全部删掉了写死子网前缀的配置，这个使用方法真实太离谱了
目前只会记录疑似恶意的请求，正常请求不会记录，没法通过这个来看网站总访问情况了，有点可惜

安装部署流程

简单分享下我调优后的安装流程，不使用写死的子网前缀做服务发现。

1. 获取 compose 文件

官方文档默认提供的不是通过 docker compose 安装，而是他们的一个脚本。可能是为了照顾广大墙内被 CSDN “惯坏"的用户吧，脚本里除了基本的环境检测，主要是提供 docker 的便捷安装，但是怎么说呢…本意是给墙内用户便捷安装，但是为什么安装的操作还是到 docker 官方安装脚本，有没有一种可能，大部分大陆的服务器访问这个站点都很慢甚至连不上呢？但凡这里切一下 docker ce 镜像源都没这么离谱…

回到正题，这里还是大家通过 docker compose 安装。没安装 docker 的建议先去安装，有条件的可以直接按照官方文档来，安装文档链接. 也可以参考我之前写的 RSSMAN 部署文档中 Docker 安装的部分，有讲解在国内环境下提前更换镜像源以更快完成下载安装。Docker 安装-RSSMAN 部署指南 - RSS101 RSSMan 部署指南

之后获取官方最新的 compose 文件。文档里贴的链接是在离线安装的章节有个 compose 文件链接 https://waf-ce.chaitin.cn/release/latest/compose.yaml

当然也可以直接去 Github 找，在 release 文件夹下。https://github.com/chaitin/SafeLine/blob/main/release/latest/compose.yaml

之后需要按照文档指示，在 compose 文件同文件夹位置，创建一个.env文件，并填写相关的变量。这里推荐使用我调整后的版本。后续如果官方对于整个架构有更新，以官方的为准，可以自行根据需要调整 compose 文件。

services:
safeline.manager:
container_name: safeline-manager
restart: always
image: chaitin/safeline-mgt-api:${IMAGE_TAG:?image tag required}
volumes:
- ${SAFELINE_DIR?safeline dir required}/resources/management:/resources/management
- ${SAFELINE_DIR}/resources/nginx:/resources/nginx
- ${SAFELINE_DIR}/logs:/logs
- /etc/localtime:/etc/localtime:ro
ports:
- ${MGT_PORT:-9443}:1443
environment:
- MANAGEMENT_RESOURCES_DIR=/resources/management
- NGINX_RESOURCES_DIR=/resources/nginx
- DATABASE_URL=postgres://safeline-ce:${POSTGRES_PASSWORD}@safeline-db/safeline-ce
- MARIO_URL=http://safeline-mario:3335
- FVM_MANAGER_URL=safeline.fvm-manager:9004
- MANAGEMENT_LOGS_DIR=/logs/management
dns:
- 119.29.29.29
- 223.5.5.5
- 8.8.8.8
networks:
- safeline
cap_drop:
- net_raw
safeline.detector:
container_name: safeline-detector
restart: always
image: chaitin/safeline-detector:${IMAGE_TAG}
volumes:
- ${SAFELINE_DIR}/resources/detector:/resources/detector
- ${SAFELINE_DIR}/logs/detector:/logs/detector
- /etc/localtime:/etc/localtime:ro
environment:
- LOG_DIR=/logs/detector
networks:
- safeline
cap_drop:
- net_raw
safeline.mario:
container_name: safeline-mario
restart: always
image: chaitin/safeline-mario:${IMAGE_TAG}
volumes:
- ${SAFELINE_DIR}/resources/mario:/resources/mario
- ${SAFELINE_DIR}/logs/mario:/logs/mario
- /etc/localtime:/etc/localtime:ro
environment:
- LOG_DIR=/logs/mario
- GOGC=100
- DATABASE_URL=postgres://safeline-ce:${POSTGRES_PASSWORD}@safeline.postgres/safeline-ce
networks:
- safeline
cap_drop:
- net_raw
safeline.tengine:
container_name: safeline-gateway
restart: always
image: chaitin/safeline-tengine:${IMAGE_TAG}
volumes:
- ${SAFELINE_DIR}/resources/nginx:/etc/nginx
- ${SAFELINE_DIR}/resources/management:/resources/management
- ${SAFELINE_DIR}/resources/detector:/resources/detector
- ${SAFELINE_DIR}/logs/nginx:/var/log/nginx
- /etc/localtime:/etc/localtime:ro
# - ${SAFELINE_DIR}/resources/cache:/usr/local/nginx/cache
- tengine-cache:/usr/local/nginx/cache
environment:
- MGT_API=https://safeline.manager:1443/api/publish/server
ulimits:
nofile: 131072
networks:
- safeline
ports:
- 80:80
- 443:443
safeline.fvm-manager:
container_name: safeline-fvm-manager
restart: always
image: chaitin/safeline-fvm-manager:${IMAGE_TAG}
environment:
- FVM_LOGS_DIR=/logs/management
- DETECTOR_URL=http://safeline-detector:8001
volumes:
- /etc/localtime:/etc/localtime:ro
- ${SAFELINE_DIR}/logs:/logs
networks:
- safeline
cap_drop:
- net_raw
safeline.postgres:
container_name: safeline-db
restart: always
image: postgres:15-alpine
volumes:
- ${SAFELINE_DIR}/resources/postgres/data:/var/lib/postgresql/data
- /etc/localtime:/etc/localtime:ro
environment:
- POSTGRES_USER=safeline-ce
- POSTGRES_PASSWORD=${POSTGRES_PASSWORD:?postgres password required}
networks:
- safeline
cap_drop:
- net_raw
command: [postgres, -c, max_connections=200]
volumes:
tengine-cache:
networks:
safeline:
name: safeline
driver: bridge
driver_opts:
com.docker.network.bridge.name: safeline

2. 安装部署

部署成功后，第一次使用理论上会跳转到 TOTP 绑定页面。我之前这里卡到 bug, 第一次访问不是首页，没有看到那个绑定 TOTP 的二维码，后面就一直没法跳转到绑定页面了….不知道后面这个 bug 修复了没有，如果大家也遇到这个问题可以考虑全部清理干净，重新安装。

TOTP 软件推荐和对比：

Microsoft Authenticator( 微软出品，支持云同步，国内可用，微软账户验证有单独的通道和验证方式，速度和体积一般)
Google Authenticator (谷歌出品，简约好用，体积小速度快，可惜大陆地区没法云同步)
BitWarden (支持使用自建实例，可惜 app 略卡)

总结

雷池 WAF 目前来看是一款够用，不难用的免费 WAF, 建议一试。

此外重要数据还是要经常备份，多副本 + 多地存储，数据无价！

关于双语字幕这件小事

Sun, 10 Sep 2023 00:00:00 +0000

今天这篇文章来探讨下双语字幕这件小事。

首先对于一部外语影片或剧集，原生的英文字幕肯定是能够轻松获得的，但是匹配、高质量的翻译字幕缺并不总是能找到。这里分享一些我在寻找和手动 DIY 双语字幕的一些经验和想法，我自己也编写了一些工具，有同样需求的朋友也可以快速上手:D

1. 考虑寻找现成的高质量字幕

很多大火的剧集都会有字幕组第一时间跟进字幕制作和资源的发布，我们可以在各种 BT, PT 站点找到这些字幕组打包好的自带字幕的资源，或者也可以在第三方的字幕站点上寻找合适的字幕。

这里安利一个油猴脚本：豆瓣资源下载大师，可以在豆瓣的影视详情页右侧显示有资源的站点，非常方便

效果如下图所示

中文字幕推荐字幕库, 大部分字幕都可以在这里找到。其他语言可以到 OpentSubtitles 碰碰运气，虽然界面有点古朴，但是人家资源还是很丰富滴

2. 字幕的时间轴修正

对于下载的字幕，我们常遇到的问题就是时间轴不匹配，相信每个影视爱好者都或多或少碰到过这样的问题。产生不匹配有多种原因，典型的比如：

视频帧率不匹配
视频有删减 (片头或者片中都有可能，常见于电视剧集，有些中间有广告转场有些没有)
视频版本不一样 (各种删减版，完整版，导演剪辑版等等)

最后一种差异的地方太多，建议重新找字幕。对于前面两种情况，文本的部分没有太多差异，只需要调整字幕的时间轴就可以了。

这里需要一些对齐时间轴的工具，这个市面上已经有很多了，大部分都是基于将对白音频持续时间和字幕对白持续时间做匹配，然后进行字幕整体时间轴的缩放或平移来实现对齐的。

比如 Sushi, 以及ffsubsync

还有一类是最近比较火的，利用 AI 来对语音进行识别，输出对应的字幕。一半都是通过 Whisper 这个开源的语音识别模型来实现的，比如autosubsync.

这类语音识别的 AI 目前已经很成熟了，市面上有很多商业应用，比如办公软件飞书，腾讯会议一般都会支持会议语音转文字。但是这种都是为会议场景准备的。其实国内网易有道在这块做的更早，对英文支持更好，网易见外可以直接对音频进行识别，并生成 srt 文件，甚至还可以直接加上翻译，效率直接拉满。免费额度基本够用，各位轻度使用的朋友不要错过。

当然，这类 AI 语音识别和翻译现阶段还是差了点意思，在各种影视作品中，各类人名，专有名词，还有各种各样的梗 (比如 The Simpsons ), AI 处理起来还是有点够呛，所以最好还是优先选择人工调教后的字幕比较好。

上面罗列的那些对齐工具只能处理字幕和影片都是原生语言的情况，比如处理英文电影的英文字幕，但是对于要对时间轴不匹配的中英文双语字幕就基本没辙了。找遍了全网都没找到合适的工具，所以我就自己写了一个 srt-fuzzy-sync

fuzzy-sync 是一个简单的同步 srt 字幕的工具，通过指定一个与音轨匹配的参考字幕文件，来将另一个未同步的字幕进行匹配，时间轴修正，使得其可以与音轨正确对齐。

简单点来说呢，这是一个专门用来对双语字幕时间轴进行修正的工具。你手头有一个英文电影资源，一个正确对齐的英文字幕，一个没对齐的双语字幕，这个时候你就可以用 srt-fuzzy-sync 这个工具，将英文字幕设定为参考，然后对双语字幕的时间轴进行修正，就可以得到一个时间轴正确的双语字幕啦！

为什么叫 fuzzy-sync 呢，这主要是为了通用性，只对两个字幕之间高度相同的一些关键对白进行匹配，其他的对白则只是基于匹配结果进行整体偏移，这样做的好处是即便你找的这两个字幕的对白数量不一样，仍然可以完成同步。

一般英文的 SDH 无障碍字幕里都会有很多非对白场景下的文字提示，比如

(Theme Music Playing)

(sigh)

(Bird Singing)

而影片对应中文字幕里一般都不会加上这些翻译。此外中文字幕还常常对影片中出现的标题、店铺招牌、标语、新闻标题做翻译说明，种种因素导致中英文字幕在句子的数量上不是严格对等的。

此外这些字幕出现的时间，通常是没有对应的对白音频的。上面基于音频匹配的都无法很好地处理这类情况，所以我才抛弃按句匹配的方法，改为按一些句子很长，具有标志性，在影片中通常只会出现一次的关键语句匹配。

至于找不到的现成双语字幕的，那就需要我们自己动手制作啦。

3. 自制双语字幕

有时只能找到现成的中文字幕和原版英文字幕，但是没有双语的版本，这个时候就需要我们手动合并了。

这里推荐一个工具网站 Subtitle Tools, 里面有各种简单的字幕工具，比如字幕合并，字幕格式转换。

对于手上又对齐的英文字幕和对齐的英文字幕，但是数量很多不想一个个到网站上去合并的，可以考虑 srt-merge 这个工具。不过原作者很久没更新了，我这里也编写了一个工具，也可以实现一样的功能。dual-lang-sub-tool

此外还有一种常见的情况，就是我们下载的 WebRip 版本资源，影片已经内置了多国语言分别的字幕，这些资源大部分是来源于 Netfilx, Disney Plus , iTunes 这些，我们可以直接提取影片资源内置的两种语言的字幕然后将它们合并。

内置字幕的提取可以使用 ffmpeg 工具，首先用 ffmpeg -i 文件路径来查看基本信息，确定好字幕所在的 track, 比如 Stream #0:3(chi) Subtitle, 这种就是说明 3 号 stream 是中文字幕。

# example output # ......
Stream #0:1(jpn): Audio: aac (LC), 48000 Hz, stereo, fltp (default)
Metadata: title : 日语
Stream #0:2(chi): Audio: aac (LC), 48000 Hz, stereo, fltp
Metadata: title : 国语
Stream #0:3(chi): Subtitle: ass (default)
Metadata: title : gb
Stream #0:4(chi): Subtitle: ass
Metadata: title : big5

可以用下面的命令将其提取出来并转换成 srt 格式

ffmpeg -i xxx.mkv -map 0:3 -c:s srt output.srt

提取完成后就可以直接合并得到成品的双语字幕了，但是你应该也会觉得这样提取太麻烦，尤其是一部剧几十集的情况。一般同一个资源，里面各个音轨和字幕的排布是一样的，比如上面只取了一集进行查看，其他集数都是一样的，中文字幕都是在 stream 0:3, shell 循环一下就可以了。

当然你可能觉得这还是太麻烦了，我也是这么想的，所以 dual-lang-srt-tool 工具也支持自动检测，导出，合并双语字幕啦:D DIY 双语字幕可以很简单

后记

对于一些专有名词太多，AI 翻译质量欠佳，又没有现成中文字幕可供参考的，那目前就没有很好的办法了。通常我遇到这种情况是用 AI 的版本将就下，或者直接全英文一把梭。不过随着 AI 技术的发展，后面或许可以考虑将过往季的字幕喂给 AI 让 ta 自己学习人名地名翻译，再辅以各种新闻八卦材料让 AI 也能对各种潮流热梗烂熟于心，到那个时候制作双语字幕就是分分种的事情了，可以预见的是这样的 AI 应该有生之年就可以用上，至于是好事还是坏事，那就交给未来去评判吧。

个人向 Linux 新服务器初始化清单

Tue, 14 Mar 2023 00:00:00 +0000

一份 Linux 初始化清单，避免每次拿到新的服务器都要一个个去各种地方搜集指令，以做备忘 & 供有需要的朋友参考。

服务器发行版我个人推荐 Debian 系列，CentOS 系现在已经开始分裂而且说实话对新手其实并不友好。Debian 是在兼容性，易用性和稳定性之间都取得不错平衡的发行版。新手推荐 Ubuntu, 不过最近商业化有点过度，夹带了越来越多的私活，我个人所有新安装的 Linux 已经全线转向 Debian. 下文以目前最新的 Debian 11 Bullseye 为例。Debian 12 bookworm 也测试通过。

azure 干净的 debian 11 镜像，资源使用情况供参考：

~1G Disk, ~100M RAM, ~300 packages

本文仅列举主要事项和操作，新手可先行阅读这篇文章熟悉概念。云服务器入门指南

正文开始

1 - 基础环境搭建

1.1 防火墙

检查服务商防火墙和系统自带防火墙 (debian 系一般为 ufw, cent os 系一般为 firewall-cmd).放行 SSH(22), 新的 SSH(自定义), HTTP, HTTPS, 以及其他常用开发端口

1.2 新建用户与检查 sudoer

登录到 root 用户，创建个人账户并设定密码

// -m 创建对应home文件夹
// 添加到 sudo 用户组自动获得sudo权限, 部分发行版为wheel组
useradd -m --groups sudo colin
// 设定密码
passwd colin

也可直接编辑/etc/sudoers 文件为新用户添加 sudo 权限，使用 visudo 指令可以自动帮你校验，避免配置写错把系统搞崩

1.3 镜像源与基础软件

如为境内服务器需要更换镜像源

更换国内镜像源

一般情况下，将 /etc/apt/sources.list 文件中 Debian 默认的源地址 http://deb.debian.org/ 替换为 http://mirrors.ustc.edu.cn 即可。

//for debian
sudo sed -i 's/deb.debian.org/mirrors.ustc.edu.cn/g' /etc/apt/sources.list
//for ubuntu
sudo sed -i 's@//.*archive.ubuntu.com@//mirrors.ustc.edu.cn@g' /etc/apt/sources.list

CentOS 系建议启用 EPEL, PowerTools 等 repo 以更方便地安装常用软件和工具。此处不再赘述

推荐的几个国内镜像站：清华大学 TUNA 镜像站, 中科大 USTC LUG 镜像站, 腾讯镜像站

基础软件

sudo apt update
sudo apt install wget curl git nano
sudo apt install zsh tmux htop duf htop tldr screenfetch tree

1.4 SSH 安全

修改端口，配置文件/etc/ssh/sshd_config. 重启机器或 sshd 服务后生效。此外最好将PermitRootLogin修改为no, 可以禁用 root 登录。

在本机检查~/.ssh/有无 id_rsa 等已生成的 key. 如没有再使用 ssh-keygen 生成私钥将本机的公钥上传到远端，再写入远端的 authorized_keys 中

cat ~/id_rsa.pub >> ~/.ssh/authorized_keys

注意修改权限，~/.ssh/authorized_keys 权限为 600. ~/.ssh/为 700

可以参考以下设置

.ssh/ 0700/rwx——
.ssh/.pub 644/rw-r–r–
.ssh/ 0600/rw——-

如失败可参考这篇文章 debug. https://superuser.com/questions/1137438/ssh-key-authentication-fails

1.5 设置 hostname

可选，为了便于识别和后续配置 oh-my-zsh 更美观。这里修改完后还需要更新 hosts 设置，把刚才设置的新的主机名指向 localhost

sudo hostnamectl set-hostname my-new-server
sudo hostnamectl status

此外/etc/hosts 中默认会有个本机 hostname 映射到127.0.0.1 的配置，修改 host 之后这里别名的映射也要修改下，不然终端执行命令会一直弹 sudo: unable to resolve host xxx: Name or service not known

修改后需重启

1.6 SWAP

可选，建议内存<2G 配置 swap, 大小至少为 2 倍物理内存，可以有效避免意外爆内存的情况。仅推荐 SSD 盘的服务器开启。

推荐用 fallocate , 因为这个是最简单、最快速的创建交换空间的方法。 fallocate 命令用于为文件预分配块 / 大小。

使用 fallocate 创建交换空间，首先在 / 目录下创建一个名为 swap_space 的文件。然后分配 2GB 到 swap_space 文件：

sudo fallocate -l 2G /swap_space
ls -lh /swap_space
// 然后更改文件权限，让 `/swap_space` 更安全：
sudo chmod 600 /swap_space
// 创建交换空间
sudo mkswap /swap_space
// 启用
sudo swapon /swap_space
// 使用 s 参数查看列表
sudo swapon -s

每次重启后都要重新挂载磁盘分区。因此为了使之持久化，就像上面一样，我们编辑 /etc/fstab 并输入下面行：

/swap_space swap  swap  sw  0  0

保存并退出文件。现在我们的交换分区会一直被挂载了。我们重启后可以在终端运行 free -m 来检查交换分区是否生效。

还可以按需选择使用 zram，提升内存可用量，不过会略微增加 cpu 使用和内存延时。可以搜索 zramctl, zramswap 等关键字

1.7 绑定域名

可选，绑定一个域名或者改下本地 host 便于后续访问

1.8 添加本地 SSH 别名

配置文件为本机的 ~/.ssh/config 格式如下

Host serverA
HostName myserver.domain.xyz
User colinx
Port 2333

2 - 常用工具与配置

2.1 Docker 环境

Docker 安装

可参考官网文档，注意是 docker engine 的安装。Docker 官方安装文档

或者我之前写的 RSS MAN 部署文档中 docker 安装的部分 RSS MAN X 安装部署指南/#1-docker 环境准备

Docker 镜像源配置及日志配置

docker mirror 配置可以加速 image pull, 国内公开可用的加速站点可以参考这里 docker 加速站点

此外服务器上的 docker 都是长时间持续运行的，不少容器日志打的很随意，log 文件容易占据过多空间，也最好限制一下。

文件位置/etc/docker/daemon.json, 下面的配置供参考

{
"registry-mirrors": [
"https://docker.nastool.de",
"https://docker.actima.top",
"https://docker.unsee.tech",
"https://docker.gh-proxy.com",
"https://docker.zhai.cm",
"https://docker.1panel.live",
"https://docker.1ms.run",
"https://docker.imgdb.de",
"https://dockerproxy.net"
],
"log-opts": {
"max-file": "5",
"max-size": "1m"
}
}

修改完保存重启 docker 服务即可生效。可使用 docker info 命令检查是否生效

2.2 OH-MY-ZSH

安装 OH-MY-ZSH, 在此之前确保已安装 git 和 zsh

sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"
# 如果在墙内 github 速度不加可以考虑使用清华的镜像
# https://mirrors.tuna.tsinghua.edu.cn/help/ohmyzsh.git/
# 先下载到任意位置，然后指定REMOTE 参数执行安装程序
git clone https://mirrors.tuna.tsinghua.edu.cn/git/ohmyzsh.git --depth=1
cd ohmyzsh/tools
REMOTE=https://mirrors.tuna.tsinghua.edu.cn/git/ohmyzsh.git sh install.sh

安装插件

git clone https://github.com/zsh-users/zsh-autosuggestions $ZSH_CUSTOM/plugins/zsh-autosuggestions --depth=1
git clone https://github.com/zsh-users/zsh-syntax-highlighting.git ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-syntax-highlighting --depth=1

git clone 速度不佳可以考虑一些开放的加速服务，比如：

按需修改配置。文件位置~/.zshrc, 下面为个人常用配置供参考。注意去源文件修改对应项，没有再到末尾加

# custom conf override
ZSH_THEME="af-magic"
CASE_SENSITIVE="false"
HYPHEN_INSENSITIVE="false"
plugins=(git z zsh-autosuggestions zsh-syntax-highlighting sudo)

自定义配置，添加到末尾

export ZSH_AUTOSUGGEST_BUFFER_MAX_SIZE=20

保存并应用

source ~/.zshrc

2.3 nano 代码文件规则

日常常用文本编辑器为 nano, 轻量级编辑需求完全满足。

curl https://cdn.jsdelivr.net/gh/scopatz/nanorc/install.sh | sh

2.4 时区调整

一般安装完都是 UTC+0, 看日志什么的不方便。服务器初始化的时候配置好后面可以免去很多麻烦

debian 系可用过 timedatectl 命令调整时区。东八区可以用这个命令

sudo timedatectl set-timezone Asia/Shanghai

2.5 厂商监控/SDK 卸载

懂得都懂，自己搜

2.6 fail2ban 配置

使用 fail2ban 可以很好地保护你的服务器，避免被人恶意爆破 SSH 等服务。

// 安装 fail2ban
sudo apt update && sudo apt install fail2ban
sudo systemctl enable fail2ban

之后需要按照实际情况修改一下配置文件。这里记录一下最小配置。注意默认的配置 /etc/fail2ban/jail.conf不要改，不然每次软件更新会被覆盖。在 jaid.d 这个目录下面新建一个文件/etc/fail2ban/jail.d/local.conf

[sshd]
enabled = true
# 这里修改为实际的 sshd 端口
port = 20000
filter = sshd
banaction = iptables-allports
[DEFAULT]
# 1h 时间窗口
findtime = 3600
maxretry = 3
bantime = 6h

之后重启sudo systemctl restart fail2ban，然后可以看下服务状态是否正常 sudo systemctl status fail2ban，如果配置文件有问题会报错。如果是显示 active (running) 就说明没有问题了。

fail2ban 的测试及关闭服务方法：

查看当前封禁 IP：sudo fail2ban-client status sshd
解禁某一 IP: sudo fail2ban-client set sshd unbanip IP_ADDRESS
停止 fail2ban 服务：sudo systemctl stop fail2ban
关闭 fail2ban 服务：sudo systemctl disable fail2ban

刚配置没一会就有 IP 被封禁了，可以看到效果还是很给力，也安心了不少

➜ sudo fail2ban-client status sshd
Status for the jail: sshd
|- Filter
| |- Currently failed: 1
| |- Total failed: 6
| `- File list: /var/log/auth.log
`- Actions
|- Currently banned: 1
|- Total banned: 1
`- Banned IP list: 154.216.19.42

2.7 Git 代理

一般在 .bashrc/.zshrc 中定义 HTTP_PROXY / HTTPS_PROXY 可以应对大部分场景。但是对于使用 ssh 协议的 git 仓库 (通过 ssh 方式，相较于 https 的不用每次输用户名和密码。一般对只有克隆公共仓库的时候才会用 https, 其他时候对于自己的仓库我都是用 ssh), 并不会走 http 代理。

这里需要在 ssh config 中配置转发走代理才行。使用nc(macOS 等默认会预装) 搭配 socks 代理最方便

Host github.com
HostName github.com
User git
Port 22
ProxyCommand nc -x 192.168.100.222:8085 %h %p

3 - 进阶内容

3.1 内核参数调优

一些内核参数调整，交换内存阈值和 bbr, tcp fast open 等，按需启用。启用前务必确认自己了解对应字段的含义，否则不如保留系统初始值。

配置文件位置 /etc/sysctl.conf

# mem
vm.swappiness = 10
# bbr and network tune 
net.core.default_qdisc=fq
net.ipv4.tcp_congestion_control=bbr
net.ipv4.tcp_fastopen=3
net.ipv4.tcp_slow_start_after_idle=0
# zram 相关配置，配合下文 zram 使用
vm.watermark_boost_factor = 0
vm.watermark_scale_factor = 125
vm.page-cluster = 0

配置完之后保存并应用

sudo sysctl -p

3.2 更多内存空间 - ZRAM

ZRAM 内存压缩，对于个人服务器来说，始终活跃的程序占用的内存只有比较小一部分，启用 zram 可以将这部分内存压缩，从而可以部署更多的服务。

建议使用zramtool, 简单方便

sudo apt install zram-tools

修改/etc/default/zramswap, 末尾添加

ALGO=zstd
PERCENT=60

之后执行sudo service zramswap reload重载生效。可以使用 swapon 命令查看生效情况

~ » sudo swapon -show
NAME TYPE SIZE USED PRIO
/swap_space file 2G 32.1M -2
/dev/zram0 partition 489.9M 0B 100

这样一来，会将机器物理内存的 50% 配置 zram, 使用 zstd 压缩算法，一般压缩比能达到 3:1, 也就是说，1G 的机器，可以相当于有0.5G+3*0.5G=2G的内存。

注意 Debian 新版本 swapon 等工具所在的目录 /usr/sbin 不在普通用户的 PATH 中，可能需要手动执行前缀使用。如 /usr/sbin/swapon

3.3 更多内存空间 - 关闭 kdump，释放预留的内存空间

新服务器开起来之后，你会发现无论是 htop 还是 free 等命令，看到的总内存就是比你买服务器时页面上写的要小。比如我开的两核 1G 的机器，实际机器上看到的总内存只有 816M. 这是因为 linux 系统会默认开启 kdump，预留了一部分内存不让我们使用。

Kdump 是 Linux 系统的一种内核崩溃转储机制，它允许在系统发生内核崩溃（例如内核 panic）时，捕获内存的转储信息，从而帮助事后分析故障原因。默认的配置2G-8G:256M,8G-16G:512M,16G-:768M, 如果你买的是 2G 的机器，上来就有 1/8 的空间用不了。

但是我们个人日常使用的 linux 机器基本用不到这个功能，不用预留这部分空间。

操作方法有两种：将预留内存改为 0 or 直接关闭 kdump 服务。对于个人玩家小内存机器我建议直接关闭。操作如下：

# 备份grub配置文件
sudo cp /etc/default/grub /etc/default/grub.bak
# 编辑grub配置,删除 crashkernel=0M-2G:0M,2G-8G:192M 这样的部分 
sudo nano /etc/default/grub
# 部分发行版镜像可能还有单独的kdump配置文件,直接删除
sudo rm /etc/default/grub.d/kdump-tools.cfg
# 更新grub配置
sudo update-grub
# 关闭并禁用Kdump服务
sudo systemctl disable kdump-tools
sudo systemctl stop kdump-tools
# 重启系统
sudo reboot
# 检查是否生效, 状态为 inactive(dead)，即 kdump 服务已停止运行
sudo systemctl status kdump
# 检查 crash size 是否为0
cat /sys/kernel/kexec_crash_size

更多内容可以参见这篇文档：预留内存相关文档 - 阿里云或者预留内存相关文档 - 腾讯云

3.3 其他进阶配置

一些其他的系统维护技巧与策略，如

配置文件管理 所有应用 docker 化，通过 docker compose 文件管理配置共享存储，rclone 挂载 webdav, 同步 docker compose 等配置文件; traefik 网关作为统一出口，负责服务发现和自动维护 HTTPS 证书，自定义配置通过 headless CMS 如 directus 管理，traefik 设定为通过 http 方式获取远端配置即可。

数据库备份 所有数据相关的统一挂载到/data/database/xxx, 配置定时任务进行备份以及配置 s3 等，上传到其他存储介质和其他地域。

这些内容此处不再赘述，有机会再单独写篇文章分享吧

END

附录

Install Docker Engine https://docs.docker.com/engine/install/
RSSManX 安装部署指南 https://blog.colinx.one/posts/rssmanx%E5%AE%89%E8%A3%85%E9%83%A8%E7%BD%B2%E6%8C%87%E5%8D%97/
云服务器入门指南 https://blog.colinx.one/posts/%E4%BA%91%E6%9C%8D%E5%8A%A1%E5%99%A8%E5%85%A5%E9%97%A8%E6%8C%87%E5%8D%97/
Portainer Install Doc https://docs.portainer.io/start/install-ce/server/docker/linux

2023 静态网站托管服务速度对比

Sun, 25 Dec 2022 00:00:00 +0000

对几家喜闻乐见的静态网站托管服务商 Vercel、Netlify、Cloudflare Pages、Azure Static Pages 测个速

测速后结论：

Vercel 全部爆炸，大陆地区全部不通
Netlify 对三家支持都比较不错，不过都有些不太稳定
Cloudflare 对电信友好，联通次之，移动大规模连不上
Azure 电信友好，联通次之，移动也是大规模连不上

特邀嘉宾：腾讯云海外 CDN

号称「充钱就可以获得力量」，那么让我们来看下冲了钱后的效果

腾讯云海外 CDN

大陆地区大部分路由到香港，极少数华东地区路由到美国，全部为 AWS 节点
移动除西北地区外都尚可，联通次之也是除西北外都还行，电信惨不忍睹

用腾讯云 CDN 被 D 怎么办？天价账单可付不起 小时结计费模式，欠费后保护期为 2 小时，还可以按流量或带宽单独设定防护策略

接下来开始真正的试炼：检测晚高峰期间各家的性能，晚上这个点各大运营商的出口都比较拥堵，这个时候更能体现出各家的性能优劣

晚高峰测速结果

Azure 全线炸裂 ⬆️

Netlify 依然给力 ⬆️

Vercel 依然一片红 ⬆️

CF 跟白天差不多，电信联通勉强可用 ⬆️

TX 海外 CDN 红绿参半，不过可以看到很强的地域特性

其他补充信息：

Vercel

不能自定义 HTTPS 证书，走 Let‘s Encrypt
有 Anycast，76.76.21.21，用 DNS 做负载均衡会比较方便
使用分钟级监控看过，时不时有连不上的情况，比 Cloudflare 明显差些，不过免费没有 SLA 保障也正常
大陆地区全部爆炸，不予考虑

Netlify

可以自定义 HTTPS 证书
无 Anycast，去年看都是 AWS 承载，今年看有近一半由 Google Cloud 承载
移动可以优先 Netlify
可以安装插件，网站更新可以自动推送 Google 比较方便
全部路由到新加坡，北方用户可能延迟较高

Cloudflare Pages

Cloudflare 可以自己签发证书，不像其他使用 Let‘s Encrypt 的必须要能解析到
有 Anycast，可以直接解析到 1.1.1.1，做负载均衡方便
移动 pass，电信联通尚可
不太稳定，动不动就被墙，需要常检测更新节点联通性

Azure Static Pages

可以通过 TXT 记录验证和自动申请 HTTPS
无 Anycast，只有香港的节点，两个 IP，方便负载均衡
移动 pass，电信联通尚可
北方用户可能延迟较高

策略

Vercel 全线不可用，Azure 晚高峰全部炸裂，大陆地区不考虑
Netlify 做全局默认 fallback
海外默认走 Cloudflare、Vercel
电信走 Netlify，无可替代
移动走 Netlify 和腾讯云海外 CDN
联通走 Netlify、Cloudflare、腾讯云海外 CDN

博客的几个镜像站点我也挂在了仓库的 README 页面，加了几个 badge 可以快速看到几个 mirror 的联通性情况。https://github.com/Colin-XKL/Colinx-Blog

Huginn 指南：为任意网站制作 RSS

Sun, 08 May 2022 00:00:00 +0000

Huginn 使用多个不同功能的 Agent 组合搭配来实现一系列功能，一个 Agent 可以执行特定的操作，并产生一个 Event，你可以指定他产生的 Event 由哪个 Agent 接收处理。

比如我们需要使用 WebSite Agent 来爬取某个网站上的列表内容，爬取后列表的每一项会生成一个 Event，我们可以指定一个 Output Agent 来接收这些 Event，并将其转换为 RSS 的格式进行输出，复制 Output Agent 返回给你的 URL 就可以进行订阅啦，Huginn 爬取网站生成 RSS 的基本原理就是这样。

Huginn 爬取普通网页制作 RSS

右键网页打开开发者工具，屏幕会分出一部分空间显示开发者工具窗口，点击左上角的按钮再把鼠标移动到页面上可以选择页面的某一个元素，比如这里我们要爬取推荐文章列表，推荐文章列表的每一项都有同样的样式，我们可以使用 CSS 选择器来指定爬取该项

该元素可以用 CSS 选择器.meiwen选择到。

Tips: class=xxx 则使用.xxx,如果为 id=xxx 则使用#xxx

该标签是 a 标签，我们可以继续限定一下条件，使用a.meiwen

如果要限制必须是 h2 标签下的带有 meiwen 的 class 属性的 a 标签，可以使用h2 a.meiwen

如果要再加一个限制，是列表元素 li 下面的 h2 标签里带有 meiwen 的 class 属性的 a 标签，可以使用li h2 a.meiwen

添加其他附加限定条件以此类推

你也可以在右侧 Style 面板里点击加号添加一个自定义样式，输入 CSS 选择器，浏览器会自动高亮符合条件的网页元素，你可以使用这个功能来检验你写的 CSS 选择器是否正确以及是不是提取的你想要的内容

接下来在 Huginn 里创建一个 Scenario，然后点击新建一个 Agent，类型选择 WebSite Agent，填写一个名称，并在最下面的配置处指定你要爬取的网页元素

Website Agent

The Website Agent scrapes a website, XML document, or JSON feed and creates Events based on the results.

url: {
css: li h2 a.meiwen
value: @href
}

以爬取 url 为例，css 表示使用 css 选择器选择网页元素，value 表示从哪里获取对应的值，对于刚才我们选取的一个元素来说

<a class="meiwen" href="/article/58030.html" title="缘起则聚，缘灭则散">缘起则聚，缘灭则散</a>

href 属性里面的内容是他的链接，title 属性里面的内容则是他的标题。接下来在 value 中填写@href指定从 href 属性提取内容，就可以取到链接地址了

Pro Tips:

如果是纯文本节点或是想提取标签内嵌的文本，value 里可以填写string(.)

如果想删除多余的空格，可以使用normalize-space(.)

Pro Tips 2:

字符串处理函数和标签属性值变量可以一起使用，如normalize-space(@title)可以获取该标签的 title 属性值并删除多余的空白字符

接下来点击 Dry Run 按钮进行测试，不出意外我们会得到一个 json 的输出，里面包括我们爬取到的每一项他的 url 和 title。

如果没有成功，你可能需要删掉上面没有使用到的 hovertext 节点，因为该项指定的内容在我们刚才的网页中并不存在。

点击 Save 保存，我们开始下一步输出 RSS。在刚才的 Scenario 中再新建一个 Agent，选择 Data Output Agent，并设置他的名字和 Source Agent

Data output Agent

The Data Output Agent outputs received events as either RSS or JSON. Use it to output a public or private stream of Huginn data.

Propagate immediately是指即时处理来自 Source Agent 的 Event，启用他方便我们调试，但会略微增加服务器负载，你可以自行决定是否使用。

在 secret 字段中为你的这个 RSS 标注一个英文的名字，修改 title 字段标注你的 RSS 的名字。item 字段是每条文章会有的属性，一般来说主要就 title 和 link，分别设置为上文我们提取的值的变量名。这里添加一个 guid 字段，这是一篇文章的唯一标识符，避免 RSS 阅读器读到的文章标题不同但是内容相同，常见于某篇文章的标题被修改，这会导致 RSS 阅读器内出现多篇重复文章。

此外建议增加一个 link 字段，值设置为与爬取的网站的主域名一致，避免网站内使用相对链接开头的资源无法正常加载。

点击 Save 保存，回到 Scenario 界面，第一次需要手动点击运行一下刚才的 Website Agent。稍等片刻后台会进行爬取，右上角会显示产生了多少个 Event。再点开刚才设置的 Data Output Agent 查看详情，vola！右侧就会显示生成的 RSS 链接了，复制以 xml 结尾的链接到 RSS 阅读器中就可以订阅啦🎉

如果你的配置正确但是 WebSite Agent 又没有输出任何内容的话，那么你要爬取的站点的内容应该是通过 JavaScript 在你带开浏览器时动态生成的。

Pro Tips:

你可以右键网页在开发人员菜单中点击显示源代码，然后用 Ctrl+F 搜索你在页面上见到的想爬取的某一条内容，如果有说明该网站的页面时静态的，否则说明你要爬取的内容并不是静态的。

要爬取这样的站点，我们需要模拟浏览器操作，执行页面上的 JavaScript 脚本，待数据生成完毕后再使用上面的方法去爬取内容。要模拟浏览器操作，这里介绍两个方案：一个是利用 browserless 的无头浏览器，另一个是使用在线 PhatomJS 服务。

使用 Huginn+Browserless 为动态网页生成 RSS

部署了RSS Man X的完整版的话默认已经包含 huginn 和 browserless 服务，无需重复安装。且 huginn 可以通过service.browserless:3000访问到 browserless 服务。

总体步骤与上文一样，不过因为被抓取的内容是通过 JavaScript 动态生成的，所以直接使用 WebSite Agent 是抓取不到东西的，我们需要先使用 Post Agent 向 browserless 服务发送指令，让他帮我们模拟浏览器操作，再将最终完整的网页返回给我们，再使用 WebSite Agent 进行后续处理。

Post Agent

A Post Agent receives events from other agents (or runs periodically), merges those events with the Liquid-interpolated contents of payload, and sends the results as POST (or GET) requests to a specified url. To skip merging in the incoming event, but still send the interpolated payload, set no_merge to true.

接下来以这个网站为例介绍一下，这个列表页的内容是由 JavaScript 动态生成的

按照以下内容设置你的 Post Agent

{
"post_url": "http://service.browserless:3000/content",
"expected_receive_period_in_days": "1",
"content_type": "json",
"method": "post",
"payload": {
"url": "https://pccz.court.gov.cn/pcajxxw/pcgg/ggdh?lx=0"
},
"headers": {
"Cache-Control": "no-cache",
"Content-Type": "application/json"
},
"emit_events": "true",
"no_merge": "false",
"output_mode": "clean"
}

其中post_url为你的 browserless 实例地址，如果你使用了 RSS MAN X 里的 Huginn 可以直接向上面一样填写。payload中的url字段填写你需要的网页地址。注意 emit_events 要设置为true，这样才方便我们后续使用 WebSite Agent 操作。

点击 Dry Run，如果能返回一个带有body字段且里面有文本内容说明调用成功。

调用不成功检查一下配置，以及是不是我们的爬虫被目标网站拦截了。若是爬虫被拦截可参考文末的解决方案。

接下来点击 Save 保存，再新建一个 Website Agent，Source 设置为刚才的 Post Agent。

{
"expected_update_period_in_days": "2",
"data_from_event": "{{ body }}",
"type": "html",
"mode": "on_change",
"extract": {
"url": {
"css": "ul#wslb li a",
"value": "normalize-space(@href)"
},
"title": {
"css": "ul#wslb li a",
"value": "@title"
},
"author": {
"css": "ul#wslb li div.center",
"value": "normalize-space(.)"
}
}
}

注意修改data_from_event的值，其他地方与爬取普通网站一样。再新建并配置一下 Output Agent，RSS 的链接就出来了

使用 PhantomJS 为动态页面生成 RSS

首先需要到Phantom Js Cloud 的官网注册一个账户，每个账户官方提供了一定的免费额度，每天大概可以爬取 500 个页面，对于做 RSS 来说妥妥的够用了。注册之后可以得到一个 API KEY，这个待会会使用到。

接下来新建一个 Phantom JS Cloud Agent，填写基本的名称、API KEY 和目标 URL，render type 选择 html。底下 User Agent 建议改用真实的浏览器 UA，减少触发反爬虫的可能性。如果不知道自己的 UA 可以到这个网站查看当前浏览器的 UA，复制字符串即可。如果懒得查也可以用这个

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/100.0.4896.81 Safari/537.36

Phantom JS Cloud Agent

This Agent generates PhantomJs Cloud URLs that can be used to render JavaScript-heavy webpages for content extraction.

URLs generated by this Agent are formulated in accordance with the PhantomJs Cloud API. The generated URLs can then be supplied to a Website Agent to fetch and parse the content. Sign up to get an api key, and add it in Huginn credentials.

点击 Dry Run 后会返回一条 url，返回格式类似这样

[
{
"url": "https://phantomjscloud.com/api/browser/xxxxxxx"
}
]

之后创建一个 WebSite Agent，Source Agent 设置为上面的 Phantom JS Cloud Agent，然后稍微改一下 url 的部分

{
"expected_update_period_in_days": "2",
"url_from_event": "{{url}}",
"type": "html",
"mode": "on_change",
"extract": {...}
}

注意将原来的url:??的部分更改为"url_from_event": "{{url}}",这样就指定使用 Phantom JS Cloud 为我们获取的完整网页，接下来的操作就大同小异了。配置好要爬取的字段和规则后点击 Dry Run 就可以看到结果

这里是刚才的 Agent 产生的一个 Event。这里除了 url 和 title 我还提取了 date 字段。在 Output Agent 中，可以配置为每一条文章输出发布时间的信息。对于这种规整的日期字母串，可以使用{{ date | date: %F }}进行解析并格式化输出为 rss 规范的时间格式如果没有配置的话，每篇文章的发布时间显示的都是一样的，为 Huginn 爬虫更新的时间。

"item": {
"title": "{{title}}",
"link": "{{url}}",
"pubDate": "{{ date | date: %F }}"
},

Pro Tips:

Huginn 解析日期

注意{{ date | date: %F }}里面，第一个date是上面的 Website Agent 产生的 Event 里面的变量名，第二个date是 Huginn 使用的 Liquid 模版引擎语法里内置的一个 filter，可以理解为有特定功能的函数

FAQ

为什么启动 docker 容器后访问 Huginn 显示网络错误？

Huignn 冷启动较慢，需要等待三五分钟。如果还是不行，检查端口映射和防火墙设置
为什么抓取到的包含相对路径的结果，网页上可以点击访问，但是生成的 RSS 不能正常使用？

检查 link 的设置，有些网站只是域名，有些网站有子目录，具体查看该网页源码中 head 节点里 base url 的设置
如何对爬取到的某一项的字符串做更高级更复杂的处理？

可以参考Hugnn 官方对 Liquid 语法的文档以及Shopify 官方关于 Liquid 模板的语法文档
为什么部署了 Huginn，等了很长时间都无法访问后台页面？

若部署后某个应用一直无法通过浏览器访问，请检查是否绑定到了 6000/6666 等特殊端口，浏览器会拦截对这些端口的访问参见这里
Huginn 爬虫访问目标网站被拦截了怎么解决
介绍几个基本的反反爬虫策略：
1. 带上 User Agent，要求是真实的浏览器 UA。
2. Browserless 去掉默认会和请求一起发送的可以被识别为爬虫的特征参数，设置 browserless 的环境变量DEFAULT_HEADLESS=false
3. 使用随机代理 IP，适用于因爬取频率达到爬虫阈值

扩展阅读

前端静态资源加载的一些优化

Fri, 06 May 2022 00:00:00 +0000

最近在折腾优化博客，由于全站都是部署在 Netlify、Vercel 的 CDN 上，都是海外节点，国内访问延迟高，在想办法优化下访问速度和体验。线路部分的优化可以看另一篇文章国外静态网站托管服务商国内速度对比及线路优化。这篇文章来探讨下前端 CSS 和 JS 资源的加载。

优化目标主要就两个：

尽可能快，但是不希望我引入的辅助性第三方库影响到页面体验，不要阻塞主要内容渲染
为了快第三方静态资源肯定是上 CDN，但是要有容灾，CDN 挂了要能 fallback 到其他 url

静态资源异步加载

prefetch、preload这些预加载技术暂且不谈，博客站点没那么多资源。这里主要是用async和defer来控制脚本异步加载，以避免阻塞 DOM 解析和页面渲染。

使用async异步加载，对于pangu这种会影响到内容呈现的使用async，对于统计类第三方库使用defer延迟加载，到 DOM 加载完再执行

有些第三方库需要手动 init，这样就不能使用defer、async关键字加载资源了，defer和async关键字只适用于远程资源，本以为把远程资源的<script>和内嵌在 HTML 里用来 init 的<script>都加上defer就可以利用它顺序加载的特性解决这个问题，结果发现不是这样的。。。。异步打乱脚本执行顺序，init 脚本不等待资源下载完毕会先执行。利用好onload事件可以解决这个问题。

before

<script src="https://cdn.jsdelivr.net/npm/pangu@4/dist/browser/pangu.min.js"></script>
<script>
pangu.spacingElementByClassName('post');
pangu.spacingElementByTagName('p');
document.addEventListener('DOMContentLoaded', () => {
pangu.autoSpacingPage();
});
</script>

after

<script>
function panguSpaing() {
pangu.spacingElementByClassName('post');
pangu.spacingElementByTagName('p');
document.addEventListener('DOMContentLoaded', () => {
// listen to any DOM change and automatically perform spacing via MutationObserver()
 pangu.autoSpacingPage();
});
}
</script>
<script async onload="panguSpaing()" src="https://cdn.jsdelivr.net/npm/pangu@4/dist/browser/pangu.min.js"></script>

除了onload还有onerror，还可以利用onerror事件在资源加载失败时 fallback 到其他 CDN，详见下文

这里跑了个测试看下优化前后的差距

优化前

First Contentful Pain Time 在 1.5s，整个页面到 1.5s 才能可见，DOM 加载总时间达到了 2.5s

本来我都已经把首页不需要加载的三方库都拿走了，但是还剩下一个，这个用于前端性能监控的 js 阻塞了渲染，挂的是腾讯云的 CDN，国内快到飞起，国外就卡到不行（作为对比上图里从 jsdelivr 加载的 js 也是快到飞起，墙内就慢得一批）

优化后

优化后页面没有再阻塞，0.8s 页面就可用了，总 DOM 加载时间只有 1.5s，相较之前简直直接起飞。

国内某检测平台的结果也显示优化效果明显

静态资源 Fallback 加载

国内好用的静态资源 CDN 还真没有，新浪那种只提供那么几个热门的库完全不符合需求，BootCDN 炸了不是一次两次，字节 CDN 的资源 URL 有够 ugly，URL 里面还带节点信息多半后面会出问题。360 奇舞 CDN 之前也换过域名、备案出问题，感觉每一个能省心用。七牛的目前看上去还行，也不知道后面会不会出什么幺蛾子。。。为了稳妥起见 + 照顾全球的访客，还是优先使用的 cloudflare 和 jsdelivr 的 CDN

网站主要三方库都是通过 jsdelivr 和 cloudflare 引入的，但是毕竟是海外的节点不知道哪一天就被墙了，所以还要为墙内的访客准备一个 fallback 方案。这里利用到script标签的onerror事件

现代浏览器都支持script和link标签上的onload和onerror事件，详细支持情况可以查看这里

https://pie.gd/test/script-link-events/

关于onerror，中文互联网上有好几篇文章说他会捕获script标签里的代码的执行错误。。。简直离谱。稍微查下 MDN 之类的文档就可以发现这玩意本来就是只捕获资源加载错误的

The onerror event is triggered if an error occurs while loading an external file (e.g. a document or an image).

https://www.w3schools.com/jsref/event_onerror.asp

利用好这个特性，就可以实现在资源加载失败时 fallback 从另一个 url 加载资源。

<script>
function fallbackJSloader(url, loadedEvent) {
console.log('Error loading asset, using fallback url');
console.log('load asset from', url);
let script = document.createElement("script");
script.type = "text/javascript";
script.src = url;
script.async = true;
if (loadedEvent)
script.setAttribute('onload', `${loadedEvent}()`)
document.body.appendChild(script);
}
</script>
<script defer onload="init_gitalk()"
onerror="fallbackJSloader('https://cdn.staticfile.org/gitalk/1.7.2/gitalk.min.js','init_gitalk')"
src="https://cdn.jsdelivr.net/npm/gitalk@1/dist/gitalk.min.js">

CSS 的 fallback 加载同理，此处不再赘述

优化后如图，在开发者工具中手动 block 资源网站，可以自动 fallback 从另一个 url 加载资源，这下网站的可用性又提升了一点点🤏哈哈哈

扩展阅读

网站 profile工具

https://www.webpagetest.org

国外静态网站托管服务商国内速度对比及线路优化

Thu, 05 May 2022 00:00:00 +0000

国外静态网站托管服务商国内速度对比及线路优化

本文主要探讨 Netlify、Vercel、Cloudflare Pages、Azure Web Hosting 在国内的速度对比及线路优化

以我的博客站点 blog.colinx.one 为例，使用 hugo 构建，选用的模板也很轻量没有太多奇奇怪怪的第三方组件，使用这些静态服务托管主要图个方便，不用备案而且基本流量不限。

分别挂了四个服务商的 CI, 每次更新 Git 仓库都会自动触发构建。分别对四个默认分配的域名进行检测。

四家服务商默认设置国内速度测试对比

Netlify

colins-blog.netlify.app

Vercel

colinx-blog.vercel.app

Azure

nice-glacier-095b09e00.1.azurestaticapps.net

CloudFlare Pages

colinx-blog.pages.dev

emmm Cloudflare 这在国内的速度可太拉胯了，虽说可以通过自选节点的方式曲线救国，但想了想还是算了。利用好其他三家的节点应该足够国内大部分用户访问。

—Update on 2022-05-22—

又重新测了一下 cloudflare 的速度，这次倒是一片绿，看来还是要运气，不太稳定。电信和联通都嗖嗖的，移动基本上全挂了。。。

这次能连接的节点主要就两个 172.66.45.34 和 172.66.46.222。

—end—

筛选后可用的节点

Netlify
18.140.226.100 amazon SG
54.255.56.197 amazon SG
206.189.46.168 digital ocean SG
Vercel
显示caronet，据说为AWS节点 (76.76.21.21 Anycast)
76.76.21.241
76.76.21.98
76.76.21.93
76.76.21.142
76.76.21.22
76.76.21.61
76.76.21.164
Azure
52.175.64.109 US MS
13.70.37.114 HK MS
51.124.12.35 UK

优化前

优化前使用了 dnspod 的解析服务做 4 个 A 记录的负载均衡，免费版套餐单记录单线路只能设置最多两个负载均衡记录，我这个是之前开通专业版套餐设置的，套餐到期了原有记录依旧保留，所以能设置四条同线路 A 记录负载均衡。

before
206.189.46.168 digital ocean %netlify
76.223.126.88 %vercel
18.140.226.100 amazon %netlify
18.139.201.98 amazon %netlify

检测一波，红了好几个省份

慢点可以接受，线路不通可不能忍。之前粗略筛的几个节点，如今过了快两年了，线路估计也发生了变化，简单跑了一下这几条，发现这个线路现在的状况实在不咋地

这圈子兜的也太大了些。。。哦原来是 Digital Ocean 的节点啊，那没事了。

亚马逊的节点稍微好些，没有绕道日本这么离谱的行为

再来看看 vercel 节点的表现

这里是自选的节点，直连东京节点，好评

但是默认的 AnyCast 节点这个路由就稍微绕路了，看来大中华区还是得自己动手调整下线路

优化后

after

检测优化过程就不赘述了，都是拿几个基本的工具ping、tcping、httping、traceroute还有上文的全国网速检测网站对那几个节点挨个检测，直接上结论：

Vercel 的 Anycast 基本上都是路由到日本，但是同一个地方可能会被路由到不同的路线，比如有些 IP 从上海出口转日本东京，有些是从广东出口转日本
Netlify 的节点主要是在新加坡，提供商有 AWS 和 Digital Ocean，实测后者的节点经常性抽风，国内流量过去会绕个大圈子，还是 AWS 的靠谱些
Azure 的静态网页托管服务现在是免费的，带宽和流量啥的妥妥够用，不过开账户有门槛，我是用 Github Education Pack 在 Azure 开了个 Azure for Students 订阅，每年 100 刀额度，到期可续
Azure 能用的就香港节点，其他都是去往北美和欧洲的，直接 pass。对电信友好，移动和联通很不友好，饶了一大圈
AWS 的节点对移动和联通挺友好，对电信支持略差
Vercel 节点也是对移动和联通友好些

其他附加信息

Netlify 可自定义证书，Vercel 不可以。所以要保证 vercel 的服务器可以把域名解析到自家服务器，不然没法续签 SSL 证书
Cloudflare 的 CI 啥的做的挺垃圾，起步晚，很多东西不完善
Netlify 可以安装插件，推送 sitemap 和网站安全性检测这些我感觉挺好使

最终线路设置

电信和其他走 Azure 与 Vercel
移动联通走 Netlify 的 AWS 节点，以及 Vercel 在 JP 的节点
海外走 Vercel 的 Anycast IP

常用线路检测与优化工具链接

Best Trace

https://apps.apple.com/us/app/best-trace/id1037779758?l=zh

IP 批量查询

http://www.jsons.cn/ipbatch/

Flutter 拖动排序列表与跨平台优化实践

Tue, 30 Mar 2021 00:00:00 +0000

Flutter 中实现拖动排序的列表非常简单，使用官方的ReorderableListView替代原本的ListView即可，ListView.builder同理。

 return ReorderableListView(
// padding: const EdgeInsets.symmetric(horizontal: 40),
 children: <Widget>[
for (int index = 0; index < _items.length; index++)
ListTile(
key: Key('$index'),
tileColor: _items[index].isOdd ? oddItemColor : evenItemColor,
title: Text('Item ${_items[index]}'),
),
],
onReorder: (int oldIndex, int newIndex) {
setState(() {
if (oldIndex < newIndex) {
newIndex -= 1;
}
final int item = _items.removeAt(oldIndex);
_items.insert(newIndex, item);
});
},
);
}

上面是官方给的 demo，简洁明了。官方介绍视频下面的评论里，人家直呼比原生 Android 写的过瘾的多。阅读文档后我给我的 App 的界面也加上了可拖动排序的功能。效果如下图

虽然可以实现拖动了，但是右边有一个按钮很碍眼。不过这个是用来控制拖动的，鼠标移上去才能触发拖动。

翻了翻文档发现，这个地方ReorderableListView在移动端和桌面端的处理是不一样的，上图（桌面 macos）右边会出现一个 dragHandler，而移动端则是靠长按列表项触发拖动。

要把这个碍眼的图标去掉，有两个方案：

找到定义这个图标的地方，更换一个合适的图标，并在外面包裹一层，仅在鼠标 hover 时将图标显示以进行拖动，其他情况下隐藏
将拖动的实现定义为和移动端相同，即都通过长按列表项触发拖动

针对方案一，以ReorderableListView 和Icon为关键词搜索，很遗憾的是并没有这方面的资料，又翻了翻源码，并没有找到可以自定义右边这个拖拽按钮的实现。

在 Flutter 官方的 Github 仓库的 issue 中，https://github.com/flutter/flutter/issues/66080#issuecomment-771123430 对相关问题做了阐述，并有提案对ReorderableListView进行了改进。该 issue 对应的 pr 已经被合并到 stable channel，查阅相关 API 后了解到可以使用buildDefaultDragHandles: false，关闭默认的拖拽触发实现，再使用ReorderableDelayedDragStartListener包裹原先的ListTile即可实现桌面端和移动端都通过长按列表项触发拖拽排序。

不过相应的，ListTile 的onLongPress就不能再有响应了。刚好今天完成了滑动删除的实现，现在列表也的删除、排序已经高度可用且多平台统一了。

附相关代码实现：

body: ReorderableListView.builder(
buildDefaultDragHandles: false,
onReorder: (int oldIndex, int newIndex) {
setState(() {
if (oldIndex < newIndex) newIndex -= 1;
var temp = l.removeAt(oldIndex);
l.insert(newIndex, temp);
});
},
itemCount: l.length,
itemBuilder: (context, index) {
final item = l[index];
return Dismissible(
key: item.key,
background: listTileBackground(),
onDismissed: (direction) {
setState(() {
lastDeleted = item;
l.removeAt(index);
});
ScaffoldMessenger.of(context).showSnackBar(msgDeleted);
},
child: ReorderableDelayedDragStartListener(
key: item.key,
index: index,
child: ListTile(
title: Text(item.title),
subtitle: Text(item.content),
contentPadding: EdgeInsets.fromLTRB(16, 8, 16, 8),
onTap: () {
//your function here
 },
// onLongPress: () {
 // lastDeleted = item;
 // l.removeAt(index);
 // setState(() {});
 // ScaffoldMessenger.of(context)
 // .showSnackBar(msgDeleted);
 // },
 )));
})));

Colin's 实验室 - 2021 春

Thu, 25 Feb 2021 00:00:00 +0000

小玩具及他们的 demo

英语文本智能查词（Project Sweeper）

自动分割给定的英文文本，提取词元后在数据库中搜索，根据给定的词汇量和难度等级进行筛选，只能提取阅读障碍词汇并高亮当前备考项目（如四级）的重点单词

知乎爬虫及 JS 逆向

日常用 RSS 订阅知乎的一些高质量专栏。但由于知乎本事并不支持 RSS，内容大多通过 RSShub 来的，其本质是个爬虫，经常会受到前端页面结构变更的影响。为了应对这个变化，RSShub 中对于知乎相关页面的爬取规则必须得重写。

分析了一通知乎的页面，发现有个接口可以直接请求，但是会检验 header。header 里面有几项特殊的自定义参数，x-zse-83 和 x-zse-86等。为了搞清楚这里面的数值怎么来的，就必须对知乎前端页面资源中的一个 js 文件进行逆向分析。

逆向折腾了大半天，就快要成功提取核心加密函数的时候，发现知乎的前端页面为了 SEO 有加入一页的文章列表数据，可以直接用上。考虑到逆向的工作量和潜在的法律问题，遂放弃原本的方案。

新的方案完成后，已向 RSShub 提交 PR 并已被合并。

MC 服务器搭建与极限优化

1 核 2G 学生机，从 2 人联机频频崩溃到 8 人挖矿毫无压力，学习了 JVM GC 种种，对服务端程序的一些参数也渐渐熟悉。优化效果喜人，总有还能压榨的性能，就像资本家看手下的骡子一样 hhh

洞洞板/冰箱贴/CVPRO/（…没想好名字）

一款跨平台的灵感素材收集与简易管理 App，基于 Flutter 构建，跨平台，颜值在线。

持续开发中，附 roadmap

version 1.0

[x] Text support
[x] Key shortcut support
[x] About Page
[ ] Content editing
[x] List item dismiss [x] List Sorting

Future - Key functions

[ ] Data Storage
[ ] Pic support
[ ] Trashbin
[ ] File support
[ ] Multiple List

Future - Key features

[ ] Grid view
[ ] Drag and Drop support
[ ] Card resize

Future - Extra

[ ] Text reformat, delete useless spaces etc.
[ ] Pic OCR support
[ ] WebDav support and automatically upload files<10M

JAMStack 初体验 - 基于 Pocket 和 Gatsby 构建你的「网络日志」

Sat, 09 Jan 2021 00:00:00 +0000

折腾了自己的专属 RSS 信息流，每天都能从那些高质量的信息源中获得不少干货知识，一般就会顺手收藏一下。有一天突然想起自己收藏的那些文章，本身不就是经过二次筛选的高质量文章吗？于是便在构想能不能通过某种方式将这个信息源也公开出来，一方面是记录，另一方面也是间接地展示自己。恰逢遇见JAMStack，最近在国外非常火，国内的阿里和腾讯也在跟进，搞静态托管那一套。经多方物色，最终确定基于Pocket API+Gatsby来构建这样一个自己的「网络日志」。

You are what you read.

简谈 JAMStack

JAMStack 即基于客户端 JavaScript，可重用 API 和预先构建 Markup 的现代 Web 开发架构。当我们谈论“堆栈”时，我们不再谈论操作系统，特定 Web JAMStack 与特定技术无关。这是一种构建网站和应用程序的新方法，可提供更好的性能，更高的安全性，更低的扩展成本以及更好的开发人员体验。

JAMStack 是一种新颖的网站架构，与传统的服务端渲染和近些年国内流行的前后端分离等架构不同的是，他的网页是静态的，可以托管在 CDN 上，内容是动态的，可以方便地进行修改。

JAMStack 几个显著的优势：

页面为静态，TTFT（TimeToFirstByte）的时间可以降到非常低
页面为静态，服务器遭受的安全风险要低得多
不同于客户端渲染，JAMStack 对 SEO 会非常友好
不同于传统纯静态网站，内容可以方便地动态更新

为什么选择 Gatsby

作为一个网站生成器 Site Generator，Gastby 的入门门槛其实是较高的，相对于 Hexo、Hugo 那种简简单单配置下就是一个站点，Gatsby 的难度要更高，因为其灵活度更大，所有的配置、页面都是 Javascript 来配置的，当然你也可以使用 Typescript。其基于 React，生态丰富且灵活度高，天生GarphQL是选择它的主要原因。

网站架构及效果

流程：

我在其他地方看到不错的文章，将其收藏到 Pocket
定时任务，从Pocket API获取文章数据，交给 Gatsby 生成站点
自动部署，将生成的静态文件部署到 CDN
reading.colinx.one站点主页就会出现我收藏的文章啦

这其中，Gastby 充当的是Site Generator的角色，而数据来源为我的Pocket API，也就是我把 Pocket 作为Headless CMS来管理我的数据，可以方便地进行更新和管理。

总结

项目已经开源，地址在https://github.com/Colin-XKL/Colinx-Reading.git。你也可以去申请自己的 Pocket API 然后部署你自己的站点。

初始尝试 JAMStack，感觉对于博客、文档这类的站点会非常友好，国外比较火的像 Shopify 这种的无头电商也不错，国内的碍于国情应该不大可能了。

链接

Welcome to the Gatsby Way of Building | Gatsby https://www.gatsbyjs.com/docs/
For fast and secure sites | Jamstack https://jamstack.org/

技术 on Colinx Blog

OpenClaw 虽好，搭配沙箱才安心 - 使用 Lume 构建 mac 虚拟环境

OpenClaw Gateway 安装 #

MacOS VM via Lume #

Search-as-a-RSS! 把任何搜索查询转换为 RSS! FeedCraft 新功能速递

前言 #

FeedCraft 如何通过搜索结果创建 RSS #

LLM Agent is All You Need - 让 AI 指导我完成 MVP 产品 - 「Colin's Weekend Project」

idea #

如果一切都从 LLM 开始… #

「AI 教我做产品」 #

Vibe Coding #

埋点上报与用户行为分析 #

投放 #

The End #

安全不是特权 - 雷池 WAF 使用体验及部署安装教程

使用体验 #

安装部署流程 #

1. 获取 compose 文件 #

2. 安装部署 #

总结 #

关于双语字幕这件小事

1. 考虑寻找现成的高质量字幕 #

2. 字幕的时间轴修正 #

3. 自制双语字幕 #

后记 #

个人向 Linux 新服务器初始化清单

1 - 基础环境搭建 #

1.1 防火墙 #

1.2 新建用户与检查 sudoer #

1.3 镜像源与基础软件 #

更换国内镜像源 #

基础软件 #

1.4 SSH 安全 #

1.5 设置 hostname #

1.6 SWAP #

1.7 绑定域名 #

1.8 添加本地 SSH 别名 #

2 - 常用工具与配置 #

2.1 Docker 环境 #

Docker 安装 #

Docker 镜像源配置及日志配置 #

2.2 OH-MY-ZSH #

2.3 nano 代码文件规则 #

2.4 时区调整 #

2.5 厂商监控/SDK 卸载 #

2.6 fail2ban 配置 #

2.7 Git 代理 #

3 - 进阶内容 #

3.1 内核参数调优 #

3.2 更多内存空间 - ZRAM #

3.3 更多内存空间 - 关闭 kdump，释放预留的内存空间 #

3.3 其他进阶配置 #

附录 #

2023 静态网站托管服务速度对比

特邀嘉宾：腾讯云海外 CDN #

腾讯云海外 CDN #

晚高峰测速结果 #

其他补充信息： #

Vercel #

Netlify #

Cloudflare Pages #

Azure Static Pages #

策略 #

Huginn 指南：为任意网站制作 RSS

Huginn 爬取普通网页制作 RSS #

Website Agent #

Data output Agent #

使用 Huginn+Browserless 为动态网页生成 RSS #

Post Agent #

使用 PhantomJS 为动态页面生成 RSS #

Phantom JS Cloud Agent #

FAQ #

扩展阅读 #

前端静态资源加载的一些优化

静态资源异步加载 #

静态资源 Fallback 加载 #

扩展阅读 #

国外静态网站托管服务商国内速度对比及线路优化

国外静态网站托管服务商国内速度对比及线路优化 #

OpenClaw Gateway 安装

MacOS VM via Lume

前言

FeedCraft 如何通过搜索结果创建 RSS

idea

如果一切都从 LLM 开始…

「AI 教我做产品」

Vibe Coding

埋点上报与用户行为分析

投放

The End

使用体验

安装部署流程

1. 获取 compose 文件

2. 安装部署

总结

1. 考虑寻找现成的高质量字幕

2. 字幕的时间轴修正

3. 自制双语字幕

后记

1 - 基础环境搭建

1.1 防火墙

1.2 新建用户与检查 sudoer

1.3 镜像源与基础软件

更换国内镜像源

基础软件

1.4 SSH 安全

1.5 设置 hostname

1.6 SWAP

1.7 绑定域名

1.8 添加本地 SSH 别名

2 - 常用工具与配置

2.1 Docker 环境

Docker 安装

Docker 镜像源配置及日志配置

2.2 OH-MY-ZSH

2.3 nano 代码文件规则

2.4 时区调整

2.5 厂商监控/SDK 卸载

2.6 fail2ban 配置

2.7 Git 代理

3 - 进阶内容

3.1 内核参数调优

3.2 更多内存空间 - ZRAM

3.3 更多内存空间 - 关闭 kdump，释放预留的内存空间

3.3 其他进阶配置

附录

特邀嘉宾：腾讯云海外 CDN

腾讯云海外 CDN

晚高峰测速结果

其他补充信息：

Vercel

Netlify

Cloudflare Pages

Azure Static Pages

策略

Huginn 爬取普通网页制作 RSS

Website Agent

Data output Agent

使用 Huginn+Browserless 为动态网页生成 RSS

Post Agent

使用 PhantomJS 为动态页面生成 RSS

Phantom JS Cloud Agent

FAQ

扩展阅读

静态资源异步加载

静态资源 Fallback 加载

扩展阅读

国外静态网站托管服务商国内速度对比及线路优化

四家服务商默认设置国内速度测试对比

优化前

优化后

常用线路检测与优化工具链接

英语文本智能查词（Project Sweeper）

知乎爬虫及 JS 逆向

MC 服务器搭建与极限优化

洞洞板/冰箱贴/CVPRO/（…没想好名字）

简谈 JAMStack

为什么选择 Gatsby

网站架构及效果