LanSplice v2.1.0 局域网传文件：配对、命令行与连通性排查

原创于 2026-11-09 12:24:46 发布 · 1k 阅读

本内容遵循CC 4.0 BY-SA版权协议

本文详解LanSplice v2.1.0在Windows与Linux间实现局域网文件传输的核心流程，涵盖设备配对认证、命令行发送/接收、端口连通性排查（UDP 47821发现 vs TCP 47820传输）、跨平台安装差异（Windows单文件EXE vs Linux Python依赖）、接收校验机制、退出码语义及群发验收要点，强调避免以ping或设备列表代替实际端口可达性验证。

LanSplice v2.1.0 局域网传文件：配对、命令行与连通性排查

LanSplice 可以在同一路由器、同一网段的设备之间直接传送文件和目录。Windows 图形界面适合临时发送，Linux 的 serve、send 和 devices 则便于接入终端工作流。配置时应把“发现设备”“建立传输”“落盘校验”拆开判断，避免只凭设备列表或 ping 结果定位问题。

下面以 Windows 与 Linux 互传为主，说明当前发行的文件选择、首次连接以及结果检查。v2.1.0 增加的多设备发送仍然逐台执行；不同平台的安装与常驻行为也有区别，不能把 Windows 的操作全部平移到 Linux。

环境与发行文件

Windows 使用 LanSplice-v2.1.0.exe。这是一个 32 位单文件构建，适用于 Windows 10 的 32/64 位系统及 Windows 11，不需另外安装 Python。Windows 8.1 没有官方实测保证，Windows 7 不受支持。不要因为运行在 64 位系统，就另找发行清单里并不存在的 x64 附件。

Linux 使用 LanSplice-2.1.0-linux-kit.tar.gz。完整包保留安装脚本、程序模块和依赖材料，安装前需有 Python 3.7 或以上版本。随包的离线加密依赖针对 UOS 20、Python 3.7、x86_64；其他 Python 或 CPU 组合要准备匹配的 cryptography，不能混用这套二进制依赖。

这次发行还包含 Android 1.9.2 APK，手机端版本号没有随桌面版一起改成 2.1.0。macOS 有源码与打包说明，但本次没有 macOS 成品发行附件，且项目未完成 Mac 真机验证。混合设备部署时，Mac 的源码运行与本地打包需要单独验证，不能直接使用 Windows 附件。

Linux 工具包解压后，安装入口为：

sudo sh install.sh
lansplice version

第二条用于检查命令入口与版本。安装后当前终端若找不到命令，先新开终端检查 PATH；不要把终端没有找到入口，直接判断成图形界面或网络传输损坏。

第一次连接：先接收，再对齐配对码

Linux 端准备一个实际用户可写的接收目录，然后启动接收：

lansplice serve --root /home/yourname/Downloads/LanSplice

其中 /home/yourname 要替换成接收账号的真实家目录。接收端会显示配对码，把它填入 Windows 的对应入口；也可以反过来统一为 Windows 已有的码。两端必须一致，IP 连通不能代替配对认证。

Windows 两端互传时，各自打开 EXE，完成联网与防火墙提示，再复制配对码到另一台，重新查找设备。首页的“保存到”是本机接收位置，发送前需分别确认两台机器的配置，别把发送端的目录当成接收端的目的地。

v2.1.0 的设备列表与清单

图中的设备选择、待发清单和发送按钮分别对应目标、输入与执行动作。

图形界面可以拖入文件夹，也可以复制文件后 Ctrl+V 加入清单。加入后检查文件和目标，再点击发送。第一次建议发送含子目录的小样本，随后到接收端查看目录结构、文件名和打开结果，确认这条路径符合后续任务。

用命令行发送与读取结果

已确认对端地址后，Linux 发送单个文件或目录的写法如下，地址需换成对端当前局域网 IP：

lansplice send /data/report.xlsx --to 192.168.1.20
lansplice send /data/materials --to 192.168.1.20 --verify
lansplice devices

--to 指定接收端，默认传输端口是 47820。配对码已保存时可使用现有配置；临时使用 --code 时，应传入双方实际约定的码。devices 负责发现设备，不是发送命令，也不能证明目标接收目录具备写权限。

--verify 会在传后让两端整文件重读进行校验，适合需要补充确认磁盘读写结果的任务。它会增加读取与等待时间，不宜用打开校验后的耗时去和未校验传输作简单速度比较。

普通发送默认不覆盖冲突文件，同名、同大小、同修改时间的文件会跳过，其他名称冲突采用带编号名称保存。只有明确需要替换目标内容时，才考虑 --overwrite。把覆盖选项设成所有任务的默认习惯，容易失去普通发送原本保留旧副本的好处。

自动化脚本要读取退出码：0 表示全部成功，也包括已经存在而跳过的文件；1 表示部分失败，适合检查后续传或重试；2 表示传输没有开始，例如地址不可达或配对码不对。后者需要先修条件，重复运行相同错误配置不会让任务自行成功。

接收端还提供 serve --once，适合收完一批后结束的流程：接收到内容退出码为零，没有收到则为一。它与发送端的退出码含义分开，脚本不要把同一数字一概解释为同一结果。需要限制等待时可使用接收端的超时参数；一次性接收和长期等待也应按任务选择。检查收件用户、目录写入权限以及实际收到的批次后，再判断是否启动下一步处理。

找不到设备，不等于传输端口一定不通

电脑广播发现使用 UDP 47821，电脑间文件传输使用 TCP 47820。先检查对端是否仍运行 GUI 或 serve，再核实地址、子网与相关防火墙规则。如果设备没有被广播找到，但已知真实地址，可以进一步检查单播传输路径，而不是只盯着设备列表。

路由器的无线客户端隔离也会影响设备互访。两台电脑都能浏览网页，并不说明它们之间允许互相连接。多网卡环境还要确认当前使用的是实际局域网地址，没有把虚拟网络地址当成对端地址。

网络体检窗口参考

v2.0.1 体检窗口示例，地址和检测数字用于展示布局；v2.1.0 的操作应以当前界面为准。

体检入口会提供网卡、网关、端口和对端状态线索。项目在 v2.0.1 已修正“ping 不通就认定不在线”的判断：ICMP 可能被阻止，而实际传输端口仍然可达。排查时把两种证据分开，优先查看应用端口的实际结果。

Linux 防火墙与桌面行为也要单独处理。按当前系统和软件提示核查传输及发现规则，不套用 Windows 一键放行的结果。Linux 关闭窗口会退出，若需要长期接收，应采用无界面的 serve 并安排适当的常驻方式。配置服务时使用真实接收用户，否则配置、配对码和接收目录可能落到 root 的环境里。