dev container模式下node调试连通的关键是：node进程必须监听0.0.0.0:9229（而非127.0.0.1），devcontainer.json中配置"forwardports": [9229]，且sourcefilemap需精准映射容器内路径（如/app）到本地工作区，差一个字符断点即失效。

直接用 Remote-Containers 扩展启动 Dev Container 是最稳的方式，能绕过 90% 的路径错位、端口不通、断点不命中问题；手动 attach 到已有容器容易卡在 --inspect 绑定地址或 sourceFileMap 配置上。

Dev Container 模式下怎么让 Node 调试器真正连上？

关键不是“能不能连”，而是容器里 Node 进程是否对外暴露调试端口，且 VSCode 知道代码在哪。

• CMD ["npm", "run", "debug"] 必须搭配 "debug": "node --inspect=0.0.0.0:9229 server.js" —— 漏掉 =0.0.0.0 就只监听 127.0.0.1，容器内其他进程都连不上，VSCode 更不可能 attach
• devcontainer.json 中的 "forwardPorts": [9229] 是必须项，它让 VSCode 自动把宿主机随机端口转发到容器 9229，不用手写 -p 9229:9229
• 别依赖自动推断 remoteRoot：Dev Container 默认挂载路径是 /workspace，但如果你在 Dockerfile 里写了 WORKDIR /app，就得在 devcontainer.json 里显式加 "workspaceFolder": "/app"

为什么断点永远不命中？

不是代码没跑，是 VSCode 调试器看到的文件路径和 Node 进程加载的真实路径对不上。

Rydberg Agent Node

使用一条命令部署ProbeChain Rydberg测试网代理节点。自动注册为Agent(NodeType=1)，免gas，支持macOS/Linux/Windows。触发词：/r

下载

• 容器里报错显示 /app/server.js:42，你就得在 launch.json 或 devcontainer.json 里写清楚："sourceFileMap": { "/app": "${workspaceFolder}" }
• 如果项目用了 TypeScript 或构建工具（如 Vite、Webpack），源码路径更复杂，sourceFileMap 得映射到 dist 或 .vscode/.tmp 下的真实输出路径，而不是原始 src/
• 用 console.log(__filename) 在服务启动时打印真实路径，比猜配置靠谱得多

attach 到已有 docker-compose 容器时最容易错哪？

不是配置 launch.json，而是容器根本没按调试模式启动。

• 检查容器内是否真监听了 0.0.0.0:9229：进容器执行 lsof -i :9229，输出必须含 *:9229，若只有 127.0.0.1:9229 就失败
• docker-compose.yml 里得有 ports: - "9229:9229"，且服务启动命令明确带 --inspect=0.0.0.0:9229，光写 --inspect 默认绑 127.0.0.1
• launch.json 的 "address": "localhost" 指的是宿主机，"port": 9229 必须和 docker-compose.yml 里 - "9229:9229" 左边那个端口一致

最常被忽略的其实是 WORKDIR 和 workspaceFolder 的一致性——差一个斜杠、多一层目录，断点就静默失效，而错误提示里根本不会提这事。