EasyTransfer 開源傳檔實測：輸 4 碼把檔案加密直傳另一台裝置

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

先說結論：EasyTransfer 把「兩台裝置互傳檔案」這件事壓到最短步驟，打開網頁、輸入對方的四字配對碼、把檔案拖進去，就這樣。我在兩個乾淨的瀏覽器環境實際配對互傳，一則文字訊息和一個檔案都完整送達，過程中兩側合計發出的四十個網路請求裡，沒有任何一個把檔案內容送往伺服器。不過它掛在招牌上的「匿名」兩個字要分層看：工具本身確實不統計、不留帳號，但網頁第一秒就載入了主機商的統計腳本，而整個配對的信任基礎，押在一支只有一百一十二行的信號伺服器程式上。日常互傳它好用；內容機敏時，你該先看懂這篇後面拆給你看的邊界。

輸四字碼就連上：兩台裝置互傳文字與檔案的實測

實際測試是這樣做的：開兩個互不相干的無痕瀏覽器環境，各自打開 EasyTransfer 網站。兩邊幾秒內各自拿到一組四字配對碼，我這邊是 4 開頭的四字碼，另一邊是 D 開頭。把對方的碼填進輸入框、按下連線鈕，幾秒內連線狀態就轉為成功。接著從這邊送出一則測試訊息和一個純文字檔案，另一邊的下載區原封不動收到兩者，檔名、內容都與送出時一致。

Pin

畫面本身極簡：左上是你自己的配對碼（點一下就複製），旁邊是輸入對方代碼的欄位，底下有一個燈號顯示 TURN 伺服器是否可用；頁面分成上傳與下載兩區，可以送檔案、照片或一則短訊息。所有互動都在同一頁完成，沒有任何彈出視窗要你登入或留信箱。

Pin

有個台灣使用者會立刻碰到的細節：它有繁體中文介面，但預設語言是英文，而且不會自動偵測你瀏覽器的語言設定，要自己打開設定選單把語言切成繁體中文，選擇會存在瀏覽器本機，下次打開就是中文。設定選單裡還有最大連線數（預設 10）、ICE 伺服器位址、自動顯示圖片、自動下載、聲音通知與深色模式等選項。

傳輸的工程細節從原始碼看也有誠意：檔案被切成略小於 64KB 的區塊逐一送出，程式會開最多十條平行的資料通道分攤流量，每個通道有 16MB 的緩衝上限，失敗會自動重試（最多三次、每次十秒逾時）。這些數字平常不需要記，但它們說明這個看起來像玩具的頁面，骨子裡是按正規工程在做。

最反常的發現：檔案真的不經伺服器，「匿名」卻從第一秒就打折

這次實測最值得單獨拿出來講的，是一組並置的事實。

一邊是：配對、傳訊息、傳檔案的全部過程，兩側瀏覽器各只發出二十個請求，我逐條看過，內容都是載入頁面本體、字型、統計腳本與連線握手訊號，沒有任何一個請求帶著檔案內容離開瀏覽器。把它的客戶端原始碼整包抓下來搜「analytics」「gtag」「umami」「sentry」這類統計關鍵字，結果是零。就「檔案內容不外流」與「工具不統計使用者」兩件事而言，它是乾淨的。

另一邊是：這個標榜匿名的網站，頁面一打開就從主機商 Cloudflare 載入網頁分析腳本，並往 /cdn-cgi/rum 端點送了一筆連線監測資料，字型也是跟 Google 字型服務要的。這些不是工具作者寫的程式，而是網站託管層自帶的標準配備，但對「站方知不知道你來過」這個問題，答案仍然是知道：主機層看得到你的 IP、連線時間與請求紀錄。

所以「匿名」的精確範圍是：沒有帳號、沒有個資欄位、工具程式不做行為統計、檔案內容不落地；但網站主機與內容傳遞網路本來就會看到的連線資訊，它沒有也無法替你藏住。這不是它獨有的問題，而是所有網頁工具共同的宿命，差別只在它把「匿名」寫得很大，而你該知道那兩個字的效力範圍到哪裡。

它怎麼做到的：瀏覽器之間的資料通道，加一支一百一十二行的信號伺服器

檔案為什麼可以不經過伺服器？因為它用的是 WebRTC，這是瀏覽器內建的點對點通信能力。兩個瀏覽器先透過一個信號伺服器交換「握手訊息」，互相知道對方的網路位置之後，就建立一條瀏覽器對瀏覽器的加密資料通道，檔案位元組從這條通道直送，從頭到尾不進任何人的硬碟。

