Android eth0静态IP配置：系统签名与反射实践

做 Android 设备量产和现场部署的人，绕不开一个需求：设备必须能配置 Android 以太网 eth0 静态 IP。一台没有触摸屏的工控盒子、一台装在产线机柜里的采集终端、一台自助取号机，现场往往没有 DHCP 服务器，网段也是甲方定好的固定规划，插上网线就得拿到指定的地址，重启、拔插、断电恢复之后还得是那个地址。这类需求看起来只是"填个 IP、填个掩码、填个网关"，真做起来却会碰到一堆事：应用的权限不够、系统 API 被标成隐藏接口、配置下发之后系统根本感知不到、有地址却上不了网、跟 WiFi 抢默认路由。下面的内容就是围绕这些真实问题展开的，从数据通路讲到代码实现，从无签名环境的替代方案讲到量产前的自检清单，适合正在做设备定制、系统集成、现场交付的开发者参考，也适合刚接手这类需求、还在纠结"为什么 ifconfig 配了 IP 却不通"的同行。

1. 先把场景和约束想清楚：eth0 静态 IP 到底难在哪

1.1 三类典型场景，各自的硬约束完全不同

我做过和见过的以太网静态 IP 需求，基本能归成三类，每一类对"配置成功"的定义都不一样。

第一类是工业现场设备。产线机柜里塞一台采集盒，通过网线连到交换机和上位机，网段是甲方规划好的，比如 192.168.10.x。这类场景的硬约束是断电恢复必须自愈：工厂经常整体拉闸，来电之后设备要在几十秒内回到可通信状态，不能要求现场人员拿手机重新配一遍。同时这类现场通常没有显示器，也没有人能操作设置界面。

第二类是自助终端和数字标牌。设备装在商场、医院、营业厅，运维人员远程管理。这类设备的诉求是地址可预期：固定 IP 才能做端口映射、才能让后台轮询到它、才能在出故障时按台账找到那台机器。这里的坑往往不是"配不上"，而是"配上了但设备换个网口就变了"，或者"现场施工把网线插到了另一个口"。

第三类是车载、机器人、视觉设备。主控板和相机模组、激光雷达、上位机在同一网段直连，中间没有路由器，甚至没有交换机。这类场景的硬约束是不能有 DHCP 广播干扰，有些模组的网络协议栈对广播包处理很粗暴，一旦收到 DHCP Discover 就延迟响应，严重的时候整条链路卡顿。这种场景下静态 IP 不是"方便"，是"必须"。

把场景分清楚之后，很多技术选型就自然了：第一类和第二类必须走系统框架层，因为要持久化、要在设置界面可见、要跟系统网络管理协同；第三类在某些极端情况下可以用非框架层的野路子，但要清楚代价。这个判断很关键，我在后面第 4 章会展开讲。

1.2 一条网线插上去，Android 内部到底发生了什么

很多人配不通，是因为脑子里没有这张图。我按顺序捋一遍。

内核侧的以太网驱动把物理层拉起来，/sys/class/net/eth0/下面会生成operstate、carrier、address这些节点。网线插上、对端交换机协商成功之后，carrier变成 1，operstate变成 up。

接着系统的网络守护进程（各家实现不同，原生体系里是 netd）会收到内核的链路事件，同时以太网管理模块会周期性扫描可用网卡列表。这里有个关键配置项：系统资源里有一个正则，用来决定"哪些网卡算以太网"，原生的默认值大致匹配eth开头加数字的名字。如果你的板子把网口命名成了usb0、enx001122334455或者lan0，而正则没改，系统就压根不认为这是一块以太网卡——设置界面里看不到以太网选项，任何上层调用都拿不到这个接口。这是我在一个定制板子上卡了大半天的坑。

系统认出网卡之后，会创建一条对应的网络记录，交给连接管理服务统一管理。这个服务是整个 Android 网络体系的中枢，所有应用的 Socket 走哪条路、哪条网络是默认网络、哪条网络算不算"可用"，都由它裁决。当你下发一份静态配置，实质上是告诉这个中枢：这块网卡不用 DHCP，用我给的地址、掩码、网关、DNS，请把这份配置写进内核的路由表和地址表，并把它登记成一条正式的、可用的网络。

