FileSync：把檔案從瀏覽器直傳到多台裝置，過程不碰雲端

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

把檔案送到別台裝置，多數人的直覺是開一個雲端空間連結，先上傳、對方再下載。FileSync 走另一條路：瀏覽器打開網址就有一個房間，把連結傳給其他裝置，檔案從你的瀏覽器直接串流到對方的瀏覽器，中間沒有儲存空間，沒有到期日，也沒有檔案大小上限。它是 MIT 授權的開源專案，官方站 filesync.app 可以直接用，整套也能用 Docker 自己架。

我在 2026 年 8 月 25 日對它做了一輪完整傳輸實測：在官方站開房間，再用另一個瀏覽器加入，丟進一個 4KB 文字檔和一個 3MB 二進位檔，接收端按下載後收到一個 3,150,209 位元組的壓縮包，解開後兩個檔案的 SHA-256 雜湊值與我本機的原檔完全相同。傳輸這件事是真的，而且整條路徑上確實沒有第三方服務經手檔案內容。

不過要先澄清一個很容易踩的坑：網路上流傳的介紹大多寫它「基於 PeerJS」。這個說法已經過時。v4.0.0 在 2026 年 6 月 11 日發布時把 PeerJS 整個拆掉了，現在是原生 WebRTC 加上內建的信令伺服器。差別不只是名詞：你照舊資料去部署或除錯，會把力氣花在已經不存在的元件上。

實測一遍：開房、加入、丟檔，對方按下載才開始傳

實際流程比想像中短。打開 filesync.app，網址列會自動變成類似 /kxl-zzql-naj 的房間網址，這串號碼是瀏覽器端用密碼學亂數產生的，格式固定為三段共十碼。畫面上就是房間連結和 QR Code，另外有一個可以選擇開啟的房間密碼。

Pin

第二個瀏覽器打開同一個網址就等於進房，房主畫面的使用者清單會出現對方。房主丟出檔案之後，接收端的清單幾乎立刻列出檔名和大小。這裡有個設計值得停下來看：清單上出現的是檔案的中繼資料，檔案本體這時候還沒有動。接收端要自己按下載，瀏覽器才會透過資料通道回送一個請求，傳送端收到請求後才開始串流。我在接收端按了全部下載，它在接收端即時打包成一個 zip 讓瀏覽器存檔，兩個檔案的雜湊比對都一致。

Pin

「接收端主動拉取」加上「沒有暫存空間」，合起來就是這個工具的性格：傳送端關掉分頁，一切就結束：雲端不會留副本，錯過了也沒得補領。它應付的場景是兩邊都在場的即時傳檔；要非同步交付，得找別的工具。

這輪實測有個邊界要先講：我的兩個瀏覽器在同一台機器上，連線走的是本機路徑，跨網路的 NAT 穿透與中繼情境我沒有實測；下文遇到作者宣稱的數字，我會直接標出來。

「不經雲端」是三段工程疊出來的

把第三方服務拿掉之後，原本由它們承接的工作要有人做。FileSync v4.0.0 的做法是把三段全部收回自己手裡。

最上游是信令。兩個瀏覽器要建立 WebRTC 連線，得先互相交換連線資訊，這段交握的行話叫信令。FileSync 的後端在 /ws 提供了一個 WebSocket 信令伺服器，只轉發這類交握訊息，訊息內容對伺服器來說幾乎都是不透明的 JSON。程式碼裡能看到一整套防護：單一連線每秒最多一百則訊息、十秒內對同一目標最多五十則、單則訊息上限 32KB、整台伺服器預設最多一萬個連線。唯一會被打開來動手腳的訊息是 TURN 中繼候選位址，後面會講到原因。

