FastFileLink Blog

Using FastFileLink to Deliver a 3.8GB, 158-File U.S. Department of War UFO Public Archive

2026-05-13T10:00:00+08:00

Recently, war.gov launched a public UFO/UAP records page.

According to the official description, the release was part of the Trump administration's push for more transparency around UAP-related information. The U.S. Department of War (DOW), together with other agencies, published a batch of unresolved UAP-related records and historical documents.

When I saw the news, my first thought was simple:

“It would be really useful if people could download this whole thing in one place.”

The official page is browsable, but if you actually want to download all the PDFs, videos, and images, the experience is not that smooth. You have to click through files one by one, figure out which items are documents, which are videos, and which are just images used by the page itself. For a normal user, even getting started is already a bit of work.

This is exactly the kind of problem FastFileLink is meant to solve: taking a batch of files and turning it into a package that can be delivered, downloaded, and clearly explained.

I was personally curious about the material too, so I spent some time collecting the files and checking whether it was legally reasonable to redistribute these public records. After confirming that it was okay to do, I decided to organize everything and make it easier for others to download.

This kind of archive is a natural fit for FastFileLink. The full package is around 3.8GB and contains many files. I honestly did not have an easy place to put it. You cannot send something like this through WhatsApp, LINE, or a regular messaging app. A cloud drive would bring its own issues: storage limits, permissions, packaged downloads, bandwidth limits, and so on. So I decided to document the whole process as I went.

First, I organized the public files into one complete folder

I started by collecting the directly downloadable files from the war.gov UFO/UAP Release 01 page.

The final package looked roughly like this:

158 downloadable files
116 PDFs
28 videos
14 images
Around 3.8GB total
Source URLs preserved for every file
SHA-256 checksums generated
Index files and a manifest included

I put everything into one folder:

04_full_release01_pack/

Besides the actual files, I also prepared a few helper files:

README.md
START_GUIDE.html
files_index.csv
files_index.jsonl
manifest.json
checksum.sha256
files/

README.md explains the source, scope, licensing notes, and the non-endorsement disclaimer.

START_GUIDE.html is an entry guide for regular users. The release itself is quite scattered: there are videos, images, FBI-related materials, NASA/Apollo-related materials, and large historical scanned PDFs. If someone downloads the archive and only sees a pile of files, they may have no idea where to begin.

So in START_GUIDE.html, I added a simple suggested browsing order:

Start with the videos
Then look at the images
Then open the shorter modern PDFs
Then move on to the FBI and NASA/Apollo-related materials
Save the large historical PDFs for last

That gives people a straightforward entry point after downloading the archive.

Uploading the whole folder with FastFileLink

Once the folder was ready, I uploaded it.

I logged into my FastFileLink account and uploaded the entire 04_full_release01_pack folder. The important part here is that I did not need to compress it into a ZIP myself, and I did not need to manually handle how all the files would be packaged, listed, or delivered to downloaders.

FastFileLink handled the folder delivery directly.

At first, the upload produced a standard download page like this:

This standard page is clean, functional, and downloads work just fine.

But when I looked at it, it felt too neutral.

This package was about the U.S. Department of War UFO/UAP public records. When someone opens the page, they should immediately understand what they are downloading. Especially for a 3.8GB package, a generic download box may not inspire enough confidence.

So I decided to use FastFileLink's white-label customization feature to make the page better match the actual content.

Using white-label customization to turn the download page into a dedicated landing page

FastFileLink's white-label settings let you customize the logo, background, colors, navigation links, download notes, footer content, and more.

I switched the logo to a white version because I wanted a dark theme for this page. Then I changed the background to a deep blue, tech-style image and used a cool color palette that fit the UFO/UAP topic.

After the customization, the page looked more like this:

Now, as soon as someone opens the page, they can quickly see that the package contains:

U.S. Department of War UFO/UAP public records
158 files
116 PDFs
28 videos
14 images
Source URLs, index files, and SHA-256 checksums

I also added source and legal notes in the footer:

Source: war.gov/UFO
This is an unofficial convenience download pack
It is not affiliated with, sponsored by, approved by, or endorsed by the U.S. Department of War, U.S. Department of Defense, AARO, NARA, DVIDS, or any U.S. government agency
The appearance of U.S. government visual information does not imply DoW/DoD endorsement of FastFileLink or this website
The archive is redistributed as publicly released and does not claim that the files prove extraterrestrial life

That disclaimer matters. Since the package uses U.S. government public records, and U.S. federal government works are generally public domain in the United States, redistribution is usually not the main issue. The important thing is to avoid giving the impression of an official partnership or endorsement.

There is also a small localization detail: my browser is set to Chinese, so the download progress and interface text appear in Chinese for me. English readers opening the same page will see the download interface in English according to their browser environment.

A download page should explain the content before asking people to download

After I published the package, someone gave me a very practical piece of feedback:

It'd still be courteous to wait for a click before downloading 4 GB of files. I just wanted to see a description of what's included first.

That made me think.

From the sender's point of view, opening a download page and preparing the download right away makes sense. The goal is to deliver the files.

But for someone seeing the link for the first time, 4GB is not a small download. They may simply want to check what is inside, confirm the source, review the size, and decide whether they actually want to download it.

FastFileLink already has an eye icon on the page that opens a preview, where people can see the file description and content information.

But I realized that if I am sharing a link on a forum or social platform, it is better not to send people straight into the download flow. A better approach is to share the preview-mode link directly.

The trick is simple: add this to the end of the URL:

?preview=true

For example, instead of:

https://0.2.fastfilelink.com/xxxx

use:

https://0.2.fastfilelink.com/xxxx?preview=true

With that, people first see the description, file information, and download notes. Then they can choose whether to start the download.

For large-file delivery, this is a very useful detail. The bigger the file, the more likely the first question is not “How do I download it?” but “What exactly is this?”

How people reacted after I shared it

After the package was ready, I posted it in a few places to see how people would react.

I tried Hacker News first. Surprisingly, it did not get much traction and only received a small number of points. Someone later pointed out that this kind of reading material or public archive is not a great fit for a Show HN submission. There may also have already been a similar effort by someone else, though that version was mainly hosted on GitHub and required Git LFS to download. Hacker News readers know how to use Git LFS, of course, but most normal users do not.

That was one of the reasons I made this package in the first place: not everyone uses Git, and not everyone has Git LFS installed. Many people just want to download the full archive through a browser.

The response on V2EX was much better than I expected. A lot of people said thanks, and many people actually downloaded the package. The backend showed thousands of clicks and hundreds of real downloads.

That gave me another useful confirmation: FastFileLink worked smoothly in a real scenario with a large archive, many files, and many people downloading around the same time. This was not just a local test, and it was not just one or two people opening the link. A real group of users actually downloaded the 3.8GB package.

What this taught me about large-file delivery

On the surface, this project looks like a quick response to a news topic.

But after going through the whole process, I came away with a clearer understanding of large-file delivery. The hard part is often not just that the file is large.

The real issues are things like:

There are many files
The file types are mixed
Source URLs need to be preserved
Downloaders need to know where to start
The content needs explanation
Checksums matter
Legal and attribution notes matter
The download page needs to feel trustworthy
Previewing before download can be important

If you simply drop a folder into a cloud drive, you have to patch together all of these details yourself.

FastFileLink turns delivery into a more complete workflow: upload the folder, customize the page, add the explanation, share the link, and let people download it through a browser.

This public archive was a good example of that workflow.

The final result

In the end, I prepared three versions for different audiences:

English
Traditional Chinese
Simplified Chinese

Each version has its own download page, README, and START_GUIDE.

This was not a UFO research project, and I did not try to interpret the files. My goal was simple: take a batch of official public files and make them easier for normal people to download and start browsing.

I also put the materials I created myself — the README, START_GUIDE, index files, checksums, manifest, and the three download links — on GitHub:

https://github.com/bear0330/war-gov-ufo-uap-release-01

The actual large files are still delivered through FastFileLink. GitHub is a good place for the index, documentation, and verification files. FastFileLink is better suited for delivering the full 3.8GB archive to normal users.

If you have a similar need, such as:

Delivering a large public archive
Sending a full set of video assets
Handing off client project files
Sharing a large collection of photos or original files
Letting someone download a folder through a browser without installing extra tools

that is exactly the kind of situation FastFileLink is designed for.

Sometimes file transfer is not just about sending files out.
Organizing the files, explaining them clearly, and helping the recipient download with confidence is what real delivery looks like.

我用快档连结交付一个 3.8GB、158 个档案的美国战争部 UFO 公开资料包

2026-05-13T10:00:00+08:00

最近，美国 war.gov 开了一个 UFO/UAP 公开档案页面。

官方说，这是回应川普政府对 UAP 相关资讯透明化的要求，由美国战争部（U.S. Department of War, DOW）与其他单位合作，把一批未解决的 UAP 相关纪录与历史文件公开出来。

我看到这个消息时，第一个反应是：「这批资料如果可以一次下载回来看，应该满方便的。」

官方页面虽然可以浏览，但如果你真的想把所有 PDF、视频、图片都下载回来，体验其实不太好。你要一个一个点，还要分辨哪些是文件、哪些是视频、哪些只是页面上的图片。对一般人来说，光是开始下载就已经有点麻烦。

这正好是快档连结想解决的问题：把一批档案整理成一个可以交付、可以下载、可以说明清楚的资料包。

正好我自己也对这批内容很有兴趣，所以就花了一点时间把档案收集下来，也确认再发布这些公开资料的法律风险。确认可以做之后，我就想把它整理好提供给大家下载。

这种资料包其实很适合用快档连结来发布。因为整包有 3.8GB，档案又很多，我还真找不到什么简单的地方可以放。你不可能用 WhatsApp、LINE 这类 IM 软件传给别人；放云端硬盘也会遇到容量、权限、打包下载、流量限制这些问题。于是我就顺手把整个整理与发布过程记录下来。

先把公开档案整理成一个完整资料夹

我先把这次 war.gov UFO/UAP Release 01 里可直接下载的档案整理下来。

最后整理出来的内容大概是这样：

158 个可下载档案
116 份 PDF
28 支视频
14 张图片
总大小约 3.8GB
每个档案都保留来源 URL
产生 SHA-256 checksum
产生索引档与 manifest

我把所有内容放在一个资料夹里：

04_full_release01_pack/

里面除了实际档案，也准备了几个辅助档案：

README.md
START_GUIDE.html
files_index.csv
files_index.jsonl
manifest.json
checksum.sha256
files/

README.md 负责说明这包资料的来源、范围、授权与非官方背书声明。

START_GUIDE.html 则是给一般使用者看的入门导览。这批资料本来就很散，有视频、有图片、有 FBI 相关资料、有 NASA/Apollo 相关资料，也有很大的历史扫描 PDF。一般人下载完，如果只看到一大堆档案，很可能完全不知道从哪里开始。

所以我在 START_GUIDE.html 里做了一个简单的浏览顺序：

先看视频
再看图片
再看比较短的现代 PDF
接着看 FBI 与 NASA/Apollo 相关资料
最后再看大型历史 PDF

这样使用者下载回去之后，至少有一个很简单的入口。

直接用快档连结上传整包资料

整理好资料夹后，接着就是上传。

我登入自己的快档连结账号，把 04_full_release01_pack 整个资料夹上传。这里的重点是，我不用再把它压成一个 ZIP，也不用自己处理一堆档案怎么包、怎么列清单、怎么让下载者取得。

快档连结会直接处理整个资料夹的交付。

一开始上传完，页面长这样：

这是标准下载页。它干净、功能清楚，也能正常下载。

可是我看了一下，觉得它太中性了。

这次的内容是美国战争部 UFO/UAP 公开档案，使用者进来之后，应该要一眼知道自己正在下载什么。尤其这是一个 3.8GB 的大包，如果页面只是一个普通下载框，对方可能会有点不放心。

所以我决定用快档连结的白牌自订功能，帮这个下载页做一个比较符合内容的样子。

用白牌自订功能把下载页变成专属页面

快档连结的白牌自订功能可以设定 logo、背景、颜色、导览列、下载说明、footer 等内容。

我先把 logo 改成白色版本，因为这次页面想走深色背景。接着把背景改成深蓝色科技感的图片，再把主色改成接近 UFO/UAP 主题的冷色系。

调整后的页面大概变成这样：

这样使用者一进来，就会马上知道这是：

美国战争部 UFO/UAP 公开档案
158 个档案
116 份 PDF
28 支视频
14 张图片
附来源 URL、索引档与 SHA-256 checksum

页面底部也放了来源与法律声明：

来源是 war.gov/UFO
这是非官方便利下载包
与美国战争部、美国国防部、AARO、NARA、DVIDS 或任何美国政府机构无合作、赞助、核准或背书关系
本页出现的美国政府视觉资讯，不代表 DoW/DoD 对 FastFileLink 或本网站背书
本资料包只是依公开来源整理，没有主张这些档案证明外星生命存在

这个声明很重要。因为这次使用的是美国政府公开档案，虽然美国联邦政府作品在美国通常属于 public domain，但页面仍然不能让人误会成「官方合作」或「官方背书」。

另外有一个小细节：我的浏览器是中文，所以我看到的下载进度与按钮文字会自动显示中文。英文读者打开同一个页面时，下载界面会依照他的语言环境显示英文。

下载页不只要能下载，也要先让人看懂内容

这次发布后，有人给了一个很实际的回馈：

It'd still be courteous to wait for a click before downloading 4 GB of files. I just wanted to see a description of what's included first.

这句话提醒了我一件事。

对提供档案的人来说，直接打开下载页、开始准备下载很合理。因为目的就是让对方拿到档案。

可是对第一次看到连结的人来说，4GB 不是小档案。他可能只是想先看一下里面有什么，确认来源、大小、内容，再决定要不要下载。

其实快档连结页面上本来就有一个眼睛图示，可以点开 preview，看档案说明和内容资讯。

但我发现，如果我要把这个连结丢到社群或论坛，最好不要让对方一进来就进入下载流程。更好的方式是直接给预览模式连结。

做法很简单：在 URL 后面加上：

?preview=true

例如原本是：

https://0.2.fastfilelink.com/xxxx

就改成：

https://0.2.fastfilelink.com/xxxx?preview=true

这样对方打开后会先看到内容介绍、档案资讯与下载说明，再自己决定要不要开始下载。

对大档案交付来说，这是一个很实用的小技巧。尤其档案一大，使用者的第一个需求往往不是「立刻下载」，而是「先确认这到底是什么」。

把它发到社群后的反应

整理好之后，我把这个下载包发到几个地方试试看。

我先试了 Hacker News。结果意外地没有什么反应，只拿到很少的点数。后来有人提醒我，这种阅读材料或公开资料整理包不太适合用 Show HN 的形式发布。也可能是因为已经有好心人士做过类似整理，只是那个版本主要放在 GitHub 上，要用 Git LFS 下载。Hacker News 的读者当然知道 Git LFS 是什么，但一般人通常不会。

这也是我一开始想做这包的原因之一：不是每个人都会用 Git，不是每个人都会装 Git LFS。很多人只是想用浏览器把整包资料下载回来。

比较意外的是，V2EX 上的反应反而很好。很多人表示感谢，也真的有人下载。后台看到有上千次点击，实际下载也有数百次。

这让我确认了另一件事：快档连结在这种「大档案、多档案、同时很多人下载」的场景下，实际上是可以顺利运作的。这不是只有我自己在本机测试，也不是只有一两个人点开连结，而是实际放到社群后，有一批人真的把 3.8GB 的资料包下载回去。

做完之后，我对「大档交付」有更清楚的感觉

这次整理 UFO/UAP 公开档案，表面上看起来像是追一个新闻热点。

但实际做完后，我更确定一件事：大档交付真正麻烦的地方，常常不只是「档案很大」。

真正麻烦的是：

档案很多
类型混杂
来源要保留
下载者需要知道怎么开始看
内容需要说明
需要 checksum
需要法律与来源声明
下载页要让人信任
最好能先预览，再下载

如果只是把一个资料夹丢到某个云端硬盘里，这些事情都要自己慢慢补。

而快档连结比较像是把「交付」这件事整理成一个流程：上传资料夹、设定页面、补上说明、给对方连结、让对方用浏览器下载。

这次的公开资料包就是一个很好的例子。

最后的成品

最后我做了三个版本，分别给不同语言使用者：

英文版
繁体中文版
简体中文版

每个版本都有自己的下载页，也都有 README 与 START_GUIDE。

这不是一个 UFO 研究项目，我也没有尝试解读这些档案。我的目标很单纯：把官方公开的一批大档案，整理成一般人比较容易下载、比较容易开始看的版本。

另外，我把这次自己整理出来的内容，也就是 README、START_GUIDE、索引档、checksum、manifest，以及三个下载连结，都放在 GitHub 上：

https://github.com/bear0330/war-gov-ufo-uap-release-01

实际的大档案仍然透过快档连结交付。GitHub 比较适合放索引、说明与可查核资料；快档连结则适合把整包 3.8GB 的档案交给一般使用者下载。

如果你也有类似需求，例如：

要交付大型公开资料包
要传一整包视频素材
要交付客户项目档
要分享大量照片与原始档
要让对方不用装工具、直接用浏览器下载

那这正是快档连结适合处理的情境。

有时候，传档不只是把档案丢出去。
把档案整理好、说明清楚、让对方安心下载，才是真正的交付。

我用快檔連結交付一個 3.8GB、158 個檔案的美國戰爭部 UFO 公開資料包

2026-05-13T10:00:00+08:00

最近，美國 war.gov 開了一個 UFO/UAP 公開檔案頁面。

官方說，這是回應川普政府對 UAP 相關資訊透明化的要求，由美國戰爭部（U.S. Department of War, DOW）與其他單位合作，把一批未解決的 UAP 相關紀錄與歷史文件公開出來。

我看到這個消息時，第一個反應是：「這批資料如果可以一次下載回來看，應該滿方便的。」

官方頁面雖然可以瀏覽，但如果你真的想把所有 PDF、影片、圖片都下載回來，體驗其實不太好。你要一個一個點，還要分辨哪些是文件、哪些是影片、哪些只是頁面上的圖片。對一般人來說，光是開始下載就已經有點麻煩。

這正好是快檔連結想解決的問題：把一批檔案整理成一個可以交付、可以下載、可以說明清楚的資料包。

正好我自己也對這批內容很有興趣，所以就花了一點時間把檔案收集下來，也確認再發佈這些公開資料的法律風險。確認可以做之後，我就想把它整理好提供給大家下載。

這種資料包其實很適合用快檔連結來發佈。因為整包有 3.8GB，檔案又很多，我還真找不到什麼簡單的地方可以放。你不可能用 WhatsApp、LINE 這類 IM 軟體傳給別人；放雲端硬碟也會遇到容量、權限、打包下載、流量限制這些問題。於是我就順手把整個整理與發佈過程記錄下來。

先把公開檔案整理成一個完整資料夾

我先把這次 war.gov UFO/UAP Release 01 裡可直接下載的檔案整理下來。

最後整理出來的內容大概是這樣：

158 個可下載檔案
116 份 PDF
28 支影片
14 張圖片
總大小約 3.8GB
每個檔案都保留來源 URL
產生 SHA-256 checksum
產生索引檔與 manifest

我把所有內容放在一個資料夾裡：

04_full_release01_pack/

裡面除了實際檔案，也準備了幾個輔助檔案：

README.md
START_GUIDE.html
files_index.csv
files_index.jsonl
manifest.json
checksum.sha256
files/

README.md 負責說明這包資料的來源、範圍、授權與非官方背書聲明。

START_GUIDE.html 則是給一般使用者看的入門導覽。這批資料本來就很散，有影片、有圖片、有 FBI 相關資料、有 NASA/Apollo 相關資料，也有很大的歷史掃描 PDF。一般人下載完，如果只看到一大堆檔案，很可能完全不知道從哪裡開始。

所以我在 START_GUIDE.html 裡做了一個簡單的瀏覽順序：

先看影片
再看圖片
再看比較短的現代 PDF
接著看 FBI 與 NASA/Apollo 相關資料
最後再看大型歷史 PDF

這樣使用者下載回去之後，至少有一個很簡單的入口。

直接用快檔連結上傳整包資料

整理好資料夾後，接著就是上傳。

我登入自己的快檔連結帳號，把 04_full_release01_pack 整個資料夾上傳。這裡的重點是，我不用再把它壓成一個 ZIP，也不用自己處理一堆檔案怎麼包、怎麼列清單、怎麼讓下載者取得。

快檔連結會直接處理整個資料夾的交付。

一開始上傳完，頁面長這樣：

這是標準下載頁。它乾淨、功能清楚，也能正常下載。

可是我看了一下，覺得它太中性了。

這次的內容是美國戰爭部 UFO/UAP 公開檔案，使用者進來之後，應該要一眼知道自己正在下載什麼。尤其這是一個 3.8GB 的大包，如果頁面只是一個普通下載框，對方可能會有點不放心。

所以我決定用快檔連結的白牌自訂功能，幫這個下載頁做一個比較符合內容的樣子。

用白牌自訂功能把下載頁變成專屬頁面

快檔連結的白牌自訂功能可以設定 logo、背景、顏色、導覽列、下載說明、footer 等內容。

我先把 logo 改成白色版本，因為這次頁面想走深色背景。接著把背景改成深藍色科技感的圖片，再把主色改成接近 UFO/UAP 主題的冷色系。

調整後的頁面大概變成這樣：

這樣使用者一進來，就會馬上知道這是：

美國戰爭部 UFO/UAP 公開檔案
158 個檔案
116 份 PDF
28 支影片
14 張圖片
附來源 URL、索引檔與 SHA-256 checksum

頁面底部也放了來源與法律聲明：

來源是 war.gov/UFO
這是非官方便利下載包
與美國戰爭部、美國國防部、AARO、NARA、DVIDS 或任何美國政府機構無合作、贊助、核准或背書關係
本頁出現的美國政府視覺資訊，不代表 DoW/DoD 對 FastFileLink 或本網站背書
本資料包只是依公開來源整理，沒有主張這些檔案證明外星生命存在

這個聲明很重要。因為這次使用的是美國政府公開檔案，雖然美國聯邦政府作品在美國通常屬於 public domain，但頁面仍然不能讓人誤會成「官方合作」或「官方背書」。

另外有一個小細節：我的瀏覽器是中文，所以我看到的下載進度與按鈕文字會自動顯示中文。英文讀者打開同一個頁面時，下載介面會依照他的語言環境顯示英文。

下載頁不只要能下載，也要先讓人看懂內容

這次發佈後，有人給了一個很實際的回饋：

It'd still be courteous to wait for a click before downloading 4 GB of files. I just wanted to see a description of what's included first.

這句話提醒了我一件事。

對提供檔案的人來說，直接打開下載頁、開始準備下載很合理。因為目的就是讓對方拿到檔案。

可是對第一次看到連結的人來說，4GB 不是小檔案。他可能只是想先看一下裡面有什麼，確認來源、大小、內容，再決定要不要下載。

其實快檔連結頁面上本來就有一個眼睛圖示，可以點開 preview，看檔案說明和內容資訊。

但我發現，如果我要把這個連結丟到社群或論壇，最好不要讓對方一進來就進入下載流程。更好的方式是直接給預覽模式連結。

做法很簡單：在 URL 後面加上：

?preview=true

例如原本是：

https://0.2.fastfilelink.com/xxxx

就改成：

https://0.2.fastfilelink.com/xxxx?preview=true

這樣對方打開後會先看到內容介紹、檔案資訊與下載說明，再自己決定要不要開始下載。

對大檔案交付來說，這是一個很實用的小技巧。尤其檔案一大，使用者的第一個需求往往不是「立刻下載」，而是「先確認這到底是什麼」。

把它發到社群後的反應

整理好之後，我把這個下載包發到幾個地方試試看。

我先試了 Hacker News。結果意外地沒有什麼反應，只拿到很少的點數。後來有人提醒我，這種閱讀材料或公開資料整理包不太適合用 Show HN 的形式發佈。也可能是因為已經有好心人士做過類似整理，只是那個版本主要放在 GitHub 上，要用 Git LFS 下載。Hacker News 的讀者當然知道 Git LFS 是什麼，但一般人通常不會。

這也是我一開始想做這包的原因之一：不是每個人都會用 Git，不是每個人都會裝 Git LFS。很多人只是想用瀏覽器把整包資料下載回來。

比較意外的是，V2EX 上的反應反而很好。很多人表示感謝，也真的有人下載。後台看到有上千次點擊，實際下載也有數百次。

這讓我確認了另一件事：快檔連結在這種「大檔案、多檔案、同時很多人下載」的場景下，實際上是可以順利運作的。這不是只有我自己在本機測試，也不是只有一兩個人點開連結，而是實際放到社群後，有一批人真的把 3.8GB 的資料包下載回去。

做完之後，我對「大檔交付」有更清楚的感覺

這次整理 UFO/UAP 公開檔案，表面上看起來像是追一個新聞熱點。

但實際做完後，我更確定一件事：大檔交付真正麻煩的地方，常常不只是「檔案很大」。

真正麻煩的是：

檔案很多
類型混雜
來源要保留
下載者需要知道怎麼開始看
內容需要說明
需要 checksum
需要法律與來源聲明
下載頁要讓人信任
最好能先預覽，再下載

如果只是把一個資料夾丟到某個雲端硬碟裡，這些事情都要自己慢慢補。

而快檔連結比較像是把「交付」這件事整理成一個流程：上傳資料夾、設定頁面、補上說明、給對方連結、讓對方用瀏覽器下載。

這次的公開資料包就是一個很好的例子。

最後的成品

最後我做了三個版本，分別給不同語言使用者：

英文版
正體中文版
簡體中文版

每個版本都有自己的下載頁，也都有 README 與 START_GUIDE。

這不是一個 UFO 研究專案，我也沒有嘗試解讀這些檔案。我的目標很單純：把官方公開的一批大檔案，整理成一般人比較容易下載、比較容易開始看的版本。

另外，我把這次自己整理出來的內容，也就是 README、START_GUIDE、索引檔、checksum、manifest，以及三個下載連結，都放在 GitHub 上：

https://github.com/bear0330/war-gov-ufo-uap-release-01

實際的大檔案仍然透過快檔連結交付。GitHub 比較適合放索引、說明與可查核資料；快檔連結則適合把整包 3.8GB 的檔案交給一般使用者下載。

如果你也有類似需求，例如：

要交付大型公開資料包
要傳一整包影片素材
要交付客戶專案檔
要分享大量照片與原始檔
要讓對方不用裝工具、直接用瀏覽器下載

那這正是快檔連結適合處理的情境。

有時候，傳檔不只是把檔案丟出去。
把檔案整理好、說明清楚、讓對方安心下載，才是真正的交付。

How ffl Differs from CLI File Transfer Tools Like croc and Magic Wormhole

2026-05-07T10:30:00+08:00

If you often move files from the terminal, you have probably heard of tools like croc, Magic Wormhole, portal, or sendme. They all solve the same basic problem: getting a file from one machine to another.

Most file transfer tools fall into two broad categories:

P2P transfer tools
These try to connect the sender and receiver directly. When a direct path is not available, some of them fall back to a relay. Magic Wormhole, portal, and sendme belong to this general category. croc is more relay-first, which helps avoid many NAT and firewall problems.
Cloud-upload tools
These upload the file to a server first, then give the recipient a download link. Tools and services like transfer.sh, WeTransfer, and file.io follow this model.

In everyday use, most people are already familiar with the second category: Google Drive, Dropbox, WeTransfer, and similar services. The reason is simple: the recipient does not need to install anything. They receive a link and download the file.

CLI transfer tools have a different strength. They are fast, simple, automation-friendly, and great for temporary transfers. But many of them share one limitation: the receiver usually needs to install the same tool too.

For example, croc is very convenient, but both sides need croc. Magic Wormhole also expects both sides to participate in the same wormhole workflow. That is fine when you are moving files between your own machines. It becomes less convenient when you need to send something to a client, a teammate, a phone user, or a group of people.

So what makes ffl different?

ffl is the CLI version of FastFileLink. Its core idea is simple: from the terminal, turn files, folders, or even stdin streams into an HTTPS download link that anyone can open.

The main difference: ffl gives the receiver an HTTPS link

The mental model of ffl looks like this:

ffl file.zip
→ creates an HTTPS link
→ the recipient downloads it with a browser, curl, wget, or ffl

The recipient does not need to install ffl first. If they have a browser, they can download the file. If they are on a server, they can use curl or wget. This changes the shape of the whole transfer flow.

Most CLI transfer tools are built around a paired session:

sender terminal  <->  receiver terminal

ffl is closer to creating a reusable delivery point:

sender creates an HTTPS link
recipient A downloads
recipient B downloads
recipient C downloads later

That is why ffl naturally fits one-to-many delivery, repeated downloads, and resumable downloads. It is useful for “send this from one of my machines to another,” and it is also built for “deliver this file to someone else.”

Quick comparison

✅ Supported / suitable　❌ Not supported / not suitable　➖ Depends, or not the main workflow

