Nacos 2.0 关闭 8848 端口只开 9848 对旧客户端有影响吗?

文章导读
关闭 8848 端口只保留 9848 会导致 Nacos 1.x 旧客户端无法连接,因为旧客户端依赖 HTTP 协议的 8848 端口进行通信。Nacos 2.x 客户端主要使用 9848 端口进行 gRPC 通信,但 8848 端口仍用于控制台访问及部分 HTTP API。只有在确认所有客户端均升级到 2.x 版本且不需要 HTTP API 兼容时,才可评估调整端口配置。
📋 目录
  1. 核心结论与原理
  2. 实操步骤
  3. 怎么验证是否生效
  4. 常见坑
  5. 参考来源
A A

关闭 8848 端口只保留 9848 会导致 Nacos 1.x 旧客户端无法连接,因为旧客户端依赖 HTTP 协议的 8848 端口进行通信。Nacos 2.x 客户端主要使用 9848 端口进行 gRPC 通信,但 8848 端口仍用于控制台访问及部分 HTTP API。只有在确认所有客户端均升级到 2.x 版本且不需要 HTTP API 兼容时,才可评估调整端口配置。

先说结论:8848 端口是 Nacos 2.0 保持向后兼容及管理控制台的关键端口,关闭它会直接阻断 1.x 客户端的连接能力,生产环境不建议单独关闭。

  • 先确认:检查当前所有客户端的版本号,确认是否存在 1.x 版本
  • 先处理:保持 8848 和 9848 端口同时开放,完成客户端升级后再评估调整
  • 再验证:升级后测试服务注册、配置获取、心跳上报等核心功能

核心结论与原理

Nacos 2.0 的端口设计采用了偏移量机制,默认主端口 8848 基础上自动计算其他端口。各端口用途分工明确:

  • 8848 端口:HTTP API 和控制台访问,保持对旧版客户端的兼容
  • 9848 端口(8848+1000):客户端 gRPC 请求服务端端口,2.x 客户端核心通信端口
  • 9849 端口(8848+1001):服务端 gRPC 请求服务端端口,用于服务间同步
  • 7848 端口(8848-1000):Jraft 请求服务端端口,用于处理服务端间的 Raft 相关请求

Nacos 1.x 客户端仅依赖 HTTP 协议与 8848 端口通信,没有 gRPC 连接能力。当 8848 端口关闭后,1.x 客户端无法完成服务注册、配置获取等基础操作。2.x 客户端虽然主要使用 9848 进行 gRPC 通信,但仍建议保留 8848 以支持控制台管理及部分 HTTP 接口调用。

实操步骤

第一步:检查客户端版本分布

在 Nacos 控制台的服务列表页面,查看各服务的客户端版本信息。或者在应用日志中搜索 nacos-client 版本号:

Nacos 2.0 关闭 8848 端口只开 9848 对旧客户端有影响吗?
grep -r 'nacos-client' /path/to/your/project/lib/ | head -20

记录所有使用 1.x 版本的应用清单,这些应用必须优先升级。

第二步:配置防火墙与安全组

在防火墙或安全组中确保以下端口开放。注意命令语法,避免直接复制错误:

# Linux 防火墙开放示例(CentOS)
firewall-cmd `--add-port`=8848/tcp `--permanent`
firewall-cmd `--add-port`=9848/tcp `--permanent`
firewall-cmd `--add-port`=9849/tcp `--permanent`
firewall-cmd `--reload`

云环境需要在安全组规则中同时放行这三个端口。

第三步:升级客户端依赖

将项目中的 Nacos 客户端依赖升级到 2.x 稳定版本。以 Maven 为例:

Nacos 2.0 关闭 8848 端口只开 9848 对旧客户端有影响吗?
<dependency>
    <groupId>com.alibaba.nacos</groupId>
    <artifactId>nacos-client</artifactId>
    <version>2.2.0</version>
</dependency>

Spring Cloud Alibaba 项目需要同步升级对应版本,确保兼容性。

第四步:容器化部署端口映射

Docker 或 Kubernetes 环境中容易只映射 8848 端口,忘记 9848 和 9849,导致 2.x 客户端连接失败。完整映射示例如下:

# Docker 运行示例
docker run -d \
-p 8848:8848 \
-p 9848:9848 \
-p 9849:9849 \
`--name` nacos-standalone \
nacos/nacos-server

Kubernetes Service 配置中需确保 targetPort 包含 9848 和 9849。

怎么验证是否生效

完成升级和端口配置后,按以下顺序验证:

  1. 从客户端机器测试端口连通性:
    telnet <nacos-server-ip> 8848
    telnet <nacos-server-ip> 9848
  2. 检查应用启动日志,确认没有'Client not connected'或'Server check fail'相关错误
  3. 在 Nacos 控制台查看服务列表,确认服务正常注册且状态健康
  4. 测试配置变更推送,验证 9848 端口的 gRPC 长连接是否正常工作

常见坑

  • 容器化部署只暴露 8848:忘记 9848 和 9849,导致 2.x 客户端连接失败
  • 修改主端口后忘记偏移量:如果将 server.port 从 8848 改为其他值,gRPC 端口会自动按偏移量计算,需要同步调整防火墙规则
  • 防火墙只放行 8848:企业网络或云安全组可能只开放了 8848,9848 被阻断,表现为 8848 能访问但 gRPC 连接超时
  • 客户端与服务端版本不匹配:2.x 客户端连接 1.x 服务端会报 9848 端口不可用,因为 1.x 服务端没有监听该端口
  • VIP 或 Nginx 转发配置错误:使用负载均衡时,9848 端口需要配置 TCP 转发,不能配置 HTTP/2 转发,否则连接会被断开
  • 7848 和 9849 端口暴露风险:这两个端口是服务端间通信端口,不应暴露到外部网络,只需在内网开放

参考来源

  • Nacos 官方 GitHub 仓库 - Issue 讨论区
  • Nacos 官方文档 - 2.0 版本升级指南
  • Spring Cloud Alibaba 官方文档 - 组件版本依赖说明