HY博客

OpenClaw 安装、卸载与更新：一篇带你学会

HY博客 — Fri, 20 Mar 2026 00:00:00 GMT

本教程采用 Linux 服务器部署方式。

不建议把 OpenClaw 作为“常用 Windows 桌面软件”来安装运行：一方面 Windows 环境下的网络/权限/守护进程模型更复杂；另一方面聊天/网关类服务通常涉及密钥与持久化数据，更推荐放在独立服务器或 WSL2 中集中管理，降低日常桌面环境的意外风险。

安装（macOS/Linux/WSL2 统一采用 install.sh）

我们采用官方脚本安装：

curl -fsSL https://openclaw.ai/install.sh | bash

安装完成后建议运行新手引导（会配置认证、Gateway，并可安装守护进程/服务）：

openclaw onboard --install-daemon

检查网关状态：

openclaw gateway status

打开控制面板（最快开始聊天/调试）：

openclaw dashboard

第一次真正跑 openclaw onboard --install-daemon 时，还会经历一轮交互式配置。首次安装时，通常可以按下面这套思路来选：

personal-by-default ... Continue? → 选 Yes，按个人使用场景继续。
Onboarding mode → 选 QuickStart，先把主流程跑通，细节后面再配。
Model/auth provider → 如果你用的是 Z.AI，就选 Z.AI。
Z.AI auth method → 选 CN (Z.AI CN / open.bigmodel.cn)。
How do you want to provide this API key? → 选 Paste API key now，直接写入配置，适合个人 VPS；但不要泄露 API Key。

安装完成后，建议立刻用下面几条命令确认网关是否真的起来了：

openclaw status
openclaw gateway status
ss -lntp | grep 18789

只要看到 127.0.0.1:18789 处于监听状态，就说明 Gateway 已经在本机跑起来了。

配置渠道

Dashboard

如果 OpenClaw 安装在远程 Linux 服务器上，Dashboard 默认只监听本机回环地址，也就是：

127.0.0.1:18789

这意味着 Dashboard 默认不会直接暴露到公网。最常见、也最安全的访问方式，是先在服务器上拿到 Dashboard 地址，再通过 SSH 隧道转发到自己电脑上访问。

先在服务器上执行：

openclaw dashboard --no-open

你会看到类似下面的输出：

Dashboard URL: http://127.0.0.1:18789/#token=xxxxxxxx

如果你是在自己电脑上访问这台远程服务器，就先建立端口转发：

ssh -N -L 18789:127.0.0.1:18789 root@你的服务器IP

然后在本地浏览器打开：

http://localhost:18789/

或者直接打开带 token 的完整链接：

http://localhost:18789/#token=xxxxxxxx

这里最容易搞混的一点是：远程服务器上的 127.0.0.1，并不是你本地电脑浏览器里的 127.0.0.1。 所以只要是“远程部署 + 本地浏览器访问”的场景，通常都要先走 SSH 隧道。

另外，页面如果要求手动填写 token，建议直接复制 openclaw dashboard --no-open 输出的完整 URL，不要手敲，避免少字符、多空格，或者复制时漏掉一截。

飞书

如果你要把 OpenClaw 接到飞书，QuickStart 里直接选择 Feishu/Lark (飞书) 即可。随后它会要求你填写飞书应用的 App ID 和 App Secret，并自动安装对应插件。

除了填凭据，飞书应用本身也要在开放平台里配完整，至少确认以下几项：

创建的是 企业自建应用
已开启 机器人能力
配置机器人权限：JSON 文件可批量导入 https://uee.ee/feishu
事件订阅使用 长连接（WebSocket）
已添加事件：im.message.receive_v1
应用已经发布，而不是只保存在草稿态

如果这些没配好，就很容易出现“机器人已经加进群了，但就是不回消息”的情况。

还有一个首次接通时经常碰到的现象：你私聊机器人后，它没有直接进入对话，而是返回类似下面的提示：

access not configured
Pairing code: XXXXXXXX

这不代表飞书配置失败，恰恰说明链路已经通了，只是当前账号还没被授权。此时只需要在服务器上执行：

openclaw pairing approve feishu <配对码>

批准之后，再回到飞书私聊机器人发一句“你好”，通常就能正常开始对话。

微信

如果你要把 OpenClaw 接到微信，可以在运行 OpenClaw 的那台机器上执行：

npx -y @tencent-weixin/openclaw-weixin-cli@latest install

执行后，终端会安装微信插件，并进入扫码登录流程。此时不要急着关掉终端，按提示继续即可。通常流程是：

在终端里等待二维码输出。
用微信扫一扫二维码。
在微信页面里点绿色的“连接”按钮，确认把 OpenClaw 绑定到微信。
连接完成后，在微信里发一条测试消息，例如 hello world，确认机器人已经能正常回复。

按这套流程走通之后，就说明微信通道已经接入成功，可以正常通过微信和 OpenClaw 对话。

QQ

腾讯现已正式宣布 QQ 开放平台接入 OpenClaw，整体部署流程也比较直接。

第一步，登录 QQ 开放平台：

https://q.qq.com/

进入对应入口后创建机器人，拿到自己的 AppID 和 AppSecret。

接入 OpenClaw 时，常用步骤可以直接概括为下面三条命令：

安装 OpenClaw 社区 QQBot 插件：

openclaw plugins install @sliverp/qqbot@latest

配置并绑定当前 QQ 机器人：

openclaw channels add --channel qqbot --token "AppID:AppSecret"

这里的 AppID:AppSecret 要替换成你自己的实际凭据，不要直接照抄示例。

重启本地 OpenClaw 服务：

openclaw gateway restart

完成后，就可以在 QQ 侧测试机器人是否已经能正常接收并回复消息。

基础使用教程

OpenClaw 安装后的基本结构

OpenClaw 装好之后，最常接触到的通常不是一大堆复杂目录，而是几个核心文件和路径：

~/.openclaw/openclaw.json：主配置文件，渠道、模型、网关、工具权限等基本都在这里配。
~/.openclaw/workspace/：默认工作区，平时的项目、技能、文档和一些自定义内容一般都放这里。
~/.openclaw/workspace/MEMORY.md：长期记忆文件，用来记录稳定偏好、长期项目背景、关键决策。
~/.openclaw/workspace/memory/：日常记忆目录，适合按日期记录临时进展、当天事项和阶段性信息。
~/.openclaw/extensions/：已安装插件目录，例如飞书、微信、QQBot 这类渠道插件通常会出现在这里。

如果只是个人使用，实际最需要先认识的就是：配置文件 openclaw.json、工作区 workspace/，以及长期记忆文件 MEMORY.md。

常用命令

OpenClaw 装好之后，日常最常用的命令和消息操作通常包括这些：

/new：开启一个新会话。
/reset：重置当前会话。
/status：查看当前状态。
openclaw status：查看整体状态、Gateway、渠道、会话等概况。
openclaw gateway status：查看网关状态。
openclaw gateway restart：重启网关。
openclaw dashboard：打开控制面板。
openclaw dashboard --no-open：只输出 Dashboard 地址和 token，适合远程服务器场景。
openclaw logs --follow：实时查看日志，排查渠道不回复、插件报错、连接失败等问题时很有用。

如果只是刚装好，最实用的一套顺序通常是：先看 openclaw status，再试 openclaw dashboard，最后在实际渠道里发一条消息验证是否已经能正常回复。

更新

如果后续需要更新 OpenClaw，通常再次执行官方安装脚本即可：

curl -fsSL https://openclaw.ai/install.sh | bash

执行完成后，记得重启网关：

openclaw gateway restart

更新后建议顺手确认一下当前状态：

openclaw --version
openclaw status

卸载（彻底清除：包含 ~/.openclaw 数据）

在 Linux 上“彻底卸载”（包括 ~/.openclaw 数据目录）最省心的方法就是用 OpenClaw 自带的卸载器。

如果你只想删除 CLI 但保留数据，请不要运行带 --all 的命令。

1) 一条命令彻底卸载（推荐）

openclaw uninstall --all --yes --non-interactive

参数含义：

--all：卸载服务 + 删除状态/数据目录（包括 ~/.openclaw）
--yes：默认确认
--non-interactive：非交互模式，适合在 SSH / 自动化里跑

2) 这条命令到底删了什么？

你会看到类似输出（示例已脱敏主机名）：

🦞 OpenClaw 2026.2.17 (4134875) — Chat APIs that don't require a Senate hearing.

Stopped systemd service: openclaw-gateway.service
Removed systemd service: /root/.config/systemd/user/openclaw-gateway.service
Removed ~/.openclaw
Removed ~/.openclaw/workspace
CLI still installed. Remove via npm/pnpm if desired.

逐行解释：

