临时给别人发一个文件，常常比预想中麻烦。聊天软件有大小限制，邮箱不适合塞压缩包，网盘能用，但接收方可能要登录、装客户端，或者等你重新发一遍已经失效的链接。
这类文件往往没有长期保存的必要。一份给同事的测试包、几张原图、一段需要从电脑送到手机的文本，交接完成就可以清理。为它们建立完整的共享目录和账号体系，维护的东西反而比要传的东西多。
FileCodeBox 做的正是这件小事。上传文件，拿到取件码，把网站地址和码发给对方；对方打开浏览器领取。服务器、域名和保留时间由你管理，接收方不必跟着迁移到某一种网盘。它适合被放在常用工具的收藏夹里，需要时打开，用完关掉。
本文用 Docker Compose 部署一套带 HTTPS 的文件快递柜，从首次初始化写到文件过期、容量限制和备份恢复。示例采用本地存储，不需要另外开通对象存储，也不需要单独安装 MySQL 或 Redis。准备购买服务器的话，可以从 雨云云服务器选购入口 或 RackNerd VPS 选购入口 查看适合自己的配置。先确定文件主要发给谁，再选择机房，比先挑一台最便宜的机器更有意义。
文件快递柜管交接，长期资料另找地方保存
把 FileCodeBox 当成一个临时交接点，使用起来会很顺手。你可以在自己的电脑上上传项目资料，让另一台没有登录聊天软件的设备领取；也可以把交付文件发给客户，约定几天后自动失效。接收方只需要浏览器，省掉的是账号、客户端和不同平台之间来回搬运的麻烦。
官方文档中的取件页面。接收方输入取件码即可继续操作；截图用于展示界面，具体样式以安装版本为准。图片来源：FileCodeBox 官方分享文档。
不过，文件快递柜和长期网盘的维护目标不同。长期网盘更关心目录、同步、多版本和多人权限；临时交接更关心上传是否成功、对方能否取到、什么时候清走。不要因为服务器还有空闲磁盘，就把唯一一份照片、合同或项目归档长期放在这里。分享过期、误删、磁盘故障，都可能让这个临时副本消失。
FileCodeBox 项目仓库提供源码与发布记录。它使用 FastAPI 和 Vue，默认通过 SQLite 保存记录，支持文件与文本分享，也提供分片上传及多种存储后端。这里不把所有可选功能一并打开。对个人和小范围协作来说，先把本地存储、自己的上传权限和到期清理用明白，远比同时接入几种云盘更容易维护。
还有一个边界要提前说清楚：取件码并不验证接收者的身份。拿到码的人通常就有机会领取文件，码也可能被转发。自建服务器让你决定数据放在哪里，但它不会自动带来端到端加密。公司机密、身份证件和密码文件，不应因为网站是自己搭的就直接上传；确需传递时，应先在本地加密，并通过另一条可靠渠道交付解密口令。
服务器先看线路和磁盘，再看核心数
文件快递柜的工作负载不难理解：接收上传，把文件写入存储，再向接收方发送。低并发、小文件场景下，堆很多 CPU 核心通常不是最先要做的事。机房与访问者之间的线路、磁盘余量、月流量和单次上传限制，更容易影响每天的使用体验。
作为个人起步配置，我建议从 1 个 vCPU、2GB 内存的 Linux VPS 看起，给系统和文件留下足够的磁盘空间。这是部署与维护上的选型建议，并非项目给出的最低配置，也不代表这个规格能承受任意数量的大文件并发。已有服务器如果资源充足，可以共用；但生产业务数据库不宜和一个允许陌生人上传文件的服务挤在同一块快满的磁盘上。
容量可以按自己的交接习惯估算。假设每天上传 20 个文件，平均每个 50MB，保存 7 天，仅有效文件就约占 7GB。系统、镜像、日志、分片临时文件和本机备份还要另算。同一批文件若平均被下载三次，每天约有 3GB 下载数据，按 30 天估算就是 90GB，尚未计入其他请求和重试。这里用十进制做粗略预算，服务商的实际计费口径应以套餐说明为准。
雨云适合先按使用者的位置筛机房
如果收发双方主要在国内，购买时应优先查看机房位置、带宽说明和可用的测试入口。可以通过 雨云查看云服务器与机房配置，把预算相近的方案放在一起比较。尤其注意套餐给的是端口速率、带宽上限，还是有明确保障的带宽，不要只看一个醒目的数字。
文件传输对持续速度的要求和打开网页不一样。一个管理面板能迅速打开，不意味着上传几百兆文件也稳定。购买前能测试就先测试，购买后用自己和接收方的实际网络各传一份文件，再决定是否把它当作日常交接工具。本文没有在雨云不同机房逐一测速，不把某个区域的体验延伸到所有套餐。
RackNerd 可以用于低预算的海外交接
如果主要接收方在海外，或你希望有一台长期保留的海外 VPS，可以从 RackNerd 查看当前 VPS 方案开始筛选。看清可选机房、磁盘、月流量、付款周期和续费条件，别仅凭促销页的首年价格做决定。
对国内访问者而言，美国机房到本地运营商的实际路由比地图上的距离更重要。端口标着 1Gbps，也不等于从你的家用宽带上传就能达到这个速度。预算有限时，宁可先买满足容量需求的小规格做验证，也不要把未测过的线路描述成高速文件分发服务。两家服务商都只是部署载体，文件快递柜的备份、更新和访问策略仍由你负责。
先准备一台能正常维护的 Linux 服务器
以下示例以一台干净的 Ubuntu 24.04 LTS 服务器为例，使用拥有 sudo 权限的账号操作。准备一个自己控制的域名，把文件服务子域名的 A 记录指向 VPS 公网 IPv4。文中的 files.example.com 只是占位符，必须换成自己的地址。没有可用 IPv6 时，不要留下指向错误机器的 AAAA 记录。
先按 Docker 的 Ubuntu 安装文档安装 Docker Engine 和 Compose 插件。完成后检查这两个命令都能正常运行：
sudo docker version
sudo docker compose version
不要把另一篇教程里的数据库、面板和整套网站环境也装进来。本例只运行 FileCodeBox 与 Caddy，后者负责域名访问和 HTTPS。服务器若已有 Nginx、Caddy 或管理面板占用 80、443 端口，应沿用现有反向代理并参考后面的配置含义，不要再启动第二套抢占端口。
截至 2026 年 9 月 20 日，本文核对并验证的是 FileCodeBox v2.7.1。官方文档部分安装示例仍使用 2.7.0，旧文章中的配置名与默认行为也可能不同。因此这里固定版本号，不用 latest。以后升级时，先读新版本发布说明，再修改镜像标签。
用 Compose 把应用和数据位置固定下来
在服务器创建专用目录。后面的操作都围绕它进行，不要在不同路径下反复执行 Compose，最后分不清哪一份数据正在使用。
sudo mkdir -p /opt/filecodebox/data
cd /opt/filecodebox
sudo nano compose.yaml
把下面内容保存到 compose.yaml：
name: filecodebox
services:
filecodebox:
image: lanol/filecodebox:2.7.1
restart: unless-stopped
environment:
APP_ENV: production
LOG_LEVEL: warning
ACCESS_LOG: "false"
WORKERS: "1"
FORWARDED_ALLOW_IPS: "172.30.89.3"
ports:
- "127.0.0.1:12345:12345"
volumes:
- ./data:/app/data
networks:
filebox:
ipv4_address: 172.30.89.2
logging:
driver: json-file
options:
max-size: "10m"
max-file: "3"
caddy:
image: caddy:2
profiles: ["public"]
restart: unless-stopped
depends_on:
- filecodebox
ports:
- "80:80"
- "443:443"
volumes:
- ./Caddyfile:/etc/caddy/Caddyfile:ro
- ./caddy-data:/data
- ./caddy-config:/config
networks:
filebox:
ipv4_address: 172.30.89.3
logging:
driver: json-file
options:
max-size: "10m"
max-file: "3"
networks:
filebox:
ipam:
config:
- subnet: 172.30.89.0/24
这里最重要的是 ./data:/app/data。容器可以重建，上传文件、SQLite 数据库和应用配置要留在宿主机的 data 目录。只记住镜像版本、不知道数据落在哪里，后续换机器和备份都会很被动。WORKERS 保持为 1，不要因为服务器有多核就随手调大；本文使用的是默认 SQLite 部署。
12345 端口只绑定服务器回环地址，公网不能直接访问这个映射。Caddy 则放在 public profile 中，默认不启动，让我们有机会先完成初始化。这里显式划出一段 Docker 私网，并给 Caddy 固定地址，只信任它转交的客户端 IP。创建前检查 172.30.89.0/24 是否与已有 Docker 网络、内网或 VPN 路由冲突；如需修改，要同步修改两个容器地址、子网和 FORWARDED_ALLOW_IPS。
接着创建 /opt/filecodebox/Caddyfile：
files.example.com {
reverse_proxy filecodebox:12345 {
header_up X-Forwarded-For {remote_host}
header_up X-Real-IP {remote_host}
}
}
保存前换掉域名。这份配置假设用户直接访问 Caddy，没有在前面套 CDN 或另一层代理；它会用实际连接来源覆盖转发头。应用只信任固定的 Caddy 地址，避免把任何客户端自报的 IP 都当真。真实 IP 关系到按地址限制请求，不能为了“能用”就把信任范围改成所有地址。反向代理的具体行为可查 Caddy 官方说明。
先检查配置，只启动应用：
sudo docker compose config -q
sudo docker compose up -d filecodebox
sudo docker compose ps
sudo docker compose logs --tail=80 filecodebox
这时不要急着开放 12345，也不需要修改文件夹为全员可写。容器如果反复重启，先看日志里的具体报错，确认磁盘、挂载目录和端口情况。把权限一股脑设为 777，只会让之后的排查更困难。
第一次初始化，通过 SSH 隧道完成
新实例的初始化页面用于设置管理员密码。如果先把它完整暴露在公网，再慢慢找教程填设置，其他人也可能抢先访问。这里让应用暂时只在服务器本机可见，通过 SSH 隧道从自己的电脑完成初始化。
在自己的电脑终端运行下面命令，把 YOUR_SERVER_IP 换成 VPS 地址；使用普通管理账号时，把 root 换成该账号。此终端保持开启：
ssh -N -L 12345:127.0.0.1:12345 -l root YOUR_SERVER_IP
然后在自己电脑的浏览器输入 http://127.0.0.1:12345。本机端口如果已经被其他程序占用，可以把 -L 后第一个 12345 改成 12346，浏览器也相应访问 12346，后面的服务器端口不变。
初始化时设置独立的管理员强密码，放进密码管理器；不要照抄旧教程里的默认口令。给站点起一个容易辨认的名字，保留本地存储。首次设置中的游客上传建议关闭，后续由自己登录后台上传，对方凭取件码领取。接收文件不需要因此获得管理员权限。
保留方式先选天、小时、分钟，最长保存时间可以设为 7 天，单文件上限按需求设为 100MB。它们是给个人交接用途的起步建议，不是必须照抄的官方标准。暂时不启用永久保存和按次数过期，理由在下一节说明。取件码优先选择字母数字混合类型，不要为少输入几个字符牺牲本来就有限的码空间。
管理页面地址是 http://127.0.0.1:12345/#/admin。首页没有后台按钮，不代表没有管理入口；隐藏入口也不能代替密码。登录后确认游客上传确实关闭，退出登录或用无痕窗口试一次，不能只看开关的颜色就认为权限已生效。
后台集中管理站点名称、密码、会话和入口显示等设置。图中是官方文档示例，不需要照搬其中的值。图片来源：FileCodeBox 官方管理文档。
到期时间、领取次数和磁盘配额要分开管
“发出去之后什么时候不能再取”与“文件什么时候从磁盘清掉”不是同一个动作。前者由访问时的过期判断控制，后者还涉及后台清理。即使页面显示过期，也不应把它当成磁盘安全擦除证明，已经被对方下载到本地的副本更不受你控制。
本文更推荐用明确的时间期限。会议资料保留一天，交付包保留几天，临时文本保留一小时，双方都容易理解。2.7.1 中按次数分享走另一套判断逻辑，不能把它简单理解成“次数和时间同时生效，哪个先到算哪个”。如果业务要求既限时又限次，要在目标版本验证这两个约束确实同时成立，不能凭界面字段推断。
领取次数也不是送达回执。文件下载请求开始处理时，服务端就可能记录一次使用；中途断网、接收方取消、重复请求，并不等于它完整收到并确认了内容。文本领取和文件领取的处理路径还有差异。需要对方确认的交付，仍应请对方检查文件并回复，不要用“只允许领取一次”代替交接确认。
在本次验证的版本里，混合取件码和纯数字取件码都是短码。混合码更适合默认使用，但远没有长随机密钥那样大的空间。不要把文件站地址和有效取件码同时贴到公开评论区；按 IP 限制错误尝试只能增加滥用成本，无法把匿名取件变成可靠身份认证。
容量也要显式设上限。假设 VPS 有 40GB 磁盘，不建议把文件存储限额直接设成 40GB。给操作系统、镜像、日志和临时文件留出余量，可以先分给快递柜 10GB 或 15GB，观察一段时间再调整。应用里的总容量限制用于控制受它管理的内容，不是整个文件系统的剩余空间保护。日志和其他程序照样可能把磁盘写满，所以还要检查宿主机：
df -h /opt/filecodebox
sudo du -sh /opt/filecodebox/data
sudo docker system df
不同版本的后台字段名称可能调整，优先在当前管理页面保存设置，不要把旧文档里的 camelCase 字段拼成一份自创配置文件挂进去。特别是“最长保存时间为 0”的语义，不应当作长期保存承诺：本文核对的版本里，按时间分享的后端逻辑还有自己的默认期限判断。把允许的分享方式和具体时限都明确设置，出问题时更容易判断。
开放域名访问，再检查一遍访客视角
完成初始化与权限设置后，在云平台安全组和服务器防火墙允许 HTTP、HTTPS，也就是 TCP 80 和 443。SSH 尽量限制为自己的可信来源。12345 不需要开放。Docker 发布端口与主机防火墙的关系不能仅凭直觉判断，这也是前面直接绑定回环地址，而不只依赖一条防火墙规则的原因。
确认域名解析正确、80 和 443 没被其他程序占用，然后启动 Caddy：
cd /opt/filecodebox
sudo docker compose --profile public up -d
sudo docker compose logs --tail=100 caddy
在域名和网络条件满足时，Caddy 会申请证书并提供 HTTPS。用浏览器打开自己的域名，检查证书有效，HTTP 能跳转到 HTTPS。首次证书签发失败时，先查 DNS、端口和 Caddy 日志，不要反复删除证书目录重来。如果套了 CDN，先弄清代理模式和上传限制；本文的客户端地址配置以直接连接 Caddy 为前提，多层代理需要重新设计可信代理链。
现在做一次完整交接：管理员上传一份没有敏感内容的小文件，另开无痕窗口输入取件码并下载，比对文件名、大小和实际内容。再发给手机，用移动网络取一次，避免两次测试其实都绕过了公网路径。之后测试一段文本，确认换行和中文保留正常。
发送页面可以选择文件或文本，再设置保留时间。截图里的 20MB 是官方演示站当时的设置，并非程序的固定上限；按前文配置后，以自己的站点显示为准。图片来源：FileCodeBox 官方上传文档。
最后退出管理员账号，在访客窗口尝试上传。如果你的目标是“只有自己能发，其他人能取”，这里就应该被拒绝。不要只验证正向功能；一个文件站能上传下载，不代表它已经按你的意愿限制了谁能往服务器写东西。
大文件传不动，先判断卡在哪一层
小文件成功、大文件失败，是这类服务最常见的后续问题。可能是应用设置了单文件上限，也可能是前面的代理限制请求体大小，或者 CDN 对单次上传有限制。返回 413 时优先查请求体限制；传了很久再超时，则要结合代理日志、应用日志、磁盘空间和网络情况判断，不要第一时间归因于 VPS 配置太低。
FileCodeBox 提供分片上传与续传能力，需要启用相应设置，也要由支持这一流程的客户端使用。它能减少传输中断后从头再来的损失，但不能让慢线路变快，也不会凭空增加存储容量。分片、合并文件和并发上传都需要空间预算，磁盘只剩下略大于目标文件的容量时，不适合继续接收大文件。
如果本来只传几十兆的文档，不必为“以后可能用到”把单文件限制放到几十 GB。设置上限的作用是让资源使用有边界。每次提高上传上限，顺手确认总容量限制、反向代理和前置服务的限制是否匹配，再用接近新上限的非敏感测试文件验证。
文件多到本地磁盘不合适时，可以再看官方的存储配置文档，评估 S3 兼容存储等后端。对象存储会引入访问凭证、请求费用、下载流量费用和自己的备份策略，并非填上一个桶名就省去了运维。不要为了让下载链接生效，把整个存储桶改成公开读取；应按照所选后端核对鉴权和分享方式。
备份整个数据目录，并在另一套环境试恢复
默认本地存储下，/app/data 中既有数据库，也有上传文件。只备份 SQLite 数据库，恢复后可能看到文件记录却下载不到附件；只复制上传目录，则会丢掉配置和取件记录。本文没有挂载 NAS 的其他目录，也没有接对象存储，所以直接备份完整 data 目录最容易说明白。
为避免数据库和文件处于不同时间点，这里采用短暂停机备份。业务量不大的私人快递柜，这比一开始就设计不停机快照更容易核实。先给接收方留出维护时间，在服务器保存下面脚本为 /opt/filecodebox/backup.sh：
#!/usr/bin/env bash
set -euo pipefail
umask 077
cd /opt/filecodebox
backup_dir="/opt/filecodebox-backups/$(date +%Y%m%d-%H%M%S)"
mkdir -p "$backup_dir"
docker compose stop filecodebox
trap 'docker compose start filecodebox' EXIT
tar -czf "$backup_dir/filecodebox-data.tar.gz" data
cp compose.yaml Caddyfile "$backup_dir/"
sha256sum "$backup_dir/filecodebox-data.tar.gz" > "$backup_dir/SHA256SUMS"
tar -tzf "$backup_dir/filecodebox-data.tar.gz" >/dev/null
通过 sudo bash /opt/filecodebox/backup.sh 执行。脚本停止应用后打包，正常结束或普通错误退出时都会尝试启动应用；机器掉电等情形不能靠 shell 的退出钩子处理。执行完仍要看 docker compose ps，确认服务恢复。备份目录在数据目录之外，避免把旧备份再次打进新备份。
这份归档含有文件、应用设置和可能存在的存储凭证，应限制读取权限，异机保存时按敏感数据处理。同一台 VPS 上的另一份压缩包，只能应付部分误操作，无法抵御整台机器丢失。至少把一份加密备份复制到另一个故障域，并设定备份保留周期。用户以为已经过期的文件，可能还在旧备份里，这是你需要解释和管理的另一份副本。
恢复演练应在另一台测试机或隔离目录进行，不要直接覆盖正在服务的数据。准备空目录，复制备份中的 Compose 与 Caddyfile，确认压缩包校验值正确，再解包，让恢复出的 data 与 Compose 位于同一级。先保持 Caddy 未启动，只运行应用，通过 SSH 隧道检查原管理员密码能否登录、原取件记录是否存在、尚未过期的测试文件能否完整下载。
在同一台服务器演练时，Compose 项目名、绑定端口和私网子网都要与原实例不同，不能原样启动两套；恢复出的数据也可能触发到期清理，使用副本测试，不要动唯一的备份。若后来改用了对象存储或 NAS 引用，本节的目录备份就不再覆盖全部原始文件，必须把外部数据的恢复方案补上。
升级前留下可以回去的那一份
文件分享服务在公网接收输入，更新不能无限期拖着；但自动拉取最新镜像，也不适合一个承载实际文件的实例。记录当前版本，阅读更新说明，做完整备份，再修改 compose.yaml 中 FileCodeBox 的标签。不要把回滚理解成随时换回旧镜像：新版本若改变了数据库结构，旧镜像不一定能直接读新数据。
改好版本后，仍在原部署目录执行：
sudo docker compose pull filecodebox
sudo docker compose up -d filecodebox
sudo docker compose logs --tail=100 filecodebox
升级验收至少覆盖管理员登录、访客上传限制、旧文件领取、新文件上传与到期行为。Caddy 也需要维护；这里使用 caddy:2 表示主版本范围，正式长期使用时可以进一步记录已验证镜像的摘要。需要退回旧版本时，用升级前的镜像与对应的数据备份成套恢复，并接受备份之后新上传内容可能需要另行处理的事实。
日常维护不必复杂到另起一套平台，但应有一个固定习惯：查看剩余空间，抽查清理结果，确认备份还在生成，关注项目安全与更新说明。站点一旦开放给陌生人上传，还会额外带来恶意内容、流量滥用和投诉处置问题。文件类型限制不能充当病毒查杀；没有准备好承担这些工作，就保持游客上传关闭。
留一个好用的交接入口就够了
文件快递柜做得好不好，最后体现在一些很具体的小事上：对方不用注册账号，文件能顺利拿到，过期规则说得清楚，服务器没有悄悄堆满无法辨认的压缩包。把这些做稳，已经足以解决很多临时传文件的麻烦。
如果现在还没有服务器，可以从 雨云选择适合收发双方的云服务器，或从 RackNerd 查看海外 VPS 方案。别为了教程一次性购买过大的配置。先用小范围、非敏感的文件把上传、领取、清理和恢复跑通，再根据真实的磁盘占用与传输体验调整。
真正需要长期保存的资料，仍放在自己的归档与备份体系里。FileCodeBox 负责把这一份交给对方，交接结束之后，快递柜里应该能腾出地方。