Node.js服务默认监听127.0.0.1，仅限本机回环访问；需显式指定'0.0.0.0'才能监听所有网卡，使远程设备可通过主机IP访问，同时须配置防火墙及云平台安全组放行对应端口。
VSCode 通过 SSH 连接远程 Linux 主机后，本地启动的 Node.js 服务默认只监听 127.0.0.1，导致在多网卡（如内网 IP、公网 IP、Docker 网桥、虚拟机 NAT 等）环境下，其他设备或宿主机浏览器无法访问 —— 这不是 VSCode 的问题，而是 Node.js 服务本身绑定逻辑和网络拓扑共同导致的。
Node 启动时为什么访问不到？
绝大多数 Node.js 框架（Express、Next.js、Vite、NestJS 等）默认用 app.listen(3000) 或 server.listen(3000)，等价于 server.listen(3000, '127.0.0.1')。这意味着：
- 只接受来自本机 loopback 接口的连接
- 即使 VSCode 已成功 SSH 连入，你在本地浏览器访问 http://:3000 仍会失败
- 远程主机上 curl localhost:3000 成功，但 curl :3000 失败，就是典型表现
如何让 Node 服务监听所有网卡？
只需显式指定监听地址为 0.0.0.0（IPv4 所有接口）或 ::（IPv6），而非默认的 127.0.0.1：
-
app.listen(3000, '0.0.0.0')（Express） -
server.listen(3000, '0.0.0.0')（原生 http.Server） - Vite 项目：在
vite.config.ts中设置server.host: '0.0.0.0' - Next.js：启动命令加
-H 0.0.0.0（如next dev -H 0.0.0.0） - NestJS：在
main.ts中传入0.0.0.0：await app.listen(3000, '0.0.0.0')
注意：某些 CLI 工具（如 create-react-app）不支持直接传 host 参数，需改用 HOST=0.0.0.0 npm start（Linux/macOS）或 set HOST=0.0.0.0 && npm start（Windows CMD）
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
防火墙和远程主机端口暴露是否生效？
即使 Node 绑定到了 0.0.0.0，仍可能被系统级拦截：
- 检查远程主机防火墙：
sudo ufw status（Ubuntu）或sudo firewall-cmd --list-ports（CentOS/RHEL），确保目标端口（如 3000）已放行 - 若使用云服务器（阿里云/腾讯云/AWS），安全组规则必须显式允许该端口从你的 IP 或
0.0.0.0/0入站 - 某些环境（如 Docker 容器内运行 Node）需额外加
--network host或映射端口，VSCode SSH 连的是宿主机，不是容器内部 - 确认远程主机多网卡中，你实际访问的那个 IP（如
192.168.1.100）确实存在且启用：ip a | grep inet
VSCode Remote-SSH 下调试时环境变量是否覆盖 host？
是的，容易被忽略：
- VSCode Remote-SSH 启动的终端默认加载
~/.bashrc或~/.zshrc，但 Node 进程若由 VSCode 的「运行和调试」面板启动（launch.json），其环境变量来自~/.profile或登录 shell，不一定包含你手动 export 的HOST - 推荐在
launch.json中显式注入："env": { "HOST": "0.0.0.0", "PORT": "3000" } - 如果用 nodemon，确保其配置文件（
nodemon.json）或命令行参数也指定--host 0.0.0.0 - 某些框架（如 SvelteKit）依赖
process.env.HOST，仅靠命令行HOST=...不一定被子进程继承，需在package.json脚本里写死或统一用 dotenv
多网卡场景下，真正起作用的永远是 Node 进程监听的地址 + 系统网络策略双重生效，VSCode 只是通道，不参与网络层决策。
