VPN 改了你 Mac 的名字吗？对比三个主机名取值

以前显示一个内容的提示符现在显示另一个，而变化的那条连接是 VPN。多数人在得出 Mac 被改名这个结论之前，手上只有这点证据，而它并不够。macOS 至少保存三个彼此独立的名字取值，各司其职，而 shell 提示符最多只显示其中一个，且很容易被误读。

把它们对比一下只需要三条命令，就能在任何人动手修改之前把问题定下来。

三个取值，三种职责

三者都是系统乐于报告的字符串，而诱惑在于把最先找到的那个当作权威。使用者因此去「修」错的那个字段，然后眼看症状继续存在。

第三行才是多数困惑的起点。未设置的 HostName 是正常状态，不是损坏，含义是系统在需要主机名时会退回到其他来源。把这份空白读成损伤，会引出一场根本不必要的修改。它同时掩盖了真正的问题：问题不是这台机器叫什么，而是在那一刻，某次查询或某个提示符用的是哪个名字。回答了这一点，空值就不再像故障了。

先读，再写

这三条命令只报告取值。它们不改动任何东西，所以在排查期间执行是安全的。

scutil --get ComputerName
scutil --get LocalHostName
scutil --get HostName

在允许的 VPN 连接前后，于同一个本地会话中执行它们，并记下究竟哪一个取值不同。如果没有任何差别，而提示符看起来仍然不对，那名字从来就不是问题：是 shell 配置或远程会话里的某处在显示另一个字符串。

Apple 关于电脑名称与本地主机名的指南把友好名称放在 General 与 About 之下，把本地名称放在 General 与 Sharing 之下。它还记录了当同一链路上另一台 Mac 已在使用某个名称时会自动添加的后缀，在把一个意外的数字当成篡改证据之前，这一点值得知道。

shell 提示符究竟能证明什么

提示符是 shell 拼出来的字符串，其中主机名那一段可能来自展开后的主机名、它的缩写形式，也可能来自配置文件里写死的值。它还可能属于另一台完全不同机器上的 SSH 会话，这是最不体面的解释，却也是「一连上 VPN 提示符就变了」最常见的解释。

先确认自己在哪儿，再去确认自己叫什么。运行 hostname，把它与三个已保存的取值比对，然后看 shell 的提示符设置里到底有没有显示主机。如果提示符里是某个人多年前敲进配置文件的字面字符串，那么任何系统改动都永远无法让它对上。

这项对比对写报告同样重要。看起来不一样的提示符，与真的被改过的已保存 ComputerName，是两个归属不同的发现，把它们并成一句，就会把下一位工程师支到错误的地方。

VPN 在哪些环节可以合理地碰命名

VPN 改变的是哪些解析器与搜索域相关，并且在客户端被配置为接受主机名时，可以通过 DHCP 把一个主机名交给客户端。这是真实存在的机制，但它比「VPN 给我的 Mac 改了名」窄得多。解析器改变某个地址解析成哪个名字，并不会重写已保存的本地取值。

所以要把两个问题分开。是这台机器自身的身份不同，还是它用来抵达别处的名字不同？前者由三个已保存的取值回答，后者由 DNS 查询与正在使用的连接配置回答。把两者当成同一个问题，就会在遇到名称解析故障时去改身份设置。

如果确实需要永久主机名

设置取值是有意的管理动作，不是外观偏好，取值应当来自掌管这台机器命名策略的人。为了让提示符看起来眼熟而覆盖一个受管理的名称，可能破坏证书校验、监控以及其他一切用来识别主机的机制。

在确实需要改动的地方，读取值的是同一个工具，写取值的也是它；HostName 接受完全限定名，而另外两个期待本地形式。把改了什么、为什么改记下来，因为正是这类编辑会让下一个查看这台机器的人吃惊。

对多数报告来说，正确答案比问题暗示的要小：读三个取值，找出哪一个不同，只改那一个。提示符是某个东西的症状，而三条命令会告诉你是什么东西。