全球主机交流论坛

标题: locsend.com真离线跨设备端对端传输,支持200条离线消息 [打印本页]

作者: mimiphp 时间: 2026-1-8 14:40
标题: locsend.com真离线跨设备端对端传输,支持200条离线消息
本帖最后由 mimiphp 于 2026-2-4 22:19 编辑

LocSend · 真离线无服务器传输·跨设备传输 | file 本地启动 · 手动信令 · 数据不经服务器

v1.01:优化下载流程，取消保存文件步骤。locsend只负责直连传输，后续保存文件逻辑交给浏览器默认动作。所有浏览器体验一致！离线版请重新下载使用

欢迎大家免费使用
什么是信令？
信令是指在浏览器 WebRTC 协议下，通过点对点 (P2P) 方式传输的地址信息。离线版本需要手动交换信令；在线版本则通过服务器自动交换信令，服务器不参与数据传输。

离线版本还需要其他软件来交换信号，那它的意义何在？
LocSend 离线版专为追求极致安全性和隐私保护的用户而设计。与其他将数据提交服务器（存在隐私风险并限制文件大小）的即时通讯和文件传输软件不同，此离线版牺牲了便捷性，让用户自行交换信号。它实现了真正的无服务器本地运行 HTML 文件，确保了安全性和可靠性！

必须在同一局域网吗？
LocSend IPv4 环境在没有公网 IP 地址的情况下仅支持局域网，而 IPv6 支持公网网络连接。P2P 可实现直接的点对点连接，无需任何中继流量，从而确保隐私、安全和可靠性。

单个文件大小有限制吗？
文件大小没有限制，但部分浏览器不支持在传输前选择保存位置，会自动默认使用内存传输，这会占用大量设备内存。对于大于 2GB 的文件，我们建议使用 Edge 或 Chrome 等原生浏览器，它们完全支持选择保存位置。此时，传输速度仅受网络连接、CPU 性能和两台设备的磁盘写入速度的限制。

移动端可以锁屏后台传输吗？
部分移动系统在后台会限制网络与 JS 计时器，建议传输时保持前台亮屏，或使用桌面端浏览器。

在线版为什么不支持局域网自动发现，而需要填写房间号？
在纯浏览器模式下，局域网自动发现完全依赖于服务器通过公网 IP 地址来识别设备。这使得任何人都可以加入大型局域网环境，例如校园网、NAT 共享网络或公司网络，从而带来安全风险。Locsend 无需在同一局域网内传输。它支持在没有公网 IPv4 或有公网 IPv6 的环境中直接连接。因此，通过使用临时房间 ID 和密码，您可以自信地搭建自己的私有传输环境，确保传输安全！

在线版房间号是固定的吗，有效期是多久？
在线免费版临时房间号有效期为24小时，可提前注销房间号。超过24小时房间号会自动销毁。

离线版本即使是同一个电脑的两个浏览器，也可能不稳定断开链接？

你用的是真·离线版本，注意这个【真】字。

真离线版没有任何服务器参与，信令需要双方手动互填，连接建立后也没有自动重连机制。

所谓 P2P 直连，是浏览器基于 WebRTC 协议生成双方的连接地址（ICE 候选），

即使是在同一台电脑、两个浏览器，也会当成两个独立节点来建立直连通道，稳定性完全取决于本机网络、系统和浏览器状态。

因此真离线版如果出现一分钟左右断开、卡顿等情况，通常不是程序错误，而是 WebRTC 在无服务器兜底情况下的正常表现。

解决办法只有两个：

1️⃣ 刷新页面，重新互填信令再试一次

2️⃣ 使用在线版本 —— 在线版支持掉线自动重连，稳定性会明显更好

真离线版追求的是零服务器、零依赖、绝对隐私，而不是连接稳定性，这一点需要理解。

reishi 发表于 2026-1-10 00:22
赞一个，点对点速度很快，希望可以向网盘方向开发一点，类似mega.nz那样，既能解决用户也能解决糊口的问题 ...

