閱後即焚能證明伺服器刪了密文，為什麼證明不了對方沒截圖

一句話先回答搜尋意圖

閱後即焚證明的是託管方手裡的密文被刪掉了，不是接收方的螢幕、剪貼簿和聊天紀錄被擦掉了。第一次成功取出密文後，再開啟同一條連結，閱讀頁會提示已被焚燬或已過期；依 HTTP 410 Gone 的語意，目標資源在來源站上已經不在，而且這種情況多半是永久的。這只能回答「伺服器還交不交得出來」，回答不了「對方有沒有留下副本」。

這篇文章給開發者、維運，以及要把一次性口令、API Key 或復原碼發給同事之前，想先分清「連結失效」和「對方沒留存」的人。它不代替 閱後即焚 的操作說明，也不重複「怎麼產生一條連結」。你要帶走的是：燒掉的是哪一層、重新整理失敗能證明什麼、截圖為什麼在範圍外、用兩次開啟和 Network 怎麼當場對照。

「已被焚燬」和「對方沒留下副本」不是一回事

日常說法把三件不同的事揉成一句「這則訊息看完就沒了」。第一件是伺服器不再保存密文：編號對應的紀錄被刪除，再請求只得到焚燬或過期。第二件是目前分頁不再顯示明文：關掉頁面、點「從本頁清除」，或指令碼在離開頁面時把文字框清空。第三件是接收方的裝置上沒有任何副本：沒有截圖、沒有複製、沒有把完整連結轉給別人、沒有把明文貼回聊天。

閱後即焚只對第一件有強制力，對第二件最多做到「這個分頁裡的展示區被清掉」，對第三件沒有強制力。頁面可以寫「攔不住複製或截圖」，那不是謙虛，而是邊界：瀏覽器不能禁止另一支手機對著螢幕拍照，也不能在對方點了「複製明文」之後，再去擦掉系統剪貼簿和聊天軟體的本機庫。

所以「我重新整理了一下，已經打不開了」只能支援很窄的結論：你這一次依編號取密文，伺服器沒有再交出來。它不能支援「只有他一個人看過」「他沒有截圖」「工單裡不會再搜到這串口令」。要把後幾句寫成可核對的事實，必須換一層觀察：看對方有沒有把明文或完整 URL 帶出這個分頁，而不是只看傳送方自己的第二次開啟。

伺服器燒掉的是哪一層

零知識焚鏈把「定位」和「解密」拆開。連結形態是 s.html?id={id}#{key}：問號後只有編號，金鑰只在井號後面。RFC 9110 規定請求的目標 URI 不含 fragment，瀏覽器向伺服器要文件時會丟掉 # 及之後的部分。伺服器按設計只能看到編號，看不到金鑰，也看不到明文。

建立時，瀏覽器用 Web Crypto 做 AES-256-GCM：亂數 32 位元組金鑰，12 位元組 IV，明文在本機收成密文後再 POST /secrets。出站欄位是密文、過期時間和閱讀次數；金鑰只出現在隨後拼好的分享連結裡。單條上限 32 KB。過期可選 1 小時、24 小時、7 天，或只在閱讀後焚燬；閱讀次數 1–10，預設 1 次。建立和閱讀都開啟即用，沒有帳號，也沒有「誰開啟過」的登入身分。

閱讀時，伺服器在成功交出密文並達到設定次數後，刪除這份密文。傳送方再開啟，看到的是「已被焚燬」或「已過期」。這證明：託管方不再持有那串密文位元組。它不證明：金鑰從未出現在聊天紀錄裡，明文從未出現在對方螢幕上，或者中間沒有第三人用同一條完整連結點過「開啟並檢視」。

金鑰一直在拿得到完整 URL 的人手裡。把 https://…/s.html?id=…#… 整串貼進群組，等於同時交出編號和鑰匙。伺服器即使已經燒掉密文，也擋不住「當時已經開啟過的人」把明文留下來；如果次數還沒用完，後來點開的人仍然能取到密文。燒掉密文，解決的是「託管方長期保存明文或密文」這一層，不是「看見整串連結的人」這一層。

重新整理失敗能證明什麼，證明不了什麼

第二次開啟失敗，至少要先分清三種提示。第一種是已被焚燬：密文已經不在，原因可能是讀滿了設定次數，也可能是編號本來就無效。第二種是已過期：到了建立時選的 TTL，即使沒人讀過，伺服器也會刪。第三種是缺少片段金鑰：編號可能還在，但本機解不開；LINE 和部分郵件客戶端會截斷井號後面的內容，接收方看到的是「缺少片段金鑰」，這和「已經被別人讀走」不是同一件事。

410 Gone 的意思是：來源站上的目標資源不再可用，並且這種情況很可能是永久的。閱讀頁把 410 再拆成「焚燬」和「過期」：回應裡如果帶 expired，對應 TTL；否則按焚燬處理。404 在實作裡也按焚燬展示，因為對接收方來說，結果一樣——再也取不到密文。網路失敗不能算焚燬：點過「開啟並檢視」之後才斷線，且建立時只允許讀一次，密文可能已被取走，但你這一次沒在本機解開。

