VMware CentOS桥接模式DHCP获取不到IP排障
虚拟机装完CentOS，桥接模式一开，满心欢喜等着DHCP自动分地址，结果ifconfig一看，只有孤零零的lo网卡，IPv4那一栏空空如也。这种场景不少见，尤其在公司网络或家里光猫+路由混搭的环境，排障思路不对，能折腾一整天。下面把踩坑路线一次性写清，照着做，十分钟内基本能让网卡拿到地址。
先确认宿主机网络是否健康
桥接的本质是把虚拟机网卡直接扔进物理局域网，宿主机自己都拿不到地址，虚拟机更没戏。Windows宿主机先跑ipconfig，看以太网口或Wi-Fi是否已有合法IPv4；Mac就去看系统设置里的TCP/IP。如果宿主机地址是169.254.x.x，说明物理网络DHCP服务器已经罢工，先修路由或主交换机，再谈虚拟机。
VMware虚拟网络编辑器里把桥接网卡选对
很多人装完VMware一路下一步，默认桥到“自动”，结果笔记本有有线、无线、VPN虚拟网卡，软件随机挑一个，挑到离线网卡自然拿不到地址。打开VMware菜单“编辑→虚拟网络编辑器”，选中VMnet0，把“自动”改成当前正上网的那块物理网卡，比如“Realtek PCIe GbE”或“Intel Wi-Fi 6”。改完点应用，虚拟机重启，立竿见影。
CentOS里看网卡名，别瞎写ifcfg-eth0
CentOS 7之后网卡名变成ens33、ens160一类，安装完系统/etc/sysconfig/network-scripts/里只有ifcfg-ens33，有人习惯cp一份ifcfg-eth0，结果NetworkManager根本不理。正确姿势：ip addr先列出真实网卡名，再vi /etc/sysconfig/network-scripts/ifcfg-ens33，确保内容如下：
BOOTPROTO=dhcp
ONBOOT=yes
TYPE=Ethernet
DEVICE=ens33
NM_CONTROLLED=yes
保存后systemctl restart NetworkManager，dhclient -v ens33，看输出里是否出现DHCPACK。
关闭NetworkManager托管，换回network.service老服务
部分老旧内网认证系统只认传统network脚本，NM一插手就发不出DHCP discover。干脆卸载NM：
yum remove -y NetworkManager
systemctl enable network
systemctl start network
再跑一次service network restart，ifconfig查看，地址通常就蹦出来。
排查MAC地址冲突
复制虚拟机时选择“我已移动”会保留原MAC，局域网里两台同MAC，后启动的被交换机直接无视。VMware设置里生成新MAC，CentOS里/etc/sysconfig/network-scripts/ifcfg-ens33也删掉HWADDR那一行，重启网络，DHCP立即响应。
检查宿主机防火墙与第三方安全软件
Windows Defender或某数字卫士的“局域网防护”偶尔会拦截虚拟网卡发出的BOOTP包，表现为宿主机正常，虚拟机收不到offer。临时关闭防火墙公共网络保护，再抓包看是否有DHCP Offer，确认后把VMware相关进程加入白名单即可。
交换机端口绑定与静态IP占用
公司网管把IP-MAC绑定写死在接入交换机，新MAC直接丢弃。联系网管在后台添加新MAC，或改用NAT模式先凑合。家里光猫如果开了“静态DHCP”，把虚拟机MAC填进去，重启光猫，地址也能秒到。
最后大招：手动指定同网段地址做反向验证
实在拿不到地址，先临时写一个同网段静态IP，比如宿主机在192.168.1.33/24，网关192.168.1.1，虚拟机写192.168.1.200，能ping通网关说明桥接链路没问题，问题铁定在DHCP服务器端，把证据甩给网管，省得来回扯皮。
走完上面八步，九成九的桥接DHCP故障都能解决。剩下那一成，多半是上游网络做了802.1X认证或DHCP snooping限速，抓包看到大量Discover无响应，就把虚拟机切NAT，或者让网管给交换机端口放通，别自己硬扛。