多谢反馈！
网盘模式和基于 WebRTC 的端对端加密传输，其实是两个安全模型完全相反的方向。
WebRTC 的设计目标是：
数据通道不经过服务器，浏览器之间直接建立加密连接。
在 IPv4 同一局域网环境下，数据甚至不会出公网，
也就不存在任何第三方审查、限速或留存的可能。
WebRTC 中服务器的作用，仅限于协助交换连接信息（信令）。
如果你使用 LocSend 的在线版本，服务器只负责自动交换信令，
一旦连接建立，数据传输实际上就是你两台设备、两个浏览器之间的直连通信。
因此你会感觉传输速度很快——
这既是 WebRTC 直连的优势，也和对大文件传输过程做的一些优化有关。
许多示例型或玩具项目并没有针对大文件做完整的数据流控制和传输策略，自然体验会差很多。
LocSend 是一个持续维护的商业项目，而不是一次性的实验代码，因此在设计之初就明确了这一定位。
至于网盘模式，本质上是：
客户端 → 服务器 → 客户端。
文件一旦上传到服务器，就已经不再是端到端传输，
隐私性、审查、大小限制、带宽限制都会随之而来。
比如微信文件传输，本质上也是网盘模式：
文件先上传到服务器，再由对方下载。
所以 LocSend 不会走网盘路线，请理解这一点。
这并不是谁更好，而是解决的问题完全不同。

jason 发表于 2026-1-10 18:17
提个建议
离线版信令太长了
反正是局域网用，自定义信令就可以了，比如是123短一些 ...

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

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

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

QQ群：709193338

官网地址：locsend.com

作者: mimiphp 时间: 2026-1-8 16:55
yywfsky 发表于 2026-1-8 16:41
赞一个，离线版非常好用。能否提供在线版的源码啊？只是问问

多谢，你是我收到的第一个赞。
你也看到右上角，我有自愿打赏需求了。。。
我是一个被优化辞退的程序员，目前没有稳定收入，一直想自己赚点钱稳定生活。
一开始我发布的作品都是基于同行程序员使用的，开源就被白**。甚至粉刺挖苦。
locsend.com算是我转型的项目，面向普通用户，反而得到被认可的机会大得多。

所以我已经不打算再走开源路线。实际上我自己认为有了AI加持，只会让程序员之间的差距越来越大。但大多数人会认为不用写代码AI就可以帮你全部弄好。实际上这误区很大了。因为我们这种老程序员只是利用AI辅助处理代码编写，审计代码漏洞。但整体代码逻辑还是要自己把控的。。。因为新手程序员估计连如何提问的关键词都构造不出来，也就是基础知识原理都不懂，你都不知道如何提问。。。。

因此，在AI时代，你可以尝试和AI合作自己弄一个。。这是我的心血，所以不再开源了。特别是大陆不遵守开源协议的大环境下，白**，抄袭无法避免，已经寒心了。请谅解~

作者: imok 时间: 2026-1-9 00:35
传输速度挺快但是都局域网了干嘛还得输入设置房间id 还得设置pin 还得设置昵称太麻烦了

直接查到局域网ip 就可以啊

作者: DataCenter 时间: 2026-1-9 01:14
技术功底不错啊

作者: ABCFUN 时间: 2026-1-9 03:43
不错，赞一个

作者: mimiphp 时间: 2026-1-9 04:20
本帖最后由 mimiphp 于 2026-1-9 04:21 编辑

在线版为什么不支持局域网自动发现，而需要填写房间号？
在纯浏览器模式下，局域网自动发现完全依赖于服务器通过公网 IP 地址来识别设备。这使得任何人都可以加入大型局域网环境，例如校园网、NAT 共享网络或公司网络，从而带来安全风险。Locsend 无需在同一局域网内传输。它支持在没有公网 IPv4 或有公网 IPv6 的环境中直接连接。因此，通过使用临时房间 ID 和密码，您可以自信地搭建自己的私有传输环境，确保传输安全！