再往下一层，真正把配置写进内核的是网络守护进程提供的接口：设置接口地址、设置路由、设置 DNS。上层框架只是把你的意图翻译成这些底层调用。所以如果你绕过框架直接调底层命令，内核里确实有地址，但中枢不知道，应用依然上不了网——这就是第 1.3 节要说的事。

1.3 为什么ip addr add配完能 ping 通，App 却连不上

这是我被问得最多的一个问题，也是新手最容易掉进去的坑。现象是：用 root 权限执行ip addr add 192.168.10.50/24 dev eth0，再ip route add default via 192.168.10.1 dev eth0，然后ping 192.168.10.1通、ping 外网也通，看着一切正常。但自己的应用里发 HTTP 请求，直接超时。

原因在于 Android 的网络选择机制。应用发起的 Socket 会被打上一个标记，这个标记指明"这条连接属于哪条网络"。系统根据标记去查路由表，决定数据包从哪个网口出去。如果应用没有显式绑定网络，它就跟随系统认定的默认网络。而系统认定的默认网络，是连接管理服务维护的那份列表里的条目，不是你用ip命令手工加的那条地址。

换句话说，内核路由表和系统网络列表是两套账。你用ip命令只改了前者，后者还是空的，系统认为"当前没有可用网络"，应用发起的连接自然找不到出口。更糟的是，如果这时系统自己又跑了一次 DHCP 或者重新下发了配置，它会按自己的账本刷新地址表，你手工加的地址可能被直接冲掉，表现就是"配好了一会儿又没了"。

还有一种更隐蔽的情况：机器上同时有 WiFi 和以太网。系统默认把 WiFi 当默认网络，应用的所有流量都走 WiFi。你用ip命令配好了以太网，ping是内核层面直接发包所以通，但应用走的是 WiFi 那条路，而 WiFi 那头可能根本连不上你的目标网段。这个现象特别迷惑人，因为"能 ping 通"给了你错误的信心。

所以结论很硬：只要你的目标设备上有正常工作的 Android 网络框架，静态 IP 就必须通过框架层下发。绕过框架的方案只在两种情况下考虑：一是设备系统被裁剪得没有以太网管理模块，二是你只需要内核层连通性（比如做底层调试、跑一个不依赖 Android 网络栈的原生程序）。

2. 前置准备：权限、签名与设备状态自查

2.1 三条可行路径，选之前先看清代价

在 Android 上改以太网配置，能走的路就三条，没有第四条。

第一条是系统签名 + 系统权限。把你的应用用平台签名签上，在清单里申请以太网管理权限，然后直接调用系统的以太网管理接口。这条路最正、最稳，配置能持久化、能跟设置界面同步、重启不丢。代价是你必须拿到平台的签名密钥，或者让方案商帮你签。做整机定制的团队通常有这个条件，做纯应用分发的团队基本没戏。

第二条是root + 命令行/底层调用。设备已经 root，通过 shell 执行系统提供的命令行工具，或者用底层调用方式直接触发框架层的方法。这条路不需要签名，但需要在设备上保留 root，量产机器留 root 是安全红线，很多项目过不了验收。而且命令行的子命令在不同系统版本上差异很大，维护成本高。

第三条是出厂预置。在系统镜像里改配置，让设备一开机就带着静态 IP 起来。这条路对应用层完全透明，稳定性最好，缺点是改一次配置要重新烧机，不适合需要现场调整的场景。

我的建议是：能拿到签名就走第一条，量产设备不要留 root；只在研发调试阶段用第二条；第三条作为兜底，跟第一条组合使用——出厂预置一个合理的默认值，应用层再提供调整能力。

2.2 上机第一件事：把设备状态摸清楚

在写任何代码之前，先用几条命令把设备现状摸清楚，能省掉后面大量猜测。这些都是 adb shell 里能直接跑的。

# 看网卡是否存在、是否 up、MAC 是多少 ip link show # 看当前地址和掩码 ip addr show eth0 # 看链路物理状态，1 表示网线插好且对端协商成功 cat /sys/class/net/eth0/carrier cat /sys/class/net/eth0/operstate # 看路由表，注意 Android 有多张路由表，别只看 main ip route show table all # 看系统是否把 eth0 识别成以太网 dumpsys ethernet # 看连接管理服务眼里的网络列表 dumpsys connectivity

