tmpfile 極簡臨時檔案分享：上傳即生限時連結，到期自動失效

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

我把一個 36 位元組的小文字檔丟進 tmpfile 的頁面，進度條跑滿就停住，沒有錯誤訊息、沒有下載連結，什麼都沒發生。打開瀏覽器的網路紀錄才看到答案：伺服器回了 401，拒絕未授權的上傳。這個 2025 年中被介紹為「極簡臨時檔案分享」的小工具，免費匿名上傳這條路已經封起來了，而且介面不會告訴你。

tmpfile 原本的賣點很單純：把檔案丟上去，換一條隨機產生的下載連結，連結到期自動失效，適合把檔案臨時交給別人，或者餵給需要讀取公開連結的 AI 服務。這篇整理它這一年的變化：入口搬到哪裡、上傳為什麼會靜靜失敗、金鑰從哪裡來、連結的自動消失是怎麼設計的，以及沒有金鑰的人現在有哪些替代路線。

tmpfile 現在還能用嗎？入口已經搬家

先講最重要的：多數介紹文章裡給的網址 tmp.dlload.cn 已經打不開。這個子網域被從網域名稱系統裡整筆移除，查詢只會回報查無紀錄，連伺服器故障都談不上。工具本體還活著，新入口是 dlload.com（dlload.cn 也通），打開後仍是同一個 tmpfile 標題與極簡版面。

把這一年攤開看：2025 年 6 月，入口在 tmp.dlload.cn、後端（實際接收藏檔案的伺服器）在 dl.dlload.cn，當時金鑰欄標為選填，匿名上傳是預設用法；同年 8 月的頁面存檔裡，自家服務的促銷卡與統計端點（回報造訪紀錄的介面位址）已經掛上，生態化的佈置先就位。到了現在，舊入口從網域名稱系統移除，舊後端的網域還在、後方主機已經連不上（連線閘道回報逾時），新後端 dl.xabclabs.com 匿名一律回 401。一年內前端與後端各搬了一次家，順便把匿名這條路收了起來。

頁面本身的變化也誠實反映了方向。舊版存檔裡，中央虛線上傳區還寫著 Drop files here，現在這個區域是空的，只剩螢幕閱讀器會讀到的替代標籤；頁面頂端則多了預設攤開的兩個欄位，伺服器位址（預設指向 dl.xabclabs.com）與 API 金鑰。舊版程式把這組設定欄的顯示開關整行註解掉，一般人根本看不到，現在則是沒存過金鑰的人一進場就會看到。介面的重心已經從打開就傳，挪到先交出金鑰。

Pin

順帶一提介面語言：頁面只有英文，站內雖然留了中文路徑，但所有字串照樣是英文，對台灣使用者來說門檻不高，只是別期待有繁中介面。另外 dlload.com 的網域存檔最早可以追溯到 2012 年，比 2025 年出現的這個工具早得多，這類個人域名上的小工具會怎麼演化，從網域履歷就能看出些端倪。

丟了檔案卻沒有任何反應，卡住的是哪一環

我用瀏覽器實際操作一次：選一個 36 位元組的文字檔丟進上傳區，佇列裡出現檔名與一條藍色進度條，進度條跑滿，畫面就定格在那裡。沒有錯誤、沒有連結，等再久也不會有下文。

側錄這次操作的網路請求，會看到上傳被打到預設後端 dl.xabclabs.com，伺服器回覆 401 Unauthorized，意思是要有金鑰才受理。換成命令列直接呼叫同一個介面，結果相同，所以跟瀏覽器或你的網路環境無關，就是伺服器端的身分檢查。除了上傳，這個後端還有一個列出檔案的介面，同樣擋在金鑰牆後面，可以想見金鑰除了開通上傳，也對應到一個帳戶層級的檔案清單。

更值得記下來的是介面的反應。網頁程式其實有把錯誤寫進畫面，佇列項目的狀態文字是 Error: Unauthorized，但這個工具的樣式表裡有一條規則，把所有帶 error 類別的元素設成隱藏。那條規則原意是給頁面頂端的錯誤橫幅用的，選擇器一視同仁，連上傳佇列的錯誤狀態也被一起藏掉。我在瀏覽器裡檢查那行文字的最終樣式，確實是隱藏狀態。結果就是你看到的畫面：一條停在原地的進度條，加一句你永遠看不到的拒絕理由。

這類樣式碰撞在工程上是幾行程式碼的小事，對使用者卻是判斷依據的全面消失。一個會把錯誤吞掉的工具，出了任何狀況你都只能重試，重試的結果永遠一樣，你也不會知道該換金鑰、換瀏覽器還是換工具。以它目前的版本，把「上傳失敗會告訴你為什麼」當成基本要求的人，可以先把它從候選裡劃掉。

對使用者的實際影響是，你無法分辨被拒絕、斷線、還是在慢速上傳，只能對著進度條猜。如果你照著 2025 年的教學操作，體驗就是卡死，而且沒有任何線索告訴你問題出在金鑰。

Pin

那把金鑰要去哪裡拿

