【踩坑记录】局域网使用 mDNS 免 IP 登录服务器，却被代理 Fake-IP 劫持的排查过程

为什么学这个

最近在折腾局域网里的 Linux 服务器（主机名 tegra-ubuntu）。由于路由器 DHCP 经常会重新分配 IP，每次 SSH 登录前都要先查一遍服务器的新 IP，非常繁琐。

为了解决这个问题，我了解到了一种零配置的局域网发现协议：mDNS（多播 DNS） 。通过它，我可以直接使用 主机名.local 的形式（例如 ssh nvidia@tegra-ubuntu.local）来访问服务器，无论 IP 怎么变，名字始终有效，纯局域网环境也能完美工作。

核心内容/步骤

在 Linux 服务器上配置 mDNS 非常简单，只需要安装并启用 Avahi 服务即可。

1. 在服务器端安装 Avahi 服务（以 Debian/Ubuntu 为例）：

Bash

sql 复制代码

sudo apt update
sudo apt install avahi-daemon -y
sudo systemctl enable --now avahi-daemon

2. 确认服务器主机名：

查看 /etc/hostname，确认机器名（例如 tegra-ubuntu）。

3. 客户端连接：

在电脑（Mac/Linux/安装了 Bonjour 服务的 Windows）上，直接 SSH 连接：

Bash

css 复制代码

ssh nvidia@tegra-ubuntu.local

原本以为三步搞定，结果却在连接时狠狠栽了个跟头。

遇到的问题与解决方法

诡异的现象：Ping 得通，SSH 连不上

配置完后，我满心欢喜地在 Windows 上发起连接，却得到了报错：

Plaintext

kotlin 复制代码

PS C:\Users\Administrator> ssh nvidia@tegra-ubuntu.local
Connection closed by 198.18.0.17 port 22

连接被瞬间掐断。但让我纳闷的是，我尝试 ping tegra-ubuntu.local 时，竟然是通的，而且延迟异常的低：

Plaintext

ini 复制代码

来自 198.18.0.17 的回复: 字节=32 时间<1ms TTL=128
...
最短 = 0ms，最长 = 0ms，平均 = 0ms

破案关键：198.18.x.x 网段

仔细看终端输出，我发现了盲点：解析出来的 IP 是 198.18.0.17。

在标准的局域网环境中，内网 IP 通常是 192.168.x.x、10.x.x.x 或 172.16.x.x。而 198.18.x.x 这个特殊的保留网段，通常是 Clash、V2Ray 等代理软件在开启"TUN 模式"或"Fake-IP（假 IP）模式"时分配的虚拟 IP。

背后的原理：

我在终端发起 tegra-ubuntu.local 的 DNS 请求。
本地的代理软件（开启了 TUN/Fake-IP）接管了流量，直接拦截了请求，并随手返回了一个假 IP 198.18.0.17。
当我执行 ping 时，代理软件伪造了 ICMP 回复，所以出现了毫无波动的 0ms 延迟。
当我执行 ssh 请求 22 端口时，代理软件拿到了这段 TCP 流量，但它根本不知道该把这个内网请求转发到哪个外网节点，于是直接掐断了连接（Connection closed）。

解决方法

原因找到，解决起来就很简单了，核心思路是让局域网流量绕过代理：

临时验证 ：彻底关闭 Windows 上的代理软件，清理 DNS 缓存 (ipconfig /flushdns)，再次 ping 和 ssh，成功获取真实的 192.168.x.x IP 并顺利登录。
彻底解决 ：在代理软件的配置中，检查"绕过局域网 (Bypass LAN)"选项是否开启，或者在路由规则（Rules）中，将 *.local 域名以及本机的真实内网网段（如 192.168.1.0/24）加入直连（DIRECT）名单。

收获与总结

mDNS 是局域网神器 ：对于家里有 NAS、树莓派或多台测试机的开发者来说，hostname.local 绝对比死记硬背 IP 或绑定静态 IP 优雅得多。
警惕代理软件的全局劫持 ：在开启了 TUN 或 Fake-IP 模式的机器上排查网络问题时，千万不要只看 ping 通不通。如果解析出的 IP 落在 198.18.x.x，那必然是被代理接管了。
排障思维：遇到网络不通，第一步先看 IP 对不对。异常的 IP 地址往往就是破局的关键线索。