Consul RPC 与 8300 端口
8300 是 HashiCorp Consul 服务端的 RPC 端口：client 与 server 之间的请求、server 之间的转发，以及 KV 与服务注册数据的查询都通过它完成。Consul 的端口是一整套：8300 RPC、8301 局域网 gossip、8302 跨数据中心 gossip、8500 HTTP API、8600 DNS 接口，缺一不可，漏放一个就会出现部分节点看不到这类难查的问题。
基本信息
| 服务 | Consul server RPC |
|---|---|
| 端口/协议 | TCP 8300，可启用 TLS |
| 配套端口 | 8301/8302 gossip 兼顾 TCP 与 UDP，8500 HTTP，8600 DNS |
| 集群模式 | server 与 client 角色，server 通常部署 3 或 5 个 |
| 权限要求 | 运维人员；启用 ACL 后需相应 token |
| 安全等级 | 仅集群与代理网段，禁止公网暴露 |
典型使用场景
- 服务发现：注册数据经 8300 汇聚，业务通过 8500 或 8600 查询健康实例
- 配置中心：把配置键值存入 KV 并由应用读取
- 多数据中心：8302 负责跨机房 gossip，8300 负责跨区 RPC
- 健康检查：agent 上报结果，server 汇聚后影响解析输出
- 集群运维：查看成员、调整 raft 成员与 leader
集群状态确认
集群状态确认
consul members # 查看集群成员与状态
consul operator raft list-peers # 查看 raft 成员与是否选出 leader
ss -lntp | grep -E '830[0-2]|8500|8600' # 核对全部相关端口是否在听
# server 启动参数示例
# consul agent -server -bootstrap-expect=3 -data-dir=/opt/consul -bind=10.0.1.11 -client=127.0.0.1
# 安全加固：gossip 使用 -encrypt，RPC 启用 TLS，并规划 ACL token 与策略Consul 端口分工
| 端口 | 角色 | 协议 |
|---|---|---|
| 8300 | server RPC，client 与 server 通信 | TCP |
| 8301 | 局域网 gossip | TCP 加 UDP |
| 8302 | 跨数据中心 gossip | TCP 加 UDP |
| 8500 | HTTP API 与 Web UI | TCP |
| 8600 | DNS 接口 | UDP 加 TCP |
运维要点
- server 节点数以 3 或 5 为宜，偶数容易在脑裂场景下无法形成多数派
- gossip 加密密钥需要全集群同步轮换，变更前先在测试集群演练一遍
- 启用 ACL 的顺序是先引导管理 token、再写策略、最后逐步收紧，避免锁死运维通道
- 备份与恢复演练要覆盖 raft 元数据与 snapshot，不只是 KV 内容
- 对外探活用 /v1/status/leader 与健康服务接口，别只看端口是否监听
bootstrap-expect 只在首次引导时使用，集群稳定后应从配置中移除；长期保留会导致节点重启后仍试图重新引导，出现难以解释的成员状态异常。
Consul 的 DNS 接口默认监听 8600，查询时要显式指定，例如 dig @127.0.0.1 -p 8600 web.service.consul，否则请求会打到系统 DNS。若要给应用直接使用，需要在 dnsmasq 或 resolv.conf 中配置转发。
8300 未启用 TLS 与 ACL 时，能连上的客户端可以注册任意服务或读取全部 KV。集群应开启 gossip 加密、RPC TLS 与 ACL，并只在集群网段放行 8300 至 8302。