能上微信、打不开网页，或者右下角网络图标带感叹号、ipconfig一看拿到的是169.254开头的地址，这两种现象看着像一回事，实际是两层问题：一个是没拿到IP，一个是拿到了IP但域名解析不出去。先分清楚，不然会围着DNS服务器折腾半天，最后发现是DHCP就没发地址。
一条命令就能分出来：
ipconfig /all
看三处。DHCP Enabled是「是」但IPv4地址是169.254段的，说明DHCP那一趟没走通，系统给自己发了个APIPA地址，这个地址段是169.254.0.0/16，定义在RFC 3927里，只能和同样拿到APIPA的机器通信，出不了网。IPv4地址正常、DNS Servers一栏空着或者指向一个不通的地址，那就是DNS层的事。再往下走两步可以确认：ping网关通、ping外网IP通、ping域名不通，问题锁在解析上；ping外网IP都不通，先去查路由和出口。
DNS侧：nslookup的四句话
nslookup www.example.com
返回的内容分四种，对应的原因完全不同：
*** [192.168.1.1] can't find www.example.com: Non-existent domain，说明DNS服务器是通的、也回答了，只是这条记录不存在。域名拼错、内部域名没加后缀、或者权威服务器上真没这条A记录，都会走到这。
*** [192.168.1.1] can't find www.example.com: Server failed，服务器收到了查询但自己没搞定，通常是它上面的转发器挂了、或者它自己上不去网。换一个公共DNS直接问一次就能验证：
nslookup www.example.com 223.5.5.5
*** Request to 192.168.1.1 timed-out，服务器压根没回应。防火墙挡了UDP 53、路由器上的DNS代理挂了、或者网卡上配的DNS地址本身就错，是这个表现。
Default Server: UnKnown这一行很多人当成故障，其实只是那台DNS服务器没有反向PTR记录，不是问题，别在这上面浪费时间。
DNS客户端事件日志默认是关的
事件查看器里 应用程序和服务日志 → Microsoft → Windows → DNS Client Events，这个Operational日志默认不启用，右键启用之后才能看到解析失败的明细。里面最有用的是1014：名称解析超时，所有配的DNS服务器都没响应；1000是当前没有任何IPv4 DNS服务器配置；1019是IPv6那侧没有。1013、1015也是超时类。每条记录里带着查询的域名和客户端PID，能直接定位是哪个进程在反复查一个不存在的名字。
之前碰到过一台机器上1014刷得飞快，查下来是网卡上第一DNS填了一个早就不存在的内网地址，客户端按顺序问下去，前面的都超时，等到问第三个才通，每个解析都要卡一两秒。把顺序调过来就好了。
PowerShell里对应的几个命令比nslookup好使，尤其是 -DnsOnly，能绕开本机缓存和hosts文件，直接问服务器：
Resolve-DnsName -Name www.example.com -Server 223.5.5.5 -Type A -DnsOnly
Get-DnsClientServerAddress -AddressFamily IPv4
Get-DnsClientCache | where {$_.Name -like "*example*"}
Clear-DnsClientCache
清缓存这条和ipconfig /flushdns等价。怀疑是缓存投毒或者旧记录没过期，先Clear-DnsClientCache再测一次。
三个容易忽略的坑
一是多网卡时的接口优先级。装了VPN、虚拟机网卡、或者同时插了有线和无线，系统会按InterfaceMetric挑一张去发查询，轻载时经常挑到那张连不上的。用Get-NetIPInterface看InterfaceMetric，值小的优先，要改就Set-NetIPInterface -InterfaceIndex 12 -InterfaceMetric 10。
二是hosts文件。路径是C:\Windows\System32\drivers\etc\hosts，改完不生效的话，多半是文件编码存成了UTF-8 BOM或者没换行结尾，用记事本另存为ANSI就能好。装过某些加速工具和破解补丁的机器，这个文件里可能塞了几十行，排查域名解析时它排在最前面。
三是DNS Client服务本身。服务名是Dnscache，卡住的时候Restart-Service Dnscache一下比重启机器快。有人为了"防止被劫持"把这个服务禁用，结果是系统不再缓存，每个解析都重新发一遍，网反而更慢。
顺带说个判断技巧：nslookup走UDP 53，但域名下有长记录或者开启DNSSEC时会切到TCP 53，只放行UDP的防火墙规则会让一部分域名时好时坏。
DHCP侧：看懂那几个事件ID
拿到169.254地址之后，去看 应用程序和服务日志 → Microsoft → Windows → Dhcp-Client下的Admin日志，这个默认是开的。里面几个ID直接对应到原因：
1001是「计算机未从网络（由DHCP服务器）分配地址」，也就是DISCOVER发出去了没有OFFER回来。1002是租约被拒绝，服务器回了DHCPNACK，客户端想续用原来的地址但服务器不认。1003是续订失败，地址还在但续约没成功，快到期时会看到。1000是丢失租约。1005是检测到地址已被占用，网上有别的机器用了同一个IP。1007是系统自己配了IP地址，看到的必然是APIPA。
这几个分开看，处理方向完全不一样。
1001的处理思路
先在客户端上强制走一遍，看报什么：ipconfig /release然后ipconfig /renew。如果提示「无法联系DHCP服务器」，八成是请求根本没到服务器。常见原因按顺序排：地址池耗尽、作用域没激活、跨网段的中继没配或者指错了服务器、交换机上开了DHCP Snooping而接客户端的口不是信任口、UDP 67与68被中间设备挡了。
服务器侧用几个命令就能看出池子是不是满了：
Get-DhcpServerv4ScopeStatistics | Select-Object ScopeId, AddressesFree, AddressesInUse, PercentageInUse
Get-DhcpServerv4Lease -ScopeId 192.168.10.0 | Where-Object {$_.AddressState -eq "Bad"}
BAD_ADDRESS一堆的话，说明服务器发地址前探测到有人在用它，通常是网里有设备私配了静态IP，或者有人把路由器接在了LAN口上自己也在发地址。拿ClientId到交换机上查MAC地址表能直接定位到端口。
见过一个比较典型的：会议室临时加了一台家用路由器，LAN口接着内网，它的DHCP默认开着，那一屋子的笔记本全拿到192.168.1.x，网关指向那台路由器，上不了内网。抓包一眼看出来：客户端收到了两个OFFER，抢先到的不是正经那个。
抓包这一步在客户端上做最直接，Wireshark里过滤bootp或者udp port 67 or 68，能看到DISCOVER发出去但没有OFFER回来，就没必要再去服务器侧找原因，问题在链路上。
1002与1005
1002常见于机器换了网段：笔记本在A网段拿过192.168.10.50，搬到B网段后开机直接请求续用这个地址，新网段的作用域里没这个地址，服务器回NACK。客户端会自动重新走一遍DISCOVER，所以一般几秒内自愈，日志里留一条痕迹而已。频繁出现才需要处理，把旧的租约记录删掉、或者把作用域的租约时长调短。
1005是地址冲突，网里有两台机器用了同一个IP。排查办法是在交换机上arp查这个地址对应的MAC，或者直接ping它看谁在回应。手配静态IP撞进DHCP池是最常见的成因。
网卡本身的问题
排了一圈都没问题，最后落在网卡上。节电选项里「允许计算机关闭此设备以节约电源」勾着时，休眠唤醒后网卡起不来，表现就是拿不到地址，在设备管理器里把这一项取消。驱动太旧的话，换2021年之后的稳定版，别追最新。实在不行，netsh int ip reset加netsh winsock reset走一遍，这两条执行完必须重启才生效，之前有台机器跑完没重启，白折腾。
最后兜一句：ipconfig /all里的Lease Obtained与Lease Expires两行，能看出地址是什么时候拿到的、什么时候到期。这一对时间戳配合上面的事件ID看，整条链路就清楚了。
数据截至2026年10月。文中命令在Windows 11的build 10.0.22631、10.0.26100、10.0.26200，以及Server一侧的10.0.17763、10.0.20348、10.0.26100，上都验证过；PowerShell一侧涉及的命令在5.1、7.2、7.4、7.6，里行为一致，老机器上没有Resolve-DnsName就用nslookup替代。DHCP相关cmdlet需要服务器装了DHCP服务器角色才有。