作者: mimiphp 时间: 2026-1-9 04:21

imok 发表于 2026-1-9 00:35
传输速度挺快但是都局域网了干嘛还得输入设置房间id 还得设置pin 还得设置昵称太麻烦了

直接查到局 ...

在线版为什么不支持局域网自动发现，而需要填写房间号？
在纯浏览器模式下，局域网自动发现完全依赖于服务器通过公网 IP 地址来识别设备。这使得任何人都可以加入大型局域网环境，例如校园网、NAT 共享网络或公司网络，从而带来安全风险。Locsend 无需在同一局域网内传输。它支持在没有公网 IPv4 或有公网 IPv6 的环境中直接连接。因此，通过使用临时房间 ID 和密码，您可以自信地搭建自己的私有传输环境，确保传输安全！

作者: 234 时间: 2026-1-9 05:10
支持，有空了试试

作者: 大爷 时间: 2026-1-9 09:17
不错，好的产品，有空试试

作者: jpfree 时间: 2026-1-9 09:20
P2P不一定快，会被运营商QOS吗？

作者: mimiphp 时间: 2026-1-9 09:26
本帖最后由 mimiphp 于 2026-1-9 09:27 编辑

双方在同一个局域网

使用内网 IPv4（192.168.x / 10.x / 172.16.x）

WebRTC 直接走内网 TCP / UDP

特点

不经过运营商公网

不经过 NAT / 路由器外网
不可能被运营商 QoS

速度只取决于：网卡、交换机、Wi-Fi 质量

这和拷贝局域网文件、NAS 传输是一个级别

双方都有公网 IPv6

WebRTC 直接使用 IPv6 地址建立连接

没有 TURN 中转、没有服务器转发

特点

会经过运营商网络（这是公网）

但只是普通点对点流量

没有“P2P 特征服务器”

没有“中心节点可被针对”

和 scp / sftp / https 下载在运营商眼里几乎没区别

结论：不会被“额外针对 QoS”

运营商最多只会做全用户统一限速策略，不会识别你这是 LocSend / WebRTC / P2P 工具

作者: mimiphp 时间: 2026-1-9 09:28

jpfree 发表于 2026-1-9 09:20
P2P不一定快，会被运营商QOS吗？

双方在同一个局域网

使用内网 IPv4（192.168.x / 10.x / 172.16.x）

WebRTC 直接走内网 TCP / UDP

特点

不经过运营商公网

不经过 NAT / 路由器外网
不可能被运营商 QoS

速度只取决于：网卡、交换机、Wi-Fi 质量

这和拷贝局域网文件、NAS 传输是一个级别

双方都有公网 IPv6

WebRTC 直接使用 IPv6 地址建立连接

没有 TURN 中转、没有服务器转发

特点

会经过运营商网络（这是公网）

但只是普通点对点流量

没有“P2P 特征服务器”

没有“中心节点可被针对”

和 scp / sftp / https 下载在运营商眼里几乎没区别

结论：不会被“额外针对 QoS”

运营商最多只会做全用户统一限速策略，不会识别你这是 LocSend / WebRTC / P2P 工具

作者: mslxd 时间: 2026-1-9 09:34
支持技术贴，开源吗？

作者: mimiphp 时间: 2026-1-9 09:48

mslxd 发表于 2026-1-9 09:34
支持技术贴，开源吗？

我是一个被优化辞退的程序员，目前没有稳定收入，一直想自己赚点钱稳定生活。
一开始我发布的作品都是基于同行程序员使用的，开源就被白**。甚至粉刺挖苦。
locsend.com算是我转型的项目，面向普通用户，反而得到被认可的机会大得多。

所以我已经不打算再走开源路线。实际上我自己认为有了AI加持，只会让程序员之间的差距越来越大。但大多数人会认为不用写代码AI就可以帮你全部弄好。实际上这误区很大了。因为我们这种老程序员只是利用AI辅助处理代码编写，审计代码漏洞。但整体代码逻辑还是要自己把控的。。。因为新手程序员估计连如何提问的关键词都构造不出来，也就是基础知识原理都不懂，你都不知道如何提问。。。。