因此，「我這邊重新整理打不開」能支援的結論是：現在依這個編號，伺服器不交出密文。它不能支援：開啟的人是指定的那位同事；他沒有複製；他沒有截圖；群組裡的預覽或安全掃描沒有先消耗次數。沒有帳號體系，就沒有「已讀回條」可以點名。次數是伺服器側的計數，不是對接收方裝置的稽核。

截圖、複製、聊天紀錄為什麼在範圍外

明文一旦畫在螢幕上，保護範圍就從「伺服器有沒有密文」變成「對方終端上發生了什麼」。系統截圖、螢幕錄影、另一支手機拍照，都不向託管方發請求，閱讀頁無法攔截，也無法事後通知。這不是某一家產品沒做完，而是瀏覽器和作業系統不把「禁止對方記錄螢幕」交給一般網頁。

複製同樣在範圍外。閱讀頁可以提供「複製明文」，也可以在離開頁面時清空文字框；清空的是這個 DOM 節點，不是系統剪貼簿，更不是聊天軟體的草稿匣。macOS 和部分輸入法還帶剪貼簿歷程。你看見「已從本頁清除」，只說明目前分頁不再顯示那句話，不說明這句話沒有進過剪貼簿。

聊天紀錄是另一條獨立的留存。完整連結如果出現在群組訊息裡，群組歷程、搜尋、多端同步和將來的匯出都能再次看見井號後面的金鑰。即使伺服器已經燒掉密文，連結本身仍是「曾經有效」的證據，有時也足夠讓不知道次數已用盡的人反覆點開、誤判成「連結壞了」。金鑰層在 HTTP 請求裡可以仍然乾淨——Referer 依規範不得帶 fragment——但對「能開啟聊天紀錄的人」來說，這層保護已經沒了。

工單、郵件和瀏覽器歷程也一樣。網址列顯示過的 # 片段，通常會進本機歷程；開了同步的瀏覽器，還可能把同一條紀錄送到其他裝置。清掉分頁不等於清掉歷程。閱後即焚減少的是伺服器保存時間，以及「同一條密文被反覆取出」的機會；它不是數位著作權控管，也不是鑑識報告。

狀態查詢為什麼不消耗次數

如果第一次開啟落地頁就取走密文，LINE 的連結預覽、郵件安全閘道和部分企業掃描器，可能先於接收方把僅有的一次讀完。接收方點開時只看到「已被焚燬」，金鑰其實從未交給預覽主機——燒掉的是閱讀次數，不是 fragment 的保密性。上一篇寫過井號為什麼預設不進 HTTP；這一篇只盯次數：預覽請求和「真正取出密文」必須拆開，否則「已被焚燬」連「接收方看過」都證明不了。

FastPwd 的閱讀頁把這兩步拆開。開啟頁面時只請求 /secrets/{id}/status，詢問密文還在不在，不取走密文；接收方點「開啟並檢視」之後，才 GET /secrets/{id} 取密文，並用井號後的金鑰在本機解密。缺少 # 金鑰時，頁面不會去取密文，以免浪費僅有的次數。建立頁和閱讀頁都不需要帳號。

預覽機器人通常只會拉落地頁，不會替你點按鈕；這能降低「預覽即焚燬」的機率，但不能保證所有掃描器都停在落地頁。你在 Network 裡應當能看見：先有一條 status，後有一條取密文；只開啟、不點擊時，不應出現取走密文的成功回應。次數仍然是伺服器側的計數，不是 fragment 的一部分。

當場對照：兩次開啟、status、Network

口號不能當證據。準備一句可丟棄的金絲雀，例如 canary-fp-20260905-burn-vs-shot，不要重用真實口令。建立時把閱讀次數留在預設的 1，過期用 24 小時即可。

1. 在建立頁寫入金絲雀，產生連結。開啟開發者工具的 Network，勾選 Preserve log。把金絲雀和井號後的金鑰分別貼進搜尋框：POST /secrets 的請求體裡應只有密文、過期時間和閱讀次數，不應出現原文或金鑰。
2. 用同一條完整連結開啟閱讀頁，先不要點「開啟並檢視」。Network 裡應出現 /secrets/{id}/status，不應出現成功取走密文的 GET /secrets/{id}。頁面應停留在等待確認。
3. 點「開啟並檢視」。此時才應依編號取密文，並在本機用 AES-256-GCM 解開。成功後的說明會寫：伺服器已刪除這段密文，或——若你把次數調到大於 1——達到設定次數後才會刪除。
4. 重新整理閱讀頁，或換一個全新的瀏覽器脈絡再開啟同一條連結。預設讀 1 次時，應看到已被焚燬；再搜 Network，取密文的請求應得到 410 或按焚燬處理的回應。金絲雀不應再作為明文出現在任何請求體裡。

