开机发现服务器连不上网,远程登录直接卡死，机房同事看了一眼说“网卡没拿到IP”。服务器自动获取IP地址失败，核心原因是DHCP交互链路断了，先重启网卡或网络服务，再查DHCP客户端日志，最后检查交换机端口和DHCP服务器状态，三步能解决绝大多数问题。
先分清是“没获取到”还是“获取了但用不了”
服务器自动获取IP的过程本质是DHCP四步握手：Discovery、Offer、Request、Ack，任何一步断掉，结果都是网卡拿不到有效的内网地址。
动手之前,先登录服务器本地控制台或通过带外管理卡看一眼当前网卡状态，Linux下执行ip addr，Windows下执行ipconfig /all，如果看到的IP是254.x.x，说明DHCP服务器根本没回应，系统自动分配了一个保留地址，如果IP是0.0.0，说明网卡协议栈都没起来，这两种情况处理方向完全不同，前者查网络链路，后者查驱动和服务。
看一眼网卡指示灯和物理链路
服务器网卡指示灯不亮或者闪烁频率异常,基本可以断定是物理层问题，网线松动、模块氧化、交换机端口被关闭，这几种情况在机房很常见，尤其是托管在IDC的机器，机柜里线缆多，运维人员操作时容易碰松。
用测线仪测一下线序,或者直接换一根成品网线，成本最低、排查最快，如果换了线还是不行，把网线插到交换机上另一个空闲端口试一下，排除端口故障的可能。
检查网卡驱动和固件状态
物理链路正常但驱动异常,同样会导致DHCP客户端无法发送广播包，Linux下用ethtool eth0查看网卡速率和协商状态，如果显示Link detected: no，但网线明明插着，基本就是驱动或固件问题。
更新网卡驱动前先确认网卡型号,lspci | grep -i ethernet可以查看硬件信息，部分老款Intel和Broadcom网卡在特定内核版本下会出现丢包严重甚至不工作的现象，升级驱动或固件能解决，Windows Server系统则在设备管理器里查看网卡属性，如果有黄色感叹号，右键更新驱动。
服务器IP地址获取失败怎么解决，从重启服务开始
排除硬件问题后,最常见的解决路径是重启DHCP客户端和网络服务，这一步操作简单，但能解决相当一部分由服务卡死引起的IP获取失败。
Linux系统重启网络服务的具体命令
不同发行版命令差别很大,别记混了，CentOS 7及以下版本用systemctl restart network，CentOS 8/Stream和Rocky Linux用nmcli networking off && nmcli networking on或systemctl restart NetworkManager，Ubuntu和Debian系用systemctl restart systemd-networkd，部分版本还需要netplan apply生效配置。
执行完重启命令后,第一时间用ip addr show确认是否拿到IP，如果还是空的，手动执行dhclient eth0强制发起DHCP请求，观察终端输出，看到DHCPDISCOVER、DHCPOFFER、DHCPREQUEST、DHCPACK完整的四步过程，就说明链路通了。
Windows Server系统释放续租IP
Windows Server在图形界面下右键网卡选择“禁用”，等待几秒后再“启用”，系统会重新发起DHCP请求。
更彻底的做法是用命令行：ipconfig /release释放当前租约，然后ipconfig /renew重新获取，执行过程中如果提示“无法联系DHCP服务器”，说明广播包没到达DHCP服务器，问题可能出在交换机端口配置上。
清除DHCP租约缓存后重试
有些时候DHCP服务器分配的租约还没到期,但服务器这边缓存了错误的租约信息，导致续租失败，Linux下删除/var/lib/dhclient/dhclient.leases文件，Windows下用ipconfig /flushdns配合netsh int ip reset重置IP协议栈，然后重启网卡。
操作完需要等待30秒到1分钟,让DHCP服务器清理旧租约记录，再尝试获取。
服务器DHCP获取IP失败原因排查，链路中间段是关键
重启服务解决不了,就要往网络中间段查了，DHCP流量走的是广播，路由器默认不转发广播包，所以DHCP服务器和客户端必须在同一个广播域内（除非配置了DHCP中继）。
交换机端口配置是否正确
接入交换机端口如果开启了Port Security，MAC地址绑定不对就会直接丢弃DHCP请求，登录交换机查看端口状态，用show port-security interface确认，如果报错就解除绑定或更新MAC地址白名单。
端口VLAN划分错误是另一个高频原因，服务器接入的端口所在VLAN如果和DHCP服务器不在同一个VLAN，且没有配置DHCP Relay，拿不到IP是必然的，用show vlan brief看端口VLAN信息，把服务器端口划到正确的VLAN里。
DHCP服务器地址池是否耗尽
地址池满了也会导致获取失败,但现象比较隐蔽，DHCP客户端一直在发Discovery，服务器收到后不回Offer，因为没地址可分了，登录DHCP服务器查看租约记录，如果租约使用率接近上限，扩大地址池范围或清理长期不用的租约。
据行业共识,机房环境里IP地址租约最佳实践是按设备类型设置不同的租约时长，静态服务器建议租约7天以上，临时测试机可以设置1小时以内，减少地址池压力。
防火墙或安全组拦截DHCP请求
云服务器和物理机都要查防火墙规则,DHCP流量用UDP 67和68端口，很多安全策略默认只放行TCP流量，UDP广播被拦了就默默丢掉，检查本地防火墙，Linux下firewall-cmd --list-all或iptables -L -n，Windows下检查高级安全Windows Defender防火墙入站规则。
云厂商的安全组也要确认,比如简米云、酷番云的VPC安全组入方向是否放行了UDP 67/68端口，有个容易忽略的坑：安全组规则里明确了源IP范围，但DHCP服务器响应是广播包，源IP可能是0.0.0.0，这种场景需要单独放行。
Linux服务器获取不到IP地址怎么办，分发行版讲透
Linux服务器占服务器市场较大比例,不同发行版的网络管理方式差异很大，排查命令也不一样，搞清楚自己用的是哪套网络管理栈，能少走很多弯路。
基于NetworkManager的发行版
CentOS 8+、Rocky Linux、Fedora、Ubuntu桌面版默认用NetworkManager，用nmcli device status查看网卡状态，如果显示disconnected，用nmcli device connect eth0重新连接，查看某个连接的详细配置用nmcli connection show，确认ipv4.method是auto而不是manual。
基于systemd-networkd的发行版
Ubuntu Server 18.04以上、Debian 10以上，如果没装NetworkManager，就是systemd-networkd管理网络，查看/etc/netplan/.yaml配置文件，确保dhcp4: true已开启，修改配置后执行netplan apply生效，如果配置格式错误，系统会直接报错提示。
虚拟机环境特殊坑点
VMware或KVM虚拟机获取不到IP,先检查虚拟交换机设置，VMware的VM Network要选择正确的端口组，KVM的虚拟网卡要选择正确的bridge，还有一个坑：克隆虚拟机后没有重新生成MAC地址，导致两台机器MAC冲突，DHCP服务器只给其中一台分配IP，在克隆设置里重新生成MAC地址，或者用virt-sysprep重置。
服务器自动获取IP和静态IP怎么选，何时该换
自动获取IP适合办公网络、测试环境、云主机（云厂商的DHCP是真正的大规模自动化方案），但物理机在IDC或企业内部核心业务场景，静态IP更稳定可控，服务器IP地址自动获取失败后改静态IP是常见做法，但需要考虑价格和场景：机房静态IP通常在带宽套餐中附带或单独计价（具体费用咨询IDC服务商），企业内网静态IP则是网络管理员规划的固定地址。
手动配置静态IP需要收集四项信息：IP地址、子网掩码、网关、DNS服务器，Linux下编辑网卡配置文件或使用nmcli命令，Windows下在网络适配器属性里直接填写，配置前确认IP没被别人占用，ping一下目标地址，有响应就换个IP，配置错了会导致IP冲突，比获取不到IP更麻烦。
改完静态IP不用重启服务器，重启网卡就生效，测试网络连通性用ping网关和公网IP各一次，能通说明配置没问题，如果只是临时应急，静态IP可以先用着，事后让网络管理员排查DHCP问题的根源，再改回自动获取。
常见问题解答
服务器显示169.254开头的IP是什么意思？
这是Windows和Linux系统在DHCP获取失败后自动生成的保留地址,范围是169.254.0.1到169.254.255.254，仅用于同一链路上的临时通信，看到这个地址，说明DHCP服务器完全不可达，检查网线连接、交换机端口和DHCP服务器是否在运行，不用在服务器配置上折腾。
DHCP获取失败后重启服务器能解决吗？
重启服务器本质上是让网卡驱动和DHCP客户端重新初始化,有些驱动异常或服务卡死的情况重启确实有效，但如果是交换机端口VLAN错配或DHCP服务器地址池耗尽，重启多少遍都没用，与其重启，不如先看日志，Linux下journalctl -u systemd-networkd或tail /var/log/messages能看到DHCP客户端的具体报错信息。
服务器要用DHCP绑定还是直接配静态IP？
基于MAC地址的DHCP静态绑定,既保留了集中管理的优势，又保证了IP固定，适合IP地址紧张或需要定期变更网络的场景，直接配静态IP更简单直接，但需要人工记录IP分配表，排查冲突比较费时，两种方式都是行业标准做法，根据团队规模和服务器数量选择服务器数量超过50台，优先DHCP静态绑定。