症状
默认网关正常，只有一个前缀不可达
典型表现是客户端可访问互联网和本地网关，却在 DHCP 续租或切换 SSID 后失去某一个办公、NAS 或实验网段的访问；另一台使用静态地址的设备仍正常。此时不要把它归结为 DNS，也不要立即删除默认路由。RFC 3442 定义的 DHCPv4 Classless Static Route Option（常称 Option 121）能下发比默认路由更具体的前缀路由。
更具体的路由通常优先于默认路由。因此，一条错误的 /24 或 /16 可以只影响一个目的网段，同时让普通互联网访问看起来一切正常。
判断层级
先按 DHCP 租约 → 客户端路由表 → 最长前缀匹配 → 下一跳 → VLAN 作用域 判断；默认路由正确不代表更具体的 Option 121 路由正确。
只读诊断命令
先选择一个明确的目的 IP，不使用实际客户地址或生产网段示例。将 <destination> 和 <expected-gateway> 替换为本次获得授权的测试对象。
# Linux / OpenWrt：确认最长前缀匹配的实际选择结果
ip route get <destination>
ip route show
# Windows PowerShell：查看 DHCP 获得的 IPv4 路由
Get-NetRoute -AddressFamily IPv4 | Sort-Object DestinationPrefix,RouteMetric
route print -4
# macOS：显示当前 IPv4 路由表
netstat -rn -f inet
route -n get <destination>结果要回答三件事：目的前缀是否存在、它来自哪个接口、下一跳是否是预期网关。若目标显示为直连路由，继续确认客户端掩码和 VLAN；若目标经由错误下一跳，才回到 DHCP 的 Option 121 下发链路。
不把 RFC 数据格式误当作设备配置
RFC 3442 定义的是 DHCP option 内部携带的“目标前缀 + router”序列，不定义 OpenWrt、dnsmasq、企业 DHCP 或云路由器的界面字段。不同服务器对输入格式、多个路由和默认路由共存的表达不同。因此本站不提供可直接粘贴到生产 DHCP 的伪通用配置。
应在对应 DHCP 服务的当前版本官方文档中核对：
- Option 121 是否启用，是否同时下发 Option 3（Router）；
- 目的前缀长度、地址和下一跳是否按预期编码；
- 该作用域是否只绑定到目标 VLAN；
- 变更前是否能导出旧作用域或保留一个静态测试终端。
可回滚修复顺序
- 只对测试 VLAN 或单个 DHCP scope 导出当前配置；记录原有 Option 121 条目。
- 删除或更正一条已证实错误的目的前缀，不同时修改 DNS、默认路由和防火墙。
- 让一台测试客户端释放并重新获取租约；不要把它当作所有终端都已刷新。
- 对目标前缀、LAN 管理地址和公网目标各做一次
route get或等价检查。 - 若结果恶化，恢复导出的 scope，再从 DHCP 服务日志和当前产品文档定位编码或作用域错误。
验证
修复后，客户端路由表中应只保留预期的特定前缀路由，且 route get 的下一跳与网络设计一致。再确认同一客户端的默认路由和本地管理网段未被覆盖。这个问题与出口专线、Wi-Fi 信号和网线故障属于不同层级；先让 DHCP 路由可解释，才讨论其他路径。
证据与边界
本页只依据 RFC 3442 说明 Option 121 的协议含义，Research Engine 已保存对应抓取哈希。具体 DHCP 产品的字段名、版本行为与界面操作必须以其当前官方文档为准。