LocalSend：局域网点对点传文件，不经服务器不出网

LocalSend 是一款开源跨平台的局域网文件互传工具，GitHub 仓库简介把自己定位成"AirDrop 的开源跨平台替代品"。它干的事很单纯：同一个 Wi-Fi 或有线局域网里的两台设备，互相发现、点一下、文件直接从一台传到另一台，不需要注册账号，不需要登录，也不需要连一台中间服务器。传统的"微信传文件""QQ 传文件""上传网盘再下载"，本质上都要绕道一台别人的服务器，文件在你手里消失一下、再出现的这段时间，其实经过了外面。LocalSend 不走这条路，它靠的是同一网段内设备之间直接建立连接，官方 README 说得很直接：它用 REST API 加 HTTPS 加密实现设备间通信，不像那些依赖外部服务器的消息应用，LocalSend 不需要联网、也不需要第三方服务器。

展厅哪道工序会用到它

第一道，甲方专网现场没外网、U 盘又被禁的时候。 不少政企场馆、金融机构的展厅项目，交付机房走的是完全隔离的专网，插网线出不了外网，USB 口在安全策略里直接被禁用，有的机柜位置本身就够不着 USB 口。这时候要往播控机、中控主机里塞一版新素材、一个系统镜像，U 盘和网盘两条常规路都断了。只要两台设备接在同一个交换机或同一个 Wi-Fi 下，LocalSend 就能把文件从你的笔记本直接送进那台机器，不用碰外网这根线。

第二道，布展现场十几台设备来回对传。 布展期现场少则七八台、多则十几台设备：工程机、讲解用的平板、展台上的触摸屏、临时接进来的笔记本。一份新到的宣传片要分发给三四台机器，传统做法是插 U 盘一台台走一遍，一圈下来大半天没了。装了 LocalSend 的设备互相都能看见，选中文件、勾上要发的几台设备，几乎是同时分发，比人肉跑机柜快得多。

第三道，跨系统混合设备互传。 展厅现场的设备很少是清一色的系统：工程机是 Windows，讲解终端可能是 iPad，运营同事随身带的是 Mac，客户现场看效果用的是安卓平板。传统方案里，Windows 到 Mac 传文件、Mac 到 iPhone 传文件常常要换不同工具、走不同流程。LocalSend 官方给出的支持范围覆盖 Windows、macOS、Linux、Android、iOS，外加通过亚马逊渠道支持的 Fire OS，一套工具打通全部组合，不用为每一种设备配对单独记一套操作。

怎么获取，该下哪个包

官方只认两个入口：官网下载页 https://localsend.org/download，以及 GitHub 仓库 https://github.com/localsend/localsend。官方 README 明确建议优先从应用商店或包管理器安装，理由很直接——这款软件本身不带自动更新功能，走商店或包管理器渠道能借助商店自身的更新机制吃到新版本，散装安装包装完之后不会自己提醒你有新版。

Windows 工程机：官方给了 Winget、Scoop、Chocolatey 几种包管理器方式，也有现成的 EXE 安装包和便携版压缩包（Portable ZIP）。工程机批量装机图省事可以走便携版，装完记得自己建一套版本巡检的习惯，别指望它自己弹更新提示。

macOS：App Store 上架，也有 Homebrew 和 DMG 安装包两条路，选一条顺手的就行。

Linux：渠道最多，Flathub、Nixpkgs、Snap、AUR、以及 TAR、DEB、AppImage 几种直接安装包都有；官方额外提了一句，Gnome 桌面环境需要装 xdg-desktop-portal 和对应的 GTK 后端，KDE 桌面则需要装 xdg-desktop-portal 和 KDE 后端，缺了这层依赖，弹窗选文件之类的系统交互可能用不了。

安卓平板/讲解终端：Google Play 商店、F-Droid，或直接下 APK 包。iPhone/iPad：只有 App Store 一条路。

选包时唯一要注意的是别选混：Windows 机器别去装 macOS 的包，安卓设备别指望装 iOS 的 App Store 版——听着是废话，但批量装机脚本里最容易在这种地方出低级错误。另外官网首页导航栏还挂了一个网页版入口 https://web.localsend.org/，浏览器直接打开就能用，不用装客户端，适合那种连装软件的权限都没有、只能开个浏览器的受限设备，具体交互逻辑跟客户端是否完全一致，官方页面没有细讲，遇到这种设备现场实测一下更稳妥。

