如果你在意隐私、速度和掌控感，那你需要认识一下 LocSend。

发现频道
1

在云盘横行的时代，文件传输似乎只剩下一种选择：
上传到服务器 → 等待 → 对方下载 → 数据永久留在云端。

但 LocSend 选择了一条完全不同的路。

:rocket: LocSend 是什么？

LocSend 是一款基于 WebRTC 的 端到端（P2P）文件与消息传输工具，
支持 IPv4 局域网 / IPv6 公网直连，数据不经过服务器、不落盘、不留存。

你可以把它理解为：

:backhand_index_pointing_right: 一个真正「只在你和对方设备之间传输数据」的工具

:locked: 真·离线版本：没有服务器，才叫真正安全

LocSend 提供了一个极其少见的形态：

  • :white_check_mark: 单个 HTML 文件
  • :white_check_mark: file:// 本地直接打开
  • :white_check_mark: 无需 HTTP / HTTPS
  • :white_check_mark: 无需后端服务
  • :white_check_mark: 无需注册、无需登录

双方只需手动交换一次 WebRTC 信令，就能建立加密直连通道。
文件从你的设备，直接到对方设备，中间没有任何第三方。

这不是“服务器转发得很快”，
而是 服务器根本不存在。

:high_voltage: 速度取决于你的网络，而不是平台限速

LocSend 的传输速度，只由三件事决定：

  • 你的网络（Wi-Fi / 有线 / IPv6）
  • 你的设备性能
  • 对方设备性能

在同一局域网内，它和拷贝 NAS、局域网共享文件是一个速度级别；
在 IPv6 公网环境下，它依然是 浏览器到浏览器的直连通信，
不会被当作“网盘流量”限速。

:mobile_phone: 手机、电脑都能用，而且不用装 App

LocSend 是纯浏览器方案：

  • Windows / macOS / Linux
  • Android / iOS
  • Chrome / Edge / Firefox / Safari

手机端甚至可以借助 微信、QQ 等内置浏览器后台运行，
数据依然是 WebRTC 直连，不经过任何平台服务器。

:globe_with_meridians: 在线版：更省事，但依然不碰你的数据

如果你不想手动交换信令，
LocSend 也提供了 在线版：

  • :high_voltage: 打开网页即可使用
  • :high_voltage: 服务器只负责交换信令
  • :high_voltage: 文件数据仍然不经过服务器

房间号临时有效，24 小时内自动重连，
兼顾了 便利性与安全性。

:cross_mark: LocSend 不做什么？

为了把事情说清楚，有些路 LocSend 明确不会走：

  • :cross_mark: 不做网盘
  • :cross_mark: 不存储用户文件
  • :cross_mark: 不扫描、不分析、不留存数据
  • :cross_mark: 不靠“隐私换便利”

LocSend 解决的是 “如何在不信任云的前提下，把文件安全地传过去”，
而不是“如何管理你的文件资产”。

:brain: 这是一个怎样的项目？

LocSend 是一个长期维护的商业级项目，
不是 Demo、不是玩具代码、也不是一次性实验。

它从一开始就围绕：

  • 真实大文件传输
  • 稳定的数据流控制
  • 浏览器底层能力
  • 现实网络环境

进行设计和优化。

:compass: 适合谁？

如果你符合下面任意一条，LocSend 都值得你试试：

  • 在意隐私，不想把文件交给云端
  • 需要在局域网或 IPv6 环境下高速传文件
  • 想要一个“随时可用、不依赖服务”的工具
  • 不喜欢安装一堆客户端

LocSend 不试图取代所有传输工具，
它只专注把一件事做到极致：

让文件，从你的设备，直接到对方的设备。

官网与离线版下载：
:backhand_index_pointing_right: https://locsend.com

如果你正在寻找一种更“干净”的传输方式，
LocSend 已经准备好了。

1
11920×2033 90.7 KB

