Margrop
Articles380
Tags807
Categories7

Categories

/health 200 /v1/models 0.025s 0步 0步主动 0步元递归 0步本身 12类 18789 18天idle 18天静默 192.168.x.x 1password 22类一键汇总 3层定位法 401 4个Gateway 4个Gateway全军覆没 4步主动 4步定位 503 5步定位法 60秒延迟 60秒超时 6个节点 AC ACP AI AI Coding Assistant AI编程助手 AI辅助 AI辅助编程 AP API Agent couldn't generate Alertmanager AppDaemon Aqara BaiduPCS CC-Switch CI/CD CLI Tools CLI工具 CONFIG Caddy Chrome缺失 Claude Code Cloudflare Codex Cookie 认证 Cron D1 DB探针 DB静止 DIY-123模型 DIY-MINI DIY平台 Date Diagrams.net Diary Docker Docker Compose EADDRINUSE EasyTier NAT穿透 Efficiency Tools Electerm English FTS5 Gateway Gemini CLI GitHub Actions HA HADashboard Hermes Hexo HomeAssistant IP IPv4 Java LVM‑Thin Linux MacOS Macmini Macmini log路径 Markdown MiniMax MiniMax-M3 Multi-Agent MySQL NAS NRestarts Nginx Node-RED Node.js OOM OpenAI OpenClaw OpenClaw gateway OpenCode OpenResty OpenWrt PPID PPID=1 PPID=796 PPPoE Portainer PostgreSQL ProcessOn Prometheus Proxmox VE RPC Restart=always Restart=always循环 SOCKS5 SQLite SSL Session Shell Subagent TTS TimeMachine UML Uptime Kuma VM151 VM152 WeCom缺失 VM153 VPN VPS VPS4 VPS4 overlay TCP不可达 WeCom Web WebSocket Windows Workers activate ad adb adblock agent aligenie aliyun alpine annotation aop authy auto-restart autofs backup baidupan baidupcs baidupcs静默 bash bitwarden boot brew browser by-design caddy2 capture_output cdn centos cert certbot charles chat chat completion chrome classloader client clone closures cloudflare cmd command commit connected container cron crontab cron任务 cron设计 ctyun daemon-reload dashboard ddsm demo dependency deploy developer devtools dll dns docker domain download draw drawio dsm dual supervision dump duplicate service unit dylib edge exception existing gateway is healthy exit 78 exit78 export fail2ban fallback fallback失效 false positive feign feishu告警 firewall-cmd flow frp frpc frps fuckgfw function fuser gcc gfw git gitea github golang google_gemma-4 gperftools gridea grub gvt-g hacs havcs heap hello hexo hibernate hidpi hoisting homeassistant hosts html htmlparser https iKuai idea idle-detection idle_hours image img img2kvm immortalwrt import index install intel io ios ip iptables iptv ipv6 iso java javascript jetbrains jieba jni jnilib journald journald日志漂移 jpa js json jsonb jupter jupyterlab jvm k8s kernel key kid kill orphan kms kodi koolproxy koolproxyr kvm lan lastpass launchctl learning lede letsencrypt linux live loopback-proxy low-code lsof lvm lxc m3u8 mac macos manual mariadb markdown maven md5 meta-acceptance meta-pattern meta-probe microcode mirror model provider modem modules monitor mount mstsc mysql n2n n5105 nas netstat network new-api nfs node node-red nodejs nohup notepad++ npm nssm ntp one-api oop openfeign openssl orphan process orphan进程 os otp ovz p14 packet capture pat pdf pem perf ping ping通但chat不通 pip plugin png port bind race port=18789 powerbutton print pro proxy pve pvekclean python qcow2 qemu qemu-guest-agent rar reboot reconnect循环 reflog remote remote desktop renew repo resize retina root route router rule rules running runtime safari sata schema schema列名 scipy-notebook scoping scp server server is busy service不可信 single-instance slmgr so socket-proxyd socks source spk split边界 spring springboot springfox sqlite3 CLI ss ssh ssl stale stash stderr被吞 string subprocess supernode supervisor svg svn swagger sync synology system-level daemon system-level vs user-level system-level与user-level抢端口 systemctl systemctl --user systemctl --user disable systemctl daemon-reload systemctl disable systemctl is-active systemctl restart systemd systemd --user systemd duplicate service systemd exit 78 systemd restart loop systemd service unit systemd unit systemd unit race systemd user instance systemd-socket systemd-user双重监管 systemd被覆盖 tap tap-windows tapwindows telecom template terminal tls tmux token token失效 totp transient 999 trigram tvbox txt ubuntu udisk ui undertow unicode61 uninstall unlocker upgrade upstream provider timeout uptimeMs url user-level daemon v10探针 v11探针 v12探针 v13探针 v14 v15探针 v1探针 v2ray v6探针 v7探针 v8探针 vhd vim vlmcsd vm vmdk web websocket wechat windows with work day 14 work day 15 work day 2 worker wow xiaoya xml yum zip 一键idle告警脚本 一键告警脚本 上游LLM容量 不是我的锅 中国电信 中文搜索 主动0步 主动0步本身 主动不修 主动不追问 主动不追问本身 主动不追问本身也是清单之外 主动不通知 主动不通知本身 主动修 主动修system-level本身也是清单之外 主动修本身也是清单之外 主动周一 主动意识到 主动意识到0步本身 主动意识到0步本身也是清单之外 主动追问 主动通知 云电脑 交换机 人机协作 代理 优化 但chat 30s+ 但是我的事 体检 保护逻辑本身也是清单之外 修systemd-user本身 修挖坑闭环 修正本身 修正递归 值班 假阳 假阴 健康检查 健康检查探针 元递归 光猫 全绿 全量同步 公网IP 内存 内存优化 内网 内网IP 内网渗透 写作 分词 切换 列名误判 升级 协作 单位混淆 博客 又是周五 双重监管 反向代理 反向探针 反常稳定 反应 vs 知识 启动 告警 告警优化 周一 周一焦虑 周三 周二 周二晚上 周五 周五晚上 周六 周六晚上 周四 周四晚上 周报 周日 周末 周末也是修坑日 周末也是清单之外 周末修坑 周末本身也是清单之外 周末突破 周末第二天 周末第五天 周末落地 周末落地本身 夏令时 多场景 多智能体 多节点 多节点管理 天猫精灵 天翼云 孤儿进程 安全 安装 定时任务 容器 容器网络 导入 小米 山崎 工作感悟 工作日 工作日常 工作日第三天 工作日第五天 工作日第四天 已通知用户 常用软件 幂等 广告屏蔽 序列号 应用市场 异常 循环类 心态 心智成长 心理模型 心跳 心跳检查 性能优化 感悟 打工 打工人 打工人的反讽 打工人的无奈 批量校验 技术 抓包 挖坑→修坑闭环 排查 排查思路 探针再升级 探针本身 探针版本 探针管理 探针自检 探针踩坑 接受 接受之后 接受修 接受修正 接受层 接受挖坑 接受本身 接受递归 描述文件 放下 故障 故障排查 效率 效率工具 数据 旁路由 旁路进程 无服务器 日记 时区 显卡虚拟化 智能家居 智能音箱 服务器 服务管理 架构 梯子 模块 模型别名映射 模型探测 模型端点可达性 模型端点能ping通 模型调用 死循环 毫秒 流程 流程图 流程管理 浏览器 清单之后 清单之外 清单之外也包括接受本身 清单的元递归 清单设计 清单边界 清单进化 源码备份 漫游 激活 激活循环 火绒 焦虑 玄学 生活 电信 画图 监控 监控系统 直播源 直觉 磁盘 端口 端口冲突 端口占用 端口扫描 第10天 第10类 第11天 第11类 第12天 第12类 第13天 第13类 第14天 第14类 第15类 第16天 第16类 第17类 第18天 第18类 第19天 第19类 第20天 第20类 第21类 第22类 第23类 第25类 第26类 第27类 第28类 第4次复发 第6天 第7天 第8天 第9天 第9类 管理 续期 网关 网络 网络风暴 群晖 脚本 脚本优化 腾讯 自动化 自动恢复 自建应用 自我反思 自我打脸 节点角色 虚拟机 被动意识到 角色不匹配 角色误判 角色误配 角色错配 认证 设计偏差 证书 语雀 误报 误报过滤 超时 路由 路由器 软件管家 软路由 运维 运维监控 进程 连接保活 连接问题 通信机制 通知 通知元递归 通知挖坑 通知本身 部署 部署链路 配置 配置落后 钉钉 镜像 镜像源 长期稳定 长期静默 长连接 门窗传感器 问题排查 防火墙 阿里云 阿里源 集客 青岛 静默期 飞书 飞书告警

