NetworkManager 中 gateway-ping-timeout 究竟在等什么

你在一篇关于笔记本先开机、网络却还没可用的帖子里看到 connection.gateway-ping-timeout，把它调大，然后情况发生了变化。这个改动是否因为你以为的原因而起了作用，是另一个问题。答案要从计时器运行期间激活究竟在做什么说起，也要从这次等待有两种可能的结束方式说起。

从命令行跟踪一条连接，语义就变得具体了。

跟踪一次激活

先看保存的连接，而不是全局默认值，因为这是按连接生效的属性。只有确实需要时才加 --show-secrets；这项设置本身不是机密。

nmcli -f connection.id,connection.gateway-ping-timeout connection show
nmcli connection show "Wired connection 1" | grep gateway-ping

属性为零时（这是文档中的默认值），地址配置一完成，激活就继续。把它设为正值，IP 配置的激活就会等到网关回应或超时到期。

然后在观察事件流的同时把连接关掉再打开。你看到的顺序正是这项设置在起作用：设备状态、地址配置、等待，最后是依赖服务通常据以排序的已激活状态。

这次等待有两种结局

两种结局都重要，但大多数人只记得一种。网关的回应会提前结束等待，超时同样会结束它，无论有没有任何东西应答。这项属性并不要求在激活完成前 ping 必须成功。

这一句话澄清了关于酒店和会议场所笔记本的大量困惑：那里的强制门户往往在你登录前拒绝 ICMP。连接在超时到期后仍会激活；它只是比需要的更晚，而排在连接之后的每个服务都跟着一起等。

它也不是存活检查。描述里没有任何东西会在连接起来之后开始 ping 网关，也没有任何东西会因为后来的 ping 失败而断开活动配置。如果你需要丢包检测，那属于协议或隧道所有者的职责，而不属于一个只在激活期间跑过一次的属性。

两个对象，一项设置

有线基础配置和 VPN 配置是彼此独立的配置对象，在其中一个上设置该属性不会影响另一个。指定了基础连接的 VPN 配置不会继承它的任何激活设置，这就是为什么你改过的值看起来对你观察的对象毫无作用。

nmcli -f NAME,UUID,TYPE connection show
nmcli connection show "Office VPN" | grep gateway-ping

读 UUID，而不是名字。重装或恢复配置后名字会重复，而两条可见名字相同的连接会让你去改错误的文件，真正的那条却原封不动。

已安装的 NetworkManager 版本也很重要。插件行为以及连接类型如何把这项属性映射到自己的激活步骤各不相同，所以要在你实际部署的版本上测试，而不要假定找到的文章原样适用。

这次等待无法证明什么

最耗时的部分在这里。本地路由器的回应只能证明激活期间有一台主机回应了一次 ICMP 回显。它不能证明 VPN 端点能解析、客户端身份被接受、私有路由已安装、办公网解析器有回应，也不能证明你在意的应用能用。

那些是彼此独立的依赖，各有各的证据。DNS 失败时网关仍可能回应，而所有应用路径都正常时网关也可能按策略悄悄丢弃 ICMP。因此以这项属性作为门槛，只是在猜哪一层慢了，而不是在测量它。

如果你在等一个依赖服务，就说清它需要什么。分配到的地址由地址配置来回答。隧道由隧道自身的状态来回答。私有名字由一次查询来回答。应用由应用来回答，而这些答案没有一个来自以网关命名的计时器。

如果要改，就写下原因

在获批的变更之前记录原值和理由，然后把它设在具体连接上，而不是到处都设。更长的等待会推迟排在该连接之后的所有对象的激活时机，这可能让慢的系统看起来正常、快的系统看起来坏了。

有一个历史陷阱值得点名：这样的值有时会被改掉，好让旧编辑器接受某份配置。如果真实情况是这样，那就是两件事而不是一件。编辑器保存了，而实际生效的网络策略变了。修好编辑器或插件，再把计时器放回去。

NetworkManager 源码把该属性定义为：IP 地址配置成功要延迟到网关回应或超时为止，默认值为零；连接设置的定义是在依赖二手描述的行为之前应当阅读的参考。