Key point	ffl	croc	Magic Wormhole	sendme	transfer.sh / WeTransfer
Receiver needs to install a tool	✅ No, browser is enough	❌ Yes	❌ Yes	❌ Yes	✅ No
Download with `curl` / `wget`	✅ Yes	❌ No	❌ No	❌ No	✅ Yes
Main handoff model	✅ HTTPS link	🔑 Code phrase	🔑 Code phrase	🎫 Ticket / CLI	☁️ Cloud link
One-to-many delivery	✅ Natural	❌ Not suitable	❌ Not suitable	❌ Not suitable	✅ Yes
Repeated downloads from the same share	✅ Yes	➖ Not the main model	➖ Not the main model	➖ Not the main model	✅ Yes
Direct P2P	✅ WebRTC P2P	➖ Mostly relay-based	➖ Can try direct paths	✅ Yes	❌ No
Fallback when direct fails	✅ HTTPS relay / tunnel	✅ Relay	✅ Transit relay	✅ Relay	➖ Already cloud-hosted
Relay impact on speed	✅ Direct path avoids an extra hop; fallback only when needed	➖ Often depends on relay location and bandwidth	➖ Depends on the path	✅ Good when direct works	➖ Depends on the cloud service and region
E2EE	✅ Supported	✅ Supported	✅ Supported	✅ Transport encryption / protocol integrity	➖ Depends on the service
Recipient verification model	✅ OTP / PubKey / Basic Auth, etc.	🔑 The code is the pairing mechanism	🔑 Wormhole code	🎫 Ticket	➖ Mostly link or account permissions
Cloud upload / sender can go offline	✅ Supported with upload mode	❌ No	❌ No	❌ No	✅ Main workflow
Resume interrupted downloads	✅ Yes	✅ Yes	➖ Depends	✅ Yes	➖ Depends on the service
Folder transfer	✅ Yes	✅ Yes	✅ Yes	✅ Yes	➖ Usually needs zipping first
Distribution model	✅ APE single file + native builds	✅ Go binary per platform	➖ Python package / OS package	✅ Rust, installed per platform	✅ Web service

Why WebRTC matters for speed and routing

ffl tries WebRTC P2P by default. When a direct path works, data flows from the sender to the receiver without going through a relay. For large files, avoiding an extra hop can make a real difference.

When P2P is not available, ffl automatically falls back to HTTPS relay / tunnel mode. The transfer can still continue instead of failing because of NAT or firewall restrictions. If the recipient uses a browser or curl, they use the HTTPS path. If the recipient also uses ffl, it can try WebRTC first.

croc leans more toward a relay-first design. That makes it very good at getting through NAT, but transfer speed can depend heavily on the relay’s location, bandwidth, and route. When you are moving large files across countries, corporate networks, or cloud regions, that difference can matter.

Tools like sendme also have strong modern P2P capabilities. The main difference is still on the receiver side: the recipient needs the matching tool or ticket workflow, while ffl can simply hand out a standard HTTPS download link.

Where tools like croc shine

croc has a very clear strength: once both devices have it installed, you can pair them with a code and move a file quickly. For engineers, it is great for sending something from a laptop to a remote host, from a work machine to a home machine, or between two machines you control.

Magic Wormhole has a similar appeal. Its code phrase is easy to communicate verbally, and its security model is mature. It works well when both sides are comfortable using the same CLI workflow.

The sweet spot for these tools is:

both sides understand CLI
both sides can install the tool
the transfer is a one-time paired session

If that is your situation, croc and Magic Wormhole are excellent tools.

Where ffl fits better

ffl is more useful when the situation looks like this:

I need to send a file to someone who does not use CLI
I want the recipient to download from a browser
I want to share one link with multiple people
I want interrupted downloads to resume
I want curl / wget support for automation
I want both P2P speed and fallback reliability

In these cases, the HTTPS link is the key advantage.

You do not need to check whether the recipient installed the right tool. You do not need to explain a code phrase flow. You send a link. The recipient can be on a browser, a phone, a server, or a CI job, and there is still a natural way to receive the file.

How it differs from cloud-upload tools

Services like transfer.sh, WeTransfer, and file.io also give you download links. Their usual flow is:

upload the file to a server
then let the recipient download it

That is convenient, but it also means the file is stored on a service first. Large files have to finish uploading before the recipient can download them. Privacy, retention, and availability depend on the service provider.

ffl gives you more flexibility. It can try WebRTC P2P first, then fall back when needed. If the sender needs to go offline, upload mode can turn it into a temporary hosted delivery link.

That covers two common workflows:

both sides online: prefer P2P
not online at the same time: use upload mode for temporary delivery

With E2EE enabled, the relay or temporary storage server cannot read the file contents.

APE: why portable single-file distribution matters

Besides native builds, ffl also provides an APE version. APE stands for Actually Portable Executable, from the Cosmopolitan ecosystem. In plain terms, it is a single executable format designed to run across multiple operating systems whenever possible.

This is different from the usual Go or Rust single-binary story. Go and Rust tools often produce one executable per target platform:

linux-amd64
linux-arm64
macos-arm64
windows-amd64.exe
...

The APE experience is closer to this:

download ffl.com
put it on a USB drive, home directory, shared folder, or toolbox
run it when needed

That is useful for DevOps work, emergency debugging, customer environments, containers, and machines where you do not have permission to install packages. You do not need a package manager, and you do not need to set up a runtime on the target machine.

APE also makes ffl unusually convenient as an embeddable transfer engine. The official Android app and the MCP Server both use the APE build as the core engine. The outer application handles the phone, AI agent, or server integration, while the same ffl.com engine handles transfer.

Practical DevOps scenarios where ffl feels different

1. Pull a result out of a container

You run a task inside a container and it produces a report, model, log bundle, or test artifact. The usual options may involve mounting a volume, setting up SCP, fixing permissions, or uploading to cloud storage first.

With ffl, you can run:

ffl /output/report.zip

It prints an HTTPS link. You can open it from your browser or download it from another machine with curl. The more temporary the container environment is, the more useful this becomes.

2. Stream a MySQL backup directly to someone or another machine

Database backups often create huge .sql files. You may not want to write the file locally first and then upload it somewhere.

You can stream directly into ffl:

mysqldump production_db | ffl - --name production_backup.sql

The recipient can download it from a browser, or receive it from another machine with ffl or curl. This is also useful when the output is part of a larger pipeline.

3. Share a large CI artifact with a reviewer

Some build artifacts are too large or too temporary to put into GitHub Actions artifacts, S3, or an internal file service. Examples include debug builds, benchmark results, model weights, and compressed log bundles.

From a CI runner or temporary build server:

ffl build/output/

Then send the link to the reviewer. They open it in a browser. They do not need to know anything about the CI runner.

4. Move files from locked-down machines

Production machines and customer environments often do not allow installing extra packages. They may not have Python, Node, or a convenient package manager.

A portable ffl.com binary is useful here. You can keep it in an internal tools directory, on a USB drive, on a jump box, or fetch it temporarily. Run it when needed, delete it when done.

5. Send technical files to non-engineers

This happens more often than people expect. You may need to send logs, videos, datasets, model outputs, design assets, or diagnostic bundles to a PM, customer, QA person, or external partner.

With croc, the other person also needs croc. With cloud drives, you may need to upload first, set permissions, and wait for sync.

With ffl, you send an HTTPS link. They download it from a browser. That is the simplest value proposition.

Which one should you choose?

If you are moving files between two machines you control, and both sides can install a CLI tool, croc, Magic Wormhole, and sendme are all mature choices.

If you are sending files to general users, clients, teammates, or multiple recipients, ffl feels more natural because the receiver gets a normal download link.

If your only goal is to upload a file to the cloud and let someone download it later, tools like transfer.sh and WeTransfer can do the job. They simply do not provide the same P2P-first path or the same portable CLI delivery-engine model.

Summary

The shortest way to describe ffl is:

It turns CLI file transfer into HTTPS link delivery.

That gives it a clear distinction from paired one-to-one tools like croc and Magic Wormhole. The receiver does not need to install anything. The same link can be downloaded by multiple people. The file can be received with a browser, curl, wget, or ffl.

With WebRTC P2P, relay fallback, E2EE, upload mode, and portable APE distribution, ffl works both as a daily CLI tool and as a practical file-delivery building block for automation.

For a more detailed feature-by-feature breakdown, see the Wiki detailed comparison.

Want to try it? Download the CLI version.

ffl 和 croc、Magic Wormhole 这类 CLI 传档工具差在哪？

2026-05-07T10:30:00+08:00

如果你常在终端机里传档，应该多少听过 croc、Magic Wormhole、portal、sendme 这类工具。它们都解决同一个基本问题：把档案从一台机器送到另一台机器。

主流传档方式大致可以分成两大类：

P2P 传输工具
尽量让两端直接连线传档。如果直连失败，有些工具会改走 relay。Magic Wormhole、portal、sendme 都属于这个方向。croc 则比较偏 relay-first，用 relay 来避开 NAT 和防火墙带来的麻烦。
云端上传型工具
先把档案上传到服务器，再给接收者下载连结。像 transfer.sh、WeTransfer、file.io 这类服务都属于这个模式。

平常大家最常用的其实是第二类，例如 Google Drive、Dropbox、WeTransfer。原因很简单：接收端不用装东西，拿到连结就能下载。

CLI 传档工具通常有另一个优点：速度快、流程短、适合工程师、自动化和临时传输。但它们也常有一个共同限制：接收端通常也要安装同一个工具。

例如 croc 很好用，但两边都要有 croc。Magic Wormhole 也一样，双方都要进入同一套 wormhole 流程。这对自己的两台机器之间传档很方便，但如果你要把档案传给客户、同事、手机使用者，或者一群人，就容易卡住。

那么 ffl 有什么不同？

ffl 是「快档连结 FastFileLink」的 CLI 版。它的核心想法很直接：在终端机里把档案、资料夹，甚至 stdin stream 变成一个可以直接打开的 HTTPS 下载连结。

ffl 的核心差异：接收端拿到的是 HTTPS 连结

ffl 的心智模型比较接近：

ffl file.zip
→ 产生一个 HTTPS link
→ 对方用 browser / curl / wget / ffl 下载

接收端不需要先安装 ffl。如果他有浏览器，就能下载。如果他在 server 上，可以直接用 curl 或 wget。这一点让整个传输模式变得很不同。

多数 CLI 传档工具比较像一次配对：

sender terminal  <->  receiver terminal

ffl 则比较像建立一个可下载的交付入口：

sender creates HTTPS link
recipient A downloads
recipient B downloads
recipient C downloads later

这也是为什么 ffl 天生适合一对多、多次下载、可续传的情境。它不是只为「我的两台电脑互传」设计，也适合「我要把这份档案交给别人」这种更接近交付的场景。

快速比较

✅ 支援 / 适合　❌ 不支援 / 不适合　➖ 视情况或不是主要模式

重点	ffl	croc	Magic Wormhole	sendme	transfer.sh / WeTransfer
接收端需要安装工具	✅ 不需要，浏览器即可	❌ 需要	❌ 需要	❌ 需要	✅ 不需要
可用 `curl` / `wget` 下载	✅ 支援	❌ 不支援	❌ 不支援	❌ 不支援	✅ 支援
主要交付方式	✅ HTTPS 连结	🔑 口令配对	🔑 口令配对	🎫 ticket / CLI	☁️ 云端连结
一对多下载	✅ 很自然	❌ 不适合	❌ 不适合	❌ 不适合	✅ 支援
多次下载同一份档案	✅ 支援	➖ 非主要模式	➖ 非主要模式	➖ 非主要模式	✅ 支援
直连 P2P	✅ WebRTC P2P	➖ 主要走 relay	➖ 可尝试直连	✅ 支援	❌ 不支援
直连失败后 fallback	✅ 自动切到 HTTPS relay / tunnel	✅ relay	✅ transit relay	✅ relay	➖ 原本就上传到云端
relay 对速度的影响	✅ 直连时少一段中转；失败才 fallback	➖ 常走 relay，速度受中转位置影响	➖ 视连线路径	✅ 直连时较佳	➖ 看云端服务与地区
E2EE	✅ 支援	✅ 支援	✅ 支援	✅ 传输层加密 / protocol integrity	➖ 视服务而定
收件者验证模型	✅ OTP / PubKey / Basic Auth 等	🔑 口令本身是配对方式	🔑 wormhole code	🎫 ticket	➖ 主要靠 link 或账号权限
上传云端 / 发送端可离线	✅ upload mode 支援	❌ 不支援	❌ 不支援	❌ 不支援	✅ 主要模式
中断续传	✅ 支援	✅ 支援	➖ 视情况	✅ 支援	➖ 视服务而定
传资料夹	✅ 支援	✅ 支援	✅ 支援	✅ 支援	➖ 通常要先压缩
分发方式	✅ APE 单档 + native builds	✅ Go 单档，依平台下载	➖ Python package / OS package	✅ Rust，依平台安装	✅ Web service

WebRTC 对速度和路径有什么影响？

ffl 默认会尝试 WebRTC P2P。打得通时，资料直接从发送端流到接收端，中间不必绕过 relay。对大档案来说，少一段中转通常很有感。

如果 P2P 打不通，ffl 会自动 fallback 到 HTTPS relay / tunnel，下载仍然能继续，不会因为 NAT 或防火墙卡住整个流程。接收端如果用浏览器或 curl，走的是 HTTPS 路径；如果接收端也用 ffl，可以优先尝试 WebRTC。

croc 的设计则比较偏 relay-first。这让它很好穿透 NAT，但速度会比较依赖 relay 的位置、带宽和路由。跨国、公司网络、云端机房之间传大档时，这个差异会变得明显。

sendme 这类工具也有现代 P2P 能力，技术上很强。不过接收端仍然需要使用对应工具或 ticket 流程，没有 ffl 这种直接给标准 HTTPS 下载连结的接收体验。

croc 这类工具强在哪？

croc 的优点很明确：两台装置都装好后，用一组 code 配对，传档流程很顺。对工程师来说，从自己的笔电传到远端主机、从公司电脑传到家里电脑，这类一对一场景很适合。

Magic Wormhole 也有类似优势。它的 code phrase 很适合口头传递，安全模型成熟，适合双方都愿意使用同一套 CLI 工具的情境。

这些工具最大的甜蜜点是：

两边都懂 CLI
两边都能安装工具
一次传完就结束

如果你的需求刚好是这样，croc 和 Magic Wormhole 都很好。

ffl 更适合哪种情境？

ffl 的优势出现在另一种场景：

我想传档给不懂 CLI 的人
我想让对方直接用浏览器下载
我想把同一个连结给多个人
我希望下载中断后可以续传
我想用 curl / wget 放进自动化流程
我想同时保有 P2P 直连和 fallback 的可靠性

这些需求一出现，HTTPS link 的价值就变明显。

你不需要确认对方有没有装工具，也不需要教对方输入口令。你只要给他一个连结。对方使用浏览器、手机、server、CI job，都有自然的接收方式。

跟云端上传型工具差在哪？

transfer.sh、WeTransfer、file.io 这类服务也能产生下载连结。它们的流程通常是：

先上传到服务器
再让对方下载

这很方便，但也代表档案一定先经过服务端储存。大档案会先等上传完成，隐私和保留期限也取决于服务提供者。

ffl 的策略更弹性。它可以先尝试 WebRTC P2P 直连，直连不行再 fallback。需要让发送端离线时，也可以使用 upload mode，让它变成临时下载连结。

这让它同时覆盖了两种常见需求：

双方都在线：优先 P2P 直连
双方不同时在线：upload mode 临时交付

如果再搭配 E2EE，relay 或暂存服务器也无法读取内容。

APE：为什么单档可携很重要？

ffl 除了 native builds，也提供 APE 版本。APE 是 Actually Portable Executable 的缩写，来自 Cosmopolitan 生态。简单说，它是一种「单一可执行档，尽量跨多个操作系统直接跑」的格式。

这跟一般 Go / Rust 工具也有差异。Go 或 Rust 常常可以编成单一 binary，但通常还是要依照平台下载不同版本：

linux-amd64
linux-arm64
macos-arm64
windows-amd64.exe
...

APE 的体验比较像：

下载 ffl.com
放进 USB、家目录、共享资料夹或工具包
需要时直接执行

对 DevOps、临时救援、客户环境、container、没有安装权限的机器很有用。你不一定要先安装 package manager，也不用在目标机器上建一堆 runtime。

这也让 ffl 的可嵌入能力比较特殊。官方 Android App 和 MCP Server 都是把 APE 版本当成核心 engine 使用。外层负责手机、AI agent 或服务端整合，底层仍然是同一个 ffl.com。

几个很有感的 DevOps 场景

1. 从 container 里把结果拉出来

你在 container 里跑了一个任务，产生了报表、模型、log bundle 或测试 artifact。一般做法可能要挂 volume、开 SCP、设权限，或者先传到云端。

用 ffl 可以直接：

ffl /output/report.zip

它印出一个 HTTPS link，你在本机浏览器或另一台机器用 curl 下载即可。container 环境越临时，这种方式越省事。

2. 把 MySQL 备份直接交给同事或另一台机器

备份数据库时，不一定想先落地一个巨大 .sql 档再上传。你可以把 stream 直接交给 ffl：

mysqldump production_db | ffl - --name production_backup.sql

对方可以用浏览器下载，也可以在另一台机器用 ffl 或 curl 接。需要还原时也可以搭配 stdout 流水线处理。

3. CI job 产生大型 artifact，临时分享给 reviewer

有些 build artifact 太大，不想塞进 GitHub Actions artifact、S3 或内部档案服务。尤其是 debug build、benchmark result、模型权重、压缩后的 log bundle。

在 CI 或临时 build server 里跑：

ffl build/output/

然后把 link 丢给 reviewer。对方用浏览器开，不需要知道 CI runner 里发生什么事。

4. 线上机器不能装太多东西，但需要临时传档

很多 production 或客户环境不适合安装额外套件，也不一定有 Python、Node、Go runtime。APE 单档在这种时候很方便。

你可以把 ffl.com 放在内部工具目录、USB、跳板机，或用一次性的方式抓下来。需要传档时执行，用完就删掉。

5. 把档案交给「不是工程师」的人

这点看似普通，其实很常见。你要把 log、视频、资料包、模型输出、设计素材交给 PM、客户、测试人员或外部厂商。

如果用 croc，对方也要装 croc。如果用云端硬盘，可能要先上传、设权限、等同步。

ffl 给对方一个 HTTPS link。对方用浏览器下载。这就是它最直接的价值。

什么时候选哪个？

如果你只是在两台自己控制的机器之间传档，而且两边都能装 CLI，croc、Magic Wormhole、sendme 都是成熟选择。

如果你要传给一般使用者、客户、同事，或者希望一个连结可以被多人、多次下载，ffl 会更自然。

如果你只需要把档案丢到云端，等对方之后下载，transfer.sh、WeTransfer 这类工具也可以完成任务。只是这类工具通常没有 P2P 直连，也比较不像一个便携式 CLI delivery engine。

小结

ffl 的特色可以用一句话概括：

它把 CLI 传档做成 HTTPS link delivery。

这让它和 croc、Magic Wormhole 这类一对一配对工具有明确区隔。接收端不必安装工具，同一个连结可以给多人下载，也能用浏览器、curl、wget 或 ffl 接收。

加上 WebRTC P2P、fallback relay、E2EE、upload mode、APE 单档可携，ffl 更像是一个可以日常使用、也能放进自动化流程里的档案交付工具。

想看更完整的逐项比较，可以看 Wiki 里的详细比较。

想试试看？可以到 FastFileLink CLI 下载。

ffl 和 croc、Magic Wormhole 這類 CLI 傳檔工具差在哪？

2026-05-07T10:30:00+08:00

如果你常在終端機裡傳檔，應該多少聽過 croc、Magic Wormhole、portal、sendme 這類工具。它們都解決同一個基本問題：把檔案從一台機器送到另一台機器。

主流傳檔方式大致可以分成兩大類：

P2P 傳輸工具
盡量讓兩端直接連線傳檔。如果直連失敗，有些工具會改走 relay。Magic Wormhole、portal、sendme 都屬於這個方向。croc 則比較偏 relay-first，用 relay 來避開 NAT 和防火牆帶來的麻煩。
雲端上傳型工具
先把檔案上傳到伺服器，再給接收者下載連結。像 transfer.sh、WeTransfer、file.io 這類服務都屬於這個模式。

平常大家最常用的其實是第二類，例如 Google Drive、Dropbox、WeTransfer。原因很簡單：接收端不用裝東西，拿到連結就能下載。

CLI 傳檔工具通常有另一個優點：速度快、流程短、適合工程師、自動化和臨時傳輸。但它們也常有一個共同限制：接收端通常也要安裝同一個工具。

例如 croc 很好用，但兩邊都要有 croc。Magic Wormhole 也一樣，雙方都要進入同一套 wormhole 流程。這對自己的兩台機器之間傳檔很方便，但如果你要把檔案傳給客戶、同事、手機使用者，或者一群人，就容易卡住。

那麼 ffl 有什麼不同？

ffl 是「快檔連結 FastFileLink」的 CLI 版。它的核心想法很直接：在終端機裡把檔案、資料夾，甚至 stdin stream 變成一個可以直接打開的 HTTPS 下載連結。

ffl 的核心差異：接收端拿到的是 HTTPS 連結

ffl 的心智模型比較接近：

ffl file.zip
→ 產生一個 HTTPS link
→ 對方用 browser / curl / wget / ffl 下載

接收端不需要先安裝 ffl。如果他有瀏覽器，就能下載。如果他在 server 上，可以直接用 curl 或 wget。這一點讓整個傳輸模式變得很不同。

多數 CLI 傳檔工具比較像一次配對：

sender terminal  <->  receiver terminal

ffl 則比較像建立一個可下載的交付入口：

sender creates HTTPS link
recipient A downloads
recipient B downloads
recipient C downloads later

這也是為什麼 ffl 天生適合一對多、多次下載、可續傳的情境。它不是只為「我的兩台電腦互傳」設計，也適合「我要把這份檔案交給別人」這種更接近交付的場景。

快速比較

✅ 支援 / 適合　❌ 不支援 / 不適合　➖ 視情況或不是主要模式

重點	ffl	croc	Magic Wormhole	sendme	transfer.sh / WeTransfer
接收端需要安裝工具	✅ 不需要，瀏覽器即可	❌ 需要	❌ 需要	❌ 需要	✅ 不需要
可用 `curl` / `wget` 下載	✅ 支援	❌ 不支援	❌ 不支援	❌ 不支援	✅ 支援
主要交付方式	✅ HTTPS 連結	🔑 口令配對	🔑 口令配對	🎫 ticket / CLI	☁️ 雲端連結
一對多下載	✅ 很自然	❌ 不適合	❌ 不適合	❌ 不適合	✅ 支援
多次下載同一份檔案	✅ 支援	➖ 非主要模式	➖ 非主要模式	➖ 非主要模式	✅ 支援
直連 P2P	✅ WebRTC P2P	➖ 主要走 relay	➖ 可嘗試直連	✅ 支援	❌ 不支援
直連失敗後 fallback	✅ 自動切到 HTTPS relay / tunnel	✅ relay	✅ transit relay	✅ relay	➖ 原本就上傳到雲端
relay 對速度的影響	✅ 直連時少一段中轉；失敗才 fallback	➖ 常走 relay，速度受中轉位置影響	➖ 視連線路徑	✅ 直連時較佳	➖ 看雲端服務與地區
E2EE	✅ 支援	✅ 支援	✅ 支援	✅ 傳輸層加密 / protocol integrity	➖ 視服務而定
收件者驗證模型	✅ OTP / PubKey / Basic Auth 等	🔑 口令本身是配對方式	🔑 wormhole code	🎫 ticket	➖ 主要靠 link 或帳號權限
上傳雲端 / 發送端可離線	✅ upload mode 支援	❌ 不支援	❌ 不支援	❌ 不支援	✅ 主要模式
中斷續傳	✅ 支援	✅ 支援	➖ 視情況	✅ 支援	➖ 視服務而定
傳資料夾	✅ 支援	✅ 支援	✅ 支援	✅ 支援	➖ 通常要先壓縮
分發方式	✅ APE 單檔 + native builds	✅ Go 單檔，依平台下載	➖ Python package / OS package	✅ Rust，依平台安裝	✅ Web service

WebRTC 對速度和路徑有什麼影響？

ffl 預設會嘗試 WebRTC P2P。打得通時，資料直接從發送端流到接收端，中間不必繞過 relay。對大檔案來說，少一段中轉通常很有感。

如果 P2P 打不通，ffl 會自動 fallback 到 HTTPS relay / tunnel，下載仍然能繼續，不會因為 NAT 或防火牆卡住整個流程。接收端如果用瀏覽器或 curl，走的是 HTTPS 路徑；如果接收端也用 ffl，可以優先嘗試 WebRTC。

croc 的設計則比較偏 relay-first。這讓它很好穿透 NAT，但速度會比較依賴 relay 的位置、頻寬和路由。跨國、公司網路、雲端機房之間傳大檔時，這個差異會變得明顯。

sendme 這類工具也有現代 P2P 能力，技術上很強。不過接收端仍然需要使用對應工具或 ticket 流程，沒有 ffl 這種直接給標準 HTTPS 下載連結的接收體驗。

croc 這類工具強在哪？

croc 的優點很明確：兩台裝置都裝好後，用一組 code 配對，傳檔流程很順。對工程師來說，從自己的筆電傳到遠端主機、從公司電腦傳到家裡電腦，這類一對一場景很適合。

Magic Wormhole 也有類似優勢。它的 code phrase 很適合口頭傳遞，安全模型成熟，適合雙方都願意使用同一套 CLI 工具的情境。

這些工具最大的甜蜜點是：

兩邊都懂 CLI
兩邊都能安裝工具
一次傳完就結束

如果你的需求剛好是這樣，croc 和 Magic Wormhole 都很好。

ffl 更適合哪種情境？

ffl 的優勢出現在另一種場景：

我想傳檔給不懂 CLI 的人
我想讓對方直接用瀏覽器下載
我想把同一個連結給多個人
我希望下載中斷後可以續傳
我想用 curl / wget 放進自動化流程
我想同時保有 P2P 直連和 fallback 的可靠性

這些需求一出現，HTTPS link 的價值就變明顯。

你不需要確認對方有沒有裝工具，也不需要教對方輸入口令。你只要給他一個連結。對方使用瀏覽器、手機、server、CI job，都有自然的接收方式。

跟雲端上傳型工具差在哪？

transfer.sh、WeTransfer、file.io 這類服務也能產生下載連結。它們的流程通常是：

先上傳到伺服器
再讓對方下載

這很方便，但也代表檔案一定先經過服務端儲存。大檔案會先等上傳完成，隱私和保留期限也取決於服務提供者。

ffl 的策略更彈性。它可以先嘗試 WebRTC P2P 直連，直連不行再 fallback。需要讓發送端離線時，也可以使用 upload mode，讓它變成臨時下載連結。

這讓它同時覆蓋了兩種常見需求：

雙方都在線：優先 P2P 直連
雙方不同時在線：upload mode 臨時交付

如果再搭配 E2EE，relay 或暫存伺服器也無法讀取內容。

APE：為什麼單檔可攜很重要？

ffl 除了 native builds，也提供 APE 版本。APE 是 Actually Portable Executable 的縮寫，來自 Cosmopolitan 生態。簡單說，它是一種「單一可執行檔，盡量跨多個作業系統直接跑」的格式。

這跟一般 Go / Rust 工具也有差異。Go 或 Rust 常常可以編成單一 binary，但通常還是要依照平台下載不同版本：

linux-amd64
linux-arm64
macos-arm64
windows-amd64.exe
...

APE 的體驗比較像：

下載 ffl.com
放進 USB、家目錄、共享資料夾或工具包
需要時直接執行

對 DevOps、臨時救援、客戶環境、container、沒有安裝權限的機器很有用。你不一定要先安裝 package manager，也不用在目標機器上建一堆 runtime。

這也讓 ffl 的可嵌入能力比較特殊。官方 Android App 和 MCP Server 都是把 APE 版本當成核心 engine 使用。外層負責手機、AI agent 或服務端整合，底層仍然是同一個 ffl.com。

幾個很有感的 DevOps 場景

1. 從 container 裡把結果拉出來

你在 container 裡跑了一個任務，產生了報表、模型、log bundle 或測試 artifact。一般做法可能要掛 volume、開 SCP、設權限，或者先傳到雲端。

用 ffl 可以直接：

ffl /output/report.zip

它印出一個 HTTPS link，你在本機瀏覽器或另一台機器用 curl 下載即可。container 環境越臨時，這種方式越省事。

2. 把 MySQL 備份直接交給同事或另一台機器

備份資料庫時，不一定想先落地一個巨大 .sql 檔再上傳。你可以把 stream 直接交給 ffl：

mysqldump production_db | ffl - --name production_backup.sql

對方可以用瀏覽器下載，也可以在另一台機器用 ffl 或 curl 接。需要還原時也可以搭配 stdout 流水線處理。

3. CI job 產生大型 artifact，臨時分享給 reviewer

有些 build artifact 太大，不想塞進 GitHub Actions artifact、S3 或內部檔案服務。尤其是 debug build、benchmark result、模型權重、壓縮後的 log bundle。

在 CI 或臨時 build server 裡跑：

ffl build/output/

然後把 link 丟給 reviewer。對方用瀏覽器開，不需要知道 CI runner 裡發生什麼事。

4. 線上機器不能裝太多東西，但需要臨時傳檔

很多 production 或客戶環境不適合安裝額外套件，也不一定有 Python、Node、Go runtime。APE 單檔在這種時候很方便。

你可以把 ffl.com 放在內部工具目錄、USB、跳板機，或用一次性的方式抓下來。需要傳檔時執行，用完就刪掉。

