Debian resolvconf 记录排序：把 VPN 记录放到最前

VPN 的域名服务器总是落到局域网那条的下面，而直接编辑 /etc/resolv.conf 只能维持几分钟。那个文件是自动生成的，所以修改永远留不住。在 Debian 的 resolvconf 里，排序的输入是 /etc/resolvconf/interface-order，它排序的是记录名而不是 DNS 地址。在动这两个文件之前，先确认究竟哪个解析器栈在负责。

确认输出归 resolvconf 管

先问清楚：当前这个文件是谁写的，之后又会由谁重写。resolvconf 包自称是动态解析器配置的框架，而一台运行 systemd-resolved 或由 NetworkManager 管理的解析器的主机，从外面看可能一模一样，实际用的却是完全不同的策略。

readlink -f /etc/resolv.conf
dpkg -l resolvconf 2>/dev/null | tail -n 1

如果解析出来的路径并不通向 resolvconf 的运行时目录，就到此为止：这份手册属于另一套栈。

只有做完这步检查，才值得列出 resolvconf 当前持有的记录。

写模式之前先读记录

interface-order 匹配的是提供方记录的名称，不是地址，也不是内核接口名。先把已注册的东西列出来，这样模式才能指向真实存在的条目。

ls /run/resolvconf/interfaces
cat /etc/resolvconf/interface-order

记录名通常带有标明提供方的后缀，因此隧道记录和 DHCP 记录可能共用同一个接口前缀，排序却不同。请照抄目录列表里的准确名称。不要从接口名去推断记录名，因为注册什么由客户端集成决定。自己编的名字永远不会匹配，那条记录会悄悄落到兜底模式上，连一句报错都没有。

把顺序写成首个匹配的模式

该文件是一串 shell glob 模式，每行一个。记录取得它匹配到的第一条模式的位置，所以把宽泛的模式放在具体模式之上，具体那行就永远轮不到。

# /etc/resolvconf/interface-order
lo*
tun_work.*
enp*
*

把具体的隧道模式放在兜底模式和物理接口模式之上。

保留文件原本就有的其他行。把整套策略换成示例，正是无关提供方悄悄挪位的根源；只改一行，重新生成再对比。模式里不能有空白、斜杠，也不能以点或波浪号开头；空行和井号注释会被忽略。

重新生成并验证结果

顺序在更新脚本重建文件时才生效。走受支持的更新路径，而不是去改生成出来的输出，然后再读解析器实际收到了什么。

resolvconf -u
cat /etc/resolv.conf

要验证两次解析而不是一次：一个应当经隧道解析的私有名称，以及一个公共的对照名称。如果顺序看起来没错、私有名称仍然失败，那问题就是命名空间路由而不是记录优先级，再怎么重排也没用。每条答案都要和返回它的服务器对照，而不只是看成功与否。被错误解析器答复的私有名称仍然是失败，对用户来说就像 DNS 出了故障。

把陈旧记录退场，而不是把它降级

断开后反复出现的废弃 VPN 记录，是客户端集成里的生命周期缺陷。把它挪到最底下只会掩盖症状，还在列表里留下一个死掉的解析器。

通过注册它的那个组件让它退场，然后确认记录目录里不再列出它。

记下提供方名称、你改的模式，以及你做的两次解析。下一个人需要的是这些名字，而不是故事。