【CC】Claude Code VSCode Extension 卡死问题完整调试记录

是Yu欸

83人浏览 · 2026-06-21 12:42:13

是Yu欸 · 2026-06-21 12:42:13 发布

Claude Code VSCode Extension 卡死问题完整调试记录

写在最前面

请添加图片描述

🌌你好！这里是晓雨的笔记本在所有感兴趣的领域扩展知识，感谢你的陪伴与支持~ 👋 欢迎添加文末好友，不定期掉落福利资讯

写在最前面

版权声明：本文为原创，遵循 CC 4.0 BY-SA 协议。转载请注明出处。

最终方案写到最前面

sudo reboot

重启解决大多数问题hh

原因是：

Server-B 上的 systemd-logind 服务与 D-Bus 通信出现问题
Claude (Node.js 应用) 在初始化时需要通过 D-Bus 与系统服务交互
D-Bus 响应超时，导致整个初始化过程挂起
Claude 卡在 plugin 初始化阶段，等待永远不会到来的 D-Bus 响应

Claude (Kiro) 辅助撰写
日期：2026-06-20
标签：#debugging #systemd #dbus #claude-code #troubleshooting

📋 问题描述

在服务器 Server-B 上使用 Claude Code VSCode Extension 时，每次发送消息后都会卡住 60 秒超时，而在同配置的服务器 Server-A 上却完全正常。

现象：

发送消息后 Extension 无响应
60 秒后超时报错
日志显示在 “Found 0 plugins” 后停止
API 代理工作正常，curl 测试成功
Claude CLI 同样卡死

🔍 调试过程

第一阶段：配置排查（❌ 无效）

尝试 1：检查 API 配置

对比了 Server-A 和 Server-B 的 ~/.claude/settings.json
配置完全相同，API 地址和 token 正确
结论：配置没有问题

尝试 2：重建配置文件

# 备份并重建
mv ~/.claude ~/.claude_backup
cat > ~/.claude/settings.json << 'EOF'
{
  "env": {
    "ANTHROPIC_BASE_URL": "http://api-gateway.internal:28647/",
    "ANTHROPIC_AUTH_TOKEN": "sk-ant-xxxxx...",
    "ANTHROPIC_MODEL": "claude-opus-4-8"
  }
}
EOF

结果：问题依旧

尝试 3：测试 API 连接

curl -X POST 'http://api-gateway.internal:28647/v1/messages' \
  -H 'x-api-key: sk-ant-xxxxx...' \
  -d '{"model":"claude-opus-4-8","max_tokens":50,"messages":[{"role":"user","content":"hi"}]}'

结果：API 完全正常，返回 200
结论：API 服务端没有问题

第二阶段：网络和代理排查（❌ 无效）

尝试 4：使用 localhost 代理

# 在 Server-B 上启动本地代理
python3 /tmp/api_proxy.py &
# 转发 localhost:28647 → api-gateway.internal:28647

# 更新配置使用 localhost
ANTHROPIC_BASE_URL="http://localhost:28647/"

结果：问题依旧
结论：不是网络延迟或 DNS 问题

尝试 5：检查防火墙和网络连接

# 检查端口监听
netstat -tln | grep 28647

# 测试代理
curl http://localhost:28647/v1/messages

结果：代理工作正常，curl 返回 200
结论：网络层面完全正常

第三阶段：进程和日志分析（🔍 发现线索）

尝试 6：追踪 Claude 进程

