Nebula 证书重新加载后 IP 没变：原因在这里

你签发了使用不同 overlay 地址的新主机证书，把它覆盖到旧文件上，发送重新加载，主机却仍然在原来的地址上应答。第一反应往往是认为重新加载失败，或者读到了错误的文件。通常两者都不是：运行中的进程有意保留了它已经持有的身份，因为这次替换改动了重新加载无法应用的内容。

Nebula 的 PKI 重新加载支持正是以这一边界为前提写入文档的，而当同一份文档显示重新加载对其他改动有效时，这一点很容易被忽略。

重新加载究竟重读什么

主机证书并不像 SSH 密钥那样只是一份凭据。它承载 overlay 地址、主机名、所属群组和有效期，而这一切都由 CA 的签名绑定在一起。守护进程用这份已签名内容来决定自己如何呈现、适用哪些规则。

重新加载让进程在不丢弃隧道的情况下取得续期后的凭据，这对于例行轮换很有价值：地址不变、名称不变、群组不变，只是到期更晚。限制在于身份必须保持不变。一旦改动 overlay 地址，重新加载路径就无法应用它，因为该地址是运行实例已经承诺的内容的一部分。

所以你看到的行为是文档写明的限制在正常工作，而不是无声的失败。磁盘上的文件是新的，内存里的身份是旧的，不重启的话进程没有受支持的办法来调和这个差异。

把证书看成一条记录、而不是一组可以分别编辑的字段，会更容易理解。更换地址不像修改某个偏好设置，因为地址会出现在其他主机的对端配置、服务绑定以及针对该身份编写的策略中。

Field	What changes when you replace it
Overlay address	Peers that pinned the old address, service bindings, and any rule written against it
Host name	Name-based policy and the identities other hosts expect to see
Groups	Which access rules match, even if the address stays identical
Validity window	Nothing structural, which is why renewal reloads cleanly

群组值得单独一行，因为它们会造成同一类混淆中更安静的那种。保留地址但更换群组的主机在重启后可能访问不同的服务，而只 ping 旧地址的测试会显得完全健康，底下的访问决策却已经变了。要检查一个受规则约束的服务，而不只是可达性。这正是确认隧道与确认策略之间的区别。

在认定守护进程忽略了文件之前，把两者都读一遍。打印你打算加载的证书，确认你以为改动过的字段，然后确认运行中的配置指向该路径，而不是别处的副本。

nebula-cert print -path /etc/nebula/host.crt
systemctl status nebula
ps -o args= -p $(pgrep -f 'nebula -config' | head -1)

进程参数比人们想象中更重要。传入 -config /etc/nebula/config.yml 的 unit 读取的是该文件的 pki.cert 条目，而装在暂存目录里的证书什么都不会影响。要检查运行中命令行的路径，而不是你照着做的文档里的路径。如果两者不一致，你根本没碰证书就找到了问题。

如果新证书的地址不同而进程保留了旧地址，你现在得到的是解释而不是谜团。如果可以接受就重启，并把地址变更当作计划内的网络变更，而不是意外。

像规划迁移一台机器那样规划它。其他主机可能在自己的配置里固定了旧地址，服务可能显式绑定到它，防火墙规则也可能是针对它写的。更换证书会移动主机，而移动主机就会让别处的假设失效。

操作时保留第二条管理通路，因为你正在中断的可能正是 overlay 连接。在即将切断的隧道上用这条隧道操作，是把五分钟的改动变成现场出差的经典做法。

能否重启取决于主机在做什么，这是排期问题而不是技术问题。不可省略的是承认需要重启，而不是第五次发送重新加载。

只在一台机器上安装替换证书，会让每个对端仍然信任它已经知道的那份凭据。如果变更原因是遭到入侵，就必须通过信任或黑名单流程注销旧身份，对端才会真正拒绝它。

这是带有自身验证的独立步骤：从另一台主机确认旧身份不再有效，而不是假定新文件已经完成任务。Nebula PKI 配置文档涵盖了可重新加载的设置以及这里描述的地址限制，在轮换任何面向生产的东西之前值得完整读一遍。