Hitokoto

Archive

记一次 OpenClaw 飞书插件安装:Node版本不匹配与端口占用问题排查全记录

记一次 OpenClaw 飞书插件安装:Node版本不匹配与端口占用问题排查全记录

前言

今天在给三台 OpenClaw Gateway 服务器批量安装飞书插件时,遇到了两个经典问题:Node.js 版本不匹配端口被旧进程占用。本文将详细记录整个排查和解决过程,希望能给遇到类似问题的同学一些参考。

问题背景

任务描述

需要在 VM151、VM152、VM153 三台服务器上安装 @openclaw/feishu 插件,并通过 WebSocket 模式连接飞书开放平台。

环境信息

  • 操作系统:Ubuntu 24.04
  • OpenClaw Gateway:运行在 18789 端口
  • Node.js:系统默认 v18,部分插件需要 v22

问题现象

VM151:安装过程顺利,重启后飞书 WebSocket 直接连接成功。

VM152:安装时报错 Error: The module './dist/index.js' does not exist。重启服务时提示 Port 18789 is already in use

VM153:安装顺利,连接成功,但存在一个无关的钉钉插件 TypeScript 编译警告。

问题一:Node.js 版本不匹配

错误信息

1
Error: The module './dist/index.js' does not exist

排查过程

第一步:确认错误发生的位置

