1. LocalSend 的基本盘它到底在传什么、怎么传群里有位做运维的老哥前几天问我统信 UOS 上有没有那种“不用登录、不用扫码、不经过任何服务器”的传文件工具。他手上的场景挺典型一台 UOS 台式机在办公室内网一台 Windows 笔记本在会议室还有一部安卓手机揣兜里三台机器之间来回复制一堆日志和截图用即时通讯软件传会压缩、用网盘传要等同步、用数据线又要插拔。我直接让他装 LocalSend十分钟后他回消息说“这玩意儿早该用了”。LocalSend 是一款开源的局域网直传工具走的是设备之间点对点通信的路子不依赖互联网也不需要注册账号。它覆盖了 Windows、macOS、Linux、Android、iOS 这些主流平台在统信 UOS 这种 Debian 系的国产系统上跑起来也没有太大障碍。很多人对它的第一印象停留在“传文件”实际上它内部把文件、文本消息、剪贴板内容都当成了一等公民来处理这才是它在 UOS 上值得深挖的地方。1.1 一次传输在网络上究竟发生了什么要玩转一个工具最好先搞清楚它在网络上做了什么动作。LocalSend 的通信分成两个阶段理解这两步后面排查问题时你就知道该往哪儿看。第一个阶段是设备发现走的是 UDP。每台运行 LocalSend 的设备都会在固定端口 53317 上周期性地发出组播公告包包里带着自己的设备名、设备类型、协议版本、端口号这些元信息。同一网段里的其他设备一边监听这个端口一边回自己的公告。所以“搜不到设备”这个问题本质上绝大多数时候就是这些 UDP 包没走到对面去。第二个阶段是实际传输走的是 HTTPS。发现对方之后发送方会向接收方发起一个注册请求走的是 HTTP 协议里的注册接口拿到对方的设备信息。真正开始传的时候双方会协商出一个会话 ID 和一个临时令牌数据通过 HTTPS 上传接口一块一块地推过去。注意这里是 HTTPS 而不是 HTTP用的是自签名证书所以第一次用浏览器直接访问对方端口时会看到证书警告这是正常的。这个架构带来一个很实在的好处没有中间服务器没有云端留痕。你传的东西从头到尾只在你自己的局域网里跑断网了照样能用。我经常在客户现场那种完全没有外网的环境下用这套东西搬文件比 U 盘靠谱得多。1.2 为什么它在统信 UOS 上的体验和其他平台不太一样同样是 LocalSend在 UOS 上使用会碰到几个平台特有的情况提前知道能省不少时间。UOS 默认桌面环境是 DDE基于 Linux 桌面体系。这带来两个直接影响一是托盘图标的支持依赖libayatana-appindicator3这类库如果装的包缺依赖程序能打开但托盘图标不显示很多人会误以为程序没启动二是 UOS 上经常同时存在物理网卡、虚拟网卡比如装过虚拟机或者容器工具后多出来的docker0、virbr0组播包往外发的时候可能挑错了网卡结果就是“两台机器明明在同一个交换机下就是互相看不见”。另外一个差异点是文件权限和中文文件名。UOS 默认用 UTF-8中文文件名基本不会乱码但如果接收目录设在 NTFS 或者 exFAT 的移动硬盘上某些特殊字符还是可能出问题。我踩过一次坑传一个名字里带英文冒号的文件接收端直接写入失败日志里才看到是文件系统不支持这个字符。这几点在后面排查章节还会展开先在这里埋个引子。2. 在统信 UOS 上把它装稳安装方式选型与首屏设置安装这一步很多人觉得没什么好讲的下载、双击、下一步完事。但在 UOS 上安装方式的选择直接决定了后面能不能用得顺手。选错了可能出现托盘不显示、桌面图标点了没反应、系统更新后程序打不开等一系列问题。2.1 deb 包、AppImage、Flatpak 三种方式的取舍LocalSend 官方在 Linux 上主要提供 deb 包和 AppImage 两种部分发行版仓库里也有 Flatpak 版本。这三种在 UOS 上的表现差别挺大我把实际对比整理成表安装方式优点缺点适合谁deb 包集成度最高桌面菜单、托盘图标、文件关联都正常依赖包版本有要求UOS 版本偏老时可能装不上长期在固定机器上用的人AppImage免安装放到任意目录就能跑不污染系统需要libfuse2不方便自动启动管理临时用、或者没 root 权限的人Flatpak沙箱隔离升级方便沙箱限制网络和目录访问必须在设置里放行熟悉 Flatpak 工作流的人我个人在 UOS 上更推荐deb 包优先AppImage 兜底。理由很直接deb 装完之后你可以在开始菜单里搜到它可以配置开机自启托盘图标也能正常常驻这些在多设备联动的场景下都是刚需。如果 deb 装的时候提示依赖缺失先别急着强行--force-depends正确的做法是把缺的依赖补上常见的就是那个 appindicator 库和基础的图形库。AppImage 的用法就一句话给它加上可执行权限然后直接运行。chmod x LocalSend-*.AppImage ./LocalSend-*.AppImage如果提示缺少libfuse.so.2装一下libfuse2就行。实在装不了还有个老办法用--appimage-extract把内容解包出来再跑。2.2 首次启动必须改掉的几个默认项装好之后别急着传文件先花两分钟把设置里的几个默认项过一遍这几项直接影响后面的使用体验和安全边界。第一项是设备名。默认名称通常是“LocalSend on 主机名”的格式如果你手上有三四台设备名字又都差不多接收的时候很容易点错。建议改成能一眼认出来的名字比如把机器用途和位置带上像“办公室-UOS-主机”这种。第二项是接收模式。一般有“关闭”“接收”“接收并自动保存”三档。默认是“接收”也就是每次有人发东西过来都要你点确认。这个默认值是合理的别为了省一次点击就改成自动保存。第三项是保存目录。默认会存到一个通用下载目录里时间长了会堆一堆杂七杂八的文件。建议单独建一个目录比如~/LocalSend后面做脚本自动化处理的时候监听这个目录会比监听整个下载目录干净得多。第四项是启动行为。是否随系统启动、是否最小化到托盘这两个选项决定你平时是不是“随时能被别人发现”。如果你希望手机随时能往电脑上丢东西就打开自动启动并最小化到托盘。2.3 端口、防火墙与多网卡UOS 上最容易翻车的地方这一节是全文最值得划重点的部分我在不同机器上踩过的坑基本都集中在这里。先说端口。LocalSend 的发现和传输都围绕53317这个端口展开UDP 用来做设备发现TCP 用来做实际传输。UOS 默认状态下不一定开着防火墙但如果你装了安全管控类软件或者自己开过 ufw就需要把 53317 的 TCP 和 UDP 都放行。用 ufw 的话是这样sudo ufw allow 53317/tcp sudo ufw allow 53317/udp sudo ufw status再说多网卡。这是 UOS 上最高频的翻车点。用ip addr看一眼就知道自己有没有这个问题如果除了enp*或者wlan*之外还冒出来docker0、virbr0、vmnet1这些那就有概率组播包走错网卡。表现出来的现象是手机能搜到电脑电脑搜不到手机或者反过来。解决办法有两个层面。简单层面直接在界面里用手动添加设备的方式输入对方的 IP 加端口绕过自动发现192.168.1.37:53317彻底一点的做法是确认默认路由走的是哪张网卡ip route show default如果默认路由不是你想要的那张物理网卡说明路由表有问题那就得从网络配置层面调整了这个属于系统网络管理范畴不建议为了一个传文件工具去动。最后提醒一个容易被忽略的点有些企业级无线网络开启了终端隔离也就是同一个 WiFi 下的设备互相不能直接通信。这种情况下无论怎么配都搜不到只能改用有线或者手机开热点、电脑连热点的方式来绕开。判断方法很简单用ping对方 IP如果 ping 不通那就是网络策略问题跟工具无关。3. 隐藏玩法一把文本和剪贴板当成一等公民用大部分人打开 LocalSend 就是拖文件其实界面上那个“消息”标签被严重低估了。文本传输配上一点脚本能让 UOS 和手机之间形成一种接近“跨设备剪贴板”的体验。这一节我把几种用法从简单到复杂捋一遍。3.1 消息面板不只是“发句话”消息面板的本质是把一段文本当作一个数据包发出去接收端收到后可以选择复制到剪贴板或者存成文件。这个能力在实际工作里能解决不少麻烦事。举几个我真实在用的场景。在 UOS 上调试一段命令想把命令原样挪到另一台机器的终端里跑直接把命令贴到消息面板发过去对方一键复制比手打或者拍照识别准得多。再比如在手机上看到一篇长文的某个段落想存到电脑上继续整理选中之后发过来就是纯文本不会像某些工具那样带一堆样式标签。这里有个实操细节值得注意单条消息有长度上限具体数值会随版本变化但经验值是几千字符量级。如果你要传的是一整份配置文件或者长文档别硬塞进消息里直接发.txt文件更稳妥接收端存下来还能保留完整格式。我在传一段很长的 JSON 时吃过亏粘贴进去发送按钮是灰的当时还以为程序卡了后来才发现是长度超了。另一个细节是换行和缩进会不会丢。实测下来纯文本的换行是保留的但如果你的内容里有制表符缩进某些接收端在复制到剪贴板时可能会被规范化。传代码片段的话建议还是走文件通道。3.2 用一条脚本把 UOS 剪贴板和手机连起来LocalSend 官方并没有内置双向的剪贴板自动同步功能网上有些说法容易让人误解以为打开某个开关就能实现实际上并没有。但用“文本消息 目录监听 剪贴板命令”这三样东西拼一下能做出一个相当好用的近似方案。先说 UOS 这边读剪贴板的命令。X11 环境下用xclipWayland 环境下换成wl-clipboard里的wl-paste。UOS 的 DDE 桌面目前主要跑在 X11 上所以xclip基本够用sudo apt install xclip inotify-tools第一步把自己剪贴板里的内容导出去方便走 LocalSend 发送#!/bin/bash # clip-out.sh —— 把当前剪贴板内容导出成一个带时间戳的文本文件 outdir$HOME/LocalSend/outbox mkdir -p $outdir out$outdir/clip-$(date %Y%m%d-%H%M%S).txt xclip -selection clipboard -o $out 2/dev/null || wl-paste $out echo 已导出$out把它存成clip-out.sh加到可执行权限然后绑一个快捷键比如我绑的是CtrlAltC。按一下剪贴板内容就变成一个 txt 文件躺在待发目录里打开 LocalSend 拖过去或者配合后面的自动化直接发走。第二步反过来把手机发过来的文本自动写进 UOS 的剪贴板。这一步用inotifywait监听接收目录#!/bin/bash # clip-in.sh —— 监听接收目录把新到的 txt 内容写进剪贴板 watchdir$HOME/LocalSend/inbox mkdir -p $watchdir inotifywait -m -e close_write --format %w%f $watchdir | while read -r f; do case $f in *.txt) xclip -selection clipboard -i $f notify-send 剪贴板已更新 $(basename $f) ;; esac donenotify-send那行的作用是弹一个系统通知让你知道剪贴板已经换内容了不然你可能会粘贴出上一次的旧内容莫名其妙。这个脚本可以加到开机自启里命令写成bash ~/scripts/clip-in.sh就行。3.3 这套剪贴板方案的边界在哪里得把话说清楚这套方案不是真正的剪贴板同步它是半自动的。区别在哪真正的剪贴板同步是你在一台设备上按CtrlC另一台设备上直接CtrlV就能用。我们这套方案中间隔了一个“文件落地 脚本写入”的环节需要你手动触发发送动作。它不适合的场景也很明确。第一二进制内容的剪贴板比如复制的图片、复制的文件对象xclip取出来的东西方向不对这套方案搞不定。第二高频次的剪贴板操作比如你在两台机器之间来回搬十几个小片段每次都要触发一次发送效率反而不如直接把内容攒成一份文件发过去。第三敏感内容剪贴板里经常会有密码、令牌这类东西如果你的接收目录是共享的或者开了自动保存这些内容就落盘了这是实打实的风险点。我个人用下来这套方案最适合的场景是“一天之内偶尔跨设备搬三到五次文本”比如从手机抄一段验证码到电脑、把电脑上的一条命令挪到另一台机器。频率再高就该考虑别的方案了。4. 隐藏玩法二多设备联动的三种实用阵型单独用 LocalSend 传个文件价值有限。真正让它变得好用的是把设备组织起来形成固定的协作阵型。这一节分享三种我实际用过的配置。4.1 固定收件站让 UOS 机器当“中转仓”最常见的阵型是固定一台 UOS 机器当收件站其他设备都往它这儿发。手机拍的照片、平板上画的草稿、另一台电脑上导出的报表统一发到这台机器上再由它做后续处理。要让这个阵型稳定运转有几个设置必须做对。接收模式改成“接收”保留确认这一步保存目录固定到~/LocalSend/inbox方便后面用脚本处理打开开机自启和最小化到托盘然后给这台机器起一个特别好认的名字比如“收件站-01”。名字这一点看着不起眼但当你有五六台设备的时候能省下大量点错的时间。如果这台机器的接收目录本身又是团队共享的还可以叠加一层把它挂到文件共享里或者用同步工具往外分发。这样 LocalSend 负责“进”文件共享负责“出”各司其职。4.2 把它变成命令行里的收发工具LocalSend 除了图形界面还有一套可编程的接口。它的传输协议是公开的走的是标准的 HTTP 语义懂得用curl就能做不少自动化。一个最基础的用法是探测对方设备信息curl -k https://192.168.1.37:53317/api/localsend/v2/info-k这个参数是必须的因为对方用的是自签名证书不加-k会直接报证书校验失败。再进一步官方也提供了命令行版本可以在没有图形界面的机器上跑比如一台只有 ssh 的服务器或者容器里。这种模式适合做“定时把某目录的内容推给指定设备”这类任务。写自动化脚本的时候有两点要注意一是接口路径和字段可能随版本变化动手之前先看一眼你装的这个版本对应的协议文档二是别把令牌之类的信息硬编码进脚本提交到代码仓库里用环境变量传。说句实在话纯命令行方案的学习成本不低如果你只是偶尔传文件用图形界面就够了。但如果你的场景是“每天固定时间把日志打包发走”这种重复劳动花一个下午把脚本写出来长期回报是划算的。4.3 临时共享盘团队内小范围分发还有一种用法是用在临时场合。比如几个人在同一个会议室要把演示文稿、素材包发给所有人又不想一个个用即时通讯软件点对点发。做法是让其中一台机器开着接收其他人依次发过去或者反过来一个人往几个设备同时发。LocalSend 支持一次选多台接收目标实测下来三到五台设备同时收是没有问题的。这个场景下网速是瓶颈如果大家都在同一个 WiFi 下传大文件2.4G 频段的体验会明显不如 5G 频段。这个阵型的注意事项是收完就关。会议结束之后记得把接收模式切回“关闭”不然下次你在别的网络环境下程序还在那儿开着接收虽然每次都要确认但总归是个不必要的暴露面。5. 翻车现场实录常见问题与排查顺序前面讲的是怎么用这一节讲坏掉了怎么办。我把这几年碰到的问题归了归类按排查顺序整理出来照着走基本能定位到原因。5.1 搜不到设备按这五步查这个问题占了所有求助的八成以上。别乱试按顺序来。第一步确认是不是同一个网段。两台设备的 IP 前三段是否一致子网掩码是不是都是255.255.255.0。有些网络里不同楼层的机器看着连的是同一个 WiFi 名字实际上是不同的 VLAN那必然搜不到。第二步ping 一下。能搜到设备名但传不了文件和压根搜不到设备是两个不同的问题。搜不到的时候先ping对方 IPping 不通就说明是网络层的问题跟工具无关。第三步检查是不是同一个网络里有多台设备重名。这个坑不常见但确实有两台设备都叫默认名字列表里看起来像只有一个。第四步查多网卡。回到 2.3 节说的用ip addr看有没有虚拟网卡用ip route show default看默认路由走哪张。第五步用 IP 直连。手动添加IP:53317绕过自动发现。如果手动添加能连上但自动搜不到那基本可以确定是 UDP 发现这一环被拦了重点查防火墙和无线网络的终端隔离设置。5.2 传一半断了、速度上不去传输过程中的问题相对好定位原因无非这么几个我整理成表方便对照现象可能原因排查动作传到一半直接失败发送方或接收方进入了休眠关掉系统的自动休眠或插上电源速度只有几百 KB/s走的是 2.4G 频段或者信号弱切到 5G 频段靠近路由器小文件很快大文件很慢接收端磁盘写入慢换到 UOS 本地磁盘目录别存到移动硬盘传输过程中进度条卡住不动网络出现瞬时中断看系统日志里的网络事件偶发失败重试就好了无线信道拥堵换个信道或者改用有线这里面我觉得最值得单独说的是休眠问题。UOS 默认的电源策略在空闲一段时间后会挂起网络或者进入睡眠传输大文件的时候如果正好赶上连接就断了。传大文件之前我一般会临时把电源设置调成“从不休眠”传完再改回来。5.3 安全和隐私上需要注意的几件事最后聊几句安全。LocalSend 走的是局域网直连没有云端参与这本身就是一层保护但也不是完全无懈可击。第一别长期开着“自动保存”。这个选项省的是每次点确认的功夫代价是同一网段里任何人发东西过来都会直接落盘。在办公室这种相对可信的环境里偶尔开开还行在咖啡馆、酒店这类地方一定要关。第二接收确认这一步别关。它的意义是让你有机会看一眼发送方是谁、要发什么。这个环节是唯一的人工闸门关掉之后就是完全敞开的状态。第三证书警告别忽略背后的含义。自签名证书是设计如此但这也意味着你没法通过证书链验证对方身份。所以在同一网段里有陌生设备的时候收到传输请求要看清楚设备名再决定接不接。第四剪贴板方案要注意落盘。回到第 3 节那套脚本如果你把剪贴板内容导成了 txt 放在共享目录里那密码之类的信息就等于明文存硬盘了。我的做法是给这类临时文件加个定时清理或者干脆在导出前手动确认一下内容。提示如果你的使用场景涉及敏感数据最稳妥的做法是把 LocalSend 的接收模式保持在“关闭”需要传的时候临时打开传完立刻关掉别图省事长期挂着。我在几台不同配置的 UOS 机器上用 LocalSend 用了挺长时间最大的体会是这个工具的价值不在于它能传文件而在于它把“跨设备的临时搬运”这件事的成本压到了极低。一个快捷键导出剪贴板、一个目录监听自动写入、一台固定机器当收件站这三样东西组合起来慢慢就成了我日常工作流里默认的一部分。前面那套剪贴板脚本我改过三四版最早的版本没加notify-send结果好几次粘出来的是上一轮的内容排查了半天才发现是脚本没覆盖到加个通知之后这类乌龙就再没出现过。
