副本集成员的host字段必须填公网可路由地址或DNS可解析域名，不能填内网IP或localhost；否则其他节点无法连接，导致rs.status()卡在STARTUP2或变为REMOVED。
副本集成员的 host 字段必须填公网可路由地址，不能填内网 IP 或 localhost
公有云混合部署（比如部分节点在 AWS，部分在阿里云）时，NAT 网关本身不参与 MongoDB 副本集通信逻辑——真正起作用的是每个 mongod 实例在 rs.initiate() 里声明的 host 值。如果这里写了内网地址（如 "10.0.1.5:27017"），其他云厂商的节点根本无法反向连接，rs.status() 会卡在 STARTUP2 或直接变成 REMOVED。
正确做法是：所有节点统一使用公网 IP 或可解析域名，且该地址必须能被其他所有节点 telnet 通。例如：
-
"mongodb-prod-a.example.com:27017"（推荐，DNS 解析需全集群一致） -
"203.205.12.34:27027"（若用非标端口，必须同步改 NAT 映射和mongod监听）
切忌混用：一个写域名、一个写 IP；或一个写 NAT 后的公网 IP、另一个写容器内网 IP。
NAT 网关映射端口必须与 mongod --port 和 rs.initiate() 中的端口严格一致
常见错误是 NAT 映射了 27027 → 27017，但 rs.initiate() 里仍写 "node1:27017"。此时其他节点尝试连 27017，实际走的是 NAT 映射后的端口，而目标机器监听的却是 27017（未映射），导致连接超时。
必须三处对齐：
- NAT 网关入方向规则：开放并映射到目标实例的
27027（举例） -
mongod启动参数或配置文件中指定--port 27027（或port: 27027） -
rs.initiate()的members数组中每个host字段末尾端口也必须是:27027
否则副本集心跳失败，rs.status().members[n].health 会长期为 0。
安全组 + NAT 映射组合下，bindIp 必须显式包含公网网卡 IP，不能只靠 0.0.0.0
很多用户设了 bindIp: 0.0.0.0 并开了安全组，却仍连不上——问题常出在云平台的网络栈：NAT 网关转发流量后，源 IP 已变为网关地址，而某些云厂商（如早期阿里云）的 ENI 模式下，0.0.0.0 可能不绑定到公网网卡，导致连接被内核丢弃。
稳妥写法是明确列出：
-
bindIp: 203.205.12.34,127.0.0.1（其中203.205.12.34是该实例绑定的公网弹性 IP） - 同时确保安全组入方向放行该端口，源地址限制为其他副本集节点的公网 IP 段（不是
0.0.0.0/0）
验证方式：从另一节点执行 mongo --host 203.205.12.34:27027 --eval "db.runCommand({ping:1})"，返回 {"ok":1} 才算通。
Docker 容器内服务暴露需额外处理端口映射与 host 解析
若用 Docker 部署（如 docker run -p 37017:27017），注意 host 字段填的是宿主机地址+映射端口（如 "www.it307.top:37017"），而非容器内地址 "127.0.0.1:27017"。容器内进程看到的 localhost 对其他节点完全不可见。
容易被忽略的点：
- 容器启动时未加
--network host，则默认 bridge 网络下，mongod绑定的仍是容器内网卡，必须依赖-p映射生效 - 若用
docker-compose，ports字段定义的是宿主机端口 → 容器端口，host字段仍要指向宿主机地址+宿主机端口 - 跨云部署时，DNS 域名解析结果必须全集群一致；某节点
/etc/hosts写了127.0.0.1 mongodb-prod-a就会直接把自己绕进去
最麻烦的不是连不通，而是连得上却同步失败——因为 oplog 复制走的是 host 字段地址，这个地址一旦解析错或路由错，数据就停在 SECONDARY 状态不动了。