最短可用路径

两台设备都装好、打开，不用注册、不用登录——这一步官方反复强调是刻意设计：没有账号体系，装完就能用。发送方选中要传的文件（图片、视频、文档，任意类型都支持），界面上会列出同一网段里能看到的设备，点一下目标设备，接收方那边会弹出确认提示，对方点接受，传输立刻开始，走的是本地网络，不用等云端中转。文件默认存进接收设备的"下载"目录，这个位置可以在设置里改。

展厅工程里真正要弄明白的那几件事

"不经过第三方服务器"这条对甲方到底意味着什么

这是本文最值钱的一段，也是能直接写进方案的一句话。LocalSend 官方 FAQ 被问到"是否走互联网"时，答案原文是：LocalSend 用的是本地 Wi-Fi 网络传文件，数据不会离开本地网络（"LocalSend uses your local WiFi network to transfer files. Your data never leaves your local network."）。README 里"How It Works"一节说得更细：设备之间靠 REST API 通信，全程走 HTTPS 加密，且每台设备上的 TLS/SSL 证书是现场动态生成的，不依赖任何第三方服务器颁发或转发。

翻成甲方 IT 能听懂的话就是：这不是"厂商服务器帮你转一道再删掉"的模式，而是两台设备直接握手、数据只在这两台机器之间流动，全程没有第三方经手。这条对政企、金融类展厅项目特别关键，因为这类项目的 IT 验收第一条红线往往就是"数据是否出网"。写方案时可以把这句原话（数据不出本地网络）作为依据引用，比自己空口保证更有说服力。

跨网段、AP 隔离——现场设备互相看不见的头号原因

装完打开，两台设备明明都在，列表里却互相看不到对方，这是现场最高频的失败场景，八成不是软件的问题，而是网络策略挡住了发现机制。官方 README 专门写了一条提醒：确保路由器上关闭了 AP 隔离（AP Isolation），并且特别点名——访客网络（Guest 网络）默认开启这项功能的情况并不少见，即便主网络没开。AP 隔离一旦生效，同一个 Wi-Fi 下的设备互相之间是被禁止直连的，这是很多路由器为了安全故意设的墙，跟 LocalSend 本身无关。

跟这个问题同源、更常见于展厅这种多设备网络的，是 VLAN 划分。如果甲方网络把不同区域、不同类型的设备划进了不同 VLAN（比如中控和讲解终端不在一个网段），彼此之间在二层网络上就是隔离的，跟 AP 隔离是同一类"看得见网线、看不见对方"的问题。这块的判断方法和处置思路，本站《展厅设备组网 IP 怎么规划》一文里讲得更细，遇到"设备明明在同一现场却互相发现不了"，先按那篇的思路排查是不是网段没打通，而不是急着重装软件。

防火墙——第二高频的失败原因

官方文档明确给出了端口要求：入站方向要放行 TCP 和 UDP 的 53317 端口，出站方向不限端口。企业级防火墙、安全软件默认往往会拦掉不认识的入站端口，这时候设备同样会互相看不见。Windows 机器还有一条额外的坑：官方排错表里专门列了一条——如果 Windows 的网络连接被系统识别成"公用网络"而不是"专用网络"，Windows 自身会对局域网发现类的流量更严格，导致对方设备列表是空的，把网络配置文件改成"专用"通常就能解决。macOS 和 iOS 上则对应另一个开关：系统"隐私"设置里有一项"本地网络"权限，如果没有单独授权给 LocalSend，同样会导致发现失败，去系统设置里切一下这个权限的开关。

大文件、传输速度与断点续传

官方在功能介绍里给的说法是"传输速度按 Wi-Fi 网络的上限跑，没有额外的带宽限制"，也没有给出任何文件大小上限的说明，理论上传多大的文件都不受软件本身限制。但官方排错表里也给了一条关于速度的建议：如果发现传输速度慢，一是切到 5GHz 频段的 Wi-Fi（2.4GHz 频段本身速率上限更低），二是把发送和接收两端的加密都关掉——这条信息本身值得留意：默认的 HTTPS 加密是有速度代价的，如果现场传输的是不涉密的普通素材文件、更在意速度，关闭加密是官方给出的正当选项；如果传输内容本身敏感，不建议为了速度关掉加密，这是个安全和速度的权衡，不是哪边天然更"对"。