5. 把檔案交給「不是工程師」的人

這點看似普通，其實很常見。你要把 log、影片、資料包、模型輸出、設計素材交給 PM、客戶、測試人員或外部廠商。

如果用 croc，對方也要裝 croc。如果用雲端硬碟，可能要先上傳、設權限、等同步。

ffl 給對方一個 HTTPS link。對方用瀏覽器下載。這就是它最直接的價值。

什麼時候選哪個？

如果你只是在兩台自己控制的機器之間傳檔，而且兩邊都能裝 CLI，croc、Magic Wormhole、sendme 都是成熟選擇。

如果你要傳給一般使用者、客戶、同事，或者希望一個連結可以被多人、多次下載，ffl 會更自然。

如果你只需要把檔案丟到雲端，等對方之後下載，transfer.sh、WeTransfer 這類工具也可以完成任務。只是這類工具通常沒有 P2P 直連，也比較不像一個可攜式 CLI delivery engine。

小結

ffl 的特色可以用一句話概括：

它把 CLI 傳檔做成 HTTPS link delivery。

這讓它和 croc、Magic Wormhole 這類一對一配對工具有明確區隔。接收端不必安裝工具，同一個連結可以給多人下載，也能用瀏覽器、curl、wget 或 ffl 接收。

加上 WebRTC P2P、fallback relay、E2EE、upload mode、APE 單檔可攜，ffl 更像是一個可以日常使用、也能放進自動化流程裡的檔案交付工具。

想看更完整的逐項比較，可以看 Wiki 裡的詳細比較。

想試試看？可以到 FastFileLink CLI 下載。

Server Migration Without Extra Disk Space: Streaming Borg Backups with FastFileLink CLI

2026-04-24T10:00:00+08:00

Migrating a production app sounds like a simple copy job until the old server is nearly full.

That is usually when migration becomes urgent. The machine is old, disk space is tight, the new server is only half-prepared, DNS cannot move yet, and the data set is large. If the migration flow still expects the source server to create one more giant tarball before anything can move, the process becomes much harder than it needs to be.

This post is a field report from reworking our own migration flow. The original path was familiar: take a Borg backup, export it as a tar or tar.gz, copy it to the target with scp, and restore it there.

That works fine when disk space is plentiful. It is much less pleasant when the source machine is already under pressure, which is often the exact reason the migration is happening in the first place.

So we moved the transfer layer to FastFileLink CLI and turned the whole operation into a streaming path. The source no longer needs to stage a tarball. The target does not need to download one either. Data flows from the old machine to the new one and lands where it needs to be restored.

This pattern is useful well beyond our own deploy system. If you need to move large backups, restore production data into a development VM, or transfer a one-off archive without prearranged SSH trust, it is a very practical approach.

Our Deployment Model

Internally, we run a lightweight deployment system with a PaaS-like shape. The main entry point is Deploy.py.

It handles install, backup, restore, migrate, update, health checks, and the surrounding operational work. Shared behavior lives in the deployment layer, while each app keeps its own app-specific scripts and settings.

We do not use Kubernetes for this class of workload. The reason is simple: for our current environment, the total complexity is not a good trade. Many of our services are small to medium production apps. We care more about clear single-host operations, readable scripts, predictable recovery, and being able to understand the entire lifecycle from the app directory.

In that context, a structured deployment interface is valuable. Full cluster orchestration would be more machinery than we actually need.

Why App Working Folders Matter

A key design choice in this system is that every app has its own working folder.

That folder contains runtime configuration, container definitions, service scripts, app-level maintenance tools, and the rules for restoring persistent volumes. The database is part of the same operational contract through dumps, backup hooks, or related tooling.

In practice, if we can recreate the following pieces on another machine, the app can usually come up there before any DNS cutover:

Piece	Why it matters
Container definition	Recreates the service process and runtime image
Volumes	Preserves uploads, user data, and other persistent state
Database	Preserves structured application data
Configuration	Recreates domains, ports, paths, secrets, and environment variables
App maintenance tools	Gives the new host the same install, backup, restore, and migrate interface

That is why each app has its own bin tools such as backup, install, restore, and migrate. The global deployment layer invokes them, but the app still owns the app-specific details.

This design is intentionally plain. In production operations, plain is often a strength.

What the Old Migration Flow Looked Like

The old migration flow looked roughly like this:

source server
  -> run Borg backup
  -> export volumes from Borg
  -> create a tar stream or tar file on disk
  -> copy it to the target with scp

target server
  -> receive the archive
  -> extract it
  -> restore database and config
  -> start the app
  -> verify before cutover

That is an easy flow to understand. Borg is a solid backup tool. scp is familiar to almost every operator. Tarballs are easy to inspect.

The real problem is the disk-usage pattern.

The Pain Point: the Source Server Is Already Short on Space

Suppose an app has 80 GB of volume data.

The old path can force the source server to carry all of this at once:

existing application data
+ Borg repository or backup cache
+ exported tar archive
+ optional compressed archive
+ partial transfer file
+ logs and temporary files

That requirement clashes with the reason migrations happen in the first place. The machines that need to be moved tend to be the ones that are already too full, too old, or too awkward to keep extending. Asking that same machine to produce one more large copy of the data is the worst possible requirement.

The more sensible approach is to let the backup output enter the transfer pipeline directly, without landing on the source disk first.

Could rsync Solve This?

If the source data already exists as a directory tree and SSH connectivity between source and target is already in place, rsync remains excellent.

rsync -aHAX --numeric-ids --partial --partial-dir=.rsync-partial \
  /srv/apps/myapp/volumes/ user@target:/srv/apps/myapp/volumes/

It resumes, preserves metadata, and is very good at synchronizing real directories. If migration simply meant "copy the live volumes and start the app somewhere else," rsync would be a very reasonable choice, and in many environments it may well be faster than a relay-capable sharing tool.

Our situation was slightly different. We already take a backup before migration. Once that backup exists, using it as the data source is natural. The new Borg archive is a clean point-in-time snapshot, and borg export-tar gives us a ready-made stdout stream that can be fed straight into a transfer pipeline.

That is an important distinction. Borg is not the reason migration exists here. It is simply the backup mechanism we already use and trust. After the backup finishes, it becomes a convenient source for the migration stream. Whether to transfer the full backup history to the new machine is a separate decision. In many environments it is optional because full-machine backups already exist elsewhere.

The other factor is target flexibility. Sometimes the target is a clean VM or a temporary test environment, and we do not want to deal with SSH keys, sshpass, or extra server-to-server trust setup before moving the first byte.

Under those conditions, a stream-oriented transfer tool is a better fit.

Why FastFileLink CLI Fits So Well

FastFileLink CLI can transfer files, folders, and stdin. That is the capability that changed the design.

Instead of exporting to a tarball and then copying that tarball, we can keep the data moving the entire time:

borg export-tar -> stdout -> FastFileLink CLI -> stdout on target -> tar extract

The source does not need to stage a tarball. The target does not need to download one either.

The sender side looks like this:

borg export-tar "$BORG_REPO::$ARCHIVE" - \
  | "$FFL" - \
      --name "$APP_NAME-volumes.tar" \
      --e2ee \
      --stdin-cache off \
      --max-downloads 1 \
      --pickup-code "$PICKUP_CODE"

The receiver side sends the stream straight into tar:

"$FFL" download "$LINK" \
  --pickup-code "$PICKUP_CODE" \
  --e2ee \
  --stdout \
  | tar xvf - -C "$RESTORE_ROOT"

That gives us exactly the shape we wanted:

source server: no exported archive on disk
target server: no downloaded archive on disk
transfer path: data streams directly into the target layout

That command shape is intentionally plain tar. borg export-tar produces a tar stream here, so the transfer is named .tar, and the receiver uses tar xvf -. If you want gzip in the middle, it is better to write it explicitly, for example borg export-tar ... - | gzip -c | ffl ..., and then extract with tar xzvf - on the target.

We kept gzip out of the main example on purpose. In this migration, the primary problem was extra disk usage, not compression ratio, and a plain tar stream keeps CPU cost and troubleshooting overhead lower on both ends.

For low-space migration, that is the real win.

What `--stdin-cache`, `--stdout`, and `--pickup-code` Are Doing

If you just paste the commands and move on, a lot of readers will not immediately understand why these flags matter.

Start with --pickup-code. It is part of the pairing flow. The sender produces a link, but the receiver still needs the pickup code before it can actually claim the transfer. If you have used croc, this style of short-code trust model will feel familiar. In a migration script, it is convenient because we can hand the link and the code to the target process without exposing an open download endpoint. Once --pickup-code is present, FastFileLink CLI already knows that pickup mode is being used, so there is no need to also spell out --recipient-auth pickup.

FastFileLink CLI is more flexible than that single mode suggests. Besides pickup, it also supports receiver-verification modes such as pubkey, pubkey+pickup, and email, plus traditional HTTP Basic Authentication through --auth-user and --auth-password. We chose pickup here because it is a very smooth fit for a one-off scripted migration.

Next is --stdin-cache off. FastFileLink CLI's default mental model is general-purpose file sharing. Files might be downloaded more than once, or by multiple receivers, so caching is useful there. A migration stream is the opposite. We know there will be a single receiver consuming the data once. Keeping a stdin cache in that scenario only spends extra source-side disk space. Turning the cache off makes the sender behave much more like a real one-shot stream producer.

--e2ee is worth enabling too. WebRTC already runs over secure transport, but migration jobs can fall back to relay or tunnel paths. With end-to-end encryption enabled, even those middle hops only see encrypted chunks. For backup material and production data, that extra protection is well worth having.

Finally, --stdout is what makes the target side clean. The receiver writes the bytes to stdout, and tar unpacks them directly into place. There is no downloaded tarball to clean up afterward.

Put together, the data path becomes very straightforward:

source app backup snapshot
  -> Borg export stream
  -> FastFileLink CLI sender
  -> FastFileLink CLI receiver
  -> tar extracts directly into the target app folder
  -> volumes land in place

How This Fits Back into Deploy.py

We did not build a completely separate migration tool.

The existing Deploy.py migrate flow already knew how to:

prepare the source and target app layout
invoke the app's own migrate and backup scripts
export volumes
dump and restore the database
restore configuration
start the target app and verify it

So the job was to swap out the transfer mechanics while leaving the rest of the workflow intact.

The resulting shape now looks like this:

Deploy.py migrate
  -> app bin/migrate
  -> ExportVolumes from Borg
  -> source streams into FastFileLink CLI
  -> target receives from FastFileLink CLI
  -> volumes extract directly into the target app folder
  -> database and privileges are restored
  -> backup history can also be transferred when desired
  -> target app is installed and started
  -> verification happens before cutover

This also keeps the old file-based path available. If we want to preserve an artifact, debug restore behavior in isolation, or simply keep the older flow for a roomy machine, that option still exists. Streaming mode is there to solve the low-space migration problem.

What FastFileLink CLI Brings to This Case

FastFileLink CLI matches this scenario surprisingly well because it brings several useful properties at once:

Capability	Why it helps migration
Single-file APE binary	Download when needed, delete after use, no permanent install
WebRTC direct transfer	Tries peer-to-peer paths when the network allows it
Relay fallback	Still completes when direct connectivity fails
End-to-end encryption	Relay infrastructure cannot see plaintext data
Pickup-code verification	Scripts can pair sender and receiver safely
`--e2ee`	Relay or tunnel hops still cannot inspect contents
stdin / stdout support	Makes true no-staging transfer possible
`--hook` event output	Integrates cleanly into existing automation

For an old production host, the single-file binary is a bigger advantage than it first sounds. We do not need to permanently install another service just to move away from that machine. Download ffl.com, run the migration, clean it up, and move on.

--hook is also worth calling out on its own. FastFileLink CLI has its own embedded mode, which can emit structured events for integration. That saved us a lot of glue code, because we no longer had to parse human-oriented console output just to understand what the transfer was doing. That kind of integration surface is unusual in this category of tools.

Comparing FastFileLink CLI with scp, rsync, croc, and Magic Wormhole

The real question with transfer tools is not which one has the flashiest feature list. It is whether the tool's assumptions match the environment you are actually operating in.

Tool	Best fit	Limitation in this scenario
`scp`	Straightforward file copy over SSH	Needs a prebuilt artifact and SSH access
`rsync`	Synchronizing live directory trees	Not a natural fit for Borg stdout streams
`croc`	Secure CLI transfer with pipe support	A good fallback option, but large transfers often end up traversing relay infrastructure, which is not very attractive for multi-hundred-megabyte or multi-gigabyte migrations
Magic Wormhole	Human-friendly one-time transfer	Better for ad hoc exchange than unattended migration pipelines
FastFileLink CLI	File, folder, stdin, and stdout streaming	Needs proper orchestration for logs, cleanup, and timeout handling

If the data is already a plain directory tree and SSH trust is stable, rsync remains very strong.

But when the data source is a backup stream and the target might be a fresh VM, FastFileLink CLI feels better aligned with the real constraints. It asks less from the environment while still giving us encryption, verification, direct-transfer attempts, and relay fallback.

The Real Lessons from Implementation

The most valuable lessons did not come from the happy path. They came from the first few attempts, when large transfers could stall and the surrounding automation did not have enough visibility into what was happening.

Our earliest version was the obvious one: start FastFileLink CLI, parse its normal output, grab the link, and let the rest of the wrapper script take it from there. That was fine for a proof of concept. It was not good enough for a real migration command.

Large data transfers make every observability problem feel bigger:

Did the sender actually begin reading stdin?
Did the receiver really connect?
Are we using a direct path or a fallback path?
If both processes are still alive, is progress real or are we just stuck?
Did the producer fail first, or did the transfer tool fail first?

Orchestration Matters More Than the Pipe

Streaming migration is not finished just because we connected a producer and a consumer with one more pipe.

When a file-based transfer fails, there is usually still a partial file sitting on disk. When a stream stalls, the system has to tell us where it stalled. The difference between a neat demo and a production migration command is usually not whether the tool supports stdin. It is whether the orchestration around that tool was designed with observability, cleanup, and retry boundaries in mind.

In practice, we found that a few things have to be designed explicitly:

Concern	Approach
temporary binary	Download `ffl.com` into a temporary directory and remove it afterward
logging	Be able to switch to DEBUG or point to a logging config when a transfer stalls
receiver readiness	Confirm that the target receiver has actually started before letting the workflow continue
progress	Watch bytes transferred or extracted, not just whether the process still exists
cleanup	Remove orphan sender / receiver processes and temporary files
retry	Retry at the transfer boundary instead of trying to resume from the middle of a half-extracted tar stream
secrets	Keep auth passwords and pickup codes out of ordinary logs

We learned this very directly during testing. If the target receiver never really comes up, the source side can still look busy for a while. It may appear to be waiting or doing useful work, even though the migration is already stuck.

So a robust migration command should at least be able to confirm:

source process is alive
target process is alive
target output is growing
logs show an accepted transfer path

For long-running transfers, "the process still exists" is not progress. Progress has to be observable.

Once we switched to FastFileLink CLI's --hook support, things got much smoother. Share links, progress, receiver state, completion, and failure events could all be tracked as structured data. That was the point where we finally stopped treating human-readable output as an API.

That shift matters a lot. Migration automation needs more than bytes moving over the wire. It needs state that can be trusted.

On top of that, we still fixed a few ordinary deploy bugs, such as target path quoting and the cleanup order for old volumes. But those became straightforward engineering issues once the transfer state itself was observable.

After that, the migration path was able to:

stream volumes from Borg through FastFileLink CLI
restore database dumps on the target
restore database privileges
optionally bring over the Borg backup repository
pull the app image
start the target container

The remaining issue in our test was no longer in the streaming layer. It was an Nginx / SSL cleanup detail on the target side. That was actually reassuring: the hardest part of the move had become ordinary deployment finish-up.

You Can Test the Migration Before DNS Moves

A good migration flow should let us validate the new machine before the real cutover happens.

That fits nicely with our app-folder design. Because the container definition, volumes, database, config, and app maintenance tools already belong to the same working-folder contract, we can restore the app onto the new machine, start it with a test port or a temporary hostname, and confirm that it behaves correctly before touching DNS or the load balancer.

In practice, the checklist is fairly simple:

1. Restore app files, volumes, database, and config on the target.
2. Start the target containers or services.
3. Run health checks.
4. Verify static files and uploaded files.
5. Verify database-backed pages and the login flow.
6. Check logs for path, permission, or environment-variable issues.
7. Only then schedule the DNS or load-balancer cutover.

That is one of the reasons migration becomes less scary. The old production server keeps serving traffic while the new machine proves, right next to it, that it is ready to take over.

This Pattern Is Useful Beyond One App

Even though this work grew out of one migration project, the pattern generalizes very well.

Any time the data source can write to stdout, the same transfer model becomes available:

borg export-tar repo::archive -
pg_dump mydb
mysqldump mydb
tar -cf - /large/folder
zfs send pool/dataset@snapshot

Pipe that into FastFileLink CLI:

producer | ffl - --stdin-cache off --max-downloads 1

Then let the target feed it directly into the real consumer:

ffl download "$LINK" --stdout | consumer

That is a good fit for:

migrating old or nearly full servers
restoring production backups into development VMs
disaster recovery transfers
moving large user-upload archives
transferring database dumps without leaving dump files behind
temporary environments where prearranged SSH trust is inconvenient

Final Takeaway

The most important part of this migration change was not a new compression trick or a more elaborate archive format.

It was rewriting the migration contract.

The old contract required the source server to prepare one more large copy of the data before it could move away.

The new version is much simpler:

read the backup stream
transfer it immediately
restore it directly on the target

--stdin-cache off and --stdout fit that model extremely well. For teams dealing with server migration, backup transfer, low-disk hosts, or temporary restore environments, this turns out to be a practical, automation-friendly, and easy-to-reason-about approach.

When the old server is full and migration has become urgent, that is exactly the behavior you want from the toolchain.

不需要额外磁盘空间的服务器迁移：用 FastFileLink 串流 Borg 备份

2026-04-24T10:00:00+08:00

搬一个 production app，表面上像是把资料复制到新机，实际上往往是在跟时间、空间和环境条件搏斗。

最常见的情况是这样：旧机快满了，大家想尽快搬走；新机刚准备好，还没正式接手流量；DNS 不能立刻切；资料量又大。这时如果 migration 流程还要求旧机先多生出一份大型 tarball，通常只会让事情更难推进。

这篇文章整理的是我们最近改造 migration 流程的实战经验。我们本来用的是很典型的做法：先用 Borg 备份，再把备份汇出成 tar 或 tar.gz，接着透过 scp 传到目标机器，最后在新机还原。

那套方式在磁盘空间充裕时很好用，也很好调试。问题出在它对来源机器的空间要求太高。偏偏真正急着搬的主机，通常就是空间最吃紧的那一台。

所以我们把传输层改成以 FastFileLink CLI 为核心，让资料从 Borg 直接串流到目标端。在这条流程里，来源端不会先落一份 tarball，目标端也不会先下载一份 tarball 再解压。资料会一路从旧机流到新机，直接还原到定位。

这个做法不只适合我们自己的部署系统。只要你有大量备份要搬、要把 production 资料还原到 development VM，或想在没有事先配置 SSH trust 的情况下做一次性大档传输，这个模式都很值得采用。

我们的部署模型

我们内部有一套轻量的部署系统，概念上接近小型 PaaS，主要入口是 Deploy.py。

它会处理 install、backup、restore、migrate、update、health check 和环境准备等维运工作。共通流程集中在部署层，app 特有的细节则交给各 app 自己的维运脚本与设定。

我们在这个场景没有选 Kubernetes，理由很单纯：对目前这类工作负载来说，它的整体复杂度偏高。很多服务是小到中型的 production app，我们更在意的是单机维运流程清楚、脚本好读、复原步骤可预期，而且能从 app 目录一路追到整个生命周期。

在这种前提下，保留一套结构化、但不过度庞杂的部署界面，比导入完整丛集编排更合适。

每个 App 自带 Working Folder 的好处

这套设计里，一个很关键的选择是：每个 app 都有自己的 working folder。

那个目录里会放 app 的执行配置、container 定义、service scripts、app 自己的维运工具，以及 persistent volumes 的还原方式。数据库则透过 dump、backup hook 或相关工具纳入同一套维运契约。

换句话说，如果能在另一台机器重现以下几个部分，app 基本上就能先在新机跑起来：

部分	作用
Container 定义	重建 service process 与 runtime image
Volumes	保留上传档、使用者资料与需要持久化的状态
Database	保留结构化资料
Configuration	重现 domain、port、path、secrets 与环境变数
App 维运工具	让新机也能用同一套 install、backup、restore、migrate 界面

这也是为什么每个 app 都会有自己的 bin 工具，例如 backup、install、restore、migrate 等。全域的部署系统会呼叫这些工具，但 app 内部的行为仍由 app 自己掌握。

这种设计刻意保持朴素。对 production 维运来说，朴素常常是优势。

旧版 Migration 流程长什么样子

原本的 migration 流程大致如下：

source server
  -> 执行 Borg backup
  -> 从 Borg 汇出 volumes
  -> 在磁盘上产生 tar 或 tar.gz
  -> 用 scp 传到 target server

target server
  -> 接收 archive
  -> 解压缩 archive
  -> 还原 database 与 config
  -> 启动 app
  -> 切流量前先验证

这是很容易理解的一条路。Borg 适合做备份，scp 几乎每个维运人员都熟，tarball 也很方便检查。

真正麻烦的是磁盘使用模式。

痛点就在来源机器快没空间

假设某个 app 的 volumes 有 80 GB。

旧流程很可能让来源机器同时承受这些空间需求：

既有 application data
+ Borg repository 或 backup cache
+ 汇出的 tar archive
+ 额外的压缩档
+ 传输中的 partial file
+ log 与暂存档

这种需求和 migration 的动机其实互相冲突。会急着搬机器，通常就是因为旧机太满、太旧、太难再撑下去。这时再要求它额外生出一份大型副本，等于把最重的负担放回来源机器身上。

更合理的做法，是让备份输出直接进入传输流程，不再经过来源端的落地档案。

rsync 能不能解这个问题

如果来源资料本来就是一棵可以直接同步的档案树，而且 source 与 target 之间的 SSH 通信也早就配置完成，那 rsync 依然很好用。

rsync -aHAX --numeric-ids --partial --partial-dir=.rsync-partial \
  /srv/apps/myapp/volumes/ user@target:/srv/apps/myapp/volumes/

它能续传、保留 metadata，也很适合同步现成目录。如果 migration 的意思只是「把 live volumes 复制到新机，然后把 app 起起来」，那 rsync 其实很合理，很多时候也可能比这类带 relay 能力的工具更快。

我们这次的情况不太一样。我们本来就会在 migrate 前先做一次备份。既然备份已经建立完成，用它当资料来源就很自然。新的 Borg archive 等于是一个干净、明确的时间点快照，而 borg export-tar 则刚好提供了现成的 stdout stream，可以直接接到传输流程里。

这里要特别说明一点：Borg 并不是 migration 存在的原因，它只是我们已经在使用、也已经信任的备份机制。做完备份之后，它顺手成了 migration 的资料来源。至于完整的备份历史记录，要不要一起带到新机，是另一个决策。在很多环境里，这其实不是必要条件，因为整台 server 本来就已经有另外的整机备份。

另一个因素是 target 的弹性。有些 target 是干净 VM、临时测试机，这时我们未必想先处理 SSH key、sshpass 或额外的 server-to-server 信任配置。

在这样的条件下，stream-oriented 的传输工具就会更顺手。

为什么 FastFileLink CLI 很适合

FastFileLink CLI 可以传档案、资料夹，也可以传 stdin。这正是整个设计改变的起点。

比起先汇出 tarball，再把 tarball 复制到目标机器，我们可以让资料一路保持在流动状态：

borg export-tar -> stdout -> FastFileLink CLI -> stdout on target -> tar extract

在这条流程里，来源机器不需要先落一份 tarball，目标机器也不需要先收一份 tarball。

来源端的指令形状大致如下：

borg export-tar "$BORG_REPO::$ARCHIVE" - \
  | "$FFL" - \
      --name "$APP_NAME-volumes.tar" \
      --e2ee \
      --stdin-cache off \
      --max-downloads 1 \
      --pickup-code "$PICKUP_CODE"

目标端则直接把收到的资料送进 tar：

"$FFL" download "$LINK" \
  --pickup-code "$PICKUP_CODE" \
  --e2ee \
  --stdout \
  | tar xvf - -C "$RESTORE_ROOT"

这代表：

来源机器：不落地汇出 archive
目标机器：不落地下载 archive
传输过程：资料一路串流到目标目录

这次主示例不把 gzip 放进来，也是刻意的取舍。因为这次 migration 的主要痛点是额外磁盘空间，不是压缩率，而 plain tar stream 可以让 source 和 target 两端少一层 CPU 负担，也更容易调试。

对低空间 migration 来说，这正是最想看到的形状。

`--stdin-cache`、`--stdout` 和 `--pickup-code` 在做什么

如果只是把上面的指令贴出来，不多解释，读者其实很难立刻理解这几个选项的意义。

先说 --pickup-code。它是这条配对流程的一部分。sender 会产生一个 link，但 receiver 除了 link 之外，还要知道 pickup code 才能真正取走资料。如果你用过 croc，应该会对这种短码信任模型很熟悉：一组短码会成为取件流程的一部分。放在 migration 这里，它的好处很直接，因为我们可以把 link 和 code 一起交给 target process，不必把下载入口完全裸露出去。有了 --pickup-code 之后，FastFileLink CLI 其实就已经知道这次用的是 pickup 模式，所以不必再另外把 --recipient-auth pickup 写出来。

FastFileLink CLI 也不只有这一种收端验证方式。除了 pickup 之外，CLI 还支援 pubkey、pubkey+pickup、email 等模式，也支援用 --auth-user、--auth-password 走传统的 HTTP Basic Authentication。这次我们选 pickup，是因为它在脚本化流程里很方便，对一次性的 migration 也很顺手。

再来是 --stdin-cache off。FastFileLink CLI 默认的心智模型，偏向一般档案分享：档案可能会被重复下载、也可能会有多个 receiver。因此它会考虑 cache，这样才能支援多次取用。但 migration stream 的情境刚好相反：我们知道这份资料只会被一个 receiver 消费一次。如果还保留 stdin cache，只是在来源端额外花磁盘空间。把 cache 关掉之后，来源端就更接近真正的单次串流 producer。

--e2ee 在这里也很值得开启。WebRTC 本身已经走安全传输，但 migration 过程有时会 fallback 到 relay 或 tunnel。把 end-to-end encryption 打开之后，即使资料走到中继路径，中间节点看到的也只是加密后的内容。对备份资料和 production data 来说，这层保护很有价值。

download --stdout 则是 target 端的关键。接收端拿到位元流之后，可以直接往 stdout 写，后面接 tar 就能原地解开，不需要先下载到一个 tarball，再做第二步解压。

合在一起之后，整个资料路径会变得很清楚：

source app backup snapshot
  -> Borg export stream
  -> FastFileLink CLI sender
  -> FastFileLink CLI receiver
  -> tar 直接解到 target app folder
  -> volumes 就定位

怎么整合回既有的 Deploy.py

我们没有重做一支全新的 migration 工具。

原本的 Deploy.py migrate 已经很清楚自己要做什么：

准备 source / target app layout
呼叫 app 自己的 migrate / backup 脚本
汇出 volumes
dump 与 restore database
还原 config
启动 target app 并验证

因此改造的重点在于把传输层换掉，让其他既有能力继续工作。

整体流程现在可以理解成：

Deploy.py migrate
  -> app bin/migrate
  -> ExportVolumes from Borg
  -> source 端串流到 FastFileLink CLI
  -> target 端从 FastFileLink CLI 接出来
  -> 直接解到 target app folder
  -> restore database 与 privilege
  -> 视需要传送 backup history
  -> install / start target app
  -> cutover 前验证

这样做还有一个好处：原本的 file-based 路径依然留着。当你需要保留 artifact、想把 restore 问题切开来 debug，或在空间充足的情况下想保留旧流程时，仍然有选择。Streaming mode 则负责解决低空间 migration 的核心问题。

FastFileLink CLI 在这个案例中的几个优势

FastFileLink CLI 跟这个场景贴得很近，主要是因为它同时满足了几个需求：

能力	对 migration 的帮助
单档 APE binary	需要时下载，用完删掉，不必预先安装
WebRTC direct transfer	网络允许时尽量点对点传输
Relay fallback	打不通直连时仍能透过 relay 完成
End-to-end encryption	relay 看不到明文内容
Pickup code 验证	脚本可以安全配对 sender 与 receiver
`--e2ee`	即使走 relay 或 tunnel，中间节点也看不到资料内容
stdin / stdout 支援	真的能做到两端都不落地的串流搬迁
`--hook` 事件输出	很适合整合到既有 automation 里

对老旧 production 主机来说，单档 binary 的意义很实际。我们不需要为了搬走它，先在上面长期安装一个新服务。抓下 ffl.com，跑完流程，清掉档案即可。

--hook 这点也很值得单独讲。FastFileLink CLI 有它自己独特的 embedded mode，可以输出结构化事件拿来做整合。这帮我们省掉很多胶水程序，因为不必再去 parse 人类看的 console output 才知道传输目前发生了什么。这种整合面在同类型工具里并不常见。