那個信號伺服器是整個架構裡最有意思的東西：我把它的原始碼完整讀過，全部一百一十二行，做的事情只有四件：登記裝置、轉發連線邀約、轉發應答、轉發網路位置候選。它不看檔案、不存資料庫、沒有使用者資料表，連嘗試次數的限制都沒有寫。換句話說，伺服器知道的是「誰跟誰在什麼時候握手」，看不到「傳了什麼」。

這裡有個值得指出的落差：官方網頁的關鍵字裡寫著「web crypto api」，讓人以為它自己在瀏覽器裡多做了一層加密；實際上整個客戶端原始碼裡找不到任何自行實作的加密，端對端加密完全由 WebRTC 資料通道內建的 DTLS 協定買單。這不是壞事，瀏覽器內建的加密經過的審視比個人作品多得多，但「自己有加解密」與「用瀏覽器內建的」是兩種宣稱，後者才是事實。

還有一個被寫在說明文件註腳裡的誠實但書：當兩個裝置之間的網路無法直接打通（例如都在嚴格的防火牆後面），流量會經過 TURN 中繼伺服器轉一手。這個中繼伺服器是作者自己架的免費服務，而且它的位址與共用帳號密碼就明寫在正式網站的程式碼裡，任何人都能取用。經過中繼的流量仍然是加密的密文，中繼伺服器看不到內容，但「誰、何時、傳了多少量」對中繼營運者是可見的。對多數家用網路環境，直接打通是常態，中繼是備援；但若你的網路環境特殊，這條路徑就會生效。

四字碼是門牌，不是鎖：配對的信任模型

多數人看到「輸入四字碼才能連線」，會直覺把它理解成一種密碼。從原始碼看，它其實是門牌號碼：作用是讓信號伺服器知道要把連線邀約轉給哪個裝置，而不是驗證對方的身分。

幾個程式碼層的事實支撐這個判斷。配對碼由伺服器隨機產生，字元集刻意排除容易看錯的 0、1、O、I、L，從剩下三十一個字元裡取四個，組合數約九十二萬；產生用的是程式語言的一般隨數函式，不是密碼學等級的亂數源；信號伺服器沒有對「嘗試連線次數」做任何限制。同時，收到連線邀約的那一端會自動應答，畫面上不會先跳出「有人要連你，確認嗎」的步驟，也不提供讓你人工核對加密指紋的介面。

把這些加起來：一個知道你配對碼的人，在你掛在網站上的期間，有機會與你建立連線。九十二萬分之一的猜中機率讓隨機掃碼的成本不低，但這條路在結構上是通的，同類的瀏覽器互傳工具也普遍存在這個攻擊面，不是它特別差。實際的使用體感也有防護的一面：連上之後，對方送什麼你的下載區就出現什麼，你會立刻看到不是自己預期的內容，而且連線建立前你那一端的任何檔案都不會外流。

所以正確的使用姿勢是：把配對碼當成「這一班車的座位號」而不是保險箱密碼。傳給坐在旁邊的人、用完就關頁面，配對碼隨連線結束失效，風險視窗很短。若要傳的內容連「被陌生人猜中座位號」都不能接受，那就該走下一節的自架路線，或改用有身分驗證的管道。

配對碼的生命週期也值得順便弄清楚，它決定你的暴露時間。打開頁面的那一刻，瀏覽器就向信號伺服器登記並取得一組新碼；這組碼只在你掛在頁面上期間有效，關掉分頁、久置斷線或伺服器重連，都會換一組新的。換碼意味著前一組碼立即作廢，先前拿到碼但沒連上的人，無法拿舊碼再找到你。實際使用時這是個可以主動利用的設計：一次傳輸完就重新整理頁面，等於把門牌換掉，把理論上的掃碼機會壓到只剩下傳輸進行中的那幾分鐘。反過來說，若你把頁面開著掛一整個下午，暴露時間就是一整個下午，這是使用習慣可以控制的部分。

三個組件都能自己架：把信任握在自己手上的代價

EasyTransfer 的三個組件，網頁前端、信號伺服器、TURN 中繼，全部開放自架，官方 wiki 提供以 Docker 為主的自架文件，信號伺服器與 TURN 中繼各有一頁說明（目錄上另列了一個用免費雲服務做法的頁面，連結已失效，點了只會跳回首頁）。自架之後，握手訊息與中繼流量都走你自己的機器，「信號伺服器是否老實」這個假設就變成你自己管理的事實。對組織內部或高機敏用途，這是它比閉源同類工具更有價值的地方。