3 个赞
发现频道近10日热门排行榜[2026年2期]
4

双重否定…… :thinking:

5 个赞
6

那这个工具怎么盈利呢

7

用了一段时间，体验很好

8

能坚持住就好。这类应用看过太多了，撑下来的不多。
另外：
建议房主如果是pc进入的话，最好能给一个手机直接登录的二维码。

1 个赞
9

相同疑问？

10

本地版没有连接成功过，如果可以应该很方便，建议整pgp端到端加密

11

都可以不用服务器，没有成本压力， 不一定非要盈利吧。应该是作者自己有需求， 实现了之后分享。再说有流量了后面做其他也好推广。

12

认真根据官网指导，已经很多人都在用了。如果实在认为有BUG,可以加入官方网站底部提供的反馈BUG途径

13

locsend.com不会考虑盈利，我是独立开发者，已经解答过很多问题，最早推广不在本社区。

如有正面反馈问题的，可以把典型问题收录在官网下面问答板块。

但不会走开源路线，原因也已经在官网解答了。

我的另外一个作品 wnmp.org ，是服务器部署用的。所以没有面向普通人推广。

后续还会制作更多作品。本人已经是20多年经验的老程序员，现已被优化辞退。但反而有时间来制作我自己的生态圈。本人全栈程序员，核心底层架构基于自己开发的lowphp框架。因此官网就是 lowphp.com，但还没有正式上线。

14

二维码方案没办法提供，这个问题也已经解答：

提个建议
离线版信令太长了
反正是局域网用，自定义信令就可以了，比如是123短一些 …

WebRTC 的信令看起来很长，是因为它不是聊天内容，而是一份“建立直连所需的连接说明书”。里面包含加密指纹、协议协商信息，以及多条网络候选路线（局域网、公网 IPv6、NAT 映射等），用来确保在不同 Wi-Fi/公司网/校园网/热点环境下也能更高概率一次打通。连接建立后，文件传输走端到端加密的点对点通道，不再依赖这段信令，也不会经过服务器

WebRTC 是浏览器底层C语言编写的，locsend只能通过js启动API，但不能自定义操作底层逻辑。你可以这样理解，整个JS脚本语言，只是浏览器底层API的启动器。浏览器底层开放了哪些API，JS才能调用哪些API**。**底层不开放的能力，JS 是无权干预的。

这也是整个webRTC安全得以保障的关键所在。类似COOKIE服务器设置httponly后,浏览器底层自动携带与服务器传递COOKIE。js脚本语言是无权干预的。这样就比大多数前端开发人员习惯的localstorage安全得多了。

总结就是：信令由浏览器底层生成，信令字符串过长，生成二维码基本无法正常扫码。而且离线版是file://本地运行，没有办法调用摄像头API。顶多只能打开相册识别本地图片，反而不方便。

离线版已提供 :sig.locsend.com 来交换信令。。

同样你也可以采用其他软件来交换信令。任意方式都行。。

如果不是最求极致隐私保护，对官方在线版有一定的信任感，建议直接采用在线版。

在IPV6在移动网络大量普及的当今。两台手机就是随时随地直连的。真正做到的去中心化发送消息和文件。

15

本机A开两个网页成功过一次， 另外两台B和C:

A和B连接， B作为加入方应用对端信令提示:

locsend.html:750 
 InvalidStateError: Failed to execute 'setRemoteDescription' on 'RTCPeerConnection': The RTCPeerConnection's signalingState is 'closed'.
    at Proxy.applyRemoteSignal (locsend.html:763:731761)
    at Proxy.remote (locsend.html:763:742836)
    at tW (locsend.html:750:20215)
    at tK (locsend.html:750:20283)
    at HTMLButtonElement.n (locsend.html:751:52352)
(匿名)	@	locsend.html:750
tz	@	locsend.html:750
(匿名)	@	locsend.html:750
Promise.catch		
tK	@	locsend.html:750
n	@	locsend.html:751