和 scp、rsync、croc、Magic Wormhole 的比较

挑工具时，真正要看的还是它的假设是否符合现场条件。

工具	适合情境	这个案例里的限制
`scp`	有现成档案要透过 SSH 复制	需要先产生 artifact，也要处理 SSH 认证
`rsync`	同步 live directory tree	不擅长直接搬 Borg stdout stream
`croc`	安全的 CLI 传输，也支援 pipe	是很好的替代方案，但大量资料时常会走 relay，对多百 MB 或多 GB 的 migration 不是特别理想
Magic Wormhole	人工一次性安全传档	比较偏 ad-hoc 传送，不是 unattended migration 的最佳主线
FastFileLink CLI	档案、资料夹与 stdin/stdout 串流	需要把 timeout、cleanup、log 观测一起设计好

如果资料已经是可直接同步的目录，而且 SSH trust 很稳定，rsync 仍然会是很强的选项。

但在「资料本来就是备份 stream」加上「目标端可能是新 VM」这种情况下，FastFileLink CLI 的整体手感明显更好，因为它对环境的前置要求更少，同时保留加密、验证、直连与 relay fallback。

实作过程里，真正踩到哪些坑

真正有价值的教训，并不是某条路径 quote 错了，或哪个 cleanup 顺序放反了。那些问题确实存在，也确实修掉了，但大量资料传输真正难的地方，是状态观测。

我们最早的版本走得很直觉：启动 FastFileLink CLI，parse 一般输出，把 link 抓出来，剩下的流程再用 shell wrapper 补。当 proof of concept 没问题，但当它变成真正的 migration command，就会开始暴露观测上的不足。

大档传输把这些问题放得很大：

sender 到底有没有开始读 stdin？
receiver 真的接上了吗？
目前走的是直连，还是 fallback 路径？
process 还活着，代表真的在前进，还是其实只是卡住？
producer 和 transfer tool，究竟是哪一端先失败？

Orchestration 比 pipe 更重要

Streaming migration 绝对不是「把 producer 接到 consumer，中间多一条 pipe」就结束。

file-based transfer 失败时，通常还会留下 partial file 可以看。stream 一旦卡住，系统自己就得知道到底卡在哪里。真正能不能拿来做 production migration，差别常常不在传输工具支不支援 stdin，而在整个 orchestration 有没有把状态观测、清理与重试边界一起设计好。

因此实作上至少要补几件事：

关注点	做法
temporary binary	`ffl.com` 下载到 temp directory，用完就删掉
logging	卡住时能切到 DEBUG，或指定 logging config 帮助排查
receiver readiness	先确认 target receiver 已启动，再让整体流程往下走
progress	观察 bytes transferred 或 extracted，不只看 process 还在不在
cleanup	清掉 orphan sender / receiver process 与临时档
retry	在 transfer boundary 重跑，不从半个 tar extraction 中间硬接
secrets	auth password、pickup code 这类资讯不应出现在一般 log

我们实测时也很明显感受到这件事：如果 target receiver 根本没跑起来，source 端表面上可能还在等、还像是在做事，但整条 migration 其实早就停住了。

所以一个够稳的 migration command，至少要能确认：

source process is alive
target process is alive
target output is growing
logs show an accepted transfer path

长时间传输里，「process 还活着」从来不等于有进度。进度一定要能观测。

等我们改成用 FastFileLink CLI 的 --hook 之后，事情顺利很多。share link、progress、receiver 状态、完成与失败事件，都可以透过结构化事件来追。这时候才真正摆脱「把人类看的输出当 API」这种脆弱作法。

这件事的价值非常高。migration automation 需要的不只是资料有没有在传，而是流程状态能不能被可靠地理解。

在这个基础上，我们当然还是修到一些一般 deploy bug，例如 target 路径 quoting、旧 volumes 的清理顺序等。但那已经是能清楚定位、也能直接修正的问题了。

修完之后，整条 migration 已经能顺利完成这些步骤：

从 Borg 串流 volumes 到 FastFileLink CLI
在 target 还原 database dump
还原 database privilege
视需要把 Borg backup repository 一起带过去
pull app image
启动 target container

我们最后遇到的剩余问题，已经不在 streaming layer，而是 target 上 Nginx / SSL 收尾的部署细节。这反而是个好讯号，表示最困难的资料搬运路径已经打通，接下来处理的是一般部署尾声该处理的事情。

不切 DNS 也能先测试 migration 结果

好的 migration 流程，应该允许我们在真正切换前，先验证新机是否已经能接手。

这一点和我们的 app folder 设计很契合。因为 app 的 container、volumes、database、config 与维运工具本来就被整理在同一套 working folder 契约里，所以可以先把整个 app 还原到新机，用测试 port 或 temporary hostname 启动，确认结果没问题，再安排 DNS 或 load balancer 的 cutover。

实际上很容易整理成这样一份 checklist：

1. 在 target 还原 app files、volumes、database、config。
2. 启动 target 上的 containers 或 services。
3. 执行 health checks。
4. 验证 static files 与 uploaded files。
5. 验证 database-backed pages 和 login flow。
6. 检查 logs 是否有 path、permission、environment variable 问题。
7. 确认后才安排 DNS 或 load balancer 切换。

这也是 migration 没那么可怕的关键。旧 production server 可以继续服务，新机则先在旁边证明自己真的能接手。

这个模式不只适用于单一 App

虽然这次是从一个具体 migration 案子长出来的，整个模式其实很通用。

只要资料来源能输出到 stdout，就可以沿用同样的传输思路：

borg export-tar repo::archive -
pg_dump mydb
mysqldump mydb
tar -cf - /large/folder
zfs send pool/dataset@snapshot

接着把 stream 接到 FastFileLink CLI：

producer | ffl - --stdin-cache off --max-downloads 1

目标端再接到真正的 consumer：

ffl download "$LINK" --stdout | consumer

这很适合用在：

老旧或磁盘快满的 server 搬迁
把 production backup 还原到 development VM
disaster recovery 传输
大量使用者上传资料搬移
不想在来源机留下 dump file 的 database 传输
事前不想配置 SSH trust 的临时环境

结语

这次 migration 改造最重要的收获，在于我们把整个搬迁契约重新整理过。

旧流程要求来源机器先准备出一份大型副本，搬迁才有办法开始。当旧机已经快满时，这个前提很容易成为第一个阻碍。

整理之后，流程会变得很直接：

读出 backup stream
立刻传走
在 target 直接还原

--stdin-cache off 与 download --stdout 很适合这条路径。对正在处理 server migration、备份传输、低磁盘空间主机，或临时还原环境的团队来说，这是一种很务实、很好自动化，也很容易说清楚的解法。

当旧机空间告急、搬迁又势在必行时，这样的行为模型会让整个流程轻松很多。

不需要額外硬碟空間的伺服器搬遷：用 FastFileLink CLI 串流 Borg 備份

2026-04-24T10:00:00+08:00

搬一個 production app，表面上像是把資料複製到新機，實際上往往是在跟時間、空間和環境條件搏鬥。

最常見的情況是這樣：舊機快滿了，大家想盡快搬走；新機剛準備好，還沒正式接手流量；DNS 不能立刻切；資料量又大。這時如果 migration 流程還要求舊機先多生出一份大型 tarball，通常只會讓事情更難推進。

這篇文章整理的是我們最近改造 migration 流程的實戰經驗。我們本來用的是很典型的做法：先用 Borg 備份，再把備份匯出成 tar 或 tar.gz，接著透過 scp 傳到目標機器，最後在新機還原。

那套方式在磁碟空間充裕時很好用，也很好除錯。問題出在它對來源機器的空間要求太高。偏偏真正急著搬的主機，通常就是空間最吃緊的那一台。

所以我們把傳輸層改成以 FastFileLink CLI 為核心，讓資料從 Borg 直接串流到目標端。在這條流程裡，來源端不會先落一份 tarball，目標端也不會先下載一份 tarball 再解壓。資料會一路從舊機流到新機，直接還原到定位。

這個做法不只適合我們自己的部署系統。只要你有大量備份要搬、要把 production 資料還原到 development VM，或想在沒有事先配置 SSH trust 的情況下做一次性大檔傳輸，這個模式都很值得採用。

我們的部署模型

我們內部有一套輕量的部署系統，概念上接近小型 PaaS，主要入口是 Deploy.py。

它會處理 install、backup、restore、migrate、update、health check 和環境準備等維運工作。共通流程集中在部署層，app 特有的細節則交給各 app 自己的維運腳本與設定。

我們在這個場景沒有選 Kubernetes，理由很單純：對目前這類工作負載來說，它的整體複雜度偏高。很多服務是小到中型的 production app，我們更在意的是單機維運流程清楚、腳本好讀、復原步驟可預期，而且能從 app 目錄一路追到整個生命週期。

在這種前提下，保留一套結構化、但不過度龐雜的部署介面，比導入完整叢集編排更合適。

每個 App 自帶 Working Folder 的好處

這套設計裡，一個很關鍵的選擇是：每個 app 都有自己的 working folder。

那個目錄裡會放 app 的執行配置、container 定義、service scripts、app 自己的維運工具，以及 persistent volumes 的還原方式。資料庫則透過 dump、backup hook 或相關工具納入同一套維運契約。

換句話說，如果能在另一台機器重現以下幾個部分，app 基本上就能先在新機跑起來：

部分	作用
Container 定義	重建 service process 與 runtime image
Volumes	保留上傳檔、使用者資料與需要持久化的狀態
Database	保留結構化資料
Configuration	重現 domain、port、path、secrets 與環境變數
App 維運工具	讓新機也能用同一套 install、backup、restore、migrate 介面

這也是為什麼每個 app 都會有自己的 bin 工具，例如 backup、install、restore、migrate 等。全域的部署系統會呼叫這些工具，但 app 內部的行為仍由 app 自己掌握。

這種設計刻意保持樸素。對 production 維運來說，樸素常常是優勢。

舊版 Migration 流程長什麼樣子

原本的 migration 流程大致如下：

source server
  -> 執行 Borg backup
  -> 從 Borg 匯出 volumes
  -> 在磁碟上產生 tar 或 tar.gz
  -> 用 scp 傳到 target server

target server
  -> 接收 archive
  -> 解壓縮 archive
  -> 還原 database 與 config
  -> 啟動 app
  -> 切流量前先驗證

這是很容易理解的一條路。Borg 適合做備份，scp 幾乎每個維運人員都熟，tarball 也很方便檢查。

真正麻煩的是磁碟使用模式。

痛點就在來源機器快沒空間

假設某個 app 的 volumes 有 80 GB。

舊流程很可能讓來源機器同時承受這些空間需求：

既有 application data
+ Borg repository 或 backup cache
+ 匯出的 tar archive
+ 額外的壓縮檔
+ 傳輸中的 partial file
+ log 與暫存檔

這種需求和 migration 的動機其實互相衝突。會急著搬機器，通常就是因為舊機太滿、太舊、太難再撐下去。這時再要求它額外生出一份大型副本，等於把最重的負擔放回來源機器身上。

更合理的做法，是讓備份輸出直接進入傳輸流程，不再經過來源端的落地檔案。

rsync 能不能解這個問題

如果來源資料本來就是一棵可以直接同步的檔案樹，而且 source 與 target 之間的 SSH 通信也早就配置完成，那 rsync 依然很好用。

rsync -aHAX --numeric-ids --partial --partial-dir=.rsync-partial \
  /srv/apps/myapp/volumes/ user@target:/srv/apps/myapp/volumes/

它能續傳、保留 metadata，也很適合同步現成目錄。如果 migration 的意思只是「把 live volumes 複製到新機，然後把 app 起起來」，那 rsync 其實很合理，很多時候也可能比這類帶 relay 能力的工具更快。

我們這次的情況不太一樣。我們本來就會在 migrate 前先做一次備份。既然備份已經建立完成，用它當資料來源就很自然。新的 Borg archive 等於是一個乾淨、明確的時間點快照，而 borg export-tar 則剛好提供了現成的 stdout stream，可以直接接到傳輸流程裡。

這裡要特別說明一點：Borg 並不是 migration 存在的原因，它只是我們已經在使用、也已經信任的備份機制。做完備份之後，它順手成了 migration 的資料來源。至於完整的備份歷史記錄，要不要一起帶到新機，是另一個決策。在很多環境裡，這其實不是必要條件，因為整台 server 本來就已經有另外的整機備份。

另一個因素是 target 的彈性。有些 target 是乾淨 VM、臨時測試機，這時我們未必想先處理 SSH key、sshpass 或額外的 server-to-server 信任配置。

在這樣的條件下，stream-oriented 的傳輸工具就會更順手。

為什麼 FastFileLink CLI 很適合

FastFileLink CLI 可以傳檔案、資料夾，也可以傳 stdin。這正是整個設計改變的起點。

比起先匯出 tarball，再把 tarball 複製到目標機器，我們可以讓資料一路保持在流動狀態：

borg export-tar -> stdout -> FastFileLink CLI -> stdout on target -> tar extract

在這條流程裡，來源機器不需要先落一份 tarball，目標機器也不需要先收一份 tarball。

來源端的指令形狀大致如下：

borg export-tar "$BORG_REPO::$ARCHIVE" - \
  | "$FFL" - \
      --name "$APP_NAME-volumes.tar" \
      --e2ee \
      --stdin-cache off \
      --max-downloads 1 \
      --pickup-code "$PICKUP_CODE"

目標端則直接把收到的資料送進 tar：

"$FFL" download "$LINK" \
  --pickup-code "$PICKUP_CODE" \
  --e2ee \
  --stdout \
  | tar xvf - -C "$RESTORE_ROOT"

這代表：

來源機器：不落地匯出 archive
目標機器：不落地下載 archive
傳輸過程：資料一路串流到目標目錄

這次主範例不把 gzip 放進來，也是刻意的取捨。因為這次 migration 的主要痛點是額外磁碟空間，不是壓縮率，而 plain tar stream 可以讓 source 和 target 兩端少一層 CPU 負擔，也更容易除錯。

對低空間 migration 來說，這正是最想看到的形狀。

`--stdin-cache`、`--stdout` 和 `--pickup-code` 在做什麼

如果只是把上面的指令貼出來，不多解釋，讀者其實很難立刻理解這幾個選項的意義。

先說 --pickup-code。它是這條配對流程的一部分。sender 會產生一個 link，但 receiver 除了 link 之外，還要知道 pickup code 才能真正取走資料。如果你用過 croc，應該會對這種短碼信任模型很熟悉：一組短碼會成為取件流程的一部分。放在 migration 這裡，它的好處很直接，因為我們可以把 link 和 code 一起交給 target process，不必把下載入口完全裸露出去。有了 --pickup-code 之後，FastFileLink CLI 其實就已經知道這次用的是 pickup 模式，所以不必再另外把 --recipient-auth pickup 寫出來。

FastFileLink CLI 也不只有這一種收端驗證方式。除了 pickup 之外，CLI 還支援 pubkey、pubkey+pickup、email 等模式，也支援用 --auth-user、--auth-password 走傳統的 HTTP Basic Authentication。這次我們選 pickup，是因為它在腳本化流程裡很方便，對一次性的 migration 也很順手。

再來是 --stdin-cache off。FastFileLink CLI 預設的心智模型，偏向一般檔案分享：檔案可能會被重複下載、也可能會有多個 receiver。因此它會考慮 cache，這樣才能支援多次取用。但 migration stream 的情境剛好相反：我們知道這份資料只會被一個 receiver 消費一次。如果還保留 stdin cache，只是在來源端額外花磁碟空間。把 cache 關掉之後，來源端就更接近真正的單次串流 producer。

--e2ee 在這裡也很值得開啟。WebRTC 本身已經走安全傳輸，但 migration 過程有時會 fallback 到 relay 或 tunnel。把 end-to-end encryption 打開之後，即使資料走到中繼路徑，中間節點看到的也只是加密後的內容。對備份資料和 production data 來說，這層保護很有價值。

download --stdout 則是 target 端的關鍵。接收端拿到位元流之後，可以直接往 stdout 寫，後面接 tar 就能原地解開，不需要先下載到一個 tarball，再做第二步解壓。

合在一起之後，整個資料路徑會變得很清楚：

source app backup snapshot
  -> Borg export stream
  -> FastFileLink CLI sender
  -> FastFileLink CLI receiver
  -> tar 直接解到 target app folder
  -> volumes 就定位

怎麼整合回既有的 Deploy.py

我們沒有重做一支全新的 migration 工具。

原本的 Deploy.py migrate 已經很清楚自己要做什麼：

準備 source / target app layout
呼叫 app 自己的 migrate / backup 腳本
匯出 volumes
dump 與 restore database
還原 config
啟動 target app 並驗證

因此改造的重點在於把傳輸層換掉，讓其他既有能力繼續工作。

整體流程現在可以理解成：

Deploy.py migrate
  -> app bin/migrate
  -> ExportVolumes from Borg
  -> source 端串流到 FastFileLink CLI
  -> target 端從 FastFileLink CLI 接出來
  -> 直接解到 target app folder
  -> restore database 與 privilege
  -> 視需要傳送 backup history
  -> install / start target app
  -> cutover 前驗證

這樣做還有一個好處：原本的 file-based 路徑依然留著。當你需要保留 artifact、想把 restore 問題切開來 debug，或在空間充足的情況下想保留舊流程時，仍然有選擇。Streaming mode 則負責解決低空間 migration 的核心問題。

FastFileLink CLI 在這個案例中的幾個優勢

FastFileLink CLI 跟這個場景貼得很近，主要是因為它同時滿足了幾個需求：

能力	對 migration 的幫助
單檔 APE binary	需要時下載，用完刪掉，不必預先安裝
WebRTC direct transfer	網路允許時盡量點對點傳輸
Relay fallback	打不通直連時仍能透過 relay 完成
End-to-end encryption	relay 看不到明文內容
Pickup code 驗證	腳本可以安全配對 sender 與 receiver
`--e2ee`	即使走 relay 或 tunnel，中間節點也看不到資料內容
stdin / stdout 支援	真的能做到兩端都不落地的串流搬遷
`--hook` 事件輸出	很適合整合到既有 automation 裡

對老舊 production 主機來說，單檔 binary 的意義很實際。我們不需要為了搬走它，先在上面長期安裝一個新服務。抓下 ffl.com，跑完流程，清掉檔案即可。

--hook 這點也很值得單獨講。FastFileLink CLI 有它自己獨特的 embedded mode，可以輸出結構化事件拿來做整合。這幫我們省掉很多膠水程式，因為不必再去 parse 人類看的 console output 才知道傳輸目前發生了什麼。這種整合面在同類型工具裡並不常見。

和 scp、rsync、croc、Magic Wormhole 的比較

挑工具時，真正要看的還是它的假設是否符合現場條件。

工具	適合情境	這個案例裡的限制
`scp`	有現成檔案要透過 SSH 複製	需要先產生 artifact，也要處理 SSH 認證
`rsync`	同步 live directory tree	不擅長直接搬 Borg stdout stream
`croc`	安全的 CLI 傳輸，也支援 pipe	是很好的替代方案，但大量資料時常會走 relay，對多百 MB 或多 GB 的 migration 不是特別理想
Magic Wormhole	人工一次性安全傳檔	比較偏 ad-hoc 傳送，不是 unattended migration 的最佳主線
FastFileLink CLI	檔案、資料夾與 stdin/stdout 串流	需要把 timeout、cleanup、log 觀測一起設計好

如果資料已經是可直接同步的目錄，而且 SSH trust 很穩定，rsync 仍然會是很強的選項。

但在「資料本來就是備份 stream」加上「目標端可能是新 VM」這種情況下，FastFileLink CLI 的整體手感明顯更好，因為它對環境的前置要求更少，同時保留加密、驗證、直連與 relay fallback。

實作過程裡，真正踩到哪些坑

真正有價值的教訓，並不是某條路徑 quote 錯了，或哪個 cleanup 順序放反了。那些問題確實存在，也確實修掉了，但大量資料傳輸真正難的地方，是狀態觀測。

我們最早的版本走得很直覺：啟動 FastFileLink CLI，parse 一般輸出，把 link 抓出來，剩下的流程再用 shell wrapper 補。當 proof of concept 沒問題，但當它變成真正的 migration command，就會開始暴露觀測上的不足。

大檔傳輸把這些問題放得很大：

sender 到底有沒有開始讀 stdin？
receiver 真的接上了嗎？
目前走的是直連，還是 fallback 路徑？
process 還活著，代表真的在前進，還是其實只是卡住？
producer 和 transfer tool，究竟是哪一端先失敗？

Orchestration 比 pipe 更重要

Streaming migration 絕對不是「把 producer 接到 consumer，中間多一條 pipe」就結束。

file-based transfer 失敗時，通常還會留下 partial file 可以看。stream 一旦卡住，系統自己就得知道到底卡在哪裡。真正能不能拿來做 production migration，差別常常不在傳輸工具支不支援 stdin，而在整個 orchestration 有沒有把狀態觀測、清理與重試邊界一起設計好。

因此實作上至少要補幾件事：

關注點	做法
temporary binary	`ffl.com` 下載到 temp directory，用完就刪掉
logging	卡住時能切到 DEBUG，或指定 logging config 幫助排查
receiver readiness	先確認 target receiver 已啟動，再讓整體流程往下走
progress	觀察 bytes transferred 或 extracted，不只看 process 還在不在
cleanup	清掉 orphan sender / receiver process 與臨時檔
retry	在 transfer boundary 重跑，不從半個 tar extraction 中間硬接
secrets	auth password、pickup code 這類資訊不應出現在一般 log

我們實測時也很明顯感受到這件事：如果 target receiver 根本沒跑起來，source 端表面上可能還在等、還像是在做事，但整條 migration 其實早就停住了。

所以一個夠穩的 migration command，至少要能確認：

source process is alive
target process is alive
target output is growing
logs show an accepted transfer path

長時間傳輸裡，「process 還活著」從來不等於有進度。進度一定要能觀測。

等我們改成用 FastFileLink CLI 的 --hook 之後，事情順利很多。share link、progress、receiver 狀態、完成與失敗事件，都可以透過結構化事件來追。這時候才真正擺脫「把人類看的輸出當 API」這種脆弱作法。

這件事的價值非常高。migration automation 需要的不只是資料有沒有在傳，而是流程狀態能不能被可靠地理解。

在這個基礎上，我們當然還是修到一些一般 deploy bug，例如 target 路徑 quoting、舊 volumes 的清理順序等。但那已經是能清楚定位、也能直接修正的問題了。

修完之後，整條 migration 已經能順利完成這些步驟：

從 Borg 串流 volumes 到 FastFileLink CLI
在 target 還原 database dump
還原 database privilege
視需要把 Borg backup repository 一起帶過去
pull app image
啟動 target container

我們最後遇到的剩餘問題，已經不在 streaming layer，而是 target 上 Nginx / SSL 收尾的部署細節。這反而是個好訊號，表示最困難的資料搬運路徑已經打通，接下來處理的是一般部署尾聲該處理的事情。

不切 DNS 也能先測試 migration 結果

好的 migration 流程，應該允許我們在真正切換前，先驗證新機是否已經能接手。

這一點和我們的 app folder 設計很契合。因為 app 的 container、volumes、database、config 與維運工具本來就被整理在同一套 working folder 契約裡，所以可以先把整個 app 還原到新機，用測試 port 或 temporary hostname 啟動，確認結果沒問題，再安排 DNS 或 load balancer 的 cutover。

實際上很容易整理成這樣一份 checklist：

1. 在 target 還原 app files、volumes、database、config。
2. 啟動 target 上的 containers 或 services。
3. 執行 health checks。
4. 驗證 static files 與 uploaded files。
5. 驗證 database-backed pages 和 login flow。
6. 檢查 logs 是否有 path、permission、environment variable 問題。
7. 確認後才安排 DNS 或 load balancer 切換。

這也是 migration 沒那麼可怕的關鍵。舊 production server 可以繼續服務，新機則先在旁邊證明自己真的能接手。

這個模式不只適用於單一 App

雖然這次是從一個具體 migration 案子長出來的，整個模式其實很通用。

只要資料來源能輸出到 stdout，就可以沿用同樣的傳輸思路：

borg export-tar repo::archive -
pg_dump mydb
mysqldump mydb
tar -cf - /large/folder
zfs send pool/dataset@snapshot

接著把 stream 接到 FastFileLink CLI：

producer | ffl - --stdin-cache off --max-downloads 1

目標端再接到真正的 consumer：

ffl download "$LINK" --stdout | consumer

這很適合用在：

老舊或磁碟快滿的 server 搬遷
把 production backup 還原到 development VM
disaster recovery 傳輸
大量使用者上傳資料搬移
不想在來源機留下 dump file 的 database 傳輸
事前不想配置 SSH trust 的臨時環境

結語

這次 migration 改造最重要的收穫，在於我們把整個搬遷契約重新整理過。

舊流程要求來源機器先準備出一份大型副本，搬遷才有辦法開始。當舊機已經快滿時，這個前提很容易成為第一個阻礙。

整理之後，流程會變得很直接：

讀出 backup stream
立刻傳走
在 target 直接還原

--stdin-cache off 與 download --stdout 很適合這條路徑。對正在處理 server migration、備份傳輸、低磁碟空間主機，或臨時還原環境的團隊來說，這是一種很務實、很好自動化，也很容易說清楚的解法。

當舊機空間告急、搬遷又勢在必行時，這樣的行為模型會讓整個流程輕鬆很多。

Direct Transfer or Cloud Relay? Here's How to Choose

2026-04-12T11:00:00+08:00

When you open FastFileLink, you will see two options: P2P direct transfer and cloud relay.

A lot of first-time users get stuck right there: "What's the difference, and which one should I pick?"

This article answers that in about three minutes.

The short version

P2P direct transfer: the file goes straight from your device to the recipient's device without touching any server. Think of it as a direct connection between two computers, just happening over the internet.

Cloud relay: you encrypt the file and upload it to our secure server first, and the recipient downloads it later when convenient. Think of it like leaving something in a secure locker for pickup.

When should you choose P2P direct transfer?

Choose P2P when both you and the recipient can be online at the same time. That is the only real requirement. During the transfer, your device needs to stay on and connected.

If that condition is met, P2P is usually the best option because:

It is faster: the data goes directly between you and the recipient, so there is no upload-first-then-download delay
It is completely free: no points are consumed, even for very large files
It is more private: the file never passes through a third-party server, including ours

Good use cases: delivering files right after a client meeting, handing off design assets between a designer and an engineer, or sending travel photos to friends.

When should you choose cloud relay?

Choose cloud relay if any of these are true:

Your schedules do not line up: you are free to send now, but the recipient is in a meeting, asleep, or in a different time zone.

You need to turn off your computer after sending: P2P requires the sender to stay online, so if you are about to sleep or head out, cloud relay is the safer option.

The recipient needs to download in parts: this is useful when multiple people need the same file or when the recipient has unstable internet and needs resumable downloads.

You want the file to stay available for a while: maybe the recipient downloads part of it today and finishes tomorrow.

How is pricing calculated?

Transfer mode	Cost
P2P direct transfer	Free forever
Cloud relay	Points-based billing (about 1 point = 1 GB of traffic)

Cloud relay is paid from your account's points balance, not through a monthly subscription. However many points you have is your available cloud transfer budget.

Free accounts include 5 points, or about 5 GB, so you can try it first. If most of your use cases are P2P, those 5 points may last a long time.

One common misunderstanding

Many people assume cloud relay is safer because the file is "backed up on a server."

In practice, the security level is the same. Both modes use end-to-end encryption, and what sits on our server is encrypted ciphertext. Even if we wanted to inspect your content, we could not.

The difference is the transfer path, not the security model.

Quick decision flow

Are you free to send now, and can the recipient receive now?
   ├─ Yes -> Will your computer stay on until the transfer finishes?
   │          ├─ Yes -> P2P direct transfer ✅ (free, fast)
   │          └─ No  -> Cloud relay
   └─ No  -> Cloud relay

For most delivery scenarios, P2P direct transfer works well. Cloud relay is the fallback when P2P is inconvenient, not the default choice.

Still need the tool? Start here. P2P direct transfer is permanently free and does not require a credit card.

直传还是上云？帮你把这题做完

2026-04-12T11:00:00+08:00

打开快档连结，你会看到两个选项：P2P 直传和上云代收。

第一次看到的人常常卡在这里：「这两个有什么差？我要选哪个？」

这篇文章三分钟帮你把这题做完。

一句话说清楚

P2P 直传：档案从你的装置直接传到对方的装置，不上任何服务器。就像两台电脑直接接线，只是透过网络。

上云代收：你先把档案加密上传到我们的安全服务器，对方在方便的时候再来下载。就像把东西放到保全的置物箱，对方之后再去取。

什么时候选 P2P 直传？

你和对方可以同时在线。这是 P2P 的唯一前提。传输期间，你的装置要保持开启和连线。

符合这个条件，P2P 直传就是最好的选择，因为：

更快：资料直接走你和对方之间的网络，不用先上传再下载，少了一半的等待时间
完全免费：不消耗任何点数，TB 级大档也没问题
更私密：档案从未经过任何第三方服务器，连我们自己也看不到

适合的场景：你和客户约好线上会议后顺便交件、设计师和工程师对接素材、朋友之间传旅游照片。

什么时候选上云代收？

以下任一情况成立，就选上云代收：

时间对不上：你现在有空传，但对方现在在开会、在睡觉、在不同时区。