自架有兩個成本。一是技術：訊號伺服器與 TURN 各要一個對外可連的位址，TURN 的頻寬就是你的頻寬。二是結構不變：四字碼的定址本質、自動應答的行為、沒有指紋核對介面，這些自架之後依然照舊，自架解決的是「信任對手是誰」，不是「配對機制本身的強度」。

它的授權採 GPL-3.0，屬於強著作左型條款：把它的程式碼改一改放進自己的產品對外提供，你的產品也需要以同授權開放原始碼。單純自架自己用沒有這個義務，拿來二次開發前要先想清楚。

與瀏覽器互傳同類工具的一條關鍵差異

這類「開網頁就互傳」的工具，TechMoon 介紹過幾個，連線模型其實分兩派。PairDrop 是房間制：兩邊打開同一個網址就互相看得到，辨識對方靠裝置名稱；EasyTransfer 是配對碼制：誰拿得到你的碼，誰才連得上你，但連上之後你看不到對方是誰，只看得到送來的東西。前者勝在零操作，後者勝在「可連我的人」範圍收斂。哪種比較安全取決於場景：在自家客廳傳照片，房間制方便；在辦公室或公共場合，配對碼制比較不容易被同網段的旁人搭上線。

其他路線各有位置：FilePizza 同樣走點對點、檔案不落地，換檔靠一條取件連結；transfer.zip 用掃 QR Code 的方式配對，適合手機對電腦；要把檔案加密拆散、以圖片形式搬運大檔的特殊需求，可以看 MixFile 的做法。EasyTransfer 在這個光譜上的位置是「最短步驟的兩裝置直連」：不建房間、不產生取件連結、不需要掃碼，代價是兩邊都要同時開著頁面。

使用前該知道的限制，集中在這裡

信號伺服器一旦斷線，頁面會整個重新載入並換一組新配對碼，這是寫在程式裡的行為；傳輸進行中斷線會發生什麼，我沒有實測，列為未知。大檔表現與長時間穩定性同樣未測，本次實測的檔案是小型文字檔，只能證明通道可用，不能證明它撐得住幾 GB 的傳輸。

維運面要看清楚：這是單人專案。原始碼在 GitHub 上有六百九十二個星星、一百多個分支， 2026 年 9 月中仍在收依賴更新，安全通報有正式管道與四十八小時內應答的承諾；但近期的更動清單幾乎全是依賴套件的自動升級，功能開發的節奏已經放緩，版本號走到 3.4.3 而更新日誌停在 3.4.2。一人維護的開源工具仍可用，只是要把它當「隨時可能停止維護」的姿勢來用：程式碼在你手裡，最壞情況可以自己接手。

共用 TURN 帳號也是雙面刃：作者把免費中繼的鑰匙放在每個使用者的瀏覽器裡，用意是免設定，代價是這個中繼承受全世界的白吃流量，尖峰時刻的品質沒有保證；文件也明說，要速度與穩定就自己架 TURN。

最後是語言與介面：預設英文、要手動切繁中，前面提過；手機瀏覽器理論上可用（它有照片上傳，版面也會隨螢幕寬度調整），但我只在桌面環境實測，行動裝置體驗列為未知。

誰適合用，誰該走別條路

適合的情境很明確：兩台自己的裝置之間臨時搬一個檔案、一段文字、幾張照片；對象是旁邊的人或你信任的對象；不想為了傳一個檔案裝 App、登帳號、把檔案先上傳到雲端硬碟再請對方下載。成功的判斷基準：連線在十秒內建立、對方下載區出現檔名完整的檔案，看到這兩件事就代表這趟傳輸成立；失敗的處理順序是先確認兩邊都還掛在頁面上，再檢查 TURN 燈號是否為綠，仍然連不上就走其他工具，不需要跟它纏鬥。

該走別條路的情境：內容機敏到需要確認「對方一定是那個人」，自架訊號伺服器是底線，更簡單的做法是改用有端對端加密且身分可驗證的通訊軟體；要傳幾 GB 的大檔且需要斷點續傳，雲端傳檔服務的成熟度仍高於瀏覽器通道；要在公用電腦收檔案，掃碼式的工具比輸配對碼更不受輸入法與鍵盤配置影響。

它的價值不在功能多，而在把「信任」這件事做得很透明：程式碼短到你能整包讀完，架構簡到你能畫在一張便條紙上。對看膩了黑盒子工具的人，這一百一十二行的信號伺服器，就是它最誠實的說明文件。