因此，在AI时代，你可以尝试和AI合作自己弄一个。。这是我的心血，所以不再开源了。特别是大陆不遵守开源协议的大环境下，白**，抄袭无法避免，已经寒心了。请谅解~

但都是免费使用，没有任何收费

作者: williamc2 时间: 2026-1-9 15:59
谢谢大佬

作者: jamesbond 时间: 2026-1-9 16:15
可以啊，大佬牛逼

作者: Sine6 时间: 2026-1-9 17:13
试了一下还挺好用的，理解不开源，希望能够长期稳下去或者留个备份站。

作者: vmvps 时间: 2026-1-9 17:49
nice，又多了一个跨平台互传的选择

作者: mimiphp 时间: 2026-1-10 02:17
reishi 发表于 2026-1-10 00:22
赞一个，点对点速度很快，希望可以向网盘方向开发一点，类似mega.nz那样，既能解决用户也能解决糊口的问题 ...

多谢反馈！
网盘模式和基于 WebRTC 的端对端加密传输，其实是两个安全模型完全相反的方向。
WebRTC 的设计目标是：
数据通道不经过服务器，浏览器之间直接建立加密连接。
在 IPv4 同一局域网环境下，数据甚至不会出公网，
也就不存在任何第三方审查、限速或留存的可能。
WebRTC 中服务器的作用，仅限于协助交换连接信息（信令）。
如果你使用 LocSend 的在线版本，服务器只负责自动交换信令，
一旦连接建立，数据传输实际上就是你两台设备、两个浏览器之间的直连通信。
因此你会感觉传输速度很快——
这既是 WebRTC 直连的优势，也和对大文件传输过程做的一些优化有关。
许多示例型或玩具项目并没有针对大文件做完整的数据流控制和传输策略，自然体验会差很多。
LocSend 是一个持续维护的商业项目，而不是一次性的实验代码，因此在设计之初就明确了这一定位。
至于网盘模式，本质上是：
客户端 → 服务器 → 客户端。
文件一旦上传到服务器，就已经不再是端到端传输，
隐私性、审查、大小限制、带宽限制都会随之而来。
比如微信文件传输，本质上也是网盘模式：
文件先上传到服务器，再由对方下载。
所以 LocSend 不会走网盘路线，请理解这一点。
这并不是谁更好，而是解决的问题完全不同。

作者: dole 时间: 2026-1-10 02:38
支持开发者

作者: mimiphp 时间: 2026-1-10 09:06
抱歉：2026年1月10日 9:00之前的离线版本请重新下载，已修正掉线问题

作者: NodeLoc 时间: 2026-1-10 10:20
和rsync比有啥优势？

作者: mimiphp 时间: 2026-1-10 11:19

NodeLoc 发表于 2026-1-10 10:20
和rsync比有啥优势？

浏览器用的，主要用在手机与电脑传输数据，又不想泄露隐私的场景

作者: 电光 时间: 2026-1-10 11:33
免费开源的localsend就挺好用的。https://localsend.org/

作者: mimiphp 时间: 2026-1-10 11:43

电光发表于 2026-1-10 11:33
免费开源的localsend就挺好用的。https://localsend.org/

域名比他短，优势在我 locsend.com

作者: tboy 时间: 2026-1-10 11:49
信令太麻烦了感觉局域网6位数的口令就够了

作者: mimiphp 时间: 2026-1-10 11:52

tboy 发表于 2026-1-10 11:49
信令太麻烦了感觉局域网6位数的口令就够了

信令离线版才需要关心，在线版只填写房间号，密码，昵称就行了！24小时有效，无需再次输入，刷新浏览器也会自动重连

作者: mimiphp 时间: 2026-1-10 19:38
jason 发表于 2026-1-10 18:17
提个建议
离线版信令太长了
反正是局域网用，自定义信令就可以了，比如是123短一些 ...

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

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

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

