局域网内手机电脑大文件互传方案：基于Nginx与分片上传的浏览器直传实践

前阵子在某公司的全内网环境做支持A同事抱着一块移动硬盘来回跑往几台电脑上拷同一个50GB的虚拟机镜像。我问为什么不直接走局域网传他说微信传不了这么大、网盘又依赖外网最后只能U盘接力。那一刻我就意识到很多人缺的其实不是某个传文件的小工具而是一整套能落地、能长期用的“内网手机电脑文件互传和聊天”基础设施——手机和电脑在同一个Wi-Fi下浏览器扫码就能互传50GB的文件传完还能顺手发条消息确认一下到没到。这篇文章我会把整体方案、核心原理、部署步骤、踩过的坑和实测数据一次写清楚适合运维、开发、实验室和宿舍党直接抄作业。1. 为什么微信网盘U盘都不香内网直传的真实场景1.1 三个每天都在发生的传文件痛点先说最常见的场景。某公司的办公网是物理隔离的没有外网出口A同事需要把一个大文件同步给另外三台电脑。传统做法是拿U盘挨个插一遍50GB的镜像遇到USB 2.0的口拷一次半小时起四个人轮一遍小半天就没了。第二个场景是家庭内网。客厅的电脑下载了一部蓝光原盘40多GB想躺在床上用手机看。用微信传到手机别说40GB超过2GB微信根本不让传。传到网盘再下回来更离谱——文件先在客厅上传到云端再通过同一个路由器下载回手机数据绕了一大圈家里外网带宽只有几十兆一来一回可能得折腾一整晚。第三个场景是实验室或者工作室。几个人共用一个千兆交换机数据集动辄几十GB需要频繁同步给不同的测试设备。手机、Windows笔记本、MacBook混着来每个设备都要能传能收还不能要求所有人都装同一个客户端。这三种场景其实指向同一个需求在同一局域网内任意一台手机或电脑只要能开浏览器就能把大文件发给另一台设备并且双端都能看到传输状态和确认消息。1.2 传统方案的缺陷逐个拆我把周围人最常用的几种方案挨个试过一遍问题非常明显。微信/QQ文件传输助手限制多超过一定体积直接拒绝传图片会被压缩接收端必须登录同一个账号在纯内网环境里微信本身就可能连不上服务。网盘中转依赖外网带宽内网没有外网时彻底失效即使有外网上传下载两次走公网延迟和速度都很离谱有些网盘对大文件还有单文件大小限制。SMB共享/FTP这个方案很接近正确答案但手机端要装第三方文件管理器或者手动输入IP地址、账号密码大文件断点续传支持参差不齐目录权限配置对小白来说不友好容易把整个盘都暴露出去。U盘/移动硬盘物理介质有瓶颈接口速率、文件系统格式都有限制如果有三台设备要拷效率极低还要保证目标磁盘有足够的剩余空间。我把这几个方案做成了一张对比表方便直观看到问题方案单文件大小限制是否需要外网手机端体验断点续传部署难度微信传输通常2GB以内需要一般不支持零部署网盘中转各平台不同必须一般部分支持零部署SMB/FTP取决于格式不需要较差取决于客户端中等U盘拷贝取决于格式不需要一般天然支持零部署浏览器直传方案50GB可扩展不需要很好完整支持低1.3 为什么我最终选择网页化方案选型的时候我的核心判断标准只有三条手机不需要装App、电脑不需要装客户端、能稳定处理50GB以上的单文件。满足这三条的只有网页化方案。手机和电脑都有浏览器这就是天然的跨平台客户端。文件上传走浏览器分片下载走HTTP的Range断点续传聊天走WebSocket长连接。整个系统本质上就是一个内网网站手机扫码访问、输入密码进入上传下载全靠网页完成。后端无论是用Nginx还是自建服务都能把大文件传输这件事处理得比任何聊天工具都稳。2. 整体架构与原理拆解为什么不直接开个共享文件夹2.1 整套系统的架构长什么样这套方案的架构并不复杂本质上是三个组件Nginx反向代理统一入口处理HTTP/HTTPS转发、WebSocket代理、静态页面。文件服务接收分片上传、合并文件、提供带Range支持的静态文件下载、生成二维码。聊天服务WebSocket聊天室负责内网即时消息广播。浏览器先把请求发给NginxNginx根据路径把请求分发给文件服务或者聊天服务。上传大文件时浏览器把文件切成多个分片逐个上传文件服务收齐所有分片后按顺序合并成完整文件再放到共享目录里。下载时Nginx或文件服务响应HTTP Range请求支持断点续传和多线程下载。2.2 50GB文件上传的三座大山要让浏览器传50GB文件不翻车必须解决三个问题浏览器内存、断点续传、磁盘格式。第一内存。如果直接把50GB文件整块读进浏览器内存再一次性POST出去任何电脑都会直接卡死。解决方法是分片把文件切成几十MB或几百MB的块逐个读取、逐个上传。每一片上传完成后释放内存再读下一片。实测用200MB一片、并发2个上传内存占用稳定保持在500MB左右即使是一台老旧笔记本也不会爆炸。第二断点续传。传输过程中Wi-Fi断一下、手机锁屏、电脑休眠都很常见。没有断点续传的方案一旦中断就得从头再来50GB文件重传一次非常痛苦。分片上传天然支持续传已经上传成功的分片会被服务端记录重新上传时跳过已有分片只补传缺失部分。每个分片上传时带上SHA-256校验值服务端核对一致才确认存储防止数据损坏。第三磁盘格式。接收文件的目标分区如果还是FAT32格式单文件最大只支持4GB50GB镜像在合并阶段就会报“文件过大”。所以接收端磁盘必须用NTFS或exFAT这一点特别容易被忽略。我一开始在测试机上踩过这个坑排查了半天才发现是U盘格式问题而不是代码问题。2.3 为什么传输和聊天要拆成两个服务有人会问聊天功能为什么不直接塞进文件服务里非要单独跑一个。原因有两点。第一职责分离。文件服务重点关注磁盘IO、校验、合并逻辑越单纯越稳定聊天服务只维护WebSocket长连接和消息广播两者互不干扰。文件传输导致磁盘满或IO阻塞时聊天还能正常用方便及时通知对方“磁盘满了”。第二扩展性。如果以后要加消息记录、Webhook通知、多房间聊天都在聊天服务里扩展不碰文件传输核心。文件服务也可以独立升级分片策略不影响在线聊天。2.4 内网设备互访的前提条件部署之前建议先确认网络环境。手机和电脑必须能互相访问也就是在同一个IP网段且路由器没有开启AP隔离。很多办公室Wi-Fi默认开了AP隔离手机能上外网但访问不到电脑的IP这种情况不是代码能解决的需要去路由器后台关闭隔离选项。电脑端防火墙也要放行对应端口Windows防火墙经常默认拦截自定义端口的入站流量我第一次部署时就是被它卡了一晚上。3. 部署实操文件互传服务完整落地3.1 用Docker Compose把整套环境拉起来为了在不同机器上快速复现我用Docker Compose编排了这套环境。目录结构大概是filechat/ ├── docker-compose.yml ├── nginx/ │ └── nginx.conf ├── fileserver/ │ ├── Dockerfile │ └── server.py ├── chat/ │ ├── Dockerfile │ └── server.py └── data/ └── shares/ # 共享文件存储目录docker-compose.yml的核心内容如下version: 3.8 services: nginx: image: nginx:alpine ports: - 8080:80 volumes: - ./nginx/nginx.conf:/etc/nginx/nginx.conf:ro - ./data/shares:/data/shares:ro depends_on: - fileserver - chat fileserver: build: ./fileserver volumes: - ./data/shares:/data/shares - ./data/uploads:/data/uploads restart: unless-stopped chat: build: ./chat restart: unless-stopped这里有个细节Nginx挂载的data/shares是只读的下载文件时由Nginx直接读文件服务挂载的data/shares是读写负责写入合并后的最终文件。临时分片放在data/uploads里不和正式文件混在一起方便定期清理。3.2 Nginx配置里的关键参数Nginx配置文件里有两个参数对超大文件传输至关重要不设置好传50GB直接翻车。server { listen 80; server_name _; client_max_body_size 0; proxy_request_buffering off; location / { proxy_pass http://fileserver:8000; } location /download/ { alias /data/shares/; autoindex on; add_header Content-Disposition attachment; filename$1; } location /chat/ { proxy_pass http://chat:8001; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; proxy_read_timeout 3600s; } }client_max_body_size 0表示不限制请求体大小这是上传大文件的前提。proxy_request_buffering off关闭请求缓冲让分片数据直接流向后端避免Nginx把整个分片先写完临时文件再转发内存和磁盘压力能降不少。下载目录配置了autoindex on浏览器访问目录时能看到文件列表直接点击就能下载。因为Nginx原生支持Range请求下载中断后重新点下载支持续传。聊天路径走WebSocket转发必须配置Upgrade头proxy_read_timeout 3600s防止长连接空闲被掐断。这个超时参数是聊天稳不稳的关键。3.3 文件服务的分片合并逻辑文件服务我使用了Python编写核心处理分片上传和合并。服务端不需要自己定协议实现要点如下上传接口接收参数文件名、分片序号、总分片数、文件总大小、分片SHA-256。每个分片写入临时目录文件名.part.序号。服务端校验分片哈希一致则返回成功不一致要求重传。所有分片齐全后按序号顺序把每个分片流式写入最终文件边写边计算最终文件的SHA-256。合并完成后删除临时分片并在共享目录生成最终文件。合并过程有个性能细节不要拿read()读整个分片进内存再写而要用流式复制比如shutil.copyfileobj()系统缓冲区自己控制内存占用极小。50GB文件合并实际峰值内存不到100MB。3.4 从手机端开始第一次完整使用整套环境起来之后手机操作流程非常直接手机连接同一个Wi-Fi浏览器输入http://电脑IP:8080或者直接扫我生成在首页的二维码。首页有一个拖拽上传区点选或者拍照选择文件。超大文件建议使用网页上传组件自动分片传入后台后能看到进度条和当前上传速度。上传完成页面会生成一个下载链接把链接发给同一内网的同事对方浏览器打开就能下载。需要聊天时点击页面右下角的“内网聊天室”入口直接进入消息页面。这个过程完全不需要装App也不需要登录腾讯或者百度账号纯内网就能跑通。3.5 上传组件的参数选择经验分片大小和并发数需要根据网络环境调整。我常用的参数是网络环境分片大小并发数备注千兆有线局域网200MB3速度稳定在90MB/sWi-Fi 5 单天线手机50MB2避免无线争抢Wi-Fi 6 双天线手机100MB3速度约50MB/s跨网段弱网20MB1优先保证成功率分片不宜太小太小会导致请求数太多服务端要频繁合并校验IO反而成瓶颈。也不宜太大太大会导致重传成本高。200MB一片在千兆有线环境很舒服无线环境建议降到50MB。4. 极简聊天服务的实现与联调4.1 内网聊天到底需要什么功能在纯内网场景里聊天需求其实很朴素发一段文本消息通知对方“文件传完了”“可以下载了”不需要图片表情包不需要视频通话甚至不需要消息历史记录。所以我做了一个极简的WebSocket广播聊天室后端代码非常短。4.2 WebSocket聊天服务后端实现我使用的Python websockets库核心代码如下import asyncio import websockets clients set() async def chat_handler(websocket): clients.add(websocket) try: async for message in websocket: # 内网场景直接广播给所有在线客户端 for client in clients: if client ! websocket: await client.send(message) except websockets.ConnectionClosed: pass finally: clients.remove(websocket) async def main(): async with websockets.serve(chat_handler, 0.0.0.0, 8001): await asyncio.Future() if __name__ __main__: asyncio.run(main())前端页面只需要建立一个WebSocket连接收到消息后追加到聊天窗口const ws new WebSocket(ws://${location.host}/chat/); ws.onmessage (event) { const msg document.createElement(div); msg.textContent event.data; document.getElementById(messages).appendChild(msg); };这个方案没有消息存储所以完全不用担心内网数据落在第三方服务器上。消息只在当前在线的浏览器之间转发离线用户看不到历史记录。对大多数人来说这足够了。4.3 聊天和文件传输怎么联动纯聊天其实不够方便最好让文件传输事件自动出现在聊天室里。我的做法是文件服务在分片合并完成后向聊天服务发起一个内网回调聊天服务收到后向所有客户端广播一条系统消息例如[sys] 虚拟机镜像.7z 已上传完成大小 50.2GB可点击下载。这个联动在实测中非常实用。A同事不用再喊一嗓子“传完了”手机上的聊天室会直接弹出提示对方点击消息里的链接就能直接下载文件。整个过程是自动化的不需要任何人中间转发。4.4 WebSocket联调过程中踩过的坑聊天服务第一次和Nginx联调时我遇到了连接不断建立又断开的问题。后来定位到是Nginx没有正确转发Upgrade头。加入proxy_set_header Upgrade $http_upgrade;和proxy_set_header Connection upgrade;后问题立刻消失。还有一次是聊天连上后过一两分钟就被断开。当时以为是代码问题后来发现是Nginx默认的proxy_read_timeout只有60秒长连接超过60秒没有数据就被掐断。改成3600秒后手机挂着聊天室几个小时都不掉线。这两个坑非常典型任何人做WebSocket代理都容易撞上。5. 50GB大文件实测与踩坑记录5.1 测试环境说明我实测的机器是某项目现场的一台普通办公电脑千兆有线接入两块机械硬盘组了RAID 1读取速度大约180MB/s系统盘是NVMe SSD。手机分别是某安卓旗舰Wi-Fi 6双天线和某旧款iPhoneWi-Fi 5单天线。路由器是普通双频千兆路由2.4GHz与5GHz分开。5.2 实测数据对比实际测试一个50GB的镜像文件结果如下环境操作平均速度耗时内存占用千兆有线直连电脑传电脑98MB/s约8.5分钟450MBWi-Fi 6手机手机传电脑52MB/s约16分钟380MBWi-Fi 5手机手机传电脑28MB/s约29分钟320MB无线下载电脑传手机45MB/s约18分钟不涉及有线环境基本跑满了千兆带宽速度非常理想。无线环境下速度瓶颈主要在手机Wi-Fi能力而不是服务端。旧款iPhone只有Wi-Fi 5单天线速度掉到28MB/s但还是比U盘接力快得多。5.3 必须记住的坑AP隔离我在另一台测试路由上部署时手机能连上Wi-Fi但网页怎么都打不开电脑的IP。Ping都不同电脑却能Ping通手机。排查到最后发现是路由器设置里有一个“AP隔离”选项被打开了这个功能会禁止同一个Wi-Fi下的客户端互相通信。关掉之后立刻恢复。这不算代码问题但非常常见。公司访客网络、宿舍路由器默认设置都可能开AP隔离。遇到手机访问不了电脑IP的情况先检查这个。5.4 必须记住的坑Windows防火墙第一次部署聊天服务时手机和电脑之间文件服务都能访问唯独WebSocket连不上。后来在电脑上抓包发现连接被Windows防火墙拦了。原因是文件服务走HTTP的80端口映射为8080Nginx有入站规则放行而聊天服务的新端口8001没有放行规则手机请求被丢弃。解决办法是在Windows防火墙里手动放行8001端口或者把整个Docker网段加入信任区域。Linux服务器一般没有这个问题但是公司Windows电脑通常默认开启防火墙这个坑非常典型。5.5 必须记住的坑iOS Safari大文件上传iOS的Safari在通过网页选择视频或文件时超过1GB的文件经常在选择阶段就直接失败表现为文件选择器崩掉或上传进度不动。这不是分片逻辑的问题是浏览器自身对文件读取的限制。我的解决方案是iPhone用户改用文件App把照片或视频先导入到本地再通过File Input的“浏览”按钮选取或者干脆用安卓手机/电脑浏览器上传。如果一定要用iPhone可以考虑使用第三方浏览器内核比如基于Chromium的iOS浏览器兼容性会好一些。5.6 调优磁盘格式与临时目录上传50GB大文件时接收端的临时分片目录和最终文件目录必须是NTFS或exFAT格式。FAT32的4GB限制会导致合并失败而且报错信息可能很迷惑——一会儿提示“空间不足”一会儿提示“参数不正确”。另外临时分片目录建议放在SSD上。机械硬盘在连续读写大文件时如果同时进行分片合并磁头来回寻道会很慢。我把data/uploads放在系统SSD最终文件放到机械硬盘合并完成后从SSD移动文件到机械盘速度有明显提升因为这个过程只涉及少量元数据操作。6. 权限、加密与长期使用细节6.1 权限控制做好了吗内网不等于绝对安全。给整套系统加上最基本的访问控制只需要在Nginx配置Basic Auth或者在文件服务里做一个简单的登录页面。我的建议是管理员账号负责上传和删除文件管理共享目录。访客账号只读下载不能上传不能删除。聊天室所有登录用户可用。如果共享目录里放的是虚拟机镜像、数据集这种内部资产一定不要裸奔。无认证的HTTP服务在局域网里传播速度很快别人扫到端口直接就能下载你的文件。6.2 要不要上HTTPS如果在公司或者宿舍这种多人共用网络的环境建议上一层HTTPS防止口令和文件内容被同网段的人用抓包工具截获。不想花钱申请证书的话可以用内网自签发证书然后在手机和电脑上安装根证书。具体做法是生成一个内部CA用这个CA给电脑IP:8080签发证书Nginx配置HTTPS监听。手机导入CA证书后浏览器不再提示安全警告访问体验和正规网站一致。这个操作第一次做会有一点繁琐但做完一劳永逸。6.3 让手机端体验接近原生App网页方案虽然不需要安装App但每次都要打开浏览器输网址确实不够爽。解决办法是用PWA渐进式网页应用在网页里加入manifest.json和service worker手机浏览器打开后选择“添加到主屏幕”图标就会出现在桌面点开是全屏体验背后还是同一个网页。我给这套系统加了一个简单的manifest图标用一张本地PNG名称叫“内网传送”。同事扫码后花五秒钟添加到主屏幕使用频率明显变高。这是个很小的优化但对非技术用户来说感知很大。6.4 后续扩展方向Webhook和自动任务最后聊聊我在这套系统上做的扩展。文件服务在文件合并完成后除了发聊天室通知还能调用一个Webhook地址。我把这个Webhook接到了备份脚本上只要内网有人传了新文件脚本就自动把文件同步到另一个备份磁盘防止共享盘故障。聊天服务也可以扩展成简单的任务通知中心备份脚本跑完发一条、跑批任务结束发一条内网同事不用盯电脑屏幕手机上就能知道结果。这些玩法不需要改很多代码却能让内网协作体验提升不少。我对这套系统的总体感受是部署一次之后基本就告别U盘了。手机传电脑、电脑传手机、电脑传电脑全部浏览器搞定50GB以上文件也没有焦虑。配置好权限和证书之后它可以安安稳稳地一直跑下去成为内网基础设施里最不起眼但最顺手的一个工具。