# 实时监控日志
tail -f ~/.claude/sessions/*/debug.log

# 发现关键日志
2026-06-20T02:06:16.240Z [DEBUG] Found 0 plugins (0 enabled, 0 disabled)
# 之后就卡住，没有后续日志

发现：Claude 在 plugin 初始化后挂起
正常流程应该继续执行 getPluginSkills()

尝试 7：对比 Server-A 的日志

# Server-A 上的正常日志
Found 0 plugins (0 enabled, 0 disabled)
getPluginSkills: Processing 0 enabled plugins  # 立即继续
Total plugin workflows loaded: 0
...

结论：Server-B 上 Claude 在调用 getPluginSkills() 时永久挂起

尝试 8：strace 追踪系统调用

strace -e trace=read,connect ~/.vscode-server/.../claude --print 'hi'

发现：Claude 不断重复读取 /proc/PID/stat
疑似陷入某种监控循环或等待状态

第四阶段：环境隔离测试（🔍 确认系统级问题）

尝试 9：隔离测试环境

# 完全隔离的环境
mkdir /tmp/claude_test
cd /tmp/claude_test
export HOME=/tmp/claude_test
export ANTHROPIC_BASE_URL='http://localhost:28647/'

timeout 15 ~/.vscode-server/.../claude --print 'hi'

结果：仍然卡住！
重要发现：问题与 ~/.claude 配置无关，是系统级问题

尝试 10：对比系统环境

# 对比内核版本
uname -r  # 两台都是 6.11.0-17-generic

# 对比 ulimit
ulimit -a  # 基本相同

# 对比 MD5
md5sum claude  # binary 完全相同

# 对比系统库
ldd claude | grep libc  # 版本相同

结论：系统环境高度相似，但 Server-B 就是不工作

第五阶段：Claude CLI 直接测试（🔍 复现问题）

尝试 11：CLI 直接调用

export ANTHROPIC_BASE_URL='http://localhost:28647/'
export ANTHROPIC_AUTH_TOKEN='sk-...'

echo 'What is 1+1?' | timeout 20 \
  ~/.vscode-server/.../claude --no-chrome

结果：超时，无输出
确认：CLI 和 Extension 都有同样问题

尝试 12：Debug 模式追踪

claude --no-chrome --debug --debug-to-stderr --print 'hi'

输出：

[DEBUG] Found 0 plugins (0 enabled, 0 disabled)
[DEBUG] Git remote URL: null
[DEBUG] No git remote URL found
# 卡住，没有 getPluginSkills 日志

第六阶段：Binary 和 Extension 替换（❌ 无效）

尝试 13：从 Server-A 复制整个 Extension

rsync -az ~/.vscode-server/extensions/anthropic.claude-code-2.1.183-linux-x64/ \
  user@Server-B:~/.vscode-server/extensions/anthropic.claude-code-2.1.183-linux-x64/

结果：问题依旧
结论：Extension 本身没有问题

第七阶段：根因发现（✅ 找到问题！）

尝试 14：测试 systemd 服务

# 尝试重启（需要 sudo）
sudo reboot

# 报错：
Failed to activate service 'org.freedesktop.login1': 
timed out (service_start_timeout=25000ms)

💡 关键发现：systemd-logind 和 D-Bus 通信超时！

验证：

systemctl status systemd-logind.service
# Status: active (running)
# 但 D-Bus 调用超时 25 秒

systemctl status dbus.service  
# Status: active (running)
# 但队列可能阻塞

根本原因分析：

Server-B 上的 systemd-logind 服务与 D-Bus 通信出现问题
Claude (Node.js 应用) 在初始化时需要通过 D-Bus 与系统服务交互
D-Bus 响应超时，导致整个初始化过程挂起
Claude 卡在 plugin 初始化阶段，等待永远不会到来的 D-Bus 响应

✅ 解决方案

方案 1：重启 systemd 服务（推荐）

sudo systemctl restart systemd-logind.service

方案 2：完全重启服务器（如果方案 1 失败）

sudo reboot

重启后的恢复步骤

重启 API 代理

python3 /tmp/api_proxy.py &

验证 API

curl http://localhost:28647/v1/messages -X POST \
  -H 'x-api-key: sk-...' \
  -d '{"model":"claude-opus-4-8","max_tokens":10,"messages":[...]}'

测试 Claude CLI

export ANTHROPIC_BASE_URL='http://localhost:28647/'
export ANTHROPIC_AUTH_TOKEN='sk-...'
echo 'hi' | claude --no-chrome

恢复聊天记录

# 从备份恢复
cp -r ~/.claude_backup_20260620_100604/projects/* ~/.claude/projects/
cp -r ~/.claude_backup_20260620_100604/sessions/* ~/.claude/sessions/
cp -r ~/.claude_backup_20260620_100604/file-history ~/.claude/
cp -r ~/.claude_backup_20260620_100604/session-env ~/.claude/

自动化恢复脚本

创建 /tmp/restore_claude_69.sh：

#!/bin/bash
echo "=== Claude Server-B 恢复脚本 ==="

# 1. 启动 API 代理
if ! pgrep -f "api_proxy.py" > /dev/null; then
    nohup python3 /tmp/api_proxy.py > /tmp/api_proxy.log 2>&1 &
    sleep 2
fi

# 2. 验证端口
ss -tln | grep -q ":28647" || exit 1

# 3. 测试 API
HTTP_CODE=$(curl -s -o /dev/null -w '%{http_code}' \
  http://localhost:28647/v1/messages -X POST ...)
[ "$HTTP_CODE" = "200" ] || exit 1

# 4. 测试 Claude CLI
export ANTHROPIC_BASE_URL='http://localhost:28647/'
export ANTHROPIC_AUTH_TOKEN='sk-...'
TEST_OUTPUT=$(echo 'hi' | timeout 15 claude --no-chrome 2>&1)
echo "$TEST_OUTPUT" | grep -qi "kiro\|claude" || exit 1

echo "✓ 所有检查通过！"

📊 问题验证

重启前：

$ echo 'hi' | claude --no-chrome
# 60秒超时，无输出

重启后：

$ echo 'hi' | claude --no-chrome
Hi! I'm Kiro, ready to help...
# ✅ 立即响应

Debug 日志对比：

重启前：

[DEBUG] Found 0 plugins (0 enabled, 0 disabled)
[DEBUG] Git remote URL: null
# 卡住

重启后：

[DEBUG] Found 0 plugins (0 enabled, 0 disabled)
[DEBUG] Git remote URL: null
[DEBUG] getPluginSkills: Processing 0 enabled plugins  # ✅ 继续执行
[DEBUG] Total plugin workflows loaded: 0
[DEBUG] Commands and agents loaded in 52ms
...

🎓 经验总结

1. 问题定位的关键步骤

由表及里的排查顺序：

✅ 配置文件（最常见）
✅ 网络连接（次常见）
✅ 进程状态和日志（找到线索）
✅ 环境隔离测试（确认范围）
✅ 系统服务（根本原因）

2. 重要的调试技巧

日志对比法：

对比正常环境（Server-A）和问题环境（Server-B）的日志
找到最后一条相同的日志，问题就在之后

环境隔离法：

逐步排除配置、用户数据的影响
使用干净的 HOME 目录测试
确认是系统级还是应用级问题

进程追踪法：

使用 strace 追踪系统调用
使用 --debug 模式查看详细日志
监控进程的 CPU、I/O 状态

3. 关键判断点

问题不在 Claude 本身的证据：

同一个 binary 在 Server-A 上正常工作
MD5 哈希完全相同
配置文件相同
API 连接测试成功

问题在系统层面的证据：

隔离环境（新 HOME）仍然失败
系统服务（systemd-logind）超时
D-Bus 通信阻塞
reboot 命令也超时

4. Node.js 应用常见的系统依赖

Node.js 应用（如 Claude）在 Linux 上可能依赖：

D-Bus：系统服务通信
systemd-logind：会话管理
systemd-resolved：DNS 解析
Unix domain sockets：进程间通信

当这些系统服务出现问题时，应用可能：

初始化挂起
超时后继续运行
某些功能失效

5. 为什么 curl 正常但 Claude 不行？

curl：

纯 HTTP 客户端
不依赖 D-Bus
不需要系统会话管理

Claude (Node.js)：

复杂的初始化流程
可能查询系统信息（用户、会话、权限）
依赖多个系统服务

6. 预防和监控

预防措施：

# 定期检查 D-Bus 状态
systemctl status dbus.service

# 监控 systemd-logind
journalctl -u systemd-logind -f

# 检查 D-Bus 队列
dbus-monitor --system

健康检查脚本：

#!/bin/bash
# 系统服务健康检查

check_service() {
    local service=$1
    if systemctl is-active --quiet $service; then
        echo "✓ $service: active"
    else
        echo "✗ $service: inactive"
        return 1
    fi
}

check_service dbus.service
check_service systemd-logind.service

# 测试 D-Bus 通信
timeout 5 dbus-send --system --print-reply \
    --dest=org.freedesktop.login1 \
    /org/freedesktop/login1 \
    org.freedesktop.DBus.Introspectable.Introspect \
    > /dev/null 2>&1

if [ $? -eq 0 ]; then
    echo "✓ D-Bus communication: OK"
else
    echo "✗ D-Bus communication: TIMEOUT"
fi