断点续传这件事，官方文档没有提及。 没查到任何关于"传输中断后可以从断点继续"的说明，工程上应当按"传输中断大概率要从头重传"来做预案：安排传大文件的时间点时，尽量避开接收设备可能锁屏、休眠或网络会断的时段，别把几十 G 的素材包安排在人还要用这台机器干别的事的时间窗里传。

跨平台支持范围，以官方兼容性表为准

官方 README 给出了明确的最低系统版本要求：Android 5.0 及以上，iOS 12.0 及以上，macOS 11（Big Sur）及以上（更老的 macOS 可以借助第三方补丁工具凑合用，官方给了对应的 issue 链接），Windows 10 及以上（更早的 Windows 7 只有旧版本能用，官方现行的最新版本已不再支持）。Linux 没有明确的最低系统版本要求，但明确点出了桌面环境依赖：Gnome 需要 xdg-desktop-portal 加 GTK 后端，KDE 需要 xdg-desktop-portal 加 KDE 后端。展厅工程机绝大多数是 Windows 10 及以上，一般不会踩到这条线；如果项目里还挂着老旧的 Windows 7 机器，这条要提前跟甲方讲清楚，别等装机当天才发现装不上。

它不是运维方案，长期分发别指望它

LocalSend 解决的是"这一次、这几台设备之间的临时对传"，不是持续性的内容分发系统。它没有排期、没有分组下发、没有失败重试和状态回执，靠的是人在现场手动点一下。如果需求是展项交付后要长期、定期给几十台设备推送新内容，还要求分组下发、灰度验证、出错能回滚，这类需求应该走专门的运维方案，而不是靠人拿着笔记本一台台点 LocalSend 传——那套流程本站另有《多展项远程批量更新内容实战》讲得更完整，两者不是一回事，也不要互相替代。

踩坑与排错清单

什么时候别用它

要做长期、成体系的内容分发时。 前面已经讲过，它是一次性的人工对传工具，没有排期、分组、状态回执这些运维系统该有的能力，硬凑合用会让运维变成体力活。

甲方网络策略卡死、IT 不配合开权限时。 AP 隔离、VLAN 隔离这类问题技术上有解法，但前提是甲方 IT 愿意配合改配置。如果对方明确不同意开这些权限，装了也是白装，得先谈流程，不是硬冲技术关。

要传到局域网以外的地方时。 它只解决同一网段内的传输，两个不在同一网络的地点之间传文件，这个工具帮不上忙，该用远程运维工具里带文件传输功能的方案，或者正经的云盘/传输服务。

对断点续传有硬性要求的大文件搬运。 官方没提供这项能力，中断了大概率要重传，追求可靠续传的场景应该找专门带这项能力的传输工具。

与本站的衔接

判断设备互相看不见是不是网络策略卡住的，先看本站《展厅设备组网 IP 怎么规划》，里面把子网划分、VLAN 隔离这些概念和排查思路讲得比这篇细。

如果最终判断这次的需求其实是长期性的内容更新和多台设备分发，而不是一次性对传，该看的是《多展项远程批量更新内容实战》，那篇讲的是分组下发、灰度验证和出错回滚的完整链路。

需要远程接管展厅工程机做维护和救火，跟本文讲的"传文件"是两码事，可以看RustDesk 软件页——两者常常配套使用：先用 RustDesk 连上机器，发现素材过时了，再用 LocalSend 把新素材传进去。

交付之后，这些环节谁来管

临时用的工具解决的是当下的问题。展厅要跑好几年，中间会换人、换素材、换设备——那时候靠的不是工具好不好用，是有没有一套能交接的运行方式。

企服君把设备纳管、状态监控、批量操作做成标准能力，让运维不依赖具体是谁在做。见集成商年费方案。

出处

本文所述的功能、端口、兼容性范围与排错方法，均来自 LocalSend 的官方渠道：官网首页与下载页、GitHub 官方仓库的 README（含 Setup、How It Works、Compatibility、Troubleshooting、Download 各节）、以及 GitHub 仓库自身登记的开源许可证信息。具体地址见本页出处栏。功能细节可能随版本调整，以官方页面为准。