虚拟机配置域名信息，核心不是敲命令，而是先把网络模式、主机名、DNS转发这三层关系理清楚，NAT模式下走虚拟网卡自带的DNS服务，桥接模式下直接依赖路由器分配，改完主机名后用hostnamectl和resolv.conf做好持久化，最后用nslookup和ping验证解析链路是否通畅。
虚拟机域名配置方法：先分清主机名、域名和DNS的关系
很多人一上手就改/etc/hosts，结果重启虚拟机后域名信息全丢，问题多半出在概念混淆上，虚拟机里的“域名信息”其实分三层：主机名（hostname）、完整域名（FQDN）、DNS解析配置，主机名是给机器自己认路的，比如web-server；完整域名是给外部设备访问用的，比如web-server.internal.lan；DNS配置决定虚拟机向谁询问“这个域名对应哪个IP”。
网络模式不同，域名配置逻辑不同
虚拟机安装时选择的网络模式,直接决定了域名信息该往哪儿写。
- NAT模式：虚拟机躲在宿主机背后，IP由VMnet8虚拟网卡分配，此时域名解析依赖虚拟机自带的NAT服务，它会自动把DNS请求转发给宿主机正在使用的DNS，这种模式下，你只需要把虚拟机的DNS指向
168.x.1（虚拟网卡网关），不用手动填外部DNS地址。 - 桥接模式：虚拟机像一台独立设备直接接入局域网，由路由器分配IP，这里域名解析走的是局域网的DHCP下发配置，路由器会自动把DNS地址告诉虚拟机，无需额外设置。
- 仅主机模式：虚拟机只能和宿主机通信，没有外网解析能力，如果想在这个模式下玩域名，需要自己装
dnsmasq或手动改/etc/hosts。
用个直观的场景来描述：NAT模式下的虚拟机像住在宿舍楼里的学生，宿管员（虚拟网卡网关）知道你该找哪个老师（DNS）；桥接模式下的虚拟机像是住在独立公寓的租客，物业（路由器）直接告诉你水电燃气找谁办，配置错了层，域名信息就只会“局部生效”。
linux虚拟机修改hostname的三种方式
大多数云服务器和本地虚拟机的操作系统都是Linux,而hostname是域名信息的起点，改错地方，重启后主机名就会“还原”，配套的域名解析规则也会跟着失效。
临时修改：适合测试验证
hostname命令可以立即生效但不会写盘：
sudo hostname vm-web-test
执行后终端提示符立刻变化,hostname命令也能查到新名字，但虚拟机重启后恢复原样，只适合临时验证配置对不对。
永久修改：systemd体系下的标准操作
现在主流的Linux发行版基本都在用systemd,统一走hostnamectl：
sudo hostnamectl set-hostname vm-web-test
执行后需要确认/etc/hostname文件里的内容也变成了新名字，不同发行版对/etc/hosts的处理稍有差异，Debian系在修改主机名后通常还要手动同步/etc/hosts里对应行，否则部分服务可能报错。
云镜像和容器场景的特殊处理
不少云服务器镜像和最小化安装的系统,会通过cloud-init在开机时重置主机名，如果改了之后重启又变回去，检查一下/etc/cloud/cloud.cfg里preserve_hostname这个参数，改成true才能锁住你的配置。
虚拟机DNS配置方法：解析不了域名时的排查步骤
域名信息配完,最常见的现象是IP能通、域名不通，这就像打电话知道对方号码，但通讯录里没存名字，系统不知道该拨给谁。
排查关键点一：/etc/resolv.conf是谁在管
在systemd环境下,/etc/resolv.conf往往被软链到systemd-resolved的托管文件，手动改这个文件经常被系统静默覆盖，正确做法是修改/etc/systemd/resolved.conf，或者在网络管理器里调整DHCP选项，你可以先看文件归属：
ls -l /etc/resolv.conf
看到/run/systemd/resolve/stub-resolv.conf之类的指向，就说明它由systemd-resolved托管。
排查关键点二：虚拟网络编辑器的DNS参数
经常有人忽略虚拟机软件自身的DNS设置,以VMware为例，打开“虚拟网络编辑器”，找到VMnet8的NAT设置，里面有一个“DNS服务器”选项，这里如果填了无效地址，虚拟机的域名解析就会拿不到结果。行业共识认为，NAT模式下这里保持默认的“自动”最稳妥。
排查关键点三：用nslookup和dig切分故障段
当域名解析失败时,先用nslookup判断是“本地配置问题”还是“上游DNS问题”：
nslookup www.baidu.com
如果返回server can't find，但宿主机能正常上网，说明虚拟机的DNS指向可能有误，接着用dig查具体解析链：
dig www.baidu.com @8.8.8.8
手动指定公共DNS去解析,能通就是本地DNS配置的事，不通就得检查虚拟机的网络连通性了。
虚拟机和宿主机域名互访：两种推荐的实践方案
本地开发时,经常需要宿主机访问虚拟机里的Nginx或数据库服务，或者多个虚拟机之间通过域名互相调用接口，手动记IP地址太累，还容易因为DHCP重分配导致失效，比较成熟的方案有两类。
hosts文件静态映射
适合虚拟机数量少、IP基本固定的场景，在宿主机C:WindowsSystem32driversetchosts（Windows）或/etc/hosts（Linux/macOS）里加一行：
168.137.101 vm-web-test.internal.lan
同样,在虚拟机的/etc/hosts里加上宿主机的主机名映射，这种做法直接绕开DNS，没有额外进程，响应速度最快，但每加一台机器都要手动编辑，维护成本随数量上升。
dnsmasq做内网DNS
虚拟机数量超过5台,或者有域名通配需求时，方案二更合适。
在宿主机上装dnsmasq，把/etc/dnsmasq.conf
里的监听地址指向虚拟网卡，加一条地址记录：
address=/internal.lan/192.168.137.101
然后把虚拟机的resolv.conf指向宿主机IP，这样一个.internal.lan的域名都能自动解析到指定虚拟机，后续扩容只改宿主机一个文件。
| 对比维度 | hosts文件映射 | dnsmasq内网DNS |
|---|---|---|
| 配置复杂度 | 极低，一行一条 | 中等，需要安装和监听配置 |
| 是否支持通配 | 不支持 | 支持，address=/domain/ip语法 |
| 适用虚拟机数量 | 5台以内 | 超过5台或域名频繁变更 |
| 对宿主机的影响 | 无 | 需要常驻监听53端口 |
虚拟机域名配置常见问题与解法
虚拟机重启后主机名变回默认值怎么办
先检查/etc/cloud/cloud.cfg的preserve_hostname参数，把false改成true，云镜像和定制版系统默认忽略hostnamectl的改动，改完这个参数再执行一次sudo hostnamectl set-hostname即可。
ping域名报“Name or service not known”是DNS问题吗
大概率是/etc/resolv.conf没有配置有效的DNS服务器，或者配置了但不可达，用cat /etc/resolv.conf，确保nameserver行指向的IP能被虚拟机网关路由到，桥接模式下写168.x.1（路由器网关）通常即可，NAT模式下写虚拟网卡网关地址。
本地访问虚拟机服务时，浏览器报“ERR_NAME_NOT_RESOLVED”
把域名信息配置的实际位置分两层看：一是虚拟机内的resolv.conf，解决虚拟机主动发起解析；二是宿主机的hosts文件或局域网DNS记录，解决外部设备反向解析虚拟机的域名，浏览器报错属于后者，直接在宿主机hosts文件添加映射或搭建dnsmasq就能解决。
图片来源于AI模型，如侵权请联系管理员。作者：酷小编，如若转载，请注明出处：https://www.kufanyun.com/ask/913812.html
评论列表（3条）
读了这篇文章，我深有感触。作者对主机名的理解非常深刻，论述也很有逻辑性。内容既有理论深度，又有实践指导意义，确实是一篇值得细细品味的好文章。希望作者能继续创作更多优秀的作品！
读了这篇文章，我深有感触。作者对主机名的理解非常深刻，论述也很有逻辑性。内容既有理论深度，又有实践指导意义，确实是一篇值得细细品味的好文章。希望作者能继续创作更多优秀的作品！
这篇文章的内容非常有价值，我从中学习到了很多新的知识和观点。作者的写作风格简洁明了，却又不失深度，让人读起来很舒服。特别是主机名部分，给了我很多新的思路。感谢分享这么好的内容！