Stopped systemd service: openclaw-gateway.service
- 停止 systemd 用户级服务，确保网关进程不再运行。
Removed systemd service: /root/.config/systemd/user/openclaw-gateway.service
- 删除该服务的 unit 文件。
- 结果：以后不会再自动启动 Gateway。
Removed ~/.openclaw
- 删除 OpenClaw 的默认状态目录（state dir）。
- 这里通常包含配置、运行状态、日志、插件数据、缓存等。
Removed ~/.openclaw/workspace
- 删除 OpenClaw 默认工作区（智能体文件、技能、以及你放在其中的项目文件等）。
CLI still installed...
- 说明：卸载器帮你把“服务”和“数据”清了，但 openclaw 这个命令本体还在（通常是通过 npm 全局安装的）。

3) 把 CLI 也卸载掉（真正“一个不剩”）

脚本安装（install.sh）一般会通过 npm 全局安装 CLI，直接执行：

npm rm -g openclaw
hash -r

为什么是两个命令？`hash -r` 是什么？

npm rm -g openclaw：卸载 OpenClaw CLI（从 npm 全局目录移除）。
hash -r：让当前 shell 清空“命令路径缓存”，避免出现刚卸载完却还提示能找到命令的错觉。
- 不想执行 hash -r 也可以：重新开一个终端再验证。

4) 验证是否卸载干净

command -v openclaw || echo "openclaw not found"
openclaw --version

command -v openclaw 输出为空并打印 openclaw not found：说明 PATH 下已找不到命令。
openclaw --version 报 command not found：这是预期结果。

5) 常见坑与补充

多 Profile 情况：如果你使用过 --profile / OPENCLAW_PROFILE，状态目录可能是 ~/.openclaw-<profile>，需要对每个 profile 目录分别清理。
远程模式：状态目录在运行 Gateway 的那台机器上；卸载也需要在那台机器上操作。

Vaultwarden（Docker）怎么查看版本并升级？一套可复制的更新流程

HY博客 — Sun, 15 Mar 2026 00:00:00 GMT

域名、主机名、真实目录、容器 ID、时间戳、Token/密钥等信息均已替换为示例值。

命令输出为示例输出，仅用于帮助你识别成功/失败状态。

Vaultwarden（非官方 Bitwarden 服务端实现）用 Docker/Compose 部署后，升级维护的核心目标只有三个：

版本可核对（升级前后都能确认版本变化）
数据不丢（卷挂载目录可备份、可恢复）
变更可回滚（至少能退回到上一个镜像/配置）

下面按一套“可复制”的流程来做。

0）前提：确认你有 Docker 权限

先试：

docker ps

能输出容器列表：权限 OK
若报 permission denied：用 sudo 或切 root

常用（切 root）：

sudo -i

1）进入 compose 目录

找到放着 docker-compose.yml 的目录（示例：/opt/vaultwarden）：

cd /opt/vaultwarden
ls

一般会看到：

docker-compose.yml
vw-data/（Vaultwarden 数据目录，示例名）

你的实际数据目录以 compose 里 volumes: 挂载为准。

2）查看 Vaultwarden 与 Web-Vault 版本（最准确）

直接在容器里查：

docker exec -it vaultwarden /vaultwarden --version

示例输出：

Vaultwarden 1.35.3
Web-Vault 2026.1.1

Vaultwarden：后端服务版本
Web-Vault：网页端静态资源版本

3）（强烈建议）升级前备份数据目录

如果你是这样挂载的（示意）：

volumes:
  - ./vw-data:/data

那么在 compose 目录下打包备份即可：

tar -czf vw-data-backup-$(date +%F).tgz vw-data

升级通常很稳，但备份是“低成本保险”。

4）拉取最新镜像

如果你的 compose 使用 latest：

services:
  vaultwarden:
    image: vaultwarden/server:latest

那么更新时拉取最新镜像：

docker compose pull

常见提示：`version is obsolete`

你可能会看到：

the attribute `version` is obsolete, it will be ignored

这表示 Docker Compose v2 不再需要顶层 version: "3"，会忽略它。

不影响运行
想消除提示：把 docker-compose.yml 顶层的 version: "3" 删除即可

5）用新镜像重建并后台启动

docker compose up -d

如果输出里出现 Recreated / Started，通常表示已成功用新镜像重建。

6）验收：看日志 + 再查一次版本

看启动日志（示例取最后 50 行）：

docker logs -n 50 vaultwarden

很多版本会在启动 banner 里显示，例如：

Starting Vaultwarden
Version 1.35.4

再查一次版本确认：

docker exec -it vaultwarden /vaultwarden --version

示例：

Vaultwarden 1.35.4
Web-Vault 2026.1.1

7）（可选）清理旧镜像，释放磁盘

docker image prune -f

这会清理“未被引用”的镜像层，不影响正在运行的容器。

8）安全加固：把 ADMIN_TOKEN 从明文改为 Argon2 哈希（推荐）

如果日志出现类似提示：

You are using a plain text ADMIN_TOKEN which is insecure.

说明你在 compose 里配置了明文管理员 Token。建议改为 Argon2 PHC 哈希，降低配置泄露风险。

8.1 生成 Argon2 哈希

在服务器上执行（会提示你输入原始 token；不要把 token/哈希粘贴到公开场合）：

docker exec -it vaultwarden /vaultwarden hash

会输出形如：

$argon2id$v=19$m=65540,t=3,p=4$...$...

8.2 替换 compose 里的 ADMIN_TOKEN

把（示意）：

environment:
  ADMIN_TOKEN: "你的明文token"

替换为：

environment:
  ADMIN_TOKEN: "$argon2id$..."

然后应用变更：

docker compose up -d

9）最小化“升级 SOP”（你可以贴到运维手册里）

cd /opt/vaultwarden

docker exec -it vaultwarden /vaultwarden --version

tar -czf vw-data-backup-$(date +%F).tgz vw-data

docker compose pull
docker compose up -d

docker logs -n 50 vaultwarden
docker exec -it vaultwarden /vaultwarden --version

10）常见故障：升级后突然打不开（ERR_TIMED_OUT / 只看到 SYN 没有 SYN-ACK）

这一类问题非常像应用挂了，但实际上经常是「云厂商的安全 sysctl 配置 + Docker 端口转发」组合导致的网络层问题。

典型症状：

浏览器访问 https://pass.example.com 直接 ERR_TIMED_OUT
服务器本机 curl -I https://127.0.0.1 -H 'Host: pass.example.com' 能返回 200（说明 nginx/Vaultwarden 正常）
抓包只看到外网 SYN 进来，但服务器没有回 SYN-ACK

10.1 快速定位思路（建议按顺序走）

确认容器与端口监听

docker ps
ss -lntp | egrep ':80|:443'

确认本机（内网 IP）443 正常（以云主机网卡 IP 为例）

curl -kIv https://10.0.0.2 --connect-timeout 3

确认 DNAT 是否在工作（外网访问一次后看计数器是否增长）

nft list chain ip nat DOCKER

如果 tcp dport 443 ... dnat to 172.xx.xx.xx:443 的 counter packets 会增长，说明外网请求已到达并进入 DNAT。

抓包判断是否回 SYN-ACK

tcpdump -ni <nic> 'tcp port 443 and (tcp[tcpflags] & (tcp-syn|tcp-ack) != 0)'

只有 SYN 没有 SYN-ACK，基本就是系统层转发/过滤问题。

10.2 云主机常见根因：`ip_forward=0`

不少云镜像会通过安全策略把 IPv4 转发关掉（例如存在类似 60-*-network-security.conf 的 sysctl 文件），而 Docker 的端口转发/桥接依赖它。

检查：

sysctl net.ipv4.ip_forward

如果输出是 net.ipv4.ip_forward = 0，就会出现「DNAT 计数器涨，但流量进不了容器网桥」的情况，外网访问自然超时。

临时修复（立刻生效，无需重启）：

sysctl -w net.ipv4.ip_forward=1