传输后你要关电脑：P2P 传输需要传送端保持连线，如果你传到一半要去睡觉或出门，就用上云代收。

对方需要分批下载：多个人要下载同一份档案，或对方网络不好需要断点续传。

想保留一段时间让对方随时取：对方可能今天下载一部分，明天再继续。

费用怎么算？

传输方式	费用
P2P 直传	永远免费
上云代收	按点数计费（大约 1 点 = 1GB 流量）

上云代收的费用是用「你的点数」支付，不是月租制。你的账户里有多少点数，就有多少「上云预算」。

免费账号送 5 点（大约 5GB）让你先试试看。如果你的需求大部分都是 P2P，这 5 点可能用很久。

一个常见的误解

很多人以为「上云代收比较安全，因为档案有备份在服务器上」。

其实，安全性是一样的——两种模式都有端到端加密，我们的服务器上存的是加密后的密文，就算我们想看你的内容也看不到。

差别只在「传输路径」，不在「安全程度」。

快速决策流程

你现在有空传，对方现在也可以收？
   ├─ 是 → 传输结束前你的电脑会一直开着吗？
   │           ├─ 是 → P2P 直传 ✅（免费、快速）
   │           └─ 否 → 上云代收
   └─ 否 → 上云代收

大多数「交件」场景，P2P 直传都能用。上云代收是当 P2P 不方便时的备案，不是默认选项。

还没下载工具？从这里开始，P2P 直传永久免费，不需信用卡。

直傳還是上雲？幫你把這題做完

2026-04-12T11:00:00+08:00

打開快檔連結，你會看到兩個選項：P2P 直傳和上雲代收。

第一次看到的人常常卡在這裡：「這兩個有什麼差？我要選哪個？」

這篇文章三分鐘幫你把這題做完。

一句話說清楚

P2P 直傳：檔案從你的裝置直接傳到對方的裝置，不上任何伺服器。就像兩台電腦直接接線，只是透過網路。

上雲代收：你先把檔案加密上傳到我們的安全伺服器，對方在方便的時候再來下載。就像把東西放到保全的置物箱，對方之後再去取。

什麼時候選 P2P 直傳？

你和對方可以同時在線。這是 P2P 的唯一前提。傳輸期間，你的裝置要保持開啟和連線。

符合這個條件，P2P 直傳就是最好的選擇，因為：

更快：資料直接走你和對方之間的網路，不用先上傳再下載，少了一半的等待時間
完全免費：不消耗任何點數，TB 級大檔也沒問題
更私密：檔案從未經過任何第三方伺服器，連我們自己也看不到

適合的場景：你和客戶約好線上會議後順便交件、設計師和工程師對接素材、朋友之間傳旅遊照片。

什麼時候選上雲代收？

以下任一情況成立，就選上雲代收：

時間對不上：你現在有空傳，但對方現在在開會、在睡覺、在不同時區。

傳輸後你要關電腦：P2P 傳輸需要傳送端保持連線，如果你傳到一半要去睡覺或出門，就用上雲代收。

對方需要分批下載：多個人要下載同一份檔案，或對方網路不好需要斷點續傳。

想保留一段時間讓對方隨時取：對方可能今天下載一部分，明天再繼續。

費用怎麼算？

傳輸方式	費用
P2P 直傳	永遠免費
上雲代收	按點數計費（大約 1 點 = 1GB 流量）

上雲代收的費用是用「你的點數」支付，不是月租制。你的帳戶裡有多少點數，就有多少「上雲預算」。

免費帳號送 5 點（大約 5GB）讓你先試試看。如果你的需求大部分都是 P2P，這 5 點可能用很久。

一個常見的誤解

很多人以為「上雲代收比較安全，因為檔案有備份在伺服器上」。

其實，安全性是一樣的——兩種模式都有端到端加密，我們的伺服器上存的是加密後的密文，就算我們想看你的內容也看不到。

差別只在「傳輸路徑」，不在「安全程度」。

快速決策流程

你現在有空傳，對方現在也可以收？
   ├─ 是 → 傳輸結束前你的電腦會一直開著嗎？
   │           ├─ 是 → P2P 直傳 ✅（免費、快速）
   │           └─ 否 → 上雲代收
   └─ 否 → 上雲代收

大多數「交件」場景，P2P 直傳都能用。上雲代收是當 P2P 不方便時的備案，不是預設選項。

還沒下載工具？從這裡開始，P2P 直傳永久免費，不需信用卡。

FastFileLink vs. Cloud Drives: Which Is Better for Delivering Files?

2026-04-12T10:30:00+08:00

What do you use to deliver files to clients? Ask ten people, and eight of them will say "Google Drive" or "WeTransfer."

Those tools are not bad. They were just built for storing files or tossing out a one-off link, not for actual delivery work. When what you are sending is a real deliverable, finished work, or something the recipient needs to use right away, the difference becomes obvious.

One table to see the difference

Feature	FastFileLink	Google Drive	WeTransfer	Dropbox
Upload large folders directly	✅ No zip needed	❌ Must zip or upload one by one	❌ Size limits apply	❌ Must upload first
P2P direct transfer (no cloud)	✅ Free	❌ Not supported	❌ Not supported	❌ Not supported
Recipient needs no account	✅	✅	✅	✅
End-to-end encryption	✅	❌	❌	❌
Custom branded download page	✅	❌	Paid only	Paid only
Download notifications and receipts	✅	❌	❌	Paid only
Recipient identity verification	✅	❌	❌	❌
Monthly subscription required	❌ No	✅ Yes	✅ Yes	✅ Yes
Unlimited file size	✅	Limited by storage	2 GB on free plan	Limited by storage
Resume interrupted transfers	✅	Unreliable	❌	❌

The core needs of file delivery are not what cloud drives solve

Speed

If you deliver a 10 GB folder through Google Drive, you first have to upload the entire folder, which might take an hour or more. Then the recipient has to download the whole thing, which means waiting all over again.

FastFileLink's P2P mode skips that entire process. The folder streams directly from your device to the recipient, so there is no "upload first, download later" delay.

Privacy

Files stored in Google Drive can, in principle, be accessed by Google. If you are delivering unreleased creative work, business-sensitive material, or personal data from a client, that is not an ideal setup.

FastFileLink uses end-to-end encryption, so even when server relay is used, only the sender and recipient can decrypt the content.

Less friction for the recipient

With Google Drive, recipients often run into the same issues: "I don't have a Google account," "It says I don't have permission," or "I don't know how to download the full folder."

FastFileLink gives them a normal HTTPS link. They can open it in any browser and download immediately, with no account and no installation required.

Knowing whether the file was actually received

Google Drive does not tell you whether the recipient downloaded the file. You have to wait for a reply or send another message asking, "Did you get it?"

FastFileLink supports download notifications, so you know as soon as the recipient actually downloads it.

What about WeTransfer?

WeTransfer is closer to a tool for one-off file drops. After upload, the link expires in a few days. There is no branded delivery page, no download notification, and the free plan's 2 GB limit is restrictive.

It is fine for occasionally sending a single image or a small file, but if you deliver multiple projects every month, it does not really solve the workflow.

When are cloud drives still the right choice?

If what you need is long-term storage and anytime access, Google Drive and Dropbox are still good options. That is exactly what they were designed for.

But if your goal is to hand something over to someone, especially large files, private material, or work that should look more professional in delivery, FastFileLink is the tool designed for that job.

Want to try it? Download the free version. P2P direct transfer is permanently free.

快档连结 vs 云端硬盘：哪个更适合交件？

2026-04-12T10:30:00+08:00

你交件用什么工具？问十个人，八个人会说「Google Drive」或「WeTransfer」。

这些工具不是不好，但它们是为了「存档案」或「一次性丢连结」设计的，不是为了「交件」设计的。当你要交的是作品、是成果、是对方会拿去用的重要东西，差别就出来了。

一张表，看清楚差异

功能	快档连结	Google Drive	WeTransfer	Dropbox
大型资料夹直传	✅ 免压缩直传	❌ 需压缩或逐一上传	❌ 有大小限制	❌ 需先上传
P2P 直传（免上云）	✅ 免费	❌ 不支援	❌ 不支援	❌ 不支援
收件人免账号	✅	✅	✅	✅
端到端加密	✅	❌	❌	❌
自订品牌下载页	✅	❌	付费版才有	付费版才有
下载通知与回条	✅	❌	❌	付费版才有
收件者身份验证	✅	❌	❌	❌
月租订阅	❌ 不需要	✅ 需要	✅ 需要	✅ 需要
无限档案大小	✅	受限于空间	免费版 2GB	受限于空间
断点续传	✅	不稳定	❌	❌

交件的核心需求，云端硬盘帮不到你

速度问题

用 Google Drive 交 10GB 的资料夹，你得先把资料夹全部上传（可能等个把小时），对方再全部下载（又等一次）。

快档连结的 P2P 模式完全跳过这个过程——资料夹直接从你的装置串流到对方那里，没有「先上传再下载」这件事。

隐私问题

Google Drive 上的档案，Google 有能力看到。如果你交的是未公开的作品、商业机密、或是客户的个人资料，这不是你想要的。

快档连结的端到端加密确保就算走服务器中继，内容也只有传送方和收件方能解密。

收件人的麻烦

用 Google Drive 交件，对方常常反映：「我没有 Google 账号」、「它说我没有权限」、「我不知道怎么下载整个资料夹」。

快档连结生成的是一个普通的 HTTPS 连结，对方用任何浏览器打开就能下载，不需要账号，不需要安装任何东西。

你知不知道对方收到了

Google Drive 不会告诉你对方有没有下载。你得等对方主动回复，或是再传一次信息问「你有收到吗？」

快档连结支援下载通知，对方一下载你就知道了。

WeTransfer 呢？

WeTransfer 比较像「一次性丢档案」的工具，上传后连结几天就失效了，没有品牌页面、没有通知、免费版 2GB 的上限更是限制不少。

对偶尔传一张图的情境还可以，但对「我每个月都要交付多个项目」的人来说，它解决不了问题。

什么情况下云端硬盘还是合适的？

如果你需要的是「长期储存、随时取用」，Google Drive 和 Dropbox 当然是好选择。它们本来就是设计来做这件事的。

但如果你的需求是「把这个东西交给对方」——特别是大档、需要隐私保护、或是想让交件过程看起来更专业——快档连结才是为这个场景设计的工具。

想试试看？下载免费版，P2P 直传本来就是永久免费的。

快檔連結 vs 雲端硬碟：哪個更適合交件？

2026-04-12T10:30:00+08:00

你交件用什麼工具？問十個人，八個人會說「Google Drive」或「WeTransfer」。

這些工具不是不好，但它們是為了「存檔案」或「一次性丟連結」設計的，不是為了「交件」設計的。當你要交的是作品、是成果、是對方會拿去用的重要東西，差別就出來了。

一張表，看清楚差異

功能	快檔連結	Google Drive	WeTransfer	Dropbox
大型資料夾直傳	✅ 免壓縮直傳	❌ 需壓縮或逐一上傳	❌ 有大小限制	❌ 需先上傳
P2P 直傳（免上雲）	✅ 免費	❌ 不支援	❌ 不支援	❌ 不支援
收件人免帳號	✅	✅	✅	✅
端到端加密	✅	❌	❌	❌
自訂品牌下載頁	✅	❌	付費版才有	付費版才有
下載通知與回條	✅	❌	❌	付費版才有
收件者身分驗證	✅	❌	❌	❌
月租訂閱	❌ 不需要	✅ 需要	✅ 需要	✅ 需要
無限檔案大小	✅	受限於空間	免費版 2GB	受限於空間
斷點續傳	✅	不穩定	❌	❌

交件的核心需求，雲端硬碟幫不到你

速度問題

用 Google Drive 交 10GB 的資料夾，你得先把資料夾全部上傳（可能等個把小時），對方再全部下載（又等一次）。

快檔連結的 P2P 模式完全跳過這個過程——資料夾直接從你的裝置串流到對方那裡，沒有「先上傳再下載」這件事。

隱私問題

Google Drive 上的檔案，Google 有能力看到。如果你交的是未公開的作品、商業機密、或是客戶的個人資料，這不是你想要的。

快檔連結的端到端加密確保就算走伺服器中繼，內容也只有傳送方和收件方能解密。

收件人的麻煩

用 Google Drive 交件，對方常常反映：「我沒有 Google 帳號」、「它說我沒有權限」、「我不知道怎麼下載整個資料夾」。

快檔連結生成的是一個普通的 HTTPS 連結，對方用任何瀏覽器打開就能下載，不需要帳號，不需要安裝任何東西。

你知不知道對方收到了

Google Drive 不會告訴你對方有沒有下載。你得等對方主動回覆，或是再傳一次訊息問「你有收到嗎？」

快檔連結支援下載通知，對方一下載你就知道了。

WeTransfer 呢？

WeTransfer 比較像「一次性丟檔案」的工具，上傳後連結幾天就失效了，沒有品牌頁面、沒有通知、免費版 2GB 的上限更是限制不少。

對偶爾傳一張圖的情境還可以，但對「我每個月都要交付多個專案」的人來說，它解決不了問題。

什麼情況下雲端硬碟還是合適的？

如果你需要的是「長期儲存、隨時取用」，Google Drive 和 Dropbox 當然是好選擇。它們本來就是設計來做這件事的。

但如果你的需求是「把這個東西交給對方」——特別是大檔、需要隱私保護、或是想讓交件過程看起來更專業——快檔連結才是為這個場景設計的工具。

想試試看？下載免費版，P2P 直傳本來就是永久免費的。

Complete FastFileLink Feature List

2026-04-12T10:00:00+08:00

FastFileLink is built specifically for file delivery. This page gives you the full feature list so you can quickly see what it helps you do.

Transfer modes

P2P direct transfer (device to device)

Files go straight from your device to the recipient's device, without passing through any server
Completely free, with no file size limit
Full NAT traversal support, with no manual network setup required
Send folders directly without zipping first
End-to-end encryption is applied automatically during transfer

Cloud relay (upload now, download later)

The best fallback when the recipient is offline or cannot receive the file in real time
Files are encrypted before upload and stored on secure servers for the number of days you choose
Supports resumable uploads, so interrupted large uploads do not have to start over
Recipients can open the link in any browser and download with no account required
Usage-based points pricing, so you pay for what you use instead of being locked into a monthly subscription

Download page and branding

Custom branded download page with your company name, logo, and message
Makes delivery look intentional and professional instead of sending a random cloud link
Optional password protection so only the intended recipient can download
Recipient identity verification supported through email verification

Notifications and tracking

You get notified when the recipient completes the download
Download status and receipts are available, so you do not have to send follow-up messages asking whether the file arrived
You can set a maximum download count to prevent the link from being shared too widely

Receiving files

FastFileLink is not only for sending, it also lets you collect files from other people
Create an upload link so others can send files to you with no account and no installation

Privacy and security

End-to-end encryption (E2EE): even when the server is involved, we still cannot read your content
Privacy mode: no identifiable link information is left on the server
Enterprise-grade encryption standards

For developers and advanced use

Open-source CLI: ideal for developers, automation workflows, and script integration (GitHub)
MCP support: connect FastFileLink to AI agents and automated tasks (GitHub)
Portable executable: no installation required, and easy to carry on a USB drive

Plans and pricing

P2P direct transfer: free forever, with no size limit
Cloud relay: points-based billing, with 5 free points included on the free plan and top-ups when needed
Free plan: cloud retention for 3 days
Standard plan (100 points): cloud retention for 14 days
Pro plan (300 points): cloud retention for 30 days, extendable
One-time purchase with lifetime license and updates, no recurring subscription required

Haven't downloaded it yet? Start with the free version. P2P direct transfer is already free by default.

快档连结完整功能列表

2026-04-12T10:00:00+08:00

快档连结（FastFileLink）是为了「交件」这件事专门设计的工具。这里整理了完整的功能清单，让你一眼看清楚它能帮你做到什么。

传输方式

P2P 直传（装置对装置）

档案从你的装置直接传到对方，不经过任何服务器
完全免费，没有档案大小限制
支援完整的防火墙穿透（NAT traversal），不需手动设定
资料夹不必先压缩，直接选取即可传送
传输过程中自动端到端加密

上云代收（服务器中继）

对方不在线、无法即时收件时的最佳备案
档案加密后上传至安全服务器，保留指定天数
支援断点续传，大型档案上传中断也不怕
收件人用任何浏览器打开连结即可下载，不需账号
点数制计费，用多少算多少，不被月租绑住

下载页面与品牌自订

自订品牌下载页，展示公司名称、Logo 与说明文字
让收件人感觉你是有在认真做事的人，而不是随手贴个云端连结
可设定密码保护，确保只有指定收件人能下载
支援收件者身份验证（Email 验证）

通知与追踪

对方下载完成后，你会收到通知
可查看下载状态与回条，不用再传信息问「你收到了吗？」
可设定最大下载次数限制，防止连结被过度散布

收档功能

不只能「送出」，也能向对方「收档」
建立收件连结，让对方把档案传给你，同样免账号、免安装

隐私与安全

端到端加密（E2EE）：就算走服务器，我们也看不到你的内容
隐私模式：连结不在服务器端留有任何可识别资讯
企业级加密标准

开发者与进阶使用

开源 CLI 版本：适合开发者、自动化流程与脚本整合（GitHub）
MCP 支援：可接入 AI Agent 与自动化任务（GitHub）
可携执行档，免安装，随身碟带着走也能用

方案与费用

P2P 直传：永久免费，无限大小
上云代收：点数制，免费方案赠送 5 点，之后按需补充
免费方案：云端保留 3 天
标准版（100 点）：云端保留 14 天
专业版（300 点）：云端保留 30 天（可延展）
一次购买，终身授权与更新，不需长期订阅

还没下载？先从免费版开始，P2P 直传本来就是免费的。

快檔連結完整功能列表

2026-04-12T10:00:00+08:00

快檔連結（FastFileLink）是為了「交件」這件事專門設計的工具。這裡整理了完整的功能清單，讓你一眼看清楚它能幫你做到什麼。

傳輸方式

P2P 直傳（裝置對裝置）

檔案從你的裝置直接傳到對方，不經過任何伺服器
完全免費，沒有檔案大小限制
支援完整的防火牆穿透（NAT traversal），不需手動設定
資料夾不必先壓縮，直接選取即可傳送
傳輸過程中自動端到端加密

上雲代收（伺服器中繼）

對方不在線、無法即時收件時的最佳備案
檔案加密後上傳至安全伺服器，保留指定天數
支援斷點續傳，大型檔案上傳中斷也不怕
收件人用任何瀏覽器打開連結即可下載，不需帳號
點數制計費，用多少算多少，不被月租綁住

下載頁面與品牌自訂

自訂品牌下載頁，展示公司名稱、Logo 與說明文字
讓收件人感覺你是有在認真做事的人，而不是隨手貼個雲端連結
可設定密碼保護，確保只有指定收件人能下載
支援收件者身分驗證（Email 驗證）

通知與追蹤

對方下載完成後，你會收到通知
可查看下載狀態與回條，不用再傳訊息問「你收到了嗎？」
可設定最大下載次數限制，防止連結被過度散布

收檔功能

不只能「送出」，也能向對方「收檔」
建立收件連結，讓對方把檔案傳給你，同樣免帳號、免安裝

隱私與安全

端到端加密（E2EE）：就算走伺服器，我們也看不到你的內容
隱私模式：連結不在伺服器端留有任何可識別資訊
企業級加密標準

開發者與進階使用

開源 CLI 版本：適合開發者、自動化流程與腳本整合（GitHub）
MCP 支援：可接入 AI Agent 與自動化任務（GitHub）
可攜執行檔，免安裝，隨身碟帶著走也能用

方案與費用

P2P 直傳：永久免費，無限大小
上雲代收：點數制，免費方案贈送 5 點，之後按需補充
免費方案：雲端保留 3 天
標準版（100 點）：雲端保留 14 天
專業版（300 點）：雲端保留 30 天（可延展）
一次購買，終身授權與更新，不需長期訂閱

還沒下載？先從免費版開始，P2P 直傳本來就是免費的。

Is AI Making Programming Harder? Why "Test Only, Zero Code Review" is an Absolute Disaster

2026-02-21T10:25:00+08:00

Recently, an article titled "AI Fatigue is Real" struck a massive chord, perfectly echoing what many developers are feeling right now: programming in the AI era has actually become more exhausting.

Because we’ve transitioned from being Creators (Builders) to Reviewers. AI generates code so fast and inconsistently that the burden of reviewing has become overwhelmingly heavy: first, it's impossible to enter a flow state; second, you are constantly context-switching; third, this kind of high-density micro-reviewing is incredibly draining and quickly pushes you into "decision fatigue."

Recently, while promoting my open-source project, the fastfilelink CLI (ffl), across various communities, I’ve been lurking and observing mainstream developer discussions. What I saw was endless anxiety, boundless hype, and a flood of "AI will replace developers" methodologies, all accompanied by massive amounts of poorly crafted code.

Some of it makes sense, but a huge portion of it is, frankly speaking, utter bullshit.

To combat this fatigue, a new, incredibly sweet-sounding proposition has emerged in the community (especially driven by the current OpenClaw-dominated faction):

"Don’t review code; review output / tests passed."

Some people even use compilers as an analogy, arguing that we don't review the assembly generated by a compiler today either. Personally, I think this argument is complete dogshit. The reason is simple:

1. LLMs are not Compilers; they lack "Determinism"

A compiler uses strict syntax for deterministic translation, but an LLM is a probabilistic model. When you ask an LLM to generate test cases, sometimes the tests themselves are fake or of terrible quality. Even if all the tests show green, it doesn't mean the system is fine. You ultimately have to review these test cases, so the premise of "not reviewing at all" is fundamentally unreliable.

2. Lack of Global Vision leads to the collapse of the Single Source of Truth

