服务器反复拿到169.254.x.x，基本可以判定是它压根没联系上DHCP服务器，触发了系统自带的自动私有地址分配；而“自动获取IP冲突”的根源，多数情况是静态地址和DHCP地址池没做隔离，前者改网络配置，后者改地址规划，方向对了，半小时能收工。
服务器老是自动获取169.254地址？先搞清楚它为什么“抢不到IP”
微软官方文档对APIPA（自动专用IP寻址）的定义很明确：当DHCP客户端在超时时间内没有收到DHCP服务器的回应，Windows会自动从169.254.0.0/16网段挑一个地址给自己用，这个地址只能同网段通信，出不了网关，等于半瘫，所以看到169.254，别急着换网卡，先顺着链路找“DHCP为什么没应答”。
三个最常见的断点
- 接入层没放行：交换机端口没划进正确的VLAN，或者端口上开了DHCP Snooping但没把上联口设为信任口，DHCP Offer直接被丢掉。
- DHCP中继缺失：服务器和DHCP服务器不在同一广播域，三层网关没配helper-address，请求包出不了本网段。
- 防火墙与虚拟化层拦截：宿主机防火墙、云安全组、虚拟交换机把UDP 67/68端口挡住了，包发出去石沉大海。
快速验证的两条命令
在Windows上先看清现状：
ipconfig /all
重点看“DHCP已启用”是不是“是”、租约获取时间是不是空的，然后手动触发一次：
ipconfig /release ipconfig /renew
如果十几秒后还是169.254，说明请求确实没被应答，问题在网络上，不在系统里，Linux侧对应的是：
sudo dhclient -r eth0 && sudo dhclient -v eth0
-v参数会打印完整的四次握手过程，卡在哪一步一目了然。
租期过半才是高发期
DHCP租约有T1、T2两个时间点：租期过半时客户端单播续租，到87.5%时广播重绑定，这两个时刻如果DHCP服务器刚好重启、链路刚好抖动，续租失败，地址就掉了，昨天还好好的，今天突然变169.254”这种描述很常见，往往不是配置改坏了，而是续租那一刻网络不通。
服务器静态IP和DHCP自动获取怎么选？按场景对号入座
很多人的纠结点在这里：服务器到底该手动配固定IP，还是让DHCP分配？行业共识认为，承载业务的生产服务器优先用静态地址或DHCP保留绑定，纯测试环境才适合动态分配。
| 方式 | 适用场景 | 优点 | 风险 |
|---|---|---|---|
| 手工静态IP | 数据库、域控、网关、监控主机 | 地址稳定，重启不变 | 容易与他人冲突，靠人记 |
| DHCP保留（MAC绑定） | 批量服务器、云主机、办公终端 | 集中管理，换机好维护 | 依赖DHCP服务可用性 |
| 纯动态DHCP | 测试机、临时设备 | 零配置 | 地址漂移，服务不可预期 |
固定IP配错了会怎样
手工填静态地址,最容易踩的坑是“随手填了个没人用的”，这个“没人用”往往只是当下没人用，DHCP池里早就把它划给别人了，等那台机器重启续租，冲突就来了，正确做法是：静态地址必须落在DHCP地址池的排除范围之外，或者在DHCP里做保留绑定。
Windows下用命令行配置静态地址,比图形界面更不容易点错：
netsh interface ipv4 set address name="以太网" source=static address=192.168.10.20 mask=255.255.255.0 gateway=192.168.10.1 netsh interface ipv4 set dnsservers name="以太网" static 223.5.5.5 primary
Linux用NetworkManager的话：
nmcli con mod "ens33" ipv4.method manual ipv4.addresses 192.168.10.20/24 ipv4.gateway 192.168.10.1 ipv4.dns 223.5.5.5 nmcli con up "ens33"
固定公网IP要不要额外花钱？价格与成本的大致账
这也是被问得很多的一类问题,云厂商的弹性公网IP通常按带宽或流量单独计费，绑定在运行的实例上才免费的情况也有，闲置不绑往往还会收保留费，整体是每月几十元到百元级的量级，IDC托管场景下，额外申请一段公网地址一般按年报价，具体看机房资源和地址段紧张程度，IPv4地址资源长期紧张是公开事实，据工信部公开的互联网基础资源相关统计，国内IPv4地址分配早已进入存量博弈阶段，多要几个公网IP”这件事，预算和审批都得提前想好，内网私有地址不受这个限制，规划好10.x、172.16.x、192.168.x三段，够用很多年。
局域网服务器IP地址冲突怎么排查？从现象到定位的完整路径
冲突的典型症状很统一：网络时通时断、远程连接随机掉线、日志里冒出“检测到IP地址冲突”的提示，严重时两台机器都上不了网，排查顺序建议从本机往外走。
第一步：确认冲突是否真实存在
Windows下看ARP表,同一个IP对应两个MAC，基本就实锤了：
arp -a
Linux用arping做地址探测,发ARP请求看有没有别人应答：
arping -D -I eth0 192.168.10.20
-D是重复地址检测模式，有回应就说明这个地址已经被占用。
第二步：定位另一台设备
在交换机上查ARP表和MAC地址表,是最快的路径，华为设备用display arp和display mac-address，思科系用show arp和show mac address-table，拿到MAC之后顺着端口找到物理位置，云环境里则去控制台看是否有实例手工绑了同一个内网IP。
第三步：判断冲突类型
- 静态撞静态：两个人各自填了同一个地址，好查，改一个就行。
- 静态撞DHCP池：手工地址落在池内，DHCP又把它分出去了，这类最隐蔽，必须靠排除范围解决。
- 双DHCP服务器：网络里多了一台路由器或旁路设备也开着DHCP，两台各发各的，抓包看到两次Offer就该警觉。
- 虚拟机克隆遗留：模板机克隆后没重新生成MAC或没清空网络配置，批量冲突。
第四步：处理与验证
找到冲突方后,先在DHCP服务器上把冲突地址从池里排除，再给设备重新分配地址，Windows清一下ARP缓存：
arp -d
交换机侧开启DHCP Snooping，并把连接合法DHCP服务器的上联口设为信任口，能挡掉大部分私接DHCP引发的问题，业内专家指出，接入层安全策略缺位是内网地址混乱的主要诱因之一，配置成本不高，收益却很直接。
把问题掐死在规划阶段：四条长期有效的习惯
与其每次冲突了再救火,不如把规则前置。
- 地址池分段：把网段切成动态池、静态保留区、设备管理区三块，物理隔离，永不交叉。
- 能绑定就不手填：服务器统一在DHCP里按MAC做保留，地址由系统下发，换机时改一条记录即可。
- 建一张IP台账：谁用了哪个地址、做什么用、什么时候到期，用表格或轻量IPAM工具记着，比脑子靠谱。
- 开日志和告警：DHCP服务器的分配日志、交换机的地址冲突告警都打开，问题出现时才有据可查。
收个尾
服务器拿到169.254，本质是DHCP链路断了；IP地址冲突，本质是地址规划没做隔离，前者查VLAN、中继和端口放行，后者查地址池排除和绑定策略，把这两条线理顺，绝大多数“自动获取乱套”的问题都不会再复发。
关于服务器自动获取IP与IP冲突的常见问答
问：服务器设置了静态IP，重启后却变回自动获取，是什么原因？
答：先看是不是被组策略或云平台的初始化脚本覆盖了，Windows上检查gpedit.msc里的网络配置策略，云主机则确认控制台是否开启了“启动时重置网络”，另一个常见原因是网卡驱动或虚拟网卡在重启时重载配置，把静态项冲掉了，可以用ipconfig /all核对DHCP是否被重新启用，再用netsh命令重设一次并重启验证。
问：同一个局域网里能不能同时存在DHCP自动分配和手工静态IP？
答：可以，但必须做隔离，手工静态地址要避开DHCP地址池，或者干脆在DHCP服务器上为这些设备做保留绑定，只要静态地址不落在动态池范围内，两者共存完全没问题，这也是多数企业的实际做法。
问：交换机上开了DHCP Snooping之后，服务器反而拿不到地址了，怎么处理？
答：这是信任口没配对，DHCP Snooping默认把所有端口设为非信任，非信任口只放行DHCP请求、丢弃DHCP应答，连接DHCP服务器或DHCP中继的上联口必须手动设为信任口，配置命令在华为设备上是dhcp snooping trusted，思科系是ip dhcp snooping trust，配在对应接口视图下即可恢复。