這四步只證明一件事：在你控制的兩次開啟之間，伺服器上的密文從「還在」變成「不在」。它們證明不了：假如這是發給同事的真實口令，對方沒有截圖。要把「對方會不會留下」收成工作習慣，只能寫進交接說明：不要截圖、不要把明文貼回群組、口令用完立刻輪換——而不是指望頁面上的「已被焚燬」替你做終端稽核。

三種把「已被焚燬」讀過頭的情況

第一，把過期當成有人讀過。建立時選了 1 小時，同事第二天才點開，提示是已過期。伺服器同樣刪了密文，但刪除原因是 TTL，不是閱讀次數用盡。過期未讀的內容無法找回，也不等於「已經被開啟過」。

第二，把缺少片段當成已被焚燬。LINE、部分郵件客戶端會截掉 # 後面的內容。接收方開啟的是 s.html?id=…，沒有金鑰。閱讀頁在缺少金鑰時不會取密文。你這邊稍後開啟完整連結，內容可能還在。這時應讓對方要回含井號的整串，而不是立刻認定「有人先看過了」。

第三，把本頁清除當成全域清除。閱讀頁可以在離開時清空文字框，也可以用 history.replaceState 去掉網址列裡的片段。這只影響目前分頁的展示和後續重新整理是否還帶金鑰。系統截圖、剪貼簿歷程、聊天備份和瀏覽器同步歷程，都不在這個清空範圍裡。

常見問題

對方重新整理後看到「已被焚燬」，是不是代表他沒留下內容？

不是。這只說明伺服器上的密文已經不在，再次依編號取不到原文。截圖、複製、螢幕錄影、聊天備份和把完整連結轉給第三人，都不經過這次刪除。已被焚燬不是「對方裝置乾淨」的證明。

LINE 或郵件的連結預覽會不會先把內容燒掉？

預覽通常只開啟落地頁。閱讀頁會先查詢密文還在不在，不取走密文；點「開啟並檢視」才依編號取密文。預覽機器人多半不會替你點按鈕，但不能保證所有掃描器都停在落地頁。次數是伺服器側的計數。對照方法是：只開啟、不點擊時，Network 裡不應出現成功取走密文的請求。

閱後即焚能證明是誰開啟的嗎？

不能。建立和閱讀都不需要帳號，伺服器也不依登入身分標記閱讀者。你能核對的是：這一次取密文之後，編號還在不在。不能從「已被焚燬」反推開啟的人是誰，也不能把它寫成已讀回條。

建立和閱讀需要註冊嗎？明文會不會上傳？

不需要註冊。明文在目前分頁用 AES-256-GCM 加密後再上傳密文；金鑰放在連結的 # 片段。用金絲雀搜 Network：請求體裡應只有密文，不應出現原文或井號後的金鑰。超過 32 KB 或整份檔案，請改用 檔案加密盒 在本機處理，不要把焚鏈當雲端硬碟。

把同一句金絲雀用開啟即用的工具對照一次

若你希望用一個把計算邊界寫清楚的頁面來練習，開啟 FastPwd 的 閱後即焚 即可，無需註冊。寫入上面那句金絲雀，閱讀次數留 1，產生後按第四節做完兩次開啟。同時盯著 Network：你應看到建立時的密文 POST、閱讀頁的 status、點擊後的取密文，以及第二次開啟時的焚燬回應；不應看到原文或井號後的金鑰作為業務欄位。

必須把口令交給同事時，才走這條通道。亂數口令可以先在 密碼產生器 裡本地產生，長度 6–128 字元、預設 16 字元；低於 8 字元會提示安全性較低。產生過程不上傳。整份合約、證件掃描檔或超過 32 KB 的材料，改在 檔案加密盒 裡用同一套 AES-256-GCM 收成 .lock / .enc，單檔案不超過 5 GB；口令仍然單獨走焚鏈，不要寫進雲端硬碟備註。

下次傳送前記住三件事。第一，已被焚燬證明的是伺服器上的密文沒了，不是對方沒截圖。第二，只開啟落地頁不應消耗次數；點「開啟並檢視」才取密文。第三，完整連結貼進聊天後，井號後的金鑰對「能看見訊息的人」已經明文可見。能重複的觀察，才值得寫進你們自己的交接說明。

延伸閱讀

井號後面為什麼預設不進 HTTP，以及把完整連結貼出去時會丟掉哪一層保護，見 URL 的井號後面為什麼適合放金鑰，以及什麼時候會失效。「本地加密、不上傳」不能當證據，要用金絲雀搜 Network，見 瀏覽器本地加密怎麼核對明文沒有離開本機。若還要把工單正文裡的身分證字號在離開本機前掩碼，見 把工單和日誌貼進 AI 之前，怎麼先核對哪些欄位會離開本機。