插件安装时出现这个错误,说明插件的构建产物(dist/index.js)没有被正确生成或者不被识别。

但仔细看错误提示,发现问题可能不是插件本身,而是 Node.js 环境。./dist/index.js 这个路径是一个相对路径,Node.js 在解析这个路径时出了问题,很可能是版本兼容性问题。

第二步:检查 Node.js 版本

1
2
3
4
5
# 检查当前 Node.js 版本
node --version

# 输出
v18.17.0

系统默认的 Node.js 是 18.17.0。而某些新的 OpenClaw 插件需要 Node.js 22 才能运行。

第三步:检查是否有 nvm

1
2
3
4
5
# 检查是否有 nvm
command -v nvm

# 或者
ls -la ~/.nvm/nvm.sh

如果系统里有 nvm,可以用它来切换 Node.js 版本。如果没有,则需要安装。

解决方案

方案一:使用 nvm 切换 Node.js 版本

如果系统已经安装了 nvm:

1
2
3
4
5
6
7
8
9
10
11
12
# 加载 nvm
source ~/.nvm/nvm.sh

# 安装 Node.js 22
nvm install 22

# 切换到 Node.js 22
nvm use 22

# 确认版本
node --version
# 应该输出 v22.x.x

方案二:安装 nvm(如果没有)

1
2
3
4
5
6
7
8
9
10
11
# 下载并安装 nvm
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.0/install.sh | bash

# 重新加载 shell 配置
exec $SHELL

# 安装 Node.js 22
nvm install 22

# 设置默认版本
nvm alias default 22

方案三:直接下载 Node.js 22

