LocalSend完全离线运行，仅依赖局域网：通过UDP广播和mDNS实现设备发现，HTTPS点对点加密传输，支持手机热点等临时局域网，无需互联网、不连外部服务器、不回传数据。
想在设备间快速传文件，但又没网，或者压根不想连网？那你可能正需要LocalSend这样的工具。它的工作方式，和那些依赖云服务的软件有本质区别。简单来说，它的一切操作都只在你自己的局域网里完成。下面，我们就来拆解一下它到底是怎么做到的。
一、LocalSend完全不依赖互联网
LocalSend的设计初衷，就是彻底摆脱广域网。它所有的“社交活动”——发现邻居、握手聊天、传递文件——都严格限定在你家或办公室的局域网内部。这意味着，它不会去联系任何外部服务器验证账号，不会偷偷上传日志，更不会在后台下载更新。整个传输过程，就是设备与设备之间的“窃窃私语”。
所以，哪怕你把路由器的外网线拔了，甚至关掉光猫，只要你的手机、电脑、平板还通过同一个Wi-Fi或网线连着，LocalSend就能照常工作，发现彼此并开始传文件。
二、局域网发现依赖本地广播与mDNS
那么，设备之间是怎么“看到”对方的呢？这里没有云端通讯录，全靠局域网底层的“喊话”机制。LocalSend利用了两套成熟的本地协议：UDP广播和多播DNS（mDNS）。
启动应用后，它会做两件事：一是朝本地子网的广播地址（255.255.255.255）“喊”一嗓子，宣告自己上线了；二是竖起耳朵监听5353端口，看看有没有其他设备用mDNS协议发布自己的“.local”域名（比如“My-Laptop.local”）。整个过程完全在子网内完成，既不需要公网IP，也跟互联网接入毫无关系。
具体步骤很清晰：
1. LocalSend启动，立即向局域网发送UDP探测包；
2. 同时，监听mDNS响应，解析出附近设备的本地域名和IP地址；
3. 将这些信息组合成可连接的节点，显示在接收方的设备列表里。
三、文件传输走点对点HTTPS直连
找到目标设备后，重头戏——文件传输就开始了。这里走的也是“直通车”：发送端和接收端会直接建立一条点对点的HTTPS加密连接。数据流直接从A点传到B点，不经过路由器以外的任何“中转站”，也完全用不上那些复杂的NAT穿透或STUN/TURN服务。
其技术流程可以概括为：
1. 接收端在本地随机开启一个HTTPS服务端口（例如8081）；
2. 发送端获取到对方的IP和端口信息，构造一个类似 https://192.168.1.102:8081/upload 的请求；
3. 通过内置的引擎，像浏览器上传文件一样，执行标准的HTTPS POST操作。其中的TLS证书由LocalSend临时生成并相互信任，确保了传输的私密性。
四、热点场景下仍属纯离线模式
用手机开热点给笔记本连，这种临时组建的小网络，LocalSend同样能胜任。这时虽然手机本身可能有移动数据，但LocalSend会“很守规矩”。它只会绑定和使用热点所创建的那个私有子网（比如192.168.43.1/24），绝不会跑去调用蜂窝网络接口。
这得益于几个层面的保障：
1. 安卓和iOS的热点功能，默认就隔离了IPv6并限制了互联网共享转发；
2. LocalSend在编程层面强制将网络通信绑定到热点分配的IPv4地址段；
3. 于是，所有的UDP广播、mDNS查询、HTTPS连接，都被牢牢限制在这个小小的临时子网里。
五、防火墙与系统权限仅影响本地通路
最后，聊聊可能遇到的“拦路虎”。有时LocalSend用不了，问题可能出在操作系统或安全软件上。比如Windows Defender防火墙、macOS的隐私控制、或者安卓的后台限制策略，可能会默认阻止LocalSend进行本地网络通信。但这本质上是系统策略对局域网功能的限制，而不是LocalSend本身需要联网。
解决这些本地权限问题通常有迹可循：
1. 在Windows上，需要在防火墙设置中，允许LocalSend通过“专用网络”；
2. 在macOS上，可能需要在“系统设置→隐私与安全性→完全磁盘访问”中勾选LocalSend；
3. 在安卓设备上，则需要授予“显示在其他应用上层”及“自启动”等权限，以确保后台的设备发现进程不会被系统清理掉。
把这些设置调整好，让LocalSend能在本地网络里自由“行走”，它的离线传输能力就能完全释放出来了。