dumpsys ethernet的输出里，重点看两件事：一是可用接口列表里有没有你的网口，二是当前配置是 DHCP 还是 STATIC。如果可用接口列表是空的，说明系统的以太网识别正则没匹配上你的网口名，这时候写再多代码也没用，得先去改系统配置。

ip route show table all也值得单独说。Android 用的是策略路由，除了 main 表还有一堆编号表，每条网络对应一张表。你只看ip route（默认 main 表）会漏掉大量信息，误判成"没有默认路由"。我第一次遇到这个的时候盯着 main 表看了半小时，最后发现默认路由在另一张表里。

2.3 各版本接口差异对照，别拿一套代码硬套

以太网管理的接口在 Android 各大版本之间改过好几轮，这也是反射方案容易翻车的原因。下面这张表是我整理的常见差异，具体签名还是要以你手上的系统源码为准，各家方案商还会做裁剪。

接口形态变化带来的直接影响是：你在 9.0 上写好的反射代码，拿到 12 上会抛"找不到方法"。所以反射封装必须做成"先枚举方法名，再按参数个数和类型匹配"，而不是写死方法签名。第 3.2 节我会给出具体写法。

还有一点要提醒：getAvailableInterfaces()这类查询接口的返回值类型也变过，早期返回字符串数组，后来返回网卡对象列表。反射拿到的返回值要做类型判断，别直接强转。

3. 核心实现：系统应用下发静态配置的完整路径

3.1 关键数据结构的字段语义，一个都不能填错

下发配置的核心是构造一份"静态 IP 配置"，它包含四样东西：地址加前缀长度、网关、DNS 服务器列表、以及可选的域名字符串。这四样里，最容易出错的是地址和前缀长度的组合方式。

在很多语言里，地址和掩码是两个独立参数；在 Android 这套结构里，地址和前缀长度是绑在一起的一个对象。前缀长度就是掩码里连续 1 的个数，255.255.255.0对应 24，255.255.0.0对应 16。这个换算必须做对，写错一位，设备就是"能 ping 通网关但访问不了同网段其他机器"或者"整个网段都访问不到"。

DNS 服务器的顺序也有讲究。列表里第一个是首选，系统解析域名时先问它，超时才问第二个。现场如果配了两个 DNS 而第一个是错的，域名解析会每次卡几秒超时，用户感知就是"网页打开特别慢"。我在一个项目里遇到过这个，现场运维填了个已经不用的旧 DNS 在前面，排查了两天才定位到。

域名字符串这个字段很多人直接留空。它在纯 IP 访问的场景下确实没用，但如果设备需要访问内网域名（比如device.local这类），留空会导致解析失败。填的时候注意不要带前导点，格式是逗号分隔的域列表。

还有代理设置，构造配置对象时必须显式指定为"不使用代理"，否则在某些系统上会继承上一次的代理配置，表现就是"配置成功了但所有请求都发到一个不存在的代理端口"。

3.2 反射封装：先找方法，再匹配参数

反射方案的核心不是"调哪个方法"，而是"怎么找到那个方法"。我用的思路是：拿到以太网管理类的 Class 对象，遍历它的全部方法，按方法名筛选，再按参数个数和参数类型二次筛选，最后按优先级调用。这样同一份代码能在多个版本上跑。