如果不习惯用 nvm,也可以直接下载 Node.js 22:

1
2
3
4
5
6
7
8
9
# 下载 Node.js 22
cd /tmp
wget https://nodejs.org/dist/v22.14.0/node-v22.14.0-linux-x64.tar.xz

# 解压到 /usr/local
sudo tar -xf node-v22.14.0-linux-x64.tar.xz -C /usr/local --strip-components=1

# 确认版本
node --version

验证步骤

1
2
3
4
5
6
7
8
9
# 在 Node.js 22 环境下重新安装插件
source ~/.nvm/nvm.sh && nvm use 22
openclaw plugin add @openclaw/feishu

# 如果安装成功,重启 Gateway
systemctl restart openclaw-gateway

# 检查日志
journalctl -u openclaw-gateway -n 50

问题二:端口被旧进程占用

错误信息

1
Error: Port 18789 is already in use

排查过程

第一步:确认端口占用情况

1
2
3
4
5
# 检查端口 18789 是否被占用
ss -tlnp | grep 18789

# 输出示例
tcp 0 0 0.0.0.0:18789 0.0.0.0:* LISTEN 123456/openclaw-ga

有进程在监听端口 18789,PID 是 123456。

第二步:检查进程详情

1
2
3
4
5
6
# 查看进程详细信息
ps -p 123456 -o pid,ppid,etime,cmd,user

# 示例输出
PID PPID ELAPSED CMD USER
123456 1 15-00:00:00 /opt/openclaw/openclaw-gateway root

关键信息:

  • 进程已经运行了 15 天
  • PPID 是 1(说明是通过 systemd 或直接 init 启动的)
  • 进程名是 openclaw-gateway,不是 openclaw-gateway.service

第三步:检查 systemd 服务状态

1
2
3
4
5
6
7
# 检查 Gateway 服务状态
systemctl status openclaw-gateway

# 示例输出
● openclaw-gateway.service - OpenClaw Gateway
Loaded: loaded (/etc/systemd/system/openclaw-gateway.service; enabled; vendor preset: enabled)
Active: inactive (dead) since Mon 10:30:00 2026; 2h ago

服务状态显示 inactive (dead),但端口却被占用。说明占用端口的进程不是通过 systemd 启动的

问题根因

这种情况下,通常是因为:

  1. 手动启动了进程:有人直接运行了 ./openclaw-gateway,没有通过 systemd
  2. 升级时的遗留:旧版本进程没有被正确退出
  3. 脚本残留:启动脚本里既有 systemd 启动又有直接运行

对于 VM152 的情况,最可能的原因是:之前有人手动启动了一个 Gateway,后来用 systemd 重启服务时,旧的进程没有被清理

解决方案

步骤一:杀掉旧进程

1
2
3
4
5
6
7
8
9
# 先确认这个进程是否可以安全杀掉
ps -p 123456 -o pid,etime,cmd

# 如果确认是旧进程,杀掉它
kill 123456

# 等待几秒,确认进程已退出
sleep 2
ss -tlnp | grep 18789

步骤二:确保 systemd 能正确管理服务

1
2
3
4
5
6
7
8
9
10
11
# 检查服务是否 enabled
systemctl is-enabled openclaw-gateway

# 如果不是 enabled,启用它
systemctl enable openclaw-gateway

# 重启服务
systemctl restart openclaw-gateway

# 检查服务状态
systemctl status openclaw-gateway

步骤三:验证端口监听

1
2
3
4
5
# 验证端口现在由 systemd 服务监听
ss -tlnp | grep 18789

# 确认是 systemd 启动的进程
ps aux | grep openclaw-gateway | grep -v grep

一键解决方案脚本

如果你经常遇到这个问题,可以使用以下脚本:

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
#!/bin/bash
# openclaw-gateway-port-fix.sh
# 用于清理占用 18789 端口的旧进程并重启服务

PORT=${1:-18789}
SERVICE_NAME="openclaw-gateway"

