1Panel部署Node.js应用时端口无法访问？

Question

在1Panel中部署Node.js应用后端口无法访问，是高频问题。常见原因包括：① 应用未监听 `0.0.0.0:{port}`（仅监听 `localhost` 或 `127.0.0.1`），导致容器/宿主机网络不可达；② 1Panel反向代理配置错误——未正确设置「目标地址」（如写成 `http://127.0.0.1:3000` 而非容器内服务地址 `http://app:3000`）或未启用HTTPS/HTTP协议透传；③ 防火墙（如UFW、firewalld）或云服务器安全组未放行对应端口；④ Node.js进程启动失败（日志显示 `EADDRINUSE` 或崩溃），但1Panel状态仍显示“运行中”；⑤ 使用PM2等进程管理器时未配置 `--watch` 或 `--no-daemon`，导致热更新后实际服务中断。建议按「查日志→验监听→测连通→检代理→核防火墙」五步排查，优先通过 `docker exec -it netstat -tuln` 验证容器内端口绑定状态。

Answer 1

```html

一、现象层：端口不可达的表征与初始判断

在1Panel中完成Node.js应用部署后，浏览器访问https://your-domain.com或直接请求http://server-ip:3000返回ERR_CONNECTION_REFUSED、502 Bad Gateway或超时，是典型“端口无法访问”现象。该问题不体现为应用崩溃报错，而表现为网络链路中断——需警惕“状态显示运行中，实则服务未就绪”的假阳性。

二、日志层：穿透表象的第一把钥匙

• 进入1Panel → 「应用」→ 选择对应Node.js服务 → 点击「日志」：重点筛查EADDRINUSE（端口被占）、Cannot find module（路径错误）、TypeError: app.listen is not a function（Express初始化异常）；
• 若使用PM2：执行docker exec -it <container_name> pm2 logs，确认是否因--no-daemon缺失导致子进程脱离控制；
• 关键信号：Server running on http://localhost:3000 ≠ 可被外部访问——此日志仅说明进程启动成功，不反映监听地址有效性。

三、网络层：容器内监听地址的致命细节

Node.js默认监听127.0.0.1:3000（或localhost:3000），但Docker容器网络中127.0.0.1指向容器自身回环，而非宿主机或同网络其他容器。正确写法必须为：

app.listen(3000, '0.0.0.0', () => {
  console.log('Server running on http://0.0.0.0:3000');
});

验证方式（核心动作）：docker exec -it <container_name> netstat -tuln | grep :3000 —— 输出应含*:3000或0.0.0.0:3000，而非127.0.0.1:3000。

四、代理层：1Panel反向代理配置的五大陷阱

错误配置	正确配置	后果
http://127.0.0.1:3000	http://app:3000（Docker Compose服务名）	反向代理连向宿主机回环，非容器内部网络
未启用「HTTPS透传」	勾选「启用HTTPS协议透传」	前端HTTPS请求被降级为HTTP，触发混合内容拦截

五、基础设施层：防火墙与云安全组的隐性拦截

即使容器监听0.0.0.0且代理配置无误，仍需逐层校验：

• 宿主机防火墙：sudo ufw status verbose（Ubuntu）或sudo firewall-cmd --list-ports（CentOS）；
• 云平台安全组：阿里云/腾讯云/AWS控制台中，确保入方向规则开放目标端口（如80/443或自定义端口），协议为TCP，源IP建议设为0.0.0.0/0（生产环境按需收紧）；
• 注意：Docker默认绕过ufw，需显式配置DEFAULT_FORWARD_POLICY="ACCEPT"并重启ufw。

六、进程管理层：PM2在容器中的生存逻辑

在1Panel的Docker环境中，PM2若以守护模式（daemon）运行，将导致：

• 热更新后主进程PID变更，但1Panel仍监控旧PID；
• 容器启动脚本未加--no-daemon，PM2 fork子进程后退出前台，触发Docker认为容器已终止；
• 解决方案：Dockerfile中使用CMD ["pm2-runtime", "start", "ecosystem.config.js", "--no-daemon"]，确保PM2前台驻留。

七、系统性排查流程图（Mermaid）

flowchart TD
    A[查日志] --> B{进程是否启动？}
    B -->|否| C[修复代码/依赖/配置]
    B -->|是| D[验监听：docker exec netstat -tuln]
    D --> E{是否绑定 0.0.0.0:PORT？}
    E -->|否| F[修改 listen 地址为 '0.0.0.0']
    E -->|是| G[测连通：curl -v http://localhost:3000 容器内]
    G --> H{返回200？}
    H -->|否| I[检查Node.js路由/中间件]
    H -->|是| J[检代理：1Panel目标地址+透传设置]
    J --> K[核防火墙/安全组]

八、高阶验证：跨网络域连通性诊断

执行以下命令组合，构建完整证据链：

1. docker inspect <container_name> | jq '.[0].NetworkSettings.Networks' → 确认容器所属网络及IP；
2. curl -v http://<container_ip>:3000（从宿主机发起）→ 验证容器网络可达性；
3. curl -v http://127.0.0.1:3000（从宿主机发起）→ 若失败，说明1Panel未正确映射端口或Nginx未转发；
4. docker exec -it <nginx_container> curl -v http://app:3000 → 验证反向代理上游连通性。

九、生产环境加固建议

• 在package.json中添加"prestart": "node -e \"console.log('Listening on 0.0.0.0:' + process.env.PORT)\""，强制暴露监听意图；
• 1Panel应用配置中启用「健康检查」：路径设为/healthz，响应码200，避免“运行中但不可用”；
• 使用docker-compose.yml定义明确网络别名（aliases: [app]），杜绝硬编码IP；
• 为Node.js容器添加restart: unless-stopped与healthcheck指令，实现自愈能力。

十、终极检查清单（Checklist）

序号	检查项	执行命令/操作	预期结果
1	Node.js监听地址	grep -r "listen.*3000" ./src/	含'0.0.0.0'或0.0.0.0
2	容器端口绑定	docker exec -it app netstat -tuln | grep :3000	*:3000 或 0.0.0.0:3000
3	1Panel代理目标	进入「网站」→「反向代理」→ 查看目标地址	http://app:3000（非127.0.0.1）

```