Minion ID 固定为 localhost.localdomain 是连接失败的常见起点，因 minion_id 文件优先被读取且 getfqdn() 解析异常；Master 拒绝公钥源于旧密钥残留导致认证冲突；防火墙或 SELinux 可能拦截 4505/4506 端口；多 Master 下 cluster_isolated_filesystem 配置不当会引发 Invalid master key 错误。
Minion 启动后 ID 固定为 localhost.localdomain
这是最常见却最容易被忽略的连接失败起点。Minion 启动时会优先读取 /etc/salt/minion_id 文件，若该文件存在且内容是 localhost.localdomain，它就直接用这个 ID 初始化连接，根本不会尝试解析真实主机名。
问题在于：getfqdn() 在 DNS 或 /etc/hosts 配置不当时，确实会退化返回 localhost.localdomain；而一旦这个值被写入 minion_id，后续所有重启都会复用它——导致 Master 端看到的永远是同一个非法 ID，甚至出现重复 key 冲突或拒绝认证。
- 先确认当前 minion ID 来源：
sudo salt-minion -l debug 2>&1 | grep "Setting up the Salt Minion" - 如果输出中 ID 是
localhost.localdomain，立即执行：sudo rm /etc/salt/minion_id - 确保
/etc/hosts中有形如127.0.0.1 your-real-hostname的映射（不能只写127.0.0.1 localhost） - 重启前可手动测试：
python3 -c "import socket; print(socket.getfqdn())"，结果必须是你期望的合法短主机名
Master 拒绝公钥：The Salt Master has rejected this minion's public key!
这个错误不是网络不通，而是认证流程卡在第二步：Minion 发送了签名请求，Master 查到已有同名 key 但指纹不匹配，于是主动拒绝。典型诱因是 minion ID 被复用、或同一台机器重装后未清理旧密钥。
关键点在于：Master 不会自动覆盖旧 key，它只做严格比对。即使你改了配置、删了 minion_id，只要 Minion 还带着旧的 /etc/salt/pki/minion/minion.pem 和 minion.pub，Master 就会认为“这是个冒名顶替者”。
- 在 Minion 端彻底清理：
sudo rm -f /etc/salt/pki/minion/minion.* - 在 Master 端同步清理：
sudo salt-key -d <minion-id>（ID 必须和 Minion 当前实际使用的完全一致） - 不要依赖
auto_accept: True—— 它只对首次握手生效；若已存在冲突 key，auto_accept 不起作用 - 验证是否干净：
sudo salt-key -L | grep <minion-id>应无输出
防火墙或 SELinux 拦截 4505/4506 端口
Minion 与 Master 通信依赖两个固定端口：4505（publish，Master→Minion 广播）和 4506（return，Minion→Master 回传）。只要其中任一端口被阻断，salt '*' test.ping 就会报 Request timed out，但日志里往往只显示“no response”，不提端口问题。
SELinux 更隐蔽：它可能允许连接建立，但在数据传输阶段静默丢弃 zeromq 消息包，现象就是 minion 能连上 master，但命令始终不返回、状态卡在 pending。
- 快速验证防火墙：
sudo iptables -L INPUT -n | grep -E '4505|4506'，缺失则补：sudo iptables -A INPUT -p tcp --dport 4505 -j ACCEPT等 - 临时关闭 SELinux 排查：
sudo setenforce 0，若此时连接恢复，说明需加载 salt 相关策略：sudo semanage port -a -t salt_port_t -p tcp 4505 - 检查 Master 端监听：
sudo ss -tlnp | grep -E ':4505|:4506'，确认 salt-master 进程确实在监听
多 Master 场景下 cluster_isolated_filesystem 导致 Invalid master key
当 Minion 通过 HAProxy 连接多 Master 集群，且 Master 启用了 cluster_isolated_filesystem: True，就会触发一个极难复现的缓存不一致问题：不同 Master 实例各自维护一份 cluster.pub 缓存，Minion 第一次从 A 获取 key，第二次被轮询到 B，B 返回的 key 签名不一致，直接报 Invalid master key。
这不是配置错误，而是 Salt 3008+ 版本中 mmap_key 缓存驱动在隔离模式下的固有缺陷。修复已在 changelog/70090.fixed.md 中合入，但旧版本仍广泛存在。
- 紧急规避：在所有 Master 上统一设置
keys.cache_driver: disk（而非默认的mmap_key） - 确认集群模式配置正确：
cluster_pool_port必须显式设置且各节点一致（cluster_port已弃用，设了也无效） - 升级 Salt 到 3009.1+ 后，仍需检查
salt --versions-report输出中的cluster_pool_port是否真正生效
minion_id 错误导致反复重连，触发 FD 泄漏（见 changelog/69991），再叠加 SELinux 限制，最终表现为“部分 minion 偶发失联”。排查时务必按顺序验证，跳过任意一环都可能白忙半天。 
