8道坎FilePizza点对点文件传输从跑通到上线的实战路径【免费下载链接】filepizza:pizza: Peer-to-peer file transfers in your browser项目地址: https://gitcode.com/GitHub_Trending/fi/filepizzaFilePizza 是一个 Next.js 15 WebRTC 的点对点文件传输服务文件不经过你的服务器直接在两个浏览器之间传输附带短链接、密码保护和 zip 流式下载。本地四条命令就能跑起来但照抄配置上线能跑和能上线之间隔着整整 8 道坎。能力速览这个项目覆盖了哪些技术面WebRTC 直传PeerJS 负责信令协商文件以 256KB 分片经可靠 DataChannel 传输服务器只负责签发 slug协议细节见 docs/file-transfer-protocol.md双 slug 体系8 位短码 4 词长链接1 小时 TTL由上传者周期性续期可选密码保护多文件上传自动打包为 zip 交给下载端流式下载Service Worker 配合 StreamSaver 拦截下载请求浏览器不必整包缓存在内存状态层Redis 存储渠道元数据未配置时降级为进程内存coturn 提供 TURN 中继本地跑通git clone https://gitcode.com/GitHub_Trending/fi/filepizza.git cd filepizza pnpm install pnpm dev要求 Node 18 与 pnpm想连 TURN 一起完整测试 WebRTC改用pnpm dev:full会额外拉起 Redis 和 coturn 容器。关卡一信令与网络通路——WebRTC 的两个默认值都是暗坑信令默认走第三方免费 PeerJS 云生产连接量看别人脸色现象本地传输一切顺利上线后用户随机卡在连接中高峰期失败率明显上升。根因src/app/api/ice/route.ts 读取PEERJS_HOST时默认值是0.peerjs.com这是免费公共 PeerJS 云对并发连接数有配额限制而 docker-compose.production.yml 并未设置该变量生产环境照样指向它。修复自建 PeerJS 服务器仓库自带start:peerjs脚本基于 express 实现把PEERJS_HOST/PEERJS_PATH指向自有域名并为该域名配置好 HTTPS/WSS。打开 COTURN_ENABLED 不等于 TURN 生效默认地址是 127.0.0.1现象同一局域网内两台设备互传成功跨 NAT手机流量、公司网络的握手直接超时。根因src/app/api/ice/route.ts 里TURN_HOST默认127.0.0.1生产 compose 虽然设置了COTURN_ENABLEDtrue却没配TURN_HOST于是浏览器拿到的 ICE 服务器是turn:127.0.0.1:3478——这个地址指向用户自己的电脑不是你的 coturn 实例。修复把TURN_HOST设为服务器公网 IP放行 3478tcp/udp与 5349 端口并开放中继端口段——生产 compose 映射的是 60000–60128coturn 侧需用--min-port/--max-port与之对应。验证方法用两台不同网络如办公网 手机热点的机器发起传输打开 DevTools 查看 ICE 连接候选类型出现relay才说明 TURN 真正生效。关卡二状态与存储——FilePizza 的 slug 链接比你想象的更脆没配 REDIS_URL渠道状态活在进程内存里重启即全断现象服务重启一次或扩到两台实例之前发出的所有短链接全部查无此渠道。根因src/channel.ts 的getOrCreateChannelRepo()在REDIS_URL未设置时回退到MemoryChannelRepo全部渠道状态存在单个 Node 进程的堆内存里重启即失、多实例不共享。修复生产环境永远配置REDIS_URL让所有实例指向同一个 Redis仓库两份 compose 文件都已内置 Redis 服务别跳过这个环境变量。开发版 compose 的 Redis 裸奔在 0.0.0.0照抄上服务器就是事故现象部署到公网机器后端口扫描器轻松发现 6379攻击者无需密码即可读写清空整个渠道数据库——无认证的 Redis 等于全量读写权限。根因docker-compose.yml 把 Redis 映射为6379:6379绑定所有网卡且无任何认证docker-compose.production.yml 则绑定127.0.0.1:6379。很多人图省事拿前者上了生产。修复生产一律用 production compose 文件若必须在公网机器跑开发版至少把端口映射改为 127.0.0.1并给REDIS_URL加上密码。渠道 TTL 只有 1 小时上传者关浏览器链接立刻失效现象下载者一小时后打开链接连不上上传者随手一关标签页进行中的传输当场中断。根因src/config.ts 将 TTL 定为 1 小时P2P 架构下数据必须流经上传者的浏览器上传者离线即无数据源续期也要靠上传端定期调用 renew 接口。修复这是架构约束而非 bug把 README FAQ 里关闭浏览器链接即失效的说法同步写进你自己的上传页文案若产品上要求上传完成后链接常存需要引入服务端存储超出本项目范围。关卡三接口安全——四个 API 端点全部裸奔公网/api/destroy 无鉴权知道 slug 的人都能拔线现象别人正在进行的传输突然报渠道断开上传者页面被重定向到举报页。根因src/app/api/destroy/route.ts 按设计允许任何持有 slug 的调用者销毁渠道这套机制服务于滥用举报流程但没有身份校验也没有频率限制。修复端点本身无法加鉴权会破坏举报链路应在网关层兜底对该路径配置按 IP 限流并对异常高频调用设置告警。create / renew / ice 无速率限制可被刷爆 Redis现象攻击脚本每分钟向 /api/ice 发数千个请求Redis 内存与连接数持续爬升。根因三个路由只校验字段是否存在完全没有限流src/config.ts 虽预定义了 peer ID 与 slug 的长度边界路由代码却未使用且每次 /api/ice 调用都会向 Redis 写一对 24 小时有效的 TURN 凭据src/coturn.ts请求量直接放大成写压力。修复在反向代理层为这三个路径加按 IP 限流并持续监控 Redis 内存增长曲线。关卡四部署与构建——standalone 产物缺了一半资产public 与静态资源不手动拷贝所有下载都会静默失败现象页面能正常打开但下载按钮静默失败控制台里 stream.html 或 sw.js 一片 404。根因next.config.js 设置了output: standalone构建产物只含服务端代码public/与.next/static不在其中package.json 的 build 脚本手动拷贝这两个目录Dockerfile 也补了这一步——自己部署 standalone 目录时必须原样照做。修复手动部署时保留 build 脚本里的拷贝步骤不要只拿.next/standalone直接起服务。验证方法生产构建后对 /sw.js、/stream.html 以及 /_next/static 下任一资源执行curl -I全部 200 再放行随后做一次真实多文件传输确认 zip 下载完整落盘。上线前自检清单关卡关键动作涉及文件信令通路自建 PeerJSTURN_HOST 设公网 IP 并放行中继端口src/app/api/ice/route.ts状态存储配置 REDIS_URLRedis 绑定 127.0.0.1src/channel.ts、docker-compose.production.yml接口安全网关层为四个 API 端点加按 IP 限流src/app/api/destroy/route.ts部署构建拷贝 public 与静态资源验证 stream.html 可达next.config.js、package.json这 8 道坎是几乎所有演示级 WebRTC 服务的共性信令与 TURN 通路决定能不能连上外部化状态存储决定链接会不会莫名失效限流与暴露面决定上线后能不能活过第一周。把连接通路、状态、抗滥用这三层逐一验证任何 P2P 传输服务都能从本地玩具升级为可交付的产品 【免费下载链接】filepizza:pizza: Peer-to-peer file transfers in your browser项目地址: https://gitcode.com/GitHub_Trending/fi/filepizza创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 8道坎：FilePizza点对点文件传输从跑通到上线的实战路径
8道坎FilePizza点对点文件传输从跑通到上线的实战路径【免费下载链接】filepizza:pizza: Peer-to-peer file transfers in your browser项目地址: https://gitcode.com/GitHub_Trending/fi/filepizzaFilePizza 是一个 Next.js 15 WebRTC 的点对点文件传输服务文件不经过你的服务器直接在两个浏览器之间传输附带短链接、密码保护和 zip 流式下载。本地四条命令就能跑起来但照抄配置上线能跑和能上线之间隔着整整 8 道坎。能力速览这个项目覆盖了哪些技术面WebRTC 直传PeerJS 负责信令协商文件以 256KB 分片经可靠 DataChannel 传输服务器只负责签发 slug协议细节见 docs/file-transfer-protocol.md双 slug 体系8 位短码 4 词长链接1 小时 TTL由上传者周期性续期可选密码保护多文件上传自动打包为 zip 交给下载端流式下载Service Worker 配合 StreamSaver 拦截下载请求浏览器不必整包缓存在内存状态层Redis 存储渠道元数据未配置时降级为进程内存coturn 提供 TURN 中继本地跑通git clone https://gitcode.com/GitHub_Trending/fi/filepizza.git cd filepizza pnpm install pnpm dev要求 Node 18 与 pnpm想连 TURN 一起完整测试 WebRTC改用pnpm dev:full会额外拉起 Redis 和 coturn 容器。关卡一信令与网络通路——WebRTC 的两个默认值都是暗坑信令默认走第三方免费 PeerJS 云生产连接量看别人脸色现象本地传输一切顺利上线后用户随机卡在连接中高峰期失败率明显上升。根因src/app/api/ice/route.ts 读取PEERJS_HOST时默认值是0.peerjs.com这是免费公共 PeerJS 云对并发连接数有配额限制而 docker-compose.production.yml 并未设置该变量生产环境照样指向它。修复自建 PeerJS 服务器仓库自带start:peerjs脚本基于 express 实现把PEERJS_HOST/PEERJS_PATH指向自有域名并为该域名配置好 HTTPS/WSS。打开 COTURN_ENABLED 不等于 TURN 生效默认地址是 127.0.0.1现象同一局域网内两台设备互传成功跨 NAT手机流量、公司网络的握手直接超时。根因src/app/api/ice/route.ts 里TURN_HOST默认127.0.0.1生产 compose 虽然设置了COTURN_ENABLEDtrue却没配TURN_HOST于是浏览器拿到的 ICE 服务器是turn:127.0.0.1:3478——这个地址指向用户自己的电脑不是你的 coturn 实例。修复把TURN_HOST设为服务器公网 IP放行 3478tcp/udp与 5349 端口并开放中继端口段——生产 compose 映射的是 60000–60128coturn 侧需用--min-port/--max-port与之对应。验证方法用两台不同网络如办公网 手机热点的机器发起传输打开 DevTools 查看 ICE 连接候选类型出现relay才说明 TURN 真正生效。关卡二状态与存储——FilePizza 的 slug 链接比你想象的更脆没配 REDIS_URL渠道状态活在进程内存里重启即全断现象服务重启一次或扩到两台实例之前发出的所有短链接全部查无此渠道。根因src/channel.ts 的getOrCreateChannelRepo()在REDIS_URL未设置时回退到MemoryChannelRepo全部渠道状态存在单个 Node 进程的堆内存里重启即失、多实例不共享。修复生产环境永远配置REDIS_URL让所有实例指向同一个 Redis仓库两份 compose 文件都已内置 Redis 服务别跳过这个环境变量。开发版 compose 的 Redis 裸奔在 0.0.0.0照抄上服务器就是事故现象部署到公网机器后端口扫描器轻松发现 6379攻击者无需密码即可读写清空整个渠道数据库——无认证的 Redis 等于全量读写权限。根因docker-compose.yml 把 Redis 映射为6379:6379绑定所有网卡且无任何认证docker-compose.production.yml 则绑定127.0.0.1:6379。很多人图省事拿前者上了生产。修复生产一律用 production compose 文件若必须在公网机器跑开发版至少把端口映射改为 127.0.0.1并给REDIS_URL加上密码。渠道 TTL 只有 1 小时上传者关浏览器链接立刻失效现象下载者一小时后打开链接连不上上传者随手一关标签页进行中的传输当场中断。根因src/config.ts 将 TTL 定为 1 小时P2P 架构下数据必须流经上传者的浏览器上传者离线即无数据源续期也要靠上传端定期调用 renew 接口。修复这是架构约束而非 bug把 README FAQ 里关闭浏览器链接即失效的说法同步写进你自己的上传页文案若产品上要求上传完成后链接常存需要引入服务端存储超出本项目范围。关卡三接口安全——四个 API 端点全部裸奔公网/api/destroy 无鉴权知道 slug 的人都能拔线现象别人正在进行的传输突然报渠道断开上传者页面被重定向到举报页。根因src/app/api/destroy/route.ts 按设计允许任何持有 slug 的调用者销毁渠道这套机制服务于滥用举报流程但没有身份校验也没有频率限制。修复端点本身无法加鉴权会破坏举报链路应在网关层兜底对该路径配置按 IP 限流并对异常高频调用设置告警。create / renew / ice 无速率限制可被刷爆 Redis现象攻击脚本每分钟向 /api/ice 发数千个请求Redis 内存与连接数持续爬升。根因三个路由只校验字段是否存在完全没有限流src/config.ts 虽预定义了 peer ID 与 slug 的长度边界路由代码却未使用且每次 /api/ice 调用都会向 Redis 写一对 24 小时有效的 TURN 凭据src/coturn.ts请求量直接放大成写压力。修复在反向代理层为这三个路径加按 IP 限流并持续监控 Redis 内存增长曲线。关卡四部署与构建——standalone 产物缺了一半资产public 与静态资源不手动拷贝所有下载都会静默失败现象页面能正常打开但下载按钮静默失败控制台里 stream.html 或 sw.js 一片 404。根因next.config.js 设置了output: standalone构建产物只含服务端代码public/与.next/static不在其中package.json 的 build 脚本手动拷贝这两个目录Dockerfile 也补了这一步——自己部署 standalone 目录时必须原样照做。修复手动部署时保留 build 脚本里的拷贝步骤不要只拿.next/standalone直接起服务。验证方法生产构建后对 /sw.js、/stream.html 以及 /_next/static 下任一资源执行curl -I全部 200 再放行随后做一次真实多文件传输确认 zip 下载完整落盘。上线前自检清单关卡关键动作涉及文件信令通路自建 PeerJSTURN_HOST 设公网 IP 并放行中继端口src/app/api/ice/route.ts状态存储配置 REDIS_URLRedis 绑定 127.0.0.1src/channel.ts、docker-compose.production.yml接口安全网关层为四个 API 端点加按 IP 限流src/app/api/destroy/route.ts部署构建拷贝 public 与静态资源验证 stream.html 可达next.config.js、package.json这 8 道坎是几乎所有演示级 WebRTC 服务的共性信令与 TURN 通路决定能不能连上外部化状态存储决定链接会不会莫名失效限流与暴露面决定上线后能不能活过第一周。把连接通路、状态、抗滥用这三层逐一验证任何 P2P 传输服务都能从本地玩具升级为可交付的产品 【免费下载链接】filepizza:pizza: Peer-to-peer file transfers in your browser项目地址: https://gitcode.com/GitHub_Trending/fi/filepizza创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考