echo "=== OpenClaw Gateway 端口冲突修复脚本 ==="
echo ""

# 1. 检查端口占用
echo "1. 检查端口 ${PORT} 占用情况..."
ss -tlnp | grep ":${PORT} " || echo "端口未被占用"
echo ""

# 2. 找到占用进程
echo "2. 分析占用进程..."
PID=$(ss -tlnp | grep ":${PORT} " | grep -oP 'pid=\K\d+' | head -1)
if [ -n "$PID" ]; then
ps -p $PID -o pid,ppid,etime,user,cmd
echo ""

# 3. 检查是否是 systemd 管理的进程
echo "3. 检查进程来源..."
SYSTEMD_PID=$(systemctl show --property=MainPID --value ${SERVICE_NAME} 2>/dev/null)
if [ "$PID" = "$SYSTEMD_PID" ]; then
echo "进程由 systemd 管理 (PID=$PID),可能是服务启动失败"
echo "检查日志:journalctl -u ${SERVICE_NAME} -n 50"
systemctl status ${SERVICE_NAME}
else
echo "进程 $PID 不是由 systemd 管理(systemd 认为 MainPID=$SYSTEMD_PID)"
echo "这是旧进程残留,正在清理..."

# 4. 清理旧进程
echo "4. 清理旧进程..."
kill $PID
sleep 2

# 5. 确认清理成功
if ss -tlnp | grep -q ":${PORT} "; then
echo "警告:端口仍被占用,尝试强制杀掉"
kill -9 $PID
sleep 1
fi
fi
else
echo "端口未被占用"
fi
echo ""

# 6. 重启服务
echo "5. 重启 ${SERVICE_NAME} 服务..."
systemctl restart ${SERVICE_NAME}
sleep 2

# 7. 验证结果
echo "6. 验证结果..."
if systemctl is-active ${SERVICE_NAME}; then
echo "✅ 服务运行正常"
ss -tlnp | grep ":${PORT} "
else
echo "❌ 服务启动失败,检查日志:"
systemctl status ${SERVICE_NAME} --no-pager
journalctl -u ${SERVICE_NAME} -n 20 --no-pager
fi

使用方法:

1
2
3
4
5
6
7
8
9
10
# 保存脚本
sudo tee /usr/local/bin/openclaw-gateway-port-fix.sh << 'EOF'
# (粘贴上面的脚本内容)
EOF

# 添加执行权限
sudo chmod +x /usr/local/bin/openclaw-gateway-port-fix.sh

# 执行脚本
sudo /usr/local/bin/openclaw-gateway-port-fix.sh

问题三:插件加载但有 TypeScript 错误

问题描述

VM153 上的钉钉连接器(dingtalk-connector)有一个 TypeScript 编译错误:

1
Error: Cannot find entry module for TypeScript: './dist/index.js'

分析

这个错误不影响飞书插件,因为钉钉插件和飞书插件是独立的。如果钉钉插件加载失败,飞书插件仍然可以正常工作。

VM153 的情况验证了这一点——钉钉插件有错误,但飞书 WebSocket 连接正常。

处理建议

如果需要修复钉钉插件的错误,可以:

  1. 更新插件版本

    1
    openclaw plugin update @openclaw/dingtalk
  2. 重新编译 TypeScript

    1
    2
    cd ~/.openclaw/plugins/dingtalk-connector
    npm run build
  3. 如果不需要钉钉功能,可以禁用插件

    1
    2
    3
    # 在配置文件中禁用
    openclaw config set plugins.dingtalk.enabled false
    systemctl restart openclaw-gateway

预防措施

1. Node.js 版本统一

为了避免 Node.js 版本问题,建议在所有服务器上使用相同版本:

1
2
# 在配置管理工具中添加 Node.js 版本检查
# 或者使用 Docker 容器来隔离 Node.js 环境

2. 禁止手动启动 Gateway

建议通过 systemd 来管理所有 Gateway 服务,禁止手动运行:

1
2
3
4
# 在 /etc/openclaw/config.yml 中添加限制
gateway:
# 只允许通过 systemd 启动
allow_manual_start: false

3. 升级脚本中加入进程检查

在升级脚本中,先检查并清理旧进程:

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
#!/bin/bash
# openclaw-upgrade.sh

# 1. 检查并停止旧服务
echo "停止旧服务..."
systemctl stop openclaw-gateway || true

# 2. 等待端口释放
echo "等待端口释放..."
sleep 3

# 3. 检查是否有残留进程
PID=$(ss -tlnp | grep ":18789 " | grep -oP 'pid=\K\d+' | head -1)
if [ -n "$PID" ]; then
echo "发现残留进程 PID=$PID,正在清理..."
kill $PID || true
sleep 2
fi

# 4. 执行升级
echo "执行升级..."
npm install -g openclaw-gateway

# 5. 启动新服务
echo "启动新服务..."
systemctl start openclaw-gateway

4. 配置端口检查告警

添加一个监控任务,定期检查端口占用情况:

1
2
# 添加到 crontab
*/5 * * * * /usr/local/bin/check-gateway-port.sh

常见问题解答

Q:为什么 Node.js 18 不能运行某些插件?

A:某些新的 OpenClaw 插件使用了较新的 Node.js API(如 fetch 内置支持、crypto 模块更新等),这些 API 在 Node.js 18 中不可用或行为不同。建议使用 Node.js 22 或更高版本。

Q:端口被占用但找不到进程怎么办?

A:可能是僵尸进程或内核级别的占用。可以尝试:

  1. ps aux | grep -v grep | grep 18789 确认进程
  2. 检查是否有 socket 文件残留:ls -la /var/run/openclaw-gateway.*
  3. 如果是 Docker 环境,检查容器网络配置

Q:如何避免端口冲突再次发生?

A:核心是确保所有 Gateway 服务都通过 systemd 管理:

  1. 禁止手动 ./openclaw-gateway 启动
  2. 升级前先停止旧服务
  3. 升级脚本中加入进程清理逻辑
  4. 配置端口监控告警

Q:systemctl 显示服务 active,但端口没监听怎么办?

A:可能是服务启动后又崩溃了。检查方法:

1
2
3
4
5
6
# 查看服务状态和最新日志
systemctl status openclaw-gateway
journalctl -u openclaw-gateway -n 50

# 检查是否有崩溃
journalctl --system --priority=3 -n 20

Q:钉钉插件报错但飞书正常,需要处理吗?

A:如果只使用飞书通道,钉钉插件的报错可以忽略。如果需要同时使用钉钉和飞书,则需要修复钉钉插件的错误。建议检查插件版本和 Node.js 兼容性。

总结

今天遇到的三个问题,本质上都是**”环境一致性”和”历史遗留”**问题:

  1. Node.js 版本不匹配:不同服务器的环境不一致,有些用 v18,有些用 v22
  2. 端口被旧进程占用:之前手动启动的进程没有被清理
  3. 插件错误不影响主流程:钉钉插件报错,但飞书功能正常

解决方案:

  1. 使用 nvm 统一管理 Node.js 版本
  2. 通过脚本自动化处理端口冲突
  3. 理清插件之间的依赖关系,独立处理

核心经验是:**运维工作不仅仅是”把服务跑起来”,还要确保”环境可重复、问题可追溯”**。只有这样,才能避免同样的问题反复出现。

希望这篇文章对正在经历类似问题的同学有所帮助。如果有更好的实践方法,欢迎交流。


作者:小六,一个今天装了三个插件查了三个问题的运维工程师
本文使用 picsum.photos 题图,授权可商用

Author:Margrop
Link:http://blog.margrop.com/post/2026-05-12-openclaw-plugin-installation-node-version-and-port-conflict-troubleshooting/
版权声明:本文采用 CC BY-NC-SA 3.0 CN 协议进行许可