面向：节点在跑、区块也在涨，但奖励一直不理想，或者官方客户端提示端口有问题的人。
结论先行：Pi 节点的入站端口是 31400 到 31409 一整段共 10 个 TCP 端口，固定不可改。
少开几个，节点看起来照样在跑 —— 这正是最难发现的地方。
先说一个反直觉的硬约束
一个公网 IP，只能让一台节点「可达」。
这不是配置问题，是 Pi 网络的设计：它按公网 IP 认定节点身份和可达性。 所以你不可能在一个 IP 后面同时挂两台节点都算"可达"。
这条约束直接决定了两件事：
- 想跑多节点，要么多拉公网 IP，要么用隧道给每个节点分配独立出口
- 家用宽带只有 1 个公网 IP，那就只能让 1 台节点获得完整的入站可达性
如果你在网上看到"一台机器开 10 个节点都满速"的说法，先问清楚它的出口 IP 是怎么解决的。
10 个端口分别是什么
Pi 节点实际是几个服务跑在 Docker 容器里，对外要用到一整段端口。官方客户端的 "端口检查"看的就是 31400-31409 这一段。
内部服务与推荐映射（这张表值得存下来）：
| 宿主端口 | 容器端口 | 服务 | 说明 | |---|---|---|---| | 31401 | 8000 | Horizon HTTP | 区块数据查询接口 | | 31402 | 31402 | stellar-core peer | 节点间通信（P2P） | | 31403 | 1570 | webfsd 本地历史服务 | 提供历史归档文件 | | — | 5432 | PostgreSQL | 严禁公网暴露 | | — | 6060 | Horizon Admin | 仅可信网络 | | — | 11626 | stellar-core HTTP | 仅可信网络（管理命令） |
注意最后三行：5432（数据库）、6060（Horizon 管理）、11626（stellar-core 管理接口） 都不该暴露到公网。尤其 5432，把数据库端口开到公网是常见的安全事故。
而 31400-31409 这一段里，除上面列出的三个之外，其余端口是 Pi 客户端用来做 NAT / 可达性检查的 —— 它们不是"有服务在等你连"，但必须全通。因为客户端会调 sync.minepi.com/v1/portscheck 把每个端口的连通结果上报上去，少了任何一个都会记为不可达。
一个实测细节：31403 → 1570 对应的是 webfsd 本地历史服务。但我们在做缓存注入时遇到过 1570 上并无服务监听的机器（不同版本/环境有差异），这时 curl localhost:31403会连不上。而 stellar-core 的管理接口 http-command 在容器内的 11626，
宿主机通常根本没映射这个端口。所以查节点状态别指望宿主端口，直接 docker exec 进容器查。少开几个会怎样（这是最难发现的部分）
老实说：少了端口，节点往往照样能跑，区块照样在涨，界面上不会明确告诉你少了什么。
它的影响是间接的：
- 入站可达性不完整 → 其他节点连不进来的路径变少
- 参与共识的机会减少
- 表现出来就是"奖励比别人的低"，但你找不到任何红字报错
我们自己的机器上踩过这个坑：早期只映射了其中几个端口，节点能连上、区块能同步、 界面看起来一切正常，但入站可达性其实不完整。补齐全通之后才恢复正常。
所以判断标准不是"界面没报错"，而是这 10 个端口从公网能不能全都连上。
怎么自己查（最实用的一段）
先在本机确认监听：
# 看容器实际映射了哪些端口
docker ps --format '{{.Names}}\t{{.Ports}}'再从另一台公网机器（不要在本机测，本机测 localhost 没有意义）逐个探活：
IP=你的公网IP
for p in $(seq 31400 31409); do
if timeout 3 nc -zv "$IP" "$p" >/dev/null 2>&1; then
echo "$p 通"
else
echo "$p 不通 ★"
fi
done十个全通才算完整。 有不通过的，回去检查防火墙、路由器端口转发、云厂商安全组 —— 这三层任何一层拦了都表现为不通。
云服务器的常见坑：安全组默认只放行 22/80/443。31400-31409 要单独加一条规则， 而且有些云厂商的安全组规则限制单条端口的数量，要分段加。
常见误解澄清
"我只用 1 个节点，是不是只要开 31401？" 不是。31401 是 Horizon HTTP（查区块数据用的），它只是这一整段里的一个。 其他端口服务的是节点通信和可达性，不是"高级功能"。
顺带说个背景：Pi 网络的整体目标是至少 1/8 的节点开放端口， 而端口开放是成为超级节点的前提之一。这意味着开放端口不只是"让你的节点更稳"， 它本身就在为整个网络做贡献 —— 也是被网络认可为合格节点的门槛。
"开这么多端口不安全吧？" 31400-31409 这段是 Pi 节点要用的，必须开。真正要注意的是别顺手把 5432、6060、11626 也开了 —— 该开的开，不该开的坚决不开。这是两件事。
"我用 FRP/内网穿透可以吗？" 可以，很多人在用。但要注意穿透工具本身的稳定性和延迟 —— 隧道抖一下， 入站可达性就断了，表现出来就是节点偶尔"失联"。
另外要清楚一点：节点身份绑定的是 NODE_SEED（存在客户端配置里），不是 IP。 所以换 IP 不会换身份。但一个公网 IP 只能让一台节点可达这条约束依然成立 —— 穿透是要给每个节点分配到独立出口，而不是把多台节点挤在同一个 IP 后面。
小结
- 入站端口是 31400-31409 共 10 个 TCP，固定不可改，少开不报错但影响奖励
- 一个公网 IP 只能让一台节点可达，这是多节点的硬约束
- 5432 / 6060 / 11626 是内部端口，不要暴露公网
- 判断标准是"10 个从公网全通"，不是"界面没报错"
- 排查顺序：容器映射 → 主机防火墙 → 路由器转发 → 云安全组
---