跨设备传文件：LocalSend 与 Syncthing，两种完全不同的思路

一句话总结：LocalSend 解决「现在把这个文件从这台设备送到那台」，靠局域网多播发现加 HTTPS 直传，不装账号不联网；Syncthing 解决「这些文件在两台设备上永远保持一致」，靠 P2P 持续同步。这篇把两者的原理、端口、排查方法和选型讲清，附一个用 cuRL 直接调 LocalSend 协议的自动化玩法。

先说痛点。iPhone 传 Windows、安卓传 Mac、手机照片传到 Linux 笔记本——这件事在 2026 年依然没有一个所有平台都服的方案。网盘中转要联网还要限速，微信传会压图，数据线插上还得折腾驱动。

LocalSend 干的就是这件事，Apache 2.0，GitHub 上九万四千多星，v1.18.2 是今年 8 月的版本。

原理：多播喊一嗓子，然后点对点传

它没有服务器，设备靠局域网多播互相发现。

启动时会往组播地址 224.0.0.167 的 53317 端口发一个 UDP 包，内容是自己的别名、设备类型、端口、指纹，还有 announce: true。同一网段里其他 LocalSend 听到之后，直接向它发 HTTP 请求登记（POST /API/localsend/v2/register）。

为什么用 224.0.0.0/24 这个段？协议文档里解释了：有些安卓设备会拒收其他组播组。这种细节只有踩过才写得出来。

传输走 HTTPS，每台设备用运行时生成的自签证书做 TLS。

实际传输是四个动作：

1. prepare-upload：发送方只发元数据（文件名、大小、MIME、可选哈希），接收方决定全收、部分收还是拒收
2. 返回 Token：接收方给每个接受的文件发一个令牌，带 sessionId
3. upload：发送方按令牌逐个上传字节流，多文件可以并行
4. 校验：哈希对不上就拒收

PIN 码是在第一步校验的（?pin= 参数）。指纹是设备互相识别的依据——开加密时它是 TLS 证书的 SHA-256，关加密时是一串随机值。

这套设计的巧妙之处在于只有一个方向需要开服务器：接收方当 server，发送方当 client。所以哪怕某台设备的网络不允许它监听端口，它照样能当发送方。

装与通

Windows 用 winget，macOS 用 brew，Linux 用 flatpak，手机上从商店或 F-Droid 装：

winget install LocalSend.LocalSend
brew install --cask localsend
flatpak install flathub org.localsend.localsend_app

装完两台设备打开就能互相看见，前提是同网段且防火墙放行 53317 的 TCP 和 UDP。

连不上先查三件事，按命中率排：

1. 防火墙。Windows 第一次运行会弹窗，手快点掉「允许」就会一直连不上。手动加规则：TCP 和 UDP 的 53317 都要。
2. 路由器的 AP 隔离（客户端隔离）。酒店、公司、咖啡馆的 Wi-Fi 常开这个，设备之间完全不可见。换一个网络或者开热点。
3. 多播被丢。有些企业网络禁多播。LocalSend 有个「legacy 模式」的兜底：把注册请求发给子网内每个 IP，慢一点、吵一点，但能通。

还有一个隐蔽情况：跨 VLAN。你有线连一个网段、手机连另一个网段，虽然都能上网，但多播出不了网关，互相看不见。这种只能手动填 IP，或者干脆用后面的 Syncthing。

用 curl 直接对话

协议是公开的 REST 接口，意味着不装 GUI 也能传。分享链接那条路是给浏览器用的（明文 HTTP，因为浏览器拒绝自签证书），要走加密就用 App 之间。

脚本化更省事的是官方新加的 CLI：

# 查看附近设备
localsend-cli discover

# 发文件给指定设备（设备名或指纹）
localsend-cli send --file D:/backup/photos.zip --to "Nice Orange"