頁面上沒有申請入口，站方也沒有留下公開的說明文件。往經營者方向追，線索倒是很整齊：這個頁面載入時，會把你造訪的網址與來源頁回報給一個統計端點；頁面右側掛著一張自家服務的促銷卡；預設後端的網域，就掛在這批服務所屬公司 XABC Labs 的網域之下。這家公司在自家頁尾署名，標注 2022 至 2026，主業是 AI 模型的 API 路由服務，統一介面轉接各家大模型，經營內容相當活躍，部落格與文件持續更新到 2026 年 9 月，旗下另一個路由器產品則主打多租戶治理，定位是把企業或團隊的模型金鑰集中託管、分發子帳戶。tmpfile 看起來是這個生態的周邊小工具，讓使用者快速把檔案變成公開連結，餵給需要讀取網址的 AI 服務。這層關係是從程式碼與網域痕跡推出來的，站方自己沒有明說；我也翻過它們的文件站，兩百多個頁面裡沒有任何檔案上傳服務的條目，金鑰與 tmpfile 的對應方式，只能靠實際拿一把去試。

所以金鑰大概率跟著那套 AI 服務的帳號體系走，而非 tmpfile 自己的註冊流程。你若本來就是它的用戶，拿既有金鑰試一次上傳介面是最快的驗證法；不是的話，目前沒有一條寫明白的申請路徑可以走。

程式另外留了一扇門：伺服器位址欄可以改。整個上傳流程的合約並不複雜，把檔案以表單送到你指定伺服器的 upload 介面，伺服器回傳下載連結、檔名、大小與到期時間，前端負責顯示。想自架相容後端的人照這個合約實作即可，只是後端沒有公開原始碼，公開倉庫裡查不到，得從頭自己寫。

連結為什麼會自己消失

臨時檔案服務的核心設計，從舊版下載連結的格式還讀得出來。網際網路檔案館留著兩條 2025 年 6 月的實例：檔名前段是八碼隨機字元，後面接著一串月日時分格式的數字，副檔名沿用原檔。隨機碼的作用是防猜測、防搜尋引擎收錄；嵌進檔名的時間戳，則讓伺服器端計算到期這件事變得很單純。這兩條存檔連結後來再訪都是 404，與短時效的設計一致。

當時對外的說法，是檔案保留一小時、累計下載三次就刪，額度用完檔案跟著消失。這組數字屬於 2025 年的政策，現在實際值多少，外部驗證不了，因為所有檔案介面都在金鑰牆後面。拿到金鑰之前，到期時長與次數上限都該當成未知數看待，先丟個無關緊要的小檔實測，比相信任何文章都可靠。

前端倒是把到期機制做得很透明。上傳成功後伺服器會回一個到期時間，歷史清單裡每筆紀錄都顯示上傳時間與到期時間的對照，過期的紀錄自動從清單剔除。要注意這份歷史只存在瀏覽器的本機儲存裡，上限 512 筆，換電腦、換瀏覽器或清掉網站資料就沒了；佇列同時最多跑三個上傳，檔案選擇支援一次多選，清單還有一鍵複製全部連結的按鈕，對「一次交一批文件給 AI」的場景算是有想到。連結本身在伺服器上自生自滅，清單只是你這台機器的備忘錄。

早期還有一個貼心細節流傳下來：同一個瀏覽器重複點擊下載連結，只會觸發一次真實的伺服器下載，不會白白消耗珍貴的次數額度。這種設計在現在的版本是否保留，同樣驗證不了，但從前端的單純程度看，計數邏輯全部在伺服器端，前後端各自演化後，行為以實測為準最保險。

還有一層壽命常被忽略：連結活多久，由工具承諾的自動到期決定，也由服務本身的存續決定，而後者從來不在你手裡。這個工具一年內換了入口、換了後端，舊連結全數失效；臨時連結丟進聊天訊息或文件註腳，幾天後對方點開是 404，多半不是對方操作錯誤，是服務那一層先到期了。

沒有金鑰的替代路線

如果你只是要把檔案交給另一個人，而且你們可以同時開著瀏覽器，點對點互傳是更省事的路：兩邊開同一個網頁，檔案直接在瀏覽器之間傳送，不落在第三方的硬碟上，我們實測過的 PairDrop 是這類工具裡很順手的選擇。要是對象不方便同時出現、需要非同步交付，把檔案加密切片再借助外部空間的 MixFile 提供另一種隱私取向的做法，金鑰不在對方手上就解不開。各類傳檔路線的適用情境與風險，整理在 檔案互傳工具總覽 裡，按情境挑選就好。

至於「上傳換一條限時連結」這個特定需求，自架相容後端是最自主的解法，介面合約前一節已經提過，並不複雜；不想自架，就先想清楚檔案能交給誰，再從上面的路線裡挑。

開頁就回報造訪，刪除宣稱也驗證不了

無論有沒有金鑰，先看頁面本身：開頁這個動作，就會把你的網址與來源頁送到第三方統計端點，對隱私敏感的場景要把這筆成本計入；實測當下這個統計端點與那張促銷卡都沒能正常載入，但不影響對程式意圖的判讀。另外，早期流傳的「伺服器端刪除百分之百可靠」這類宣稱，閉源服務從外部永遠無法證實，自動刪除是設計意圖，把它當保證，等於把自己的檔案押在別人的維運紀律上。真正機敏的檔案，一開始就不該走任何第三方中轉。

一句話收尾：把 tmpfile 當成某個 AI 服務生態的周邊小工具看待，它的入口網址與存續（以及牆後面的任何額度），都跟著那個生態起伏。站在生態外的人，看清這一點比糾結它好不好用更重要；手邊的檔案該怎麼安全交出去，上面幾條替代路線都比一條安靜卡住的進度條可靠。