LocalSend电脑版搜不到设备？先搞清「同一个 WiFi」不等于「同一个网络」

两台设备连的是同一个 WiFi，LocalSend电脑版却互相搜不到。

刷新了好几遍，列表里就是没有对方。

第一反应是软件出问题了。但更可能的原因是——它们其实不在同一个"局域网"里。

同一个 WiFi 名称，不等于同一个网络。这两件事经常被混为一谈。

要说清楚这个，得先知道 LocalSend电脑版是怎么"发现"设备的。

发现靠的是"喊话"

LocalSend 最方便的地方是不用输 IP 地址——打开软件就能看到同一网络里的其他设备。

这个能力来自 mDNS（组播 DNS）。

它的工作方式和普通网络请求不一样。

普通请求是"点对点"的：你知道对方的地址，直接发过去。

而 mDNS 是"广播"的：你不知道对方是谁，于是对着整个网络喊一嗓子。

具体说：

• 协议：UDP
• 端口：5353
• IPv4 组播地址：224.0.0.251
• 域名后缀：.local

流程是这样的：

第一步：通告

设备启动后，先检查自己想用的名字有没有被占用，然后主动向组播地址发一条消息：

我是谁、我的 IP 是多少、我提供什么服务。

第二步：查询

当你想找某台设备时，也往那个组播地址发一条查询。

这个查询，同一个网络里所有开了 mDNS 的设备都能收到。

第三步：应答

只有名字对得上的那台设备会回应，把自己的 IP 告诉询问方。

之后双方就建立直连了。

注意——整个过程中没有服务器参与。

这也是它和微信传文件、网盘的根本区别：那些工具需要一个"中间人"帮你牵线，而 mDNS 是直接在本地网络里喊，谁听见谁回。

为什么"同 WiFi"不等于"同网络"

现在能解释开头那个现象了。

mDNS 有个硬性限制：它的组播包只在同一个子网内传播。

路由器不会把组播包转发到别的网段。

所以如果两台设备虽然连的是同一个 WiFi 名称，但实际被划分到了不同的子网，它们互相就听不见。

这种情况比想象中常见。

公共 WiFi 的 AP 隔离

酒店、机场、商场、学校的 WiFi，通常会开启"AP 隔离"。

它的作用是——让连在同一 WiFi 上的设备之间无法直接通信。

为什么这么做？ 因为在公共场所，你不知道隔壁坐的是谁。允许设备互通，等于把每个人的设备暴露给所有人。

但对 LocalSend 来说，这就是致命的——组播包发不出去，设备列表永远是空的。

判断方法很简单：如果你在咖啡馆、酒店里搜不到设备，在手机热点下却正常，那基本就是 AP 隔离。

VPN 和代理的干扰

如果设备上开着 VPN 或代理软件，局域网流量可能被"劫持"。

原因在于——这类软件会修改系统的路由表，把流量导向虚拟网卡。

mDNS 的组播包如果被导进了 VPN 隧道，那就等于发到了一个没人听的通道里。

关掉代理和 VPN 再试，这是排查的第一步。

跨网段

企业网络和校园网经常划分多个 VLAN。

同一个 WiFi 名称下，不同设备可能被分到不同网段——比如办公室三楼和五楼连的是同一个 SSID，但不在一个子网。

这种情况下 mDNS 同样不工作。

判断方法：对比两台设备的 IP 和子网掩码。如果前三段不一样，或者掩码不是 255.255.255.0，就很可能跨网段了。

Windows 上还有个容易漏的设置

说一个 Windows 上特有的坑——LocalSend电脑版搜不到设备，经常是这个原因。

Windows 把网络分成两种类型，而这个选择会直接影响设备发现。

• 专用网络（设备发现：开启；用在哪：家里、办公室）
• 公用网络（设备发现：关闭；用在哪：咖啡厅、机场）

当你第一次连上一个新 WiFi 时，Windows 会问"是否希望此电脑可被发现"。

很多人随手选了"否"，网络就被标记为"公用"。

在这个状态下，Windows 会阻止大多数未经请求的传入连接——包括 LocalSend 的组播包。

设置里的「网络和 Internet」中可以改：把当前网络的类型从"公用"改成"专用"，设备发现就会放开。

注意：这个改动只在你信任的网络上做。在公司或公共 WiFi 上改成专用，等于把自己的设备暴露出去。

防火墙也会拦

LocalSend 用的是 53317 端口。

Windows 防火墙默认会拦截它。

如果软件里提示需要放行，或者安装了却没弹出授权窗口可以手动加规则。

用管理员身份打开命令提示符：

netsh advfirewall firewall add rule name="LocalSend_TCP" dir=in action=allow protocol=TCP localport=53317

netsh advfirewall firewall add rule name="LocalSend_UDP" dir=in action=allow protocol=UDP localport=53317

两条规则——TCP 和 UDP 都要加。

其实 LocalSend 内置了故障排查功能，可以自动添加防火墙规则。先试这个，比自己敲命令省事。

实在搜不到就手动连

如果前面的方法都不行，或者网络环境确实不允许组播，LocalSend电脑版还有最后一招：手动输入 IP。

mDNS 只是"帮你找到对方"的便利功能，不是传输的必要条件。

只要两台设备网络互通，直接指定 IP 就能传。

在发送端找到"手动输入"的选项，填对方的局域网 IP 地址即可。

这也从侧面说明了一个问题：发现失败和传输失败是两件事。

前者是"找不到人"，后者是"找到了但连不上"——排查方向完全不同。

顺带说说传输安全性

既然聊到原理，有件事值得说清楚。

LocalSend电脑版的传输是加密的。

它用的是 HTTPS——也就是说，文件和指令都走 TLS 加密通道。

但有个细节容易让人困惑：它没有 CA 证书。

原理是这样的：每台设备在运行时动态生成自己的自签名证书。

因为是局域网直连，双方通过交换证书指纹来确认身份——而不是通过第三方机构验证。

这套机制的效果是：同在局域网里的第三方即便抓到了数据包，也无法解密。

换个角度看，这也解释了它和网盘的关键差别：

• 数据路径（LocalSend：设备到设备；网盘 / 微信：上传服务器 → 下载）
• 需要联网（LocalSend：不需要；网盘 / 微信：必须）
• 速度上限（LocalSend：局域网带宽；网盘 / 微信：公网上传带宽）
• 数据经过谁（LocalSend：只有双方；网盘 / 微信：服务商服务器）

没有外网也能用——这是它和所有云传输工具的根本区别。

一句总结

LocalSend电脑版能自动发现设备，靠的是往局域网里"广播"。

广播的覆盖范围就是子网边界——出了这个范围，谁也听不见谁。

所以"同一个 WiFi"和"同一个网络"是两回事：AP 隔离、VPN、跨网段、Windows 的公用/专用设置，任何一项都能让两台设备虽然连着同一个 WiFi，却形同陌路。

排查顺序建议这样：先关 VPN 和代理 → 换手机热点测一下（排除 AP 隔离）→ 检查 Windows 网络类型 → 放行防火墙端口 → 最后手动输 IP。

安装包：

https://dubapkg.cmcmcdn.com/cs/257def/Localsend%E7%94%B5%E8%84%91%E7%89%88.exe