接著是打洞與中繼。瀏覽器之間要直連，得先知道彼此在網路上的位置，多數情況靠 STUN 就能找到路；少數環境（對稱 NAT、封鎖 UDP 的公司網路）找不到路，就要靠 TURN 伺服器代轉。官方的部署設定直接綁了一個 coturn 容器，瀏覽器向應用程式的憑證端點領五分鐘有效的 HMAC 憑證，UDP 和 TCP 都聽 3478 埠，中繼流量走 50000 到 50100 的 UDP 埠範圍。README 對直連成功率的說法是約有百分之五到十的連線需要中繼，這個比例是作者宣稱，我沒有跨網路環境可以驗證，但需要中繼的流量也只是加密過的位元組流經你自己的伺服器，內容仍讀不到。

接收端怎麼把資料寫進磁碟，是另一段工程。收到的大量資料怎麼存，決定了大檔案會不會把瀏覽器記憶體撐爆。它準備了三層：支援的瀏覽器優先走 File System Access API，直接串流寫進指定的檔案；不支援時退到 Service Worker 串流成一般下載；兩者都沒有，才會整包塞進記憶體的 Blob 模式。前兩層需要 HTTPS 環境，純 HTTP 部署只剩第三層，實務上約 500MB 以上就不可靠。傳送端同樣是逐段讀檔，每個分塊 16KB，記憶體佔用停留在單一分塊的水準。

原始碼裡還有一個多數自架 WebRTC 服務都會踩的坑被處理掉了：coturn 跑在 Docker 橋接網路裡，會把只有容器內部可達的位址回報給瀏覽器，導致需要中繼的連線默默失敗。FileSync 在信令層把這類中繼候選位址改寫成接收端實際連到伺服器的那個位址，同一台伺服器同時服務區網內和外網的訪客時，各自拿到各自可路由的版本。這個細節不影響使用體驗，但看得出專案的工程深度。

加密與房間密碼各自守在哪一層

「端到端加密」這四個字在這裡說的是 WebRTC 內建的 DTLS 傳輸加密：瀏覽器之間自動協商，檔案在通道裡是密文。專案沒有再疊一層自己的應用層加密。要下形容的話，「傳輸層加密」比「端到端加密」老實。

房間密碼是另一回事，它守的是門，不是內容。設定密碼後，加入者的瀏覽器會把密碼的 SHA-256 雜湊值透過資料通道送給房主的瀏覽器比對，明文密碼和雜湊值都不經過伺服器，比對由房主端的程式碼完成。沒有密碼的人會在資料通道這一層被拒於門外。要注意，密碼解不開任何東西，它只負責把人擋在門外；內容的機密性從頭到尾由 DTLS 承擔。

伺服器到底看得到什麼，這點要講清楚。信令伺服器看得到：誰用哪個識別碼連上來、連線交握的內容、TCP 層的來源位址。它看不到：檔名、檔案大小、檔案內容，因為這些都走瀏覽器之間的資料通道。官方站首頁只載入三個自家 JavaScript 檔案，裡面找不到任何分析或廣告追蹤腳本，隱私主張至少在程式碼層面是自洽的。

原始碼註解裡作者自己也寫明了一個取捨：知道別人識別碼的人，可以搶先登記同一個識別碼把對方的信令連線踢掉。已建立的資料通道不受影響（DTLS 持續保護），但同房間裡確實存在被搗亂的可能。房間網址本身就是識別碼，所以這個風險等同於「拿到連結的人可以鬧場」，自架給固定對象使用時心裡有數即可。

自己架之前要算的帳

自架是兩個容器：應用程式本體加上 coturn。啟動前必須設定一把 SECRET_KEY，它同時用來簽 TURN 憑證和連線權杖；程式會檢查這個值，如果沿用範本裡的佔位字串會直接拒絕啟動，因為那是公開已知的值，等於任何人都能自己簽憑證。

埠要開三組：80 或 443 給網頁介面、3478 的 TCP 加 UDP 給連線建立與中繼入口、50000 到 50100 的 UDP 給中繼流量。雲端主機的防火牆和家用路由器都要對應，少開任何一組，功能就少一截。

