问题说明

本文用于排查ZCenter部署后无法访问、接口返回502/503、服务启动失败或服务之间无法发现等端口和依赖连通性问题。本文区分外部代理端口与Gateway内部端口，避免将8100和8200混用。

现象

• 客户端访问 http://<host>:8100 时连接超时、Connection refused或无法建立连接。
• 8100可以连接但返回502/503，或页面能打开但API请求失败。
• 服务启动日志出现连接 3306、6379、5672、8848 被拒绝、超时或认证失败。
• Gateway可访问，但访问 /api/portal/...、/api/vm/... 等接口返回503或无路由。

适用环境

• 产品：ZCenter
• 版本：5.1.0
• 组件：Caddy/反向代理、Gateway、Nacos、Base及各业务服务
• 部署形态：单节点或多节点；实际端口可能被部署参数、容器映射、负载均衡或防火墙策略覆盖

可能原因

• 外部防火墙、负载均衡或安全组未放通8100，或者Caddy没有监听该端口。
• Caddy监听8100但无法连接本机Gateway 8200。
• Gateway未启动，或启动后无法连接Nacos 8848，导致服务发现/路由失败。
• Base、Portal或业务服务使用的内部端口与实际部署映射不一致。
• MariaDB/MySQL、Redis或RabbitMQ未启动、地址配置错误或认证信息不匹配。

排查步骤

端口和访问关系

1. 从客户端确认外部入口

• 命令：

  curl -v --max-time 10 http://<zcenter-host>:8100/

• 预期结果：TCP连接成功并返回页面或HTTP响应。即使返回404，也说明端口和HTTP路径已到达服务。
• 异常处理：超时或Connection refused时，检查外部防火墙、安全组、负载均衡/NAT映射和Caddy监听状态，不要先排查业务接口。

2. 在ZCenter主机检查8100和8200

• Linux命令：

  ss -lntp | grep -E ':(8100|8200)\b'
  curl -v --max-time 10 http://127.0.0.1:8100/
  curl -v --max-time 10 http://127.0.0.1:8200/

• 预期结果：Gateway在8200监听；如启用Caddy，外部代理在8100监听且本机8100可访问。
• 异常处理：8200未监听时检查Gateway启动日志；8200正常而8100异常时检查Caddy配置和进程；8100仅本机可访问时检查外部监听地址和防火墙。

3. 验证代理到Gateway的路由

• 命令：

  curl -v --max-time 10 http://127.0.0.1:8100/api/portal/v4/pub/login

• 预期结果：返回参数校验、认证失败等应用层响应，表示HTTP路径已到达Gateway或Portal；TCP拒绝/超时不属于业务参数问题。
• 异常处理：8100返回502/503时检查Caddy upstream是否指向可达的127.0.0.1:8200。若Gateway在独立容器中，localhost可能指向错误的网络命名空间，应按实际容器网络调整部署配置。

4. 验证Nacos和服务发现

• 命令：

  curl -v --max-time 10 http://<nacos-host>:8848/nacos/actuator/health

• 检查项：确认Gateway能够访问Nacos，且Portal、Base、VM等目标服务已注册并处于可用状态。
• 预期结果：Nacos可访问，Gateway访问/api/portal/...等路径时能找到对应服务实例。
• 异常处理：检查8848的网络策略、Nacos状态、命名空间/凭据和服务注册日志；不要仅凭Gateway进程存活判断路由正常。

5. 验证外部依赖

• 只读连通性检查：

  nc -vz <db-host> 3306
  nc -vz <redis-host> 6379
  nc -vz <rabbitmq-host> 5672

• 预期结果：端口可达，且使用实际账号执行应用层认证检查。
• 异常处理：根据实际运行时配置核对地址、端口、密码、数据库和TLS设置，并查看对应服务日志。源码中的127.0.0.1仅是默认/示例值，不代表所有部署环境。

6. 按故障范围隔离

• 如果8100和8200都不可达：优先检查Gateway/Caddy进程和主机端口策略。
• 如果8100正常、8200正常但Portal接口503：优先检查Nacos和Portal服务注册/健康状态。
• 如果页面可打开但登录或资源操作失败：继续检查Redis、数据库、RabbitMQ及对应业务服务日志。

7. 收集支持信息

• 记录客户端访问时间、源地址、请求URL、HTTP状态码和完整响应头。
• 收集Caddy、Gateway、Nacos以及受影响业务服务在同一时间窗口的日志。
• 提供部署拓扑、容器/主机网络、端口映射、防火墙/负载均衡规则和实际运行时配置。

处理方式

1. 放通经过确认的外部入口8100及服务间必要访问路径，避免无关端口对外暴露。
2. 恢复Caddy和Gateway进程，确认Caddy的upstream与Gateway实际监听地址一致。
3. 恢复Nacos并确认目标服务重新注册；必要时按部署规范重启受影响服务。
4. 恢复数据库、Redis和RabbitMQ连接后，按业务范围逐项验证，不要通过批量重启或清空缓存掩盖根因。

验证方法

• 入口验证：从客户端访问8100成功，页面和静态资源正常返回。
• 路由验证：通过/api/portal/...和一个受影响业务服务的已知接口获得应用层响应，不再出现502/503。
• 注册验证：Gateway、Portal、Base及目标业务服务在Nacos中处于可用状态。
• 业务验证：完成一次登录和一个受控业务操作，确认任务状态和结果正常。
• 日志验证：观察一个完整请求周期，确认不再出现连接拒绝、连接超时、服务无实例或upstream错误。

风险与回滚

• 修改防火墙、负载均衡或端口映射可能影响现有访问，应先记录原规则并在维护窗口操作。
• 多节点环境不能简单将所有服务端口直接暴露到公网；优先通过外部代理和必要的内部网络策略访问。
• 配置变更后异常时，恢复变更前的端口映射和运行时配置，再按原部署方式重新加载服务。

补充信息

• 关键关系：外部客户端 → 8100 Caddy → 8200 Gateway → Nacos服务实例。
• Gateway的8200不是通常意义上的外部访问入口；外部入口是否为8100仍需结合现场负载均衡和部署配置确认。
• 关联KB：ZCenter 登录或资源同步失败，如何确认并恢复 Redis？。