作者: 气味 时间: 2026-1-10 19:43
听起来很NB的样子

作者: bbsbbs 时间: 2026-1-10 19:54
不错，支持一下

作者: SO2 时间: 2026-1-10 19:59
WebRTC放局域网就是画蛇添足，放公网那么双方都得有公网IP，NAT后面就必须要有TUN服务器，
所以用来传文件非常鸡肋，用来聊聊天、搞搞短信息传递还可以。
可以看看以下开源项目
https://github.com/MatrixSeven/file-transfer-go

作者: cloverzrg 时间: 2026-1-10 20:00
网站打不开

作者: mimiphp 时间: 2026-1-10 20:10

cloverzrg 发表于 2026-1-10 20:00
网站打不开

locsend.com 截个图我看看。。。应该能打开的啊

作者: mimiphp 时间: 2026-1-10 20:20
本帖最后由 mimiphp 于 2026-1-10 20:27 编辑

SO2 发表于 2026-1-10 19:59
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 不适合长期存储和大规模分发，但在临时、安全、无需服务器中转的文件传输场景中，它并不鸡肋，反而是非常高效且隐私友好的方案。

作者: mimiphp 时间: 2026-1-11 09:06
本帖最后由 mimiphp 于 2026-1-11 09:07 编辑

新增：未链接可发送200条离线消息，连接后双方整合同步

作者: mimiphp 时间: 2026-2-4 22:19
v1.01:优化下载流程，取消保存文件步骤。locsend只负责直连传输，后续保存文件逻辑交给浏览器默认动作。所有浏览器体验一致！离线版请重新下载使用

作者: 小怪 时间: 2026-2-5 13:09
加密了JS呀

作者: mimiphp 时间: 2026-2-5 16:28

小怪发表于 2026-2-5 13:09
加密了JS呀

官网已有解答。不开源是防止改名党，修改个名称就说是自己原创的，我是独立开发者。并准备注册公司，商业运作，所以代码严谨性比一般开源软件要负责，你可以自己体验传输速度区别。以及在线版sse服务稳定性区别！当然，你一定要破解也并不难，前端js本身就不是真正加密，而且混淆而已！但同样免费提供给你用，不用特别在意一定要开源才敢使用@否则你大多数公司化运行的app，软件，都应该删除了

作者: floe 时间: 2026-2-10 23:29
这个能做成在线客服吗？

作者: mimiphp 时间: 2026-2-11 00:45
本帖最后由 mimiphp 于 2026-2-11 00:56 编辑

floe 发表于 2026-2-10 23:29
这个能做成在线客服吗？

当然可以，但是侧重点不一样，在线客服是即时聊天，而不是文件传输！并且在线客服不强调隐私保护，而是客人与企业之间的咨询信息，所以一般都是走客户端到服务端，服务端储存聊天记录的模式！而webrtc就是去中心化的p2p，只要链接成功，任何第三方，包括服务器方也无法解密！属于一对一直连加密聊天！目前我正在本地做视频会议中！

作者: floe 时间: 2026-2-11 15:51
要能加一个在线客服模式很爽了。

作者: mimiphp 时间: 2026-2-12 19:52

floe 发表于 2026-2-11 15:51
要能加一个在线客服模式很爽了。

没问题，那就弄一个出来，到时候提供集成到你们网站的教程

作者: floe 时间: 2026-2-12 21:37

mimiphp 发表于 2026-2-12 19:52
没问题，那就弄一个出来，到时候提供集成到你们网站的教程

感谢啊。

作者: mimiphp 时间: 2026-2-12 21:49

floe 发表于 2026-2-12 21:37
感谢啊。