private static Object invokeSetConfiguration(Object ethManager, Object ipConfig, Object netIf) throws Exception { Class<?> clazz = ethManager.getClass(); // 优先级 1：双参数形态，新版系统 for (Method m : clazz.getMethods()) { if (!"setConfiguration".equals(m.getName())) continue; Class<?>[] pts = m.getParameterTypes(); if (pts.length == 2 && netIf != null && pts[0].isInstance(netIf) && pts[1].isInstance(ipConfig)) { return m.invoke(ethManager, netIf, ipConfig); } } // 优先级 2：单参数形态，老版系统 for (Method m : clazz.getMethods()) { if (!"setConfiguration".equals(m.getName())) continue; Class<?>[] pts = m.getParameterTypes(); if (pts.length == 1 && pts[0].isInstance(ipConfig)) { return m.invoke(ethManager, ipConfig); } } throw new NoSuchMethodException("no usable setConfiguration on this rom"); }

这段代码有两个细节值得说。第一，用getMethods()而不是getDeclaredMethods()，因为目标方法可能继承自父类或者由接口声明。第二，判断参数类型用isInstance()而不是equals()，因为不同版本里参数可能是接口类型也可能是实现类型，用isInstance能兼容两种情况。

网卡对象的获取也要做兼容。新版接口需要传入网卡对象，老版只需要字符串名字。我的做法是先调查询接口拿到列表，然后遍历列表，用反射读每个元素的名字字段，匹配到eth0就停。如果列表元素是字符串，直接用；如果是对象，反射调getName()。

注意：反射调用隐藏接口在部分系统上会因为非 SDK 接口限制而被拦截，表现为抛NoSuchMethodException或者直接返回空。如果你的目标系统有这个限制策略，反射方案可能整体失效，这时候只能走系统签名直调或者出厂预置。上机验证之前，先确认这一点。

3.3 完整下发流程：从构造到生效

把上面几块拼起来，一次完整的配置下发大概是这么几步。我把代码写成一个方法，参数是字符串形式的 IP、掩码位数、网关、DNS，方便从配置文件读进来直接用。

public boolean applyStaticIp(String ip, int prefixLen, String gateway, String dns1, String dns2) { try { Class<?> emCls = Class.forName("android.net.EthernetManager"); Object em = context.getSystemService("ethernet"); if (em == null) return false; // 1. 构造 LinkAddress（地址 + 前缀长度） Class<?> laCls = Class.forName("android.net.LinkAddress"); Constructor<?> laCtor = laCls.getConstructor(InetAddress.class, int.class); Object linkAddr = laCtor.newInstance(InetAddress.getByName(ip), prefixLen); // 2. 构造 StaticIpConfiguration Class<?> sicCls = Class.forName("android.net.StaticIpConfiguration"); Object sic = sicCls.getDeclaredConstructor().newInstance(); setField(sic, "ipAddress", linkAddr); setField(sic, "gateway", InetAddress.getByName(gateway)); ArrayList<InetAddress> dns = new ArrayList<>(); dns.add(InetAddress.getByName(dns1)); if (dns2 != null && !dns2.isEmpty()) dns.add(InetAddress.getByName(dns2)); setField(sic, "dnsServers", dns); setField(sic, "domains", ""); // 3. 构造 IpConfiguration，指定为静态 Class<?> icCls = Class.forName("android.net.IpConfiguration"); Class<?> ipAssignCls = Class.forName("android.net.IpConfiguration$IpAssignment"); Class<?> proxyCls = Class.forName("android.net.IpConfiguration$ProxySettings"); Object staticEnum = Enum.valueOf((Class<Enum>) ipAssignCls, "STATIC"); Object noneEnum = Enum.valueOf((Class<Enum>) proxyCls, "NONE"); Object ipConfig = null; for (Constructor<?> c : icCls.getDeclaredConstructors()) { Class<?>[] pts = c.getParameterTypes(); if (pts.length >= 3 && pts[0] == ipAssignCls && pts[2] == sicCls) { c.setAccessible(true); ipConfig = c.newInstance(staticEnum, noneEnum, sic, null, null); break; } } if (ipConfig == null) return false; // 4. 找网卡并下发 Object netIf = findInterface(em, "eth0"); invokeSetConfiguration(em, ipConfig, netIf); return true; } catch (Exception e) { Log.e(TAG, "applyStaticIp failed", e); return false; } }

setField是个简单封装：按字段名找 Field、setAccessible(true)、赋值。找不到就跳过——因为字段在不同版本里可能存在也可能不存在（比如domains字段就没在所有版本里出现）。

这段代码里我特意保留了ipConfig构造的遍历逻辑，因为构造器参数在不同版本里排布不同。实际项目里更稳妥的做法是：先用构造器模式尝试，失败再回退到无参构造加 setter。写两套兜底，代码丑一点，但上机成功率高。

下发之后不要立刻认为成功，要验证。验证的方式是读回来：调查询接口拿当前配置，看里面的地址是不是你刚写的那份。更进一步，用连接管理服务查网络列表，确认目标网络存在并且状态是"已连接"。

3.4 掩码换算与 IP 规划的几个实操提醒

前缀长度和点分十进制掩码的换算，我列个表，现场填参数时直接查，别心算。

除了掩码，还有三个现场经验值得写下来。

第一，不要用网段的第一个和最后一个地址。这两个是网络地址和广播地址，虽然现代系统允许配置，但某些老旧的 PLC 或者工控交换机对这类地址会拒绝响应。

第二，网关地址要跟甲方确认清楚。我遇到过现场把网关规划成.254而不是.1的情况，交付人员按习惯填了.1，设备能通同网段但出不了网段，排查时先怀疑了一堆别的原因。填之前问一句，省两天时间。

第三，DNS 至少配一个能用的。纯内网场景下很多交付人员直接不填 DNS，设备调用域名接口的时候会卡在解析上，超时时间还特别长（有的系统默认 5 秒重试两次）。哪怕是内网，也配一个内网 DNS 或者用一个可达的地址，能显著改善体验。

4. 没有系统签名时，还有哪些替代路径

4.1 用系统自带的命令行工具下发配置

系统里通常带了一套调试命令，可以查询和设置以太网配置。用法在adb shell里执行帮助命令就能看到，不同版本的子命令集合不一样。

# 先看这个版本支持哪些子命令 adb shell cmd ethernet help # 常见的查询用法 adb shell cmd ethernet ipconfig

这条路的好处是不需要改应用，缺点是：一，子命令集合随版本变，写进脚本里的命令换台机器可能就不认；二，这条命令依赖系统服务，本质上还是走了框架层，所以它改的配置是"真的"，系统能感知；三，但它通常需要 shell 权限，普通应用调用不了，只能用来做现场调试和临时验证。

如果想在应用里触发同样的效果，还有一条很偏门的路：用 root 执行service call直接调用系统服务的某个事务。这条路我不推荐——事务号在不同版本、不同厂商的系统上完全不一样，属于典型的"只能在自己机器上跑"的代码，量产维护成本极高。我在早期项目里用过一次，后来系统升级全部重写，得不偿失。

4.2 root 直接改网卡：什么时候能用，什么时候必须放弃

前面第 1.3 节讲过ip addr add的问题，这里把边界说清楚。

能用的场景：设备没有真正的 Android 网络框架（比如极简系统、或者框架被完全裁剪）、你只需要内核层连通性、目标是跑一个原生的守护进程做数据采集。

不能用的场景：设备上有正常工作的框架和应用、需要通过应用发起网络请求、需要远程管理、需要重启保持。这些场景下用ip命令配置，会出现三个连锁问题：系统认为没网、应用连不上、配置被框架覆盖。更麻烦的是这三个问题会互相掩盖——系统认为没网导致应用连不上，你去查应用代码；配置被覆盖导致地址消失，你去查是不是网卡驱动有问题。方向全错。

如果你确实需要在 root 环境下用命令行把状态做对，至少要做三件事：一是同时配置地址和默认路由，二是手工写 DNS（改系统属性里的 DNS 配置或者直接改/etc/resolv.conf的等价位置），三是配置完之后用ip rule检查策略路由是不是把你这条链路排除了。这三件事做完，内核层能通，但应用层能不能通还是取决于框架。所以我的态度很明确：调试可以，量产不行。

4.3 出厂预置：把静态配置烧进系统镜像

这条路最稳，适合量产的固定配置场景。做法是在系统的资源文件里预先声明网卡标识和默认网络配置。

具体位置通常是系统框架的资源定义文件，里面有一个配置项专门管"哪些网卡算以太网"，值是一个正则表达式。把正则改成能匹配你板子上网口名的形式，比如板子上网口叫lan0，就加一条匹配lan0的规则。这个改动需要重新编译系统镜像，属于整机定制范畴。

更进一步，某些系统版本支持在资源里声明默认的静态配置，包括地址、掩码、网关、DNS。设备第一次启动、网卡第一次被检测到的时候，系统会直接应用这份配置，不需要任何应用参与。这个方案的缺点是"硬编码"：换个现场、换个网段，就得重新出镜像。

实际量产里我用的组合方案是：出厂镜像里预置一套内网专用网段的默认配置（比如 192.168.100.x），保证设备出厂第一次上电就有地址、能被生产线的工装访问；然后在应用层做一个配置界面或者配置文件读取逻辑，交付人员到现场之后按实际网段改一次，配置写进应用自己的持久化存储，开机时由应用下发。这样既保证了"开箱有地址"，又保留了"现场可改"。

这个组合方案有一个细节要注意：应用下发配置的时机。太早了系统还没把网卡初始化完，调用会失败；太晚了设备会先拿一次 DHCP 地址再被覆盖，中间会有几秒的空窗。我的做法是监听系统的网络状态广播，收到以太网可用的事件之后再下发，同时加一个重试机制，失败之后隔两秒再试，最多试五次。这套逻辑上线之后，现场反馈的"开机没网"问题基本消失了。

5. 常见问题与排查实录

5.1 现象、原因、动作：一张表先定位方向

现场问题千奇百怪，但归类之后其实就那么几种。我整理了一张速查表，遇到问题先按现象对号，能快速收敛排查范围。

这张表里，我个人觉得最容易误判的是"系统提示无网络连接"这一条。设备明明有 IP、能 ping 通、能访问内网服务，系统状态栏却显示一个感叹号。这是因为系统会定期做连通性探测——往预设的探测地址发请求，看能不能拿到预期响应。如果探测地址在内网不可达，系统就判定这条网络"没有互联网访问"，标记成未验证状态。有些定制系统会因此把这条网络的优先级降到很低，应用的流量就不走它了。

处理这个问题的思路有两条：一是关掉系统的连通性检测（在系统设置里改全局开关，需要系统权限），二是把探测地址改成内网可达的地址。前者简单粗暴，后者更规范。我在内网隔离的项目里两种都用过，关检测的方式见效快，但会让系统的其他网络状态判断也一起失效，得评估影响。

5.2 三个真实坑的复盘

坑一：板子换了网口名，代码全白写。某项目用的是定制主板，网口在系统里被命名成eth0，一切正常。后来换了个批次的主板，芯片方案改了，网口名变成了usb0（走的是 USB 网卡芯片）。应用代码没动，但所有调用都返回失败。查了半天以为是权限问题，最后ip link一看名字就不对。解决办法是在系统资源里把识别正则改成同时匹配eth和usb开头的网卡，代码里也把硬编码的eth0改成"取第一个匹配到的以太网接口"。这个教训让我之后所有项目都不再硬编码网口名。

坑二：配置下发成功，但重启就没了。早期实现是每次开机由应用下发配置，看起来没问题。但现场反馈说设备断电重启之后有几十秒是完全没网的，产线设备等不了。原因是我把"下发配置"放在了应用启动流程的后段，应用启动本身就要几秒，加上系统初始化，整个空窗期接近半分钟。后来改成两部分：系统镜像里预置一份默认配置保证开箱即通，应用启动后再用持久化的现场配置覆盖。空窗期缩短到几乎没有。

坑三：双网共存时的默认路由打架。设备同时有 WiFi 和以太网，WiFi 连的是办公网，以太网连的是设备网。应用需要访问设备网里的相机，结果请求全跑到 WiFi 上去了，超时。这个问题不是配置没生效，而是网络选择策略的问题。解决办法是在应用侧显式绑定网络：先枚举系统里的所有网络，找到承载以太网的那个，然后用它打开 Socket。这个做法需要应用持有网络管理相关权限，或者至少能拿到网络列表。另一种更彻底的做法是在系统层调整网络的优先级评分，让以太网优先，但这会影响所有应用，得评估。

5.3 上线之前，我会过一遍这份清单

每次交付前我都会按这个清单走一遍，能挡掉大部分现场问题。

清单里最容易被跳过的是"热插拔恢复"。实验室里网线一插到底，没人拔过，到了现场机柜门一开一关、施工队一动线，问题就出来了。我现在的做法是每次联调都强制拔插三次，把这个动作变成肌肉记忆。

提示：所有涉及网络的配置改动，务必保留一份可回滚的默认值。我在应用里固定留一个"恢复出厂网络设置"的入口，通过一个特定的广播或者按键组合触发，不需要屏幕也能操作。现场出问题时，这一条能救命。

6. 几个能省时间的实现细节

6.1 配置写入的位置与读取顺序

配置持久化我一般分三层：系统镜像里的默认值、应用私有目录里的现场配置、以及运行时的内存状态。读取顺序是现场配置优先，没有就用默认值。这样做的原因是：镜像里的默认值保证"一定能起来"，现场配置保证"能按实际网段工作"，内存状态则是当前生效的那份，用来做状态展示和异常恢复。

写文件的时候要注意原子性。我踩过一次坑：设备在写配置文件的过程中被断电，文件写了一半，下次启动读到的是残缺内容，解析失败之后设备直接用了全零配置，完全没网。后来改成"写临时文件 + 重命名"的方式，重命名在文件系统层面是原子的，要么成功要么保持旧文件，不会再出现半截内容。

6.2 参数校验：宁可拒绝，不要写坏

下发之前一定要做参数校验，这一步能挡掉大量现场误操作。要校验的项目包括：IP 地址能不能正常解析（InetAddress.getByName对非法字符串会抛异常）、前缀长度在 1 到 30 之间、网关和本机地址在同一个网段、DNS 地址格式合法、本机地址不是网络地址或广播地址。

"网关和本机地址在同一网段"这条校验特别有价值。现场最常见的手误就是把网关填成另一个网段的地址，结果设备有 IP 但出不了网段，现象跟"网关没配"一模一样，排查起来很绕。加上这条校验，配置文件写错的时候应用直接拒绝并打日志，省掉现场排查的时间。

校验失败的处理策略也要想清楚：是拒绝下发保持原状，还是回落到默认配置。我的选择是拒绝下发并且保持当前可用配置不变，同时把错误信息写到一个固定的日志文件里。这样即使现场人员乱填，设备也还是连得上，还能通过日志找到原因。

6.3 下发之后的状态确认，别只看返回值

配置接口返回成功，不代表配置真的生效了。我遇到过接口返回成功但地址没写进内核的情况，原因是系统内部有个异步流程还没走完，配置对象被后续的 DHCP 结果覆盖了。

确认状态的方法是回读：调查询接口拿当前生效的配置，比对地址、前缀长度、网关三项。如果对不上，说明下发没生效，需要重试。重试间隔我一般设两秒，最多五次，五次都失败就记日志放弃，避免无限重试把系统拖垮。

除了回读配置，还可以做一个更实在的验证：主动向网关发一个 ICMP 探测，通了才算真的通了。这个验证直接反映"能不能通信"，比比对配置字段更接近实际需求。代价是有些现场禁用了 ICMP 响应，探测会误报失败。我的做法是"配置比对为主，ICMP 探测为辅"，两个都失败才判定失败。

6.4 日志怎么写才在售后有用

网络问题的日志，光打"配置成功/失败"是没用的。我现在的日志至少包含：下发时的全部参数（IP、掩码、网关、DNS）、接口返回的结果、回读到的实际配置、网卡的链路状态、以及当前系统里所有网络的列表快照。

关键是最后一项。很多问题不是单条网络的问题，而是多条网络互相影响。有一份"当时的完整网络列表"日志，事后能还原出当时的网络选择策略，比什么都强。这份日志我会在每次下发配置和每次网络状态变化时都打一次，写到一个滚动文件里，保留最近十次，方便现场直接导出来发给我。

7. 个人在这些项目里攒下的几点体会

以太网静态 IP 这件事，技术上没有多高深，难的是"稳定"两个字。实验室里配一次成功很容易，难的是在不同批次的主板、不同版本的系统、不同现场的网段上，每次都成功，而且断电、拔插、重启之后还能自己恢复。

我最大的体会是：不要把"配置成功"当成目标，要把"设备在任何异常之后都能回到可用状态"当成目标。基于这个思路，方案设计上会自然倾向于多层兜底——镜像预置一层、应用持久化一层、运行时重试一层，任何一层失效都还有其他层顶着。

另外一个体会是排查顺序。遇到"没网"的问题，我现在的固定顺序是：先看物理层（网线、指示灯、carrier值），再看地址层（ip addr），再看路由层（ip route show table all），再看系统层（dumpsys里网络列表和状态），最后才看应用代码。这个顺序是从下往上，每一层排除完再进下一层，比东一榔头西一棒子地猜要快得多。年轻人容易一上来就翻应用代码，其实九成问题在下面三层。

最后一个建议：任何需要现场人员操作的配置项，都要做输入校验和错误提示。现场不是实验室，填错一个数字太正常了。校验做得厚一点，返工就少一点。