有一筆帳我實際驗過：憑證端點 /api/credentials 不做任何身分驗證。我直接向官方站的這個端點發請求，不帶任何登入狀態，回應本體就是一個裝著 TURN 帳號密碼的 JWT。設計上有反向代理層的速率上限（每秒二十次、允許短爆量），防的是洪水式請求，不是授權。這對官方站無所謂，對公開自架的人意義就不同了：任何訪客都能每五分鐘領一次有效憑證，把你的 coturn 當免費中繼用，頻寬帳單由你吸收。它不是漏洞，是自架前應該知道的成本結構。

另外兩個現實限制：信令是單一工作程序的記憶體內設計，沒有水平擴展，自架單機夠用，別期待拿它撐大型服務；coturn 設定裡的 realm 寫死了 filesync.app，自架不改也能跑，只是憑證裡會看到這個字串。想走 HTTPS，官方提供附 Caddy 的部署範本，自動申請與續期 Let’s Encrypt 憑證，順便解鎖前兩層串流寫入模式，這對大檔傳輸是必要的投資。

已經在跑 3.x 舊版的人要注意升級方式：v4.0.0 改了整套部署拓撲，只把映像檔拉到最新版不夠，compose 設定檔要重新下載取代，舊版 compose 綁的那個 PeerJS 信令伺服器容器，在新版裡已由內建信令取代，設定檔沒換會對不起來。官方站也內建了一個診斷頁（網址列加上 /test.html），會列出瀏覽器支援的寫入模式與 WebRTC 相容狀態，升級後先跑一輪診斷可以少踩很多環境問題。

什麼時候用它，什麼時候回頭找雲端

跟 COW Transfer 這類「先上傳、產生連結、對方之後自己領」的服務比起來，FileSync 的差異是結構性的：它不存檔，所以連結不會過期、下載次數不設限，檔案大小只受瀏覽器能力約束；代價是兩端必須同時開著瀏覽器。要臨時把一個數 GB 的影片從桌機送到客廳的電腦、在會議現場把資料包發給十個人、或單純不想讓檔案落到第三方伺服器，它都勝任。要交付給半夜才上線的同事、需要留存傳檔紀錄、跨時區協作，雲端傳檔仍然是對的工具，兩者各司其職。

自架的意義則在完全自控。跟自架 Bichon 郵件歸檔 或 QM 音樂伺服器 的動機類似：資料路徑上每一台機器都是自己的。WebRTC 自架的例子可以再參考 Call-Me 視訊通話，同樣是把連線建立與轉送握在自己手裡的思路。

限制攤開與我的判斷

把會影響使用決策的限制集中列在這裡。兩端必須同時在場，傳送端一離開就一切歸零；接收端也要主動按下載，檔案不會自動落地。HTTP 部署撐不起大檔，HTTPS 是基本前提。行動裝置瀏覽器的記憶體上限仍在：專案 issue 有一整串行動端大檔卡住的討論，作者最終用 v4.0.0 的三層寫入機制回應，桌面環境已經穩定，手機端受限於瀏覽器本身的記憶體限制，這是幾乎所有 WebRTC 傳檔工具共同的物理限制。跨網路直連成功率我未實測，中繼比例採信的是作者宣稱。公開自架要承擔 TURN 憑證開放領取的頻寬風險。

專案本身是西班牙開發者 Pol Alzina 的個人專案，2023 年 7 月開始，截至 2026 年 8 月有一千四百九十顆星、一百四十個 fork，Docker 映像累積兩萬兩千餘次拉取，v4.0.0 發布後仍有依賴更新提交進來。單人維運是事實，但從信令限流、ICE 位址改寫、三層串流寫入到反向代理的安全標頭，這份原始碼的工程品質高出這類工具的平均水準，MIT 授權也讓商用與修改沒有疑慮。

我的判斷：把它定位成「現場把檔案發出去」的工具，它目前是同類中最乾淨的選擇之一；把它當雲端傳檔的替代品，期待對方晚點自己來領，它做不到。臨時需求用官方站就夠；常態使用又在意的話，用 Docker 架一套 HTTPS 版，把 TURN 的頻寬成本算進去，整條傳輸路徑就都是自己的了。