那我这里还是给你讨论一下。基于webrtc是端对端传输的。也就是双方都是对等的P2P浏览器客户端。建立连接后就没有服务器参与了。但这就带来一个问题：由于你是1对多关系，就已经算是即时聊天软件了，而不是我主打的1对1文字和文件发送了。所以需要维护一个好友列表，即使是临时对话，也需要维护一个类似好友的列表。
这是需要服务器来参与维护的。本来我是计划启用locmsg.com 或者 locppt.com 来弄真正的基于webrtc的及时聊天软件的。既然你提出来要在线客服系统。那么，我可能会启用另外一个独立域名来做这个事情。因为与1v1发送文件为主要目标的locsend就不太合适了。

作者: floe 时间: 2026-2-12 21:52

mimiphp 发表于 2026-2-12 21:49
那我这里还是给你讨论一下。基于webrtc是端对端传输的。也就是双方都是对等的P2P浏览器客户端。建立连接 ...

独立域名是没有问题。比如客户点击进入聊天自动创建个独立的通道与客服链接上就可以的当然每个客户都需要独立的聊天不是群聊方式。

作者: mimiphp 时间: 2026-2-12 22:08

floe 发表于 2026-2-12 21:52
独立域名是没有问题。比如客户点击进入聊天自动创建个独立的通道与客服链接上就可以的当然每个客户都需 ...

是的。为了不影响论坛其他人的正常看帖，不再占用公共资源，你可以加我的locsned官方QQ**流：709193338

但我这里可以简单给你讲解一下原理。你作为官方客服人员，但其实也是一个对等的浏览器客户端。这与传统的聊天软件区别很大。也就是说，你1v2,1v3没问题，但1v10以上就不能无脑建立连接了。因为你只是个浏览器，而不是传统的服务器接收消息，然后转发给你的模式。。所以这时就需要改变策略。比如你正在跟一个人建立了webrtc通道沟通中，这时有其他人也要跟你沟通，就只能在其他人的浏览器缓存消息，不能无脑与你建立webrtc通道。这时服务器参与进来只能提示你的浏览器有新消息。你需要退出当前的webrtc通道，点开好友列表，才能与新的人建立webrtc通道，等你们重新建立了webrtc通道后，对方提前发送的消息才会推送给你的浏览器。。。这就存在几个问题，如果你响应很慢，对方关闭了浏览器，这个提前发送的消息，其实还在对方浏览器中，对方已经走了，你再打开他的好友列表，也无法与他建立连接了。所以你也看不到消息了。明白了吗？这与传统及时聊天，服务器接收消息，转发消息区别很大。因为webrtc是双方本地加密消息，只有建立成功的双方浏览器才能解密。服务器也无能为力。但如果不遵循webrtc协议，直接走websocket或者sse，服务器都已经把消息存入数据库了。当然你任何时候想看，都可以推送给你的。。。。但这就不是P2P加密传输了。因为服务器已经存入数据库，服务器方是可以看到你的消息的。。。。所以传统客服系统或者及时聊天软件，都没有采用webrtc，原理就在这里。。。webrtc并不适合离线消息，而是必须保证双方都已经建立连接后时时发送消息。。。所以可以理解为就是对讲机，而不是传统离线消息推送。。。。

作者: lnx 时间: 2026-2-12 23:00
加入局域网直接发现，类似 https://web.localsend.org/

作者: mimiphp 时间: 2026-2-12 23:01

lnx 发表于 2026-2-12 23:00
加入局域网直接发现，类似 https://web.localsend.org/

在线版为什么不支持局域网自动发现，而需要填写房间号？
在纯浏览器模式下，局域网自动发现完全依赖于服务器通过公网 IP 地址来识别设备。这使得任何人都可以加入大型局域网环境，例如校园网、NAT 共享网络或公司网络，从而带来安全风险。Locsend 支持在没有公网 IPv4 或有公网 IPv6 的环境中直接连接。因此，通过使用临时房间 ID 和密码，您可以自信地搭建自己的私有传输环境，确保传输安全！

第一次建立链接需要输入房间号，密码，昵称，之后24小时内有效，刷新浏览器也会自动重连，不用再输入任何信息！

作者: 游歌 时间: 2026-2-13 02:16
牛

欢迎光临全球主机交流论坛 (https://loc.528866.xyz/)