Constrained by the extreme limits of context windows and RAG capabilities, LLMs can only see fragments of a project; they cannot comprehend the system as a whole. This results in generated code packed with extreme redundancy, completely violating the DRY (Don't Repeat Yourself) principle. Once requirements change, it's incredibly prone to producing a massive amount of inconsistent bugs.

3. The Context Window Limit is a short-term unsolvable fatal flaw

Stop fantasizing that "it'll be fine once the models get stronger." Bound by the physical limits of training data and attention mechanisms, context windows will always have a ceiling (not to mention that no matter how big the context window gets, projects will only get bigger). Therefore, the architectural collapse mentioned in Point 2 is practically unsolvable in the foreseeable future.

4. Trapped in a "Chicken-and-Egg" infinite loop

To prevent those weird, unpatched, and inconsistent edge-case bugs from Point 2, your Test Coverage must approach 100%, and the tests must be designed with extreme rigor. This brings us right back to Point 1: Test Cases are themselves Code, heavily copy/pasted by the LLM.

If you want to save yourself the effort of reviewing Production Code, you must spend equal (or even more) effort reviewing a massive pile of Test Code. You are merely trading one hell for another.

The Cruel Reality: This is a game of "Compute Capitalism"

Therefore, the methodology of only caring if test cases pass while ignoring the code has fundamental flaws. It's more of an AI hype—it sounds awesome, but in practice, it’s riddled with issues. You're just swapping one problem for another.

Of course, you might argue: "But it seems to work! As long as we only care about tests/outputs, if we give the LLM enough time and tokens to fix it, it can eventually pass the tests."

Oh, yeah, sure! Because as the project grows larger and gets filled with more and more repetitive logic created by the LLM, you can indeed just throw money at it and let it slowly fix things. But the key points are:

Not reviewing is impossible: You’ve just shifted the target of your review from Production Code to Test Cases. That is still Code, and it still drains your brainpower.
Maintenance costs compound exponentially: Once technical debt stacks up, fixing even a minor bug will cost increasingly more tokens and time.

People are lazy. Who wouldn't want to dump all their work onto AI? (Especially for the vast majority of developers who don't even enjoy coding that much—to them, it's just a job). So, this narrative that "AI can do everything for you" is guaranteed to excite people, while simultaneously peddling anxiety.

But who is the ultimate beneficiary? It's the AI development tool vendors. The more bloated the code is, and the more times you need to debug, the more money they make. The cruel truth they don’t want you to know is that the oldest software engineering adage still holds true: "No Silver Bullet."

AI 时代写程序反而更累？「只看 Test 不 Review Code」根本是场灾难

2026-02-21T10:25:00+08:00

最近有一篇文章《AI Fatigue is Real》引发了强烈共鸣，完美说出了现在许多开发者的心声：AI 时代编程反而更累了。

因为我们从创造者（Builder）变成了审查者（Reviewer）。AI 产出源代码的速度太快又不稳定，导致 Review 的负担变得极重：一来无法进入心流，二来不断 Context switch，三来这种高密度的微观审查，是种极大的消耗，很快就会让人陷入「决策疲劳」。

最近我在各大社群推广我的开源项目 fastfilelink CLI (ffl) 时，潜水观察了主流开发者的讨论。我看到的是满满的焦虑、无止尽的 Hype，以及伴随着大量粗制滥造的源代码，所衍生出各种「AI 将取代开发者」的方法论。

其中有些确实有道理，但有很大一部分，说白了就是鬼扯。

为了对抗这种疲劳，现在社群（特别是现在以 OpenClaw 为主的流派）诞生了一种听起来很爽的主张：

"Don’t review code; review output / tests passed."（不要 Review 源代码，只要 Test 会过就好。）

有人甚至拿 Compiler 来类比，说我们现在也不会去 Review Compiler 产生出来的 Assembly。我个人觉得这个说法根本狗屁不通。理由很简单：

1. LLM 不是 Compiler，它没有「确定性」

Compiler 是基于严格语法的确定性转换，但 LLM 是概率模型。你叫 LLM 产生 Test Case，它有时候连 Test 本身都是假的或质量不到位。就算绿灯全亮，也不代表系统没问题。你终究得去 Review 这些 Test Case，所以「完全不 Review」根本不靠谱。

2. 缺乏全域视野，导致 Single Source of Truth 崩坏

受限于 Context Window 及 RAG 的能力极限，LLM 只能看到项目的碎片，无法理解系统全貌。这导致它产生的源代码会有极度多的重复内容，完全不 DRY（Don't Repeat Yourself）。一旦需求变更，极容易产生大量不一致的 Bug。

3. Context Window 的极限是短期无解的硬伤

不要幻想「以后模型变强就好了」。受限于训练资料与注意力机制的物理极限，Context Window 永远会有天花板（更何况 Context window 不管多大，项目只会更大），所以第 2 点的架构崩坏问题，在可见的未来几乎是无解的。

4. 陷入「鸡生蛋、蛋生鸡」的无穷循环

为了防堵第 2 点那些奇奇怪怪的边角 Bug，你的 Test Coverage 必须逼近 100%，而且必须设计得极度严谨。这就回到了第 1 点：Test Case 本身也是 Code，也是 LLM 大量 Copy/Paste 写出来的。

如果你想省下 Review Production Code 的力气，你就必须花同等（甚至更多）的心力去 Review 庞大的 Test Code。你只是把一个地狱换成了另一个地狱。

残酷的现实：这是一场「算力资本主义」的游戏

所以，只看 Test Case 会过而不去管 Code 的方法论，有着根本上的基本问题。它更像是一种 AI Hype，听起来很爽，但实务上问题一大堆，只是把一个问题换成了另一个问题。

当然，你可能会说：「但似乎 it works 啊！只要只管 test / output，给 LLM 足够的时间和 Token 让它去修，它还是能把 test 跑过。」

哦，是啊！因为项目越来越大，被 LLM 搞得重复逻辑越来越多，你确实可以砸钱让它慢慢改。但重点是：

不 Review 是不行的： 只是你 Review 的对象从 Production Code 变成了 Test Case，那依然是 Code，依然消耗你的脑力。
维护成本呈指数级累加： 技术债叠加之后，改一个小 Bug 需要消耗的 Token 和时间越来越多。

人都懒，谁不想把所有工作都丢给 AI？（尤其是对本来就不那么享受写程序的绝大多数开发者来说，这只是一份工作）。所以这种「AI 可以帮你做完所有事」的叙事只会让人感到兴奋，同时也贩卖了焦虑。

但最终的受益者是谁？是那些 AI 开发工具商。 源代码越冗长、你需要 Debug 的次数越多，他们赚得越多。他们不想让你知道的残酷真相是：软件工程界那句老话依然适用——「没有银弹 (No Silver Bullet)」。

AI 時代寫程式反而更累？「只看 Test 不 Review Code」根本是場災難

2026-02-21T10:25:00+08:00

最近有一篇文章《AI Fatigue is Real》引發了強烈共鳴，完美說出了現在許多開發者的心聲：AI 時代編程反而更累了。

因為我們從創造者（Builder）變成了審查者（Reviewer）。AI 產出程式碼的速度太快又不穩定，導致 Review 的負擔變得極重：一來無法進入心流，二來不斷 Context switch，三來這種高密度的微觀審查，是種極大的消耗，很快就會讓人陷入「決策疲勞」。

最近我在各大社群推廣我的開源專案 fastfilelink CLI (ffl) 時，潛水觀察了主流開發者的討論。我看到的是滿滿的焦慮、無止盡的 Hype，以及伴隨著大量粗製濫造的程式碼，所衍生出各種「AI 將取代開發者」的方法論。

其中有些確實有道理，但有很大一部分，說白了就是鬼扯。

為了對抗這種疲勞，現在社群（特別是現在以 OpenClaw 為主的流派）誕生了一種聽起來很爽的主張：

"Don’t review code; review output / tests passed."（不要 Review 程式碼，只要 Test 會過就好。）

有人甚至拿 Compiler 來類比，說我們現在也不會去 Review Compiler 產生出來的 Assembly。我個人覺得這個說法根本狗屁不通。理由很簡單：

1. LLM 不是 Compiler，它沒有「確定性」

Compiler 是基於嚴格語法的確定性轉換，但 LLM 是機率模型。你叫 LLM 產生 Test Case，它有時候連 Test 本身都是假的或品質不到位。就算綠燈全亮，也不代表系統沒問題。你終究得去 Review 這些 Test Case，所以「完全不 Review」根本不靠譜。

2. 缺乏全域視野，導致 Single Source of Truth 崩壞

受限於 Context Window 及 RAG 的能力極限，LLM 只能看到專案的碎片，無法理解系統全貌。這導致它產生的程式碼會有極度多的重複內容，完全不 DRY（Don't Repeat Yourself）。一旦需求變更，極容易產生大量不一致的 Bug。

3. Context Window 的極限是短期無解的硬傷

不要幻想「以後模型變強就好了」。受限於訓練資料與注意力機制的物理極限，Context Window 永遠會有天花板（更何況 Context window 不管多大，專案只會更大），所以第 2 點的架構崩壞問題，在可見的未來幾乎是無解的。

4. 陷入「雞生蛋、蛋生雞」的無窮迴圈

為了防堵第 2 點那些奇奇怪怪的邊角 Bug，你的 Test Coverage 必須逼近 100%，而且必須設計得極度嚴謹。這就回到了第 1 點：Test Case 本身也是 Code，也是 LLM 大量 Copy/Paste 寫出來的。

如果你想省下 Review Production Code 的力氣，你就必須花同等（甚至更多）的心力去 Review 龐大的 Test Code。你只是把一個地獄換成了另一個地獄。

殘酷的現實：這是一場「算力資本主義」的遊戲

所以，只看 Test Case 會過而不去管 Code 的方法論，有著根本上的基本問題。它更像是一種 AI Hype，聽起來很爽，但實務上問題一大堆，只是把一個問題換成了另一個問題。

當然，你可能會說：「但似乎 it works 啊！只要只管 test / output，給 LLM 足夠的時間和 Token 讓它去修，它還是能把 test 跑過。」

哦，是啊！因為專案越來越大，被 LLM 搞得重複邏輯越來越多，你確實可以砸錢讓它慢慢改。但重點是：

不 Review 是不行的： 只是你 Review 的對象從 Production Code 變成了 Test Case，那依然是 Code，依然消耗你的腦力。
維護成本呈指數級累加： 技術債疊加之後，改一個小 Bug 需要消耗的 Token 和時間越來越多。

人都懶，誰不想把所有工作都丟給 AI？（尤其是對本來就不那麼享受寫程式的絕大多數開發者來說，這只是一份工作）。所以這種「AI 可以幫你做完所有事」的敘事只會讓人感到興奮，同時也販賣了焦慮。

但最終的受益者是誰？是那些 AI 開發工具商。 程式碼越冗長、你需要 Debug 的次數越多，他們賺得越多。他們不想讓你知道的殘酷真相是：軟體工程界那句老話依然適用——「沒有銀彈 (No Silver Bullet)」。

Benefits of using server upload

2026-01-18T23:47:00+08:00

Why Choose FastFileLink’s Server Upload Mode?

FastFileLink offers two file transfer modes: P2P and Server Upload.
P2P focuses on real-time, peer-to-peer transfers, while Server Upload is built for flexibility, persistence, and advanced control.

This article highlights the key advantages of Server Upload, with a Quick Navigation section to help you jump directly to the topics you care about.

Quick Navigation

1. No need for both parties to be online at the same time
2. Asynchronous downloads for flexible collaboration
3. Limit downloads to control resource usage
4. Graceful handling when links expire or reach download limits
5. Update shared content without changing the link
6. Built for professional and long-term sharing

1. No need for both parties to be online at the same time

In P2P mode, file transfers require both the sender and the recipient to be online simultaneously. If either side goes offline, shuts down their device, or loses connection, the transfer cannot be completed.

With Server Upload mode, files are first uploaded to FastFileLink’s cloud servers. After the upload is complete, recipients can download the files at any time within the specified retention period, without needing the sender to stay online.

2. Asynchronous downloads for flexible collaboration

Server Upload enables true asynchronous file delivery, making it ideal for:

Cross-time-zone collaboration
Team-based workflows
Sharing files with multiple recipients at different times

Recipients can access the files whenever it’s convenient, without coordination or scheduling constraints.

3. Limit downloads to control resource usage

To avoid unnecessary or excessive downloads, Server Upload allows you to set a maximum download limit for each shared file.

Once the download count reaches the defined limit, the system automatically disables further downloads. This helps you keep usage predictable while ensuring resources are spent where they matter most.

4. Graceful handling when links expire or reach download limits

When a file expires or exceeds its maximum download count, you’re not limited to showing a generic “link expired” message.

With Redirect links, you can:

Display a custom message to inform downloaders
Redirect users to another destination, such as:
Your official website
A new or updated sharing link
The latest version of the file
A support or contact page

This creates a smoother experience and avoids broken or confusing links.

5. Update shared content without changing the link

When shared content needs to be updated, Server Upload lets you keep the original link unchanged.

By configuring a Redirect link, you can point users to a new file or a new sharing page, without having to resend links or worry about outdated URLs still being circulated. This is especially useful for public links, documentation, or large distribution lists.

6. Built for professional and long-term sharing

Server Upload is designed for real-world, professional use cases that require:

Stable, persistent file availability
Fine-grained control over access and usage
A polished and reliable sharing experience

These capabilities make Server Upload a strong choice for long-term file sharing, client delivery, and team collaboration.

Conclusion

Compared to P2P, Server Upload provides greater flexibility, stronger control, and a more professional sharing workflow.

From asynchronous downloads and download limits to redirect-based link management and content updates, Server Upload ensures your file sharing remains reliable, scalable, and future-proof.

Choose FastFileLink’s Server Upload mode to experience a more flexible and powerful way to share files.

使用云端上传的好处

2026-01-18T23:47:00+08:00

为什么选择快档连结的云端上传模式？

快档连结提供两种档案传递模式：P2P 与 云端上传。
P2P 着重于即时、点对点的传输，而云端上传则是为了弹性、持续性与进阶控管而设计。

本文将重点介绍 选择云端上传的主要优势，并提供一个 快速导览区块，协助你直接跳转到最关心的主题。

1. 不必双方同时在线

在 P2P 模式 下，档案传递必须建立在「传送方与接收方同时在线」的前提之上。只要其中一方离线、关闭装置，或网路中断，传输就无法完成。

使用 云端上传模式 时，档案会先上传至快档连结的云端伺服器。上传完成后，接收者可在指定的保存期限内随时下载档案，无需传送者持续保持在线。

2. 非同步下载，提升协作弹性

云端上传支援真正的 非同步档案传递，非常适合以下情境：

跨时区协作
团队型工作流程
在不同时间与多位接收者分享档案

接收者可以在自己方便的时间存取档案，无需事先协调或配合特定时程。

3. 限制下载次数以控管资源使用

为了避免不必要或过度的下载，云端上传允许你为每个分享的档案设定 最大下载次数限制。

当下载次数达到设定上限后，系统会自动停用后续下载。这能帮助你更可预期地控管使用量，并确保资源用在最重要的地方。

4. 当连结过期或达到下载上限时的优雅处理方式

当档案过期或 超过最大下载次数 时，你不再只能显示单调的「连结已失效」提示。

透过 重新导向连结（Redirect links），你可以：

显示自订讯息，向下载者说明状况
将使用者导向其他目的地，例如：
你的官方网站
新的或更新后的分享连结
最新版本的档案
客服或联络页面

这样的设计能带来更流畅的使用体验，避免出现中断或令人困惑的连结。

5. 不更换连结即可更新分享内容

当分享的内容需要更新时，云端上传让你能 维持原本的连结不变。

只要设定重新导向连结，即可将使用者指向新的档案或新的分享页面，无需重新寄送连结，也不必担心旧连结仍在流传。这对于公开连结、文件说明或大量发送的情境特别实用。

6. 专为专业与长期分享而打造

云端上传是为了实际的专业使用情境所设计，能满足以下需求：

稳定且可长期存取的档案可用性
更细致的存取与使用控管
专业且可靠的分享体验

这些特性使云端上传成为长期档案分享、客户交付与团队协作的理想选择。

结论

相较于 P2P，云端上传提供了更高的弹性、更强的控制能力，以及更专业的分享流程。

从非同步下载、下载次数限制，到基于重新导向的连结管理与内容更新，云端上传能确保你的档案分享流程稳定、可扩充，并具备长期使用的可靠性。

选择 快档连结的云端上传模式，体验更弹性且更强大的档案分享方式。

使用雲端上傳的好處

2026-01-18T23:47:00+08:00

為什麼選擇快檔連結的雲端上傳模式？

快檔連結提供兩種檔案傳遞模式：P2P 與 雲端上傳。
P2P 著重於即時、點對點的傳輸，而雲端上傳則是為了彈性、持續性與進階控管而設計。

本文將重點介紹 選擇雲端上傳的主要優勢，並提供一個 快速導覽區塊，協助你直接跳轉到最關心的主題。

索引

1. 不必雙方同時在線
2. 非同步下載，提升協作彈性
3. 限制下載次數以控管資源使用
4. 當連結過期或達到下載上限時的優雅處理方式
5. 不更換連結即可更新分享內容
6. 專為專業與長期分享而打造

1. 不必雙方同時在線

在 P2P 模式 下，檔案傳遞必須建立在「傳送方與接收方同時在線」的前提之上。只要其中一方離線、關閉裝置，或網路中斷，傳輸就無法完成。

使用 雲端上傳模式 時，檔案會先上傳至快檔連結的雲端伺服器。上傳完成後，接收者可在指定的保存期限內隨時下載檔案，無需傳送者持續保持在線。

2. 非同步下載，提升協作彈性

雲端上傳支援真正的 非同步檔案傳遞，非常適合以下情境：

跨時區協作
團隊型工作流程
在不同時間與多位接收者分享檔案

接收者可以在自己方便的時間存取檔案，無需事先協調或配合特定時程。

3. 限制下載次數以控管資源使用

為了避免不必要或過度的下載，雲端上傳允許你為每個分享的檔案設定 最大下載次數限制。

當下載次數達到設定上限後，系統會自動停用後續下載。這能幫助你更可預期地控管使用量，並確保資源用在最重要的地方。

4. 當連結過期或達到下載上限時的優雅處理方式

當檔案過期或 超過最大下載次數 時，你不再只能顯示單調的「連結已失效」提示。

透過 重新導向連結（Redirect links），你可以：

顯示自訂訊息，向下載者說明狀況
將使用者導向其他目的地，例如：
你的官方網站
新的或更新後的分享連結
最新版本的檔案
客服或聯絡頁面

這樣的設計能帶來更流暢的使用體驗，避免出現中斷或令人困惑的連結。

5. 不更換連結即可更新分享內容

當分享的內容需要更新時，雲端上傳讓你能 維持原本的連結不變。

只要設定重新導向連結，即可將使用者指向新的檔案或新的分享頁面，無需重新寄送連結，也不必擔心舊連結仍在流傳。這對於公開連結、文件說明或大量發送的情境特別實用。

6. 專為專業與長期分享而打造

雲端上傳是為了實際的專業使用情境所設計，能滿足以下需求：

穩定且可長期存取的檔案可用性
更細緻的存取與使用控管
專業且可靠的分享體驗

這些特性使雲端上傳成為長期檔案分享、客戶交付與團隊協作的理想選擇。

結論

相較於 P2P，雲端上傳提供了更高的彈性、更強的控制能力，以及更專業的分享流程。

從非同步下載、下載次數限制，到基於重新導向的連結管理與內容更新，雲端上傳能確保你的檔案分享流程穩定、可擴充，並具備長期使用的可靠性。

選擇 快檔連結的雲端上傳模式，體驗更彈性且更強大的檔案分享方式。

How Do You Send a 50GB Holiday Photo Album?

2025-10-21T19:45:00+08:00

The 50GB Post-Vacation Nightmare

Last week, three of us went on an amazing trip to Japan. We all came back with tons of photos and videos. Back home, the group chat started up:

"Hey, how are we sharing all the Japan files? I've got 10GB." "My drone footage alone is 30GB..." "I've got about 10GB too. So, 50GB total. How do we send this stuff to each other?"

Silence. The hardest part of the entire Japan trip... turned out to be sharing the photos.

"...WhatsApp or Messenger?" "You want to send 3,000 photos one by one? (lol) Besides, it'll crush the quality and pixelate the videos. We want the originals!"

"Okay, fine... Google Drive or Dropbox?" "Come on, who has 50GB of free space? Are we supposed to buy a subscription for one-time use?"

"Alright, alright... I'll just pay for a subscription this month!" friend A offered.

Why Cloud Storage Is a Terrible Option

"Are you made of money?" I shot back. "And even if you did, it's not a real solution. It's still a massive hassle."

"What? How is it a hassle? I paid. I just drag the folder up, right?"

"Theoretically," I said. "But have you thought about it? You're uploading thousands of files. What if the connection drops halfway through? And what about the people downloading? Are we supposed to download them one by one? Or use that 'Download as ZIP' function? You have to wait forever for it to compress!"

"A 'smarter' way is to ZIP that 10GB folder first, right? But your computer will be chugging away for half an hour just on that."

"And then? You start the 10GB upload. With good internet, that's 2 hours. Then we have to download for 2 hours, and then we have to unzip... it'll take all night!"

Friend A sighed. "...This is way too complicated. You know what? I'll just bring a hard drive over next time."

"That's a great idea," I said, "but we don't live next door. Who knows when we'll see each other next?"

"And..." friend C, who had been quiet, finally spoke up. "I really don't want our private, goofy photos sitting on Google's servers."

Friend A: "Google is a huge company, it's probably fine, right?"

"Seriously?" C retorted. "How do you know some engineer won't see our photos during a debug or system check?"

"Exactly!" I added. "Next thing you know, your files leak, and you're the next Jennifer Lawrence!"

"No way!" C said. "So if we're going to send them, they must be encrypted first! That's the minimum."

"See?" I continued. "And if we listen to C, you have to 'encrypt and compress' that 10GB folder... your computer will be tied up for an hour, even worse than you thought!"

"And not to mention," I added, delivering the final blow, "even if you, A, pay for 2TB of space... what about us? We still only have 15GB of free space, and it's almost full! We'd have to delete our own old files just to make room to receive yours. That's the real hassle."

Is "sneakernet" (passing around a hard drive) really our best option in 2025?

The "Aha!" Moment — The Tool We Built for Interns

Just as we were about to give up, something clicked.

"Wait... I just remembered a small tool we use at my company."

A few weeks ago, we needed a secure way for interns to hand over their final project files (scripts, docs, configs) when they finished their internships.

The requirements were very specific: 1. It had to be secure: Files couldn't be leaked. P2P (peer-to-peer) was the ideal. 2. It had to be flexible: If the intern wasn't available for a live P2P transfer, we needed a "secure server" fallback. 3. It had to be automatic: This was key. We didn't want interns fumbling with encryption. The tool had to automatically lock the files, ensuring they were secure even on the server.

I suddenly realized... this tool perfectly matched every single condition we just laid out.

How FastFileLink Solved the Mess

I immediately sent FastFileLink to my friends. Its two modes handled our situation perfectly.

Scenario 1: Me and Friend A (The P2P Direct Mode)

That night, friend A and I were both at home. We decided to use the "P2P Direct" mode.

I dragged my 10GB "folder" into the tool.
It instantly generated a link—no waiting, because it skipped all the "compression" and "uploading" steps.
I pasted the link to friend A.
The moment he clicked it, the files began to encrypt and stream from my laptop directly to his.

In less than an hour, we had exchanged 20GB of original files. No one had to buy cloud storage, no one stared at a progress bar, and the files never sat on a third-party server, which perfectly satisfied C's privacy concerns.

Scenario 2: Friend B (The Secure Server Mode)

But friend B, with his 30GB of drone footage, had to work late.

"I can't do a P2P transfer now," he said. "I'll send it to you guys later."

This was the perfect time for FastFileLink's other feature.

Friend B chose the "Server Relay" mode from the start.
The tool automatically handled the "on-the-fly encryption and compression" of the 30GB folder on his computer.
This fully encrypted package (so secure even B couldn't open it) was uploaded to our secure server.
He sent us the link and went to bed.

The next day, friend A and I downloaded and decrypted the 30GB of footage whenever it was convenient for us.

A Tool Built to Solve Real-World "Hassles"

That's the story behind FastFileLink.

It's not a tool designed for "perfect" conditions. It was built from day one to handle all the real-world messes:

You want the fastest, most private way? Use P2P Direct.
Your schedules don't line up? Use the Secure Server mode.
You're worried about privacy? It's all end-to-end encrypted, automatically.

It started as a solution for our intern handovers, and then it accidentally solved our massive "holiday photo" problem.

We realized this pain was universal. Whether it's designers delivering projects, videographers sending master files, or just friends like us, trying to share precious memories.

A tool we built for ourselves, and now, we're proud to share it with the world.

50GB 的假期相簿，你要怎么传？

2025-10-21T19:45:00+08:00

上个星期，我们 3 个人一起去日本玩，每个人都拍了许多照片和影片。回到家，我们在群组里开始讨论：

「嘿，大家怎么分享这次日本的照片？我这里有 10GB。」「我的空拍机影片（对，我还带了空拍机）有 30GB...」「我这边加起来也快 10GB。总共 50GB，我们要怎么互传？」

一阵沉默。这趟日本行最困难的部分，竟然是「分享照片」。

「...用 WhatsApp 或 LINE 传？」「你传 3000 张照片试试看？(笑) 而且画质会全部被压缩，影片也会糊掉。我们要的是『原始档』啊！」

「好吧，那... Google Drive 或 Dropbox？」「拜托，我们谁的免费空间有 50GB？为了传一次档案去买订阅吗？」

「好吧，那...大不了我这个月课金！」朋友A提议。

云端硬碟，真的不是个好选项

「你钱太多哦？」我白了他一眼，「而且那也不是办法，很麻烦。」

「蛤？哪里麻烦？付钱了还不方便吗？直接把资料夹拖上去不就好了？」

「理论上是这样。」我说，「但你有想过，你上传那几千个档案，传到一半断线怎么办吗？而且，下载的人呢？难道要我们一张一张点下载？还是要用那个『打包下载成 ZIP』的功能？那个打包也要等半天！」

「比较方便的方法是，把你那 10GB 的资料夹『压缩』成一个超大的 ZIP 档？但光是这一步，你电脑可能就要跑半天。」

「然后呢？你开始上传。10GB 档案，就算网路不错也要传个 2 小时吧。好，你传完了，换我们要下载，又是 2 小时。下载完还要解压缩...天都亮了！」

朋友A：「...好像真的很麻烦欸。不然，我下次带随身碟（硬碟）拿给你们？」

「这倒是个办法，」我苦笑着，「但我们又不住隔壁，下次见面不知何时了。」

「而且...」一直没说话的朋友C这时开口了，「我才不想把我们那些私密的搞怪照丢到 Google 上。」

朋友A：「Google 是大公司欸，应该还好吧？」

「拜托，」朋友C反驳，「你怎么知道他们哪个工程师，不会因为除错、还是什么系统整理，就看到我们的照片？」

「对啊！」我补了一枪，「到时候档案流出去，你就变成下一个陈冠希，要红了！」

「我才不要！」朋友C说，「所以，如果要传，档案一定要先加密！这是最低要求！」

「这就对了！」我接着说，「如果你要听C的，先加密再上传，那你那个 10GB 资料夹，『加密加压缩』起来，你电脑可能就要跑 1 小时，比你原来想的还惨！」

「还有，」我补上最后一刀，「就算你课金了有 2TB 空间。我们呢？我们还是只有 15GB 免费空间，而且早就快用光了！我们还得先去删自己的旧档案，清出空间来，这才叫麻烦！」

难道都 2025 年了，我们最好的选择只剩下「用随身碟人肉快递」吗？

「啊哈！」—— 那个我们为实习生打造的工具

就在我们一筹莫展时，我突然想到了。

「等等...我想起我们公司内部用的一个小工具。」

几周前，公司为了让实习生在结束实习时，能安全地交接他们的专案档案（脚本、文件、设定档），我们打造了一个内部工具。

当时的需求很明确： 1. 要够安全：档案绝不能外流，最好是P2P（点对点）直传。 2. 要够灵活：如果实习生没空 P2P，也要有「安全上传」的备案。 3. 要自动加密：这点最重要。我们不想让实习生自己搞加密，工具必须自动把档案锁好，确保就算走伺服器模式，档案内容也绝不外泄。

我突然意识到，这不就完美符合我们刚刚开出的所有条件吗？

快档连结如何解决这场混乱

我立刻把快档连结丢给了朋友们。它有两种模式，完美地应对了我们的需求。

场景一：我和朋友A (P2P 直传模式)

那天晚上，我跟朋友A刚好都在家。我们决定使用「P2P 直传」模式。

我把我的 10GB 「资料夹」拖进去。
它「立刻」就产生了一个连结——完全不用等待，因为它跳过了所有「压缩」和「上传」的步骤。
我把连结贴给朋友A。
他一点开，档案就开始从我的电脑，「加密并串流」到他的电脑。

不到一小时，我们就交换完了 20GB 的原始档。没有人需要买云端空间，没有人需要等待进度条，而且档案从未经过任何第三方伺服器，完美回应了朋友C对隐私的担忧。

场景二：朋友B (安全伺服器模式)

但拥有 30GB 空拍机影片的朋友B，那天晚上刚好要加班。

「我没办法跟你们P2P，我晚点弄好再传给你们。」他说。

这正是快档连结的另一个功能派上用场的时候。

朋友B一开始就选择了「云端中继」模式。
工具自动在他的电脑上，将那 30GB 的资料夹「即时加密并压缩」。
然后，这个「连B自己都打不开」的加密包，被上传到我们的安全云端上。
他传完连结，就安心去睡觉了。

隔天，我跟朋友A在各自方便的时间，点开连结，就把那 30GB 的档案下载回来解密了。

一个为了解决真实世界「麻烦」而生的工具

这就是快档连结背后的故事。

它不是一个在「理想状态」下才好用的工具。它一开始就被设计来处理「真实世界」的各种麻烦：

你想最快、最私密？用 P2P 直传。
你们时间对不上？用安全云端模式。
你担心隐私外泄？它全程自动加密。

它最初是为了解决「实习生交接」问题，接着又意外地解决了我们这次「日本行相簿」这个大麻烦。

我们意识到，这个痛苦是共通的。无论是设计师交付专案、影片工作者传送母带，或是像我们一样，只是想和朋友分享珍贵的回忆。

一个我们为自己打造的工具，现在，我们很自豪地将它分享给全世界。

50GB 的假期相簿，你要怎麼傳？

2025-10-21T19:45:00+08:00

上個星期，我們 3 個人一起去日本玩，每個人都拍了許多照片和影片。回到家，我們在群組裡開始討論：

「嘿，大家怎麼分享這次日本的照片？我這裡有 10GB。」「我的空拍機影片（對，我還帶了空拍機）有 30GB...」「我這邊加起來也快 10GB。總共 50GB，我們要怎麼互傳？」

一陣沉默。這趟日本行最困難的部分，竟然是「分享照片」。

「...用 WhatsApp 或 LINE 傳？」「你傳 3000 張照片試試看？(笑) 而且畫質會全部被壓縮，影片也會糊掉。我們要的是『原始檔』啊！」

「好吧，那... Google Drive 或 Dropbox？」「拜託，我們誰的免費空間有 50GB？為了傳一次檔案去買訂閱嗎？」

「好吧，那...大不了我這個月課金！」朋友A提議。

雲端硬碟，真的不是個好選項

「你錢太多哦？」我白了他一眼，「而且那也不是辦法，很麻煩。」

「蛤？哪裡麻煩？付錢了還不方便嗎？直接把資料夾拖上去不就好了？」

「理論上是這樣。」我說，「但你有想過，你上傳那幾千個檔案，傳到一半斷線怎麼辦嗎？而且，下載的人呢？難道要我們一張一張點下載？還是要用那個『打包下載成 ZIP』的功能？那個打包也要等半天！」

「比較方便的方法是，把你那 10GB 的資料夾『壓縮』成一個超大的 ZIP 檔？但光是這一步，你電腦可能就要跑半天。」

「然後呢？你開始上傳。10GB 檔案，就算網路不錯也要傳個 2 小時吧。好，你傳完了，換我們要下載，又是 2 小時。下載完還要解壓縮...天都亮了！」

朋友A：「...好像真的很麻煩欸。不然，我下次帶隨身碟（硬碟）拿給你們？」

「這倒是個辦法，」我苦笑著，「但我們又不住隔壁，下次見面不知何時了。」

「而且...」一直沒說話的朋友C這時開口了，「我才不想把我們那些私密的搞怪照丟到 Google 上。」

朋友A：「Google 是大公司欸，應該還好吧？」

「拜託，」朋友C反駁，「你怎麼知道他們哪個工程師，不會因為除錯、還是什麼系統整理，就看到我們的照片？」

「對啊！」我補了一槍，「到時候檔案流出去，你就變成下一個陳冠希，要紅了！」

「我才不要！」朋友C說，「所以，如果要傳，檔案一定要先加密！這是最低要求！」

「這就對了！」我接著說，「如果你要聽C的，先加密再上傳，那你那個 10GB 資料夾，『加密加壓縮』起來，你電腦可能就要跑 1 小時，比你原來想的還慘！」

「還有，」我補上最後一刀，「就算你課金了有 2TB 空間。我們呢？我們還是只有 15GB 免費空間，而且早就快用光了！我們還得先去刪自己的舊檔案，清出空間來，這才叫麻煩！」

難道都 2025 年了，我們最好的選擇只剩下「用隨身碟人肉快遞」嗎？

「啊哈！」—— 那個我們為實習生打造的工具

就在我們一籌莫展時，我突然想到了。

「等等...我想起我們公司內部用的一個小工具。」

幾週前，公司為了讓實習生在結束實習時，能安全地交接他們的專案檔案（腳本、文件、設定檔），我們打造了一個內部工具。

當時的需求很明確： 1. 要夠安全：檔案絕不能外流，最好是P2P（點對點）直傳。 2. 要夠靈活：如果實習生沒空 P2P，也要有「安全上傳」的備案。 3. 要自動加密：這點最重要。我們不想讓實習生自己搞加密，工具必須自動把檔案鎖好，確保就算走伺服器模式，檔案內容也絕不外洩。

我突然意識到，這不就完美符合我們剛剛開出的所有條件嗎？

快檔連結如何解決這場混亂

我立刻把快檔連結丟給了朋友們。它有兩種模式，完美地應對了我們的需求。

場景一：我和朋友A (P2P 直傳模式)

那天晚上，我跟朋友A剛好都在家。我們決定使用「P2P 直傳」模式。

我把我的 10GB 「資料夾」拖進去。
它「立刻」就產生了一個連結——完全不用等待，因為它跳過了所有「壓縮」和「上傳」的步驟。
我把連結貼給朋友A。
他一點開，檔案就開始從我的電腦，「加密並串流」到他的電腦。

不到一小時，我們就交換完了 20GB 的原始檔。沒有人需要買雲端空間，沒有人需要等待進度條，而且檔案從未經過任何第三方伺服器，完美回應了朋友C對隱私的擔憂。

場景二：朋友B (安全伺服器模式)

但擁有 30GB 空拍機影片的朋友B，那天晚上剛好要加班。

「我沒辦法跟你們P2P，我晚點弄好再傳給你們。」他說。

這正是快檔連結的另一個功能派上用場的時候。

朋友B一開始就選擇了「雲端中繼」模式。
工具自動在他的電腦上，將那 30GB 的資料夾「即時加密並壓縮」。
然後，這個「連B自己都打不開」的加密包，被上傳到我們的安全雲端上。
他傳完連結，就安心去睡覺了。

隔天，我跟朋友A在各自方便的時間，點開連結，就把那 30GB 的檔案下載回來解密了。

一個為了解決真實世界「麻煩」而生的工具

這就是快檔連結背後的故事。

它不是一個在「理想狀態」下才好用的工具。它一開始就被設計來處理「真實世界」的各種麻煩：

你想最快、最私密？用 P2P 直傳。
你們時間對不上？用安全雲端模式。
你擔心隱私外洩？它全程自動加密。

它最初是為了解決「實習生交接」問題，接著又意外地解決了我們這次「日本行相簿」這個大麻煩。

我們意識到，這個痛苦是共通的。無論是設計師交付專案、影片工作者傳送母帶，或是像我們一樣，只是想和朋友分享珍貴的回憶。

一個我們為自己打造的工具，現在，我們很自豪地將它分享給全世界。

FastFileLink Technical FAQ

2025-10-20T11:22:00+08:00

Welcome to our Technical FAQ section!

Here you can find answers to technical questions about our service. If you’re looking for common information, please check out our FAQ.

Content

Q1. What is P2P (Peer-to-Peer), Device-to-Device, or "Directly Share" in FastFileLink?
Q2. What is Relayed P2P? How does FastFileLink handle connection issues?
Q3. What is NAT (Network Address Translation) and how does it affect FastFileLink?
Q4. What is "Resuming Download" or Continuation Transfer?
Q5. How does FastFileLink handle privacy and file security?
Q6. What is End-to-End Encryption (E2EE) and "Zero-Knowledge" in FastFileLink?
Q7. What is FastFileLink's core technology, and why isn't it a web-based tool?

Q1. What is P2P (Peer-to-Peer), Device-to-Device, or "Directly Share" in FastFileLink?

P2P (Peer-to-Peer), or Device-to-Device, is a method of sharing files directly between two computers over the internet without needing to upload the file to a central server first. When you use FastFileLink's "Directly share file (P2P) by local" option, your computer connects directly to the recipient's computer.

This process often utilizes web technologies like WebRTC (Web Real-Time Communication), which enables browsers and applications to establish direct communication channels. This means the file data travels from your device to the recipient's device, making the transfer potentially faster and more private as it doesn't rely on an intermediary server storing the file.

For more information on WebRTC, you can visit the WebRTC project website or its Wikipedia page. A key security feature of FastFileLink is that your own computer acts as its own signal server to establish the connection (see Q7 for more details), meaning no third-party server is involved in brokering the initial P2P handshake, further enhancing your privacy.

Q2. What is Relayed P2P? How does FastFileLink handle connection issues?

Sometimes, a direct P2P connection isn't possible. This can happen due to network configurations like certain types of NAT (Network Address Translation) or restrictive firewalls/ports that block direct connections. In such cases, FastFileLink uses a fallback mechanism called Relayed P2P. Instead of your file going through a generic WebRTC TURN server, FastFileLink will use its own dedicated relay server. This server acts as a go-between:

It uses port 443, the standard port for HTTPS/SSL traffic. This port is rarely blocked, ensuring a very high connection success rate even in restricted network environments.
The relay server only forwards data (socket-to-socket) between your computer and the recipient's.
Crucially, our relay server does not store any intermediate data or your files. It also keeps no logs of the transfer content, ensuring your privacy is maintained during the relay process.

Q3. What is NAT (Network Address Translation) and how does it affect FastFileLink?

NAT (Network Address Translation) is a method used by routers to allow multiple devices on a private network (like your home or office) to share a single public IP address when accessing the internet. You can think of it as a receptionist for your network, directing internet traffic to the correct device.

For more details, see the Wikipedia article on NAT. While NAT is essential, it can sometimes make direct P2P connections tricky because devices are hidden behind this shared IP. Technologies like WebRTC (used in our P2P sharing) have built-in mechanisms (like STUN/ICE) to discover the public IP address and attempt to establish direct connections even through many types of NAT. However, some NAT configurations are more restrictive. This is where FastFileLink's Relayed P2P feature becomes vital. By using our relay servers on port 443, we can achieve a very high connection reliability (e.g., around 99.9%), bypassing most NAT-related P2P connection issues.

Q4. What is "Resuming Download" or Continuation Transfer?

FastFileLink supports "Resuming Download" or Continuation Transfer, and we've put significant effort into making this robust.

During P2P Transfers: If a direct WebRTC connection becomes unstable, FastFileLink will attempt to fall back to our Relayed P2P connection. During this fallback, it uses standard HTTP Range requests to try and continue the download from where it left off, saving time and bandwidth.
In a Browser: Due to browser security restrictions, a browser cannot access partially saved files on your disk. This means if you completely close the browser tab or shut down your computer, the download cannot be resumed from scratch. However, as long as the connection is active (even if temporarily lost), our system will try to resume.
Using the FastFileLink CLI: For maximum reliability, the FastFileLink CLI supports a --resume flag. This allows you to continue a transfer at any time, even if the program was completely closed.
During Server Uploads: We also support resuming uploads for our Server Upload Mode. This is ideal for extremely large files (hundreds of GBs or even TBs) where P2P is impractical (requiring both users to be online for a very long time). You can upload a file in parts, even across several days, and it's fully compatible with End-to-End Encryption (E2EE). Our CLI even supports a --pause command to interrupt the upload at a specific percentage.

Q5. How does FastFileLink handle privacy and file security?

We prioritize your privacy and the security of your files:

During Direct P2P or Relayed P2P transfers: The connection established for transferring data is encrypted by default (using WebRTC's built-in DTLS). For maximum security, you can optionally enable End-to-End Encryption (E2EE). This adds a second layer of encryption, ensuring that even if the transfer falls back to our Relayed P2P server, the data is unreadable to us (making us a "Zero-Knowledge" server). As mentioned, our relay servers do not store your files or log transfer contents. The link generated for sharing is also protected by a random code, making it difficult for attackers to guess or use brute-force methods to access your download link. (See Q6 for more details on E2EE).
When using Server Upload Mode: If you choose to upload your file to the FastFileLink server, you can optionally enable End-to-End Encryption (E2EE). This ensures your privacy, making our server a Zero-Knowledge Server—we cannot see the contents of your file, guaranteeing your privacy. The connection itself is also encrypted. Files are stored only for the temporary retention period you select and are protected by our storage protocols before being periodically removed.
Application Security: The FastFileLink application itself is designed to be safe. We guarantee it contains no malware or malicious code.
- Certified Applications: Our Windows application is certified and available through the Microsoft Store. Files downloaded from the MS Store are signed directly by Microsoft, indicating they have passed their security review. Our macOS version is also signed by Apple.
- Transparency: The source code for our FastFileLink CLI is fully open-source. Anyone can audit the code to verify its security implementation and confirm there are no backdoors.

Q6. What is End-to-End Encryption (E2EE) and "Zero-Knowledge" in FastFileLink?

End-to-End Encryption (E2EE) is a security method that encrypts data on the sender's device and only decrypts it on the recipient's device. No one in between, including the service provider, can read the data.

Why is this important? FastFileLink already uses DTLS (Datagram Transport Layer Security) by default to encrypt all WebRTC traffic. However, we provide an optional, additional E2EE layer that you can enable for both P2P and Server Upload modes.

When you enable E2EE: - Your file is encrypted on your device before any data is sent. - This provides multiple layers of protection. Even if the underlying DTLS encryption were somehow compromised, your data would still be secure. - This ensures that even if your connection falls back to our Relayed P2P server, or if you use the Server Upload Mode, the data passing through our servers is encrypted, and we cannot see its contents.

This makes FastFileLink a Zero-Knowledge Server. We only manage the connection but have zero knowledge of the content you are transferring.

The only trade-off: Standard FastFileLink links can be downloaded using any HTTP tool (like curl or wget). However, when E2EE is enabled, these tools will only download the encrypted file (ciphertext). To successfully download and decrypt the file, the recipient must use a supported browser or the FastFileLink CLI: https://github.com/nuwainfo/ffl.

Q7. What is FastFileLink's core technology, and why isn't it a web-based tool?

Many P2P file-sharing tools (like ToffeeShare, Snapdrop, or Send Anywhere) operate primarily within a web browser. FastFileLink is a native application, a design based on our core technical principles:

FastFileLink's principle is to turn your own machine into a secure, temporary file server.

Here's how it works: 1. Local-as-Server: When you share a file, your computer opens a random port to serve that file. 2. Tunneling for NAT Traversal: To ensure anyone on the internet can connect to you (bypassing most NATs and firewalls), we use secure tunneling technology. This can be handled by our dedicated tunnel server, or you can opt to use an external tunnel service (like Cloudflare Tunnel) to expose your connection. 3. Automatic HTTPS: This tunneled connection is automatically secured with HTTPS, encrypting data in transit. 4. WebRTC P2P Transfer: FastFileLink then uses WebRTC for the direct P2P data transfer, but with a key difference: your computer also acts as its own WebRTC Signal Server. This means no central server is needed to manage the connection handshake, maximizing privacy.

Why this is better than a Web App: - Stability with Massive Files: Browsers have memory and processing limitations. Trying to share a very large file (e.g., 100GB+) or a folder with thousands of files via a web app can easily crash the browser tab or make it unresponsive. A native application like FastFileLink can handle these large-scale transfers much more efficiently and reliably. - Stronger Security & Privacy: By acting as a local server and managing its own signaling, FastFileLink removes the reliance on third-party signaling servers, giving you full control over the connection. - Guaranteed Connectivity: Our tunneling technology provides a more robust method for NAT traversal than standard WebRTC (which can fail in some restrictive networks), ensuring a higher connection success rate.

快档连结技术常见问题（Technical FAQ）

2025-10-20T11:22:00+08:00

欢迎来到快档连结的技术常见问题页面！

在这里你可以找到关于快档连结的技术性问题解答。如果你想查看一般使用相关的资讯，请参考我们的常见问题（FAQ）

内容

Q1. 快档连结中的 P2P（Peer-to-Peer）、Device-to-Device 或「Directly Share」是什么？
Q2. 什么是 Relayed P2P？快档连结如何处理连线问题？
Q3. 什么是 NAT（Network Address Translation），它如何影响快档连结？
Q4. 什么是「续传下载（Resuming Download）」或延续传输？
Q5. 快档连结如何处理隐私与档案安全？
Q6. 快档连结中的端对端加密（E2EE）与「零知识（Zero-Knowledge）」是什么？
Q7. 快档连结的核心技术是什么？为什么它不是一个纯 Web 工具？

Q1. 快档连结中的 P2P（Peer-to-Peer）、Device-to-Device 或「Directly Share」是什么？

P2P（Peer-to-Peer），也称为 Device-to-Device，是一种让两台电脑透过网际网路直接进行档案传输的方式，过程中不需要先将档案上传到中央伺服器。

当你使用快档连结的「Directly share file (P2P) by local」功能时，你的电脑会直接与接收方的电脑建立连线。

此流程通常会使用像是 WebRTC（Web Real-Time Communication）这类的网页技术，让浏览器或应用程式之间可以建立直接的通讯通道。这代表档案资料会直接从你的装置传送到对方的装置，不需要经过中介伺服器储存，因此在速度与隐私性上都更具优势。

若想了解更多 WebRTC 的资讯，可以参考 WebRTC 官方网站或其 Wikipedia 页面。

快档连结的一个关键安全特点是：你的电脑本身就扮演了讯号伺服器（Signal Server） 来建立连线（详见 Q7）。这表示在 P2P 连线初始化的过程中，并没有第三方伺服器参与，进一步提升你的隐私保护。

Q2. 什么是 Relayed P2P？快档连结如何处理连线问题？

在某些情况下，直接的 P2P 连线可能无法建立。这通常是因为特定的 NAT（网路位址转换）设定，或是防火墙／连接埠限制阻挡了直接连线。

当发生这种情况时，快档连结会启用一种备援机制，称为 Relayed P2P。不同于使用通用的 WebRTC TURN Server，快档连结会使用自有的专用中继伺服器，其运作方式如下：

使用 443 连接埠（HTTPS/SSL 的标准连接埠），此连接埠极少被封锁，因此即使在高度受限的网路环境中，也能维持极高的连线成功率。
中继伺服器仅负责在你的电脑与接收方之间转发资料（socket-to-socket）。
最重要的是：我们的中继伺服器不会储存任何中间资料或你的档案，也不会记录传输内容，确保在中继过程中依然维持你的隐私。

Q3. 什么是 NAT（Network Address Translation），它如何影响快档连结？

NAT（Network Address Translation）是路由器常用的一种技术，用来让多台位于私人网路中的装置（例如家中或公司）共用一个对外的公共 IP 位址上网。

你可以把 NAT 想象成网路的接待员，负责将外部的网路流量正确导向内部的装置。

虽然 NAT 非常重要，但它有时会让直接的 P2P 连线变得困难，因为装置实际上被隐藏在共用的 IP 位址后方。像 WebRTC（快档连结 P2P 传输所使用的技术）内建了 STUN / ICE 等机制，用来尝试找出公共 IP，并在多数 NAT 环境中建立直接连线。

然而，某些 NAT 设定仍然相当严格。这时，快档连结的 Relayed P2P 就变得至关重要。透过使用 443 连接埠的中继伺服器，我们可以绕过大多数 NAT 所带来的限制，达到极高的连线可靠度（例如约 99.9%）。

Q4. 什么是「续传下载（Resuming Download）」或延续传输？

快档连结支援「续传下载（Resuming Download）」或延续传输，且我们在这方面投入了大量心力来确保稳定性。

P2P 传输期间：若 WebRTC 直接连线变得不稳定，快档连结会尝试切换至 Relayed P2P。切换过程中，系统会使用标准的 HTTP Range 机制，尽可能从中断的位置继续下载，节省时间与频宽。
在浏览器中：由于浏览器的安全限制，浏览器无法存取磁碟上尚未完成的部分档案。因此，如果你完全关闭浏览器分页或关机，下载将无法在下次重新启动后继续。但只要连线尚未完全中断（即使短暂掉线），系统仍会尝试续传。
使用快档连结 CLI：若你需要最高等级的可靠性，快档连结 CLI 提供 --resume 参数，让你即使在程式完全关闭后，也能随时继续传输。
伺服器上传模式：我们同样支援伺服器上传模式的续传，非常适合超大型档案（数百 GB 甚至 TB 级），因为这类档案若使用 P2P，通常需要双方长时间同时在线。你可以分段、跨天上传档案，且完整支援 端对端加密（E2EE）。CLI 甚至提供 --pause 指令，让你在指定的上传进度暂停。

Q5. 快档连结如何处理隐私与档案安全？

我们非常重视你的隐私与档案安全：

Direct P2P 或 Relayed P2P 传输期间：所有资料传输连线预设即为加密（使用 WebRTC 内建的 DTLS）。你也可以选择性启用 端对端加密（E2EE），增加第二层保护。即使传输过程回退到 Relayed P2P，中继伺服器也无法读取资料内容，使我们成为真正的「零知识（Zero-Knowledge）」伺服器。分享连结本身也包含随机码，能有效防止暴力猜测。（更多 E2EE 细节请见 Q6）
伺服器上传模式：若你选择将档案上传至快档连结伺服器，也可选择性启用 E2EE，确保我们无法看到档案内容，使伺服器成为 Zero-Knowledge Server。档案仅会依你选择的暂存期限保存，并会定期清除。
应用程式本身的安全性：
官方签章：Windows 版本已上架 Microsoft Store，由 Microsoft 直接签署；macOS 版本亦由 Apple 签署。
透明性：我们的快档连结 CLI 为完全开源，任何人都可以审核程式码，验证其安全性与无后门设计。

Q6. 快档连结中的端对端加密（E2EE）与「零知识（Zero-Knowledge）」是什么？

端对端加密（End-to-End Encryption, E2EE） 是一种安全机制，资料会在传送端装置上加密，并只在接收端装置上解密，过程中包含服务提供者在内的任何第三方都无法读取内容。

为什么这很重要？ 快档连结预设已使用 DTLS 加密所有 WebRTC 传输，但我们仍提供一层可选的额外 E2EE 加密，适用于 P2P 与伺服器上传模式。

启用 E2EE 后： - 档案会在送出前就于你的装置上完成加密。 - 即使底层 DTLS 理论上遭到破解，资料仍然安全。 - 无论是 Relayed P2P 或伺服器上传模式，经过我们伺服器的资料都无法被我们读取。

这使得快档连结成为真正的 零知识（Zero-Knowledge）服务。

唯一需要注意的取舍：一般的快档连结下载连结可使用 curl、wget 等 HTTP 工具下载；但在启用 E2EE 后，这些工具只能取得加密后的档案。接收方必须使用支援的浏览器或 快档连结 CLI 才能正确解密档案： https://github.com/nuwainfo/ffl

Q7. 快档连结的核心技术是什么？为什么它不是一个纯 Web 工具？

许多 P2P 档案分享工具（如 ToffeeShare、Snapdrop、Send Anywhere）主要运作于浏览器中。而快档连结是一个原生应用程式，这是基于我们的核心技术理念：

快档连结的设计理念，是将你的电脑变成一个安全、暂时性的档案伺服器。

运作方式如下： 1. 本机即伺服器：分享档案时，你的电脑会开启一个随机连接埠来提供档案。 2. 穿透 NAT 的安全通道：为了让任何人都能连线到你，我们使用安全通道技术，可由快档连结自有通道，或由你选择外部服务（如 Cloudflare Tunnel）来建立。 3. 自动 HTTPS：通道连线会自动启用 HTTPS，确保传输过程加密。 4. WebRTC P2P 传输：快档连结使用 WebRTC 进行资料传输，且你的电脑同时也是 WebRTC 的讯号伺服器，不需要中央伺服器来协调连线，隐私性最高。

为什么这比 Web App 更好？ - 大型档案稳定性：浏览器在记忆体与处理能力上有限，分享 100GB 以上档案或大量档案时容易卡死。原生应用程式更稳定可靠。 - 更强的隐私与安全性：不依赖第三方讯号伺服器，连线完全由你掌控。 - 更高的连线成功率：通道技术比标准 WebRTC 更能应付受限网路环境，大幅提升成功率。

快檔連結技術常見問題（Technical FAQ）

2025-10-20T11:22:00+08:00

歡迎來到快檔連結的技術常見問題頁面！

在這裡你可以找到關於快檔連結的技術性問題解答。如果你想查看一般使用相關的資訊，請參考我們的常見問題（FAQ）

內容

Q1. 快檔連結中的 P2P（Peer-to-Peer）、Device-to-Device 或「Directly Share」是什麼？
Q2. 什麼是 Relayed P2P？快檔連結如何處理連線問題？
Q3. 什麼是 NAT（Network Address Translation），它如何影響快檔連結？
Q4. 什麼是「續傳下載（Resuming Download）」或延續傳輸？
Q5. 快檔連結如何處理隱私與檔案安全？
Q6. 快檔連結中的端對端加密（E2EE）與「零知識（Zero-Knowledge）」是什麼？
Q7. 快檔連結的核心技術是什麼？為什麼它不是一個純 Web 工具？

Q1. 快檔連結中的 P2P（Peer-to-Peer）、Device-to-Device 或「Directly Share」是什麼？

P2P（Peer-to-Peer），也稱為 Device-to-Device，是一種讓兩台電腦透過網際網路直接進行檔案傳輸的方式，過程中不需要先將檔案上傳到中央伺服器。

當你使用快檔連結的「Directly share file (P2P) by local」功能時，你的電腦會直接與接收方的電腦建立連線。

此流程通常會使用像是 WebRTC（Web Real-Time Communication）這類的網頁技術，讓瀏覽器或應用程式之間可以建立直接的通訊通道。這代表檔案資料會直接從你的裝置傳送到對方的裝置，不需要經過中介伺服器儲存，因此在速度與隱私性上都更具優勢。

若想了解更多 WebRTC 的資訊，可以參考 WebRTC 官方網站或其 Wikipedia 頁面。

快檔連結的一個關鍵安全特點是：你的電腦本身就扮演了訊號伺服器（Signal Server） 來建立連線（詳見 Q7）。這表示在 P2P 連線初始化的過程中，並沒有第三方伺服器參與，進一步提升你的隱私保護。

Q2. 什麼是 Relayed P2P？快檔連結如何處理連線問題？

在某些情況下，直接的 P2P 連線可能無法建立。這通常是因為特定的 NAT（網路位址轉換）設定，或是防火牆／連接埠限制阻擋了直接連線。

當發生這種情況時，快檔連結會啟用一種備援機制，稱為 Relayed P2P。不同於使用通用的 WebRTC TURN Server，快檔連結會使用自有的專用中繼伺服器，其運作方式如下：

使用 443 連接埠（HTTPS/SSL 的標準連接埠），此連接埠極少被封鎖，因此即使在高度受限的網路環境中，也能維持極高的連線成功率。
中繼伺服器僅負責在你的電腦與接收方之間轉發資料（socket-to-socket）。
最重要的是：我們的中繼伺服器不會儲存任何中間資料或你的檔案，也不會記錄傳輸內容，確保在中繼過程中依然維持你的隱私。

Q3. 什麼是 NAT（Network Address Translation），它如何影響快檔連結？

NAT（Network Address Translation）是路由器常用的一種技術，用來讓多台位於私人網路中的裝置（例如家中或公司）共用一個對外的公共 IP 位址上網。

你可以把 NAT 想像成網路的接待員，負責將外部的網路流量正確導向內部的裝置。

雖然 NAT 非常重要，但它有時會讓直接的 P2P 連線變得困難，因為裝置實際上被隱藏在共用的 IP 位址後方。像 WebRTC（快檔連結 P2P 傳輸所使用的技術）內建了 STUN / ICE 等機制，用來嘗試找出公共 IP，並在多數 NAT 環境中建立直接連線。

然而，某些 NAT 設定仍然相當嚴格。這時，快檔連結的 Relayed P2P 就變得至關重要。透過使用 443 連接埠的中繼伺服器，我們可以繞過大多數 NAT 所帶來的限制，達到極高的連線可靠度（例如約 99.9%）。

Q4. 什麼是「續傳下載（Resuming Download）」或延續傳輸？

快檔連結支援「續傳下載（Resuming Download）」或延續傳輸，且我們在這方面投入了大量心力來確保穩定性。

P2P 傳輸期間：若 WebRTC 直接連線變得不穩定，快檔連結會嘗試切換至 Relayed P2P。切換過程中，系統會使用標準的 HTTP Range 機制，盡可能從中斷的位置繼續下載，節省時間與頻寬。
在瀏覽器中：由於瀏覽器的安全限制，瀏覽器無法存取磁碟上尚未完成的部分檔案。因此，如果你完全關閉瀏覽器分頁或關機，下載將無法在下次重新啟動後繼續。但只要連線尚未完全中斷（即使短暫掉線），系統仍會嘗試續傳。
使用快檔連結 CLI：若你需要最高等級的可靠性，快檔連結 CLI 提供 --resume 參數，讓你即使在程式完全關閉後，也能隨時繼續傳輸。
伺服器上傳模式：我們同樣支援伺服器上傳模式的續傳，非常適合超大型檔案（數百 GB 甚至 TB 級），因為這類檔案若使用 P2P，通常需要雙方長時間同時在線。你可以分段、跨天上傳檔案，且完整支援 端對端加密（E2EE）。CLI 甚至提供 --pause 指令，讓你在指定的上傳進度暫停。

Q5. 快檔連結如何處理隱私與檔案安全？

我們非常重視你的隱私與檔案安全：

Direct P2P 或 Relayed P2P 傳輸期間：所有資料傳輸連線預設即為加密（使用 WebRTC 內建的 DTLS）。你也可以選擇性啟用 端對端加密（E2EE），增加第二層保護。即使傳輸過程回退到 Relayed P2P，中繼伺服器也無法讀取資料內容，使我們成為真正的「零知識（Zero-Knowledge）」伺服器。分享連結本身也包含隨機碼，能有效防止暴力猜測。（更多 E2EE 細節請見 Q6）
伺服器上傳模式：若你選擇將檔案上傳至快檔連結伺服器，也可選擇性啟用 E2EE，確保我們無法看到檔案內容，使伺服器成為 Zero-Knowledge Server。檔案僅會依你選擇的暫存期限保存，並會定期清除。
應用程式本身的安全性：
官方簽章：Windows 版本已上架 Microsoft Store，由 Microsoft 直接簽署；macOS 版本亦由 Apple 簽署。
透明性：我們的快檔連結 CLI 為完全開源，任何人都可以審核程式碼，驗證其安全性與無後門設計。

Q6. 快檔連結中的端對端加密（E2EE）與「零知識（Zero-Knowledge）」是什麼？

端對端加密（End-to-End Encryption, E2EE） 是一種安全機制，資料會在傳送端裝置上加密，並只在接收端裝置上解密，過程中包含服務提供者在內的任何第三方都無法讀取內容。

為什麼這很重要？ 快檔連結預設已使用 DTLS 加密所有 WebRTC 傳輸，但我們仍提供一層可選的額外 E2EE 加密，適用於 P2P 與伺服器上傳模式。

啟用 E2EE 後： - 檔案會在送出前就於你的裝置上完成加密。 - 即使底層 DTLS 理論上遭到破解，資料仍然安全。 - 無論是 Relayed P2P 或伺服器上傳模式，經過我們伺服器的資料都無法被我們讀取。

這使得快檔連結成為真正的 零知識（Zero-Knowledge）服務。

唯一需要注意的取捨：一般的快檔連結下載連結可使用 curl、wget 等 HTTP 工具下載；但在啟用 E2EE 後，這些工具只能取得加密後的檔案。接收方必須使用支援的瀏覽器或 快檔連結 CLI 才能正確解密檔案： https://github.com/nuwainfo/ffl

Q7. 快檔連結的核心技術是什麼？為什麼它不是一個純 Web 工具？

許多 P2P 檔案分享工具（如 ToffeeShare、Snapdrop、Send Anywhere）主要運作於瀏覽器中。而快檔連結是一個原生應用程式，這是基於我們的核心技術理念：

快檔連結的設計理念，是將你的電腦變成一個安全、暫時性的檔案伺服器。

運作方式如下： 1. 本機即伺服器：分享檔案時，你的電腦會開啟一個隨機連接埠來提供檔案。 2. 穿透 NAT 的安全通道：為了讓任何人都能連線到你，我們使用安全通道技術，可由快檔連結自有通道，或由你選擇外部服務（如 Cloudflare Tunnel）來建立。 3. 自動 HTTPS：通道連線會自動啟用 HTTPS，確保傳輸過程加密。 4. WebRTC P2P 傳輸：快檔連結使用 WebRTC 進行資料傳輸，且你的電腦同時也是 WebRTC 的訊號伺服器，不需要中央伺服器來協調連線，隱私性最高。

為什麼這比 Web App 更好？ - 大型檔案穩定性：瀏覽器在記憶體與處理能力上有限，分享 100GB 以上檔案或大量檔案時容易卡死。原生應用程式更穩定可靠。 - 更強的隱私與安全性：不依賴第三方訊號伺服器，連線完全由你掌控。 - 更高的連線成功率：通道技術比標準 WebRTC 更能應付受限網路環境，大幅提升成功率。

FastFileLink FAQ

2025-10-04T15:00:00+08:00

Welcome to our FAQ section!

Here you can find answers to common questions about our service. If you’re looking for more in-depth or technical information, please check out our Technical FAQ.

Content

Q1. Is the application secure?
Q2. Why Microsoft Defender SmartScreen block the application?
Q3. What is user points?
Q4. Why do some terminals suddenly flash when I terminate sharing file?
Q5. How does the server handle expired or failed uploaded files?
Q6. What is “Failed to connect server”?
Q7. Does “Directly share” require user points?
Q8. What is “User close the connection, please try again”?
Q9. What is “Could not find a copy/paste mechanism for your system.”?
Q10. Can anyone download the files I upload?
Q11. What is directly share?

Q1. Is the application secure?

Our application has passed most of generally antivirus detections. Only a little antivirus detections will overly cautiously label the application as Trojan because we provide directly P2P share feature. Besides, even the well-known web browser, Brave, have been false positive detected as Trojan in a little antivirus detections in VirusTotal. We promise that our application does not contain any malware or malicious code. For more detail, you can see here.

For maximum peace of mind, you can download the application from Microsoft Store. All Microsoft Store apps go through strict signing and security checks, so this version is guaranteed safe. The direct download version we provide is the same application—just in a portable format—so it is equally safe to use.

Q2. Why Microsoft Defender SmartScreen block the application?

Because each user’s application will have different serial numbers, Microsoft Defender SmartScreen flags them as different software, and will not put them to the list of files that are well known and downloaded frequently. For more detail, you can see Microsoft Defender SmartScreen overview | Microsoft Learn. If you still worried that the application could be a malware, you can submit it by Microsoft malware analysis or VirusTotal to check.

Q3. What is user points?

The user points are used for upload files to FastFileLink server and let the others can download files from FastFileLink server. The pricing of user points is related to the file size and its reservation time on server. How it works?

Q4. Why do some terminals suddenly flash when I terminate sharing file?

This is normal because the application is trying to clean the sharing file process.

Q5. How does the server handle expired or failed uploaded files?

Once a file expires, it will be removed from our server. In addition, we regularly clean up the server to ensure all files are properly deleted.

Q6. What is “Failed to connect server”?

“Failed to connect server” usually means the network between your computer and FastFileLink Server is unreachable. Please check your network connection or contact us.

Q7. Does “Directly share” require user points?

No, “Directly share” does not require any user points. It only need user to keep the application running until the others successfully download file.

Q8. What is “User close the connection, please try again”?

It means that the download from the others has been terminated by themselves or because of network instability.

Q9. What is “Could not find a copy/paste mechanism for your system.”?

It means that your computer does not install xclip or xsel. So the application cannot automatically copy share link into the clipboard. However, it will not affect you to share file, you can still use share link.

But if you still want to use this copy/paste feature, you can install the following tool depending on your Linux distribution by copying the appropriate command into your terminal:

For Ubuntu / Debian:

sudo apt update
sudo apt install xclip

For Arch Linux / Manjaro:

sudo pacman -S xclip

For Fedora / RHEL / CentOS:

sudo dnf install xclip

For openSUSE:

sudo zypper install xclip

If it’s still not working you can try install xsel instead. ex.

sudo apt install xsel

Once installed, try running your script again. pyperclip should now be able to copy text to the clipboard.

Q10. Can anyone download the files I upload?

No, only users with access to your unique link can download the file. The link is secured with a randomly generated code, making it resistant to brute-force attacks. Furthermore, we offer an account and password protection feature for shared documents, providing an additional layer of security for your files.

Q11. What is directly share?

It means that your file will be shared to the others by pure P2P (Device-to-Device P2P) or Relayed P2P, and will not upload the file to FastFileLink server. For more detail, you can see our Technical FAQs.

云端上传常见问题（FAQ）

2025-10-04T15:00:00+08:00

欢迎来到我们的常见问题（FAQ）页面！

在这里你可以找到关于本服务的常见问题解答。如果你正在寻找更深入或偏技术性的资讯，请参考我们的技术常见问题（Technical FAQ）。

内容

Q1. 这个应用程式安全吗？
Q2. 为什么 Microsoft Defender SmartScreen 会封锁这个应用程式？
Q3. 什么是使用者点数？
Q4. 为什么在我终止档案分享时，有些终端机会突然闪一下？
Q5. 伺服器如何处理过期或上传失败的档案？
Q6. 什么是「Failed to connect server」？
Q7.「Directly share」需要使用者点数吗？
Q8. 什么是「User close the connection, please try again」？
Q9. 什么是「Could not find a copy/paste mechanism for your system.」？
Q10. 任何人都可以下载我上传的档案吗？
Q11. 什么是直接分享（Directly share）？

Q1. 这个应用程式安全吗？

我们的应用程式已通过大多数防毒软体的检测。只有极少数防毒软体，因为我们提供直接的 P2P 分享功能，会过度谨慎地将此应用程式标示为木马程式。事实上，即使是知名的浏览器 Brave，也曾在少数防毒软体的检测中被误判为木马程式。

我们保证，本应用程式不包含任何恶意软体或恶意程式码。你也可以在这里查看详细的检测结果： https://www.virustotal.com/gui/file/3f688c34cfc30019a4bd820ea990184aa864889e017ce52d43f04bb7624517b4

如果你希望获得最高等级的安心保障，建议你直接从 Microsoft Store 下载我们的应用程式。所有 Microsoft Store 上架的应用程式都必须通过严格的签章与安全性检查，因此此版本可保证安全。我们所提供的直接下载版本与 Microsoft Store 版本为相同的应用程式，仅差别在于为可携式版本，因此同样可以安心使用。

Q2. 为什么 Microsoft Defender SmartScreen 会封锁这个应用程式？

由于每位使用者下载的应用程式都会有不同的序号，Microsoft Defender SmartScreen 会将它们视为不同的软体，因此不会被列入「常见且大量下载的已知安全档案」清单中，进而显示警告。

如果你仍然担心该应用程式可能包含恶意程式码，也可以自行提交至 Microsoft 恶意软体分析或 VirusTotal 进行检测。

同样地，若你希望完全避免此类警告，建议直接从 Microsoft Store 下载。本公司提供的直接下载版本与 Microsoft Store 版本为相同程式，安全性一致。

Q3. 什么是使用者点数？

使用者点数是用来将档案上传至快档连结云端伺服器，并让其他人可以从快档连结云端伺服器下载档案。点数的计费方式与档案大小，以及档案在伺服器上保留的时间有关。

Q4. 为什么在我终止档案分享时，有些终端机会突然闪一下？

这是正常现象，代表应用程式正在清理档案分享相关的处理程序。

Q5. 伺服器如何处理过期或上传失败的档案？

一旦档案过期，系统就会自动将其从伺服器中移除。此外，我们也会定期进行伺服器清理，以确保所有档案都被正确删除。

Q6. 什么是「Failed to connect server」？

「Failed to connect server」通常表示你的电脑与快档连结伺服器之间的网路连线无法建立。请检查你的网路状态，或联络我们寻求协助。

Q7.「Directly share」需要使用者点数吗？

不需要。「Directly share」不会消耗任何使用者点数，只需要在对方成功下载档案之前，保持应用程式持续执行即可。

Q8. 什么是「User close the connection, please try again」？

这代表下载端的使用者主动中断了连线，或是因为网路不稳定而导致连线中止。

Q9. 什么是「Could not find a copy/paste mechanism for your system.」？

这表示你的电脑尚未安装 xclip 或 xsel，因此应用程式无法自动将分享连结复制到剪贴簿中。不过这不会影响你分享档案，你仍然可以正常使用分享连结。

如果你希望使用自动复制功能，可以依照你所使用的 Linux 发行版，在终端机中安装以下工具：

Ubuntu / Debian - sudo apt update - sudo apt install xclip

Arch Linux / Manjaro - sudo pacman -S xclip

Fedora / RHEL / CentOS - sudo dnf install xclip

openSUSE - sudo zypper install xclip

若仍无法使用，可改安装 xsel： - sudo apt install xsel

安装完成后请重新执行程式。

Q10. 任何人都可以下载我上传的档案吗？

不行。只有拥有你专属分享连结的使用者，才能下载该档案。分享连结包含随机产生的安全码，可有效防止暴力破解。此外，我们也提供帐号与密码保护功能，为你的档案提供额外的安全防护。

Q11. 什么是直接分享（Directly share）？

直接分享代表你的档案会透过纯 P2P（装置对装置 P2P）或中继式 P2P 的方式传送给其他人，档案不会上传至快档连结伺服器。

更多技术细节请参考技术常见问题（Technical FAQs）

雲端上傳常見問題（FAQ）

2025-10-04T15:00:00+08:00

歡迎來到我們的常見問題（FAQ）頁面！

在這裡你可以找到關於本服務的常見問題解答。如果你正在尋找更深入或偏技術性的資訊，請參考我們的技術常見問題（Technical FAQ）。

內容

Q1. 這個應用程式安全嗎？
Q2. 為什麼 Microsoft Defender SmartScreen 會封鎖這個應用程式？
Q3. 什麼是使用者點數？
Q4. 為什麼在我終止檔案分享時，有些終端機會突然閃一下？
Q5. 伺服器如何處理過期或上傳失敗的檔案？
Q6. 什麼是「Failed to connect server」？
Q7.「Directly share」需要使用者點數嗎？
Q8. 什麼是「User close the connection, please try again」？
Q9. 什麼是「Could not find a copy/paste mechanism for your system.」？
Q10. 任何人都可以下載我上傳的檔案嗎？
Q11. 什麼是直接分享（Directly share）？

Q1. 這個應用程式安全嗎？

我們的應用程式已通過大多數防毒軟體的檢測。只有極少數防毒軟體，因為我們提供直接的 P2P 分享功能，會過度謹慎地將此應用程式標示為木馬程式。事實上，即使是知名的瀏覽器 Brave，也曾在少數防毒軟體的檢測中被誤判為木馬程式。

我們保證，本應用程式不包含任何惡意軟體或惡意程式碼。你也可以在這裡查看詳細的檢測結果： https://www.virustotal.com/gui/file/3f688c34cfc30019a4bd820ea990184aa864889e017ce52d43f04bb7624517b4

如果你希望獲得最高等級的安心保障，建議你直接從 Microsoft Store 下載我們的應用程式。所有 Microsoft Store 上架的應用程式都必須通過嚴格的簽章與安全性檢查，因此此版本可保證安全。我們所提供的直接下載版本與 Microsoft Store 版本為相同的應用程式，僅差別在於為可攜式版本，因此同樣可以安心使用。

Q2. 為什麼 Microsoft Defender SmartScreen 會封鎖這個應用程式？

由於每位使用者下載的應用程式都會有不同的序號，Microsoft Defender SmartScreen 會將它們視為不同的軟體，因此不會被列入「常見且大量下載的已知安全檔案」清單中，進而顯示警告。

如果你仍然擔心該應用程式可能包含惡意程式碼，也可以自行提交至 Microsoft 惡意軟體分析或 VirusTotal 進行檢測。

同樣地，若你希望完全避免此類警告，建議直接從 Microsoft Store 下載。本公司提供的直接下載版本與 Microsoft Store 版本為相同程式，安全性一致。

Q3. 什麼是使用者點數？

使用者點數是用來將檔案上傳至快檔連結雲端伺服器，並讓其他人可以從快檔連結雲端伺服器下載檔案。點數的計費方式與檔案大小，以及檔案在伺服器上保留的時間有關。

Q4. 為什麼在我終止檔案分享時，有些終端機會突然閃一下？

這是正常現象，代表應用程式正在清理檔案分享相關的處理程序。

Q5. 伺服器如何處理過期或上傳失敗的檔案？

一旦檔案過期，系統就會自動將其從伺服器中移除。此外，我們也會定期進行伺服器清理，以確保所有檔案都被正確刪除。

Q6. 什麼是「Failed to connect server」？

「Failed to connect server」通常表示你的電腦與快檔連結伺服器之間的網路連線無法建立。請檢查你的網路狀態，或聯絡我們尋求協助。

Q7.「Directly share」需要使用者點數嗎？

不需要。「Directly share」不會消耗任何使用者點數，只需要在對方成功下載檔案之前，保持應用程式持續執行即可。

Q8. 什麼是「User close the connection, please try again」？

這代表下載端的使用者主動中斷了連線，或是因為網路不穩定而導致連線中止。

Q9. 什麼是「Could not find a copy/paste mechanism for your system.」？

這表示你的電腦尚未安裝 xclip 或 xsel，因此應用程式無法自動將分享連結複製到剪貼簿中。不過這不會影響你分享檔案，你仍然可以正常使用分享連結。

如果你希望使用自動複製功能，可以依照你所使用的 Linux 發行版，在終端機中安裝以下工具：

Ubuntu / Debian - sudo apt update - sudo apt install xclip

Arch Linux / Manjaro - sudo pacman -S xclip

Fedora / RHEL / CentOS - sudo dnf install xclip

openSUSE - sudo zypper install xclip

若仍無法使用，可改安裝 xsel： - sudo apt install xsel

安裝完成後請重新執行程式。

Q10. 任何人都可以下載我上傳的檔案嗎？

不行。只有擁有你專屬分享連結的使用者，才能下載該檔案。分享連結包含隨機產生的安全碼，可有效防止暴力破解。此外，我們也提供帳號與密碼保護功能，為你的檔案提供額外的安全防護。

Q11. 什麼是直接分享（Directly share）？

直接分享代表你的檔案會透過純 P2P（裝置對裝置 P2P）或中繼式 P2P 的方式傳送給其他人，檔案不會上傳至快檔連結伺服器。

更多技術細節請參考技術常見問題（Technical FAQs）

Release Notes

2025-10-04T14:00:00+08:00

Welcome to our Release Notes section!

Here you can find all version updates and new feature releases. We’ll keep this page up to date — future updates and improvements will also be added here.

🛡️ 3.8 (2025/12/24)

Published and passed security review on Microsoft Store and Apple App Store
Enhanced security and privacy
Tor support with full private download mode
Multi-channel sharing support
Multi-language support (English, Traditional Chinese, Simplified Chinese)

⚙️ 3.7 (2025/10/04)

Added robust upload and download resume support
Introduced end-to-end encryption with CLI download/decrypt functionality
Added support for uploading and sharing folders, including realtime ZIP streaming download

🌐 3.6 (2025/08/11)

Added support for external tunnels (e.g., Cloudflare, ngrok, etc.)
Implemented CLI authentication support

🧙 3.5 (2025/08/02)

Released the Magical “Actual Portable Executable (APE)” CLI version
Successfully tested on Windows/Linux (x64), macOS/Android (ARM64)

🧩 3.4 (2025/07/19)

Refactored client to support modular addon architecture
Added CLI (Command Line Interface) version
Introduced macOS support

🚀 3.3 (2025/07/12)

Enabled faster uploading/downloading for files larger than 1TB, with no theoretical size limit
Enhanced server scalability

📦 3.2 (2025/06/30)

Overhauled client/server architecture for improved performance and reliability

⚡ 3.1 (2025/05/26)

Optimized P2P sharing transmission
Sped up file downloads from server
Sped up file uploads to server

🔒 3.0 (2025/05/08)

Upgraded all connections via SSL to enhance robustness in port-restricted environments and improve security

🧰 2.3 (2025/04/25)

Optimized file size

🔄 2.2 (2025/03/27)

Supported resuming downloads

📥 2.1 (2025/03/12)

Added downloading page
Added Trial version

☁️ 2.0 (2025/01/10)

Supported uploading files to the server

🐧 1.1 (2024/07/29)

Added Linux support
Auto-copy download link
Unique ID protection

🔗 1.0 (2024/05/27)

Introduced P2P sharing

发行说明（Release Notes）

2025-10-04T14:00:00+08:00

欢迎来到我们的发行说明页面！

在这里你可以查看所有版本更新与新功能释出资讯。本页将持续更新，未来的功能改进与版本更新也都会收录于此。

🛡️ 3.8（2025/12/24）

已于 Microsoft Store 与 Apple App Store 上架并通过安全性审查
强化安全性与隐私保护
支援 Tor，提供完整的私密下载模式
支援多管道分享
支援多语言（英文、繁体中文、简体中文）

⚙️ 3.7（2025/10/04）

新增稳定可靠的上传与下载续传支援
导入端对端加密（End-to-End Encryption），并提供 CLI 下载与解密功能
新增资料夹上传与分享支援，包含即时 ZIP 串流下载

🌐 3.6（2025/08/11）

新增外部通道（External Tunnel）支援（例如 Cloudflare、ngrok 等）
实作 CLI 身分验证支援

🧙 3.5（2025/08/02）

发布具魔法般体验的「真正可携式可执行档（Actual Portable Executable, APE）」CLI 版本
成功于 Windows / Linux（x64）、macOS / Android（ARM64）上完成测试

🧩 3.4（2025/07/19）

重构用户端架构，支援模组化外挂（Addon）设计
新增 CLI（Command Line Interface，命令列介面）版本
新增 macOS 支援

🚀 3.3（2025/07/12）

启用超大型档案（大于 1TB）的高速上传与下载，理论上无档案大小限制
强化伺服器的可扩展性

📦 3.2（2025/06/30）

全面重构用户端与伺服器架构，以提升效能与稳定性

⚡ 3.1（2025/05/26）

最佳化 P2P 分享传输效能
加快从伺服器下载档案的速度
加快上传档案至伺服器的速度

🔒 3.0（2025/05/08）

全面升级所有连线为 SSL，以提升在受限连接埠环境中的稳定性与整体安全性

🧰 2.3（2025/04/25）

最佳化档案大小

🔄 2.2（2025/03/27）

支援下载续传功能

📥 2.1（2025/03/12）

新增下载页面
新增试用版本（Trial）

☁️ 2.0（2025/01/10）

支援将档案上传至伺服器

🐧 1.1（2024/07/29）

新增 Linux 支援
自动复制下载连结
独立唯一 ID 保护机制

🔗 1.0（2024/05/27）

推出 P2P 档案分享功能

發行說明（Release Notes）

2025-10-04T14:00:00+08:00

歡迎來到我們的發行說明頁面！

在這裡你可以查看所有版本更新與新功能釋出資訊。本頁將持續更新，未來的功能改進與版本更新也都會收錄於此。

🛡️ 3.8（2025/12/24）

已於 Microsoft Store 與 Apple App Store 上架並通過安全性審查
強化安全性與隱私保護
支援 Tor，提供完整的私密下載模式
支援多管道分享
支援多語言（英文、繁體中文、簡體中文）

⚙️ 3.7（2025/10/04）

新增穩定可靠的上傳與下載續傳支援
導入端對端加密（End-to-End Encryption），並提供 CLI 下載與解密功能
新增資料夾上傳與分享支援，包含即時 ZIP 串流下載

🌐 3.6（2025/08/11）

新增外部通道（External Tunnel）支援（例如 Cloudflare、ngrok 等）
實作 CLI 身分驗證支援

🧙 3.5（2025/08/02）

發佈具魔法般體驗的「真正可攜式可執行檔（Actual Portable Executable, APE）」CLI 版本
成功於 Windows / Linux（x64）、macOS / Android（ARM64）上完成測試

🧩 3.4（2025/07/19）

重構用戶端架構，支援模組化外掛（Addon）設計
新增 CLI（Command Line Interface，命令列介面）版本
新增 macOS 支援

🚀 3.3（2025/07/12）

啟用超大型檔案（大於 1TB）的高速上傳與下載，理論上無檔案大小限制
強化伺服器的可擴展性

📦 3.2（2025/06/30）

全面重構用戶端與伺服器架構，以提升效能與穩定性

⚡ 3.1（2025/05/26）

最佳化 P2P 分享傳輸效能
加快從伺服器下載檔案的速度
加快上傳檔案至伺服器的速度

🔒 3.0（2025/05/08）

全面升級所有連線為 SSL，以提升在受限連接埠環境中的穩定性與整體安全性

🧰 2.3（2025/04/25）

最佳化檔案大小

🔄 2.2（2025/03/27）

支援下載續傳功能

📥 2.1（2025/03/12）

新增下載頁面
新增試用版本（Trial）

☁️ 2.0（2025/01/10）

支援將檔案上傳至伺服器

🐧 1.1（2024/07/29）

新增 Linux 支援
自動複製下載連結
獨立唯一 ID 保護機制

🔗 1.0（2024/05/27）

推出 P2P 檔案分享功能

How FastFileLink Was Born

2025-02-23T11:22:00+08:00

The Problem We Faced

FastFileLink was born out of a real problem we faced in our company.

At the end of each internship period, we often encountered an issue: interns leaving the company without uploading or committing their latest work-related files. These files could include scripts, documents, configurations, or other essential contributions that were not yet backed up or pushed to our internal systems.

To prevent data loss, we initially asked all interns to burn their files to a DVD and mail it back to us. But as you can imagine, that quickly became outdated and inconvenient. No one uses DVD-ROM drives anymore, and the entire process—burning the disc, packaging it, and shipping it—was time-consuming and error-prone.

Why Cloud Storage Didn't Work

A natural alternative would have been to use cloud storage like Google Drive or Dropbox. But that introduced another problem: storage limitations.

Neither the interns nor our company accounts had enough cloud storage space to easily hold all the necessary files. These weren’t just a few documents—we’re talking about project folders, videos, datasets, and other materials that could easily add up to tens of gigabytes per person. Upgrading the plans would mean additional cost, and we didn’t want to incur recurring expenses just to retrieve a one-time upload from each intern.

Furthermore, even if we had the space, uploading directly to our internal systems from outside the company network wasn’t straightforward. Our servers were behind a secure intranet, and accessing them remotely would require configuring NAT, VPNs, or port forwarding—something we didn’t want our interns to have to deal with after they had already left.

The Birth of FastFileLink

So we built FastFileLink—a simple, secure, and cloud-free way to send files from one person to another.

With FastFileLink, the intern could easily send files directly to us, without worrying about internal network access, cloud storage quotas, or physical mailing. It just worked—files would go from their machine to ours, fast and effortlessly.

And we thought: if this tool could help us, maybe it could help others too.

That’s how FastFileLink was born.

From Real-Time to Upload Now and Download Later

Initially, FastFileLink required both sender and receiver to be online at the same time. While that worked, it wasn’t always convenient—especially when trying to coordinate across time zones or busy schedules.

So we made it better.

We upgraded FastFileLink to support upload now and download later: the sender uploads files to our server, and the receiver can download them anytime later. This greatly improved flexibility for both sides.

Now interns could upload files whenever it was convenient for them, and we could download them whenever we were available. No more waiting, no more syncing schedules.

A Simple Tool That Just Works

FastFileLink has drastically improved our workflow and made file handovers smoother than ever. It’s a lightweight tool, but it solves a very real and painful problem for us—and potentially for many others.

That’s the story behind FastFileLink. A tool we built for ourselves, and now proudly share with the world—just like we did with MailTrigger.

快档连结的诞生故事

2025-02-23T11:22:00+08:00

我们遇到的问题

快档连结的诞生，源自于我们公司实际遇到的一个真实问题。

在每一期实习结束时，我们经常遇到同样的状况：实习生离职时，尚未上传或提交他们最新的工作相关档案。这些档案可能包含程式码脚本、文件、设定档，或其他尚未备份、也尚未推送到公司内部系统的重要成果。

为了避免资料遗失，我们一开始要求所有实习生将档案烧录成 DVD，并邮寄回公司。但你可以想象，这个做法很快就显得过时又不方便。现在几乎没有人还在使用 DVD-ROM 光碟机，而整个流程——烧录、包装、寄送——既耗时又容易出错。

为什么云端储存行不通

一个很自然的替代方案，是使用像 Google Drive 或 Dropbox 这样的云端储存服务。但这又带来了另一个问题：储存空间限制。

不论是实习生个人帐号，还是公司帐号，都没有足够的云端空间来轻松存放所有必要的档案。这些并不只是几份文件，而是包含专案资料夹、影片、资料集等内容，单一实习生的档案量就可能轻易累积到数十 GB。若要升级方案，就意味着额外的成本，而我们并不希望只为了回收一次性的档案，就承担长期的订阅费用。

此外，就算云端空间足够，从公司外部直接将档案上传到内部系统也并不容易。我们的伺服器位于受保护的内部网路之中，远端存取通常需要设定 NAT、VPN 或 Port Forwarding——这些都不是我们希望实习生在离职后还得处理的事情。

快档连结的诞生

于是，我们打造了 快档连结 ——一个简单、安全、且不依赖云端的档案传送方式。

透过快档连结，实习生可以直接将档案传送给我们，完全不需要烦恼公司内部网路存取、云端空间额度，或实体邮寄的问题。一切就是这么直觉——档案可以快速、顺畅地从他们的电脑传送到我们这边。

而我们也开始思考：如果这个工具能解决我们的问题，或许也能帮助到其他人。

这正是快档连结诞生的起点。

从即时传送，到先上传、之后下载

在最初的版本中，快档连结需要传送端与接收端同时在线。虽然这样可以运作，但在实际使用上并不总是方便——尤其是在跨时区，或彼此行程繁忙的情况下。

因此，我们进一步优化了它。

我们为快档连结新增了 「先上传，之后再下载」 的功能：传送端可以先将档案上传到我们的云端伺服器，而接收端则可以在任何方便的时间再下载。这大幅提升了双方使用上的弹性。

现在，实习生可以在自己方便的时间上传档案，而我们也能在有空时再下载。不再需要等待，也不必再为了同步时间而烦恼。

一个真正「好用就好」的工具

快档连结彻底改善了我们的工作流程，让档案交接变得前所未有地顺畅。它是一个轻量的小工具，却解决了一个对我们而言非常真实、也非常痛苦的问题——而这个问题，其实也存在于许多人的日常工作中。

这就是快档连结背后的故事。一个我们为自己打造的工具，如今也像 MailTrigger 一样，正式与全世界分享。

快檔連結的誕生故事

2025-02-23T11:22:00+08:00

我們遇到的問題

快檔連結的誕生，源自於我們公司實際遇到的一個真實問題。

在每一期實習結束時，我們經常遇到同樣的狀況：實習生離職時，尚未上傳或提交他們最新的工作相關檔案。這些檔案可能包含程式碼腳本、文件、設定檔，或其他尚未備份、也尚未推送到公司內部系統的重要成果。

為了避免資料遺失，我們一開始要求所有實習生將檔案燒錄成 DVD，並郵寄回公司。但你可以想像，這個做法很快就顯得過時又不方便。現在幾乎沒有人還在使用 DVD-ROM 光碟機，而整個流程——燒錄、包裝、寄送——既耗時又容易出錯。

為什麼雲端儲存行不通

一個很自然的替代方案，是使用像 Google Drive 或 Dropbox 這樣的雲端儲存服務。但這又帶來了另一個問題：儲存空間限制。

不論是實習生個人帳號，還是公司帳號，都沒有足夠的雲端空間來輕鬆存放所有必要的檔案。這些並不只是幾份文件，而是包含專案資料夾、影片、資料集等內容，單一實習生的檔案量就可能輕易累積到數十 GB。若要升級方案，就意味著額外的成本，而我們並不希望只為了回收一次性的檔案，就承擔長期的訂閱費用。

此外，就算雲端空間足夠，從公司外部直接將檔案上傳到內部系統也並不容易。我們的伺服器位於受保護的內部網路之中，遠端存取通常需要設定 NAT、VPN 或 Port Forwarding——這些都不是我們希望實習生在離職後還得處理的事情。

快檔連結的誕生

於是，我們打造了 快檔連結 ——一個簡單、安全、且不依賴雲端的檔案傳送方式。

透過快檔連結，實習生可以直接將檔案傳送給我們，完全不需要煩惱公司內部網路存取、雲端空間額度，或實體郵寄的問題。一切就是這麼直覺——檔案可以快速、順暢地從他們的電腦傳送到我們這邊。

而我們也開始思考：如果這個工具能解決我們的問題，或許也能幫助到其他人。

這正是快檔連結誕生的起點。

從即時傳送，到先上傳、之後下載

在最初的版本中，快檔連結需要傳送端與接收端同時在線。雖然這樣可以運作，但在實際使用上並不總是方便——尤其是在跨時區，或彼此行程繁忙的情況下。

因此，我們進一步優化了它。

我們為快檔連結新增了 「先上傳，之後再下載」 的功能：傳送端可以先將檔案上傳到我們的雲端伺服器，而接收端則可以在任何方便的時間再下載。這大幅提升了雙方使用上的彈性。

現在，實習生可以在自己方便的時間上傳檔案，而我們也能在有空時再下載。不再需要等待，也不必再為了同步時間而煩惱。

一個真正「好用就好」的工具

快檔連結徹底改善了我們的工作流程，讓檔案交接變得前所未有地順暢。它是一個輕量的小工具，卻解決了一個對我們而言非常真實、也非常痛苦的問題——而這個問題，其實也存在於許多人的日常工作中。

這就是快檔連結背後的故事。一個我們為自己打造的工具，如今也像 MailTrigger 一樣，正式與全世界分享。

FastFileLink Blog

Using FastFileLink to Deliver a 3.8GB, 158-File U.S. Department of War UFO Public Archive

我用快档连结交付一个 3.8GB、158 个档案的美国战争部 UFO 公开资料包

我用快檔連結交付一個 3.8GB、158 個檔案的美國戰爭部 UFO 公開資料包

How ffl Differs from CLI File Transfer Tools Like croc and Magic Wormhole

The main difference: ffl gives the receiver an HTTPS link

Quick comparison

Why WebRTC matters for speed and routing

Where tools like croc shine

Where ffl fits better

How it differs from cloud-upload tools

APE: why portable single-file distribution matters

Practical DevOps scenarios where ffl feels different

1. Pull a result out of a container

2. Stream a MySQL backup directly to someone or another machine

3. Share a large CI artifact with a reviewer

4. Move files from locked-down machines

5. Send technical files to non-engineers

Which one should you choose?

Summary

ffl 和 croc、Magic Wormhole 这类 CLI 传档工具差在哪？

ffl 的核心差异：接收端拿到的是 HTTPS 连结

快速比较

WebRTC 对速度和路径有什么影响？

croc 这类工具强在哪？

ffl 更适合哪种情境？

跟云端上传型工具差在哪？

APE：为什么单档可携很重要？

几个很有感的 DevOps 场景

1. 从 container 里把结果拉出来

2. 把 MySQL 备份直接交给同事或另一台机器

3. CI job 产生大型 artifact，临时分享给 reviewer

4. 线上机器不能装太多东西，但需要临时传档

5. 把档案交给「不是工程师」的人

什么时候选哪个？

小结

ffl 和 croc、Magic Wormhole 這類 CLI 傳檔工具差在哪？

ffl 的核心差異：接收端拿到的是 HTTPS 連結

快速比較

WebRTC 對速度和路徑有什麼影響？

croc 這類工具強在哪？

ffl 更適合哪種情境？

跟雲端上傳型工具差在哪？

APE：為什麼單檔可攜很重要？

幾個很有感的 DevOps 場景

1. 從 container 裡把結果拉出來

2. 把 MySQL 備份直接交給同事或另一台機器

3. CI job 產生大型 artifact，臨時分享給 reviewer

4. 線上機器不能裝太多東西，但需要臨時傳檔

5. 把檔案交給「不是工程師」的人

什麼時候選哪個？

小結

Server Migration Without Extra Disk Space: Streaming Borg Backups with FastFileLink CLI

Our Deployment Model

Why App Working Folders Matter

What the Old Migration Flow Looked Like

The Pain Point: the Source Server Is Already Short on Space

Could rsync Solve This?

Why FastFileLink CLI Fits So Well

What --stdin-cache, --stdout, and --pickup-code Are Doing

How This Fits Back into Deploy.py

What FastFileLink CLI Brings to This Case

Comparing FastFileLink CLI with scp, rsync, croc, and Magic Wormhole

The Real Lessons from Implementation

Orchestration Matters More Than the Pipe

You Can Test the Migration Before DNS Moves

This Pattern Is Useful Beyond One App

Final Takeaway

不需要额外磁盘空间的服务器迁移：用 FastFileLink 串流 Borg 备份

我们的部署模型

每个 App 自带 Working Folder 的好处

旧版 Migration 流程长什么样子

痛点就在来源机器快没空间

rsync 能不能解这个问题

为什么 FastFileLink CLI 很适合

--stdin-cache、--stdout 和 --pickup-code 在做什么

怎么整合回既有的 Deploy.py

FastFileLink CLI 在这个案例中的几个优势

和 scp、rsync、croc、Magic Wormhole 的比较

实作过程里，真正踩到哪些坑

What `--stdin-cache`, `--stdout`, and `--pickup-code` Are Doing

`--stdin-cache`、`--stdout` 和 `--pickup-code` 在做什么

`--stdin-cache`、`--stdout` 和 `--pickup-code` 在做什麼