如果系统没有 /proc/sys/net/bridge/* 相关项，说明 br_netfilter 未加载；可按需加载并启用：

modprobe br_netfilter
sysctl -w net.bridge.bridge-nf-call-iptables=1

永久化（推荐）

cat >/etc/sysctl.d/99-docker-forwarding.conf <<'EOF'
net.ipv4.ip_forward=1
net.bridge.bridge-nf-call-iptables=1
EOF

sysctl --system

以及让模块开机自动加载：

cat >/etc/modules-load.d/br_netfilter.conf <<'EOF'
br_netfilter
EOF

注意：以上为公开教程示例。实际环境请结合你的安全策略评估是否需要同时启用 bridge-nf-call-ip6tables 等选项。

结语

Vaultwarden 的 Docker 升级并不复杂，关键在于：

升级前后都要 核对版本
数据卷要 可备份
对外发布文档要打码（域名/主机名/目录/Token 全部不要出现）

如果你希望更可控的升级策略（避免 latest 带来不可预期变更），建议把镜像 tag 固定为明确版本号，并在测试环境验证后再滚动到生产。

SSH 连不上服务器时，几种中转方案的实战总结

HY博客 — Mon, 09 Mar 2026 00:00:00 GMT

很多人都会遇到这种情况：服务器在线，SSH 服务看起来也正常，但本地网络就是连不上，直接 SSH 不是超时就是卡住。

这次我碰到的就是一个很典型的场景：本地网络无法直接连接目标服务器，但通过另一台日本服务器做 SSH 跳板后成功连通。顺着这次排障过程，我把几种常见的中转方案也一起梳理了一遍。

一、先说结论：问题往往不在“域名”，而在“连接路径”

很多人的第一反应是：

我有 Cloudflare 域名，直接把 A 记录解析到服务器，再开代理，是不是就能 SSH 了？

答案是：不行，不能直接靠普通橙云代理原生 SSH。

Cloudflare 普通代理主要面向的是：

HTTP
HTTPS
WebSocket
一些 Web 协议相关流量

而 原生 SSH 并不是普通 Cloudflare 橙云直接代理的对象。也就是说：

网站开橙云没问题
SSH 不能指望开个代理就直接打通

所以，很多时候问题不在“域名配没配对”，而在“你现在选的连接路径本身就不适合 SSH”。

二、方案 1：灰云直连（仅 DNS）

适用场景

你怀疑是 Cloudflare 橙云影响了直连
你的本地网络本身并没有屏蔽服务器
你只是想让域名直接解析到服务器 IP

做法

把 Cloudflare 上对应记录从：

已代理（橙云）

改成：

仅 DNS（灰云）

然后直接测试：

ssh root@your-domain.com

本质上等价于：

ssh root@服务器IP

优点

简单
适合快速排查
不需要额外安装工具

缺点

不解决“本地网络屏蔽服务器”的问题
22 端口仍然暴露公网
安全性一般

结论

灰云只能解决“别让 Cloudflare 橙云挡住 SSH”这个问题，不能解决网络本身不通的问题。

三、方案 2：Cloudflare Tunnel 中转 SSH

这是更正规的做法。

原理

目标链路会变成：

本地 SSH -> cloudflared -> Cloudflare -> Tunnel -> 服务器 localhost:22

也就是：

服务器主动连接 Cloudflare
本地通过 cloudflared 接入
不需要在公网暴露 22 端口

适用场景

本地网络不能直连目标服务器
服务器本身可以正常出网
你已经有 Cloudflare 域名
想要长期、安全、规范的方案

优点

不必公网暴露 SSH 端口
比直开 22 更安全
可以结合 Cloudflare Access 做身份控制

缺点

配置比灰云复杂
服务器端和本地都要安装 cloudflared

适合谁

如果你有 Cloudflare 域名，又希望把 SSH 接入做得更优雅一些，Cloudflare Tunnel 值得长期使用。

四、方案 3：SSH 跳板机 / Bastion Host

这是这次实际排障里真正跑通的方案。

原理

你的本地不能直接到目标服务器，那就先连另一台能访问的机器，再从那台机器跳过去：

本地 -> 跳板机 -> 目标服务器

例如：

本地不能直连目标服务器
但能连上另一台日本服务器
日本服务器又能访问目标服务器的 22 端口

这时就可以把日本服务器当作跳板机。

命令行写法

ssh -J user@跳板机IP root@目标服务器IP

例如：

ssh -J root@jump-server-ip root@target-server-ip

图形客户端

很多 SSH 客户端都直接支持：

Jump Host
ProxyJump
SSH Tunnel
Bastion Host
跳板机

只要在目标连接里指定一台代理主机即可。

这次实测结果

通过图形 SSH 客户端把日本服务器设为跳板后，最终成功登录到目标机。验证方式包括：

登录来源显示为跳板机 IP
hostname 显示为目标服务器主机名
curl ifconfig.me 与目标服务器公网出口对应

这就能确认：当前会话已经不在跳板机上，而是成功落到了目标服务器。

优点

非常实用
配置简单
网络受限场景往往立刻见效

缺点

需要额外一台服务器
跳板机本身也要维护安全
公共、陌生、免费跳板机不适合作为长期正式方案

结论

如果你手里刚好有另一台可用服务器，SSH 跳板机通常是恢复连接最快的方案。

五、方案 4：Tailscale / WireGuard

如果你的目标不是“用域名优雅接入”，而是“先稳定连上”，那么 Tailscale 或 WireGuard 也非常值得考虑。

原理

本地和服务器都加入同一个虚拟网络：

本地 <-> Tailscale / WireGuard <-> 服务器

然后通过分配到的内网地址 SSH。

优点

对 NAT、复杂网络环境友好
不一定需要暴露 22 端口
多台机器统一管理时很方便

缺点

需要额外安装客户端
对部分只想临时排障的人来说，理解成本略高

结论

如果你管理的不止一台服务器，Tailscale/WireGuard 更像是一种长期网络方案，而不是一次性的补丁。

六、这次排障中最容易踩的误区

误区 1：以为开橙云就等于可以代理 SSH

不是。普通 Cloudflare 橙云适合网站，不适合直接代理原生 SSH。

如果想通过 Cloudflare 做 SSH 中转，应该用：

Cloudflare Tunnel
Cloudflare Access / Zero Trust

而不是只改 DNS 开关。

误区 2：以为改灰云就一定能连上

灰云只是“直接解析到服务器 IP”，它不负责解决：

本地网络封锁
运营商限制
服务器 22 端口未开放
云厂商安全组拦截
服务器防火墙限制

所以灰云只是排查步骤，不是万能修复。

误区 3：只盯着目标服务器，不看连接路径

这次最关键的发现就是：

目标服务器并不是彻底不可达
真正不通的是“本地到目标服务器这条路径”
一旦换成“本地 -> 跳板机 -> 目标服务器”，整个链路立刻恢复

很多 SSH 故障，问题并不在服务器本身，而在“你怎么到达它”。

七、怎么选：不同场景下的建议

1. 只是临时排查

先试：

把 Cloudflare 记录改成仅 DNS（灰云）
直接 SSH 测试

适合快速确认问题是否来自 Cloudflare 代理。

2. 本地网络受限，但你有另一台服务器

直接上：

SSH 跳板机

这是恢复连接最快的实战方案。

3. 你有 Cloudflare 域名，想长期正规使用

直接考虑：

Cloudflare Tunnel

长期看，它比直开 22 更优雅，也更安全。

4. 你管理多台服务器，希望网络统一

考虑：

Tailscale
WireGuard

适合长期多机互联。

八、安全提醒：不要长期使用 root + 密码

排查 SSH 时，很多人为了快，会直接用：

root
密码登录

这虽然方便，但风险非常高，尤其在需要截图、远程协助、多次调试跳板机的场景里，密码很容易在不经意间暴露。

更推荐的做法是：

尽快改成 SSH key 登录
验证密钥可用后关闭密码登录
跳板机也要单独做安全加固
避免长期直接使用 root + 密码

九、最后总结

这次排障最重要的结论其实很简单：

当 SSH 连不上时，先别急着怀疑服务器坏了，先判断是不是“连接路径”出了问题。

从这次实战来看：

Cloudflare 橙云不适合直接代理原生 SSH
灰云只是直连解析，不解决网络封锁
Cloudflare Tunnel 适合长期正规中转
SSH 跳板机是最快恢复连接的实战方案
Tailscale/WireGuard 更适合长期多机互联

而这次最终真正跑通的方案，是：

通过一台日本服务器作为 SSH 跳板机，成功连接到目标服务器。

这再次说明：有时候问题不在目标机，而在你怎么到达它。

十、附：几条实用命令

灰云直连测试

ssh root@your-domain.com

跳板机连接

ssh -J root@jump-server-ip root@target-server-ip

Cloudflare Tunnel 方式连接

ssh -o ProxyCommand="cloudflared access ssh --hostname ssh.example.com" root@ssh.example.com

登录后确认当前机器

hostname
curl ifconfig.me

OpenClaw 怎么安装和更新？curl脚本、npm、Docker 全对比

HY博客 — Mon, 02 Mar 2026 00:00:00 GMT

OpenClaw 的安装方式不止一种。选错方式，后续更新和排障会越来越痛；选对方式，升级、回滚、自动化都很顺。

这篇文章按实战角度对比四类方式：官方脚本安装、npm 全局安装、源码运行、容器部署，并补上对应的更新与回滚方法。

1) 官方脚本安装（推荐新手与快速上线）

安装

curl -fsSL --proto '=https' --tlsv1.2 https://openclaw.ai/install.sh | bash

--proto '=https' 与 --tlsv1.2 用于强制安全链路下载，建议保留。

更新

openclaw gateway stop
curl -fsSL --proto '=https' --tlsv1.2 https://openclaw.ai/install.sh | bash
openclaw gateway start
openclaw --version
openclaw status

适用场景

追求最快上手
不想折腾 Node 包管理细节
单机部署与维护

优缺点

优点：简单、快、官方路径清晰
缺点：脚本入口可变，生产建议先在测试机验证

2) npm 全局安装（适合 Node 生态用户）

安装

npm install -g openclaw

更新

openclaw gateway stop
npm install -g openclaw@latest
openclaw gateway start
openclaw --version
openclaw status

适用场景

已有 Node/NPM 运维体系
希望纳入 CI/CD 脚本

优缺点

优点：版本控制直观（@latest 或指定版本）
缺点：需要关注全局路径，避免多份安装混淆

建议排查命令：

which openclaw
readlink -f "$(which openclaw)"
npm ls -g --depth=0 | grep -i openclaw

3) 源码运行（适合二次开发与调试）

安装（示意）

git clone https://github.com/openclaw/openclaw.git
cd openclaw
npm install
npm run build

更新

git pull
npm install
npm run build
# 然后重启对应服务进程

适用场景

需要改源码、打补丁
想深度调试内部行为

优缺点

优点：自由度最高
缺点：运维复杂度最高，需自行承担依赖兼容风险

4) 容器部署（适合团队与标准化运维）

安装/运行（示意）

docker run -d --name openclaw ...

更新

docker pull <image>:<tag>
docker stop openclaw && docker rm openclaw
docker run -d --name openclaw <image>:<tag>

适用场景

多环境一致性要求高
需要可回滚、可审计、自动化发布

优缺点

优点：环境一致、回滚方便
缺点：要处理卷挂载、配置注入、日志采集、健康检查

如何选型？

个人用户/首次上手：官方脚本
Node 运维体系：npm 全局
开发调试/二开：源码
团队生产环境：容器

通用更新与验收流程（推荐）

无论哪种安装方式，都建议遵循：

升级前停止网关服务
按“原安装通道”升级（脚本装就脚本升，npm 装就 npm 升）
升级后立即验收

openclaw --version
openclaw gateway status
openclaw status

回滚思路

脚本 / npm 安装

升级前备份当前安装目录（或保留上一个可用版本）
若升级异常，回滚到旧版本再重启服务

容器安装

直接切回旧镜像 tag 并重启容器

常见问题

Q1：更新后版本没变？

可能是已经最新，或执行的是另一套安装路径。先检查二进制指向：

which openclaw
readlink -f "$(which openclaw)"

Q2：脚本安装为什么也可能看到 npm 行为？

很多安装脚本底层也会调用包管理器完成安装，这是实现细节。运维上仍建议“同路径安装同路径更新”，避免路径混乱。

Q3：安全告警如何处理？

若凭据目录权限过宽（例如 777），应立即收紧：

chmod 700 /root/.openclaw/credentials

结语

没有“唯一正确”的安装方式，只有“最适合当前阶段”的方式。

重稳定：脚本或容器
重可控：npm 或源码

关键不在“怎么装”，而在于你是否有清晰的更新、验收、回滚流程。

在 OpenClaw 服务器上安装并使用 Playwright + Chromium（含 Xvfb）

HY博客 — Sat, 28 Feb 2026 00:00:00 GMT

想在服务器上让 OpenClaw 具备“能打开网页、点击、输入、截图”的能力，最稳的路径通常是：Playwright + Chromium + Xvfb。

这篇文章记录一套在无桌面 Linux 服务器上可复用的安装与使用流程，并顺带说明在 OpenClaw 里怎么把它用起来。

说明：部分网站（尤其是 Google / Cloudflare 的高级验证）对自动化访问非常敏感，可能仍需要人工或更高级的网络/代理方案。本文重点是「让环境跑通」与「可稳定截图/交互」。

1. 安装 Playwright

确认 Node.js 环境可用：

node -v
npm -v

安装 Playwright（推荐安装到工作区，避免全局包路径差异）：

cd /root/.openclaw/workspace
npm install playwright

如果你更偏好全局安装（便于快速试验 CLI），也可以：

npm install -g playwright

2. 安装 Chromium

下载 Playwright 管理的 Chromium：

npx playwright install chromium

Playwright 会把浏览器放到类似 ~/.cache/ms-playwright/ 的目录下。

3. 安装系统依赖（关键）

无桌面服务器上，Chromium 需要一堆运行库（字体、X11/GL/GTK 相关等）。直接安装 Playwright 的依赖集合最省事：

npx playwright install-deps chromium

这一步通常会安装 xvfb 以及各类字体与图形库依赖。

4. 用 Xvfb 运行（无桌面环境推荐做法）

即便你使用 headless: true，在某些环境/网站场景里也会遇到 “Missing X server or $DISPLAY”。

统一用 xvfb-run 包一层，是最稳的无桌面运行方式：

xvfb-run -a node your-script.js

-a 会自动选择可用的 DISPLAY，避免冲突。

5. 最小可用脚本：访问网页并截图

在 /root/.openclaw/workspace 新建 pw-shot.js：

const { chromium } = require('playwright');

(async () => {
  const browser = await chromium.launch({
    headless: true,
    // 服务器上常见建议参数
    args: ['--no-sandbox', '--disable-dev-shm-usage'],
  });

  const page = await browser.newPage();
  await page.goto('https://example.com', {
    waitUntil: 'domcontentloaded',
    timeout: 30000,
  });

  await page.waitForTimeout(1500);
  await page.screenshot({ path: 'example.png', fullPage: false });
  console.log('saved example.png');

  await browser.close();
})().catch((e) => {
  console.error(e);
  process.exit(1);
});

运行：

cd /root/.openclaw/workspace
xvfb-run -a node pw-shot.js

6. 点击/输入：UI 框架页面的常见坑

很多站点使用 UI 框架（例如 Semi Design / Ant Design）封装了复选框、按钮，导致：

元素看起来可点，但点击会被某个 span/div 拦截
click() 超时，日志里出现 “intercepts pointer events”

常用应对策略：

点击真正可点击的可视层（比如 .semi-checkbox-inner-display）
必要时 click({ force: true })
用 locator() 结合 :has-text() 精准定位按钮

示例：

// 输入
await page.locator('input').nth(0).fill('HY');
await page.locator('input').nth(1).fill('2484913990');

// 勾选（点可见层 + force）
await page.locator('.semi-checkbox-inner-display').click({ force: true });

// 点击登录
await page.locator('button:has-text("登录"), button[type="submit"]').first().click();

7. 在 OpenClaw 里怎么“用起来”

如果你不想依赖本地电脑（Chrome 扩展 relay），最直接的做法是：

把 Playwright 脚本放在 /root/.openclaw/workspace
让 OpenClaw 通过 exec 运行 xvfb-run -a node xxx.js
输出截图/日志到 workspace，然后由 OpenClaw 转发到 Telegram

例如：

cd /root/.openclaw/workspace
xvfb-run -a node pw-shot.js

这样就能在服务器端完成“访问 + 交互 + 截图”的闭环。

8. 结语

Playwright + Chromium + Xvfb 是服务器端自动化的一条通用路线：

能稳定跑在无桌面环境
适合做截图、表单填写、点击跳转、简单抓取
面对强风控验证码时需要额外策略，但不影响大多数日常自动化需求

从开发到分享：Docker + GitHub 完整部署指南（以 Domain Checker 为例）

HY博客 — Fri, 27 Feb 2026 00:00:00 GMT

import Warning from "../../components/mdx/Warning.astro";

前言

你开发了一个很棒的应用，现在想让别人也能用。但怎么分享呢？

直接给代码？别人还要自己配置环境、安装依赖
打包成可执行文件？跨平台兼容性差
上传到 Docker Hub？别人一条命令就能用

这篇文章就是教你怎么做最后一种——用 Docker + GitHub 让你的应用可以被全世界使用。

我们以 Domain Checker（批量域名查询工具）为例，从零开始讲解整个流程。

第一部分：准备工作

你需要什么

Docker — 已安装
Docker Hub 账户 — 免费注册：https://hub.docker.com
GitHub 账户 — 免费注册：https://github.com
Git — 已安装
一个可以工作的应用 — 我们用 Domain Checker 作例子

项目结构

一个标准的可分享项目应该是这样的：

domain-checker/
├── docker-compose.yml      # Docker Compose 配置
├── .env.example            # 环境变量模板（给别人参考）
├── .env                    # 真实环境变量（本地用，不上传）
├── .gitignore              # Git 忽略规则
├── README.md               # 项目说明
├── Dockerfile              # Docker 镜像定义
├── requirements.txt        # Python 依赖
└── main.py                 # 应用代码

第二部分：本地开发与测试

1. 创建项目目录

mkdir domain-checker
cd domain-checker

2. 编写应用代码

创建 main.py（这里用一个简单的 FastAPI 应用作例子）：

from fastapi import FastAPI
import os

app = FastAPI(title="Domain Checker")

FASTLY_TOKEN = os.getenv("FASTLY_TOKEN", "")
MAX_CONCURRENCY = int(os.getenv("MAX_CONCURRENCY", "5"))

@app.get("/")
async def index():
    return {
        "message": "Domain Checker API",
        "token_configured": bool(FASTLY_TOKEN),
        "max_concurrency": MAX_CONCURRENCY
    }

@app.get("/health")
async def health():
    return {"status": "ok"}

3. 创建 `requirements.txt`

fastapi==0.104.1
uvicorn==0.24.0
httpx==0.25.2
pytz==2024.1
python-multipart==0.0.6

4. 创建 `Dockerfile`

FROM python:3.12-slim

ENV PYTHONDONTWRITEBYTECODE=1 \
    PYTHONUNBUFFERED=1

WORKDIR /app

RUN apt-get update && apt-get install -y --no-install-recommends ca-certificates && rm -rf /var/lib/apt/lists/*

COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY . .

EXPOSE 8000
CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]

5. 创建 `docker-compose.yml`

version: '3.8'
services:
  domain-checker:
    image: myhywo/domain-checker:latest
    container_name: domain-checker
    restart: unless-stopped
    ports:
      - "22332:8000"
    volumes:
      - ./data:/app/data
      - ./wordlists:/app/wordlists
    environment:
      - MAX_CONCURRENCY=5
      - HTTP_TIMEOUT_SECONDS=10
      - CACHE_TTL_SECONDS=86400
      - FASTLY_TOKEN=your_fastly_api_token_here
      - FASTLY_ENDPOINT=https://api.fastly.com/domain-management/v1/tools/status
      - RESET_DAY=18
      - RESET_TIMEZONE=Asia/Shanghai
networks:
  default:
    name: domain-checker-net

6. 创建 `.env.example`

这个文件告诉别人需要配置什么环境变量：

# Fastly API Configuration
FASTLY_TOKEN=your_fastly_api_token_here
FASTLY_ENDPOINT=https://api.fastly.com/domain-management/v1/tools/status

# Application Settings
MAX_CONCURRENCY=5
HTTP_TIMEOUT_SECONDS=10
CACHE_TTL_SECONDS=86400

# Reset Configuration
RESET_DAY=18
RESET_TIMEZONE=Asia/Shanghai

7. 创建 `.env`（本地用）

这个文件放你的真实配置，不要上传到 GitHub：

FASTLY_TOKEN=your_real_token_here
FASTLY_ENDPOINT=https://api.fastly.com/domain-management/v1/tools/status
MAX_CONCURRENCY=5
HTTP_TIMEOUT_SECONDS=10
CACHE_TTL_SECONDS=86400
RESET_DAY=18
RESET_TIMEZONE=Asia/Shanghai

8. 创建 `.gitignore`

.env
.env.local
*.log
app/__pycache__/
app/*.pyc
data/
.DS_Store

9. 本地测试

# 构建镜像
docker compose build

# 启动容器
docker compose up -d

# 测试应用
curl http://localhost:22332/

# 查看日志
docker compose logs -f

# 停止容器
docker compose down

第三部分：推送到 Docker Hub

1. 登录 Docker Hub

docker login

输入你的 Docker Hub 用户名和密码。

2. 给镜像打 tag

假设你的 Docker Hub 用户名是 myhywo：

docker tag domain-checker-domain-checker myhywo/domain-checker:latest

3. 推送到 Docker Hub

docker push myhywo/domain-checker:latest

等待上传完成。你可以在 https://hub.docker.com/r/myhywo/domain-checker 看到你的镜像。

**重要：** 推送前确保 `docker-compose.yml` 里的 `FASTLY_TOKEN` 是占位符（`your_fastly_api_token_here`），不是真实的 Token。真实的 Token 应该在本地的 `.env` 文件里。

第四部分：上传到 GitHub

1. 在 GitHub 创建新仓库

访问 https://github.com/new，创建一个新仓库，名字叫 domain-checker。

2. 初始化本地 Git 仓库

cd domain-checker
git init
git add .
git commit -m "Initial commit: domain-checker with docker-compose"

3. 添加远程仓库

git remote add origin https://github.com/myhywo/domain-checker.git
git branch -M main
git push -u origin main

输入你的 GitHub 用户名和 Personal Access Token（或用 SSH 密钥）。

4. 提交并推送到 GitHub

git add README.md
git commit -m "Initial commit: domain-checker with docker-compose"
git push -u origin main

第五部分：别人如何使用你的项目

方式 1：从 GitHub Clone（推荐）

# Clone 项目
git clone https://github.com/myhywo/domain-checker.git
cd domain-checker

# 复制环境变量模板
cp .env.example .env

# 编辑 .env，填入自己的 Fastly Token
nano .env

# 启动容器
docker compose up -d

# 访问应用
curl http://localhost:22332/

方式 2：直接用 Docker 镜像（不需要 Clone）

docker run -d \
  -p 22332:8000 \
  -e FASTLY_TOKEN=their_token_here \
  -e FASTLY_ENDPOINT=https://api.fastly.com/domain-management/v1/tools/status \
  myhywo/domain-checker:latest

方式 3：用 Docker Compose（不需要 Clone）

创建一个 docker-compose.yml：

services:
  domain-checker:
    image: myhywo/domain-checker:latest
    container_name: domain-checker
    restart: unless-stopped
    ports:
      - "22332:8000"
    volumes:
      - ./app:/app
    environment:
      - MAX_CONCURRENCY=5
      - HTTP_TIMEOUT_SECONDS=10
      - CACHE_TTL_SECONDS=86400
      - FASTLY_TOKEN=their_token_here
      - FASTLY_ENDPOINT=https://api.fastly.com/domain-management/v1/tools/status
      - RESET_DAY=18
      - RESET_TIMEZONE=Asia/Shanghai

然后运行：

docker compose up -d

第六部分：最佳实践

1. 版本管理

每次发布新版本时，给镜像打多个 tag：

# 构建镜像
docker compose build

# 打 tag
docker tag domain-checker-domain-checker myhywo/domain-checker:latest
docker tag domain-checker-domain-checker myhywo/domain-checker:v1.0.0

# 推送
docker push myhywo/domain-checker:latest
docker push myhywo/domain-checker:v1.0.0

在 docker-compose.yml 里，别人可以选择用 latest 或指定版本：

image: myhywo/domain-checker:v1.0.0  # 指定版本
# 或
image: myhywo/domain-checker:latest  # 最新版本

2. 敏感信息管理

永远不要在代码里硬编码 Token 或密钥。

✅ 正确做法：

environment:
  - FASTLY_TOKEN=${FASTLY_TOKEN}  # 从 .env 读取

❌ 错误做法：

environment:
  - FASTLY_TOKEN=abc123xyz  # 硬编码，会泄露！

3. 健康检查

在 docker-compose.yml 里配置健康检查，Docker 会自动监控应用状态：

healthcheck:
  test: ["CMD", "curl", "-f", "http://localhost:8000/health"]
  interval: 30s
  timeout: 10s
  retries: 3
  start_period: 40s

4. 日志管理

配置日志驱动，防止日志文件无限增长：

logging:
  driver: "json-file"
  options:
    max-size: "10m"
    max-file: "3"

5. 资源限制

为容器设置 CPU 和内存限制，防止占用过多资源：

deploy:
  resources:
    limits:
      cpus: '1'
      memory: 512M
    reservations:
      cpus: '0.5'
      memory: 256M

6. 卷挂载

代码卷 — 用于开发时热重载：./app:/app
数据卷 — 用于持久化数据：./data:/app/data

volumes:
  - ./app:/app          # 代码（开发时热重载）
  - ./data:/app/data    # 数据（持久化）

第七部分：更新和维护

更新代码后的流程

# 1. 修改代码
nano main.py

# 2. 测试
docker compose restart
curl http://localhost:22332/

# 3. 重新构建镜像
docker compose build

# 4. 推送到 Docker Hub
docker tag domain-checker-domain-checker myhywo/domain-checker:latest
docker push myhywo/domain-checker:latest

# 5. 提交到 GitHub
git add .
git commit -m "Fix: improve performance"
git push

# 6. 创建 Release（可选）
# 在 GitHub 上创建一个新的 Release，标记版本号

自动化推送（可选）

如果你想自动化这个流程，可以用 GitHub Actions：

# .github/workflows/docker-push.yml
name: Build and Push Docker Image

on:
  push:
    branches:
      - main

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      
      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v1
      
      - name: Login to Docker Hub
        uses: docker/login-action@v1
        with:
          username: ${{ secrets.DOCKER_USERNAME }}
          password: ${{ secrets.DOCKER_PASSWORD }}
      
      - name: Build and push
        uses: docker/build-push-action@v2
        with:
          context: .
          push: true
          tags: myhywo/domain-checker:latest

常见问题

Q: 别人用我的镜像时，需要修改代码吗？

A: 不需要。所有配置都通过环境变量传入，别人只需要修改 .env 文件或 docker-compose.yml 里的环境变量即可。

Q: 我的 Token 会泄露吗？

A: 不会。只要你：

在 docker-compose.yml 里用占位符
在 .env 里放真实 Token
在 .gitignore 里排除 .env

就不会泄露。

Q: 别人能看到我的 Token 吗？

A: 不能。Token 只存在于别人的本地 .env 文件里，不会上传到 GitHub 或 Docker Hub。

Q: 如何回滚到旧版本？

A: 在 docker-compose.yml 里改镜像标签：

image: myhywo/domain-checker:v1.0.0  # 改成旧版本

然后重启：

docker compose down
docker compose up -d

Q: 如何在多台服务器上部署？

A: 在每台服务器上都运行同样的命令：

git clone https://github.com/myhywo/domain-checker.git
cd domain-checker
cp .env.example .env
# 编辑 .env
docker compose up -d

总结

步骤	命令	说明
1. 本地开发	`docker compose up -d`	在本地测试应用
2. 推送到 Docker Hub	`docker push myhywo/domain-checker:latest`	上传镜像
3. 上传到 GitHub	`git push`	上传代码
4. 别人使用	`docker compose up -d`	一条命令启动

现在你的应用已经可以被全世界使用了。每次更新代码时，只需要重复步骤 1-3 即可。

参考资源

Docker 官方文档： https://docs.docker.com/
Docker Hub： https://hub.docker.com/
GitHub： https://github.com/
Docker Compose： https://docs.docker.com/compose/
最佳实践： https://docs.docker.com/develop/dev-best-practices/

纯 IPv6 服务器获得 IPv4 出站能力：NAT64 DNS + Cloudflare WARP 完整指南

HY博客 — Tue, 24 Feb 2026 00:00:00 GMT

import Warning from "../../components/mdx/Warning.astro";

问题：纯 IPv6 服务器的困境

你有一台纯 IPv6 服务器，但现实很残酷：

GitHub、PyPI、Docker Hub 等主要服务还是 IPv4
无法下载软件包、安装脚本
即使有 IPv6 DNS，也解析不了 IPv4 资源
一切都卡在"网络不可达"

这篇文章就是为了解决这个问题。

解决方案：两步走

第一步：NAT64 DNS（临时应急）

用公益 NAT64 服务器临时获得 IPv4 访问能力，这样你就能下载 wgcf。

第二步：Cloudflare WARP（长期方案）

配置 WARP 获得稳定的 IPv4 出站，然后停用 NAT64。

第一步：配置 NAT64 DNS

什么是 NAT64？

NAT64 是 IPv6 到 IPv4 的转换技术。通过配置 NAT64 DNS 服务器，纯 IPv6 服务器可以访问 IPv4 资源。

公益 NAT64 服务器（欧洲）：

2001:67c:2b0::4
2001:67c:2b0::6

配置

# 编辑 /etc/resolv.conf
cat > /etc/resolv.conf << 'EOF'
nameserver 2001:67c:2b0::4
nameserver 2001:67c:2b0::6
EOF

# 验证
cat /etc/resolv.conf

# 测试 DNS 解析
nslookup github.com

# 测试连接
curl -I https://github.com

预期输出： HTTP/2 200

**为什么只是临时方案？** NAT64 服务通常收费，免费的公益服大多在欧洲。如果你的服务器在美国，流量要先去欧洲再回来，延迟高。不适合长期使用。

第二步：安装 wgcf

现在网络可用了，下载 wgcf 来配置 Cloudflare WARP。

下载 wgcf

cd /root
wget -6 -qO wgcf https://github.com/ViRb3/wgcf/releases/download/v2.2.30/wgcf_2.2.30_linux_amd64
chmod +x wgcf

# 验证
ls -lah wgcf

注册 WARP 账户

cd /root
echo 'yes' | ./wgcf register

输出示例：

Successfully created Cloudflare Warp account
Account Id: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

生成 WireGuard 配置

./wgcf generate
cat wgcf-profile.conf

第三步：配置 WireGuard 接口

Alpine Linux 缺少 ip6tables-restore，所以我们用手动方式配置。

手动启动 WireGuard

# 1. 复制配置文件
cp /root/wgcf-profile.conf /etc/wireguard/wgcf.conf
chmod 600 /etc/wireguard/wgcf.conf

# 2. 创建 WireGuard 接口
ip link add wgcf type wireguard

# 3. 设置私钥
wg set wgcf private-key <(grep PrivateKey /root/wgcf-profile.conf | awk '{print $3}')

# 4. 配置 IP 地址（从配置文件提取）
WARP_IPV4=$(grep "Address = " /root/wgcf-profile.conf | grep -oE "172\.[0-9]+\.[0-9]+\.[0-9]+" | head -1)
WARP_IPV6=$(grep "Address = " /root/wgcf-profile.conf | grep -oE "2606:[0-9a-f:]+/128" | head -1)
ip address add ${WARP_IPV4}/32 dev wgcf
ip address add ${WARP_IPV6} dev wgcf

# 5. 设置 MTU
ip link set mtu 1280 up dev wgcf

# 6. 配置 Peer（Cloudflare WARP 服务器）
wg set wgcf peer bmXOC+F1FxEMF9dyiK2H5/1SUtzH0JuVo51h2wPfgyo= \
  allowed-ips 0.0.0.0/0,::/0 \
  endpoint engage.cloudflareclient.com:2408

# 7. 配置路由（让所有 IPv4 流量走 WARP）
ip route add default dev wgcf

# 8. 配置 DNS
cat > /etc/resolv.conf << 'EOF'
nameserver 2606:4700:4700::1111
nameserver 2606:4700:4700::1001
nameserver 1.1.1.1
nameserver 1.0.0.1
EOF

验证 WireGuard 状态

wg show wgcf
ip route show
cat /etc/resolv.conf

第四步：验证 IPv4 出站能力

测试 IPv4 连接

curl -4 ipinfo.io

预期输出：Cloudflare IPv4 地址

{
  "ip": "104.28.197.244",
  "org": "AS13335 Cloudflare, Inc.",
  ...
}

测试 IPv6 连接（确保不中断）

ping -c 1 2001:4860:4860::8888

预期：正常响应

第五步：清理 NAT64 DNS

现在 WARP 已经配置好，停止使用 NAT64 DNS，改用 Cloudflare DNS。

cat > /etc/resolv.conf << 'EOF'
nameserver 2606:4700:4700::1111
nameserver 2606:4700:4700::1001
nameserver 1.1.1.1
nameserver 1.0.0.1
EOF

一键配置脚本

如果想一次性配置，用这个脚本：

#!/bin/bash

# 1. 临时配置 NAT64 DNS
echo "配置 NAT64 DNS..."
cat > /etc/resolv.conf << 'EOF'
nameserver 2001:67c:2b0::4
nameserver 2001:67c:2b0::6
EOF

# 2. 下载 wgcf
echo "下载 wgcf..."
cd /root
wget -6 -qO wgcf https://github.com/ViRb3/wgcf/releases/download/v2.2.30/wgcf_2.2.30_linux_amd64
chmod +x wgcf

# 3. 注册 WARP 账户
echo "注册 WARP 账户..."
echo 'yes' | ./wgcf register

# 4. 生成配置
echo "生成 WireGuard 配置..."
./wgcf generate

# 5. 配置 WireGuard
echo "配置 WireGuard..."
cp /root/wgcf-profile.conf /etc/wireguard/wgcf.conf
chmod 600 /etc/wireguard/wgcf.conf

ip link add wgcf type wireguard
wg set wgcf private-key <(grep PrivateKey /root/wgcf-profile.conf | awk '{print $3}')
ip address add 172.16.0.2/32 dev wgcf
ip link set mtu 1280 up dev wgcf
wg set wgcf peer bmXOC+F1FxEMF9dyiK2H5/1SUtzH0JuVo51h2wPfgyo= \
  allowed-ips 0.0.0.0/0,::/0 \
  endpoint engage.cloudflareclient.com:2408
ip route add default dev wgcf

# 6. 配置 DNS
echo "配置 DNS..."
cat > /etc/resolv.conf << 'EOF'
nameserver 2606:4700:4700::1111
nameserver 2606:4700:4700::1001
nameserver 1.1.1.1
nameserver 1.0.0.1
EOF

# 7. 验证
echo "验证 IPv4 出站..."
curl -4 ipinfo.io

echo "验证 IPv6 连接..."
ping -c 1 2001:4860:4860::8888

echo "配置完成！"

故障排查

WireGuard 接口创建失败

错误： RTNETLINK answers: File exists

解决：

ip link delete wgcf 2>/dev/null
ip link add wgcf type wireguard

DNS 无法解析

错误： curl: (6) Could not resolve host

解决：

cat /etc/resolv.conf
ping -c 1 2606:4700:4700::1111
nslookup github.com 2606:4700:4700::1111

IPv4 出站失败

错误： curl: (7) Failed to connect

解决：

wg show wgcf
ip route show
wg show wgcf peers

IPv6 连接中断

症状： SSH 连接断开

原因： 默认路由指向 wgcf，导致 IPv6 流量也走 WARP

解决： 只让 IPv4 流量走 WARP（见第三步的路由配置）

关键要点

项目	说明
NAT64 DNS	临时方案，用来下载 wgcf；不适合长期使用
WARP	长期方案，提供稳定的 IPv4 出站能力
WireGuard	WARP 的底层协议，需要手动配置（Alpine 不支持 wg-quick）
DNS 配置	使用 Cloudflare DNS（IPv6 优先），确保 DNS 查询可达
路由配置	只让 IPv4 流量走 WARP，IPv6 保持原样

参考资源

NAT64 服务列表： http://nat64.xyz
Cloudflare WARP： https://www.cloudflare.com/warp/
wgcf 项目： https://github.com/ViRb3/wgcf
WireGuard 文档： https://www.wireguard.com/

第六步：安装 komari-agent（可选）

如果你想在那个 Alpine 服务器上安装监控代理，可以用 komari-agent。

下载并安装 komari-agent

# 下载安装脚本
wget -qO- https://raw.githubusercontent.com/komari-monitor/komari-agent/refs/heads/main/install.sh | sudo bash -s -- \
  -e https://monitor.031003.xyz \
  -t YOUR_TOKEN_HERE \
  --disable-web-ssh \
  --month-rotate 22

验证安装

# 检查进程
ps aux | grep komari-agent | grep -v grep

# 查看日志
tail -20 /tmp/komari-agent.log

故障排查进阶

WARP Peer 握手失败

症状： wg show wgcf 显示 peer 信息，但没有 latest handshake 时间

原因： Peer 握手失败，WARP 连接未真正建立

解决：

# 删除旧接口
ip link delete wgcf 2>/dev/null

# 重新创建并配置
ip link add wgcf type wireguard
wg set wgcf private-key <(grep PrivateKey /root/wgcf-profile.conf | awk '{print $3}')
ip address add 172.16.0.2/32 dev wgcf
ip link set mtu 1280 up dev wgcf
wg set wgcf peer bmXOC+F1FxEMF9dyiK2H5/1SUtzH0JuVo51h2wPfgyo= \
  allowed-ips 0.0.0.0/0,::/0 \
  endpoint engage.cloudflareclient.com:2408
ip route add default dev wgcf

# 等待握手
sleep 5

# 验证
wg show wgcf | grep "latest handshake"

komari-agent 无法连接到监控服务器

症状： komari-agent 日志显示 Failed to connect to WebSocket

原因： 网络连接不稳定或 DNS 解析失败

解决：

# 检查 DNS
cat /etc/resolv.conf
nslookup monitor.031003.xyz

# 检查 WARP 状态
wg show wgcf

# 检查路由
ip route show

# 重启 komari-agent
pkill -f komari-agent
sleep 2
nohup /opt/komari/komari-agent -e https://monitor.031003.xyz -t YOUR_TOKEN > /tmp/komari-agent.log 2>&1 &

总结

通过 NAT64 DNS + Cloudflare WARP 的组合方案，我们成功为纯 IPv6 服务器配置了 IPv4 出站能力。这个方案既解决了初期的网络问题（无法下载软件），又提供了长期稳定的解决方案。

下次遇到纯 IPv6 服务器，你就知道怎么办了。

Google 发布 Gemini 3.1 Pro：逻辑推理能力翻倍，重塑 AI 复杂任务处理新标杆

HY博客 — Fri, 20 Feb 2026 00:00:00 GMT

在人工智能领域，模型能力的进化速度总是令人惊叹。就在今天，Google 正式推出了备受瞩目的 Gemini 3.1 Pro 模型。这次更新绝不仅仅是版本号的简单+0.1，而是一次针对复杂任务处理和核心推理能力的深度进化。

如果你是开发者、科研人员或是重度 AI 用户，Gemini 3.1 Pro 绝对值得你立刻上手体验。

🧠 核心亮点：推理性能实现“翻倍”跨越

在过去的一年里，大模型的“语言表达”已经趋于完美，但“逻辑推理”始终是区分模型上限的核心指标。Gemini 3.1 Pro 这次交出了一份令人惊艳的答卷：

ARC-AGI-2 基准测试创佳绩：在该项旨在衡量 AI 抽象推理和泛化能力的严苛测试中，Gemini 3.1 Pro 取得了 77.1% 的高分。
性能翻倍：相比于前代 Gemini 3 Pro，3.1 Pro 在逻辑推理性能上提升了超过一倍。这意味着它在面对长文本逻辑梳理、复杂代码调试、多步骤数学推导以及深层次问题拆解时，将展现出前所未有的敏锐度与准确率。

🛠️ 开发者优先：全面接入核心生态

为了让开发者能够第一时间将这种强大的推理能力转化为实际应用，Google 已经在其核心开发平台上开放了 Gemini 3.1 Pro 的预览版：

Gemini API：快速集成到各类第三方应用中，为你的产品注入强大的“思考”能力。
Vertex AI：企业级用户的首选，支持在安全合规的环境中进行模型的微调、部署与大规模扩展。
Android Studio：移动端开发者的福音。得益于推理能力的提升，Android Studio 中的 AI 助手将能更精准地理解上下文，提供更深度的代码重构建议和 Bug 修复方案。

💻 普通用户如何第一时间体验？

你不需要懂代码，同样可以感受到 Gemini 3.1 Pro 带来的生产力飞跃。目前，该模型已同步向普通用户开放：

Gemini 应用：日常的问答、写作、逻辑分析，你都会感觉到它的回答更加严谨、深刻。
NotebookLM：这是 Gemini 3.1 Pro 绝佳的用武之地。借助翻倍的推理能力，NotebookLM 能够更精准地从你的海量文档、笔记和学术论文中提取关键逻辑，生成更具深度的洞察报告。

💡 贴士：对于重度依赖 AI 生产力的用户，Google 提供了分层级的服务。Google AI Pro 与 Ultra 的订阅用户将享有更高的 Gemini 3.1 Pro 使用限额，确保在处理高强度工作流时畅通无阻。

总结：从“能言善辩”到“深思熟虑”

Gemini 3.1 Pro 的发布，释放了一个明确的信号：Google 正在将 AI 的发展重心从单纯的“生成”向更深层次的“推理”转移。这不仅将改变开发者构建应用的方式，也将深刻重塑我们每一个人使用 AI 工具的习惯。

你会如何利用 Gemini 3.1 Pro 翻倍的推理能力？是去挑战一段一直没解决的复杂代码，还是让它帮你梳理晦涩难懂的学术论文？欢迎在评论区分享你的想法！

窗外一瞥能"加分"：开阔窗景如何提升高压力考试表现

HY博客 — Mon, 22 Dec 2025 00:00:00 GMT

import Warning from "../../components/mdx/Warning.astro";

研究背景

湘潭大学的学者在经济学期刊《Journal of Economic Behavior & Organization》发表了一项有趣的研究：坐在窗边是否会影响高风险环境中的认知表现？

这个问题看似简单，但答案可能会改变我们对考场设计的理解。

研究方法

研究基于中国高考的真实数据，利用随机座位分配这一"天然实验"来隔离窗景的因果效应。

座位设计

考生被随机分配到 5 列 × 6 行 的座位：

第 5 列 — 靠窗且可见室外，有开阔的自然视野
第 1 列 — 同样靠窗但因走廊遮挡，几乎无窗景
第 2-4 列 — 中间座位，无窗景

因果推断

研究者用平衡性检验证明了座位分配与考生的性别、年龄、城乡等特征完全不相关，从而将不同的"窗景暴露"视为近似自然实验。这意味着我们可以放心地将座位位置与成绩差异因果关联起来。

核心发现

结果出人意料地清晰：

仅"无遮挡窗景"与更高成绩相关：

第 5 列考生成绩提高约 0.09 个标准差（换算约 9 分）
进入"一本/第一梯队大学"的概率高 2.8 个百分点
第 1 列与中间座位的差异不显著

这说明关键不是"靠窗"，而是能否真正看到窗外。

机制解释：注意力恢复理论

为什么窗景能提升成绩？研究指向注意力恢复理论（Attention Restoration Theory）：

心理休息 — 眼睛看向窗外时，大脑短暂放松
自然刺激 — 温和的自然景观提供低强度的认知刺激
注意力恢复 — 这种"微休息"帮助考生恢复专注力，应对后续的高强度认知任务

效应的不均匀性

有趣的是，效应并非对所有人都相同：

注意力容易分散的学生获益更大 — 说明这种"自然休息"对那些本来就难以集中注意力的人帮助最大
男生效应更强 — 可能反映不同群体的注意力特征差异

实际启示

这项研究对考场设计有直接的启示：

座位安排 — 如果条件允许，优先给考生安排能看到窗外的座位
低成本干预 — 这是一个几乎零成本的性能提升方案
个体差异 — 对注意力本来就容易分散的学生，这个效应尤其明显

但需要注意的是，平衡很重要 — 窗景的目的是帮助恢复注意力，而不是让学生分心。

结论

一个简单的座位选择，竟然能影响高考成绩。这不仅说明了环境因素的重要性，也提醒我们：有时候，最好的干预不是复杂的技术，而是理解人类认知的基本规律，然后做出简单而聪明的设计。

下次设计考场或工作空间时，不妨想想：窗外的景色，可能比你想象的更重要。

参考

研究发表于：Journal of Economic Behavior & Organization
研究机构：湘潭大学
研究方法：随机座位分配自然实验
样本：中国高考考生

开源工具分享：GeminiWatermarkTool — 离线去除 Gemini 图片水印

HY博客 — Sun, 21 Dec 2025 00:00:00 GMT

import Warning from "../../components/mdx/Warning.astro";

项目介绍

GeminiWatermarkTool 是一款开源命令行工具，可以离线去除 Google Gemini 生成图片右下角的可见水印。

项目地址：allenk/GeminiWatermarkTool

Stars: 74
Forks: 12
Contributors: 1

核心特性

1. 离线处理

用 C++ 编写，无需依赖
完全本地运行，不依赖任何服务器
支持批量处理整个目录

2. 算法原理

采用反向 Alpha 混合计算来还原被水印覆盖的像素：

原始像素 = (混合像素 - 水印像素 × α) / (1 - α)

这个方法的优势在于：

精确性高 — 直接数学还原，不依赖 AI 修补
避免不确定性 — AI 修补可能引入额外的失真或错误
速度快 — 纯数学计算，处理速度很快

3. 格式支持

支持常见的图片格式：

JPG
PNG
WebP

4. 批量处理

可以一次性处理整个目录的图片，适合大量去水印的场景。

使用方式

基本用法很简单：

# 处理单个文件
./gemini-watermark-remover input.png output.png

# 批量处理目录
./gemini-watermark-remover ./input_dir ./output_dir

前端版本

有开发者基于此项目开发了纯前端版本：

journey-ad/gemini-watermark-remover

前端版本的优势

完全在浏览器本地运行 — 无需下载工具，打开网页即用
JavaScript 实现 — 跨平台兼容性更好
同样的算法 — 使用反向 Alpha 混合还原像素
隐私友好 — 所有处理都在本地，不上传到服务器

技术亮点

反向 Alpha 混合 vs AI 修补

方案	精确度	速度	依赖	稳定性
反向 Alpha 混合	高	快	无	高
AI 修补	中	慢	模型	中

反向 Alpha 混合的核心优势是确定性 — 同样的输入总是产生同样的输出，不会因为模型更新而变化。

局限性

作者坦诚了工具的局限：

✅ 支持去除可见水印（透明度混合的水印）
❌ 不支持去除隐藏水印（如 LSB 隐写、频域水印等）

这是合理的 — 可见水印是透明度混合，可以反向计算；隐藏水印需要更复杂的逆向工程。

适用场景

这个工具适合：

Gemini 用户 — 想要保存无水印的生成图片
批量处理 — 需要去除大量图片的水印
隐私考虑 — 不想上传图片到在线工具
开发者 — 想要集成到自己的工作流中

总结

GeminiWatermarkTool 是一个简洁而有效的开源项目：

算法原理清晰（反向 Alpha 混合）
实现方式多样（C++ CLI + JavaScript 前端）
使用场景明确（去除 Gemini 水印）
局限性透明（只支持可见水印）

无论你是想快速去除几张图片的水印，还是想理解 Alpha 混合的原理，这个项目都值得一看。

进化！我在用 OpenClaw 智脑写博客

HY博客 — Sat, 20 Dec 2025 00:00:00 GMT

import Warning from "../../components/mdx/Warning.astro"; import AudioPlayer from "../../components/mdx/AudioPlayer.tsx";

告别传统发布流程

以前发博客：写 Markdown -> 存文件 -> Git Commit -> Git Push -> 等待 Vercel 构建。现在发博客：直接在 Telegram 里吩咐我的智脑（OpenClaw）。

**高效提醒**：通过 OpenClaw 自动化发布，你只需要专注于内容创作，剩下的环境配置、文件结构和推送任务都由 AI 自动完成。

它是如何工作的？

我的智脑 OpenClaw 运行在服务器后台，通过 GitHub Personal Access Token 获得了仓库的读写权限。它不仅能理解我的自然语言，还能：

结构化处理：自动生成符合 Astro 规范的 Frontmatter（标题、日期、标签）。
文件管理：在 src/content/blog 目录下精准创建 .mdx 文件。
自动部署：完成写入后自动执行 Git 操作，触发 Vercel 的生产环境构建。

配置核心

为了让智脑动起来，我只需要在本地环境中配置好 GitHub Token。

# .env.local 示例
GITHUB_TOKEN=ghp_your_secure_token
GITHUB_USER=himyhy
GITHUB_REPO=SaroProck

主人寄语：科技不应该增加负担，而应该消除负担。

创作 BGM

在写作时，我喜欢听这首歌来寻找灵感：

这篇文章就是由 OpenClaw 辅助完成并自动推送发布的。

HY博客

OpenClaw 安装、卸载与更新：一篇带你学会

推荐服务器（示例）

安装（macOS/Linux/WSL2 统一采用 install.sh）

配置渠道

Dashboard

飞书

微信

QQ

基础使用教程

OpenClaw 安装后的基本结构

常用命令

更新

卸载（彻底清除：包含 ~/.openclaw 数据）

1) 一条命令彻底卸载（推荐）

2) 这条命令到底删了什么？

3) 把 CLI 也卸载掉（真正“一个不剩”）

为什么是两个命令？hash -r 是什么？

4) 验证是否卸载干净

5) 常见坑与补充

Vaultwarden（Docker）怎么查看版本并升级？一套可复制的更新流程

0）前提：确认你有 Docker 权限

1）进入 compose 目录

2）查看 Vaultwarden 与 Web-Vault 版本（最准确）

3）（强烈建议）升级前备份数据目录

4）拉取最新镜像

常见提示：version is obsolete

5）用新镜像重建并后台启动

6）验收：看日志 + 再查一次版本

7）（可选）清理旧镜像，释放磁盘

8）安全加固：把 ADMIN_TOKEN 从明文改为 Argon2 哈希（推荐）

8.1 生成 Argon2 哈希

8.2 替换 compose 里的 ADMIN_TOKEN

9）最小化“升级 SOP”（你可以贴到运维手册里）

10）常见故障：升级后突然打不开（ERR_TIMED_OUT / 只看到 SYN 没有 SYN-ACK）

10.1 快速定位思路（建议按顺序走）

10.2 云主机常见根因：ip_forward=0

永久化（推荐）

结语

SSH 连不上服务器时，几种中转方案的实战总结

一、先说结论：问题往往不在“域名”，而在“连接路径”

二、方案 1：灰云直连（仅 DNS）

适用场景

做法

优点

缺点

结论

三、方案 2：Cloudflare Tunnel 中转 SSH

原理

适用场景

优点

缺点

适合谁

四、方案 3：SSH 跳板机 / Bastion Host

原理

命令行写法

图形客户端

这次实测结果

优点

缺点

结论

五、方案 4：Tailscale / WireGuard

原理

优点

缺点

结论

六、这次排障中最容易踩的误区

误区 1：以为开橙云就等于可以代理 SSH

误区 2：以为改灰云就一定能连上

误区 3：只盯着目标服务器，不看连接路径

七、怎么选：不同场景下的建议

1. 只是临时排查

2. 本地网络受限，但你有另一台服务器

3. 你有 Cloudflare 域名，想长期正规使用

4. 你管理多台服务器，希望网络统一

八、安全提醒：不要长期使用 root + 密码

九、最后总结

十、附：几条实用命令

灰云直连测试

跳板机连接

为什么是两个命令？`hash -r` 是什么？

常见提示：`version is obsolete`

10.2 云主机常见根因：`ip_forward=0`

3. 创建 `requirements.txt`

4. 创建 `Dockerfile`

5. 创建 `docker-compose.yml`

6. 创建 `.env.example`

7. 创建 `.env`（本地用）

8. 创建 `.gitignore`