Linux ARP 邻居表满怎么查：ip neigh、gc_thresh 与局域网断连恢复

服务器明明还在线，局域网内的新连接却突然超时，重启网络后又能短暂恢复正常，遇到这类故障，可以优先排查ARP邻居缓存的问题。Linux 需要把 IPv4 地址解析成 MAC 地址并保存在 ARP 邻居表里；条目堆积过多、回收不及时或预设阈值过小，都可能导致新的邻居条目无法正常建立。

先确认：断连是否真的发生在 ARP 邻居层

先把故障时间、接口和目标网段记下来。假设业务接口是 ens192，不要只看网卡是否 UP；链路正常并不代表每个下一跳的二层解析都成功。

ip -br link show ens192
ip route get 192.168.10.25
ip -s neigh show dev ens192

重点看邻居状态：REACHABLE 表示近期确认可达，STALE 只是暂时没有新确认，不等于故障；大量 FAILED、INCOMPLETE，或者失败条目持续增长，才值得继续追查。这里先别急着清空缓存，先保存一次现场。

把条目数量和回收阈值对上

不同发行版和内核版本暴露的 sysctl 配置项可能不完全一致。先列出当前主机实际存在的邻居配置，再读取对应数值；不要直接照搬网上其他版本系统的配置路径套用到生产环境机器上。

sysctl -a 2>/dev/null | grep 'net.ipv4.neigh.*gc_thresh'
cat /proc/net/arp
ip neigh show dev ens192 | awk 'END {print NR}'

通常我们可以把三个ARP邻居相关阈值理解为低水位、开始主动回收的临界水位和允许的最大上限。这三个参数并非越大越好：如果机器承载了大量生命周期很短的局域网地址，盲目调大上限只会把内存压力和异常流量问题掩盖起来。先记录下当前的配置数值，再结合自身网段规模、邻居条目增长速度和内存剩余余量做针对性调整。

临时恢复与持久调整要分开做

如果现场确认是大量失效ARP条目导致故障，先针对出问题的网络接口做小范围清理，之后立刻验证一条真实业务路径是否正常：

ip neigh flush dev ens192 nud failed
ip neigh flush dev ens192 nud incomplete
ip neigh get 192.168.10.25 dev ens192

清理命令只会处理指定状态和对应接口下的条目，执行前还是要先确认本机 iproute2 版本对参数的支持情况。操作后如果新的邻居解析很快恢复，只能说明缓存异常和当前故障症状相关，还不能证明根因已经彻底消除。接着需要排查是否有端口扫描器、动态容器网络或是短租约地址在快速生成新的ARP邻居条目。

需要调高阈值时，先保存旧值，修改一个接口或一个节点做灰度，观察 ip -s neigh、内存和业务连接失败率。持久化配置应放入发行版认可的 sysctl 配置目录，重载后再次读取实际生效值；不要只看配置文件内容。

回滚、告警与复盘怎么安排

如果阈值调整后出现内存占用异常、邻居条目回收变慢或是故障范围扩大，立刻恢复之前的旧配置值并重新加载sysctl配置。回滚后的验收至少要覆盖这几个点：业务网关可达、新接入的局域网地址可以正常完成ARP解析、失败状态的条目不再持续增长、配置重载后的数值和预期完全一致。

告警不要只设“邻居数超过固定数字”。更有用的是记录邻居总数、FAILED/INCOMPLETE 比例、增长斜率和业务连接错误；不同网卡、网段和容器节点应有自己的基线。

常见问题

大量 STALE 条目是不是异常？

不一定。STALE 状态表示这条条目近期没有被确认过，并不等同于解析失败；要结合新连接是否超时和后续条目状态的变化综合判断。

清空邻居表后马上恢复，能说明交换机没问题吗？

不能直接下结论。临时清理ARP条目只能说明旧的缓存状态参与了故障发生过程，后续仍需要检查 ARP 报文交互、VLAN 配置、网关连通性和地址快速增长的根因。

gc_thresh 值可以直接翻倍吗？

不建议直接照搬参数改大。先确认当前系统实际存在的 sysctl 配置项、内存剩余余量和邻居条目快速增长的原因，再小步调整配置并且提前准备好回滚方案。

最后的检查清单

完整的处理流程是：先保存故障现场，区分不同状态的邻居条目，读取本机当前的阈值配置，统计条目增长来源，做限定范围的临时恢复，小幅度调整持久配置，最后用新连通测试和实际业务指标做验收。只看到“重启网络后故障临时消失”还不算问题闭环，下一次出现地址 churn 流量高峰的时候故障依然可能复发。