局域网之间传文件最麻烦的往往不是网络本身而是绕了太多圈先通过微信或 QQ 把文件发出去再到另一台设备上登录、下载、保存图片被压缩、视频被二次转码遇到大一点的安装包还可能被提示“文件过大无法发送”。如果两台设备明明就在同一个办公室、同一个路由器下面为什么不能直接点对点传输这正是 LocalSend 这类局域网文件传输工具要解决的问题。这篇文章会围绕 LocalSend 的安装部署、核心工作原理、日常使用流程、常见问题排查以及安全边界做一次完整梳理。无论你是想在手机和电脑之间快速传图还是需要在 Windows、macOS、Linux 三套系统之间互传安装包读完这篇文章后你都可以不再依赖网盘中转也不需要注册任何账号就能完成不压缩、不走公网的局域网安全互传。1. LocalSend 是什么解决局域网传输的真正痛点1.1 从 AirDrop 说到跨平台传输用过苹果生态的人很多都习惯用 AirDrop 在 iPhone、iPad、Mac 之间传文件。它的体验非常好打开 Wi-Fi 和蓝牙选中文件点击附近设备对方点击接收文件就以点对点方式直接传过去不经过云端文件也不会被压缩。但 AirDrop 的问题也很明显它只存在于苹果生态。如果换成 Android 手机和 Windows 电脑AirDrop 就彻底失效了。传统方案要么是登录微信或 QQ要么是上传网盘再下载过程繁琐且受限于公网带宽。LocalSend 则尝试把 AirDrop 式的体验带到所有主流平台上。从专业定义上看LocalSend 是一个免费、开源、跨平台的局域网文件传输工具。它基于 Flutter 开发使用 REST API 和 HTTPS 加密通信。设备之间通过局域网LAN直接传输文件、文件夹、文本和剪贴板内容默认不依赖互联网连接也不需要外部服务器中转。1.2 与主流传输方案对比为了方便你理解 LocalSend 的定位我整理了一张常见传输方案的对比表传输方案是否依赖公网是否注册账号是否压缩文件主要局限微信 / QQ 文件传输是是是文件大小限制、压缩画质百度网盘 / OneDrive是是通常不压缩上传后再下载链路长AirDrop否否否仅限苹果生态浏览器 WebRTC 传文件视具体工具而定通常否否需要浏览器和服务端信令配合LocalSend否否否需要设备处于同一个局域网从表里可以看出LocalSend 的核心优势有三点第一不依赖公网断网环境下只要局域网通就能用第二没有账号体系不需要手机号、邮箱或第三方登录第三文件不做压缩原图、原文件直接传输。1.3 哪些场景下最推荐使用 LocalSend根据实际使用经验下面几类场景最值得引入 LocalSend开发者在开发机、测试机、服务器之间互传安装包和配置文件。办公室环境中同事之间快速交换大体积附件。在没有外网的企业内网里需要通过局域网完成文件交换。个人用户在 Windows、macOS、Android、iOS 之间互相传图传视频。活动现场、展会或临时组网环境中快速共享资料。如果你只是偶尔在微信里传一张小图片LocalSend 带来的改变可能不明显但如果你的日常工作高度依赖跨设备文件交换它能节省的时间非常可观。2. 环境准备LocalSend 全平台安装LocalSend 目前的客户端覆盖 Windows、macOS、Linux、Android、iOS 五个平台。安装方式主要分两类一类是去应用商店或 GitHub Releases 页面下载安装包另一类是通过命令行包管理器安装。下面按平台说明。2.1 Windows 安装Windows 用户有两种常用方式。第一种是直接到 GitHub Releases 页面下载安装包。在项目主页的 Releases 区域选择带有windows字样的安装包比如.exe或.msi文件下载后双击安装即可。第二种是使用 Windows 包管理器winget安装。先打开 PowerShell 或 Windows Terminal执行搜索命令winget search localsend搜索完成后会返回一个或多个结果。找到对应的包 Id 后执行安装winget install 实际查询到的包Id这里不写死具体包 Id是因为不同渠道的包名可能变化以你本机查询到的结果为准更稳妥。安装完成后可以在开始菜单中找到 LocalSend 并启动。2.2 macOS 安装macOS 用户最推荐的方式是使用 Homebrew Caskbrew install --cask localsend这条命令会自动下载最新版本并安装到 Applications 目录。如果你更习惯图形化操作也可以去 App Store 搜索 LocalSend或从 GitHub Releases 下载.dmg文件手动安装。首次打开 macOS 应用时如果系统提示“无法打开因为无法验证开发者”需要手动到“系统设置 - 隐私与安全性”中允许应用运行。这是 macOS 对未签名或未公证应用的默认保护机制不是应用本身有问题。2.3 Linux 安装Linux 的发行版较多安装方式也略有差异。这里以 Debian / Ubuntu 为例。如果你下载了.deb安装包可以使用dpkg安装sudo dpkg -i LocalSend-*.deb如果安装过程中提示缺少依赖可以再执行sudo apt-get -f install除了 deb 包LocalSend 还提供了 AppImage、Flatpak、Snap 等多种 Linux 打包格式。如果你使用 Snap可以尝试sudo snap install localsend如果你使用 Flatpak需要先在系统上配置好 Flathub 源再通过 Flatpak 安装。具体包名以 Flathub 页面上的实际名称为准。2.4 Android 与 iOS 安装Android 用户可以在 Google Play、F-Droid 或者 GitHub Releases 中下载安装。国内 Android 用户如果无法访问 Google Play可以使用 GitHub Releases 页面提供的 APK 文件安装时允许“安装未知来源应用”即可。iOS 用户直接在 App Store 搜索 LocalSend 安装。需要注意移动端 App 安装完成后首次打开时系统通常会询问“本地网络权限”。iOS 和 Android 较新版本都会对局域网通信做权限限制如果不允许 LocalSend 使用本地网络它会搜不到同一局域网内的其他设备。这一步在后面的常见问题部分还会重点提到。2.5 从源码编译面向开发者LocalSend 本身是开源项目使用 Flutter 开发。如果你有定制需求可以拉取源码自行编译。基本流程如下git clone https://github.com/localsend/localsend.git cd localsend flutter pub get flutter run -d linux执行以上命令前需要先安装 Flutter SDK并按需启用对应的桌面平台支持。比如在 Linux 桌面端运行前可能需要执行flutter config --enable-linux-desktop需要说明的是源码编译适合有 Flutter 开发经验的用户。普通使用者直接安装 Release 版本即可不需要也不建议自行编译。3. 核心原理拆解LocalSend 是怎么工作的很多教程只告诉你“怎么用”但如果你想真正排查问题就必须理解它“为什么能搜到设备”“为什么能传文件”。下面拆解 LocalSend 的三个核心机制。3.1 设备发现UDP 广播LocalSend 启动时会监听一个默认端口53317。当用户打开设备列表或点击刷新时LocalSend 会向局域网发送 UDP 广播包广播包里携带设备名称、协议版本、可用端口等信息。同一网段内其他运行 LocalSend 的设备收到广播后会把自己的设备信息回复给发送方于是两台设备的界面上就能互相看到对方。这个机制和 AirDrop 类似都是基于本地网络发现。它的优势是无需中央服务器所有设备都能自组织地出现在列表中。但它的限制也很明显UDP 广播通常只在同一个二层网络内生效。如果两个设备不在同一个网段或者路由器开启了“AP 隔离”功能设备之间就无法通过广播互相发现。下面是一个用 Python 演示“UDP 广播发现”思路的示意代码。请注意这里只是帮助理解原理并不是 LocalSend 官方协议的完整实现实际协议细节以官方源码或抓包结果为准。 演示代码向局域网发送 UDP 广播探测 LocalSend 设备。 重点在于理解“广播 - 回复”的发现机制消息字段仅为示意。 import json import socket BROADCAST_IP 255.255.255.255 PORT 53317 def discover(timeout3): # 创建 UDP socket sock socket.socket(socket.AF_INET, socket.SOCK_DGRAM) # 允许发送广播包 sock.setsockopt(socket.SOL_SOCKET, socket.SO_BROADCAST, 1) sock.settimeout(timeout) # 示意数据包实际格式请以官方协议为准 payload { deviceName: python-demo, deviceModel: PC, port: PORT, } sock.sendto(json.dumps(payload).encode(), (BROADCAST_IP, PORT)) print(已发送 UDP 广播等待设备响应 ...) while True: try: data, addr sock.recvfrom(4096) print(f收到 {addr} 的响应: {data.decode(errorsignore)}) except socket.timeout: print(广播探测结束) break if __name__ __main__: discover()这段代码的价值在于帮助你建立“局域网设备发现”的直觉。实际遇到搜不到设备的问题时首先就要检查 UDP 广播路径是否通畅。3.2 文件传输HTTP over TLS设备发现只是第一步。真正传输文件时LocalSend 使用的是 HTTP 协议并叠加 TLS 加密。也就是说发送方和接收方都会在本机启动一个 HTTPS 服务默认端口同样是53317。当发送方选中文件并点击发送时发送方会构造一个包含文件元数据的请求推送到接收方的 53317 端口。接收方用户选择“接受”或“拒绝”。如果接受接收方会从发送方下载文件数据。整个过程在局域网内点对点完成不走公网也不经过第三方服务器。为了确保传输安全LocalSend 会在本地生成 TLS 证书并使用 HTTPS 加密通道。首次连接时双方会核对证书指纹部分版本还会通过 PIN 码确认来防止中间人攻击。这里的逻辑和 SSH 首次连接时确认指纹非常相似。3.3 网络端口与防火墙规则LocalSend 默认使用的端口是53317。实际使用中你至少要保证这条规则成立UDP 53317用于设备发现广播。TCP 53317用于 HTTPS 文件传输。如果你开启了防火墙或者公司网络有统一的安全策略需要将这两个端口放行。下面以 Linux UFW 防火墙为例sudo ufw allow 53317/tcp comment LocalSend HTTPS file transfer sudo ufw allow 53317/udp comment LocalSend device discovery在 Windows 上如果首次运行时系统弹出防火墙授权窗口一定要勾选“专用网络”并允许访问。如果误点了取消后续可以到“Windows 安全中心 - 防火墙和网络保护 - 允许应用通过防火墙”中重新配置。4. 完成一次本地文件传输实战下面通过一系列具体操作从零开始走通一次 LocalSend 文件传输。4.1 传输前检查清单在正式开始之前我建议先快速检查这几点能避免后面踩坑两台设备连接的是同一个路由器或同一个局域网。两台设备都已经安装并启动 LocalSend。两台设备处于同一网段例如都是192.168.1.x。如果使用移动端确认已授予“本地网络”权限。如果设备开启了系统防火墙确认 53317 端口放行。4.2 发送文件 / 文件夹 / 文本以 Windows 和 Android 互传为例完整流程如下在两台设备上分别打开 LocalSend。确认设备列表里能看到对方的设备名。如果看不到点击刷新或稍等几秒。在发送方点击“发送文件”按钮选择要传输的文件。从设备列表中选择接收方。接收方会收到一条传输请求显示文件名、大小、发送方信息。接收方点击“接受”文件开始传输。传输完成后接收方可以在设置中指定的保存目录里找到文件。文件夹的传输操作完全一致LocalSend 会保留目录结构。文本传输则更轻量点击“发送文本”后输入内容接收方可以直接复制到剪贴板适合快速传递链接或短文本。4.3 使用二维码传输LocalSend 在每台设备的界面上都会展示一个二维码。这个二维码包含当前设备的地址、端口、设备指纹等信息。使用场景通常是这样的你在电脑上打开了 LocalSend对方用手机打开 LocalSend 后点击扫描二维码就可以直接向你的电脑发送文件。这个功能很适合会议现场或临时环境不用手工输入 IP 地址。4.4 接收模式与保存目录设置LocalSend 默认是手动接收模式每次收到传输请求都会弹窗需要用户点击“接受”才会开始接收。如果你在可信的局域网环境中使用建议开启“快速保存”模式。开启后文件会自动保存到指定目录不需要每次手动确认效率会高很多。但在公共网络或不确定对方身份的场合建议保持手动接收模式避免陌生设备给你推送文件。保存目录可以在设置中修改。Windows 和 Linux 默认一般会使用“下载”目录移动端则通常保存在应用专属目录或系统下载目录。建议在设置中固定一个专门目录方便后续查找和整理。4.5 从命令行和网络层验证连通性如果你在排查“明明能看到设备但发送失败”的问题可以回到网络层验证。假设设备 A 的 IP 是192.168.1.10设备 B 的 IP 是192.168.1.20。在设备 A 上先 ping 设备 Bping 192.168.1.20如果 ping 不通说明两台设备之间的网络路径有问题这时候需要检查网段、AP 隔离、路由器配置。如果 ping 通了再检查端口是否正常监听。在 Linux 或 macOS 上可以执行ss -tlnup | grep 53317在 Windows 上可以用netstat -ano | findstr 53317如果本机 53317 端口没有进程监听说明 LocalSend 没有正确启动或者已经被系统拦截。重新启动 LocalSend 后再检查一次。5. 常见问题与排查思路LocalSend 使用过程中最集中的问题几乎都出现在设备发现和传输超时两个方面。下面按问题现象、常见原因、解决思路的顺序整理成表。问题现象常见原因解决思路两台设备互相搜不到不在同一网段或路由器开启 AP 隔离连接同一 Wi-Fi关闭 AP 隔离能搜到设备但发送请求超时防火墙拦截 TCP 53317放行 TCP 53317 端口手机能搜到电脑电脑搜不到手机手机 App 缺少“本地网络”权限或后台被清理进入系统设置授予本地网络权限允许后台运行传输速度很慢Wi-Fi 信号弱、2.4GHz 干扰大距离路由器近一些切换到 5GHz 频段对方设备请求被自动拒绝LocalSend 接收模式设置为手动且未确认接收方点击“接受”或开启“快速保存”提示证书指纹 / PIN 码不一致设备重新安装过 LocalSend或连接异常确认接收方身份重新配对后再传输公司内网无法广播发现网络做了 VLAN 隔离、广播隔离联系网络管理员确认二三层网络互通策略下面再展开几个高频问题的排查细节。5.1 设备互搜不到这是最常见的问题。先说结论90% 以上的“互搜不到”都是因为两台设备不在同一个局域网或者网络隔离配置阻止了 UDP 广播。排查步骤可以按下面顺序来确认两台设备连接的是同一个 Wi-Fi 或有线网络。在设置里查看两台设备的 IP 网段是否一致。检查路由器后台是否开启了“AP 隔离”或“访客网络隔离”。检查两台设备是否都授予了 LocalSend 必要的网络权限。如果公司网络有 VLAN 划分确认两个设备是否被划分到不同 VLAN。5.2 能搜到对方但发送超时设备能被搜到说明 UDP 广播路径是通的。发送超时则大概率是 TCP 53317 端口被拦截或接收方没有正常监听。处理思路在接收方设备上确认 LocalSend 正在前台运行。检查接收方防火墙是否放行 TCP 53317。尝试发送小文件判断是否与文件大小有关。如果发送方和接收方系统时间偏差很大也可能导致 TLS 校验失败建议校准时间。5.3 移动端被系统清理后台Android 和 iOS 对后台进程都有严格限制。LocalSend 如果被系统清理就无法继续监听端口自然收不到文件。解决方法是Android在系统设置中允许 LocalSend 后台运行关闭电池优化。iOS在 App 切换器中保留 LocalSend并允许后台刷新。传输大文件时尽量保持 LocalSend 在前台运行。6. 安全与隐私边界LocalSend 适合传什么不适合传什么LocalSend 的宣传点之一是“文件不经过云端”这一点确实能避免很多隐私风险。但我还是建议你对它的安全边界有一个更清醒的认识。6.1 LocalSend 能做什么LocalSend 在传输层使用了 TLS 加密。也就是说文件在局域网内传输时数据内容是加密的旁观者无法直接看到明文内容。同时由于没有账号体系它不会把你的手机号、邮箱、设备通讯录等个人信息上传到任何服务器。从隐私角度看LocalSend 的“本地传输”设计比“云盘转存”更安全因为它不创造额外的数据副本。6.2 LocalSend 不能做什么需要明确的是TLS 加密解决的是“传输过程中被窃听”的问题并不能解决“接收方本身就是恶意设备”的问题。如果把文件发送给一个陌生设备对方依然能查看文件内容。另外LocalSend 的自签名证书机制决定了它不依赖公共 CA 体系。为了防止中间人攻击配对时核对 PIN 码和证书指纹非常重要。如果忽略这些提示理论上存在被中间人劫持的风险。所以我的建议是只在可信局域网中使用 LocalSend。不要接收来自完全陌生设备的传输请求。涉及高敏感文件时建议先通过其他安全渠道确认接收方身份。公司内网若对安全有严格要求应结合网络隔离策略控制 LocalSend 的使用范围。7. 最佳实践与工程建议7.1 个人使用建议个人使用时建议做三件事第一给设备命名。LocalSend 默认的设备名可能包含随机字符多台设备一起使用时很难分辨。在设置中改成类似“办公室-Windows”“家里-手机”的名称可以显著减少发错对象的情况。第二开启快速保存前确认目录。建议创建一个专门的LocalSend文件夹把所有接收文件统一归档避免文件散落在不同目录。第三关注版本更新。LocalSend 仍在活跃迭代中版本更新通常会带来安全修复和体验优化。建议通过官方渠道获取最新版本不要使用来源不明的安装包。7.2 团队与企业网络注意事项如果你计划在公司内部推广 LocalSend需要考虑的就不是软件本身而是网络和安全策略。与网络管理员确认路由器或交换机是否允许 UDP 广播和端口 53317 通信。如果公司网络做了严格的设备分区可以将 LocalSend 限制在办公网段内使用。禁止在公共 Wi-Fi 或不安全的访客网络中使用 LocalSend 传输敏感资料。对需要审计的业务应明确 LocalSend 不适合作为正式的办公数据交换通道因为它的传输记录和管理能力较弱。7.3 防火墙放行配置示例如果你需要在 Linux 服务器或开发机上放行 LocalSend 端口可以使用 UFW 配置sudo ufw allow 53317/tcp comment LocalSend HTTPS file transfer sudo ufw allow 53317/udp comment LocalSend device discovery如果你是安全管理员更细粒度地限制来源 IP 也是常见做法。例如只允许办公网段访问sudo ufw allow from 192.168.1.0/24 to any port 53317 proto tcp sudo ufw allow from 192.168.1.0/24 to any port 53317 proto udp这里要强调一下最小权限原则不要为了省事把端口暴露到全部网络接口。在真实生产环境中应该先确认哪些网段需要互传文件再针对性地放行。7.4 开发者如何拓展 LocalSend如果你有兴趣参与 LocalSend 的二次开发建议先读项目源码理解它的discovery和send两个核心模块。你可以基于 LocalSend 做以下拓展定制文件接收策略实现分类归档。接入公司内部的日志系统记录传输事件。修改 UI 语言或交互流程适配内部使用场景。通过脚本调用本地命令与 CI/CD 流程集成。需要注意LocalSend 的生态还处于快速发展阶段不同版本之间的 API 可能有调整。二次开发时锁定版本并针对目标版本做兼容测试是比较稳妥的做法。8. 总结与下一步这篇文章从 LocalSend 是什么开始梳理了它的安装方式、核心机制、使用流程、安全边界和排查思路。关键点可以归纳为三条第一LocalSend 是跨平台、开源、无账号体系的局域网点对点传输工具适合在可信局域网内替代微信、QQ、网盘等中转方案。第二它使用 UDP 广播完成设备发现使用 HTTPS 完成文件传输默认端口是 53317。大部分问题都可以从网络发现和防火墙规则两个方向排查。第三使用时要认识到它的安全边界它适合日常文件交换但高敏感场景仍需谨慎确认接收方身份。接下来你可以做的是在手机和电脑上各安装一个 LocalSend然后实际传一次文件观察它是否搜得到设备、传输速度如何、快速保存模式是否好用。实践一遍之后再结合这篇文章的排错章节你基本就能独立解决大多数局域网传输问题了。
局域网之间传文件最麻烦的往往不是网络本身而是绕了太多圈先通过微信或 QQ 把文件发出去再到另一台设备上登录、下载、保存图片被压缩、视频被二次转码遇到大一点的安装包还可能被提示“文件过大无法发送”。如果两台设备明明就在同一个办公室、同一个路由器下面为什么不能直接点对点传输这正是 LocalSend 这类局域网文件传输工具要解决的问题。这篇文章会围绕 LocalSend 的安装部署、核心工作原理、日常使用流程、常见问题排查以及安全边界做一次完整梳理。无论你是想在手机和电脑之间快速传图还是需要在 Windows、macOS、Linux 三套系统之间互传安装包读完这篇文章后你都可以不再依赖网盘中转也不需要注册任何账号就能完成不压缩、不走公网的局域网安全互传。1. LocalSend 是什么解决局域网传输的真正痛点1.1 从 AirDrop 说到跨平台传输用过苹果生态的人很多都习惯用 AirDrop 在 iPhone、iPad、Mac 之间传文件。它的体验非常好打开 Wi-Fi 和蓝牙选中文件点击附近设备对方点击接收文件就以点对点方式直接传过去不经过云端文件也不会被压缩。但 AirDrop 的问题也很明显它只存在于苹果生态。如果换成 Android 手机和 Windows 电脑AirDrop 就彻底失效了。传统方案要么是登录微信或 QQ要么是上传网盘再下载过程繁琐且受限于公网带宽。LocalSend 则尝试把 AirDrop 式的体验带到所有主流平台上。从专业定义上看LocalSend 是一个免费、开源、跨平台的局域网文件传输工具。它基于 Flutter 开发使用 REST API 和 HTTPS 加密通信。设备之间通过局域网LAN直接传输文件、文件夹、文本和剪贴板内容默认不依赖互联网连接也不需要外部服务器中转。1.2 与主流传输方案对比为了方便你理解 LocalSend 的定位我整理了一张常见传输方案的对比表传输方案是否依赖公网是否注册账号是否压缩文件主要局限微信 / QQ 文件传输是是是文件大小限制、压缩画质百度网盘 / OneDrive是是通常不压缩上传后再下载链路长AirDrop否否否仅限苹果生态浏览器 WebRTC 传文件视具体工具而定通常否否需要浏览器和服务端信令配合LocalSend否否否需要设备处于同一个局域网从表里可以看出LocalSend 的核心优势有三点第一不依赖公网断网环境下只要局域网通就能用第二没有账号体系不需要手机号、邮箱或第三方登录第三文件不做压缩原图、原文件直接传输。1.3 哪些场景下最推荐使用 LocalSend根据实际使用经验下面几类场景最值得引入 LocalSend开发者在开发机、测试机、服务器之间互传安装包和配置文件。办公室环境中同事之间快速交换大体积附件。在没有外网的企业内网里需要通过局域网完成文件交换。个人用户在 Windows、macOS、Android、iOS 之间互相传图传视频。活动现场、展会或临时组网环境中快速共享资料。如果你只是偶尔在微信里传一张小图片LocalSend 带来的改变可能不明显但如果你的日常工作高度依赖跨设备文件交换它能节省的时间非常可观。2. 环境准备LocalSend 全平台安装LocalSend 目前的客户端覆盖 Windows、macOS、Linux、Android、iOS 五个平台。安装方式主要分两类一类是去应用商店或 GitHub Releases 页面下载安装包另一类是通过命令行包管理器安装。下面按平台说明。2.1 Windows 安装Windows 用户有两种常用方式。第一种是直接到 GitHub Releases 页面下载安装包。在项目主页的 Releases 区域选择带有windows字样的安装包比如.exe或.msi文件下载后双击安装即可。第二种是使用 Windows 包管理器winget安装。先打开 PowerShell 或 Windows Terminal执行搜索命令winget search localsend搜索完成后会返回一个或多个结果。找到对应的包 Id 后执行安装winget install 实际查询到的包Id这里不写死具体包 Id是因为不同渠道的包名可能变化以你本机查询到的结果为准更稳妥。安装完成后可以在开始菜单中找到 LocalSend 并启动。2.2 macOS 安装macOS 用户最推荐的方式是使用 Homebrew Caskbrew install --cask localsend这条命令会自动下载最新版本并安装到 Applications 目录。如果你更习惯图形化操作也可以去 App Store 搜索 LocalSend或从 GitHub Releases 下载.dmg文件手动安装。首次打开 macOS 应用时如果系统提示“无法打开因为无法验证开发者”需要手动到“系统设置 - 隐私与安全性”中允许应用运行。这是 macOS 对未签名或未公证应用的默认保护机制不是应用本身有问题。2.3 Linux 安装Linux 的发行版较多安装方式也略有差异。这里以 Debian / Ubuntu 为例。如果你下载了.deb安装包可以使用dpkg安装sudo dpkg -i LocalSend-*.deb如果安装过程中提示缺少依赖可以再执行sudo apt-get -f install除了 deb 包LocalSend 还提供了 AppImage、Flatpak、Snap 等多种 Linux 打包格式。如果你使用 Snap可以尝试sudo snap install localsend如果你使用 Flatpak需要先在系统上配置好 Flathub 源再通过 Flatpak 安装。具体包名以 Flathub 页面上的实际名称为准。2.4 Android 与 iOS 安装Android 用户可以在 Google Play、F-Droid 或者 GitHub Releases 中下载安装。国内 Android 用户如果无法访问 Google Play可以使用 GitHub Releases 页面提供的 APK 文件安装时允许“安装未知来源应用”即可。iOS 用户直接在 App Store 搜索 LocalSend 安装。需要注意移动端 App 安装完成后首次打开时系统通常会询问“本地网络权限”。iOS 和 Android 较新版本都会对局域网通信做权限限制如果不允许 LocalSend 使用本地网络它会搜不到同一局域网内的其他设备。这一步在后面的常见问题部分还会重点提到。2.5 从源码编译面向开发者LocalSend 本身是开源项目使用 Flutter 开发。如果你有定制需求可以拉取源码自行编译。基本流程如下git clone https://github.com/localsend/localsend.git cd localsend flutter pub get flutter run -d linux执行以上命令前需要先安装 Flutter SDK并按需启用对应的桌面平台支持。比如在 Linux 桌面端运行前可能需要执行flutter config --enable-linux-desktop需要说明的是源码编译适合有 Flutter 开发经验的用户。普通使用者直接安装 Release 版本即可不需要也不建议自行编译。3. 核心原理拆解LocalSend 是怎么工作的很多教程只告诉你“怎么用”但如果你想真正排查问题就必须理解它“为什么能搜到设备”“为什么能传文件”。下面拆解 LocalSend 的三个核心机制。3.1 设备发现UDP 广播LocalSend 启动时会监听一个默认端口53317。当用户打开设备列表或点击刷新时LocalSend 会向局域网发送 UDP 广播包广播包里携带设备名称、协议版本、可用端口等信息。同一网段内其他运行 LocalSend 的设备收到广播后会把自己的设备信息回复给发送方于是两台设备的界面上就能互相看到对方。这个机制和 AirDrop 类似都是基于本地网络发现。它的优势是无需中央服务器所有设备都能自组织地出现在列表中。但它的限制也很明显UDP 广播通常只在同一个二层网络内生效。如果两个设备不在同一个网段或者路由器开启了“AP 隔离”功能设备之间就无法通过广播互相发现。下面是一个用 Python 演示“UDP 广播发现”思路的示意代码。请注意这里只是帮助理解原理并不是 LocalSend 官方协议的完整实现实际协议细节以官方源码或抓包结果为准。 演示代码向局域网发送 UDP 广播探测 LocalSend 设备。 重点在于理解“广播 - 回复”的发现机制消息字段仅为示意。 import json import socket BROADCAST_IP 255.255.255.255 PORT 53317 def discover(timeout3): # 创建 UDP socket sock socket.socket(socket.AF_INET, socket.SOCK_DGRAM) # 允许发送广播包 sock.setsockopt(socket.SOL_SOCKET, socket.SO_BROADCAST, 1) sock.settimeout(timeout) # 示意数据包实际格式请以官方协议为准 payload { deviceName: python-demo, deviceModel: PC, port: PORT, } sock.sendto(json.dumps(payload).encode(), (BROADCAST_IP, PORT)) print(已发送 UDP 广播等待设备响应 ...) while True: try: data, addr sock.recvfrom(4096) print(f收到 {addr} 的响应: {data.decode(errorsignore)}) except socket.timeout: print(广播探测结束) break if __name__ __main__: discover()这段代码的价值在于帮助你建立“局域网设备发现”的直觉。实际遇到搜不到设备的问题时首先就要检查 UDP 广播路径是否通畅。3.2 文件传输HTTP over TLS设备发现只是第一步。真正传输文件时LocalSend 使用的是 HTTP 协议并叠加 TLS 加密。也就是说发送方和接收方都会在本机启动一个 HTTPS 服务默认端口同样是53317。当发送方选中文件并点击发送时发送方会构造一个包含文件元数据的请求推送到接收方的 53317 端口。接收方用户选择“接受”或“拒绝”。如果接受接收方会从发送方下载文件数据。整个过程在局域网内点对点完成不走公网也不经过第三方服务器。为了确保传输安全LocalSend 会在本地生成 TLS 证书并使用 HTTPS 加密通道。首次连接时双方会核对证书指纹部分版本还会通过 PIN 码确认来防止中间人攻击。这里的逻辑和 SSH 首次连接时确认指纹非常相似。3.3 网络端口与防火墙规则LocalSend 默认使用的端口是53317。实际使用中你至少要保证这条规则成立UDP 53317用于设备发现广播。TCP 53317用于 HTTPS 文件传输。如果你开启了防火墙或者公司网络有统一的安全策略需要将这两个端口放行。下面以 Linux UFW 防火墙为例sudo ufw allow 53317/tcp comment LocalSend HTTPS file transfer sudo ufw allow 53317/udp comment LocalSend device discovery在 Windows 上如果首次运行时系统弹出防火墙授权窗口一定要勾选“专用网络”并允许访问。如果误点了取消后续可以到“Windows 安全中心 - 防火墙和网络保护 - 允许应用通过防火墙”中重新配置。4. 完成一次本地文件传输实战下面通过一系列具体操作从零开始走通一次 LocalSend 文件传输。4.1 传输前检查清单在正式开始之前我建议先快速检查这几点能避免后面踩坑两台设备连接的是同一个路由器或同一个局域网。两台设备都已经安装并启动 LocalSend。两台设备处于同一网段例如都是192.168.1.x。如果使用移动端确认已授予“本地网络”权限。如果设备开启了系统防火墙确认 53317 端口放行。4.2 发送文件 / 文件夹 / 文本以 Windows 和 Android 互传为例完整流程如下在两台设备上分别打开 LocalSend。确认设备列表里能看到对方的设备名。如果看不到点击刷新或稍等几秒。在发送方点击“发送文件”按钮选择要传输的文件。从设备列表中选择接收方。接收方会收到一条传输请求显示文件名、大小、发送方信息。接收方点击“接受”文件开始传输。传输完成后接收方可以在设置中指定的保存目录里找到文件。文件夹的传输操作完全一致LocalSend 会保留目录结构。文本传输则更轻量点击“发送文本”后输入内容接收方可以直接复制到剪贴板适合快速传递链接或短文本。4.3 使用二维码传输LocalSend 在每台设备的界面上都会展示一个二维码。这个二维码包含当前设备的地址、端口、设备指纹等信息。使用场景通常是这样的你在电脑上打开了 LocalSend对方用手机打开 LocalSend 后点击扫描二维码就可以直接向你的电脑发送文件。这个功能很适合会议现场或临时环境不用手工输入 IP 地址。4.4 接收模式与保存目录设置LocalSend 默认是手动接收模式每次收到传输请求都会弹窗需要用户点击“接受”才会开始接收。如果你在可信的局域网环境中使用建议开启“快速保存”模式。开启后文件会自动保存到指定目录不需要每次手动确认效率会高很多。但在公共网络或不确定对方身份的场合建议保持手动接收模式避免陌生设备给你推送文件。保存目录可以在设置中修改。Windows 和 Linux 默认一般会使用“下载”目录移动端则通常保存在应用专属目录或系统下载目录。建议在设置中固定一个专门目录方便后续查找和整理。4.5 从命令行和网络层验证连通性如果你在排查“明明能看到设备但发送失败”的问题可以回到网络层验证。假设设备 A 的 IP 是192.168.1.10设备 B 的 IP 是192.168.1.20。在设备 A 上先 ping 设备 Bping 192.168.1.20如果 ping 不通说明两台设备之间的网络路径有问题这时候需要检查网段、AP 隔离、路由器配置。如果 ping 通了再检查端口是否正常监听。在 Linux 或 macOS 上可以执行ss -tlnup | grep 53317在 Windows 上可以用netstat -ano | findstr 53317如果本机 53317 端口没有进程监听说明 LocalSend 没有正确启动或者已经被系统拦截。重新启动 LocalSend 后再检查一次。5. 常见问题与排查思路LocalSend 使用过程中最集中的问题几乎都出现在设备发现和传输超时两个方面。下面按问题现象、常见原因、解决思路的顺序整理成表。问题现象常见原因解决思路两台设备互相搜不到不在同一网段或路由器开启 AP 隔离连接同一 Wi-Fi关闭 AP 隔离能搜到设备但发送请求超时防火墙拦截 TCP 53317放行 TCP 53317 端口手机能搜到电脑电脑搜不到手机手机 App 缺少“本地网络”权限或后台被清理进入系统设置授予本地网络权限允许后台运行传输速度很慢Wi-Fi 信号弱、2.4GHz 干扰大距离路由器近一些切换到 5GHz 频段对方设备请求被自动拒绝LocalSend 接收模式设置为手动且未确认接收方点击“接受”或开启“快速保存”提示证书指纹 / PIN 码不一致设备重新安装过 LocalSend或连接异常确认接收方身份重新配对后再传输公司内网无法广播发现网络做了 VLAN 隔离、广播隔离联系网络管理员确认二三层网络互通策略下面再展开几个高频问题的排查细节。5.1 设备互搜不到这是最常见的问题。先说结论90% 以上的“互搜不到”都是因为两台设备不在同一个局域网或者网络隔离配置阻止了 UDP 广播。排查步骤可以按下面顺序来确认两台设备连接的是同一个 Wi-Fi 或有线网络。在设置里查看两台设备的 IP 网段是否一致。检查路由器后台是否开启了“AP 隔离”或“访客网络隔离”。检查两台设备是否都授予了 LocalSend 必要的网络权限。如果公司网络有 VLAN 划分确认两个设备是否被划分到不同 VLAN。5.2 能搜到对方但发送超时设备能被搜到说明 UDP 广播路径是通的。发送超时则大概率是 TCP 53317 端口被拦截或接收方没有正常监听。处理思路在接收方设备上确认 LocalSend 正在前台运行。检查接收方防火墙是否放行 TCP 53317。尝试发送小文件判断是否与文件大小有关。如果发送方和接收方系统时间偏差很大也可能导致 TLS 校验失败建议校准时间。5.3 移动端被系统清理后台Android 和 iOS 对后台进程都有严格限制。LocalSend 如果被系统清理就无法继续监听端口自然收不到文件。解决方法是Android在系统设置中允许 LocalSend 后台运行关闭电池优化。iOS在 App 切换器中保留 LocalSend并允许后台刷新。传输大文件时尽量保持 LocalSend 在前台运行。6. 安全与隐私边界LocalSend 适合传什么不适合传什么LocalSend 的宣传点之一是“文件不经过云端”这一点确实能避免很多隐私风险。但我还是建议你对它的安全边界有一个更清醒的认识。6.1 LocalSend 能做什么LocalSend 在传输层使用了 TLS 加密。也就是说文件在局域网内传输时数据内容是加密的旁观者无法直接看到明文内容。同时由于没有账号体系它不会把你的手机号、邮箱、设备通讯录等个人信息上传到任何服务器。从隐私角度看LocalSend 的“本地传输”设计比“云盘转存”更安全因为它不创造额外的数据副本。6.2 LocalSend 不能做什么需要明确的是TLS 加密解决的是“传输过程中被窃听”的问题并不能解决“接收方本身就是恶意设备”的问题。如果把文件发送给一个陌生设备对方依然能查看文件内容。另外LocalSend 的自签名证书机制决定了它不依赖公共 CA 体系。为了防止中间人攻击配对时核对 PIN 码和证书指纹非常重要。如果忽略这些提示理论上存在被中间人劫持的风险。所以我的建议是只在可信局域网中使用 LocalSend。不要接收来自完全陌生设备的传输请求。涉及高敏感文件时建议先通过其他安全渠道确认接收方身份。公司内网若对安全有严格要求应结合网络隔离策略控制 LocalSend 的使用范围。7. 最佳实践与工程建议7.1 个人使用建议个人使用时建议做三件事第一给设备命名。LocalSend 默认的设备名可能包含随机字符多台设备一起使用时很难分辨。在设置中改成类似“办公室-Windows”“家里-手机”的名称可以显著减少发错对象的情况。第二开启快速保存前确认目录。建议创建一个专门的LocalSend文件夹把所有接收文件统一归档避免文件散落在不同目录。第三关注版本更新。LocalSend 仍在活跃迭代中版本更新通常会带来安全修复和体验优化。建议通过官方渠道获取最新版本不要使用来源不明的安装包。7.2 团队与企业网络注意事项如果你计划在公司内部推广 LocalSend需要考虑的就不是软件本身而是网络和安全策略。与网络管理员确认路由器或交换机是否允许 UDP 广播和端口 53317 通信。如果公司网络做了严格的设备分区可以将 LocalSend 限制在办公网段内使用。禁止在公共 Wi-Fi 或不安全的访客网络中使用 LocalSend 传输敏感资料。对需要审计的业务应明确 LocalSend 不适合作为正式的办公数据交换通道因为它的传输记录和管理能力较弱。7.3 防火墙放行配置示例如果你需要在 Linux 服务器或开发机上放行 LocalSend 端口可以使用 UFW 配置sudo ufw allow 53317/tcp comment LocalSend HTTPS file transfer sudo ufw allow 53317/udp comment LocalSend device discovery如果你是安全管理员更细粒度地限制来源 IP 也是常见做法。例如只允许办公网段访问sudo ufw allow from 192.168.1.0/24 to any port 53317 proto tcp sudo ufw allow from 192.168.1.0/24 to any port 53317 proto udp这里要强调一下最小权限原则不要为了省事把端口暴露到全部网络接口。在真实生产环境中应该先确认哪些网段需要互传文件再针对性地放行。7.4 开发者如何拓展 LocalSend如果你有兴趣参与 LocalSend 的二次开发建议先读项目源码理解它的discovery和send两个核心模块。你可以基于 LocalSend 做以下拓展定制文件接收策略实现分类归档。接入公司内部的日志系统记录传输事件。修改 UI 语言或交互流程适配内部使用场景。通过脚本调用本地命令与 CI/CD 流程集成。需要注意LocalSend 的生态还处于快速发展阶段不同版本之间的 API 可能有调整。二次开发时锁定版本并针对目标版本做兼容测试是比较稳妥的做法。8. 总结与下一步这篇文章从 LocalSend 是什么开始梳理了它的安装方式、核心机制、使用流程、安全边界和排查思路。关键点可以归纳为三条第一LocalSend 是跨平台、开源、无账号体系的局域网点对点传输工具适合在可信局域网内替代微信、QQ、网盘等中转方案。第二它使用 UDP 广播完成设备发现使用 HTTPS 完成文件传输默认端口是 53317。大部分问题都可以从网络发现和防火墙规则两个方向排查。第三使用时要认识到它的安全边界它适合日常文件交换但高敏感场景仍需谨慎确认接收方身份。接下来你可以做的是在手机和电脑上各安装一个 LocalSend然后实际传一次文件观察它是否搜得到设备、传输速度如何、快速保存模式是否好用。实践一遍之后再结合这篇文章的排错章节你基本就能独立解决大多数局域网传输问题了。
