TechMoon 科技月球
WordPress、SEO 與 AI 工具實測指南
LocalSend 免費開源跨平台傳檔：不上雲端這件事，可以自己驗
LocalSend 是免費開源的跨平台區網傳檔工具，宣稱檔案不離區域網路、零廣告零追蹤。這篇照著官方公開的傳輸協議手寫程式做實測：與官方程式完成真實互傳、雙向憑證加密、checksum 不符真的會被擋，同時整理防火牆與同網段這些實際會撞到的門檻。
用 AI 摘要這篇文章：
手機拍的影片要送到 Windows 電腦、iPad 的截圖要交給 Android 手機，這種跨系統的近距離傳檔，多數人的繞法是丟上雲端硬碟再下載，或乾脆用通訊軟體傳給自己，代價是檔案繞了一圈外部伺服器，影片還可能被壓縮。LocalSend 給的答案是另一種：全部設備裝上同一個免費開源 App，檔案直接在區域網路裡飛過去，帳號不用申請，網路斷了照樣傳。
這類「檔案不離區網」的說法，你在各種工具的宣傳頁都讀得到，問題是你只能選擇相信。LocalSend 比較特別的地方在於：它的傳輸協議整份公開放在 GitHub 上，任何人都照著規格自己驗證。我實際做了這件事，把官方釋出的命令列版本跑起來，再只照著協議文件手寫一支六十多行的 Node.js 程式充當另一台設備，兩邊在本機完成了一次真實的檔案傳輸，落地檔案的 SHA-256 驗證值與來源完全一致。過程裡還撞見兩件官網沒有大力宣傳的事：它的加密是雙向憑證驗證，比一般想像的「有 HTTPS」更嚴格；而檔案完整性檢查是真的會擋，只是時機在檔案落地之後。
先講結論：對家裡或辦公室同一段網路下的混合設備，LocalSend 是現行最不需要「信任某家廠商」的傳檔選項。它的門檻出在網路環境，技術反而是簡單的那一半，後面會把實際會撞到的坑說清楚。
我怎麼測的：官方 CLI 加上六十多行自己寫的程式
LocalSend 專案在 GitHub 上有超過 93,000 個 star（2026 年 10 月初的數字），採 Apache-2.0 授權，從 2022 年 12 月開源至今仍在活躍更新，截至 2026 年 10 月初倉庫仍持續收到新的提交。它提供 Windows、macOS、Linux、Android、iOS 五個平台的圖形介面 App，另外從 2026 年 8 月的 1.18.0 版起，官方開始釋出命令列版本 CLI，跟圖形 App 共用同一套 Rust 核心程式庫。這個 CLI 是這次驗證的關鍵工具：它把協議完整實作了一遍，又不需要動到手機。
我的做法分兩邊。一邊下載官方 CLI 1.18.2 的 macOS 執行檔（下載後先核對 SHA-256 指紋），讓它扮演接收檔案的設備。另一邊，我只打開協議文件，照著規格用 Node.js 寫了一支六十多行的發送程式，不參考任何官方原始碼，扮演傳檔的另一台設備。如果這支土砲程式能跟官方程式完成完整傳輸，就等於證明了一件事：協議文件是真的，任何第三方都能實作，你不被官方 App 綁架。
結果是全套跑通。我的程式先向官方 CLI 詢問設備資訊，拿到一個 JSON，內容包括對方的顯示名稱、協議版本 2.2、裝置類型，以及一組指紋碼。接著送出傳檔請求，官方 CLI 跳出確認提示，模擬按下接受後，它配置了一組交易代號與每個檔案專屬的權杖，我的程式把檔案位元組流送過去，落地檔案與原始檔案的 SHA-256 完全相同。全程都在這台機器的本機迴路位址上完成，沒有任何封包需要離開它。
連線先被拒絕，才知道它要的是雙向憑證
測試的第一個版本其實失敗了，而這個失敗比成功更有價值。
我的發送程式第一次去敲官方 CLI 的通訊埠時，TLS 交握直接被對方終止，錯誤訊息是 certificate required，也就是「你沒有出示憑證」。這個反應透露了一個很少有人注意到的細節：LocalSend 的傳輸通道要求雙方都要有憑證，傳送端與接收端互相驗證身分，即所謂的雙向 TLS。官方倉庫裡有一份獨立的除錯範例，說明這套機制不依賴任何外部憑證機構，而是採「首次使用即信任」原則：每台設備安裝時自己產生一把自簽憑證，第一次連線時互相記住對方的指紋，之後就能察覺身分被調包。
對一般使用者的意義是這樣：多數標榜加密的工具，驗證的只有「伺服器是不是它宣稱的那個人」；LocalSend 連「傳檔的對象是不是我認識的那台設備」也一起驗。它的安全模型因此不需要帳號系統：信任的錨點放在設備指紋上。
我把自己的自簽憑證附上之後，連線立刻放行，也就有了上面那段完整傳輸。另外兩個協議細節也順手驗了。一件是傳輸進行中如果有別的連線要求插隊，官方程式會以 409 狀態碼明確拒絕，一次只允許一個工作階段，跟協議文件的規定一致。另一件是我故意在傳輸前宣告錯誤的檔案驗證值，位元組送達後，官方程式比對不符，以 422 狀態碼拒絕這筆傳輸。檢查的時機才是重點：資料是先串流寫入硬碟、收完之後才比對，所以 422 拒絕的是這筆傳輸的效力，實測當下檔案本體仍留在目的地資料夾。完整性有把關，但屬於事後驗證，這對拿它接收不可信來源檔案的場景是個有用的認知。
檔案怎麼飛過去：協議其實只有四個動作
把實測的過程拆開，LocalSend 協議 v2.2 的全貌相當好理解，文件開頭就寫明目標是一套不依賴任何外部伺服器的 REST 協議。
起點是報身分。App 啟動時對區網的群播位址 224.0.0.167、連接埠 53317 發出 UDP 群播封包，內容是自己的名稱、裝置類型、指紋與通訊埠，同一段網路裡的其他 LocalSend 設備聽到後，會用 HTTP 請求向它登記，雙方就互相看見了。接著談條件，傳送方先把檔案的中繼資料（檔名、大小、類型、驗證值）送給接收方，接收方決定全收、部分收或拒絕，若設了 PIN 碼，這一步會要求附上。真正的位元組流傳輸排在條件談成之後，接收方配置權杖，傳送方逐檔上傳，多個檔案可以平行送。收尾的把關就是前面實測看到的：驗證值不符就拒收，中途取消也有對應的 API。
整個協議只需要接收一方架 HTTP 伺服器，這是刻意設計的寬容：就算某台設備的網路環境不允許它當伺服器，照樣能當傳送方。文件也誠實交代了一個例外，讓瀏覽器直接下載或上傳的「分享連結」頁面走的是明文 HTTP，原因很實際，瀏覽器會拒絕自簽憑證的 HTTPS 連線。也就是說，App 對 App 的通道是雙向加密，App 對瀏覽器的輔助通道是明文，拿同一台路由器下的公用電腦臨時收個檔可以，敏感內容就別走這條。
跟瀏覽器 P2P 傳檔的根本差別：斷網還能傳
同樣打著「設備對設備」的工具不少，機制上卻分成了兩個世界。瀏覽器版的 P2P 傳檔工具（例如先前介紹過的 PairDrop 這類網頁傳檔）走 WebRTC，兩台瀏覽器要先經過一個信令伺服器牽線，多數還需要 STUN 伺服器協助穿透，這表示網頁打開的那一刻，你已經依賴了外部基礎設施；對外線路一斷，牽線就失敗。LocalSend 的發現機制完全在區網內，把網際網路線拔掉，兩台設備依然互相看見、依然傳檔，這是它與瀏覽器方案最本質的差別。
兩種方案因此各有位置。臨時把檔案丟給不熟的人、對方不想裝 App，瀏覽器方案順手；自己設備之間的日常搬移，特別是大檔與斷網環境（例如出國時的飯店熱點、無對外線路的會議室），LocalSend 這種區網直傳才有意義。順帶一提，如果你的需求其實是反向的，把公用電腦上的檔案掃進自己手機，先前介紹過的 PrintRelay 免登入掃碼傳檔 是另一種臨時通道的設計；想要更快配對的近距離直傳，EasyTransfer 用四碼加密直送 也值得認識。
還有一個定位上的常見疑問：Apple 生態內有 AirDrop，Android 陣營有 Quick Share，系統內建的方案對「同陣營」的傳檔早就夠用，LocalSend 的存在理由正是那條跨陣營的縫，iPhone 對 Windows、Mac 對 Android、Linux 對任何東西。它也順手補了幾個系統工具不做的細節：除了檔案，文字訊息與剪貼簿內容也能直接送給另一台設備（官方版本說明對文字分享流程修整過多輪），命令列版還能用參數直接指定收檔資料夾。
免費、無廣告、零遙測：程式碼目前撐得起這些字
LocalSend 官網掛著幾個響亮的宣稱：五百萬次以上下載、零廣告與零追蹤、端對端加密、不需網際網路。行銷頁的數字總是值得核對；核對之後，有的屬實，有的還低估了。
零遙測這條，目前經得起原始碼檢驗。我把 App 的依賴清單整份掃過，找不到任何統計或崩潰通報 SDK，沒有 Firebase、Sentry、PostHog 這類常見套件；專案裡唯一的商業元件是捐款頁的 App 內購，而且原始碼標注了在 FOSS 版本會整段移除。程式裡對外連線的位址，除了協議本身的區網通訊，不外乎官網說明頁、GitHub 議題連結與捐款頁。隱私政策也寫得罕見地直白：不收集個人資料，連非個人資料也不收集，第三方（作業系統、裝置製造商與其他 App）的行為則明確切割不背書。
下載量級可以從 GitHub 發布頁直接讀：2026 年 8 月下旬的 1.18.2 版，macOS 安裝檔累積約 42.6 萬次下載，Windows 簽署版約 31.8 萬次，Android 主流架構安裝檔約 12.5 萬次，每個檔案各自累計。這只是 GitHub 單一渠道的量，還不包括 Google Play、F-Droid（那邊的上架頁目前正常提供）與各作業系統商店，官網宣稱的全渠道五百萬次屬合理量級，甚至偏向保守。有個小落差反而有趣：官網首頁還寫著 70k+ GitHub Stars，實際數字在 2026 年 10 月已經超過 93,000，行銷頁的更新速度追不上專案本身。
版本動向方面，1.18.0 是個分水嶺，官方版本說明寫明核心的網路與檔案 I/O 已完成 Rust 重寫、傳輸速度有感改善、checksum 檢查預設開啟，並首次釋出 CLI。瀏覽器版已經在 web.localsend.org 上線，官網導覽列也有入口，靠官方自架的信令伺服器牽線走 WebRTC；那是一條用到外部伺服器的產品線，與區網直傳的主協議並行，而且迄今未出現在桌面與手機正式版的更新說明裡。App 介面內建繁體中文（zh-TW），台灣使用者沒有語言門檻。
下載之前，先知道門檻在哪
工具本身的安裝很簡單，真正會磨掉耐性的是網路環境，GitHub 議題區把這些坑記錄得很完整。
防火牆排最前面。GitHub 議題區以防火牆為題的討論有十五件，橫跨 Windows、macOS 與 Linux：macOS 有使用者反映防火牆擋掉設備發現，Linux 社群在整理 UFW 規則，Windows 則一直有人希望安裝時自動設定防火牆，官方到 1.18.0 總算在 macOS 版加入一鍵打開防火牆設定的疑難排解按鈕。我自己這次的實測也踩到同一件事：我從另一個程序對群播位址發出身分宣告，官方 CLI 遲遲沒有看見，最後是改用直接指定 IP 的方式完成連線。單一台機器的觀察不能斷定成因，但方向與議題區的反映一致，多播封包在真實網路裡被攔、被吃掉是常態，好在協議把「手動輸入 IP」設計成內建退路。
「同網段」這個前提本身也要看清。兩台設備必須在同一個區域網路裡，這在家裡與辦公室通常成立，在公共場所就未必：不少咖啡廳與飯店的 Wi-Fi 開啟了客戶端隔離，設備之間互相看不見，LocalSend 直接失效。這屬於這類工具共同的物理限制，每家都一樣，先有預期就好。熱點是替代解，讓其中一台設備開熱點給另一台連，兩台就自成一個區網。
更隱性的門檻是身分確認的責任在你。首次連線時設備互相記住指紋，之後的加密通道確保對象沒被調包，但「第一次那一下」的判斷是人工的，接收方按下接受之前，看清楚對方名稱是否眼熟。這套模型把帳號系統省掉了，代價就是這一絲注意力。官方也提供 PIN 碼與我的最愛裝置選項，把裝置加進最愛後，後續傳輸預設自動接受，這是便利與嚴謹之間自己拿捏的光譜。
這次驗證有明確邊界：我實測的是協議層與命令列版，五個平台的圖形介面 App、手機上的背景傳輸、實體 Wi-Fi 下的傳輸速度都不在範圍內，這些面向的描述出自官方文件與版本說明。
什麼人該裝，什麼人不用
家裡同時有 Windows 電腦與 Android 手機、辦公室 Mac 要跟同事的筆電交換檔案、攝影工作室把記憶卡內容分散到不同系統的機器，這些混合設備的場景就是 LocalSend 的甜蜜點：免費、開源、無廣告、無帳號，裝完即用，協議層的隱私宣稱經得起自己動手驗證。
兩種人可以跳過。設備全在 Apple 生態裡，AirDrop 已經夠用，多裝一個 App 只是多一個煩惱；常態性的跨地點傳檔（人在台北、檔案在台中），區網工具幫不上忙，雲端硬碟或 transfer.zip 這類掃碼點對點傳檔才是對的工具。如果你的需求其實偏遠端操作與檔案瀏覽，而不是單純丟檔案，鄰雲這類區網遠端控制工具或 AndroMeld 在 Finder 裡管理 Android 會更貼近。
下載一律走官方渠道：GitHub Releases、官網 localsend.org，Android 用家也可以從 F-Droid 取得，避開來路不明的打包版。裝完如果兩台設備互看不見，先別懷疑工具，防火牆放行、確認同一網段、必要時手動輸入 IP，絕大多數的「不能用」都出在這幾個地方。