A和C连接， 发起方A最后一步应用对端信令时， 提示

[webrtc] 
Object
 当前浏览器支持 WebRTC ✅
locsend.html:763 [SIG] createOffer...
locsend.html:763 [ICE] gatheringState=gathering
locsend.html:763 [ICE] gatheringState=complete
2
locsend.html:763 [SIG] applyRemote type=answer
locsend.html:750 
 InvalidStateError: Failed to execute 'setRemoteDescription' on 'RTCPeerConnection': Failed to set remote answer sdp: Called in wrong state: stable
(匿名)	@	locsend.html:750
tz	@	locsend.html:750
(匿名)	@	locsend.html:750
Promise.catch		
tK	@	locsend.html:750
n	@	locsend.html:751
16

你用的是英文版本，需要理解的是另外一个解答：

WebRTC放局域网就是画蛇添足，放公网那么双方都得有公网IP，NAT后面就必须要有TUN服务器，
所以用来传文件 …

locsend 已经提供真离线版,下载html，本地桌面双击运行。本地 HTML 文件,file 直接打开,真正无后端服务。
无公网环境，都是使用STUN,但不是TURN。。。
而STUN,的地址列表：stun:stun.l.google.com:19302
stun:stun1.l.google.com:19302
stun:stun2.l.google.com:19302
stun:stun3.l.google.com:19302
stun:stun4.l.google.com:19302
stun:stun.cloudflare.com:3478
stun:stun.qq.com:3478
stun:stun.aliyun.com:3478
stun:stun.huawei.com:3478

都是大型机构提供的公开服务，类似公共DNS一样的服务。

总结：WebRTC 并不是为“聊天”单独设计的协议，而是一套通用的端到端实时数据通道。它从设计之初就是为了解决 NAT、跨网络、跨平台直连问题，而不是假设双方都有公网 IP。
在大多数家庭宽带、手机网络、IPv6 环境下，STUN 就可以完成打洞，TURN 只是极端场景下的兜底方案。
WebRTC 不适合长期存储和大规模分发，但在临时、安全、无需服务器中转的文件传输场景中，它并不鸡肋，反而是非常高效且隐私友好的方案。

补充解答：由于即使是离线版file://文件开头，你也要理解这是个传输工具，所以不能同一个浏览器两个tab来测试。同时浏览器底层会请求stun:stun1.l.google.com:19302。。英文版本肯定在大陆无法正常使用。因此建议使用中文版本的离线版，会请求：stun:stun.aliyun.com:3478

当然，你完全可以先用在线版测试通信是否正常，再考虑重新测试离线版

17

这段 AI 回答术语齐全、段落完整，但没有解决问题。如果要回答，就请对问题负责。

18

这不是AI解答的。这是我手写的。不要误解。我已经建议你先用在线版本测试你的网络环境是否能正常通信，再反馈离线版的BUG。你需要按照我说的步骤测试一次，证实在线版本正常，就只有离线版本不正常，我才能定位问题所在。

19

https://www.locsend.com/offline.mp4 专门为你录制了一个视频教程。请参考

20

局域网 手机和电脑连接成功,文本消息发送成功 传送文件保存后 文件大小是0

21

官网已经提供视频教程，并且你文件传输完毕会有文字提示。

大型文件，传输完毕后会有一个硬盘写入的过程。这个过程不论是手机还是电脑，都需要耐心等待。你可以尝试先传送1M-100M之间的小型文件，测试看看文件大小是否正常。然后再尝试传输1GB以上的大文件，耐心等待看看最终的尺寸是否正常。这个过程在手机端可以下拉刷新你的文件目录，可以看到尺寸变动的。而win系统，会看到一个.crswap的临时文件，一定要耐心等待这个临时文件消失后，才能正常打开你传输的文件。这些都是浏览器底层逻辑。我们只能适应这个过程。请认真查看视频教程的后半部分的演示!