这个能力比想象中有用：定时把服务器日志打包发到工作站、CI 跑完把产物推到测试机，都可以用几行脚本搞定，比配 SSH 简单。

Syncthing：换一个问题的答案

LocalSend 传完就结束了，没有「状态」。如果你的需求是「这几台设备上的这个文件夹永远一致」，那它不对口。

Syncthing 是持续同步：MPL-2.0 协议，P2P，设备之间用证书指纹互相认证（每个设备有个 Device ID）。它不依赖同一个局域网——局域网点对点直连，跨网络走中继（relay）。

默认端口：

用起来是三步：装好 → 打开 http://127.0.0.1:8384 → 两边互加 Device ID，然后共享文件夹。

它的代价要提前说清：

• 需要常驻运行。它是后台服务，不是用完就关的工具
• 冲突处理要理解。两边同时改同一个文件会生成 .sync-conflict 副本，不会自动合并
• 不适合大文件一次性搬运。同步是增量的，第一次同步一个 50GB 目录会很慢

怎么选

我自己是两个都装着：日常传文件用 LocalSend，几个固定目录（笔记、素材库）用 Syncthing 后台同步。它们不冲突。

图 1：左为 LocalSend 的一次性直传，右为 Syncthing 的持续双向同步

坑清单

坑一：防火墙只放了 TCP。 发现走多播 UDP，传输走 TCP，两个都要开。只开 TCP 的表现是「完全看不到设备」。

坑二：以为开了 VPN 也能传。 VPN 常把流量路由改掉，多播直接失效，设备互相看不见。传输时把 VPN 关掉，或者把本地网段加到分流规则里。

坑三：用浏览器的分享链接传敏感文件。 App 对 App 是双向 TLS 加密，但浏览器的分享页走的是明文 HTTP（浏览器不信任自签证书）。同一台路由器下的公用电脑临时收个文件还行，合同、证件这类别走这条路。

坑四：Syncthing 同步了不该同步的目录。 比如把 node_modules、.git、虚拟机镜像整个同步过去，CPU 和带宽全废。用 .stignore 排除，或者只同步明确的子目录。

坑五：把 Syncthing 当备份。 它不是备份工具。误删文件会同步删除到所有设备，只保留一个可配置的版本历史（默认关闭）。要备份另找工具。

边界

这两个都是局域网/点对点工具，适合个人和小团队。它们不解决「跨公网给客户传 20GB 素材」这类需求，那需要对象存储或专门的大文件服务。

另外提醒一句：LocalSend 的发现是广播式的，同网段内所有人都能看到你的设备名。在公司或咖啡馆把设备名改成不暴露身份的名字，是个低成本习惯。

FAQ

需要联网吗？

LocalSend 完全不需要，断网也能传。Syncthing 在局域网内不需要外网，跨网络同步才需要中继或公网直连。

传输速度有多快？

跑满局域网带宽，千兆网络下大文件能到 100MB/s 以上。瓶颈通常是 Wi-Fi 而不是软件。

iOS 能用吗？

能，iOS 13 起支持，从 App Store 装。注意从其他 App 分享到 LocalSend 需要 iOS 14 以上。

数据会不会经过第三方？

LocalSend 不会，设备直连。Syncthing 默认走设备直连，直连失败时才经由社区中继，中继内容是加密的。

两个工具能一起用吗？

能，它们不冲突。一个按需传，一个常驻同步。

结语

这两个工具真正的区别不在功能，在你问的问题：LocalSend 回答「这个文件怎么过去」，Syncthing 回答「这些文件怎么一直一样」。

先想清楚你问的是哪个，再选工具。选错了会觉得都难用。

参考资料

• LocalSend 官方仓库 - Apache 2.0，Flutter + Rust 实现
• LocalSend Protocol v2.2 - 多播发现与上传流程的完整定义
• Syncthing 文档 - 端口、设备 ID 与中继机制
• 本站 Windows 装机工具清单 - 同类效率工具的搭配建议